Anthropic、LangChain发来年终汇报！2024人工智能应用全景报告！如何构建有效的Agent和Workflow

Anthropic总结了2024年一些最佳实践，并分享了“如何构建有效的智能体(Building effective agents)”接下来这篇文章将跟大家分享 Anthropic 从与客户共建 agents 的过程中学到的经验，并为开发者们提供如何构建有价值的 agents 的相关建议。

一致的是，最成功的实现并不是使用复杂的框架或专门的库。相反，它们是通过简单、可组合的模式构建的。

原文链接：

https://www.anthropic.com/research/building-effective-agents

一种是将代理定义为完全自主的系统，这些系统可以在较长时间内独立运行，使用各种工具完成复杂任务。另一种“代理”则是用来描述更规范的实施，这些实施遵循预定义的工作流程。Anthropic将所有这些变体归类为代理系统，但在工作流程和代理之间划出了一个重要的架构区别：

工作流程是通过预定义的代码路径协调LLMs和工具的系统。

另一方面，代理是LLMs动态指导自己的流程和工具使用，保持对如何完成任务的控制。

“代理”可以有多种定义，既可以是使用各种工具来完成复杂的任务的，能够长期独立运行且完全自主的系统，也可以是符合规范性的并遵循预定义的工作流。Anthropic将所有这些不同的形式都归类为 agentic systems(智能系统)，但在 workflows(工作流)和 agents(智能体)之间做出了一个重要的架构区分：

Workflows 是通过预先定义好的代码路径来编排大模型和工具的系统。

Agents 是由大模型动态规划自身处理流程和工具使用，并能够自主控制如何完成任务的系统。

划重点：对于多数场景来说，优化单个LLM调用并使用检索和上下文示例通常就足够了，越简单越好

有的时候根本不需要构建代理系统，要想清楚。因为往往代理系统需要以延迟和成本为代价来换取更好的任务性能，到底有没有必要和意义要仔细衡量。

什么时候用Workflows，什么时候用Agents：

当任务不可避免的需要更多复杂的方式实现时，Workflows工作流程为定义明确的任务提供了便利

当需要灵活性和大规模的模型驱动决策时，更适合选择Agents。

有许多框架可以用来方便的实现智能代理，包括：

• LangChain的LangGraph；

• 亚马逊Bedrock的AI代理框架；

• Rivet，一个拖放式GUI LLM工作流构建器；

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

这些框架通过简化标准任务——如调用LLMs、定义和解析工具以及链接调用等，使得构建过程变得容易。但是也会因为创建额外的抽象层而隐藏掉底层的 Prompt 和响应内容，使得调试很费劲(亲身体验过!)。另外这些框架还也会让开发者在一些本可以用更简单方案解决的场景中不自觉地引入不必要的过度设计。

Anthropic的建议是，开发人员从直接使用 LLM API 开始，因为通常只需几行代码即可实现许多常用的模式。如果确实想要使用框架，你得有对底层的代码足够的了解，因为通常是对底层设计的错误的假设和理解最容易导致错误的出现。

可以参阅Anthropic 官方手册

https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents了解一些示例实现。

接下来聊下Anthropic生产中常见的agentic systems模式。从基础构建模块——增强型大模型(augmented LLM)开始，逐步提升复杂度，从简单的组合工作流到自主的 agents 系统。

智能体系统的核心构成是增强型 LLM，它具备检索、工具运用和记忆等功能。我们的模型能够主动运用这些功能，进行搜索查询的生成、选择适宜的工具以及决定如何筛选信息。

进行智能体的设计和实现时要重点关注以下两大方面：

1. 个性化定制：根据您的特定应用场景来定制这些功能。

2. 用户体验：为 LLM 提供一个简洁且文档齐全的接口。

实现途径就很多了，比如Anthropic 最近发布的模型上下文协议(MCP，Model Context Protocol)，通过简单的 client implementation，开发者可以借助该协议接入各种第三方工具生态。小纸条之前也给大家分享过：

MCP：

https://www.anthropic.com/news/model-context-protocol 

对于下文内容，我们预设每个 LLM 都可以默认使用这些增强功能。

提示链通过将任务细分为一连串的步骤来实现，每个 LLM 调用都基于前一个步骤的输出进行操作。还可以在任何中间节点步骤插入编程验证(图中的“gate”)，以此来确保流程的正确执行。

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

