1. 项目概述：从“直接干”到“先想后做”的思维跃迁

在AI智能体（Agent）的开发浪潮里，我们常常会陷入一个误区：拿到一个任务，就迫不及待地让大模型（LLM）开始“干活”。无论是写代码、分析数据还是规划行程，我们习惯于构建一个“感知-行动”的快速循环。这听起来很高效，就像看到一个按钮就按下去。但实际结果呢？代码逻辑混乱、数据分析跑偏、行程规划漏掉关键环节……问题层出不穷。其根源在于，我们让AI在缺乏全局视角和深度思考的情况下，就开始了具体操作。这就像让一个建筑师不看图纸就去砌墙，效率低下且错误百出。

“Plan-and-Solve”（先规划，再解决）正是针对这一痛点的系统性方法论。它不是一个具体的工具或框架，而是一种核心的智能体设计范式。其核心理念可以概括为： 在面对复杂任务时，强制智能体进行前置的、结构化的思考与规划，形成明确的步骤蓝图，然后再按图索骥地执行 。这与人类处理复杂问题的本能方式高度一致——我们先在脑子里或者纸上列出大纲、分解步骤，而不是提笔就写。

从技术演进上看，Plan-and-Solve是对早期ReAct（Reasoning and Acting）范式的深化与补充。ReAct通过“思考-行动-观察”的循环，让智能体具备了初步的推理能力，但它更侧重于在行动中动态调整。而Plan-and-Solve则强调“静态规划”的重要性，主张将大部分推理工作前置。这并不是说ReAct过时了，而是两者可以结合：先通过Plan-and-Solve制定一个高质量的初始计划，再在ReAct的循环中微调和执行。当前热门的LangGraph、CrewAI等框架，其底层工作流引擎都非常适合实现这种“规划-执行-监控”的混合模式。

对于智能体开发者、AI应用工程师乃至任何希望利用大模型解决复杂问题的人来说，理解并实践Plan-and-Solve都至关重要。它能显著提升智能体任务完成的成功率、可控性和可解释性。简单说，它让AI从“莽夫”变成了“谋士”。接下来，我将结合具体的技术选型（如LangGraph）和实战代码，拆解如何为你的智能体注入“先想清楚”的能力。

2. 核心范式解析：Plan-and-Solve vs. ReAct

要理解Plan-and-Solve的价值，必须将其与它的“前辈”ReAct放在一起对比。很多人会把它们对立起来，但实际上，它们是互补关系，适用于不同的任务粒度和复杂度。

2.1 ReAct：在行动中思考的动态策略

ReAct范式可以概括为 Reason -> Act -> Observe -> Loop 。智能体在每一步都会生成一个“思考”（Reason），基于这个思考决定一个“行动”（Act，如调用一个工具），然后观察（Observe）行动的结果，并进入下一轮循环。

它的优势在于灵活性：

  • 适应不确定性 ：对于环境反馈敏感、路径不确定的任务（如交互式调试、探索性网页浏览），ReAct能根据最新观察实时调整策略。
  • 即时纠错 ：当某一步行动失败或产生意外结果时，智能体可以在下一轮思考中立即尝试替代方案。

但其局限性也很明显：

  • 短视风险 ：容易陷入局部最优，缺乏对任务整体的长远规划。比如写一篇长文，可能开头写得过于详细，导致后面篇幅不足或结构失衡。
  • 效率问题 ：每一步都要进行“思考-行动”的循环，对于已知步骤明确的复杂任务，会产生大量冗余的LLM调用，增加成本和延迟。
  • 规划深度不足 ：LLM的单步思考很难承载复杂的、多层次的分解逻辑。

一个典型的ReAct循环伪代码结构如下：

