吴恩达 Agentic 四步法：从循环工程到图工程（全文翻译）

译注：本文依据吴恩达（Andrew Ng）在 DeepLearning.AI、Sequoia Capital AI Ascent 等公开场合的课程与演讲独立编译整理（2026 年 7 月），与吴恩达本人及其机构无关联，亦未获其背书。所有基准数据均引自吴恩达的公开分析，所有引语均出自其公开演讲与文章。以下为全文翻译。

图 1. 图接地的多智能体架构。用户将任务委托给架构师智能体（Architect Agent），后者通过类型化交接（typed handoffs）将任务移交给技术负责人智能体（Tech Lead Agent）与开发者智能体（Developer Agent）。每个阶段的环内反馈都会回传给用户。

摘要 —— 吴恩达证明：GPT-3.5 套上智能体工作流后，在 HumanEval 上得到 95.1% 的得分，超过了零样本（zero-shot）模式下得分 67.0% 的 GPT-4。架构比模型更重要。 吴恩达识别出四种设计模式——反思（Reflection）、工具调用（Tool Use）、规划（Planning）与多智能体协作（Multi-Agent Collaboration）。Anthropic 则独立形式化了五种生产级工作流。本文将这九种模式一并呈现并附实现代码，描绘它们如何从简单的循环组合成图架构，并给出从第一天到生产环境的分阶段构建路径。

索引词 —— Agentic AI、设计模式、反思、工具调用、规划、多智能体协作、工作流编排、图架构、LLM 智能体。

一、引言

要求 LLM 一次性生成有用的输出之所以困难，原因与要求一个人一气呵成写完一篇润色完毕的文章一样困难。吴恩达的类比刻意平常：人类作者会打草稿、重读、删除、查证来源、重组段落、请他人批评。而零样本的 LLM 通常被剥夺了所有这些机会。尽管有这一限制，现代模型的表现依然出色。智能体设计的核心主张并不是”直接提示没用”，而是：当模型被放进一个允许迭代、取证、任务分解与角色分离的工作流时，许多任务的可靠性会显著提升[1][2]。

这一结果不应被解读为普适排名。HumanEval 是一个编程基准，工作流的具体细节至关重要，这里的数字是按吴恩达报告的原样呈现，而非独立复现。即便加上这些限定，这个对比仍然揭示了一条实用的工程经验：一个带强流程的弱模型，可以胜过一个被要求一次性作答的强模型。

HumanEval 的例子让”架构论”变得具体。据吴恩达报告：GPT-3.5 零样本解决该基准 48.1% 的题目；GPT-4 零样本为 67.0%；当 GPT-3.5 被包裹进智能体工作流后，报告得分升至 95.1%[1]。因此，从 GPT-3.5 升级到 GPT-4 的提升，与迭代式工作流设计带来的提升相比，显得微不足道。

吴恩达这样总结其战略含义：“AI 智能体工作流将推动今年 AI 的巨大进步——甚至可能超过下一代基础模型。“[1] 这句话把注意力从模型选型转移到了系统设计上。

吴恩达的四种模式提供了初始词汇表：反思让模型检查并修订自己的工作；工具调用让它获取参数之外的信息；规划让它选择步骤；多智能体协作让多个实例贡献各自不同的能力。

本文的核心综合观点是：这些模式不是孤立的配方，而是认知外化的不同阶段。 循环外化了”修订”，链外化了”任务顺序”，网络外化了”角色分工”，图外化了”共享状态与关系”。一旦多个工作者必须跨会话保存事实、在不必复制完整对话记录的前提下协调、并能解释结果为何改变，系统需要的就不再只是提示词——它需要一个持久的信息层。

1.1 本文面向的读者

本文面向正在构建智能体系统、想要的是设计模式而非效忠于某个特定框架的工程师。它假设你熟悉 LLM 调用、结构化输出与基本 API 集成，但不假设你使用某个特定的编排库。目标读者可能在改进单个生产提示词、设计内部调研智能体，或在更大的软件流程中协调多个专业化工作者。

1.2 贡献

本综合文做出三项贡献。第一，在一篇面向实现的叙述中同时呈现吴恩达的四种设计模式与 Anthropic 的五种工作流模式。第二，描绘这些模式如何组合成循环、链、网络与图架构。第三，提供一个决策框架与分阶段构建路径，把评估、成本、延迟与可调试性当作一等约束而非事后补救。