当任务能够被明确划分为若干个子任务时，就会比较适合使用这种提示链的方式。我们要明白工作流的主要目的是通过简化单个 LLM 调用的任务，以时间上的投入换取结果的精确度。

典型场景：

• 生成市场营销文案，然后将其翻译成不同语言。

• 先制定文档大纲，然后检验该大纲是否满足特定标准，最后依照大纲完成文档的撰写。

这类工作流的思路是根据输入来路由后续的步骤。这种方法可以有效地实现关注点的分离，并构建更为精确的提示词。不然的话我们针对某中特定输入的优化可能会反而会造成另一种情况的表现受影响。

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

一些由明确的子任务组成的，且针对不同子任务适合分别来处理的场景，更适合这种路由的工作流方式，同时针对不同的子任务可以通过 LLM 或更传统的分类模型/算法进行准确处理。

典型场景：

• 需要为用户不同的服务请求分配不同的处理流程、提示词prompts或者工具

• 需要根据不同难度的问题指定不同模型来控制成本和响应效率的情况，比如简单的问题就让Claude 3.5 Haiku 回答，难一点的就让Claude 3.5 Sonnet冲

大语言模型(LLM)有时能够同时处理一个任务，并通过编程手段合并其结果。并行化工作流程主要有两种拆分方式：

任务拆解：讲一个任务拆分成互相独立可并行执行的子任务

投票：将同一个任务多次执行以获得不一样的输出

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

• 当通过子任务拆分并行可以提升处理速度，或者需要从多个视角尝试来获得更高质量的结果时，并行是个好办法。

• 对于具有多重考虑的复杂任务，通常把每个要考虑的因素都通过单独的 LLM 调用进行处理时，LLM 的表现更佳。

典型场景：

1. 分块处理：

• 在实施安全防护时，一个模型实例负责处理用户查询，而另一个实例则负责筛选不当内容或请求。这种方法通常比让单个 LLM 调用同时处理安全监测和核心响应更有效。

• 自动化评估，用于评估 LLM 在特定 Prompt 下的表现，每个 LLM 用于评估模型表现的不同方面。

1. 多选投票：

• 审查代码是否存在安全漏洞，通过多个不同的Prompt提示词对代码进行多角度审查。

• 评估内容是否不当，其中多个Prompt提示词从不同角度进行评估，或设置不同的投票阈值，以平衡误报和漏报的风险。

在协调器-工作者(Coordinator-Worker)工作流程中，一个中央 LLM 动态地将任务拆分，并将这些子任务分配给工作者 LLM，随后整合它们的输出结果。

虽然它的流程图跟并行工作流很像，但关键区别在于其更灵活——子任务不是预先定义的，而是由 Orchestrator 根据特定输入确定的。

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

• 这种工作流程适用于那些子任务无法预先确定的复杂任务（例如，在写代码的过程中，需要更改的文件数量和每个文件内部的更改都是不确定的）。

典型场景：

• 在编程项目中，每次都需要对多个文件进行复杂修改的产品开发。

• 搜索任务，涉及从多个来源搜集和分析信息，以提取可能相关的信息。

在这种评估优化的工作流程中，一个 LLM 负责生成响应，而另一个 LLM 提供评估和反馈，形成循环。

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

这种工作流程在存在明确评估标准且迭代改进能够带来可量化价值的情况下极为有效。两个关键适用条件是：一是 LLM 的响应能够通过人类反馈显著提升；二是 LLM 能够提供此类反馈。这类似于人类作者在编辑和润色文档时所经历的迭代写作过程。

典型场景：

• 文学翻译，其中翻译 LLM 可能最初无法捕捉到的细微差别，但负责评估的 LLM 可以提供有用的改善建议。

• 需要多轮搜索和分析以收集全面信息的复杂搜索任务，负责评估的 LLM 决定是否需要进一步搜索。

随着大语言模型(LLM)在理解复杂输入、推理与规划、工具的可靠使用以及错误恢复等关键技能方面的日逐渐完善，AI Agent 智能体也正在生产环境中被更多的使用。