# 伪代码示意
state = {"task": "写一篇关于气候变化的文章", "history": []}
while not task_finished(state):
    # 1. Reason: 根据当前状态和历史，思考下一步该做什么
    reasoning = llm.generate_reason(state, state["history"])
    # 2. Act: 根据思考结果，选择工具并执行
    action, parameters = llm.decide_action(reasoning)
    result = execute_tool(action, parameters)
    # 3. Observe: 记录行动结果
    state["history"].append((reasoning, action, result))
    # 更新状态，判断是否继续
    state = update_state(state, result)

2.2 Plan-and-Solve：谋定而后动的静态蓝图

Plan-and-Solve范式则将流程拆分为两个截然不同的阶段：

  1. 规划阶段 (Plan) ：在此阶段，智能体接收初始任务，并利用LLM的推理能力，生成一个完整的、结构化的任务分解计划。这个计划通常是一个步骤列表（Step List）或一个有向无环图（DAG），明确规定了“要做什么”以及“步骤之间的依赖关系”。
  2. 解决阶段 (Solve) ：严格（或相对严格）地按照规划阶段产出的蓝图，依次执行每个步骤。在执行每个步骤时，可以调用必要的工具（Tools），并将结果传递给后续步骤。

它的核心优势在于：

  • 全局一致性 ：在开始任何具体工作前，就对整个任务有了全景视图，能确保最终成果的结构完整性和逻辑自洽。
  • 执行高效 ：一旦计划制定，执行阶段就变成了相对机械化的过程，减少了反复调用LLM进行决策的开销，尤其适合批量处理相似任务。
  • 可解释性与可控性 ：产出的计划是人类可读、可审查、可干预的。在计划执行前，开发者或用户就可以审核计划是否合理，并进行手动调整。
  • 复杂任务处理 ：能够更好地处理需要多步骤、多条件分支的复杂任务。

当然，它也有其适用边界：

  • 依赖环境稳定 ：如果任务执行环境变化剧烈，事先制定的计划可能迅速失效。
  • 规划成本 ：制定一个高质量的计划本身需要一次（有时是多次）LLM调用，对于极其简单的任务，这可能显得“杀鸡用牛刀”。

一个典型的Plan-and-Solve两阶段伪代码如下：

# 第一阶段：规划
task = "为公司新产品‘智能水杯’设计一个上线社交媒体（微博、小红书）的推广方案，包括内容方向和发布节奏。"
plan_prompt = f"""
你是一个资深市场营销策划。请为以下任务制定一个详细的分步执行计划。
任务：{task}
请以清晰的列表形式输出计划，每一步都应该是具体、可执行的动作。
"""
plan = llm.generate(plan_prompt) # 输出可能是一个多步列表
# 示例计划：
# 1. 分析产品核心卖点与目标用户画像（25-35岁都市白领，注重健康与科技感）。
# 2. 竞品调研：分析市场上类似产品的社交媒体推广策略。
# 3. 确定微博、小红书两个平台的内容风格差异与发布形式（微博重话题、新闻稿；小红书重体验、种草图文/视频）。
# 4. 规划首月内容日历：第一周产品揭秘，第二周KOL体验投放，第三周用户互动活动，第四周口碑总结。
# 5. 设计具体的内容素材（文案、图片、视频脚本）清单。
# 6. 制定发布后的数据监控指标与反馈收集机制。

# 第二阶段：解决
steps = parse_plan_to_steps(plan) # 将文本计划解析为结构化步骤对象
for step in steps:
    if step.needs_tool:
        result = execute_tool(step.tool_name, step.parameters)
        step.result = result
    else:
        # 可能需要LLM进行内容生成等
        step.result = llm.generate(step.instruction)
    # 将上一步结果作为上下文传递给下一步（如果需要）
    context = update_context(context, step.result)
final_output = compile_results(steps)

2.3 如何选择与结合：动态与静态的融合

