lijianfei.com

在生成式 AI 的演进历程中，业界正经历一场深刻的技术范式迁移：从依赖单次 Prompt 技巧的“生成式问答”，全面跨入具备环境感知、状态保持、分层规划与工具调用的“自主智能体（Agentic Systems）”时代。然而，多数团队在跨越这道技术鸿沟时，常常陷入随机试错的泥潭——上下文雪崩、状态失忆、级联幻觉、死循环无法终止以及多 Agent 协议割裂，使得原本炫酷的 Demo 极难走向企业级生产交付。

正如当年面向对象编程混沌期诞生的 GoF《设计模式》为软件工程奠定了坚实原语，Google 资深工程总监 Antonio Gulli 开源的重磅力作《Agentic Design Patterns》（涵盖 424 页完整技术专著与 58 个配套实战 Notebook），首次系统性地梳理出 21 种智能体架构原语。本文将结合作者的权威代码实现（覆盖 Google ADK、LangGraph、CrewAI 与 FastMCP），对这套架构模式进行全方位工程解构与选型推演。

1. 为什么大模型落地需要“设计模式”？

在传统软件工程中，系统行为是确定性状态机的转移：只要输入相同，输出与副作用便 100% 可控。但在大语言模型驱动的智能体系统中，核心运算单元是一个具备概率分布的黑盒。

随着智能体执行的任务步数（Steps）增加，系统整体的成功率遵循指数级衰减定律：

$P_{total} = \prod_{i=1}^{n} P_{step\_i}$

若单步推理或工具调用的准确率为 90%，经过 10 步复杂链路后，端到端成功率仅剩约 35%。若缺乏严密的架构原语控制，智能体系统极易在生产环境中遭遇以下灾难：

1. 级联雪崩（Cascading Failures）：上游工具返回的微小格式偏差，在下游链条中被模型当作事实持续放大，最终彻底偏离业务目标；
2. 状态失忆与膨胀（Context Bloat & Amnesia）：无节制地将全量历史堆入上下文窗口，不仅导致推理成本呈二次方爆炸，更会引发“大海捞针”困境，遗忘关键系统指令；
3. 工具死锁与震荡（Oscillation & Infinite Loops）：工具调用报错后，Agent 反复尝试同一无效参数陷入死循环；
4. 协议孤岛（Protocol Fragmentation）：不同的 Agent 框架（LangChain、AutoGen、CrewAI、Semantic Kernel）各自为政，无法跨边界协同。

Antonio Gulli 在《Agentic Design Patterns》中，将解决上述痛点的架构手段解构为四层演进体系：

flowchart TD
    subgraph Enterprise ["第四层：企业治理与自治模式 (Enterprise Patterns)"]
        P15["Ch15: Inter-Agent A2A 协议"]
        P16["Ch16: 资源与成本感知优化"]
        P17["Ch17: 高级推理引擎"]
        P18["Ch18: 安全护栏与拦截器"]
        P19["Ch19: LLM-as-a-Judge 轨迹评估"]
        P20["Ch20: 动态任务优先级"]
        P21["Ch21: 自主探索与假设生成"]
    end

    subgraph Production ["第三层：生产级弹性工程模式 (Production Patterns)"]
        P12["Ch12: 异常捕获与熔断降级"]
        P13["Ch13: 人机协同审批闸门 (HITL)"]
        P14["Ch14: 知识检索与实时接地 (RAG)"]
    end

    subgraph Advanced ["第二层：高级认知与协议模式 (Advanced Patterns)"]
        P8["Ch8: 分层状态与会话记忆"]
        P9["Ch9: 动态优化与演化学习"]
        P10["Ch10: Model Context Protocol (MCP)"]
        P11["Ch11: 目标设定与收敛监控"]
    end

    subgraph Core ["第一层：核心基础原语 (Core Patterns)"]
        P1["Ch1: Prompt Chaining (提示词链)"]
        P2["Ch2: Routing (语义与能力路由)"]
        P3["Ch3: Parallelization (并行化处理)"]
        P4["Ch4: Reflection (反思与自愈)"]
        P5["Ch5: Tool Use (工具集成与沙箱)"]
        P6["Ch6: Planning (战略分解与规划)"]
        P7["Ch7: Multi-Agent (多智能体协同)"]
    end

    Core --> Advanced
    Advanced --> Production
    Production --> Enterprise

2. 第一层：核心基础模式（Core Patterns）

核心模式专注于将单个 Prompt 的不可靠性，转化为结构化确定性执行流。

模式 1：Prompt Chaining（链式任务分解）