Agents 的工作始于来自用户的命令或互动讨论。一旦任务明确，agents 就可以独立规划和行动，其中可能会反问人类，以获取进一步的信息或判断。在执行任务过程中，agents 在每一步(如工具调用或代码执行)获得环境的 "ground truth"(“真实情况”)来评估任务进展至关重要。因此，agents 可以在遇到障碍时暂停，以获取人类的反馈。任务通常在完成时终止，但也常常包括停止条件(如最大迭代次数)以保持控制。

agents 可以处理复杂任务，但它们的实现往往很直接，因为它们也就只是基于环境反馈循环使用工具的 LLM。因此设计清晰且全面的工具集及其文档至关重要。

什么时候使用Agents：

Agent适用于那些对于回答步骤很难或者根本无法预测的开放式问题，或者是没办法通过编码明确实现的。LLM 可能需要多次运行，因此需要对它的决策有一定的信任。AI Agent 智能体的自主性使其非常适合在受信任的环境中扩展任务。

Agent的自主决策能力也同时意味着更高的成本和错误累积的风险，建议在沙箱环境充分测试，并结合一些对输出内容安全性的控制。

典型场景：

•  解决 SWE-bench（一个 AI 评估基准，用于评估模型完成软件工程的能力）的编程 agents，该项目涉及根据任务的描述对多个文件进行编辑

SWE-bench：https://www.anthropic.com/research/swe-bench-sonnet

• Anthropic推出了名为“Computer Use”的AI Agent，这是一个能够指导Claude完成各种计算机操作任务的AI Agent。这些任务包括查看屏幕内容、移动光标、点击按钮以及打字等。开发者可以通过这个API将书面指令转换为具体的计算机指令，从而实现自动化任务

https://github.com/anthropics/anthropic-quickstarts/tree/main/computer-use-demo

这些架构构建模块并非一成不变。它允许开发者根据不同业务场景进行组合和调整。与任何 LLM 功能一样，成功的关键在于性能的把控和不断的迭代实现。一定要记住：只有再能够显著改善结果时，才考虑增加复杂度。

在大模型领域落地成功并不在于构建最复杂的系统，而在于为需求构建合适的系统。从简单的 Prompt 开始，通过对结果的评估进行优化，非必要不增加复杂的步骤。

在实施 AI Agent 智能体时，记住以下三个核心原则：

1. 保持 AI Agent 智能体设计的简洁性;

2. 通过清晰地展示 AI Agent 智能体的规划步骤来优先考虑透明度;

3. 通过全面的工具文档和测试精心设计你的 AI Agent 智能体-计算机接口agent-computer interface(ACI)。

Anthropic也分享了两个与客户的合作过程的有前景有价值的agents应用，这两个应用都表明了agents在与人类对话和行动有关的任务中的重大价值，我们也可以参考这些Agents放大价值的场景的共性，作为我们选择场景解决方案的标准。

A.客户支持（Customer support）

客户支持累场景通过工具集成将熟悉的聊天机器人界面与增强的功能结合起来。该场景适用于开放式 agents 的原因有：

1. 遵循对话流程，交互自然，同时需要访问外部的信息和执行动作；

2. 可以集成工具以提取客户数据、订单历史和知识库文章；

3. 如退款或更新工单等操作可以用增加代码节点的方式处理；

4. 可以通过用户预先定义的理想解决效果，明确衡量是否 agents 解决了该问题。

有几家公司通过基于使用量的定价模型证明了这种方法的可行性，该模型仅对成功的解决方案收费，也表现出了对其 agents输出有效性的信心。

B. 编程辅助（Coding agents）

软件开发领域显示出 LLM 的显著潜力，功能从代码补全演变为自主解决问题。该场景适用于agents 的原因有：

1. 代码问题的解决可以通过自动化测试进行验证；

2. 代理可以使用测试结果作为反馈，对流程方案进行迭代；

3. 问题定义明确且结构化；

4. 输出质量可以客观测量。

工具的重要性：在我们的Agent系统中，工具是非常重要的组成部分，要学会利用它们与外部世界进行交互。

工具定义：需要精确地定义这些工具的结构和规则，这样Agent才知道如何使用它们。

多种格式：完成同一个任务可能有多种方法。例如，编辑文件可以通过写一个差异文件（diff）或者重写整个文件来完成。在输出结构化数据时，可以选择用markdown格式或者JSON格式。

格式的难易度：有些格式对于Agent系统来说更难生成。比如，生成差异文件需要知道有多少行代码在变化；在JSON中写代码需要对换行符和引号进行额外的转义。