在实际项目中，纯Plan或纯ReAct都较少见，更多的是两者的融合。一个高效的智能体架构往往是 “宏观Plan，微观ReAct” 或者 “主干Plan，分支ReAct” 。

  • 场景一：复杂项目开发 。你可以用Plan-and-Solve制定开发蓝图（需求分析 -> 架构设计 -> 模块A开发 -> 模块B开发 -> 联调测试），而在“模块开发”这个具体步骤内部，采用ReAct范式来调用代码解释器、搜索引擎等工具，解决编码中的具体问题。
  • 场景二：数据分析报告 。先用Plan制定分析大纲（数据获取 -> 数据清洗 -> 描述性统计 -> 相关性分析 -> 可视化 -> 结论撰写）。在“数据清洗”这一步，如果遇到异常值处理规则不明确的情况，可以转入一个ReAct子循环，让LLM判断如何处理这个异常值。

选择的关键在于任务的结构化程度和不确定性：

  • 高结构化、低不确定性 ： 强烈推荐Plan-and-Solve 。例如：代码生成（根据详细需求生成CRUD API）、文档总结（按固定模板提取信息）、流程审批（固定的步骤序列）。
  • 低结构化、高不确定性 ： ReAct或加强版ReAct更合适 。例如：开放域问答（需要实时搜索）、故障排查（路径未知）、创意写作（需要随时迸发灵感）。
  • 混合型任务 ： 采用分层策略 。顶层用Plan分解出几个大的、目标明确的子任务，每个子任务内部根据其特性选择Plan或ReAct。

实操心得 ：不要陷入“非此即彼”的框架战争。我的经验是，为你的智能体设计一个“规划器（Planner）”模块和一个“执行器（Executor）”模块。规划器负责生成和优化计划，执行器负责按计划运行，并允许在特定节点触发ReAct子循环。这种架构提供了最大的灵活性。

3. 技术实现深度剖析：以LangGraph构建Plan-and-Solve智能体

理解了范式，我们来看如何实现。这里我选择LangGraph作为实现框架，因为它用“图”的概念来建模工作流，与Plan-and-Solve的思想天然契合。图中的节点（Node）可以代表规划步骤或执行动作，边（Edge）代表步骤间的流转条件。

3.1 架构设计：状态机与有向图

在LangGraph中，智能体的核心是一个 StateGraph 。状态（State）是一个字典，承载了任务执行过程中的所有信息。我们的Plan-and-Solve智能体可以设计为包含以下关键状态属性：

from typing import TypedDict, Annotated, List
from langgraph.graph.message import add_messages
import operator

class AgentState(TypedDict):
    # 输入与核心状态
    original_task: str  # 原始任务描述
    plan: List[str]     # 规划阶段生成的步骤列表
    current_step_index: int  # 当前执行到的步骤索引
    current_step_result: str # 当前步骤的执行结果
    accumulated_results: Annotated[list, operator.add]  # 累积所有步骤的结果
    # 执行上下文
    context: str  # 传递给LLM的上下文信息，包含历史结果
    # 控制流
    should_continue: bool  # 是否继续执行

我们的工作流图将包含两类主要节点：

  1. 规划节点 (Plan Node) ：接收原始任务，调用LLM生成计划，并将计划存入状态。
  2. 解决节点 (Solve Node) ：这是一个“多路复用”节点。它根据 current_step_index 从 plan 中取出对应的步骤描述，调用LLM或工具执行，并更新状态。

边（Edges）则控制流程：从 开始 -> 规划节点 -> 解决节点 -> 判断 -> 循环回解决节点或结束 。

3.2 规划节点的实现：让LLM成为战略家

规划节点的目标是生成一个高质量、可执行的步骤列表。提示词（Prompt）工程在这里至关重要。

from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI

