青蛙小白

Agentic System Patterns（智能体设计模式）

本文整理自 Anthropic 2024 年 12 月发布的工程实践文章《Building Effective Agents》，系统介绍了他们在与数十个企业团队合作时总结出的 Agent 系统设计框架。核心结论是：成功的实现往往使用简单、可组合的模式，而非复杂框架。

Workflow vs. Agent 的关键区分

Anthropic 将所有 Agent 系统归类为 Agentic Systems（智能体系统），其中最重要的架构区分是：

类型定义特点
Workflow（工作流）LLM 和工具通过预定义代码路径编排可预测、一致、适合定义明确的任务
Agent（智能体）LLM 动态指导自身的流程和工具使用，自主掌控完成方式灵活、适合需要模型级决策的开放任务

对于大多数应用，优化单次 LLM 调用（加检索和 in-context 示例） 已经足够。只有在确认更高复杂度能带来可测量的性能提升时，才应该引入 Agentic System。

基础构件：增强型 LLM

AI Agent（智能体）系统的基础构件是 Augmented LLM（增强型 LLM）：在 LLM 之上叠加检索（Retrieval）、工具调用（Tools）和记忆（Memory）三种能力。

现代模型能主动使用这些能力——自己生成搜索 query、选择合适工具、决定保留哪些信息。Model Context Protocol（模型上下文协议）是实现这些增强的标准化接入方式之一。

flowchart LR
    In((In)) --> LLM[LLM]
    LLM --> Out((Out))
    LLM <-.->|"Query / Results"| Ret[Retrieval]
    LLM <-.->|"Call / Response"| Tools[Tools]
    LLM <-.->|"Read / Write"| Mem[Memory]

五种工作流模式

1. Prompt Chaining（提示链）

将任务分解为顺序步骤，每次 LLM 调用处理上一步的输出。中间可加"gate"（程序检查点）确认流程正常推进。

适用场景： 任务可以清晰分解为固定子任务；追求以延迟换精度（每次 LLM 调用做更简单的子任务）。

典型用例：

  • 先生成营销文案，再翻译成目标语言
  • 先写文档提纲，检查提纲达标后，再按提纲写全文

详见：Prompt Chaining（提示链）

2. Routing（路由）

对输入进行分类，再导向对应的专属子流程。实现关注点分离，让各类输入得到专门处理。

适用场景： 存在几类截然不同的输入类型，且分类可由 LLM 或传统分类器可靠完成。

典型用例：

  • 客服系统：把普通咨询、退款请求、技术支持分别路由到不同处理流程
  • 模型路由：简单/常见问题走 Haiku，复杂/罕见问题走 Sonnet，优化性价比
flowchart LR
    In((In)) --> R[LLM Router]
    R --> C1[LLM Call 1]
    R -.-> C2[LLM Call 2]
    R -.-> C3[LLM Call 3]
    C1 --> Out((Out))
    C2 -.-> Out
    C3 -.-> Out

3. Parallelization（并行化）

同时执行多个 LLM 调用，结果由程序汇总。分两种变体：

  • Sectioning（分块）：将任务拆成可并行的独立子任务同时执行
  • Voting（投票）：同一任务运行多次，获取多样输出以提升置信度

典型用例（Sectioning）：

  • 安全护栏：一个 LLM 处理用户请求，另一个同步检测不当内容，比同一个 LLM 兼顾两项性能更好
  • 自动化评估：每个 LLM 调用评估模型输出的不同维度

典型用例（Voting）：

  • 代码漏洞扫描：多个 prompt 分别审查代码，有任意一个发现问题就标记
  • 内容审核：多个 prompt 评估不同维度，通过可调投票阈值平衡假阳性和假阴性
flowchart LR
    In((In)) --> C1[LLM Call 1]
    In --> C2[LLM Call 2]
    In --> C3[LLM Call 3]
    C1 --> Agg[Aggregator]
    C2 --> Agg
    C3 --> Agg
    Agg --> Out((Out))

