新智元报道
编辑：alan
【新智元导读】近日，Anthropic开发者关系主管发推表示：万事俱备，2025年将是智能体系统之年！在年终总结的博文中，Anthropic分享了一年来与客户合作构建智能体系统的最佳实践。
模型到应用之间的距离，就是烧钱与搞钱之间的距离。
这条路上，Agent已经身经百战，万事俱备。
在这个2024的结尾，Anthropic开发者关系主管Alex Albert表示：2025年将是智能体系统之年！
「各个部分正在就位，是时候开始考虑构建这些系统了。」
过去的一年里，Anthropic与数十个团队合作，构建了跨行业的大语言模型智能体系统。
实战表明，最成功的实现方式并不是使用复杂的框架或专用库，而是应用简单的可组合模式。
根据与客户合作的经验，Anthropic在年末总结的博文中分享了构建有效智能体系统的实用建议。
Agent系统最佳实践
智能体（Agent）可以有多种定义方式，比如将其视为完全自主的系统，可以在较长时间内独立运行，并使用各种工具完成复杂的任务。
这听起来很像另一个名词：工作流，但两者之间有着重要的架构区别：
工作流是通过预定义的代码路径来调用LLM和工具的系统； 而智能体则是LLM动态指导自己的流程和使用工具，控制完成任务方式的系统。
那么，什么时候使用智能体？什么时候使用工作流？
一个原则是：找到尽可能简单的解决方案，并且仅在需要时增加复杂性。
智能体系统通常会以延迟和成本为代价来获得更好的任务性能，开发者应当根据实际情况权衡，是否真的需要构建智能体系统。
当需要更高的复杂性时，工作流为定义明确的任务提供可预测性和一致性；当需要大规模的灵活性和模型驱动的决策时，智能体是更好的选择。
对于许多应用程序来说，使用检索和上下文来优化单个LLM调用通常就足够了。
何时使用框架
有许多现成的框架可以帮助构建智能体系统，比如：
LangChain的LangGraph； Amazon Bedrock的AI Agent框架 Rivet，拖放式GUI LLM工作流构建器； Vellum，用于构建和测试复杂工作流的GUI工具
框架简化了标准的低级任务（如调用LLM、定义和解析工具、将调用整合在一起），但通常会创建额外的抽象层。
这可能会掩盖底层提示和响应，使系统更难调试。但开发者有时会禁不住框架的诱惑而选择增加系统的复杂性。
Anthropic建议开发人员尽量直接使用LLM（许多功能只需几行代码就能搞定），如果确实需要使用框架，请确保先了解底层代码，——对框架实现原理的错误假设是错误的常见来源。
从0开始构建系统
生产中的常见模式，是从基础模块开始，逐步增加复杂性，从简单的组合工作流到自主智能体系统。
基础模块：增强型LLM
智能体系统的基本构建块是LLM，并通过检索、使用工具和记忆等功能进行了增强。
增强型LLM可以主动使用这些功能，生成自己的搜索查询、选择适当的工具并确定要保留的信息。
Anthropic建议在实施中关注两个关键方面：根据特定应用定制这些功能，以及确保为LLM提供简单且文档健全的接口。
比如Anthropic最近发布的Model Context Protocol，允许开发人员通过简单的客户端实现与各种第三方工具进行集成。
提示链（Prompt chaining）
提示链将任务分解为一系列步骤，每个LLM调用都会处理前一个调用的输出。可以在任何中间步骤中添加编程检查，以确保流程处于正轨。
这种工作流非常适合可以轻松将任务分解为固定子任务的情况（每个LLM负责一个简单的子任务）。
提示链应用场景：
生成市场营销策略，然后将其翻译成不同的语言。 编写文档的大纲，检查大纲是否满足特定条件，然后根据大纲编写文档。
路由（Routing）
路由对输入进行分类并将其定向到专门的后续任务，这个过程可以分离关注点，并构建更专业的提示。否则，针对一种输入进行优化可能会损害其他输入的性能。
路由适用于复杂任务，通过LLM或更传统的分类算法准确处理分类，对于不同类别的子任务，可以更好地单独处理。
路由应用场景：
将不同类型的客户服务查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具中。 将简单常见的问题路由到较小的模型（如Claude 3.5 Haiku），将困难的问题路由到功能更强大的模型（如Claude 3.5 Sonnet），以优化成本和速度。
并行化（Parallelization）
LLM有时并行处理一项任务，并以编程方式聚合其输出。并行化工作流有两种形式：
分段（Sectioning）：将任务分解可以为并行运行的独立子任务。 投票（Voting）：多次运行同一任务，获得不同的输出。
当已划分的子任务可以并行执行，或者需要多次推理以获得更高置信度的结果时，并行化非常有效。
对于需要考虑多个因素的复杂任务，让单独的LLM负责一个特定的方面，通常会提高系统的表现力。
并行化的应用场景：
一个模型实例处理用户查询，另一个模型实例筛选用户查询是否存在不适当的内容。这往往比使用相同的LLM同时处理安全校验和核心响应的性能要好。 自动评估LLM的性能：每个LLM调用都会评估模型在给定提示符下性能的不同方面。 检查一段代码是否存在漏洞，如果发现问题，则触发不同的提示来检查并标记代码。 评估给定的内容是否合适：多个提示用来评估不同的方面或使用不同的投票阈值来平衡误报和漏报。
Orchestrator-workers
在orchestrator-workers工作流中，中央LLM动态分解任务，将它们委托给worker LLM，并综合其结果。
这种工作流非常适合于无法预测所需子任务的复杂任务（比如编码中，需要更改的文件数以及每个文件中更改的内容取决于实际情况）。
orchestrator-workers与并行化在拓扑上相似，主要区别在于子任务不是预定义的，而是由orchestrator根据特定输入确定的。
应用场景：
每次对多个文件进行复杂更改的编码任务。 从多个来源收集和分析相关信息的搜索任务。
Evaluator-optimizer
在evaluator-optimizer工作流中，一个LLM调用生成响应，另一个LLM在循环中提供评估和反馈。
当开发者有明确的评估标准，且迭代过程能提供用于比较的值时，evaluator-optimizer工作流特别有效。
evaluator-optimizer应用场景：
文学翻译中，译者LLM最初可能无法捕捉到一些细节，但评估者LLM可以提供有用的批评反馈。 复杂的搜索任务中，需要多轮搜索和分析以收集全面的信息，评估者LLM决定是否需要进一步搜索。总结
智能体在生产中帮助理解复杂的输入、参与推理和规划、可靠地使用工具以及从错误中恢复。
执行过程中，智能体在每个步骤从环境中获取「基本事实」以评估其进度，也可以在检查点或遇到障碍时暂停以获得人工反馈。
智能体用于难以预测所需步骤数，以及无法对固定路径进行硬编码的开放式问题。LLM可能会运行多个回合，需要用户对其决策有一定程度的信任。
智能体的自主性意味着更高的成本，并且可能会使错误复杂化。作者建议在沙盒环境中进行广泛测试，并使用适当的防护机制。
LLM的成功应用并不是构建最复杂的系统，而是根据需求构建正确的系统。在应用智能体时，尽量遵循三个核心原则：
保持智能体设计的简单性； 明确显示智能体的规划步骤； 提供全面的工具文档和测试，作为智能体和计算机之间的接口
框架可以帮助快速入门，但面对生产环境时，不要犹豫，减少抽象层并使用基本组件进行构建。
参考资料：
https://www.anthropic.com/research/building-effective-agents