[!info] related notes

• 相关主题:
• 相关 MOC:
• 相关 howto:

Building Effective Agents

这是什么

Anthropic 于 2024-12-19 发布的 Agent 工程方法论文章。它不是某个 Agent SDK 的教程，而是在回答一个更基础的问题：什么时候应该使用 Agentic System，以及复杂度应该增加到什么程度。

文章来自 Anthropic 与大量客户共同构建 Agent 的经验。核心观察是：生产中成功的系统往往依赖简单、可组合、可验证的模式，而不是尽可能复杂的 Agent 框架。

2026 年回看时要注意：Anthropic 已在原文顶部注明，2024 年描述的 tooling landscape 已发生明显变化，并指向 Managed Agents 等后续架构。但文章关于复杂度、Workflow / Agent 边界、Ground Truth 和 ACI 的设计原则仍然成立。

核心结论

整篇文章可以压缩成一句话：

从最简单的方案开始，只有当评估能够证明复杂结构确实改善结果时，才增加 Agentic Complexity。

推荐的复杂度阶梯可以理解为：

Single LLM Call
      ↓
Augmented LLM
      ↓
Prompt Chaining
      ↓
Routing
      ↓
Parallelization
      ↓
Orchestrator-Workers
      ↓
Evaluator-Optimizer
      ↓
Autonomous Agent

这不是“能力等级排行榜”。越往下通常意味着更高的灵活性，同时也意味着更高的 latency、token cost、调试成本和错误累积风险。

因此正确的问题不是：

能不能把它做成 Agent？

而是：

现有更简单的结构是否已经无法满足任务，并且更复杂结构是否在 eval 中提供了可测量收益？

Workflow 与 Agent 的关键区别

Anthropic 把更大的范畴称为 Agentic Systems，并区分两类控制流：

• Workflow：LLM 和工具如何流转由代码预先定义。
• Agent：LLM 根据目标、环境反馈和工具结果动态决定下一步行动。

真正的区别不是“用了几个模型”或“有没有子 Agent”，而是：

下一步控制权主要掌握在代码里，还是模型里？

因此，多 Agent 系统也可能只是确定性 Workflow；单个模型只要持续根据环境反馈自主选择下一步，也可以构成 Agent。

基础构件：Augmented LLM

Augmented LLM 是整套体系的基础：

LLM
├── Retrieval
├── Tools
└── Memory

重点并不是“能力接得越多越好”，而是这些能力是否：

• 与当前用例匹配；
• 能被模型稳定理解和调用；
• 有清晰、易用、充分说明的接口。

这也直接引向后面的 ACI 与 面向 Agent 的工具设计。

五种常见 Workflow

完整关系见 Agentic Workflow Patterns。

1. Prompt Chaining

Prompt Chaining 将任务拆成固定串行步骤：

LLM A → Gate → LLM B → Gate → LLM C

适合可以自然拆成稳定子任务的场景。它本质上用更高 latency 换取更低的单步任务难度和更高准确率。

2. Routing

LLM Task Routing 先识别输入类型，再交给专门路径处理：

Input → Classifier → Route A / Route B / Route C

适用于存在明显任务类别，而且分类本身足够可靠的系统。模型路由也属于这种模式，例如简单问题用便宜模型、复杂问题升级到更强模型。

3. Parallelization

LLM Parallelization 有两个不同目的：

• Sectioning：拆成独立子任务并行处理，用于提速或让每个调用专注单一维度。
• Voting：对同一任务做多次独立判断，通过多视角或投票提高置信度。

例如代码审查可以并行检查 security、architecture、performance；高风险分类也可以让多个独立 reviewer 给出判断。

4. Orchestrator-Workers

Orchestrator-Workers 的关键不是“有 manager 和 worker”，而是子任务无法事先写死：

Task
 ↓
Orchestrator
 ├→ Worker A
 ├→ Worker B
 └→ Worker C
 ↓
Synthesis

它特别适合 coding 与复杂 research，因为每次任务需要修改哪些文件、查哪些来源、产生多少子任务，都可能不同。