二、四大设计模式

2.1 第一步：反思（Reflection）

反思是一个迭代过程：LLM 检查一份输出，将其与任务或评分标准（rubric）对照，识别缺陷，然后产出修订版。该模式可以用一个在”生成器”与”评审器”提示词之间交替的模型实例实现，也可以用两个角色分离的实例——一个负责产出、一个负责评估。重要属性不是模型对象的数量，而是存在显式的反馈回路与停止规则（stopping rule）。

在机制上，反思至少需要四类产物：任务、当前草稿、评审意见、修订决策。最小闭环是：生成一次 → 请求一次结构化评审 → 修订 → 重复，直到评审者判定结果合格或达到固定迭代上限。生产实现应当保存每一个中间产物，以便工程师检查失败究竟源于生成太弱、评估太弱，还是停止规则有误。

代码清单 1. 最小反思回路

@dataclass
class Critique:
    satisfactory: bool
    issues: list[str]
    revision_instructions: list[str]

def reflect(task: str, llm, max_iterations=3):
    draft = llm.generate(task)
    for _ in range(max_iterations):
        feedback = llm.evaluate(task=task, draft=draft)
        if feedback.satisfactory:
            return draft
        draft = llm.revise(task, draft, feedback)
    return draft

吴恩达的编程示例很直接：一个编码智能体写完代码后，收到一段相当于”这是为任务 X 写的代码，请仔细检查其正确性、风格与效率”的提示。评审者往往能发现初稿忽略的 bug、缺失的边界条件或糟糕的结构。随后无需更换底层模型即可修复草稿[3]。吴恩达报告说：“这些改进对我应用效果的提升令我惊喜”，并把反思称为”相当稳健的技术——我几乎总能把它们调好”[1]。

当输出质量可以依据显式标准评估时，反思最有用。代码可以对照测试与风格规则检查；报告可以对照必需章节、来源覆盖与禁止性论断检查；SQL 查询可以对照数据库模式与期望行数检查。当评审者并不比生成者拥有更好的信号时，该模式的可靠性会下降。

第一条实践提示：把评审与重写分开。 不要说”改进一下”然后接受一个不透明的替换结果。先请求一份结构化的问题清单，再把清单喂给一个独立的修订步骤。第二条提示：让评审者引用草稿、测试或源材料中的证据。第三条：为迭代设上限。没有上限，反思回路会一边消耗 token，一边做无助于任务成功的微小风格修改。

失败模式：(1) 自我确认——评审者重复了产生草稿的那套假设。角色分离有帮助，但不能保证独立。(2) 评分标准漂移——评审者奖励的是流畅度而非任务正确性。(3) 非单调修订——一个修改修复一个问题的同时引入另一个。控制手段：保持任务描述不可变，每次修订都与评分标准比对，先跑确定性检查再做主观评估，记录停止原因。

参考论文：Self-Refine [7]、Reflexion [8]、CRITIC [9]。

2.2 第二步：工具调用（Tool Use）

工具调用允许 LLM 选择并调用外部能力，如网络搜索、代码执行、计算器、数据库、文件操作或应用 API。模型贡献语言理解与决策；工具贡献接地的（grounded）真实数据或确定性的动作执行。这种分工把系统扩展到模型训练时记忆的内容之外，也扩展到自由文本所能可靠计算的范围之外。

吴恩达观察到，早期重要的工具调用工作来自计算机视觉社区，因为语言模型无法直接操作图像。“唯一的办法就是让 LLM 生成一个能够操作图像的函数调用——比如生成图像或做目标检测”[1]。如今同一架构已经支撑起广泛得多的动作空间。

代码清单 2. 带类型化工具的智能体

@dataclass
class ToolCall:
    name: str
    arguments: dict

tools = {
    "web_search": search_web,
    "run_code": execute_python,
    "query_db": database_query,
}

def agent_with_tools(task, llm, tools, max_steps=10):
    context = [task]
    for _ in range(max_steps):
        action = llm.choose_action(context, tools)
        if action.name == "finish":
            return llm.synthesize(context)
        result = tools[action.name](**action.arguments)
        context.append({"tool": action.name,
                        "result": result})
    return llm.synthesize(context)

