1. 从“工具”到“伙伴”：Agent设计范式的根本性转变

最近吴恩达教授关于Agent设计范式的演讲，在圈内引发了不小的讨论。很多人被“Agent > GPT5？”这个标题吸引，但我觉得更值得关注的是演讲中提炼出的四种具体设计模式。这不仅仅是技术上的迭代，更是一种思维方式的转变。过去几年，我们习惯了把大模型当作一个超级智能的“工具”——我们提问，它回答。但Agent的核心理念，是将其升级为一个能自主规划、执行、反思的“智能体”或“伙伴”。这意味着AI不再是被动响应，而是能主动理解你的意图，拆解复杂任务，调用各种工具（比如搜索、写代码、操作软件），并在这个过程中自我纠错。这种范式转移，对于开发者、产品经理乃至普通用户来说，都意味着全新的可能性和挑战。无论是想开发一个能自动处理邮件的个人助手，还是构建一个复杂的多智能体协作系统，理解这四种基础范式，都是构建可靠、高效Agent的起点。

2. 四种Agent设计范式深度解析

吴恩达教授总结的四种范式，可以看作构建Agent的四种基础“骨架”或“工作流”。它们并非互斥，在实际项目中常常组合使用，但理解其核心差异，能帮助我们在设计之初就做出更合适的选择。

2.1 反思式（Reflection）Agent：让AI拥有“三思而后行”的能力

这是最基础也最核心的一种范式。其核心思想是模仿人类的思考过程：先行动，再评估结果，根据评估进行修正。一个典型的反思式Agent工作流包含三个关键循环： 执行（Act）-> 观察（Observe）-> 反思（Reflect） 。

执行（Act） ：Agent根据当前的目标和状态，采取一个行动。这个行动可以是调用一个工具（如执行一段代码、进行一次网络搜索），也可以是生成一段文本（如回答一个问题、起草一封邮件）。

观察（Observe） ：行动会产生结果。Agent需要“观察”这个结果，获取环境反馈。例如，执行代码后是成功输出还是报错？搜索后返回了哪些信息？

反思（Reflect） ：这是“反思式”命名的由来，也是最体现智能的一步。Agent需要基于目标和观察到的结果，进行批判性思考：“我上一步做得对吗？结果是否符合预期？如果不符合，问题出在哪里？我下一步应该怎么做？” 这个过程通常由大模型驱动，通过精心设计的提示词（Prompt）来引导模型进行自我批评和计划修正。

实操要点与心得 ：

  • 反思提示词（Reflection Prompt）的设计是关键 。你不能简单地问“刚才错了吗？”，而要引导模型进行结构化分析。例如：“请基于我们最初的目标‘获取XX公司今日股价’，评估上一步‘搜索XX公司’返回的结果。1. 结果中是否包含股价信息？2. 股价信息是否是今日的？3. 如果不完全符合，缺失了什么信息？我们下一步应该调整搜索关键词还是尝试其他数据源？”
  • 设置反思深度和次数限制 。无限反思会导致效率低下甚至陷入死循环。通常我会设置一个最大反思迭代次数（比如3-5次），或者当模型判断“结果已足够好”时自动跳出循环。
  • 成本考量 ：每一次反思都是一次新的LLM API调用，这意味着更高的成本和延迟。在简单、确定性高的任务中，可能不需要复杂的反思机制。

注意 ：反思式Agent的强大之处在于其通用性和自我改进能力。但它对提示词工程的要求很高，且反思过程本身可能产生错误，形成“错误反思错误”的恶性循环。在实际开发中，需要结合具体任务设计可靠的反思触发条件和评估标准。

2.2 工具使用式（Tool Use）Agent：为AI装上“瑞士军刀”

如果说反思式Agent赋予了AI“思考”的能力，那么工具使用式Agent则赋予了AI“动手”的能力。其核心是让大模型学会在合适的时机，调用外部工具来扩展其能力边界。大模型本身不擅长精确计算、实时信息获取或操作特定软件，但它可以学会“描述”需要做什么，然后由专门的工具去执行。