• 核心思想：绝不试图让大模型在一个庞大的 Prompt 中同时完成“理解、搜索、推理、格式化、审查”全部任务。通过将高熵任务分解为多个单向传递的低熵管道，每一步输出均作为下一步的严格输入。
• 工程解法：在步骤交接处引入强制 Schema 校验（如 Pydantic BaseModel），在中间件层阻断非结构化乱码。

模式 2：Routing（语义与能力路由）

• 核心思想：根据用户输入或中间状态的语义特征，将任务分发给最适配的处理管道。
• 架构实现：
  1. 意图路由：通过轻量分类器（如 Gemini Flash 或嵌入向量余弦相似度）划分业务领域（如订单售后 vs 技术答疑）；
  2. 模型分级路由：简单检索请求走小参数量模型，高难度逻辑分析才激活高算力前沿模型，极大降低调用成本。

flowchart LR
    UserQuery["用户输入 Query"] --> Router["语义意图分类器 (Router)"]
    Router -->|"业务问询"| SmallLLM["轻量小模型 (Flash/Mini)"]
    Router -->|"代码/复杂逻辑"| FrontierLLM["前沿推理模型 (Pro/Reasoning)"]
    Router -->|"确定性规则"| RuleEngine["确定性规则/API 引擎"]

模式 3：Parallelization（并行计算与推测采样）

• 核心思想：打破传统串行链式瓶颈，利用多并发降低 p99 耗时并增强结果鲁棒性。
• 典型范式：
  • 分治汇总（Sectioning / Map-Reduce）：将 50 页的长文档切分为 10 个独立章节，并发生成摘要后进行二次合成；
  • 多数表决（Voting / Self-Consistency）：针对高危推理逻辑，并发调用 3 次生成不同思维路径，通过一致性聚合降低单次随机幻觉。

模式 4：Reflection（自我反思与 Critic 校验）

• 核心思想：引入生成器（Generator）与评估器（Evaluator / Critic）的双重角色闭环。
• 工作机制：生成器产生初稿，评估器根据预设的不变式（Invariants）与业务标准打分并给出明确缺陷反馈，生成器依据反馈修正，直至达到收敛阈值或耗尽最大反思轮数（Max Iterations）。

sequenceDiagram
    autonumber
    participant G as Generator (执行生成)
    participant E as Evaluator (规则与评判)
    participant S as State / Memory (状态缓存)

    G->>E: 提交初始输出候选
    E->>E: 校验业务规范与质量得分
    alt 评分达标 (Pass)
        E-->>S: 固化结果并退出循环
    else 评分未达标 (Fail)
        E->>G: 返回详细结构化 Critique (缺陷诊断与修改意见)
        G->>G: 结合上下文修正产出
        G->>E: 提交迭代候选结果
    end

模式 5：Tool Use（工具执行与受控沙箱）

• 核心思想：通过标准的 Function Calling 机制将 Agent 接入外部物理世界与 API。
• 防踩坑实践：
  • 必须实施参数前置校验，防止大模型幻觉出不存在的字段参数；
  • 涉及 Python 或 Shell 执行的代码解释器（Code Execution），必须挂载在隔离容器或 gVisor 安全沙箱中，严格限制网络出栈与文件系统写权限。

模式 6：Planning（规划与动态解耦）

• 核心思想：在采取具体动作前，先自顶向下生成结构化执行图（DAG）。
• 对比机制：
  • ReAct（边做边想）：单步灵活性高，但面对超过 15 步的宏观任务极易中途跑偏或迷失最终目标；
  • Plan-and-Solve（先定方案再执行）：先产出全量 Task Checklist，由调度器推进执行；每完成一个阶段，动态评估当前环境并按需更新后续 Plan（如 Google Deep Research 的递归规划能力）。

模式 7：Multi-Agent Collaboration（多智能体拓扑协同）

• 核心思想：打破单 Agent“全能角色”的认知负载陷阱，按照领域职责组建垂直 Agent 专家组。
• 四大经典拓扑：
  1. 协调者模式（Coordinator / Orchestrator）：中心化 Agent 负责任务指派与结果验收；
  2. 接力流模式（Sequential Pipeline）：前置 Agent 的最终工件交由下游 Agent 深入加工；
  3. 竞合表决模式（Competitive / Consensus）：多个异构智能体就同一方案进行辩论并达成共识；
  4. 事件驱动群（Event-Driven Swarm）：基于共享黑板（Blackboard）或消息总线触发异步协作。

3. 第二层：高级认知与协议模式（Advanced Patterns）

当智能体从单轮交互走向长期跨会话服务时，状态管理与生态标准化成为不可逾越的关键瓶颈。

模式 8：Memory Management（分层持久化状态体系）