能执行代码的模型可以验证自己的逻辑；能搜索的模型可以为论断找到事实依据；能访问数据库的模型可以给出精确答案而非统计意义上的近似。工具调用把 LLM 从一个会幻觉（hallucination）补全的封闭系统，变成一个能对照现实检查自身工作的开放系统。

失败模式：(1) 选错工具——需要数据库查询时却调用了搜索。(2) 参数非法——传入格式错误的输入。(3) 盲信工具输出——不校验结果。(4) 工具滥用——上下文已足够时仍然调用工具。控制手段：类型化的工具模式（tool schema）、参数校验、结果确认、权限边界。

参考论文：Toolformer [10]、HuggingGPT [11]。

2.3 第三步：规划（Planning）

规划使用 LLM 自主决定执行怎样的步骤序列来完成一个更大的任务。例如，被要求就某个主题做在线调研时，模型可能把目标拆成更小的子任务：调研具体子话题、综合发现、编写报告。

吴恩达描述过一次现场演示：他的调研智能体的网络搜索 API 返回了限流（rate-limiting）错误。“让我惊讶的是，智能体敏捷地转向了一个维基百科搜索工具——我都忘了自己给过它这个工具——然后用维基百科替代网络搜索完成了任务。这对我来说是一个 AI 智能体的’惊喜时刻’“[5]。吴恩达还提到把调研智能体用于自己的日常工作：“有一项研究我自己懒得去 Google——我就丢给调研智能体，几分钟后回来看看它做了什么。”

代码清单 3. 计划-执行智能体

def plan_and_execute(objective, llm, tools, budget):
    plan = llm.create_plan(objective)  # JSON 结构化步骤
    results = []
    for step in plan.steps:
        result = execute_step(step, tools, results)
        results.append(result)
        if result.failed:
            plan = llm.replan(objective, results,
                              remaining_budget=budget)
    return llm.synthesize(results)

吴恩达的成熟度评估很明确：“更前沿——有时它们的表现让我大开眼界，但至少在此时此刻，我没法保证总能可靠地跑通”[1]。实践含义是：规划智能体需要比反思回路更紧的约束：结构化的计划格式、依赖校验、有界的步骤数，以及兜底策略。

失败模式：(1) 过度规划——为简单任务生成庞大计划。(2) 计划-执行脱节——计划描述了智能体实际做不了的步骤。(3) 级联失败——一步出错污染所有后续步骤。(4) 无界重规划——无限重排计划而不收敛。控制手段：执行前校验依赖、跨重规划保留已完成的有效工作、限制总步数。

参考论文：HuggingGPT [11]、ChemCrow [12]。

2.4 第四步：多智能体协作（Multi-Agent Collaboration）

多智能体协作出多个 LLM 实例参与，各自被赋予不同角色的提示词，共同完成受益于专业化分工、独立交叉验证或并行覆盖的任务。

吴恩达的 ChatDev 例子：“完全开源，在我的笔记本上就能跑。“系统提示同一个 LLM 有时扮演软件工程公司的 CEO，有时是设计师，有时是产品经理，有时是测试工程师。“这群智能体会协作、进行扩展的对话——你告诉它’请开发一个围棋游戏’，它们真的会花几分钟写代码、测试、迭代，然后生成复杂得惊人的程序”[1]。

多智能体辩论——让不同智能体互相辩论——“确实也能带来更好的性能。让多个模拟的 AI 智能体协同工作，已被证明是一种强大的设计模式”[1]。

代码清单 4. 多智能体软件团队

agents = {
    "coder": Agent(role="senior software engineer"),
    "reviewer": Agent(role="expert code reviewer"),
    "tester": Agent(role="QA engineer"),
}

def multi_agent_build(spec, agents, max_rounds=3):
    code = agents["coder"].implement(spec)
    for _ in range(max_rounds):
        review = agents["reviewer"].critique(code)
        tests = agents["tester"].write_and_run(code)
        if review.approved and tests.passed:
            return {"code": code, "tests": tests}
        code = agents["coder"].revise(
            spec=spec, code=code,
            review=review, test_result=tests)
    return {"code": code, "status": "limit_reached"}