一个标准的工具使用流程包括： 规划（Plan）-> 调用（Call）-> 整合（Integrate） 。

规划（Plan） ：模型分析用户请求，判断是否需要以及需要调用哪个工具。例如，用户问“今天纽约天气如何？”，模型会规划调用“天气查询API”。

调用（Call） ：模型按照工具定义的格式（通常是JSON Schema）生成规范的调用指令。例如，生成 {“action”: “get_weather”, “parameters”: {“location”: “New York”}} 。

整合（Integrate） ：工具执行完毕返回结果（如 {“temp”: 22, “condition”: “sunny”} ），模型需要将这个结果“消化”并整合到对话上下文中，生成面向用户的自然语言回复。

工具定义与链接实践 ： 工具的定义必须清晰、无歧义。我通常使用类似OpenAI的Function Calling格式来描述工具：

{
  "name": "get_stock_price",
  "description": "获取指定公司股票的最新价格。",
  "parameters": {
    "type": "object",
    "properties": {
      "company_symbol": {
        "type": "string",
        "description": "公司的股票代码，例如：AAPL, GOOGL"
      }
    },
    "required": ["company_symbol"]
  }
}

将这套工具描述通过系统提示词（System Prompt）提供给大模型，模型就能学会在对话中根据需要调用。现在流行的框架如LangChain、LlamaIndex以及Cursor的Agent模式，底层都封装了这套机制。

避坑指南 ：

  • 工具过多与冲突 ：当注册的工具很多时，模型可能难以选择或产生混淆。建议对工具进行清晰分类，并在提示词中说明各自的优先使用场景。
  • 工具输出的可靠性 ：模型严重依赖工具返回的结果。如果工具API不稳定、返回错误数据或格式异常，会直接导致Agent失败。必须对工具调用层做好异常处理和结果验证。
  • 幻觉调用 ：模型有时会“幻想”出一个不存在的工具并进行调用。需要在调用前有一层校验逻辑，确保调用的工具在已注册的列表内。

2.3 规划式（Planning）Agent：像项目经理一样分解任务

对于复杂任务，一步到位的执行或简单的迭代反思是不够的。规划式Agent的核心在于 任务分解（Task Decomposition）和子目标管理 。它像一个项目经理，接到一个大型项目（用户请求）后，不是立刻动手，而是先制定一个可行的计划，将大任务拆解为一系列有序的、可执行的小任务（子目标），然后逐个击破。

其工作流可以概括为： 理解总目标 -> 制定分步计划 -> 按序执行与监控 -> 汇总结果 。

例如，用户请求“帮我分析一下开源项目LangChain最近三个月的核心议题和发展趋势”。一个规划式Agent可能会制定如下计划：

  1. 子目标A：搜索并收集LangChain官方GitHub仓库最近三个月的Issue、Pull Request和Release Note。
  2. 子目标B：对收集的文本进行主题聚类和关键词提取。
  3. 子目标C：分析各主题的热度变化趋势（如讨论数量随时间变化）。
  4. 子目标D：根据以上分析，生成一份总结报告。

实现规划的关键技术 ：

  • Chain-of-Thought (CoT) 及其变种 ：通过“让我们一步步思考”这类提示，激发模型的推理和规划能力。更高级的如Tree of Thoughts (ToT) 允许模型在每一步考虑多种可能性，形成树状搜索空间，适合探索性任务。
  • ReAct范式 ：将推理（Reasoning）和行动（Action）结合起来，在每一步行动前都先进行一句简短推理（“我需要先搜索LangChain的GitHub地址”），这本质上是将规划和执行在微观层面结合了。
  • 外部规划器 ：对于极其复杂的任务，可以用一个专门的“规划器”模型（或模块）来制定计划，再由“执行器”模型（或Agent）去负责具体步骤。两者可以是大模型的不同实例，甚至是专精于不同任务的模型。

经验分享 ： 规划的质量直接决定最终结果。我发现，在提示词中要求模型以“第一步、第二步...”或“- [ ]”任务列表的形式输出计划，能显著提高计划的结构性和可执行性。同时，要为计划预留“缓冲”和“回滚”机制。某个子任务失败时，Agent应能评估是重试、跳过还是调整整个计划。

