人工智能的发展日新月异，Anthropic在2024年围绕智能体（Agents）的研究探索与工程实践，交出了一份极具分量的实战答卷。随着相关技术日趋成熟，构建智能体系统已成为当下人工智能应用的重要方向。通过广泛携手不同行业的团队，他们在大型语言模型（LLM）智能体的构建过程中积累了丰富的实战经验，并在官方博客中深入分享了关于如何“构建高效智能体”的深度思考与方法论。
一、智能体的定义与架构差异
对于“智能体”究竟为何物，不同的人心中或许有着截然不同的答案。有些客户认为，它应该是一个能够长期独立运转、灵活调用各类工具以完成复杂任务的“完全自主系统”；而在另一些客户看来，它更像是一个严格遵循预设流程、按部就班执行的规范性实现方案。Anthropic将这些概念统一归类为“Agent系统”，但其中存在一个核心分水岭：工作流是预先设定好代码逻辑路径，用于协调LLM与工具的系统；而智能体则是由LLM动态掌控自身流程与工具调用，自主决策如何完成任务。下文将围绕这两种类型的Agent系统展开详细探讨。
二、智能体的使用时机与考量
2.1 简单至上原则
当使用LLM构建应用程序时，一条朴素但屡试不爽的原则是：优先寻觅最简单的可行方案。在多数情况下，你完全无需构建一个Agent系统。因为Agent系统在提升任务性能的同时，往往不可避免地会牺牲响应速度并增加运行成本，因此必须审慎权衡其间的得失。
2.2 复杂任务应对策略
如果任务确实需要更高的复杂度，那么工作流能够为明确的任务提供稳定性和可预测性；而当任务规模庞大、需要高度灵活性以及模型自主决策能力时，智能体则是更为理想的选择。不过，对于绝大多数应用程序而言，通过优化检索策略或提供更精准的上下文示例来提升单次LLM调用的质量，往往已经足够应对需求。
2.3 框架的合理运用
当前市面上涌现出诸多框架，能够帮助开发者快速搭建智能体系统，例如LangChain的LangGraph、Amazon Bedrock的AI Agent框架、Rivet（一款拖放式GUI工作流构建器）以及Vellum等。这些框架极大地简化了调用LLM、定义和解析工具以及链接调用等基础操作，使得开发者能够快速上手。然而，它们也带来了一些隐患：额外的抽象层会让底层的提示与响应变得模糊不清，徒增调试的难度。更为重要的是，有时仅凭简单的设置便能满足需求，而这些框架反而可能诱使你过度设计。因此，Anthropic给出的建议直截了当：直接使用LLM API即可，许多模式仅用寥寥几行代码就能实现。假如非要使用框架，那务必深入理解其底层代码，否则很可能因为对底层机制的错误假设而陷入困境。
三、构建块、工作流与智能体详解
3.1 增强型LLM：构建基石
智能体系统的基础构建块，是经过功能增强的LLM，这意味着它必须具备检索能力、工具使用能力以及记忆功能。Anthropic当前的模型便能够主动运用这些能力，例如生成搜索查询、选择合适的工具并确定哪些信息需要保留以供后续使用。在具体实施时，有两个关键点值得特别关注：第一，应当根据具体用途来定制这些功能；第二，务必为LLM提供一个简洁且文档完备的接口。近期发布的模型上下文协议，就为开发者提供了通过统一客户端与不断扩展的第三方工具生态进行集成的便捷途径。在本文后续部分，我们默认每个LLM调用都具备上述这些增强功能。
3.2 工作流类型与应用场景
3.2.1 Prompt chaining
这种工作流将复杂任务拆解为一系列顺序执行的子步骤，每个LLM调用负责处理前一步的输出，中间还可以插入程序检查（例如“门”机制），以确保整个流程按预定计划顺利推进。它非常适合那些能够清晰拆分成固定子任务的场景。虽然会引入额外的延迟，但能够换来更高的准确性，因为每个LLM调用所处理的任务都变得更加简单明确。举例来说，先生成营销文案，再将其翻译成不同语言；或者先撰写文档大纲，检查大纲是否达到标准，然后根据大纲进一步撰写完整的文档。
3.2.2 路由
路由工作流首先对输入进行分类，然后将其引导至专门的后续处理任务。这能够有效分离关注点，从而构建出更具针对性的提示信息。倘若没有路由，针对某一类输入的优化很可能会对其他类型的处理效果产生负面影响。它尤其适用于存在不同类别、需要分别加以处理，并且能够通过LLM或传统分类模型进行准确分类的复杂任务。例如，将不同类型的客户服务咨询（如一般问题、退款请求、技术支持）引导至不同的下游流程和工具；或者根据问题的难度级别，将简单的问题路由到较小的模型（如Claude 3.5 Haiku），把困难的问题交由更强大的模型（如Claude 3.5 Sonnet）处理，从而在成本和速度之间实现优化平衡。
3.2.3 并行化
LLM有时可以同时处理一项任务的不同方面，最后通过编程方式汇总所有输出结果。它主要有两种形式：分段（将任务分解成并行运行的独立子任务）和投票（多次运行相同任务以获取不同输出）。当子任务能够并行执行以提升速度，或者需要从多个视角进行考量、多次尝试以获得更可靠的结果时，并行化是一种非常高效的策略。例如，在实施安全防护措施时，可以让一个模型实例处理用户查询，同时让另一个模型实例专门负责筛选不当内容，这通常比让同一个LLM同时处理这两件事效果更佳。在自动评估LLM性能时，每个LLM调用可以分别评估模型的不同方面；在审查代码漏洞时，使用多个不同的提示可以从不同角度发现问题；在评估内容是否恰当时，也可以设置不同的投票阈值来平衡误报和漏报的风险。
3.2.4 Orchestrator-workers
在这种工作流模式中，有一个中央LLM（称为编排器）负责动态地分解任务，将其分配给多个worker LLM，然后汇总它们的结果。它特别适合那些无法预先确定子任务的复杂场景，比如编码时，每次需要修改哪些文件、每个文件需要修改什么内容，都可能因具体任务而异。虽然它在拓扑结构上看起来与并行化颇为相似，但关键的区别在于其灵活性：子任务并非事先固定好的，而是由编排器根据具体的输入内容动态决定。例如，每次都需要对多个文件进行复杂修改的编码产品，或者需要从多个来源收集并整合分析信息的搜索任务，都是这类工作流的典型应用场景。
3.2.5 评估器 - 优化器
在这个工作流中，一个LLM负责生成响应，另一个LLM则在循环中提供评估和反馈意见。当存在明确的评估标准，并且通过迭代改进能够带来显著价值时，这种模式非常有效。有两个标志可以帮助判断是否适合采用此模式：第一，当人类给出反馈时，LLM的响应质量能够得到明显改善；第二，LLM本身能够提供富有价值的反馈意见。这很像人类作家在创作高质量文档时所经历的迭代写作过程。例如，在文学翻译任务中，负责翻译的LLM最初可能无法准确把握某些细微的差别，但负责评估的LLM可以给出有价值的批评意见；在复杂的搜索任务中，可能需要进行多轮搜索和分析才能收集到全面的信息，最后由评估者决定是否还需要继续深入搜索。
四、智能体的特性与应用
随着LLM在理解复杂输入、进行推理规划、可靠地使用工具以及从错误中恢复等关键能力上取得持续进步，智能体已经逐步投入实际生产环境。智能体通常以接收人类用户的指令或参与互动讨论为起点，待任务明确之后，它便能够独立地进行规划和执行操作，在此过程中也可能向人类请求更多的信息或寻求判断。在执行任务时，智能体必须从每个步骤的环境中获得“真实反馈”（例如工具调用的结果或代码的执行输出）来评估自身进度，也可以在检查点或遇到阻碍时暂停下来，等待人类的反馈。任务一般在完成之后结束，但通常也会设置一些停止条件（比如最大迭代次数）以确保整个过程的可控性。
尽管智能体能够处理复杂的任务，但其实现方式通常颇为简洁，本质上就是基于环境反馈循环来使用工具的LLM。因此，一套清晰且精心设计的工具集连同其完善的文档至关重要。智能体尤其适用于那些开放式的问题，也就是难以预测具体步骤数量、无法通过硬编码固定执行路径的场景。在这些情况下，LLM可能需要进行多次运行，开发者也必须对其所做的决策抱有足够的信任。智能体的自主性使其在受信任的环境中成为扩展任务的理想选择，但同时也不可避免地带来了更高的成本和出现复合错误的风险。因此，强烈建议在沙盒环境中进行广泛的测试，并设置好适当的防护措施。例如，Anthropic自己实现的编码智能体，能够根据任务描述解决SWE-bench任务中涉及多个文件的编辑问题；此外，还有那套让Claude使用计算机完成任务的“计算机使用”参考实现，都是很好的实践案例。
说明
上文提到的这些构建块，并非一成不变的规则，而是开发者可以根据不同用例灵活搭配、自由组合的常见模式。与所有LLM功能一样，成功的关键在于持续衡量性能并不断迭代优化。再次强调：只有当复杂性的增加能够显著改善最终结果时，才值得去引入它。
五、实施智能体的核心原则
5.1 保持设计简洁性
尽量不让设计变得过于复杂，确保智能体的整体架构和各项功能都易于理解、便于维护。
5.2 确保透明度
通过清晰地展示智能体的规划步骤和决策依据，让用户和开发者都能轻松理解它的思考与行动过程。
5.3 精心打造接口
借助全面的工具文档和严格的测试流程，用心设计智能体与计算机之间的接口（ACI），确保交互过程顺畅无阻、稳定可靠。
框架在项目早期有助于快速启动，但一旦进入生产阶段，就不要再犹豫不决，应果断减少不必要的抽象层，直接使用基本组件来构建系统。这样才能对系统的性能和稳定性拥有更充分的掌控。遵循这些原则，开发者可以创建出不仅功能强大，而且稳定可靠、易于维护且令人放心的智能体。
六、附录
6.1 实践中的智能体应用
6.1.1 客户支持
借助工具集成，客户支持系统能够将常规的聊天机器人界面与丰富的增强功能深度融合，非常适合向更为开放的智能体应用方向发展。这是因为支持交互天然遵循对话流程，同时又需要访问外部信息和执行具体操作。可以集成多种工具来提取客户数据、订单历史记录和知识库文章；像处理退款或更新订单这类操作也能通过编程方式实现；而且成功与否可以通过用户定义的解决标准来清晰衡量。不少公司已经通过基于使用量的定价模式验证了这种方法的可行性，这种模式只对成功解决的问题收费，这本身就体现了对其智能体效率的充分自信。
6.1.2 编码智能体
在软件开发领域，LLM已经从简单的代码补全发展到了自主解决问题的能力，智能体在其中扮演了至关重要的角色。编码智能体之所以特别有效，原因在于：代码解决方案可以通过自动化测试来验证正确性；智能体能够利用测试结果作为反馈信号进行迭代改进；整个问题空间定义明确且结构清晰；输出的质量也能够得到客观的衡量。在Anthropic的实际应用中，智能体现在已经能够仅根据拉取请求的描述，来解决SWE-bench Verified基准测试中的真实GitHub问题。不过，尽管自动化测试有助于验证功能逻辑，但人工审核对于确保最终解决方案符合更广泛的系统设计要求，仍然是不可或缺的一环。
6.2 工具设计优化要点
无论构建何种类型的智能体系统，工具都是其核心组成部分。通过在API中明确指定外部服务和API的确切结构与定义，工具让Claude能够与它们顺畅交互。当Claude生成响应时，如果它计划调用某个工具，会在API响应中包含一个“工具使用”块。工具的定义和规范，应当像对待整体提示那样，给予同等的重视和精心的工程打磨。
通常，完成同一个操作可以有多种不同的方式。例如，文件编辑既可以通过编写差异（diff）来实现，也可以通过重写整个文件来完成；对于结构化输出，既可以使用markdown格式，也可以使用JSON格式来返回代码。在软件工程领域，这些格式之间的差异或许并不重要，甚至可以无损转换。但对于LLM而言，某些格式写起来会相当费劲。比如，编写diff需要你在写新代码之前，先弄清楚块头中包含多少行发生了变化；而使用JSON格式编写代码，相比markdown，还需要额外对换行符和引号进行转义处理。
Anthropic就如何决定工具格式，给出了以下几点实用建议：
- 在模型遇到性能瓶颈之前，给予它足够且充分的“思考”空间。
- 尽量让工具格式接近模型在互联网文本中自然遇到的常见格式。
- 尽量避免格式上的“开销”，例如精确计数数千行代码，或者对你编写的代码进行不必要的字符串转义操作。
一个值得借鉴的经验法则是：想想你在人机界面（HCI）设计上投入了多少精力，那么在创建一个良好的智能体-计算机界面（ACI）时，也应该投入同样多的精力。具体可以这样做：从模型的角度去思考，仅凭描述和参数，它能否清楚地理解工具应该如何被使用；优化参数的名称和描述，让它们更加清晰直观，就像为团队里的初级开发人员撰写一份优秀的文档字符串一样；在工作台中用大量的示例输入进行测试，观察模型使用工具的具体情况，一旦发现问题就立即迭代改进；采用防错法设计，调整参数以从源头上减少错误发生的可能性。举个例子，在构建SWE-bench智能体时，Anthropic在优化工具上所花费的时间，实际上比优化整体提示还要多。他们发现，当智能体移出根目录后，如果工具使用的是相对文件路径，模型就容易出错。后来他们果断将工具修改为始终要求使用绝对文件路径，模型便能够完美地运用这个方法来完成任务了。
Anthropic在2024年的这些研究探索与工程实践，为智能体的构建设立了一套全面且深入的实践指南。从理论概念到实际应用，从构建模块到工作流程，再到实施原则和工具设计，都为人工智能领域的开发者和研究者提供了非常宝贵的参考与借鉴经验，有助于推动智能体技术在更多领域实现有效落地。