吴恩达称多智能体协作”更前沿”，但说它”效果比你想的好得多”。该模式可能因以下原因失败：冗余智能体（所有智能体看到同样的证据、优化同样的评分标准）、群体思维（groupthink）、对话过长、协调开销。智能体数量增多并不会自动带来更多智能。

实践提示是：为每一次交接（handoff）定义产物契约（artifact contract）。 调研者返回带来源的论断；规划者返回类型化步骤；编码者返回代码与假设；评估者返回缺陷与决策。智能体之间应通过产物与共享状态通信，而不是通过无限制的对话历史。这一约束也是在为图架构做准备。

参考论文：AutoGen [13]、ChatDev [14]。

三、Anthropic 的五种工作流模式

Anthropic 的《Building Effective Agents》区分了工作流（workflows，LLM 与工具通过预定义代码路径运行）与智能体（agents，模型动态指挥自己的过程）[4]。这个区分之所以有用，是因为它抵抗不必要的自主性。许多可靠系统可以由简单、可组合的工作流构建。只有当任务真正需要自适应时，才应引入动态智能体。

表 I. 模式成熟度评估（吴恩达）

3.1 提示链（Prompt Chaining）

提示链把一次 LLM 调用的输出按固定顺序送入下一次调用。每个阶段执行一个窄域转换，且可以在阶段之间插入程序化检查。适用于任务能”容易且干净地分解为固定子任务”的场景 [4]。优点：可预测，每个阶段可独立测试。缺点：对意外输入不灵活。

3.2 路由（Routing）

路由对输入进行分类，并将其送往专门的提示词、工具集、模型或工作流。一个客服系统可以把账单问题路由给账单智能体，把技术故障路由给诊断工作流。路由无需让智能体对话即可实现关注点分离。主要失败模式：误分类。控制手段包括置信度阈值与兜底路由。

3.3 并行化（Parallelization）

并行化同时运行多次 LLM 调用并聚合输出。两个变体：分片（sectioning，独立子任务分给多个工作者）与投票（voting，同一任务跑多次、由聚合器选最优）。分片降低延迟；投票提升稳健性。注意：同一个模型用几乎相同的提示词生成十份输出，并不等于十个独立判断。

3.4 编排者-工作者（Orchestrator-Workers）

编排者-工作者使用一个中央 LLM 分析任务、动态创建子任务、委派给工作者并综合输出。该模式组合了规划与多智能体协作。这一架构的强大之处在于自适应，但编排者可能成为上下文瓶颈。实际系统应要求工作者返回结构化产物而非原始对话。

3.5 评估器-优化器（Evaluator-Optimizer）

评估器-优化器把生成与评估分开。一个 LLM 产出响应；另一个对照显式标准评估它；生成者修订；循环持续直至达到阈值。这本质上就是反思模式以显式角色分离的形式被形式化为生产工作流。对翻译、代码、受政策约束的写作与结构化文档尤其有效。

表 II. 吴恩达模式与 Anthropic 工作流的映射

3.6 先选工作流，再上智能体

生产默认应当是能满足任务的最简单模式。简单提问用直接 LLM 调用；步骤固定用链；请求属于清晰类别用路由；独立覆盖重要时用并行工作者；分解方式需要现场发现时用编排者；质量可判定且可迭代改进时用评估器-优化器。

这个顺序不是为保守而保守。每上一级都会增加成本、延迟、非确定性与失败模式。 当复杂度是针对观察到的错误而增加时，智能体设计才有效；而不是从一开始就把每一种可用模式都堆上去。

四、从循环到图

把两套模式词汇合在一起，可以描述状态、控制与职责组织方式的一种递进。这个递进不是每个项目都必须爬完的成熟度阶梯。许多任务就应该停留在直接调用或固定链上。

4.1 循环阶段

循环阶段包含一个反复检查并修订自身工作的智能体。反思是其核心机制，常由工具辅助。循环紧凑、易于原型验证，对装得进单个上下文窗口（context window）的任务很有效。当任务包含太多证据、太多独立关注点或太多历史时，循环就会失效——每次迭代都可能重发任务、草稿、评审、工具结果与历史决策。上下文变得昂贵而嘈杂。

4.2 链阶段

链阶段把工作拆分为固定顺序的专业化转换。它把”顺序”外化到应用代码中。每个阶段可以有自己的提示词、模型、工具与校验。与反思回路相比，链更可预测，因为路径是已知的。局限在于必须预想到意外情况。