2.4 多智能体协作式（Multi-Agent Collaboration）：构建AI团队

这是最复杂、也最具想象力的一种范式。它不再是单个AI在战斗，而是由多个具备不同角色、专长和目标的Agent组成一个“团队”，通过协作、辩论、竞争甚至博弈来完成超复杂任务。这模拟了人类社会的组织方式。

在一个多Agent系统中，通常包含：

  • 管理者/协调者（Manager/Coordinator） ：负责接收总任务，分解并分配给其他Agent，协调它们的工作，解决冲突，汇总最终结果。
  • 专家Agent（Specialist Agent） ：每个专家负责一个特定领域。例如，一个团队里可以有“代码专家”、“文档专家”、“测试专家”、“沟通专家”。
  • 沟通机制 ：Agent之间如何“对话”？通常通过一个共享的工作区（如黑板模型Blackboard）或消息传递机制。它们可以互相提问、请求帮助、传递中间结果。

经典协作模式举例 ：

  • 辩论模式 ：针对一个开放性问题（如“哪种架构更适合我们的系统？”），让持有不同观点的Agent（如“微服务派Agent”和“单体架构派Agent”）进行多轮辩论，最终由管理者或用户根据辩论内容做出决策。这有助于全面评估方案的优缺点。
  • 流水线模式 ：像工厂流水线，每个Agent完成一道工序。例如，Agent A负责从网上爬取数据，Agent B负责清洗数据，Agent C负责分析并生成图表，Agent D负责将图表整合进报告。数据在Agent间顺序传递。
  • 招标-应标模式 ：管理者发布一个子任务（如“需要为这段代码编写单元测试”），多个具备相关能力的Agent可以“投标”，提交自己的执行计划和预估成本（如计算耗时），管理者选择最合适的Agent来执行。

开发挑战与选型建议 ： 构建多Agent系统复杂度陡增。你需要考虑：

  1. 通信开销 ：Agent间频繁通信会带来巨大延迟和API成本。
  2. 共识与冲突解决 ：当Agent意见不一致时，如何制定决策规则？
  3. 系统稳定性 ：一个Agent的失败不能导致整个系统崩溃。 对于初学者，不建议直接从零搭建。可以基于现有框架如 CrewAI 、 AutoGen （微软） 来开始实验。这些框架提供了角色定义、任务编排、通信流程等基础组件，能让你更关注Agent本身的能力设计，而非通信底层逻辑。

3. 从范式到实践：构建你的第一个Agent

理解了理论，我们来动手设计一个简单的、融合了多种范式的Agent。假设我们要构建一个“技术调研助手”，它能根据一个技术名词，自动搜索相关资料，整理核心观点，并生成一份摘要报告。

3.1 系统架构设计

我们的Agent将采用“规划式 + 工具使用式 + 反思式”的混合架构。

  1. 主控（Planner） ：负责任务规划和流程控制。它本身是一个大模型，接收用户查询（如“调研一下RAG技术在2024年的最新进展”）。
  2. 工具集 ：
    • web_search(query) : 调用搜索引擎API（如Serper API、Tavily）进行网络搜索。
    • read_webpage(url) : 读取并提取指定网页的正文内容。
    • summarize_text(text) : 对长文本进行摘要总结。
    • write_report(outline, points) : 根据提纲和要点，生成格式良好的Markdown报告。
  3. 反思模块 ：在关键节点（如搜索后、摘要后）评估结果质量，决定是否重试或调整策略。

3.2 核心工作流程与代码示意

以下是使用Python和LangChain框架的一个高度简化的逻辑示例：

# 伪代码/示意代码，展示核心逻辑
import os
from langchain.agents import initialize_agent, Tool
from langchain_openai import ChatOpenAI
from langchain.chains import LLMChain
from langchain.prompts import PromptTemplate

# 1. 定义工具函数
def web_search(query):
    # 调用搜索API，返回搜索结果列表（标题、链接、摘要）
    pass

def read_webpage(url):
    # 使用爬虫或Readability工具提取网页主要内容
    pass