OpenAI Cookbook 的 Parallel Agents with the OpenAI Agents SDK 是这一模式在 Agents SDK 里的具体示例：多个 specialist agent 并行分析同一输入，再由 MetaAgent 汇总。它可以用应用代码里的 asyncio.gather 实现，也可以把 specialist agent 暴露成 tools，让 manager/meta-agent 通过并行工具调用动态选择。

4. Orchestrator-Workers（编排者-执行者）

一个中心 LLM（编排者）动态分解任务，委派给工作者 LLM 执行，最后汇总结果。与 Plan-and-Execute（规划与执行）的关键区别是灵活性——子任务不是预定义的，由编排者根据具体输入动态决定。

适用场景： 无法预知需要哪些子任务（如复杂代码修改，涉及哪些文件和改动取决于任务本身）。

典型用例：

  • 编程产品：每次任务动态决定需要修改哪些文件、做什么改动
  • 多源搜索：从多个来源收集并分析信息，相关性和数量事先未知

Codex 的子智能体是这一模式的产品化实现：主智能体按用户的显式要求启动 Explorer、Worker 或自定义角色，等待各线程完成后汇总结论。对预先列出的多个独立检查点，它也同时表现为 Parallelization；两种模式的区别在于子任务是主智能体动态拆分，还是用户预先给定。

flowchart LR
    In((In)) --> Orch[Orchestrator]
    Orch -.-> C1[LLM Call 1]
    Orch -.-> C2[LLM Call 2]
    Orch -.-> C3[LLM Call 3]
    C1 -.-> Syn[Synthesizer]
    C2 -.-> Syn
    C3 -.-> Syn
    Syn --> Out((Out))

5. Evaluator-Optimizer（评估器-优化器）

一个 LLM 生成响应，另一个 LLM 提供评估和反馈，两者在循环中迭代。

适用场景： 有清晰的评估标准，且迭代提升有可衡量的价值。判断两个标志：一是 LLM 的响应在人给出反馈后能被明显改进；二是 LLM 自身能提供这样的反馈。

与 Reflexion（反思）的区别：Reflexion 是同一模型自我反思；Evaluator-Optimizer 是两个独立角色，评估者 LLM 不依赖于生成者 LLM 的视角。

典型用例：

  • 文学翻译：翻译 LLM 可能未捕获的细微差别，由评估 LLM 提供有效批评
  • 复杂搜索：评估者决定是否需要更多轮搜索

详见：Evaluator-Optimizer（评估器-优化器）

完全自主 Agent

当以上工作流模式也无法应对时，才引入完全自主 Agent。Agent 适用于开放性问题：难以或不可能预测需要多少步骤，无法硬编码固定路径。

Agent 通常就是在环境反馈循环中使用工具的 LLM（即 Agent Loop（智能体循环））。其自主性意味着：

  • 更高成本
  • 错误复合的潜力（单步 90% 准确率 × 20 步 = 整体约 12%）
  • 需要在沙箱环境中大量测试，配合适当的防护机制

典型用例：

  • 解决 SWE-bench 任务的编程 Agent（需修改多个文件，改动由任务描述驱动）
  • Computer Use（例如 Computer-Using Agent通过屏幕、鼠标和键盘完成任务）
flowchart LR
    Human((Human)) <-.-> LLM[LLM Call]
    LLM -->|Action| Env((Environment))
    Env -->|Feedback| LLM
    LLM -.-> Stop[Stop]

sequenceDiagram
    participant H as Human
    participant I as Interface
    participant L as LLM
    participant E as Environment
    H->>I: Query
    loop Until tasks clear
        I->>L: Clarify
        L->>I: Refine
    end
    I->>L: Send context
    L->>E: Search files
    E->>L: Return paths
    loop Until tests pass
        L->>E: Write code
        E->>L: Status
        L->>E: Run tests
        E->>L: Results
    end
    L->>I: Complete
    I->>H: Display

OpenAI guide 的编排视角

OpenAI 的《A practical guide to building agents》给出一个更产品化的拆分：先尽量做强单 Agent + 清晰工具 + 清晰指令，只有当复杂条件分支或相似工具过载导致模型持续选错时，再拆成多 Agent。这里的判断标准不是工具数量本身，而是工具之间是否相似、prompt 是否已经难以维护、错误是否能通过更好的工具命名和参数描述解决。