4.3 网络阶段

网络阶段引入多个角色专业化的工作者。编排者委派、工作者执行、结果回传综合。核心限制是上下文管理。正如 Anthropic 指出的：“当上下文复杂到单个智能体无法有效管理时，就会造成性能瓶颈，智能体难以维持一致性”[4]。编排者可能沦为接收每个工作者完整输出的”对话枢纽”。

4.4 图阶段

图阶段把共享状态外化为一个持久、可查询的结构。每个工作者只读取与其任务相关的子图，并把新的实体与关系写回。编排者的上下文保持精简；共享状态活在图里，任何智能体在任何时间都可以查询。

知识图谱以三种不同的角色服务于多智能体系统：

• 作为编排者-工作者的共享记忆：工作者直接对图读写；编排者的窗口保持干净。这是 Anthropic”会话不等于上下文窗口”原则的多智能体对应物。
• 作为评估器-优化器的事实锚定层（grounding layer）：评估者对照带显式溯源（provenance）的图谱边来核查论断，让判断锚定在被抽取的事实而非模型的估计上。反馈从”这看起来不太对”变成”三元组（X, 任职于, Y）在图中不存在”。
• 作为循环的持久世界模型：图在上下文窗口的冲刷中幸存，就像状态文件在进程重启后幸存一样。智能体会遗忘；图不会。

4.5 最小图模式（Schema）

一个有用的模式可以从五类节点起步：实体（Entity，人物、组织、产品、概念）、论断（Claim，可能被支持或反驳的陈述）、来源（Source，文档、API 响应、测试结果）、产物（Artifact，计划、草稿、代码、报告）、运行记录（Run，执行记录）。边刻画关系：提及（mentions）、支持（supports）、反驳（contradicts）、派生自（derived_from）、取代（supersedes）。每条论断保留溯源。每次修订指向前一版本。

最小写操作应当是增量式的。与其静默覆盖一条论断，不如创建新版本并用 supersedes 链接它。与其删除矛盾证据，不如保留两条论断并附上一份评估。这种设计让长期运行的系统可审计。

4.6 图架构不等于自动正确

图保存错误与保存事实一样高效。实体对齐（entity resolution）可能把不同的组织合并成一个。抽取可能挂错日期。一个过度自信的评估者可能把弱来源标记为充分。因此图接地的系统需要数据质量机制：模式校验、规范化标识符、溯源、冲突显式表示、置信度校准，以及周期性审查。

五、实践实施指南

推荐的构建路径从最小的可靠循环起步，每次只增加一种能力。每个阶段都应有基线、任务级指标、成本预算与回滚路径。

5.1 从反思开始 —— 第 1 天

选一个输出可以被评估的现有 LLM 调用。增加第二个调用，对照显式评分标准评审第一份输出。把评审喂给一次修订调用。把修订后的输出与基线对比。预期改进：质量提升 10–30%，但团队应当度量自己的提升幅度。

代码清单 5. 生产级反思记录

{
  "task_id": "case-017",
  "draft_version": 1,
  "rubric_version": "support-v3",
  "issues": [
    { "type": "missing_evidence", "severity": "high" },
    { "type": "tone", "severity": "low" }
  ],
  "decision": "revise",
  "iteration": 1,
  "max_iterations": 3
}

5.2 增加工具调用 —— 第 2 天

给智能体至少一个工具的访问权：代码执行或网络搜索。让智能体自己决定何时使用。在纳入工具结果前先校验。留意吴恩达描述的”绕过故障改走他路”的时刻。

5.3 构建规划智能体 —— 第 1 周

对复杂任务，先让 LLM 以结构化 JSON 写出计划再执行。逐步执行、收集结果。若某步失败，带着”哪些已经成功”的上下文重规划。跨重规划保留已完成的有效工作。

5.4 上多智能体 —— 第 2 周

把任务拆成角色：至少”生成者 + 评审者”。使用同一个模型、不同的系统提示词。迭代直到评审者满意或达到迭代上限。为每次交接定义产物契约。

5.5 接入图 —— 第 1 个月

在智能体运行之间加入持久状态。从简单开始：共享 JSON 文件或数据库。当智能体需要跨会话串联事实时，再升级为知识图谱。加入溯源跟踪与版本历史。

