Building effective agents
这是一篇 Anthropic 于 2024-12-19 发布的 agent 方法论文章。它不是在讲某个特定 benchmark，而是在给出一套更通用的构建原则：先区分 Workflows vs agents，再从最简单、最可验证的模式开始，只在效果明确提升时才增加系统复杂度。
- 文章把所有这类系统统称为
agentic systems，但进一步强调应明确区分workflows和agents。 workflows指模型和工具通过预定义代码路径被编排；agents指模型基于环境反馈动态决定接下来做什么。- Anthropic 的默认建议不是“尽快上 agent”，而是先尝试单次调用、检索和 in-context examples，只有在这些方案明显不够时才增加多步结构。
- 文章明确反对把框架当默认答案。框架能加速起步，但也容易遮蔽底层 prompt、tool call 和失败模式，让系统更难 debug。
- 这篇文章把
augmented LLM视为最底层 building block，也就是带有 retrieval、tools 和 memory 的模型调用，而不是“裸模型 + 外挂 orchestrator”。 - 在此基础上，文章给出了五种常见 workflow：
prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer。 prompt chaining适合能稳定拆成固定子步骤的任务，本质是用更多 latency 换更高局部正确率。routing适合输入类别差异很大、需要不同 prompt 或不同模型专门处理的任务。parallelization包括sectioning和voting两类：前者为提速，后者为提高结果置信度。orchestrator-workers与普通并行的区别在于：子任务不是事先写死，而是由协调者模型根据具体输入动态拆解。evaluator-optimizer则把“生成”和“挑错”拆成两个角色，在清晰标准下做迭代改进。- 真正的
agents则是在这些 workflow 之外，再加上一层基于工具结果和环境反馈持续循环的自主决策。 - 文章最后把三条原则收束得很清楚：保持简单、保持透明、认真设计 agent-computer interface。
- Appendix 2 的价值很高：Anthropic 明确把工具接口当作 prompt engineering 的一部分，强调输出格式要贴近模型自然见过的文本分布，避免计数、转义和差异格式这类不必要负担。
ℹ️ Conflict:
- 这篇文章倡导“先简单、后复杂”，但随着模型能力提升，某些过去必须用 workflow 的任务，后来可能被单次调用吃掉；因此它给的是决策框架，不是长期固定配方。
- 文中对框架的怀疑是合理的，但在复杂团队环境中，完全不用框架也可能导致可观测性、权限控制和复用性不足。
- 文章把
orchestrator-workers和agents分得很清楚，但现实系统常常同时具备预定义结构和局部自主性，两者边界会随实现方式变化。
- Workflows vs agents
- Agent scaffold
- Agent teams
- Generator-evaluator loop
- Tool ergonomics for agents
- Model Context Protocol (MCP)
- Agentic engineering
- Anthropic
- Anthropic, “Building effective agents”, 2024-12-19.
- 原文摘录：[llm-wiki/raw/anthropic/Building effective agents](/raw/anthropic/Building effective agents.md)