Building Effective Agents

• 公司：Anthropic
• 来源类型：官方 Engineering 文章
• 发布时间：2024-12-19
• 原文：https://www.anthropic.com/engineering/building-effective-agents
• 可靠性：高；这是 Anthropic 基于客户项目与内部实践的公开工程总结。页面同时提示，部分工具生态已经变化，应结合当前文档阅读。

核心观点

Anthropic 的主张是：最成功的 Agent 往往不是最复杂的系统，而是由简单、可组合的模式构成。应先用最简单的方案解决问题，再在效果可测量地提升时增加复杂度。

方法框架

1. 先区分增强型 LLM、工作流和 Agent

• 增强型 LLM：模型加上检索、工具、记忆等能力。
• 工作流：步骤基本固定，程序控制流程，适合可预测任务。
• Agent：模型根据环境反馈动态决定下一步，适合步骤数量和路径难以预先确定的开放问题。

2. 五类常见工作流

• Prompt chaining：把任务拆成固定的连续步骤；适合可清晰分解的任务，可在中间加程序化检查。
• Routing：先分类，再进入不同的专门处理路径；适合输入类型差异明显的任务。
• Parallelization：并行执行独立子任务，或让多个调用从不同角度作答，再程序化汇总；适合提速或提高置信度。
• Orchestrator-workers：中心模型动态拆任务，分派给 Worker，再综合结果；适合无法提前知道子任务结构的复杂任务。
• Evaluator-optimizer：一个调用生成，另一个调用评估并反馈，循环优化；适合评价标准清晰且迭代确实有价值的任务。

3. Agent 的关键是工具和环境反馈

Agent 通常是模型在循环中调用工具，并根据真实环境返回结果修正计划。工具描述、参数和返回结果必须清晰；每一步都应尽量获得 ground truth，而不是仅依赖模型自我判断。

4. 自主性必须换来可控性

Agent 适合开放式、无法硬编码路径的任务，但会带来更高成本和错误累积风险。建议：

• 在沙盒环境中测试；
• 设置最大迭代次数和停止条件；
• 在高风险节点暂停并请求人工判断；
• 用评估集持续测量，而不是凭一次 Demo 判断。

可直接复用的原则

1. 先尝试单次调用、检索和示例，再考虑 Agent。
2. 只有当增加复杂度能带来可测量收益时才增加复杂度。
3. 工作流优先于 Agent；固定任务不要强行自治。
4. 工具接口是 Agent 能力的一部分，工具说明要像 API 设计一样认真。
5. 框架可以帮助起步，但生产化前要理解底层提示、调用和状态。

适用场景

研究、编码、客服分流、资料审核、需要多轮工具调用的开放式任务。

不应过度解读

文章是 2024 年的工程总结，不是某个 SDK 的最新 API 手册。具体实现应以当前产品文档为准。