Building Effective Agents 解读：别急着上 Agent，先从简单模式开始
Building Effective Agents 总结
原文：https://www.anthropic.com/engineering/building-effective-agents
一句话概括
这篇文章不是在鼓励“凡事都上 Agent”，而是在讲：构建有效 AI Agent 的关键，是从最简单、可评估、可调试的模式开始，只有当任务确实需要更高自主性时，才逐步增加复杂度。
文章主要讲了什么
Anthropic 把 agentic systems 分成两类：
| 类型 | 含义 | 适合场景 |
|---|---|---|
| Workflow | LLM 和工具按照预定义代码路径运行 | 任务流程清晰、步骤固定、需要稳定可控 |
| Agent | LLM 自己决定流程、工具使用和下一步行动 | 开放式任务、步骤不可预知、需要模型动态决策 |
文章的核心观点是：多数成功实现并不依赖复杂框架，而是使用简单、可组合的模式。很多时候，一个优化好的单次 LLM 调用，加上检索、示例、工具或记忆，就已经足够。
核心构建块：增强型 LLM
Anthropic 认为 Agent 系统的基础不是“神秘的智能体框架”，而是一个增强型 LLM：
- LLM
- Retrieval / 检索
- Tools / 工具
- Memory / 记忆
- 清晰的工具接口和说明
重点在于：工具不是随便接上就行，而要像设计人机界面一样设计“模型-工具界面”，让模型容易理解、容易调用、少犯错。
常见模式
1. Prompt Chaining：提示链
把任务拆成固定步骤，前一步输出给后一步。
适合：
- 任务能清晰拆解
- 每一步都有明确目标
- 愿意牺牲一些延迟换准确率
例子：
- 先写营销文案，再翻译
- 先写大纲，检查大纲，再写全文
注意点：适合线性流程，不适合步骤高度动态变化的任务。
2. Routing：路由
先分类输入，再把它交给不同流程、提示词、工具或模型。
适合：
- 输入类型差异明显
- 不同类型需要不同处理方式
- 分类准确率可以保证
例子：
- 客服问题分成退款、技术支持、普通咨询
- 简单问题交给便宜小模型，复杂问题交给强模型
注意点：路由分类错了，后续流程也会错。所以分类器本身要评估。
3. Parallelization：并行化
让多个 LLM 调用同时处理任务，再汇总结果。
两种形式：
- Sectioning：拆成独立子任务并行处理
- Voting：同一个任务跑多次，用投票或聚合提升可靠性
适合：
- 子任务可以独立完成
- 需要多个视角检查
- 需要提高置信度
例子：
- 一个模型回答用户问题，另一个模型做安全审查
- 多个模型或提示词审查代码漏洞
注意点：并行不只是为了快，也可以为了“分散注意力”，让每个模型专注一个维度。
4. Orchestrator-Workers：编排者-工作者
一个中心 LLM 负责拆解任务、分配给多个 worker，再综合结果。
适合：
- 任务复杂
- 事先不知道要拆成哪些子任务
- 子任务数量和类型取决于输入
例子：
- 编程任务：不知道要改哪些文件、怎么改
- 搜索研究：需要从多个来源收集、筛选、综合信息
注意点：它看起来像并行化，但关键区别是：并行化的子任务通常预先定义，orchestrator-workers 的子任务由 LLM 动态决定。
5. Evaluator-Optimizer：评估者-优化者
一个 LLM 生成答案，另一个 LLM 评价、反馈，然后循环改进。
适合：
- 有明确评价标准
- 迭代确实能提升质量
- LLM 能给出有效反馈
例子：
- 文学翻译
- 复杂研究任务，需要多轮搜索和分析
注意点：如果评价标准模糊，循环可能只是增加成本，不一定提高质量。
6. Autonomous Agent：自主 Agent
Agent 在任务明确后，自主计划、调用工具、观察环境反馈、调整策略，必要时向人类请求帮助。
适合：
- 开放式问题
- 无法预先硬编码流程
- 需要多轮操作
- 有可靠环境反馈，例如测试结果、工具结果、执行结果
例子：
- 编程 Agent 解决 SWE-bench 任务
- Claude 的 computer use 示例
注意点：Agent 能力更强，但成本、延迟和错误累积风险也更高。必须有沙箱、护栏、停止条件和人工检查点。
文章最重要的观点
1. 先简单，再复杂
不要一开始就上完整 Agent。文章反复强调：先从简单 prompt、单次 LLM 调用、检索、上下文示例开始。只有当评估证明简单方法不够时，才增加 workflow 或 agent。
2. Workflow 比 Agent 更可控
很多业务场景其实更适合 workflow，而不是完全自主 Agent。Workflow 的优点是稳定、可预测、容易调试；Agent 的优点是灵活，但也更难控制。
3. 框架可以用，但不要被框架遮住底层
框架能降低上手成本，例如封装 LLM 调用、工具定义、链式调用等。但框架也可能带来额外抽象，让 prompt、响应和工具调用更难调试。
建议是：最好先理解底层，甚至直接用 API 实现简单模式。用了框架，也要知道它内部到底做了什么。
4. 工具设计是 Agent 成败关键
文章特别强调 Tool Prompt Engineering。工具定义、参数名、描述、输入输出格式，都需要像 prompt 一样认真设计。
好的工具应该：
- 参数清楚
- 描述明确
- 有示例
- 边界清晰
- 不容易误用
- 格式贴近模型熟悉的自然文本
- 避免复杂转义、行号统计、难写 diff 等格式负担
一个很实际的例子：他们发现相对路径容易让模型犯错，于是改成要求绝对路径，效果更好。
5. Agent 需要环境反馈
Agent 不是闭门“思考”就能可靠完成任务。它需要不断从环境获得 ground truth，例如：
- 工具调用结果
- 代码执行结果
- 测试结果
- 搜索结果
- 用户反馈
没有真实反馈，Agent 很容易在错误路径上越走越远。
两个特别适合 Agent 的场景
客户支持
客服天然具备：
- 对话式交互
- 需要查订单、用户信息、知识库
- 可以执行退款、更新工单等动作
- 成功标准相对清晰
编程 Agent
软件开发具备：
- 结构化问题空间
- 可以运行测试
- 可以根据测试失败迭代
- 结果相对容易客观评估
但即使自动测试通过，人类 review 仍然重要，因为测试不能覆盖所有系统意图和产品约束。
需要特别注意的坑
- 不要为了“看起来高级”而做 Agent。
- 不要忽略成本和延迟，Agent 通常更贵更慢。
- 不要让 Agent 无限循环，要设置停止条件。
- 不要只看 demo，要做系统性 eval。
- 不要把工具接口设计得让模型费劲。
- 不要过度依赖框架抽象，否则 debug 会很痛苦。
- 不要让 Agent 在高风险环境里直接操作，先沙箱测试。
- 不要把“模型能做”误解成“生产环境可靠”。
实践路线
可以按这条路线逐步演进：
单次 LLM 调用 -> 增强型 LLM -> 简单 workflow -> 组合 workflow -> 自主 Agent每升一级复杂度，都应该有评估结果证明它值得。
我的理解
这篇文章的重点非常工程化：Agent 不是一个产品标签，而是一种复杂度选择。真正有效的 Agent 系统，通常不是最炫的，而是最清楚、最可测、最能被人理解和控制的。
如果要落到团队实践里，可以把问题改成：
- 这个任务是否真的需要模型自主决定下一步？
- 能不能先用固定 workflow 解决？
- 是否有明确 eval 来证明 Agent 版本更好？
- 工具接口是否足够清楚、可控、可调试？
- 出错时人类是否能理解它为什么错、错在哪里？
这也是文章最值得带走的地方：少一点“Agent 崇拜”，多一点工程判断。
支持与分享
如果这篇文章对你有帮助，欢迎分享给更多人或赞助支持！
评论区
音乐
暂未播放