构建高效智能体

在本文中，我们将分享自己在帮助客户构建智能体、以及亲自构建智能体的过程中学到的经验，并为开发者提供一些关于如何构建高效智能体的实用建议。

什么是智能体？

“智能体（Agent）”有多种定义方式。有些客户把智能体定义为能够在较长时间内独立运行、使用各种工具完成复杂任务的全自主系统；另一些人则用这个词指代更具约束性的实现——系统按照预先定义好的工作流执行任务。

我们把这些不同形式统称为智能体系统（agentic systems），但在架构上会明确区分工作流（workflows）与智能体（agents）：

• 工作流：LLM 和工具按照预先定义好的代码路径被编排执行。

• 智能体：LLM 会动态决定自己的执行过程和工具使用方式，并持续掌控任务究竟该如何完成。

下面我们会详细讨论这两类智能体系统。在附录 1“智能体的实际应用”中，我们还会介绍两个客户已经发现这类系统具有明显价值的应用领域。

什么时候该使用智能体，什么时候不该使用？

在使用 LLM 构建应用时，我们建议优先寻找尽可能简单的解决方案，只有在确有必要时才增加复杂度。这甚至可能意味着：根本不需要构建智能体系统。

智能体系统通常是用更高的延迟和成本，换取更好的任务执行效果。因此，你需要认真判断，这种权衡是否真的值得。

当任务确实需要更高复杂度时，工作流更适合那些定义明确、强调可预测性和一致性的任务；而当系统需要更高的灵活性，并且需要让模型大规模自主做决策时，智能体通常更合适。

不过，对于很多应用来说，对单次 LLM 调用进行优化，再辅以检索和上下文示例，通常就已经足够了。

什么时候、以及如何使用框架？

目前有很多框架可以降低智能体系统的实现难度，例如：

• Agent SDK；

• AWS 的 Strands Agents SDK；

• Rivet，一款支持拖拽式构建 LLM 工作流的图形界面工具；

• Vellum，另一款用于构建和测试复杂工作流的 GUI 工具。

这些框架通过简化一些标准的底层工作——例如调用 LLM、定义和解析工具、把多个调用串联起来——让开发者能够更快上手。

但与此同时，它们往往也会额外增加抽象层，把底层真正发生的提示词与响应隐藏起来，从而增加调试难度。框架还可能诱使开发者在本来可以保持简单的情况下，不必要地引入更多复杂性。

我们的建议是：开发者一开始应尽量直接使用 LLM API。很多常见模式只需要几行代码就能实现。

如果你确实使用了框架，请务必理解它底层究竟在做什么。对“框架内部实际发生了什么”存在错误假设，是我们在客户实践中经常见到的问题来源。

一些示例实现可以参考我们的 cookbook。

构建模块、工作流与智能体

这一节中，我们会介绍自己在真实生产环境里看到的几种常见智能体系统模式。

我们会从最基础的构建模块——增强型 LLM（augmented LLM）——开始，然后逐步增加复杂度，从简单的组合式工作流一直讲到自主智能体。

构建模块：增强型 LLM

智能体系统最基础的组成单元，是一个通过检索、工具和记忆等能力得到增强的 LLM。

当前的模型已经可以主动利用这些能力：自己生成搜索查询、选择合适的工具，并决定哪些信息值得保留。

在实现这类增强能力时，我们建议重点关注两个方面：

1. 根据具体应用场景定制这些能力；

2. 为 LLM 提供简单、清晰、文档完善的接口。

增强 LLM 有多种实现方式。其中一种方式是使用我们近期发布的 Model Context Protocol（MCP）。开发者只需要实现一个简单的客户端，就可以接入不断扩大的第三方工具生态。

本文接下来的内容都默认：每一次 LLM 调用，都可以使用这些增强能力。

工作流：提示链（Prompt Chaining）

提示链会把一个任务拆成一系列连续步骤，其中每一次 LLM 调用都会处理上一次调用的输出。