def summarize_text(text):
    # 调用LLM进行摘要
    summary_prompt = PromptTemplate(...)
    chain = LLMChain(llm=llm, prompt=summary_prompt)
    return chain.run(text=text)

# 2. 将函数封装为LangChain Tool
tools = [
    Tool(name="Web Search", func=web_search, description="用于搜索网络最新信息。"),
    Tool(name="Read Webpage", func=read_webpage, description="读取并提取指定URL的网页内容。"),
    Tool(name="Summarizer", func=summarize_text, description="对长文本进行摘要。"),
]

# 3. 创建主控Agent（采用ReAct模式，结合了规划和工具使用）
llm = ChatOpenAI(model="gpt-4-turbo", temperature=0)
agent = initialize_agent(
    tools,
    llm,
    agent="react-docstore", # 使用ReAct代理类型
    verbose=True, # 打印详细思考过程，便于调试
    handle_parsing_errors=True # 处理解析错误
)

# 4. 设计系统提示词，注入规划与反思能力
system_prompt = """
你是一个技术调研专家。请按以下步骤执行用户请求：
1.  **规划**：理解请求，规划需要搜索的关键词和需要阅读的资料来源类型（如技术博客、官方文档、论文）。
2.  **执行与反思**：
    a. 使用`Web Search`工具进行搜索。
    b. **反思**：评估搜索结果的相关性和质量。如果前3条结果都不够好，调整关键词重新搜索。
    c. 对最相关的3-5个链接，使用`Read Webpage`工具获取内容。
    d. 对每个网页内容，使用`Summarizer`工具提取核心观点。
3.  **整合**：将所有核心观点去重、归类，形成一个报告提纲。
4.  **生成**：根据提纲，撰写一份结构清晰、包含引用的调研摘要报告。
请一步步思考，并在每一步行动前说明你的理由。
"""

# 5. 运行Agent
result = agent.run(system_prompt + "\n用户请求：调研一下RAG技术在2024年的最新进展。")
print(result)

3.3 关键参数与配置心得

  • LLM模型选择 ：主控Planner需要较强的推理和规划能力，建议使用GPT-4、Claude 3 Opus等顶级模型。工具调用（如摘要）对可靠性要求高，但任务相对简单，可以使用GPT-3.5-Turbo或Claude 3 Haiku以降低成本。
  • Temperature（温度参数） ：对于规划、反思等需要严谨推理的步骤，温度应设低（如0-0.2），以保证输出的稳定性和可靠性。对于最终报告生成，可以稍微调高（如0.7），让文字更有创造性。
  • 超时与重试 ：网络工具调用可能失败。必须为每个工具函数设置合理的超时时间和重试机制（如最多重试2次）。
  • Token限制与管理 ：整个流程涉及多次LLM调用和可能很长的上下文（网页内容）。需要精细管理上下文窗口，及时清理无关历史消息，对于长文本可以采用“Map-Reduce”式的摘要策略，先分段摘要再整体摘要。

4. 开发中的典型问题与实战排查技巧

在实际构建Agent时，你会遇到各种各样的问题。下面是我踩过坑后总结的一些常见问题及其排查思路。

4.1 Agent陷入循环或“发呆”

现象 ：Agent反复执行同一个操作，或者长时间不输出任何内容（“发呆”）。 原因与排查 ：

  1. 反思死循环 ：反思提示词设计有缺陷，导致Agent永远对自己的行动不满意，不断重复“执行->反思->执行同一操作”。 检查反思步骤的判断条件 ，确保有明确的“任务完成”或“结果满意”的退出标准。可以强制加入最大迭代次数限制。
  2. 工具调用失败但未处理 ：工具返回了错误或异常格式，但Agent没有相应的错误处理逻辑，导致状态卡住。 在所有工具函数中加入健壮的异常捕获和日志记录 ，确保即使失败也返回一个结构化的错误信息（如 {"error": "API timeout"} ），让Agent能“观察”到失败并触发反思或重试。
  3. Prompt指令模糊 ：给Agent的指令不够清晰，导致它“不知道下一步该干什么”。 优化你的系统提示词 ，使用更明确、更结构化的指令，例如“你必须先做X，再做Y，最后做Z”。