# 1. 定义规划提示词模板
PLANNER_PROMPT = ChatPromptTemplate.from_messages([
    ("system", """你是一个卓越的任务规划专家。你的目标是将一个复杂的用户任务分解为一系列清晰、离散、可顺序执行的具体步骤。
每个步骤都应该是一个简单的动作句，例如‘搜索关于XX的最新资料’，‘编写一个实现YY功能的Python函数’，‘对比A和B的优缺点并总结’。
请确保步骤之间逻辑连贯，前一步的输出通常可以作为后一步的输入。避免步骤过于庞大或模糊。"""),
    ("human", "请为以下任务制定执行计划：{task}")
])

# 2. 创建规划链
llm = ChatOpenAI(model="gpt-4-turbo", temperature=0.1) # 低temperature保证规划稳定性
planner_chain = PLANNER_PROMPT | llm

# 3. 定义规划节点函数
def plan_node(state: AgentState):
    """规划节点：生成任务步骤列表"""
    task = state["original_task"]
    # 调用LLM生成计划文本
    plan_response = planner_chain.invoke({"task": task})
    plan_text = plan_response.content

    # **关键步骤**：解析LLM返回的文本，提取结构化的步骤列表。
    # 这里假设LLM以数字列表形式返回，如“1. ... 2. ...”
    # 在实际应用中，你可能需要更鲁棒的解析器，或让LLM以JSON格式返回。
    steps = [line.strip() for line in plan_text.split('\n') if line.strip() and (line.strip()[0].isdigit() or line.startswith('-'))]
    # 简单清理：移除编号和项目符号
    cleaned_steps = [step.split('. ', 1)[-1].split('- ', 1)[-1] for step in steps]

    # 更新状态
    new_state = {
        "plan": cleaned_steps,
        "current_step_index": 0, # 从第一步开始
        "context": f"原始任务：{task}\n生成计划：{plan_text}", # 初始化上下文
        "should_continue": len(cleaned_steps) > 0 # 如果有步骤，则继续
    }
    return new_state

注意事项 ：规划阶段LLM的 temperature 参数建议设置较低（如0.1-0.3），以确保生成的计划稳定、可靠。高温度可能导致每次生成的计划差异巨大，不利于后续自动化执行。此外， 强烈建议让LLM以结构化格式（如JSON）输出计划 ，这能极大简化后续的解析逻辑，提高系统鲁棒性。你可以修改提示词，要求LLM输出 {"steps": ["step1", "step2", ...]} 的格式。

3.3 解决节点的实现：稳健的执行引擎

解决节点是工作流的核心循环体。它需要：1. 获取当前步骤指令；2. 组织执行上下文；3. 调用LLM或工具；4. 保存结果。

from langchain_community.tools import DuckDuckGoSearchRun
from langchain_core.tools import Tool

# 假设我们有一些工具可供调用
search_tool = DuckDuckGoSearchRun()
# 可以定义更多工具，如：代码执行器、文件读写器、API调用器等
def fake_calculator(expression: str) -> str:
    """一个假的计算器工具示例"""
    try:
        return str(eval(expression))
    except:
        return "计算错误"

tools = [
    Tool(name="WebSearch", func=search_tool.run, description="当需要获取最新、实时的公开信息时使用此工具。"),
    Tool(name="Calculator", func=fake_calculator, description="用于执行数学计算。")
]

# 解决节点的提示词模板
SOLVER_PROMPT = ChatPromptTemplate.from_messages([
    ("system", """你是一个严谨的任务执行者。请严格根据‘当前步骤’的要求和‘上下文’中已有的信息，完成指定的工作。
你可以使用提供的工具来获取信息或进行计算。你的回答应聚焦于完成当前步骤，输出结果应简洁、完整，便于后续步骤使用。
如果步骤要求生成文本（如写摘要、写代码），请直接输出最终成果。"""),
    ("human", """
**上下文信息（历史步骤结果）**:
{context}

**当前需要执行的步骤**:
{current_step}

请完成上述步骤。如果你认为需要使用工具，请说明你将使用哪个工具以及输入是什么。否则，请直接输出步骤结果。
""")
])