在原生代码实现中，Antonio Gulli 使用 Google ADK 的 SessionService 架构，展示了工业级内存的三层分化：

flowchart TD
    subgraph WorkingMemory ["1. 临时工作内存 (Scratchpad / Ephemeral)"]
        W1["当前 Step 上下文、临时 Tool Call 返回值、中间思考过程"]
    end

    subgraph SessionMemory ["2. 会话状态服务 (Session Service)"]
        S1["InMemorySessionService (本地单测与轻量调试)"]
        S2["DatabaseSessionService (基于 SQLAlchemy / PostgreSQL 落地)"]
        S3["VertexAiSessionService (云原生托管会话)"]
    end

    subgraph LongTermMemory ["3. 长期语义与情节记忆 (Episodic & Semantic Memory)"]
        L1["用户偏好实体画像 (Profile Graph)"]
        L2["向量知识索引 (Vector DB)"]
        L3["历史关键里程碑总结 (Distilled Milestones)"]
    end

    WorkingMemory -->|会话结束/刷盘| SessionMemory
    SessionMemory -->|提炼沉淀| LongTermMemory

通过这一分层，执行引擎能够随时清理 Scratchpad 中的冗余中间 Token，而长期记忆仅在收到相关语义唤醒时才被动态注入上下文。

模式 10：Model Context Protocol（MCP 标准上下文协议）

智能体开发面临的最大工程内耗是：每切换一个框架，工程师就必须将已写好的业务 Tool 用该框架的专属 Class 重新封装一遍。

书中 Chapter 10 重点解析了由 Anthropic 发起并迅速成为业界共识的 Model Context Protocol (MCP)。通过标准化的 FastMCP 服务端，所有的工具能力、文档上下文（Resources）与提示词模板（Prompts）均成为通用的微服务资产：

# fastmcp_server.py
# 基于 FastMCP 构建跨 Agent 框架的标准工具服务
from fastmcp import FastMCP
from typing import Dict, Any

mcp = FastMCP("DataOpsService")

@mcp.tool()
def execute_sql_query(query: str, database_id: str) -> Dict[str, Any]:
    """在指定数据库中执行只读分析 SQL 查询，包含严格权限与只读拦截"""
    # 业务查询逻辑与连接池处理
    return {"status": "success", "rows_affected": 42, "data": [...]}

if __name__ == "__main__":
    mcp.run()

无论宿主 Agent 是运行在 Google ADK、LangGraph 还是 Cursor / Claude Desktop 中，只需一行配置接入该 MCP Server，即可拥有完全一致的工具集与鉴权凭证。

4. 第三层：生产级弹性工程模式（Production Patterns）

在真实业务场景中，网络超时、模型限流、Schema 畸变是不可避免的常态。生产级模式赋予系统强韧的容错自愈能力。

模式 12：Exception Handling & Self-Healing（异常捕获与级联降级）

• 动态重试（Dynamic Self-Correction）：当工具返回 HTTP 400: Invalid payload schema 时，系统绝不能直接抛出 Exception 中断流水线，而是将异常堆栈、原始入参与错误原因打包，注入为次轮模型的 System Prompt，让大模型自适应重构参数；
• 模型级联熔断（Fallback Cascade）：
  • 主模型（如顶级推理模型）出现 429 限流或超时（Latency > 15s）；
  • 触发 Circuit Breaker，自动平滑回退至预备的高吞吐备用模型；
  • 核心状态与对话上下文保持无损透传。

模式 13：Human-in-the-Loop（人机协同审批闸门）

智能体绝不能在未受控的情况下执行“不可逆操作”（如退款打款、删库、向百万用户发送营销邮件）。

书中演示了基于 持久化断点（Interrupt & Checkpoint） 的 HITL 架构：

sequenceDiagram
    autonumber
    participant Agent as 智能体系统
    participant Gate as 权限判定闸门
    participant Ops as 人工审批端 (Slack / Dashboard)
    participant State as 状态持久化库 (State Store)

    Agent->>Gate: 触发高风险工具 (如: RefundMoney)
    Gate->>Gate: 拦截高危操作，挂起当前执行流
    Gate->>State: 持久化保存执行快照 (State Checkpoint)
    Gate->>Ops: 推送审批卡片 (包含参数、理由与执行上下文)
    Note over Agent: 智能体转入等待休眠，释放计算资源
    Ops->>Gate: 管理员审批通过 (Approve / Override)
    Gate->>State: 加载快照恢复上下文
    Gate->>Agent: 恢复中断线程，正式执行工具调用

5. 第四层：企业级治理与 A2A 协议（Enterprise Patterns）

