Claude的Agent开发圣经| Agent的设计模式Claude的Agent开发圣经| Agent的设计模式【AI

Claude的Agent开发圣经| Agent的设计模式

【AI大模型教程】

2025所谓智能体元年，从年初的雨后春笋，到年底彻底爆发。

如果你也在设计Agent，不妨先看下Anthropic官方的这几篇文章，堪称智能体开发的必读圣经：

《Building effective agents》
《How we built our multi-agent research system》
《Effective context engineering for AI agents》
《Equipping agents for the real world with Agent Skills》

以上文章我会连续更新解读，感兴趣点击关注哦~

首先，今天这篇我会以道法术器来解读「构建高效Agent的设计哲学与框架选型」，原文附在最后。

道：尽可能简单的解决方案

“大道至简，衍化至繁”，使用大模型构建AI应用时，Anthropic建议大家：找到尽可能简单的解决方案，仅在需要时增加复杂性。

也就是说，对于很多AI应用场景并不需要构建Agent，使用检索和上下文示例优化单个 LLM 调用通常就足够了，而Agent通常是以延迟和成本来换取更好的答案。

技术服务于业务，选择工作流or智能体？可以参考如下：

AI Workflow（工作流）：可以预先定义明确调用步骤的任务，采用工作流能提供可预测性和一致性。
AI Agent（智能体）：大规模灵活性和模型驱动决策的任务，由大模型自主决定执行步骤。

法：常见的设计模式

类似传统编程的设计模式，Agent也有一些常见的设计模式，从基础构建块逐步增加复杂性，从简单的组合工作流程到自主决策的智能体。

增强型LLM

智能体系统的基础构建是通过检索、工具和内存等来增强LLM的功能，针对用户输入，由LLM进行意图识别并确定调用什么工具来实现任务。

比如通过MCP来调用第三方天气查询工具，从而扩展LLM能力。

提示词链 Prompt Chaining

有些任务虽然复杂，但能清晰地拆解为几个固定子任务，那么就可以让LLM每次任务调用都更简单明确，权衡延迟以获得更高的准确性。

如图所示，提示词链工作流将任务分解为一系列步骤，其中每个LLM调用都会处理前一个步骤的输出，并且可以在任何中间步骤上添加程序检查，以确保流程仍按计划进行。

路由 Routing

对于输入有不同类别并需要采用不同处理方式的场景，就可以使用路由工作流对输入进行分类，将其定向到专属的后续任务。

该工作流允许分离关注点，并且可以避免优化一种输入类型可能会损害其他输入的性能。

此外，这里的任务类别分类，可以通过LLM或更传统的分类模型/算法准确处理分类。

并行化 Parallelization

当子任务可以并行执行来提高速度，或者需要多个视角和尝试以获得更高准确性时，可以采用并行化工作流方案。

这种并行化工作流，有两个关键变体：

分段：将任务分解为独立的子任务并行运行
投票：多次运行同一任务以获得不同的输出

该方案的优势是，每个考虑因素都由单独的LLM调用处理，LLM可以集中注意力，从而实现更好的效果。

协调者-辅助者 Orchestrator-workers

当无法预测所需子任务时，可以采用「协调者-辅助者」工作流，先由协调者LLM动态分解任务，子任务委托给不同的辅助者LLM，并综合其结果。

与并行化模式相比，「协调-辅助」工作流更具灵活性，子任务不是预定义的，而是由业务流程协调LLM根据输入判断的。

评估器-优化器 Evaluator-optimizer

当存在明确的评估标准，并且迭代优化提供可衡量价值时，可以使用「评估器-优化器」工作流，一个LLM调用生成响应，另一个调用则循环提供评估和反馈。

自主性智能体Agent

对于复杂的开放式问题，往往无法硬编码固定路径，就可以使用具有自主性的智能体模式。

开始：始于用户的一条指令或交互式讨论，一旦任务明确，Agent便会自主规划与执行。
执行：在执行过程中，每一步都能从环境中获取“真实情况”（如工具调用结果或代码执行），以评估自身进度；还可以在检查点或遇到阻塞时暂停，以获取人类反馈。
结束：任务通常在完成后终止，但也可以人为设置停止条件（如最大迭代次数）以保持可控。

如上图所示，Agent虽然可以处理复杂任务，但实现其实并不复杂，通常只是基于环境反馈、循环使用工具的一个大语言模型。

术：Agent架构设计

以上7个设计模式作为原子架构，在实际业务场景的智能体架构设计中如何组合应用呢？我举2个例子来说明。

首先，以最最简单的“查询某地附近的美食”为例，该架构如何设计？

回顾第二部分的设计模式，可以组合使用「增强型」+「评估-优化型」这两个设计模式，详见下图：

当用户提出“帮我查一下中关村附近的美食”，执行流程：

① 先由增强型LLM进行意图理解并判断是否需要调用工具生成结果；

② 假设第一次LLM通过联网搜索工具查到小红书推荐的海淀区必打卡的几家美食店，然后将结果交给Evaluator LLM判断是否满足要求，Evaluator LLM判断这里得到的答案位置分散、不够全面，不符合中关村附近的要求；

③ 所以返给Generator LLM进行二次生成，这次Generator LLM分析要获取具备更全面且有时效性的信息，调用地图MCP的周边检索工具，并将最新结果交给Evaluator LLM；

④ 评估第二次得到的结果满足要求，就输出给用户；

然后，再看下字节开源的深度研究智能体deerflow的官方架构设计。

如下图所示，整体采用的是「协调者-辅助者」+「智能体」设计架构。

针对用户问题，先由Coordinator进行意图识别，将符合深度研究的问题交给planner（自主规划）进行任务分解，当用户确认进行深度研究后，由research_team（协调者）判断是否需要调用coder，以及安排几个researcher（辅助者）执行子任务，research_team综合结果后交给planner判断获取的信息是否足够，然后交给reporter生成最终的研究报告。

器：开发与框架

在具体开发中，Agent分为两派：

一派是使用Dify、Coze、n8n类软件搭建Agent，其本质是将模型作为返回字符串的后端；
另一派是真正AI驱动的原生Agent，需要低代码开发，可以直接使用LLM API，也可以借助Agent框架来简化开发。

市面上第一代LangChain和LlamaIndex定义了通用LLM应用框架范式，层出不穷的新一代框架更专注复杂工作流控制和多智能体协作。

主流的Agent框架选型参考如下：

框架的优势是将共有的、重复的工作进行封装和抽象，例如LLM调用、状态管理、工具调用等，从而简化开发难度，让我们更专注于业务逻辑；

但框架的劣势是通过构建额外的抽象层，从而掩盖了底层的提示和响应，使它们难以调试。

所以，Anthropic建议先从直接使用LLM API开始，当了解底层代码后，再使用框架，从而能够更好地进行问题定位。