solver_chain = SOLVER_PROMPT | llm.bind_tools(tools) # 将工具绑定给LLM

def solve_node(state: AgentState):
    """解决节点：执行单个计划步骤"""
    plan = state["plan"]
    idx = state["current_step_index"]
    accumulated = state.get("accumulated_results", [])

    if idx >= len(plan):
        return {"should_continue": False, "current_step_result": "所有步骤已完成。"}

    current_step_description = plan[idx]
    # 构建上下文：包含原始任务、计划、以及之前所有步骤的结果
    historical_context = "\n".join([f"步骤{i+1}结果：{res}" for i, res in enumerate(accumulated)])
    full_context = f"{state.get('context', '')}\n{historical_context}"

    # 调用LLM执行步骤
    response = solver_chain.invoke({
        "context": full_context,
        "current_step": current_step_description
    })

    # 处理响应：检查LLM是否想调用工具
    step_result = ""
    if response.tool_calls:
        # LLM请求调用工具
        for tool_call in response.tool_calls:
            tool_name = tool_call['name']
            tool_args = tool_call['args']
            # 找到对应的工具并执行
            tool_to_use = next((t for t in tools if t.name == tool_name), None)
            if tool_to_use:
                tool_output = tool_to_use.invoke(tool_args)
                step_result += f"[调用工具 {tool_name}，输入：{tool_args}，输出：{tool_output}]\n"
            else:
                step_result += f"[尝试调用未知工具 {tool_name}，失败。]\n"
        # 工具调用后，可能需要让LLM基于工具结果进行总结（这里简化处理，将工具输出直接作为结果）
        # 更复杂的实现可以在这里引入一个子循环，让LLM消化工具输出后再给出最终步骤结果。
    else:
        # LLM直接给出了文本结果
        step_result = response.content

    # 更新状态
    new_accumulated = accumulated + [f"步骤{idx+1}（{current_step_description}）：{step_result}"]
    new_state = {
        "current_step_index": idx + 1,
        "current_step_result": step_result,
        "accumulated_results": new_accumulated,
        "context": full_context, # 更新上下文
        "should_continue": (idx + 1) < len(plan) # 判断是否还有下一步
    }
    return new_state

3.4 组装工作流与条件判断

最后，我们用LangGraph将节点和边组装起来，形成一个完整的工作流。

from langgraph.graph import StateGraph, END

# 创建图
workflow = StateGraph(AgentState)

# 添加节点
workflow.add_node("planner", plan_node)
workflow.add_node("solver", solve_node)

# 设置入口点
workflow.set_entry_point("planner")

# 添加边：规划完成后，进入解决节点
workflow.add_edge("planner", "solver")

# **关键部分：定义条件边**
# 从解决节点出来后，根据状态中的 `should_continue` 决定是循环还是结束
def decide_after_solve(state: AgentState):
    if state.get("should_continue", False):
        return "solver" # 回到解决节点，执行下一步
    else:
        return END # 结束

workflow.add_conditional_edges(
    "solver",
    decide_after_solve, # 条件判断函数
    {
        "solver": "solver",
        END: END
    }
)

# 编译图
app = workflow.compile()

现在，你可以运行这个智能体了：

# 定义初始状态
initial_state = {"original_task": "查询特斯拉（Tesla）当前股价，并计算如果购买100股需要多少美元。", "accumulated_results": []}
# 执行图
final_state = app.invoke(initial_state)

print("=== 生成计划 ===")
for i, step in enumerate(final_state.get("plan", [])):
    print(f"{i+1}. {step}")

print("\n=== 执行结果 ===")
for result in final_state.get("accumulated_results", []):
    print(result)

这个智能体会先规划出类似 ["搜索特斯拉当前股价", "使用计算器将股价乘以100"] 的步骤，然后依次执行，最终给出结果。

4. 高级技巧与实战避坑指南