随着业务规模扩大，单一组织内部将涌现成百上千个功能迥异的 Agent。如何让这些由不同团队维护、部署在不同网络环境中的智能体实现自主发现与通信？

模式 15：Inter-Agent Communication（A2A 跨系统通信协议）

在 Chapter 15 中，项目展示了基于 AgentCard 的开放 Agent-to-Agent（A2A）标准通信范式。每一个暴露在网络中的智能体都会挂载一个符合规范的 JSON 元数据清单：

{
  "name": "WeatherAnalyticsBot",
  "description": "提供精准气象预测、历史异常数据挖掘与极端天气预警分析",
  "url": "https://weather-agent.corp.internal/a2a",
  "version": "1.2.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false,
    "stateTransitionHistory": true
  },
  "authentication": {
    "schemes": ["bearerToken"]
  },
  "skills": [
    {
      "id": "get_extreme_weather_risk",
      "name": "评估指定经纬度未来 72 小时极端天气风险",
      "inputModes": ["application/json"],
      "outputModes": ["application/json"],
      "tags": ["weather", "risk-assessment", "real-time"]
    }
  ]
}

上游调度智能体通过读取对端的 AgentCard，可以在运行时动态感知其拥有的 Skills、输入输出 Schema 和通信协议，从而像调用本地微服务一样完成跨云端、跨团队的复杂业务委托。

模式 18：Guardrails（运行时多层安全护栏）

• 输入层防御：拦截越狱注入（Prompt Injection）、隐匿指令窃取、敏感词检测；
• 工具调用层防御：结合 Google ADK 的 validate_tool_params，对入参进行严格的正则匹配、枚举范围校验以及语义范围限制，阻断任意命令注入；
• 输出层防御：利用小模型作为轻量级守卫（LLM-as-a-Guardrail），对最终吐给终端用户的回答进行真实性、毒性、合规性二次校验。

# 模式 18 落地示范：基于工具拦截器的动态安全校验
from google.adk.tools.base_tool import BaseTool
from google.adk.tools.tool_context import ToolContext
from typing import Optional, Dict, Any

def validate_tool_params(
    tool: BaseTool,
    args: Dict[str, Any],
    tool_context: ToolContext
) -> Optional[Dict[str, Any]]:
    """在物理工具被触发前，执行强制入参防御与审计拦截"""
    if tool.name == "execute_bash_command":
        command = args.get("command", "")
        # 高危危险操作硬拦截
        dangerous_patterns = ["rm -rf", "sudo", "chmod 777", "mkfs", "> /dev/"]
        for pattern in dangerous_patterns:
            if pattern in command:
                raise PermissionError(f"安全拦截：检测到高危指令特征 [{pattern}]，工具拒绝执行")
    return args

6. 主流智能体框架横向选型与决策矩阵

面对庞杂的智能体开源框架，架构师该如何在不同场景下选型？基于书中 58 个 Notebook 的真实跑通体验，我们将核心框架进行多维比对：

架构选型推演指南

1. 如果业务逻辑有明确的判定流程与复杂环路：直接选用 LangGraph，利用其状态图（StateGraph）对每个节点的转移条件做形式化定义；
2. 如果团队需要构建跨团队、跨系统的企业级中台：底层工具全部基于 FastMCP 暴露，通信骨干采用 A2A (AgentCard) 契约协议；
3. 如果需要开箱即用的多专家分工与内容创作流水线：选用 CrewAI 快速搭建协同角色；
4. 如果深耕 Google Cloud 生态并要求高可靠会话隔离：优先采用 Google ADK 的 BaseAgent 与 SessionService。

7. 总结与架构思考

从单轮 Chatbot 到多智能体自治系统，AI 应用开发正在告别“撞大运式的提示词炼金术”，步入真正具备可预期性、健壮性与可维护性的系统软件工程阶段。

Antonio Gulli 在《Agentic Design Patterns》中所提炼的 21 种模式，本质上揭示了一条核心设计哲学：永远不要把智能寄托在大模型单次全知全能的完美输出上，而要将大模型的泛化能力封装在严密的确定性工程护栏之中。

通过提示词链降解复杂度、通过路由按需分配算力、通过反思与熔断提供自愈底线、通过 MCP 与 A2A 终结协议割裂——这套架构原语，正是每一个试图在 2026 年构建工业级 AI 系统的工程师不可或缺的基础底座。

原文链接与参考资料

• 项目开源代码仓：evoiz/Agentic-Design-Patterns (GitHub)
• 专著预订与详情：Amazon - Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems
• 作者个人主页：Antonio Gulli - LinkedIn
• 官方完整学习资源库：Agentic Design Patterns Google Drive Materials