选择工具格式的建议：

• 给模型足够的“思考”空间，避免它一开始就陷入困境。

• 保持格式接近模型在互联网上自然看到的形式。

• 避免不必要的格式“负担”，比如不需要精确计算大量代码行数，或者对它生成的代码进行字符串转义。

设计原则：在设计人机交互界面（HCI）时投入多少努力，就应该在设计智能系统与计算机交互界面（ACI）时投入同样的努力。

工具定义的考虑：

• 站在模型的角度思考，工具的使用是否明显，还是需要仔细考虑？如果是后者，模型可能也会遇到同样的困难。一个好的工具定义通常包括示例用法、边缘情况、输入格式要求和与其他工具的明确界限。

• 如何改变参数名称或描述以使事情更清晰？这就像是为你团队中的初级开发人员编写优秀的文档字符串。当使用许多类似的工具时，这一点尤其重要。

• 测试模型如何使用你的工具：在工作台上运行许多示例输入，看看模型犯了哪些错误，并进行迭代。

• 对工具的输入进行边界值测试：避免参数输入导致出错。

美国人工智能公司LangChain日前发布了State of AI Report 2024-《2024年人工智能全景报告》。LangChain团队已连续七年发布当年的《人工智能全景报告》，成为人工智能行业流行的风向标。在今年的报告中，通过深入探究大模型应用开发平台LangSmith产品的使用模式(LangSmith 是 LangChain 的一个 all-in-one 的 LLM 应用开发平台，在今年每个月都有近三万用户注册使用 LangSmith.)，LangChain团队揭示出人工智能生态系统以及人们构建大型语言模型应用的方式是如何演变的。

其中包括：开源模型的使用率急剧上升，从以用于检索的工作流为主，向包含多步骤的Agentic workflow工作流的智能体应用Agent模式转变。

原文链接：https://blog.langchain.dev/langchain-state-of-ai-2024/

根据LangSmith的使用分析情况统计，OpenAI在LangSmith用户群中同去年一样稳居第一大语言模型供应商宝座，使用率是排名第二的Ollama的六倍以上。

榜单中侧重于本地运行的Ollama和专注于云端部署的Groq都支持用户运行开源模型，在今年的增长势头迅猛，分别获得第2和第5的好名次。可以看出来市场对于更加灵活的部署选择和个性化人工智能基础设施的日益增长的需求。

在提供开源模型的提供商方面，顶级提供商与去年相比保持相对一致 - Ollama、Mistral 和 Hugging Face 使开发人员可以轻松地在其平台上运行开源模型。

对排名前三向量数据库与去年相同，Chroma 和 FAISS 是最受欢迎的选择。2024 年，Milvus、MongoDB 和 Elastic 的向量数据库也进入了前十名。

随着开发人员在利用生成式AI方面越来越多的经验，日益复杂的应用程序正在被构建。像是上面Anthropic报告中说的，从工作流程越来越多的模式，到人工智能代理的兴起，下面的图是今年开发上的一些趋势，这些趋势也表明创新生态系统正在不断发展。

(一)可观测性不仅限于LangChain应用程序

开源框架LangChain虽然是众多开发者构建大语言模型应用的首选，但根据LangSmith今年的追踪数据，有15.7%的追踪来自非LangChain框架。

可观测性是指能够监测和分析软件系统的状态，以便了解其运行情况并进行故障排除。这段话指出，不仅仅是使用LangChain的应用程序需要这种能力。

有15.7%的追踪数据来自不是基于LangChain构建的应用程序，表明其他框架也在被广泛使用。无论开发者选择哪种框架来构建他们的应用程序，他们都需要能够监控和理解这些应用程序的运行情况。LangSmith通过支持不同框架间的互操作性，满足了这一需求。

(二)Python继续占据主导地位，JavaScript使用率稳步上升

调试、测试和监控在 Python 开发者心中占有特殊地位，84.7% 的使用量来自 Python SDK。但是，随着开发者们对 Web 应用开发的追求，大家对 JavaScript 的兴趣也在显著增加，JavaScript SDK 今年占 LangSmith 使用量的 15.3%，比上一年增加了 3 倍。

(三)AI agents智能体正逐渐受到关注