4.2 工具调用不准或“幻觉调用”

现象 ：Agent该用工具A时用了工具B，或者试图调用一个不存在的工具。 排查与解决 ：

  1. 工具描述（Description）不够精准 ：这是最常见的原因。工具的描述必须清晰、无歧义，并明确说明适用场景。对比以下两种描述：
    • 差的描述： “获取数据。”
    • 好的描述： “根据公司股票代码（如AAPL），从财经API获取该公司的最新股价、涨跌幅和交易量。输入必须是标准的股票代码。”
  2. 提供少量示例（Few-Shot） ：在系统提示词中，提供几个正确调用工具的对话示例，能极大提高模型调用工具的准确性。
  3. 后置校验 ：在Agent框架的执行层，加入一道校验程序。在真正执行工具调用前，检查模型生成的 action 和 action_input 是否与已注册的工具列表匹配，参数格式是否符合要求。如果不匹配，则拦截此次调用，并返回一个错误信息给模型，要求其重新决策。

4.3 效率低下与成本失控

现象 ：完成一个简单任务耗时很长，API调用费用惊人。 优化策略 ：

  1. 缓存（Caching） ：对于相同或相似的请求（如搜索相同关键词、读取同一URL），结果应该被缓存。可以使用简单的内存缓存（如 functools.lru_cache ）或外部缓存（Redis）。这能大幅减少重复的LLM调用和工具调用。
  2. 异步执行 ：如果多个子任务之间没有严格的先后依赖关系，应该让它们并行执行。例如，在读取多个网页内容时，可以使用 asyncio 库进行并发请求，而不是串行等待。
  3. 模型分级使用 ：不要所有步骤都用最贵、最强的模型。用大模型（GPT-4）做核心规划和复杂反思，用小模型（GPT-3.5-Turbo）或专用模型处理摘要、格式转换等简单任务。 “大模型当导演，小模型当员工” 是控制成本的黄金法则。
  4. 设置预算和熔断 ：为你的Agent服务设置每日/每月的API调用预算上限和频率限制。当接近限额时，触发降级策略（如换用更便宜的模型）或直接拒绝新任务。

4.4 结果质量不稳定

现象 ：同样的输入，多次运行的结果好坏参半。 应对方法 ：

  1. 确定性种子（Seed） ：如果使用的LLM API支持（如OpenAI的 seed 参数），可以设置一个固定的随机种子。这能在很大程度上保证，在模型版本、参数不变的情况下，对于相同的输入得到相同的输出，便于调试和复现。
  2. 自洽性检查（Self-Consistency） ：对于关键输出（如最终报告的核心结论），可以让Agent生成多次（例如3次），然后通过一个简单的投票机制或让另一个“评审”Agent来判断哪次输出的质量最高、最自洽。这虽然增加了成本，但能显著提升关键结果的可靠性。
  3. 人工反馈闭环（Human-in-the-Loop） ：在关键决策点引入人工确认。例如，Agent生成调研报告大纲后，可以先发给用户确认，用户点头后再继续执行详细的资料收集和撰写。这尤其适用于对准确性要求极高的生产环境。

构建一个健壮的Agent系统，调试和优化往往占据了大部分时间。我的体会是，从一个极其简单的、只做一件事的Agent开始，让它稳定运行起来，然后再像搭积木一样，逐步加入反思、规划、多工具等复杂能力，并在每一步都进行充分的测试和验证。不要试图一开始就设计一个万能Agent，那几乎注定会失败。

Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

国内知名的企业级Agent智能体厂商有哪些？2026中国AI智能体产业格局及落地选型深度拆解

avatar AI Agent技术社区
cover

给你的AI Agent装上“行为记忆“：agentmemory安装到整合全指南

avatar AI Agent技术社区

claude与其他agent的对比

Anthropic 的 Claude 在 AI Agent（智能体）领域被认为强于多数竞品，主要体现在，以及底层的。

avatar AI Agent技术社区