OpenAI Agents SDK则把这个编排视角落成 SDK 原语：Agent、tool、handoff、guardrail 和 trace。它不是新增一种设计模式，而是把下面几类模式统一成可组合的工程接口。

单 Agent 优先

单 Agent 系统用一个模型控制工作流，逐步增加工具、指令和护栏。优点是评估、调试、维护更简单；缺点是在逻辑分支太多或工具语义重叠时，模型选择动作的负担会变重。

Manager pattern（Agents as tools）

OpenAI guide 中的 Manager pattern 与上文的 Orchestrator-Workers 很接近：中心管理者 Agent 保持用户交互和上下文控制，把专门任务作为工具调用分派给领域 Agent，再综合结果。适合需要统一用户体验、统一汇总答案、且不希望多个 Agent 轮流接管对话的场景。

flowchart LR
    U[用户：请求翻译成西班牙语、法语、意大利语] --> M[管理者 Agent]

    M <-->|分派任务 / 返回结果| ES[任务：西班牙语翻译
专门 Agent：西班牙语]
    M <-->|分派任务 / 返回结果| FR[任务：法语翻译
专门 Agent：法语]
    M <-->|分派任务 / 返回结果| IT[任务：意大利语翻译
专门 Agent：意大利语]

    M --> U

Decentralized handoff（去中心化交接）

去中心化 handoff 模式让多个 Agent 处于相对平等的位置，一个 Agent 可以把工作流控制权交给另一个专门 Agent，并把当前对话状态一并转移。它适合客服分诊、订单/销售/维修等专业域明确、且被交接的 Agent 可以独立完成后续对话的场景。

flowchart LR
    U[用户：我的订单在哪？] --> T[分诊]
    T -.-> I[问题与维修]
    T -.-> S[销售]
    T -.-> O[订单]
    O --> R[订单：在路上了！]

Manager pattern 和 handoff 的核心差别是控制权：前者由管理者持续掌控和综合，后者把控制权转移给更合适的 Agent。二者都需要 Agent Guardrails（Agent 护栏）和清晰的 Agent-Computer Interface（智能体计算机接口），否则多 Agent 只会把错误路由和工具误用放大。

三条核心原则

Anthropic 在实现 Agent 时遵循的核心原则：

  1. 保持简单（Maintain Simplicity）：避免为了复杂而复杂，能用简单方案解决的不引入 Agent
  2. 展示规划步骤（Prioritize Transparency）：显式呈现 Agent 的规划过程，让结果可解释
  3. 精心打磨 ACI（Carefully craft the ACI）：Agent-Computer Interface（智能体计算机接口）的质量与 prompt 本身同等重要，花在工具文档和测试上的时间应与花在总体 prompt 上一样多

生产案例：Anthropic 多智能体研究系统

Anthropic 将 Orchestrator-Workers 模式落地为其内部研究 Agent 系统。关键工程发现：

  • Token 用量是核心变量：Token 使用量单独解释了 80% 的性能方差——多 Agent 的优势本质上是在任务上投入了更多计算，约为普通对话的 15×
  • 最后一里往往是最长一里：从原型到生产的工程量远超预期，生产级 Agent 系统需要 checkpoint、彩虹部署、全链路追踪等基础设施
  • 八条 Agent 提示工程原则：从广到窄的搜索策略、按复杂度嵌入工具调用数量规则、让 Agent 参与自我诊断等（详见多智能体研究系统词条）

关于框架的建议

文章明确建议：先直接使用 LLM API，不要过早引入框架。很多模式用几行代码就能实现。如果使用框架，必须理解它底层做了什么——错误假设"框架做了什么"是常见错误来源。

相关概念

参考来源
  1. 1. https://www.anthropic.com/engineering/building-effective-agents
  2. 2. https://www.anthropic.com/engineering/multi-agent-research-system
  3. 3. https://developers.openai.com/codex/subagents
  4. 4. https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
  5. 5. https://openai.com/index/new-tools-for-building-agents/
  6. 6. https://developers.openai.com/cookbook/examples/agents_sdk/parallel_agents
评论