构建有效智能体：Anthropic 的实践总结与指南
人工智能的发展日新月异，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年的这些研究与实践，为智能体的构建提供了全面且深入的指导。从理论概念到实际应用，从构建模块到工作流程，再到实施原则和工具设计，都为人工智能领域的开发者和研究者提供了非常宝贵的参考与借鉴，有助于推动智能体技术在更多领域有效落地。