掌握了基础实现后，我们来看看如何让Plan-and-Solve智能体变得更强大、更可靠。这些都是从实际项目中踩坑总结出来的经验。

4.1 提升规划质量的三大策略

规划阶段的质量直接决定了整个任务的成败。

  1. 多轮规划与反思 ：不要让LLM只做一次规划。可以采用“规划-批判-优化”的循环。

    def reflective_planner(task, max_rounds=2):
    plan = initial_planner(task)
    for _ in range(max_rounds-1):
        critique = critic_chain.invoke({"task": task, "plan": plan}) # 另一个LLM角色批判计划
        if "没有问题" in critique or "很好" in critique: # 简单的停止条件
            break
        # 根据批判意见重新规划
        plan = planner_chain.invoke({"task": task, "critique": critique})
    return plan

    提示词设计 ：批判者（Critic）的提示词可以要求它检查计划的：步骤粒度是否均匀、逻辑顺序是否合理、是否有缺失的关键环节、步骤是否真正“可执行”。

  2. 领域知识注入 ：通用LLM可能对特定领域（如法律、医疗、金融）的流程不熟悉。在规划提示词中提供领域特定的规划模板或约束条件。

    例如：“你是一个资深DevOps工程师。请按照标准的CI/CD流水线阶段（代码提交 -> 静态检查 -> 单元测试 -> 构建镜像 -> 部署到预发环境 -> 集成测试 -> 部署生产）来规划以下应用的发布任务...”

  3. 输出格式强制 ：如前所述，使用Pydantic或JSON Schema来严格约束LLM的输出格式。LangChain对此有很好的支持。

    from pydantic import BaseModel, Field
from langchain_core.output_parsers import PydanticOutputParser

class PlanSchema(BaseModel):
    steps: List[str] = Field(description="有序的任务步骤列表")
    estimated_time_per_step: List[float] = Field(description="每个步骤的预估耗时（分钟）")
    dependencies: List[List[int]] = Field(description="步骤间的依赖关系，如[[2,1]]表示步骤2依赖于步骤1")

parser = PydanticOutputParser(pydantic_object=PlanSchema)
prompt = ChatPromptTemplate.from_template(
    "...你的回答格式必须遵循：{format_instructions}...\n任务：{task}"
).partial(format_instructions=parser.get_format_instructions())

4.2 执行阶段的容错与优化

计划赶不上变化，执行阶段必须有容错机制。

  1. 步骤执行超时与重试 ：为每个步骤设置超时时间。如果LLM调用或工具执行超时，自动重试（最多N次），并在重试失败后记录错误，根据预设策略决定是跳过该步骤、终止整个任务，还是转入人工审核。
  2. 动态上下文窗口管理 ：随着步骤累积， accumulated_results 会越来越长，可能超出LLM的上下文窗口。需要设计摘要策略（Summarization Strategy）：每完成3-5个步骤，或用一个新的LLM调用，将之前步骤的详细结果总结成一段精炼的摘要，替换掉冗长的历史记录，只保留最关键的信息供后续步骤参考。
  3. 工具调用异常处理 ：工具可能失败（如网络错误、API限流）。在执行工具调用的代码块中，必须使用 try...except 进行包裹，并将清晰的错误信息捕获后，作为状态的一部分传递给下一步。更好的做法是，设计一个“错误处理”节点，专门处理执行失败的情况，并尝试修复（如更换参数重试、选择备用工具等）。

4.3 与ReAct的混合模式实现

如前所述，最强大的架构是混合模式。在LangGraph中，这很容易实现：在 solve_node 中，如果当前步骤的描述包含“探索”、“分析可能原因”等开放性关键词，可以触发一个子图（Subgraph），这个子图内部是一个完整的ReAct循环。

from langgraph.graph import StateGraph as SubStateGraph

# 定义一个内部ReAct子图（简化版）
def create_react_subgraph():
    react_graph = SubStateGraph(...)
    # ... 定义ReAct的思考、行动、观察节点
    return react_graph.compile()