表 III. 实施时间线

六、基准证据

HumanEval 数据是”架构重于模型”论点的核心证据：

表 IV. HumanEval 编程基准（吴恩达报告）

关键洞察：“从 GPT-3.5 到 GPT-4 的提升，与引入迭代式智能体工作流相比显得微不足道”[1]。这意味着：投资工作流架构，而不只是升级模型。 吴恩达：“如果你期待把你的应用跑在 GPT-5 零样本上，在某些应用中，用更早的模型加上智能体推理，可能就能接近那个性能水平。”

吴恩达强调的另一个洞察：快速 token 生成对智能体工作流很重要，因为 LLM 生成的 token 是给其他 LLM 读的，不是给人读的。“能以远超任何人类阅读速度的速度生成 token 太棒了。“即使质量略低的模型，只要出 token 快，“相比更好的模型出慢 token，可能给出不错的结果——因为它让你能在这个循环里多跑很多圈”[1]。这使得快速推理（优化的推理服务、量化模型）成为智能体系统性能的直接乘数。

七、决策框架

表 V. 何时使用哪种模式

经验法则：如果当前模式的失败模式已被理解、且下一个模式正好解决这个具体失败，就加它。如果失败模式还不清楚，先度量再增加复杂度。每种模式都会增加成本、延迟与调试面。能满足任务的最便宜模式通常就是对的那个。

八、局限

三点局限值得直说。第一，吴恩达本人把规划与多智能体称为”前沿”——它们并不总是好用。“至少在此时此刻，我没法保证总能可靠地跑通”[1]。第二，智能体工作流用延迟换质量。吴恩达：“我们需要学会把任务委派给 AI 智能体，然后耐心等待几分钟、甚至几小时的响应。就像一个新手经理把事情派给某个人、五分钟后就去催——那是没有生产力的。“[1] 第三，每次循环迭代都要花 token。智能体数量增多并不会自动带来更多智能。如果所有智能体看到同样的证据、优化同一个弱评分标准，系统只会用更高的成本把同一个错误重复多遍。

此外，HumanEval 是一个编程基准。95.1% 这个数字不应被假定可直接迁移到所有领域。团队应当构建自己的评估集，并在自己的具体场景中度量提升。

九、结论

吴恩达的四个模式是词汇，Anthropic 的五种工作流是语法，图是语言。 最重要的单点结论：工作流架构比模型能力更重要。GPT-3.5 加智能体工作流（95.1%）胜过零样本模式下的 GPT-4（67.0%）。

构建路径是增量的。从反思开始——它今天就能可靠地工作，适用于大多数质量可评估的任务。加工具，把答案锚定到真实数据。为复杂任务构建规划智能体。当专业化带来可度量的信号时上多智能体。当状态必须跨会话持久、智能体必须共享世界模型时接入图。

模式的分层复合效应才是真正性能所在。 每种模式解决上一阶段的一个特定局限：反思解决单次生成的错误，工具解决知识缺口，规划解决复杂度，多智能体解决视角局限，图解决记忆局限。这个递进不是强制性的，但它是有方向的。

吴恩达的最后观察道出了更广泛的意义：“通往 AGI 的路更像一场旅程而不是一个终点，而这类智能体工作流，能帮助我们在非常漫长的旅途中向前迈出一小步。“[1]

致谢与来源

本文档是一份为学习而独立汇编的综合整理。它与吴恩达、DeepLearning.AI、Anthropic 或文中提及的任何其他组织均无关联、亦未获其背书。所有基准数字来自吴恩达已发表的分析。所有引语均出自其公开演讲与文章。

参考文献

[1] A. Ng, “What’s Next for AI Agentic Workflows,” Sequoia Capital AI Ascent, Mar. 2024.

[2] A. Ng, “Four AI Agent Strategies That Improve GPT-4 and GPT-3.5 Performance,” The Batch, DeepLearning.AI, Mar. 2024.

[3] A. Ng, “Agentic Design Patterns Part 2: Reflection,” The Batch, Apr. 2024.

[4] E. Schluntz and B. Zhang, “Building Effective Agents,” Anthropic Engineering, Dec. 2024.

[5] A. Ng, “Agentic Design Patterns Part 4: Planning,” The Batch, Apr. 2024.