你还可以在任意中间步骤加入程序化检查——以确认整个执行流程仍然处于正确轨道上。

什么时候适合使用这种工作流：

当任务能够被轻松、清晰地拆解成一组固定子任务时，提示链非常合适。

它的核心思路，是牺牲一定延迟，换取更高准确率。因为经过拆分以后，每一次 LLM 调用都只需要解决一个更简单的问题。

适合使用提示链的例子：

• 先生成营销文案，再把它翻译成另一种语言；

• 先生成文档大纲，检查大纲是否符合特定要求，然后再根据大纲完成全文。

工作流：路由（Routing）

路由工作流会先对输入进行分类，然后把它导向一个专门针对该类输入设计的后续任务。

这种方式可以把不同问题分开处理，并让开发者为每一种情况设计更专业的提示词。

如果不使用路由，在优化一种输入类型时，往往可能无意中损害另一种输入类型上的表现。

什么时候适合使用这种工作流：

当任务比较复杂，但可以清晰划分成若干类别，而且不同类别更适合采用不同处理方式时，路由非常有效。

前提是分类本身必须足够准确，可以由 LLM 完成，也可以采用传统分类模型或算法。

适合使用路由的例子：

• 把不同类型的客服请求——例如一般咨询、退款请求、技术支持——分别导向不同的后续流程、提示词和工具；

• 把简单、常见的问题路由给成本更低的小型模型，例如 Haiku 4.5；把困难或罕见的问题路由给能力更强的模型，例如 Sonnet 4.5，以优化整体性能与成本。

工作流：并行化（Parallelization）

LLM 有时可以同时处理同一个任务的不同部分，然后由程序对输出进行聚合。

这种工作流称为并行化，主要有两种形式：

• 分块（Sectioning）：把任务拆成彼此独立的子任务，然后并行执行；

• 投票（Voting）：让同一个任务被执行多次，从而得到多个不同结果。

什么时候适合使用这种工作流：

当拆分后的子任务能够并行处理，从而提升速度时，并行化很有效；如果一个问题需要多个视角或多次尝试，才能获得更高置信度，并行化同样适合。

对于需要同时考虑多个因素的复杂任务，让不同 LLM 调用分别聚焦于某一个具体方面，通常会比让一次调用同时处理所有因素得到更好的效果。

适合使用并行化的例子：

分块：

• 实现安全护栏：一个模型实例负责处理用户请求，另一个模型实例同时检查其中是否包含不当内容或请求。通常，这比要求同一个 LLM 调用同时负责安全检查和核心回答效果更好；

• 自动化评测：让不同的 LLM 调用分别评估模型在同一个提示词下的不同表现维度。

投票：

• 审查代码漏洞：使用多个不同提示词分别检查代码，只要某些审查发现问题就进行标记；

• 判断某段内容是否不当：让多个提示词从不同角度进行判断，或者设置不同的投票阈值，以平衡误报和漏报。

工作流：编排者—工作者（Orchestrator-Workers）

在“编排者—工作者”工作流中，一个中心 LLM 会动态拆解任务，把子任务分配给若干工作 LLM，最后再综合这些工作者的结果。

什么时候适合使用这种工作流：

这种模式特别适合那些很难提前预测具体需要哪些子任务的复杂任务。

例如在编程任务里，需要修改多少文件、每个文件需要做什么改动，往往都取决于当前具体任务本身，因此无法提前写死。

它在结构上看起来与并行化比较相似，但两者之间最关键的区别是灵活性：

并行化中的子任务通常是预先定义好的；而在编排者—工作者模式中，子任务是由编排者根据当前输入动态决定的。

适合使用编排者—工作者的例子：

• 每次都需要对多个文件执行复杂修改的编程产品；

• 需要从多个来源收集并分析信息、判断哪些信息可能相关的搜索任务。

工作流：评估者—优化者（Evaluator-Optimizer）

在“评估者—优化者”工作流中，一个 LLM 调用负责生成答案，另一个 LLM 调用负责评估并给出反馈，两者通过循环不断迭代。