react_subgraph = create_react_subgraph()

def solve_node_with_react(state: AgentState):
    current_step = state["plan"][state["current_step_index"]]
    # 判断是否进入ReAct模式
    if needs_react(current_step): # 自定义的判断函数
        # 将当前步骤作为初始问题，传入子图
        subgraph_result = react_subgraph.invoke({"problem": current_step, "context": state["context"]})
        step_result = subgraph_result["final_answer"]
    else:
        # 正常执行Plan-and-Solve模式
        step_result = normal_solve(current_step, state["context"])
    # ... 更新状态

这种设计使得智能体在主体框架清晰的前提下，保留了处理局部不确定性的敏捷性。

4.4 常见问题排查与调试技巧

  1. 计划过于空泛 ：如步骤描述为“分析数据”、“撰写报告”。

    • 排查 ：检查规划提示词是否明确要求“具体、可执行的动作”。提高提示词中示例的质量。
    • 解决 ：在提示词中加入反面示例：“不好的步骤：‘分析数据’。好的步骤：‘使用Pandas加载data.csv文件，并计算销售额字段的平均值和标准差。’”

  2. 步骤间信息传递断裂 ：后一步无法正确使用前一步的结果。

    • 排查 ：打印每个步骤执行前后的 context 状态，查看信息是否被正确拼接和格式化。
    • 解决 ：强制规定步骤结果的输出格式。例如，要求每个步骤的结果都以 ## 步骤X结果：[清晰的内容] 格式输出，并在下一步的提示词中明确指示“请特别注意‘## 步骤X结果’中的内容”。

  3. 智能体在某个步骤“卡住”或循环 。

    • 排查 ：检查 solve_node 中LLM的响应。它是否在反复调用同一个工具而没有进展？是否生成了无法被解析为工具调用的内容？
    • 解决 ：引入最大步数限制（Max Step Limit）。在状态中增加一个 steps_taken 计数器，在 decide_after_solve 函数中，不仅检查 should_continue ，也检查 steps_taken 是否超过阈值，若超过则强制跳转到 END 或一个“人工干预”节点。

  4. 工具选择错误 ：LLM为步骤选择了不合适的工具。

    • 排查 ：检查工具的描述（ description ）是否清晰、无歧义，是否与步骤任务高度相关。
    • 解决 ：优化工具描述。使用更具体、包含关键词的描述。例如，将“搜索工具”的描述从“搜索信息”改为“当需要获取实时、公开的网页信息，如新闻、股价、天气时使用此工具。不适合查询内部数据库或进行复杂计算。”

我个人最深刻的体会是 ：Plan-and-Solve智能体的稳定性，80%取决于规划阶段的质量。花时间精心设计规划提示词、实施多轮反思、并强制结构化输出，这比在解决阶段添加复杂的容错逻辑要有效得多。把LLM想象成一个需要明确指令和优秀模板的实习生，你给它的蓝图越清晰，它交付的成果就越可靠。

# AI智能体
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

一次 API 调用搞定时序预测：时序大模型 TimechoAI 使用与能力全解析

avatar 亚马逊云科技技术品牌专区
cover

智能软件工程AI4SE（十六）——需求工程工具Jira

avatar 亚马逊云科技技术品牌专区

AI Agent 面试题 353：A2A协议的服务发现和注册机制详解

A2A 协议 是 AI Agent 技术体系中的重要组成部分。简单来说，它涉及到 Agent 如何在 工具使用与函数调用 层面实现智能化的行为和决策。在实际应用中，A2A 协议 的核心目标是让 Agent 能够更加高效、准确地完成特定任务。这需要我们深入理解其底层原理和实现机制。从学术角度来看，A2A 协议 的研究可以追溯到人工智能的早期阶段。早在 1950 年代，Alan Turing 就提出了

avatar 亚马逊云科技技术品牌专区