它与普通 Parallelization 的核心区别是：

Parallelization 的子任务通常预先知道；Orchestrator-Workers 的子任务由 orchestrator 根据当前输入动态决定。

5. Evaluator-Optimizer

Evaluator-Optimizer 形成生成—评价—修正循环：

Generator → Candidate → Evaluator → Feedback
    ↑                                ↓
    └──────────── Repair ────────────┘

适合两个条件同时成立的任务：

1. 有相对明确的评价标准；
2. evaluator 提出的反馈能够让下一轮结果可测量地变好。

如果 reviewer 只能重复“继续优化”，而无法指出具体差距，这种循环通常只是在增加 token 和 latency。

Autonomous Agent：最后才增加的复杂度

真正的 Agent 更像：

Goal
 ↓
Reason / Plan
 ↓
Action / Tool
 ↓
Environment Result
 ↓
Observe
 ↓
Replan
 ↓
...

适合难以提前预测步骤数量和固定路径的开放式任务。

Agent 的实现本身未必复杂，常常只是：

LLM + Tools + Environment Feedback + Loop

困难主要发生在 loop 周围的工程约束，而不是 while 循环本身。

Ground Truth Feedback 是 Agent 可靠性的核心

Agent 执行过程中必须持续从环境获得真实反馈，详见 Agent 中的 Ground Truth Feedback。

对于 Coding Agent：

“我已经修改完成”
≠ Ground Truth

Git Diff / Test Result / Build Result / Runtime State
= Ground Truth Evidence

Agent 的自然语言叙述不能充当成功证明。系统必须通过环境中的可观察结果判断进度，否则长链路很容易退化成“模型不断相信自己已经完成”的闭环幻觉。

这也是 coding agent 特别适合 Agent 化的重要原因：代码天然拥有 compile、test、lint、runtime、diff 等高质量反馈信号。

Stopping Conditions：自主不等于无限循环

Agent 必须有明确退出机制，详见 Agent 中的 Stopping Conditions。

至少需要考虑：

• success condition；
• max iterations；
• token / cost budget；
• time budget；
• repeated failure；
• human checkpoint / escalation。

停止原因和任务结果还应分开建模：预算耗尽只说明当前执行必须停止，并不意味着任务已经成功。

Framework：抽象不能牺牲可观察性

Anthropic 并不反对 Agent framework，但警告复杂框架容易隐藏：

• 实际 prompt；
• message history；
• tool calls；
• tool results；
• control flow。

这样虽然起步更快，却会让生产问题难以定位，也容易诱导团队在并不需要时增加复杂度。

因此一个重要工程原则是：

Abstraction should remove repetition, not observability.

可以使用框架，但必须理解框架下面真实发生了什么；如果抽象阻碍调试，就应下沉到更基础的组件。

ACI：像设计 HCI 一样设计 Agent-Computer Interface

Agent-Computer Interface (ACI) 是文章最值得长期保留的思想之一。

人类软件工程长期研究 HCI：如何让软件对人容易使用。Agent 系统同样需要研究：

怎样让工具、文件系统、终端和 API 对 Agent 容易使用。

工具定义本身应该像 prompt 一样被认真设计和测试。

减少无意义的格式摩擦

对模型来说，一些对人类程序员只是“格式差异”的接口，难度可能完全不同。例如：

• 手写 unified diff 需要精确维护行数；
• 在 JSON 字符串中输出代码需要大量 escaping；
• 相对路径会因 cwd 改变产生额外推理负担。

设计工具时应尽量：

• 使用模型自然熟悉的格式；
• 减少 line counting、escaping 等 bookkeeping；
• 给模型足够空间在输出前完成推理；
• 让错误状态更难被表达。

Poka-yoke：不要只提醒 Agent 别犯错

比起在 prompt 里写：

请务必使用绝对路径。

更好的设计是：

工具 schema 根本不接受相对路径。

这就是防呆（Poka-yoke）思想：将约束放入接口，而不是依赖模型永远记住规则。