LangChain发布的可控智能体框架LangGraph，自2024年3月发布以来，受欢迎程度稳步增长—现在有43%的使用LangSmith平台的组织正在发送LangGraph追踪数据。这些追踪数据代表了复杂、协调的任务，超越了基本的大语言模型互动。

这一增长与智能体行为的增加相一致。LangChain团队发现，平均有21.9%的追踪现在涉及工具调用，而2023年的平均值仅为0.5%。

工具调用允许模型自主调用函数或外部资源，增强智能体与外部系统交互的能力，标志着更多的智能体行为，即模型决定何时采取行动。

在应用程序开发领域，尤其是在利用大语言模型资源的应用中，实现速度与复杂性的平衡是一个核心挑战。LangChain分析了组织如何与应用程序交互，以平衡应用的复杂度与

LangChain团队追踪到智能体应用中的独立操作步骤从2023年的2.8步上升至2024年的7.7步，包括对大语言模型、检索器或工具的调用。这一增长趋势说明了组织正在采用更加复杂和多维的工作流程。用户所构建的系统已经超越了简单的问答交互，转而将多个任务串联起来，如信息检索、信息处理以及产出可执行的结果。

而在统计中，大语言模型的平均调用次数增长缺没有明显提高，只是从1.1次增至1.4次。这表明开发者在系统设计中，努力以较少的 LLM 调用实现更多的功能，在达成功能的同时控制昂贵的 LLM 成本。

虽然维持大语言模型应用的高标准质量是一项艰巨任务，但调查发现组织正利用LangSmith的评估工具来自动化测试流程，构建用户反馈机制，开发出更加稳健和可靠的应用程序。

用 LLM 评估时，开发者首先在 Prompt 里写评分规则注入 LLM，然后 LLM 按照定义的规则来判断输出是否符合标准并进行评分。开发者测试最多的维度为：Relevance(相关性), Correctness(正确性), Exact Match(精确匹配度), Helpfulness(有用性)。

这表明大多数开发者都在对 LLM 的响应质量进行一些检查，以确保人工智能生成的内容不会严重偏离预期目标。

在构建大语言模型应用的过程中，人类反馈扮演着至关重要的角色。LangSmith通过加速收集和整合人类反馈至追踪和执行过程中(即执行跨度)，帮助用户构建出更丰富的数据集，以便于改进和优化应用。在过去一年里，标注的执行次数增长了18倍，这一增长与LangSmith使用量的增加成正比。

尽管每次执行的反馈数量从2.28条上升到2.59条，显示出轻微的增长，但相对于每次执行来说，反馈量仍然较少。这可能意味着用户在审查执行时更倾向于追求速度，而不是提供详尽的反馈，或者他们可能只针对那些最关键或存在问题的执行提供评论。

对于构建 LLM 应用来说，人类反馈是迭代循环的关键部分。

LangSmith通过加速收集和整合人类反馈至追踪和执行过程中(即执行跨度)，帮助用户构建出更丰富的数据集，以便于改进和优化应用。在过去一年中，带有注释的运行增长了 18 倍，与 LangSmith 使用量的增长成线性关系。

尽管每次执行的反馈数量从2.28条上升到2.59条，但每次运行的反馈仍然相对不算很多。开发者会优先考虑核查运行的速度，而不是提供全面的运行反馈，或者只对需要关注的最关键或最有问题的运行进行评价。

总结一下2024年开发者在构建大语言模型应用时的共性趋势：

1.更加倾向于采用多步骤智能体来增加应用的复杂性

2.通过减少大语言模型的调用次数来提升效率

3.引入质量检查机制，通过反馈和评估方法来确保输出结果的质量。

好啦，2024年Anthropic和LangChain的总结报告内容就是这些，要说最大的一个感悟，那就是一切从场景出发，非必要不复杂。另外还有一个，就是动手做起来!因为在日常支持场景开发任务时变着法儿的设计和改进工作流的经验，在看Anthropic报告中说的几种模式时惊奇的发现其实自己在落地Agent的过程中其实都有用到过，而经过自己实际摸索过后再看到专业的对于这些模式适用场景的整理，也会更有条理理解的更加深刻。所以朋友们，有时候混乱的时候也不要放弃，搞清楚任何事情仿佛都有该花的时间，就像是大模型学习训练也需要“量”的积累引起“质”的变化吧，给自己一些耐心等开悟，但也不要盲目努力哦!人生处处是平衡，共勉❤️