本页目录7
- Workflows(预定义代码路径编排LLM和工具)与Agents(LLM动态自主决策流程)是两类不同复杂度的系统,应按需渐进选择,而非一开始就上Agent。
- 五种常见workflow模式:Prompt Chaining(提示链)、Routing(路由分类)、Parallelization(并行化,含Sectioning和Voting两种)、Orchestrator-Workers(编排者-工作者)、Evaluator-Optimizer(评估者-优化者)。
- Agent适合步骤数无法预判、无法硬编码固定路径的开放式问题,但自主性越高,成本和复合错误风险也越高,需要在沙箱中充分测试。
- 建议先直接用LLM API裸写,很多模式几行代码就能实现;框架能简化底层调用但也可能掩盖真实的prompt和响应,使系统更难调试。
- 三大核心原则:保持agent设计简洁(simplicity)、让agent的规划步骤对外透明(transparency)、通过详尽文档和测试打磨好agent-computer interface(ACI)。
- 工具设计(ACI)常常比整体prompt更值得花时间打磨,例如SWE-bench案例中把相对路径参数改成强制绝对路径后模型调用质量显著提升。
本文是对 Anthropic 官方文章《Building Effective Agents》的中文要点摘要,完整内容以原文为准:https://www.anthropic.com/engineering/building-effective-agents
Workflow 与 Agent 的区别
文章基于 Anthropic 与数十个团队合作的实践经验,核心结论是:最成功的实现往往用的是简单、可组合的模式,而不是复杂框架。文中给出了两个关键定义:
- Workflows(工作流):LLM 和工具通过预定义的代码路径被编排调用。
- Agents(代理):LLM 动态地自主指导自身的处理流程和工具使用。
两者不是对立关系,而是复杂度递进的两端。文章建议:优先用简单方案——单次 LLM 调用配合检索(retrieval)和上下文示例(in-context examples)——通常就够用;只有当任务确实需要更高灵活性和模型驱动的决策时,才逐步引入 workflow 乃至 agent。需要注意,agentic 系统通常是用延迟和成本去换取更好的任务表现。
五种常见 Workflow 模式
| 模式 | 定义 | 适用场景 |
|---|---|---|
| Prompt Chaining(提示链) | 把任务拆成若干顺序步骤,前一步输出作为后一步输入 | 任务能被清晰、干净地拆解为固定子任务时,如「生成营销文案→翻译」「写大纲→质检→成文」 |
| Routing(路由) | 先对输入分类,再分发给专门处理该类别的后续流程 | 任务类别边界清晰的场景,如按查询类型分流客服请求,或按难度选用不同规模模型(如 Haiku 与 Sonnet) |
| Parallelization(并行化) | 分为 Sectioning(拆分子任务并行跑)和 Voting(同一任务多次跑取多元结果)两种变体 | 子任务可并行以提速,或需要多个视角互相校验时,如内容审核与生成分离、代码安全的多路审查 |
| Orchestrator-Workers(编排者-工作者) | 中央 LLM 动态拆解任务、派发给工作 LLM、再汇总结果 | 子任务无法提前预测的复杂任务,如涉及多文件的编码改动、多信息源检索与整合 |
| Evaluator-Optimizer(评估者-优化者) | 一个 LLM 生成响应,另一个在循环中给反馈,迭代优化 | 有明确评估标准、且迭代能带来可衡量提升的场景,如文学翻译的字斟句酌、多轮检索分析 |
与 Parallelization 相比,Orchestrator-Workers 的关键差异在于:子任务不是提前拆好的,而是编排者依据具体输入动态决定的,灵活性更高。
Agent 的特征与何时使用
Agent 的核心机制是在循环中根据环境反馈行动:每一步都从环境获取「ground truth」,必要时可以在检查点暂停等待人类反馈。文章指出,Agent 的实现本身其实并不复杂——「本质上就是 LLM 基于环境反馈在循环里使用工具」。
适用场景:步骤数难以预判、无法硬编码固定路径的开放式问题。典型案例包括 SWE-bench 中涉及多文件编辑的编码任务,以及 Claude 的「computer use」参考实现。
风险:自主性带来更高成本和复合错误的可能性,因此需要在沙箱环境中做充分测试。
框架该不该用
文中提到几类现成框架,包括 Claude Agent SDK、AWS Strands Agents SDK,以及提供拖拽式 GUI 的 Rivet、Vellum 等。
框架的价值在于简化调用 LLM、定义和解析工具等标准化底层工作,但代价是「会引入额外的抽象层,掩盖底层真实的 prompt 和响应,使系统更难调试」。文章建议先直接用 LLM API 裸写,很多模式几行代码就能实现;若确实要用框架,务必先弄清楚框架底层到底做了什么——「对底层实现的错误假设是客户常见的错误来源」。
三大核心设计原则
- Simplicity(简洁性):agent 设计要尽量简单。
- Transparency(透明性):显式展示 agent 的规划步骤,而不是黑盒运行。
- ACI(agent-computer interface):通过详尽的工具文档和充分测试,精心打磨 agent 与工具之间的接口。
关于工具设计(附录中的 ACI 部分),文章给出几条实操建议:
- 给模型留足「思考」的 token 空间,不要让格式挤占推理过程。
- 工具输入输出格式尽量贴近互联网上自然出现的形式,避免额外的格式开销(比如强制精确计数、复杂字符转义)。
- 像给初级工程师写 docstring 一样打磨参数命名和工具说明,包含示例、边界情况和输入格式要求。
- 在 workbench 里跑多个真实示例,观察模型在哪里犯错,再针对性调整工具设计;可以用「poka-yoke」思路,改造参数结构让误用变得更难发生。
文章特别提到一个 SWE-bench 案例:团队实际花在打磨工具上的时间比打磨整体 prompt 还多。他们发现模型经常在相对路径参数上出错,把参数改为强制绝对路径后,模型的工具调用质量显著提升。
两个典型应用场景
- 客户支持:自然对话流结合工具调用,能接入客户数据、订单历史、知识库,支持退款、更新工单等具体操作,且成功与否有明确可测量的标准。
- 编程 Agent:代码质量可以通过自动化测试客观验证,agent 能依据测试结果的反馈不断迭代,问题空间本身也有清晰的结构,天然适合 agentic 方式。
总结建议
文章的整体方法论是递进式的:先优化单次 LLM 调用,再按需加入检索和示例,只有在明确需要时才逐步引入多步系统或 agent。最后引用原文的核心态度:
「LLM 领域的成功不在于构建最复杂精巧的系统,而在于为你的需求构建恰到好处的系统。」
成功的关键在于持续衡量效果并迭代实现,只有当更高的复杂度能带来可验证的效果提升时,才值得引入。