Anthropic 在 SWE-bench Agent 中甚至发现，工具优化投入比整体 prompt 优化更多；将文件工具改为强制 absolute path 后，相关错误显著减少。

为什么 Customer Support 与 Coding Agent 特别典型

文章选择了两个生产价值明显的场景：

Customer Support

Customer Support Agents 同时具有：

• 对话式输入；
• 外部数据和工具；
• 可程序化动作；
• 明确完成标准；
• 必要的人类监督。

Coding Agents

Coding Agents 的优势来自：

• 输出可通过自动测试验证；
• 测试结果可以成为下一轮反馈；
• 问题空间相对结构化；
• 质量比很多开放式知识任务更容易客观评估。

所以 Coding Agent 的成功不仅是因为模型“会写代码”，更是因为软件工程环境提供了高密度 Ground Truth。

三条最终原则

Anthropic 最后把整篇文章压缩为三条原则：

1. Simplicity：保持 Agent 设计简单，只在需要时增加复杂度。
2. Transparency：让 Agent 的计划、行为和执行状态可观察。
3. ACI：投入足够精力设计、记录和测试 Agent 使用的工具接口。

可以进一步总结为：

复杂度必须由收益证明；
自主性必须由反馈约束；
能力必须通过好接口暴露。

对自主软件工程系统的启发

对于 ForgeFlow / Pixel 这类系统，最值得采用的不是“全部 Agent 化”，而是：

Deterministic Workflow
        ↓
Plan → Implement → Review → Validate → Repair
          │          │
       Agent      Agent / Eval

外层 Workflow 负责工程纪律和不可妥协的不变量：

• 必须产生真实 diff；
• 必须运行验证；
• 必须满足 acceptance criteria；
• review 不通过必须进入 repair；
• 重复失败必须停止或升级；
• 高风险操作必须经过边界控制。

内层 Agent 负责真正需要智能判断的部分：

• 去哪里查问题；
• 修改哪些文件；
• 怎样拆解任务；
• 下一步执行哪个工具；
• 根据反馈如何重新规划。

因此最重要的架构原则可以概括为：

确定性由系统提供，智能性由 Agent 提供。

不要让 Agent 自己决定是否需要遵守测试、审查和交付标准。

2026 后续演进：从 Agent Loop 到 Managed Agent Interfaces

2026-04-08，Anthropic 在 Scaling Managed Agents: Decoupling the brain from the hands 中进一步发展了这套思想。

新的重点不是推翻 2024 年的模式，而是把长期 Agent 的基础设施拆成更稳定的接口：

• Session：持久、append-only 的事件历史；
• Harness：负责调用模型、组织 context、路由工具调用的执行循环；
• Sandbox / Hands：真正执行代码、修改文件或连接外部环境的执行端。

核心变化是将 brain 与 hands 解耦：模型推理循环不再必须与某一个 container / sandbox 紧耦合，而可以把不同执行环境视为工具。

这延续了本文的长期原则：

稳定接口
>
绑定某一代模型行为的复杂 harness

随着模型能力提高，过去为旧模型添加的 workaround 可能变成负担，因此架构更应该固定“接口契约”，而不是固定某一代 Agent 的具体行为假设。

后续阅读：

• Scaling Managed Agents: Decoupling the brain from the hands

阅读后的决策规则

以后设计 Agentic System 时，可以先按以下顺序判断：

1. 单次 LLM + Retrieval / Context 能否解决？
   └─ 能 → 不增加复杂度

2. 路径是否固定且可预定义？
   └─ 是 → Workflow

3. 是否只是分类、并行或生成-评价循环？
   └─ 是 → 使用对应 composable pattern

4. 子任务是否无法预先知道？
   └─ 是 → Orchestrator-Workers

5. 下一步路径和执行轮数是否本质不可预测？
   └─ 是 → 才考虑 Autonomous Agent

6. 无论采用哪一层：
   → 定义 Eval
   → 定义 Ground Truth
   → 定义 Stop Conditions
   → 保留 Observability
   → 优化 ACI

这比“先选 Agent 框架再想需求”更接近本文真正的方法论。