AI智能体设计模式与框架解析

★ 点击名片，关注我们不迷路 ★

许多朋友对智能体（Agent）的运作模式感到陌生，对于ReAct、Planner、反思等术语感到困惑。别担心，本文将以最易懂的方式，带您深入了解智能体的内部机制。

一个成熟的智能体系统通常包含多个智能体、反思机制、规划能力、推理与行动、记忆功能、RAG（检索增强生成）、工具使用以及MCP（多智能体通信协议）等组成部分。首先，让我们来探讨“Multi-Agent”这一核心概念，它充满了趣味性！

在当前技术水平下，让单一的AI（仅通过系统提示词赋能的LLM）完全替代人类工作仍然面临巨大挑战。我们很快意识到，要构建高效的系统，必须让多个专业化智能体协同合作、自主组织。为此，AI智能体领域已经涌现出多种架构模式。多个智能体协同工作的模式，即Multi-Agent，目前已有七种主要的实现方式。

在《Agentic Design Patterns》一书中，这种模式被称为Prompt Chaining。在这种模式下，每个智能体逐步完成一项任务，例如，一个智能体负责生成代码，另一个负责审核代码，第三个负责部署代码。前一个智能体的输出作为下一个智能体的输入。这种信息传递方式构建了一个依赖链，前序操作的上下文和结果能够指导后续的处理，使LLM能够在前一步的基础上不断深化理解，逐步逼近最终目标。

这种模式非常适用于工作流自动化、ETL（提取、转换、加载）以及多步骤推理流程等场景。

路由模式为智能体的操作框架引入了条件判断逻辑，使其能够从固定的执行路径转向动态评估标准，并从一组可能的后续动作中进行选择，从而实现更灵活、更具上下文感知能力的操作。一个控制器智能体负责将任务分配给最合适的专业智能体，这是上下文感知智能体路由的基础，在MCP、A2A等框架中都能看到其应用。

路由模式的实现方式有四种：

基于Embedding的路由：利用嵌入技术，将查询路由到最相似的路径上，适用于语义路由，即决策基于输入的含义而非关键词。

基于定义规则的路由：采用硬编码的方式，根据关键词、模式或结构化数据进行路由。这种方法比LLM路由更快、结果更确定，但灵活性较低。

基于自训小模型的路由：采用如分类器等判别模型，在小规模标注数据集上进行专门训练以实现路由任务。与向量嵌入方法类似，但其特点是通过监督微调过程，将路由逻辑编码在模型权重中。与LLM路由不同，决策组件不是在推理时执行提示的生成模型，而是经过微调的判别模型。LLM可用于生成合成训练数据，但不参与实时路由决策。

每个智能体负责处理不同的子任务，例如数据爬虫、网络检索和摘要生成，它们的输出最终会合并成一个单一的结果。这种模式非常适合在处理高吞吐量管道时减少延迟（例如文档解析或API编排）。

智能体持续优化自身输出，直到达到预期的质量标准。这种模式非常适合校对、报告生成或创意迭代等场景，在这些场景中，系统会在确定最终结果前进行多次思考和调整。反思机制就是在此模式上的进一步优化。

许多智能体生成部分结果，然后由一个主智能体将这些结果整合为最终输出。在这种模式下，每个智能体形成一个独立的观点，然后由一个Master智能体汇总这些观点形成共识。这种模式在RAG的检索融合、投票系统等场景中非常常见。

在这种模式下，没有明确的层级结构，智能体之间可以自由交流，动态共享上下文信息。它适用于模拟、多智能体游戏以及需要自由形式行为的集体推理系统。例如，agentscope-samples 模拟了9个智能体进行的狼人杀游戏。

一个顶级的规划智能体负责将子任务分配给工作智能体，跟踪它们的进展，并做出最终决策。这类似于经理与其团队的工作方式（许多中间件的架构也采用了类似模式，如Redis、ES、Nocas）。意图识别就是采用此模式。

我们一直在思考的关键问题是，哪种模式能最大限度地减少智能体之间的交互摩擦，而不是哪种模式看起来最酷。启动10个智能体并称之为团队很容易，但难点在于设计沟通流程，以确保：没有两个智能体会执行重复的任务。每个智能体都清楚何时该行动、何时该等待，从而使整个系统作为一个整体，比其任何单个部分都更加智能。为此，我们遵循 building-effective-agents 的设计原则。

多智能体模式将人工智能工作流构建为一个智能体团队，它们相互协作，每个智能体都拥有明确的角色。每个智能体都能够感知输入、进行推理（通过思维链）并执行操作来完成子任务。通常，每个智能体都会被配置特定的角色，并且只能访问该角色所需的工具或信息。例如，PM Agent负责判断需求是否需要其他智能体参与，如果需要技术决策，则会联动Tech lead agent。智能体将循环进行思考（“思考……”）和行动（“行动……”），直到完成其工作部分的任务。如下图所示。

以上简要介绍了多智能体的设计模式，那么当前是否已经有成熟的框架可供我们使用呢？答案是肯定的！

AutoGPT：Github 180k Star

Dify： Github 118k Star

AutoGen： Github 51.4k Star

CrewAI： Github 40.1k Star

LangGraph： Github 20.6k Star

当遇到“问题无法完全穷举、需要跨多个系统进行核实、并且需要在对话中进行澄清、协商、决策”等情况时，更应该使用Agent框架，而不是纯粹的Workflow。

Workflow在对话中的“澄清—再决策—再行动”过程并不天然友好，需要将每一步的提问、回答、重试都绘制成节点，这会导致流程复杂且脆弱。

场景示例：用户发起请求：“我的包裹还没到，怎么办？”

通过Workflow创建的智能体可能需要考虑：(目前不期望GPT-6等模型能自主思考的智能体)

智能体数量 × 物流状态 × 用户等级 × 物流政策…. 您的分支会呈指数级增长。因此，需要使用Dify这类支持动态决策、动态推理和澄清的智能体框架。

以 AutoGen、CrewAI 等Agent框架为例，它们将“在对话中动态规划与调用工具”作为核心能力：

场景示例：用户说“我10.1买的手机现在还没到，给我退货！另外，你们的运费险的保账期是多久？”

一个合格的客服Agent团队会如何处理？

在没有路由决策的情况下，首先会动态匹配所有查询，并将查询改写为“查询用户的订单”，“用户想要退货”，“运费险的保账范围和条款”。

Policy Agent：套用“假期延误 + Plus会员 + 运费险”的组合条款，评估可提供的补偿范围，以及是否触发风控人工复核。

在这些操作中，许多步骤无法预先“绘制”成固定的分支，需要在对话上下文中进行决策，需要跨工具动态组合，需要“问一句 → 查一下 → 再决定”，这正是Agent的强项所在。

结尾：以上是对多智能体模式的总结，您掌握了吗？