Agent系统架构设计：Anthropic大道至简原则与实践，零基础小白收藏这一篇就够了！！-优快云博客

前言

日前，Anthropic 刊载了一篇如何高效构建 Agent 系统的博客文章，文章分享了他们在构建 Agent 过程中总结的经验，通篇文章散发着架构设计的通用原则，”强调“大道至简”的重要性，越简单越成功。

什么是 Agent？

Agent 并非一个标准概念，它可以是完全自主的系统，也可以是遵循预定工作流的系统。Anthropic 将这些变体统称为"Agent 系统"，并将其在实现架构上划分为两类：

工作流（Workflow）：通过预定义的代码路径编排 LLM 和工具
智能体（Agent）：LLM 动态指导自身流程和工具使用，保持对任务完成方式的控制

保持简单

Anthropic 一直强调，不应过度追求复杂的系统架构。开发者应首选最简单的解决方案，仅在确实需要时增加系统复杂度。同时指出，虽然很多 Agent 框架，如langchain等，内置了 Agent 的一些架构模式能够简化入门过程，但是同时也会带来复杂性，导致难以维护。他们建议开发者应直接使用底层 LLM接口实现，可以参考示例[1]来实现。许多模式可以用几行代码实现，并不是很复杂。如果到真有必要使用框架时，也应该确保理解底层代码，避免错误假设。

Agent 系统构建的范式

Anthropic 总结了在生产中常见的架构模式，在“增强 LLM”基本模块开始，一步步增加复杂性，从简单的组合工作流演变到自主 Agent。

基础元件：增强型 LLM

Agent 系统的基本模块是经过增强的 LLM，如检索、工具和记忆。我们的当前模型可以主动使用这些能力——生成自己的搜索查询、选择适当的工具并确定保留哪些信息。

在实现上，需要根据具体场景定制这些能力，并确保它们为 LLM 提供易于使用的、文档齐全的接口，以便 LLM 正确调用。对于接口集成 Anthropic 建议使用他们发布的模型上下文协议（Model Context Protocol,MCP），它允许开发者通过简单的客户端实现与不断增长的第三方工具生态系统集成。

下面是基于增强 LLM 基本模块的一些常见架构范式。

工作流：提示链（Prompt Chaining）：将任务分解为固定子任务序列

提示链将任务分解为一系列步骤，每个 LLM 调用处理前一个的输出。您可以在任何中间步骤添加程序化检查（见下图中的“gate”）以确保过程仍在正轨。

该模式适用于任务可以轻松且清晰地分解为固定子任务的情况。主要目标是通过对每个 LLM 分解调用执行更简单的任务，以延迟换取更高的准确性。

示例场景：

生成营销文案，然后将其翻译成另一种语言。
编写文档大纲，检查大纲是否符合某些标准，然后根据大纲编写文档。

工作流：路由（Routing）：根据输入类型分类处理

路由对输入进行分类，并将其定向到专门的后续任务。此工作流程允许分离关注点，并构建更适应具体子任务的提示。没有此工作流程，优化一种输入可能会损害其他输入的性能。

该模式适用于复杂任务，其中存在最好分别处理的明显类别，并且分类可以由 LLM 或更传统的分类模型/算法准确处理。

示例场景：

将不同类型的客户服务查询（一般问题、退款请求、技术支持）定向到不同的下游流程、提示和工具。
将简单/常见问题路由到较小的模型（如 Claude 3.5 Haiku），将困难/不常见问题路由到更强大的模型（如 Claude 3.5 Sonnet），以优化成本和速度。

工作流：并行化（Parallelization）：同时处理多个子任务

LLM 有时可以同时处理任务，并程序化地聚合其输出。此工作流程，并行化，表现为两种关键变体：

分段（Sectioning）：将任务分解为独立子任务并行运行。
投票（Voting）：多次运行同一任务以获得多样化的输出。

该模式在当分割的子任务可以并行化以提高速度，或当需要多个视角或尝试以获得更高置信度结果时有效。对于具有多个考虑因素的复杂任务，LLM 通常在单独的 LLM 调用处理每个特定方面时表现更好，从而能够专注于每个具体方面。

示例：

分段：

在一个模型实例处理用户查询的同时，另一个模型实例对其进行不当内容或请求的筛查。这种方法通常比让同一个 LLM 调用同时处理防护栏和核心响应要好。

自动化评估以评估 LLM 性能，其中每个 LLM 调用评估模型在给定提示上的不同性能方面。
投票：

审查代码漏洞，其中几个不同的提示审查并标记代码问题。评估给定内容是否不当，多个提示评估不同方面或需要不同的投票阈值以平衡假阳性和假阴性。

工作流：编排者-工作者（Orchestrator-workers）：动态分解和委派任务

在编排者-工作者工作流中，一个中央 LLM 动态分解任务，将其委托给工作者 LLM，并综合其结果。

