Anthropic：高效构建Agents设计理念
High-level flow of a coding agent
高效构建Agents的设计理念
始终贯穿"实用优先、简洁可控、按需适配"的逻辑。
1. 最小复杂度优先，拒绝过度设计
构建 LLM 系统时，始终以最简方案为起点：优先使用单次 LLM 调用 + 检索或上下文示例。仅当基础方案无法达成性能目标时，才逐步引入多步骤 workflows 或 Agents。核心在于避免为技术炫技而牺牲效率，持续权衡延迟、成本与任务表现之间的平衡，绝不因追求"先进"而无谓堆砌功能或依赖重型框架。
2.架构按需匹配，不搞"一刀切"
系统选型应由任务特性驱动，而非技术偏好：预定义 workflows：适用于规则清晰、需稳定输出的场景；自主 Agents：适配开放性高、依赖模型动态推理的任务；基础 LLM 调用：对单步任务，直接使用原生能力，无需引入任何中间层。架构的本质是"场景适配"，而非"技术驱动"。
3.模块化可组合，灵活适配需求
以"增强型 LLM"为统一基础单元（集成检索、工具调用、记忆能力），搭配五类可复用 workflows 模式（提示词链、路由、并行化等），支持按需拆解与重组。模式非固定模板，允许自由定制，拒绝"一套框架通吃"的僵化思维，强调轻量、弹性与可迭代性。
4.透明可控为基，兼顾实用与可维护
拒绝冗余抽象：优先直连 LLM API，即便使用框架，也必须透彻理解其底层机制；过程全可见：清晰呈现 Agents 的每一步规划路径，工具接口需文档完备、参数命名直观、示例齐全；防呆设计：强制规范输入格式（如绝对路径）、压缩冗余结构，降低模型误用工具的概率，提升系统鲁棒性。
5.人机协同赋能，可控范围内自主
Agents 的"自主"不是无界自由，而是在监督框架内实现：人类介入点：在任务卡点、结果审核等关键环节保留人工干预，构建"评估者-优化者"反馈闭环；风险控制机制：沙盒测试 + 最大迭代限制 + 行为护栏，防止错误累积与成本失控；角色互补：Agents 处理重复执行与动态决策，人类专注标准制定与复杂判断，目标是增强而非替代。
构建高效的 Agents 细节
发布时间：2024年12月19日 00:00:00 | Anthropic 工程团队 著我们与众多行业内致力于构建大语言模型（LLM）Agents的团队建立了深度协作。实践反复验证，最具成效的实施方案，往往源于简洁且具备高可组合性的设计，而非冗余的复杂框架。过去一年中，我们已与数十支横跨不同领域的团队共同推进LLM Agents的落地，而贯穿始终的共性是：顶尖成果从未依赖重型框架或专属库，而是根植于轻量、模块化、易于拼接的架构逻辑。本文旨在系统梳理我们在客户合作与自研实践中沉淀的洞察，并为开发者提供一套可直接落地的高效Agents构建指南。何为"Agents"？业界对"Agent"的理解存在显著差异。一些客户将其视为具备长期运行能力、能自主调用多种工具以完成复杂目标的全自治系统；另一些则将其理解为严格遵循预设工作流的指令驱动型实现。在Anthropic的语境中，我们统称这些形态为agentic systems，但明确在架构层面区分两类核心范式：workflows：通过静态编码路径对LLM与工具进行固定编排的系统。Agents：由LLM动态决策执行路径与工具调用，自主掌控任务完成逻辑的系统。
什么时候(以及什么时候不)使用Agents？
在基于 LLM 构建应用时，应优先采用最简方案，仅在必要时引入复杂性------有时，这意味着完全无需构建任何 Agents 系统。Agents 通常以更高的延迟与成本为代价，换取任务性能的提升，你需要审慎评估这种权衡是否值得。当确实需要更高层级的系统设计时：workflows 适用于目标清晰、流程固定的场景，能保障执行的可预测性与一致性；而 Agents 则更适配那些依赖模型自主决策、具备高度动态性与开放性需求的任务。然而，对多数应用场景而言，仅通过检索增强与上下文示例优化单次 LLM 调用，往往已能充分满足需求。关于框架的选择与使用：当前已有多个工具可简化 Agents 系统的开发，例如：LangChain 推出的 LangGraph；Amazon Bedrock 的 AI Agent 框架；Rivet（一款提供拖拽式 GUI 的 LLM workflows 构建工具）；以及 Vellum（另一款专为复杂 workflows 设计与测试的 GUI 平台）。这些框架通过封装 LLM 调用、工具定义与解析、多步串联等底层逻辑，显著降低了开发门槛。但与此同时，它们也引入了额外的抽象层，可能隐藏提示词结构与模型响应细节，从而增加调试难度；更易误导开发者在简单方案足以胜任时，盲目叠加复杂架构。我们建议：优先直接调用 LLM API------许多核心模式仅需数行代码即可实现。若确需借助框架，请务必深入理解其底层实现机制；对抽象层的误判，正是生产环境中常见的故障根源。可参阅我们的示例代码集（cookbook）获取实践参考。本节将梳理我们在生产环境中观察到的 Agents 系统典型架构模式。我们将从最基础的构建单元------增强型 LLM------出发，逐步递进，依次展开对轻量级可组合 workflows 与全自主 Agents 的探讨。
构建Blocks：增强型 LLM
The augmented LLMAgents系统的基本构建块是增强型 LLM------即通过检索、工具、记忆等增强功能扩展的 LLM。我们当前的模型能够主动运用这些能力：生成自己的搜索查询、选择合适的工具，并决定需要保留哪些信息。
注：我们的评估表格未包含 OpenAI 的 o1 模型系列，因为该系列模型依赖大量预响应计算时间，与典型模型存在本质差异，导致性能对比缺乏参考意义。
增强型 LLM 的实现建议
建议聚焦两大关键实现原则：根据实际应用场景定制增强功能，并为 LLM 构建简洁且文档完备的接口。尽管实现这些增强能力的路径多样，模型上下文协议(Model Context Protocol) 为我们提供了一种高效方案------开发者仅需完成轻量级客户端集成，即可无缝接入不断扩展的第三方工具生态。在本文后续讨论中，我们将默认所有 LLM 调用均自动启用上述增强能力。
workflows：提示词链(Prompt Chaining)
该机制将复杂任务拆解为连续的多个步骤，每一阶段的 LLM 调用均以先前步骤的输出作为输入。你可在任意中间环节插入程序化校验节点（参见下图中的"gate/网关"），以保障流程严格遵循预设逻辑推进。
The prompt chaining workflow
适用场景
该 workflows 适用于那些能够被轻松、清晰拆解为固定子任务的场景，其核心目的在于通过简化每个 LLM 调用的具体任务，以增加处理延迟为代价，换取更高的输出准确性。典型应用包括：先生成营销文案，再将其译为多种语言；或先拟定文档大纲，验证其是否符合预设规范，随后依据审核通过的大纲完成全文撰写。
workflows：路由（Routing）
路由机制会对输入内容进行分类，并定向分发至对应的专用后续处理模块。该机制支持关注点分离，使提示词设计更具领域针对性。若缺失此路由结构，对某一类输入的专项优化，极易对其他类型输入的处理效能造成连锁干扰。
The routing workflow
适用场景
路由适用于以下类型的任务：任务存在清晰可辨的类别划分，且每一类别均具备独立处理的最优路径；此类分类可通过大型语言模型（LLM）或传统分类模型/算法高效实现。典型应用场景包括：将客户服务请求（如一般咨询、退款申请、技术支持）分别路由至对应的处理流程、提示模板与工具链；针对简单或高频问题，调用 Claude 3.5 Haiku 等轻量级模型以提升响应效率，而对复杂或非标问题，则交由 Claude 3.5 Sonnet 等高性能模型处理，从而实现成本与延迟的最优平衡。
Workflows：并行化（Parallelization）
在某些场景下，LLM 可同步执行同一任务的多个实例，并通过程序化机制整合输出结果。该类并行化流程主要包含两种核心模式：分段处理（Sectioning）：将原始任务分解为若干互不依赖的子任务，同步并行推进；投票机制（Voting）：对同一任务执行多次独立推理，收集多样输出后进行共识聚合。
The parallelization workflow
适用场景
当子任务能够通过并行执行加速处理，或需从多角度反复验证以提升结果可信度时，并行化策略展现出显著优势。针对包含多重评估维度的复杂任务，LLM 在每个维度由独立调用的模型分别处理时，往往能取得更优表现------此举使各模型得以聚焦于单一分析面向。实用示例分段处理：实现护栏机制（guardrails）：一个模型实例专责响应用户查询，另一实例同步过滤不当内容或违规请求（该架构通常优于单个 LLM 同时兼顾护栏与核心响应）；自动化评估 LLM 性能：每一次 LLM 调用独立评估模型在特定提示下的某项能力表现。投票机制：代码漏洞审查：运用多个差异化提示对代码进行多轮审查，发现任一问题即标记；内容合规性评估：通过多组提示从不同维度判定内容是否违规，并动态设定投票阈值，以精准权衡误报率与漏报率。
Workflows：协调者-执行者（Orchestrator-workers）
在协调者-执行者工作流中，中央 LLM 动态拆解任务，将子项分派至多个执行者 LLM，并最终整合各结果生成统一输出。
适用场景
该 workflows 专为子任务不可预知的复杂场景设计（如编码中，待修改文件的数量与内容高度依赖具体任务需求）。尽管其结构看似与并行化相近，本质差异在于动态性------子任务并非在启动前固定，而是由协调者依据实时输入动态生成。典型应用场景包括：需对多个文件实施精细化调整的编码系统；需整合多源信息并进行深度分析的检索任务。
workflows：评估者-优化者（Evaluator-optimizer）
在此框架中，一个 LLM 调用负责生成初始响应，另一个 LLM 则通过迭代循环持续提供评估与反馈，形成闭环优化机制。
适用场景
该 workflows 在以下场景中表现尤为突出：具备清晰的评估准则；通过反复迭代可实现可衡量的效能提升。判断其适用性的两大核心指标为：当人类提供明确反馈时，LLM 的输出质量出现显著跃升；LLM 自身亦能生成具有建设性的反馈意见。这一机制与作家打磨文稿时的循环修订过程高度相似。典型应用场景包括：文学翻译：译者 LLM 初期或难以精准传达语义 nuances，但评估者 LLM 能够提出精准的修辞建议与风格修正；复杂搜索任务：需经多轮信息抓取与交叉验证方可形成完整认知，评估者 LLM 负责判定是否需继续拓展检索范围。随着 LLM 在核心能力------理解复杂输入、推理与规划、稳定调用工具、从失败中自愈------上的持续进化，Agents 已逐步进入生产级部署阶段。其典型工作流结构如下：接收人类指令，或经由对话交互厘清任务目标；任务界定后，自主制定执行路径并驱动操作，必要时主动请求人类介入以确认判断；执行过程中，关键在于 Agents 每一步均能获取来自环境的真实数据（如工具返回结果、代码运行输出），用以动态评估进展；在关键检查点或遭遇执行障碍时，可主动暂停，等待人工反馈；任务通常于达成目标后自然终止，但为保障可控性，普遍设定终止条件（如最大迭代轮次）。Agents 能够驾驭高度复杂的任务，但其底层架构往往极为简洁------本质上，不过是 LLM 在闭环中依据环境反馈持续调用工具的过程。因此，工具集的设计完整性与文档的清晰度，成为决定系统成败的基石。关于工具开发的最优实践，详见附录 2《工具的 Prompt engineering》。
Autonomous agent
适用场景
Agents 适用于以下场景：开放式问题：步骤数量难以预判，无法通过硬编码设定固定流程；多轮操作需求：模型需执行连续交互，且对其自主决策具备合理信任；Agents 的自主特性，使其在受控可信环境中具备规模化任务处理的天然优势。然而，这种自主性也伴随更高的资源开销与错误逐层累积的风险。建议在沙盒环境中完成全面验证，并部署有效的护栏机制以约束行为边界。实用示例（基于自有实现）：编码 Agents：应对 SWE-bench 任务（依据任务描述协同修改多个文件）；"计算机使用"参考实现：Claude 通过直接操作计算机界面完成目标任务。
High-level flow of a coding agent
组合与定制这些模式
这些构建块并非强制性规范，而是开发者可根据不同用例调整和组合的常见模式。与所有 LLM 功能一样，成功的关键在于衡量性能并迭代优化实现方案。再次强调：仅当复杂度的增加能显著改善结果时，才考虑添加。
总结
在 LLM 领域实现突破，关键不在于追求系统复杂度，而在于精准构建贴合实际需求的解决方案。起步阶段，优先采用简洁的提示词，并通过系统性评估持续迭代；只有当基础方案无法达成目标时，才引入多步骤 Agents 系统。在构建 Agents 时，始终坚守三大准则：保持设计的极简性；优先实现透明性------清晰呈现每个规划环节；依托完备的工具文档与严格测试，细致打磨 Agents-计算机接口（ACI）。原型阶段可借助框架加速开发，但迈向生产环境时，应主动剥离冗余抽象，回归基础组件进行搭建。恪守这些准则，你将打造出兼具强大功能、高可靠性、易维护性与用户信赖度的 Agents 系统。