[6] A. Ng, “Agentic AI,” DeepLearning.AI course, Oct. 2025.

[7] A. Madaan et al., “Self-Refine: Iterative Refinement with Self-Feedback,” 2023.

[8] N. Shinn et al., “Reflexion: Language Agents with Verbal Reinforcement Learning,” 2023.

[9] Z. Gou et al., “CRITIC: LLMs Can Self-Correct with Tool-Interactive Critiquing,” 2024.

[10] T. Schick et al., “Toolformer: Language Models Can Teach Themselves to Use Tools,” 2023.

[11] Y. Shen et al., “HuggingGPT: Solving AI Tasks with ChatGPT and Friends,” 2023.

[12] A. M. Bran et al., “ChemCrow: Augmenting LLMs with Chemistry Tools,” 2023.

[13] Q. Wu et al., “AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation,” 2023.

[14] C. Qian et al., “ChatDev: Communicative Agents for Software Development,” 2024.

附录

表 VI. 本文术语表

A. 反思

触发条件：首次输出常常不完整或不正确，且质量可以依据显式标准评估。最小架构：生成器、评估器、修订回路、停止规则。最佳首个指标：同一任务集相对无反思的改进幅度。暂不要加：多个评审者——除非已证明单个评审者确实漏掉某类独特错误。

B. 工具调用

触发条件：模型缺少当前的、私有的、精确的或可执行的信息。最小架构：类型化工具模式、参数校验、结果确认、权限边界。最佳首个指标：目标错误类别（幻觉、过时、不精确）的减少。暂不要加：写权限——在只读行为尚不可靠之前。

C. 规划

触发条件：任务路径多变，无法经济地编码为固定链。最小架构：结构化计划格式、依赖校验、有界执行、重规划策略。最佳首个指标：固定链失败案例上的任务完成率。暂不要加：没有预算或步数上限的开放式重规划。

D. 多智能体协作

触发条件：专业化、独立评审或并行覆盖相对单智能体带来可度量的信号。最小架构：差异化角色、产物契约、编排者或聚合器。最佳首个指标：可比成本下相对单智能体工作流的质量增益。暂不要加：提示词与证据实质相同的智能体。

E. 图架构

触发条件：状态必须跨会话持久、关系很重要、且对话重放已不再现实。最小架构：稳定标识符、带版本的产物、类型化边、溯源、有界查询。最佳首个指标：相关状态的正确检索，以及最终论断到源材料的可追溯性。暂不要加：复杂本体——在真实查询确立所需模式之前。

生产检查清单

• 任务定义：目标以稳定的语言写就。成功标准可观察。禁止的动作与数据边界显式声明。成本与延迟预算已定义。
• 模型与提示词：模型与提示词版本被记录。每个角色的职责窄域。结构化输出模式经过校验。系统可以返回不确定性或升级（escalation）。
• 工具：工具名称与描述无歧义。参数类型化并校验。读写权限分离。副作用从工具响应确认。重试有界且幂等。
• 规划：计划包含标识符与依赖。检测环与被阻塞的步骤。已完成的有效工作在重规划中幸存。失败类别决定重试、重规划或停止。
• 多智能体协调：每次交接都是一份产物。工作者返回证据与不确定性。编排者接收有界的摘要。除非评估显示有价值，否则移除冗余角色。
• 图与记忆：论断保留来源溯源。版本使用显式取代（supersession）。冲突被显式表示而非被覆盖。实体对齐决策可检查。访问控制作用于图查询与写入。
• 评估：组件级、工作流级与运营级指标都被跟踪。尽可能优先使用确定性检查。模型评估者使用显式评分标准。高风险或模糊场景可转人工评审。提示词或模型变更上线前先做回归测试。

一个可靠的智能体系统应当让下面这句话为真：

每一个重要输出，都可以追溯到一个任务、一份计划、一个产物、一个来源、一个评估决策，以及一条有界的执行记录。

当这句话为假时，更多自主性通常只会增加不确定性。当它为真时，循环、工具、计划、工作者与图就成为可组合的工程机制，而不是不可解释的行为。从循环到图的路径，不是从简单到复杂的路径。它是从隐式状态到显式状态、从易失内存到持久内存、从估计到证据的路径。