该模式适用于复杂任务，其中无法预测所需的子任务（例如，在编码中，需要更改的文件数量和每个文件中更改的性质可能取决于任务）。虽然拓扑上相似，但与并行化的关键区别在于其灵活性——子任务不是预定义的，而是由编排者根据具体输入确定的。

示例场景：

编码产品，每次对多个文件进行复杂更改。
搜索任务，涉及从多个来源收集和分析可能相关信息。

工作流：评估者-优化者（通过反馈循环不断改进输出）

在评估者-优化者工作流中，一个 LLM 调用生成响应，而另一个提供评估和反馈循环。

该场景适合当有明确的评估标准，且迭代改进能提供可衡量的价值时特别有效。两个良好匹配的迹象是，首先，当人类明确反馈时，LLM 响应可以显著改进；其次，LLM 可以提供此类反馈。这类似于人类作家在生成精炼文档时可能经历的迭代写作过程。

示例场景：

文学翻译，其中翻译 LLM 可能最初无法捕捉到细微差别，但评估 LLM 可以提供有用的批评。
复杂搜索任务，需要多轮搜索和分析以收集全面信息，其中评估者决定是否需要进行进一步搜索。

Agent

随着 LLM 在关键能力上的成熟——理解复杂输入、进行推理和规划、可靠地使用工具以及从错误中恢复——Agent 正在生产中出现。Agent 从人类用户的命令或互动讨论开始工作。一旦任务明确，Agent 独立规划和操作，可能返回人类以获取更多信息或判断。在执行过程中，Agent 在每个步骤从环境中获取“事实（ground truth）”（如工具调用结果或代码执行）以评估其进展至关重要。Agent 可以在检查点或遇到障碍时暂停以获取人类反馈。任务通常在完成时终止，但通常也包括停止条件（如最大迭代次数）以保持控制。

Agent 可以处理复杂的任务，但它们的实现通常很直接。它们通常只是基于环境反馈在循环中使用工具的 LLM 。因此，清晰、周到地设计工具集及其文档至关重要。

该模式适用于开放式问题，其中难以或无法预测所需的步骤数，且无法硬编码固定路径。LLM 可能会进行多轮操作，因此需要对其决策有一定程度的信任。Agent 的自主性意味着更高的成本和潜在的错误累积。建议在沙盒环境中进行广泛测试，并配备适当的护栏。

示例场景：

以下示例来自我们自己的实现：

一个编程 Agent 来解决 SWE-bench 任务，涉及根据任务描述对多个文件进行编辑。
我们的“计算机使用”参考实现，其中 Claude 使用计算机完成任务。

组合和定制这些模式

Anthropic 指出上面这些模式并非是标准的，不可修改的，这些也不过是生产实践的总结。开发者可以根据实际情况修改和组合使用，它们是开发者可以根据不同用例塑造和组合的常见模式。成功的关键，就是评估并持续迭代它们，并且不要过早引入复杂度。

总结

最后，Anthropic 再次强调，LLM 应用开发的成功不在于构建最复杂的系统，而在于构建满足实际需求的正确系统。从简单的 Prompt 开始，通过全面评估进行优化，仅在简单解决方案不能满足需求时，再引入多步的 Agent 系统。

在实现 Agent 系统时，建议遵循三个核心原则：

在 Agent 的设计中保持简洁性。
通过明确显示 Agent 的规划步骤来优先考虑透明度。
通过详尽的工具文档和测试来精心设计 Agent-计算机接口（ACI）。

最后，再一次指出，要慎用框架，框架可以帮助入门和原型构建，但是真的投产时应尽量减少抽象层，多使用底层组件构建，基于这些原则更利于强大而且可靠、可维护且受用户信任的 Agent 系统。

最后

为什么要学AI大模型

当下，⼈⼯智能市场迎来了爆发期，并逐渐进⼊以⼈⼯通⽤智能（AGI）为主导的新时代。企业纷纷官宣“ AI+ ”战略，为新兴技术⼈才创造丰富的就业机会，⼈才缺⼝将达 400 万！

DeepSeek问世以来，生成式AI和大模型技术爆发式增长，让很多岗位重新成了炙手可热的新星，岗位薪资远超很多后端岗位，在程序员中稳居前列。

在这里插入图片描述

与此同时AI与各行各业深度融合，飞速发展，成为炙手可热的新风口，企业非常需要了解AI、懂AI、会用AI的员工，纷纷开出高薪招聘AI大模型相关岗位。
在这里插入图片描述
最近很多程序员朋友都已经学习或者准备学习 AI 大模型，后台也经常会有小伙伴咨询学习路线和学习资料，我特别拜托北京清华大学学士和美国加州理工学院博士学位的鲁为民老师给大家这里给大家准备了一份涵盖了AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频 全系列的学习资料，这些学习资料不仅深入浅出，而且非常实用，让大家系统而高效地掌握AI大模型的各个知识点。