什么时候适合使用这种工作流：

当任务拥有明确的评价标准，而且反复优化能带来可测量的改进时，这种模式尤其有效。

通常有两个信号可以说明它非常适合某个任务：

1. 当人类明确说出修改意见后，LLM 的输出可以显著变得更好；

2. LLM 自己也能够生成这类有价值的修改意见。

这与人类作者反复修改文章、逐步把初稿打磨成成熟文本的过程非常类似。

适合使用评估者—优化者的例子：

• 文学翻译：翻译 LLM 第一版可能遗漏一些细微语义，但评估 LLM 可以指出其中的问题；

• 复杂搜索任务：需要多轮搜索和分析才能收集完整信息，由评估者判断是否还需要继续进行新的搜索。

智能体（Agents）

随着 LLM 在几个关键能力上不断成熟——理解复杂输入、推理与规划、可靠使用工具、从错误中恢复——智能体正在越来越多地进入真实生产环境。

智能体的工作通常从人类用户的一条指令，或一段交互式对话开始。

一旦任务足够明确，智能体就可以自行规划并独立执行。在执行过程中，它也可能再次回到用户这里，请求额外信息或寻求人类判断。

智能体执行任务时，一个至关重要的要求是：它必须在每一步都从环境中获得“真实反馈（ground truth）”，例如工具调用结果或代码实际执行结果，以此判断自己的执行进度。

智能体可以在预设检查点停下来接受人类反馈，也可以在遇到阻塞问题时请求用户介入。

任务通常会在目标完成后结束，但为了维持系统可控性，也常常会加入停止条件，例如设置最大迭代次数。

智能体能够处理相当复杂的任务，但它们的实现本身往往并不复杂。

从本质上说，它们通常只是一个 LLM：不断根据环境反馈调用工具，并在循环中继续行动。

因此，清晰、谨慎地设计工具集及其文档极其重要。我们会在附录 2“对工具进行提示工程”中进一步讨论工具开发的最佳实践。

什么时候适合使用智能体：

智能体适合那些开放式问题：你很难甚至不可能预先预测完成任务需要多少步骤，也无法用代码写死一条固定执行路径。

LLM 可能会连续运行很多轮，因此你必须对它的决策能力具备一定程度的信任。

智能体具有较高自治性，所以尤其适合在可信环境中大规模扩展任务执行能力。

但这种自治性也意味着更高成本，以及错误不断累积、放大的可能性。

因此，我们建议在沙箱环境中进行充分测试，并加入合适的安全护栏。

适合使用智能体的例子：

下面两个例子都来自我们自己的实现：

• 一个用于解决 SWE-bench 任务的编程智能体。此类任务通常要求根据任务描述修改多个文件；

• 我们的 “computer use（计算机使用）”参考实现，其中 会直接操作计算机来完成任务。

组合并定制这些模式

这些构建模块并不是强制规范。

它们只是开发者在实践中经常使用的一些常见模式，可以根据不同应用场景自由调整、组合。

和任何 LLM 功能一样，真正决定成败的关键是：测量性能，并持续迭代实现。

再强调一次：只有当增加复杂度能够被明确证明会改善结果时，你才应该这样做。

总结

在 LLM 领域，成功并不意味着你必须构建最复杂、最先进的系统，而是要构建最适合自己需求的系统。

先从简单提示词开始，通过全面评估不断优化；只有当简单方案确实不够用时，再引入多步骤智能体系统。

在实现智能体时，我们通常遵循三个核心原则：

1. 在智能体设计中保持简单；

2. 优先保证透明性，明确展示智能体的规划步骤；

3. 通过充分的工具文档与测试，认真设计智能体—计算机接口（Agent-Computer Interface，ACI）。

框架可以帮助你快速起步，但当系统逐渐进入生产阶段时，不要害怕减少抽象层，直接使用更基础的组件来构建。

遵循这些原则，你就能够构建出不仅强大，而且可靠、易维护，并能得到用户信任的智能体。