Agentic Design Patterns A Hands-On Guide to Building Intelligent Systems · Antonio Gulli

🎯 一句话定位

把"等着串行执行"改成"同时跑独立子任务"，是降低 Agent 延迟最直接的杠杆——书中给的例子：研究 Agent 要总结 5 个来源，串行 50 秒，并行 10 秒。

🧠 核心机制：三种典型并行形态

• ① Map-Reduce 型：100 个文档分别摘要（map）→ 汇总成一份报告（reduce）。最经典，但 reduce 阶段易爆 context
• ② 多视角型：同一个问题，3 个 Agent 用不同角色（PM/Eng/Designer）并行回答，再投票或汇总。常用于决策类任务
• ③ 多采样型 / Self-Consistency：同一 prompt 高 temperature 跑 N 次，选出现频率最高的答案。对推理题、数学题特别有效

🛠 实战要点

• LangChain 的 RunnableParallel：声明式地让多个 chain 并行跑。语法很直观
• Google ADK 的"LLM-Driven Delegation"：Coordinator agent 自己识别哪些子任务独立，自动分派
• asyncio：纯 Python 实现时用 asyncio.gather() 等所有任务完成
• 并发上限：必须设 semaphore（如 max_concurrent=10），否则 API 限流会让所有请求一起 fail
• I/O 密集场景收益最大：API 调用、向量检索、网页抓取等等

⚠️ 易错点

• 误判独立性：以为两个任务独立，其实下游依赖上游某个字段 → 结果不一致。先画依赖图！
• Reduce 阶段超 context：100 条 200 字摘要合在一起 = 20K tokens，可能超模型上限。解药：分层 reduce——每 10 条先合并，再合 10 个中间结果
• 引入并行 = 引入复杂度：debugging、日志、错误处理、限流都变难，"the adoption of a concurrent architecture introduces substantial complexity and cost"（书中原话）。简单任务别强行并行
• 部分失败处理：10 个并行任务 1 个失败怎么办？整体重试 / 用其他 9 个 / fail-fast？必须预先设计

🔗 与其他章节

常与 Chaining (Ch1) 混合：先并行抓数据 → 串行 synthesize。也是 Multi-Agent (Ch7) 的底层执行机制（不同 Agent 并行做事）。在 Reasoning Techniques (Ch17) 里 Self-Consistency 是并行采样的应用。

🎯 一句话定位

让 Agent 学会"批判自己的初稿，再改一遍"——通过 Generate → Critique → Refine 的反馈环路提升输出质量，是 Agentic AI 区别于普通 LLM 调用的关键能力之一。

🧠 核心机制：Producer-Critic 模型

书中重点推荐 Producer-Critic 模型：用两个独立的 Agent（或同一模型但不同 system prompt）分饰两角：

• Producer：生成初稿（如代码、报告、邮件）
• Critic：扮演"严格审稿人"——对照预设 rubric / checklist 找问题
• Refiner（可由 Producer 兼任）：根据 critique 重写

Gulli 强调："this separation of concerns enhances objectivity"。如果 Producer 和 Critic 是同一个模型 + 同一个 prompt，会陷入 self-preference bias——LLM 倾向于认可自己的输出，critique 形同虚设。

🛠 实战要点

• Critic 用不同模型：Producer 用 GPT-4 + Critic 用 Claude，或反之；不能行的话至少换 system prompt
• Rubric 必须可量化："清晰度 1-5 分"远胜于"写得好不好"
• 终止条件组合：max_iterations（如 3 轮）+ "no major issues" 判定。不能等 Critic "完全满意"——会陷入死循环（critic 永远能挑出小毛病）
• 框架支持：完整迭代反思一般需要 stateful workflow（LangGraph 最适合）；单轮反思可用 LangChain LCEL 实现；Google ADK 用 sequential workflow 模拟

⚠️ 易错点

• 成本和延迟翻 2-3 倍：每轮要多调一次 Critic + 多调一次 Refiner。书中明确警告："these benefits come at the cost of increased latency and computational expense"
• 不是所有任务都适合反思：事实性 / 数学 / SQL 类——错的反思后还是错（反思帮不了 hallucination 类错误）。适合：开放式生成（文案、代码 review、策略分析）
• 容易超 context window：迭代多轮后历史累积巨大

🔗 与其他章节

Reflection 是 Self-Correction 的实现方式之一，与 Reasoning Techniques (Ch17) 中的 Self-Consistency 互补。Anthropic 的 Constitutional AI 是 Reflection 的工业级实例（用 rules 当 critic 的 rubric）。在 Multi-Agent (Ch7) 中可看作"两 Agent 互相 review"的简化形态。

🎯 一句话定位

让 LLM 跳出"只会说话"的牢笼——通过 Function Calling 机制调用外部 API、数据库、代码执行器、计算器，把 Agent 接通真实世界。是从"聊天机器人"升级为"Agent"的临界点。

🧠 核心机制：5 步循环

书中明确列出标准流程：

1. Tool Definition：把外部函数 / API 用结构化 schema 描述给 LLM（包含 name、description、parameters）
2. LLM Decision：LLM 看到用户请求 + 工具列表，决定是否需要调工具、调哪个、传什么参数
3. Structured Call：LLM 输出 {"name": "get_weather", "args": {"city": "Beijing"}} 形式的 JSON
4. Orchestration Layer 执行：框架解析 JSON，真实调用函数，拿到结果
5. Result Injection：把工具结果回填给 LLM，LLM 用它继续生成最终回答

🛠 工具设计 5 原则（书中精华）

• ① 单一职责：一个工具只做一件事，不要做"万能工具"
• ② Clear description：description 字段直接决定 LLM 用不用对——LLM 是看 description 而非函数名决策的。写人话，举例子
• ③ 幂等：可重复调用产生相同结果（重试时不会副作用累加）
• ④ 结构化错误：返回 {"error":"...","code":"...","suggestion":"..."} 而非 throw exception
• ⑤ 限速友好：内置 rate limit 处理，不让上游 Agent 操心

📦 主流框架

• LangChain：@tool 装饰器 + create_tool_calling_agent + AgentExecutor
• Google ADK：预置 Google Search、Code Execution、Vertex AI Search 等工具，开箱即用
• Crew AI：以 Agent + Task + Tool 三元组组织

⚠️ 易错点

• 工具描述模糊 → LLM 选错工具或不知何时调用（最常见的故障！）
• 参数没有类型限制 → LLM 传错类型导致执行失败
• 没设超时 → 慢工具拖垮整个 Agent
• 工具数量过多（>20 个）：LLM 选择困难，准确率下降。解药：分组 + Routing 先选组

🔗 与其他章节

Tool Use 是 MCP (Ch10) 标准化的对象之一。与 Planning (Ch6) 组合形成 ReAct 范式。在 Reasoning Techniques (Ch17) 里 Program-Aided Reasoning 也是 Tool Use 的特例（代码执行器作为工具）。

🎯 一句话定位

给 Agent 一个 high-level 目标（"组织一次团队 offsite"），让它自主拆解出可执行步骤序列——从"反应式响应"升级为"战略式执行"。这是真正 Agentic AI 的核心。

🧠 核心机制：Planning 的两种范式

书中对比了两条主线：

• ① ReAct (Reason + Act)：边想边做。每一步输出 Thought → Action → Observation，根据观察决定下一步。优点：灵活、能 react to surprises；缺点：步数多时容易迷路
• ② Plan-and-Execute：先一次性生成完整 plan（步骤列表），然后 executor 逐条执行，中途允许 replan。优点：plan 可被人审查；缺点：plan 不够灵活

🛠 实战要点

• 初始状态 + 目标状态 + 操作集合：经典 AI Planning 的三要素，LLM 也按这个套路生成 plan
• "Plan is not a rigid script"：书中强调初始 plan 只是起点，遇到障碍要能 replan
• 选型经验：步数 ≤ 3 → ReAct；4-10 步 → Plan-and-Execute；> 10 步或高度不确定 → 分层 plan（先粗规划，每个粗步骤再细规划）
• Google DeepResearch：书中标杆案例——它 reflects、plans、executes 三件事循环做
• 典型应用：研究报告生成、员工 onboarding、竞品分析、复杂代码重构

⚠️ 易错点

• 没有 Replan 机制= "按死规则执行"。Plan-and-Execute 的灵魂是 replan
• Plan 太抽象："研究市场" 这种步骤没法直接执行 → 拆得更具体或交给 sub-planner
• 过度计划：简单任务（1-2 步）不需要 plan，直接 ReAct 反而高效
• 状态管理混乱：plan 步骤之间共享什么状态、怎么共享？必须显式设计

🔗 与其他章节

Planning 几乎是所有高级模式的前置：Multi-Agent (Ch7) 通常用 Planner 当 supervisor 分派任务给 worker；Goal Setting (Ch11) 是 Planning 的指挥棒；Exception Handling (Ch12) 给 Replan 提供触发信号。ReAct 在 Reasoning Techniques (Ch17) 中是 reasoning + acting 的代表。

🎯 一句话定位

不是"一个超级 Agent"，而是"多个专精 Agent 协同"——通过 task decomposition + inter-agent communication 解决单 Agent 搞不定的复杂多领域问题。

🧠 核心机制：4 种协作拓扑

书中重点介绍以下协作形态：

• ① Sequential Handoffs：A 做完交给 B，B 做完交给 C（本质是 Chaining 的多 Agent 版）
• ② Parallel Workstreams：多个 Agent 并行处理不同方面（Chaining 配合 Parallelization）
• ③ Hierarchical / Supervisor：Supervisor 决定分派任务给哪个 worker，收集结果再汇总——最常用、最易调试
• ④ Debate：两个或多个 Agent 互相论辩，提升答案质量（类似 Reflection 的扩展版）

典型示例：复杂研究任务 = Research Agent（信息检索） + Data Analysis Agent（统计） + Synthesis Agent（写报告）。

🛠 实战要点

• 专精化 system prompt：每个 Agent 一份 role-specific 提示词。书中强调"shared ontology"——所有 Agent 共享相同术语表，否则 communication 出问题
• Communication Protocol：定义清晰的消息格式（如 JSON schema 描述 task / status / result）
• 框架：CrewAI（最早做 multi-agent 的）、AutoGen（Microsoft）、LangGraph（用图建模 agent 网络）、Google ADK（多 Agent 内置）
• 主要价值：① 专业化（不同模型 / 工具 / 权限隔离）；② 可扩展（加新角色不影响别人）；③ 并行加速

⚠️ 易错点（书中最警告的部分）

• "Multi-Agent 总是更好"是误区：很多 multi-agent 系统效果不如一个设计良好的单 Agent。原因：① 通信丢信息；② 协调开销大；③ 错误跨 Agent 传播放大
• 真正该用 multi-agent 的 3 种情况：① 不同角色需要不同 system prompt / 不同模型；② 任务能真正并行；③ 需要工具集 / 权限隔离（如审计 Agent 不该有写权限）
• Peer / Network 拓扑很 cool 但 debug 噩梦——消息满天飞，事后还原过程很难。90% 项目用 Supervisor 就够

🔗 与其他章节

Multi-Agent 是 Inter-Agent Communication / A2A (Ch15) 的应用场景；与 Memory Management (Ch8) 紧密关联（agents 之间共享什么记忆？）；Supervisor 角色本质是 Planning (Ch6) 的执行体。

🎯 一句话定位

让 Agent "记住事"——从"每次对话都失忆"的 stateless LLM，升级为能跨会话记得用户偏好、过往任务、领域知识的真正智能体。书中说这是"agent 实用化"的硬门槛。

🧠 核心机制：双层 / 三层记忆模型

书中给的工业级 Memory 分层：

• ① Short-term（工作记忆）：当前对话的 message 历史，存在 LLM context window 里。受 token 上限约束
• ② Long-term（语义记忆）：跨会话的事实、偏好、知识。存在向量数据库（Chroma、Pinecone、Weaviate），按语义检索
• ③ Episodic（情景记忆）：过去完整任务的执行轨迹，可作 few-shot 示例反哺新任务

🛠 实战要点（以 Google ADK 为例）

• Session：一次连续对话的容器，包含 events（消息历史）+ state（临时数据）
• State：一个 dict，按前缀区分作用域：user:（跨 session 的用户级）、app:（跨用户的全局）、temp:（仅当前 session）
• MemoryService：长期记忆的接口，对接外部向量库
• 更新方式：用 EventActions.state_delta 或 output_key，不要直接改 state dict（会绕过 framework 的 audit 和持久化）

📐 长对话压缩 4 策略

• ① Sliding Window：只保留最近 N 轮（简单粗暴，丢早期信息）
• ② Summarization：旧消息总结成一段（信息有损，细节丢失）
• ③ Vector Recall：旧消息存向量库按需检索（无损但查询慢）
• ④ Hierarchical（推荐）：最近原文 + 中期摘要 + 远期向量召回，三者组合

⚠️ 易错点

• Memory 隐私：用户要求删除某条记忆怎么办？必须支持逐条 DELETE（这也是 memory 比 fine-tuning 优越的地方之一）
• 关键信息只存摘要：丢细节后后续无法精确引用——必须 keep raw snippets in vector store
• 没设 TTL（Time-To-Live）：老旧记忆累积成噪声，影响检索准确度

🔗 与其他章节

Memory 是 Learning & Adaptation (Ch9) 的底层基础设施（memory-based learning 直接读写 episodic memory）。与 RAG (Ch14) 在技术栈上高度重叠（都用向量库）但目的不同：RAG 检索外部知识，Memory 检索 Agent 自身经验。

🎯 一句话定位

让 Agent "越用越聪明"——不是只有 fine-tuning 一种学习方式，而是包含 in-context learning、memory-based learning、self-modification 等多种范式，让 Agent 在动态环境中自主进化。

🧠 核心机制：3 种学习方式

• ① In-Context Learning：通过 few-shot 示例临时学习。最便宜、最即时、但重启即丢
• ② Memory-Based Learning：把成功 / 失败经验存进 episodic memory，下次任务前检索"过去遇到过类似情况吗"，作为 few-shot 注入。这是 Agent 自我改进的主流方式——成本低、可解释、可逐条删除（隐私友好）
• ③ Parameter Update：fine-tuning / RLHF / DPO，真改模型权重。最贵、最持久、最难撤销

🌟 前沿案例（书中重点介绍）

• SICA (Self-Improving Coding Agent)：能修改自己的代码来提升 benchmark 表现。它发明了 Smart Editor、AST Symbol Locator 等工具——典型的 self-modification
• AlphaEvolve（Google）：用 LLM + 进化算法发现新的、更高效的算法解。已经在数学、计算机科学问题上发现人类未知的解
• RLHF/RLAIF：用人类（或 AI）偏好作为 reward signal 微调模型

🛠 实战要点

• 架构：Sub-agent + Overseer：自我改进系统通常需要一个 overseer 监督 sub-agent 的修改不破坏稳定性
• Context window 是关键：system prompt、core prompts、assistant messages 的组织方式决定学习效率
• 选型路径：先尝试 ②（memory-based），效果到瓶颈再考虑 ③（fine-tune）
• 持续学习需要数据 pipeline：经验从对话流入 memory 的过程要自动化

⚠️ 易错点

• Self-modification 失控：让 Agent 改自己的代码很危险——必须有 overseer + 沙箱 + 回滚机制
• Memory 噪声：错误的 episodic 记忆会污染未来决策。需要"质量过滤"或"deprecation"机制
• Fine-tune 的成本黑洞：标注数据 + GPU 时间 + 模型评估 + 部署——比想象中贵

🔗 与其他章节

Learning 直接依赖 Memory (Ch8)。与 Reflection (Ch4) 共同构成"自我改进"机制——前者是跨任务的学习，后者是任务内的修正。Evaluation (Ch19) 是 learning 的反馈信号源。

🎯 一句话定位

Anthropic 主导的开放协议，被业界戏称为"LLM 的 USB-C"——用一套标准让 LLM 接入任何工具 / 数据源，告别"每接一个新 API 就写一遍适配代码"。2025-2026 年 Agent 工程师必备技能。

🧠 核心机制：3 类对象 + Client-Server 架构

书中明确定义 MCP 的三种核心对象：

• ① Tools：可执行操作（如 query_database、send_email）
• ② Resources：可读数据（如文件、URI、数据库表）
• ③ Prompts：参数化的 prompt 模板，让 server 推荐 prompt 给 client

架构：Host（Claude Desktop / Cursor / VS Code 等）↔ Client（Host 内置的 MCP 客户端逻辑）↔ Server（你写的工具封装）。三方通过 JSON-RPC 通信，传输层支持 stdio 和 SSE / HTTP。

🛠 实战要点

• 能力可发现：Client 启动时调用 tools/list、resources/list、prompts/list，动态发现 server 能力，不需要硬编码
• FastMCP（书中推荐）：简化 Python 实现 MCP server，几行装饰器就能暴露工具
• MCP Tools for Genmedia Services：Google Cloud 出品，让 Agent 接入 Imagen、Veo、Chirp 3 HD、Lyria 等生成媒体能力
• ADK 双向支持：既能消费现有 MCP server，也能把自己的工具包装成 MCP server 暴露

⚠️ 易错点（书中犀利提醒）

• "MCP 是 agentic interface 的契约"——但很多开发者只是把遗留 API 直接 wrap 一下就当 MCP server。例如：ticketing 系统只能"按 ID 取详情"，Agent 要总结所有高优先级 ticket → 又慢又不准。解药：底层 API 要为 Agent 重设计，增加 filter / sort / batch 能力
• Schema 写得糙：description 字段还是那个老问题——LLM 用不用对全看 description
• 认证 / 权限隔离：MCP server 暴露的工具可能被任何 client 调用，必须设计好访问控制

🔗 与其他章节

MCP 是 Tool Use (Ch5) 的标准化形态。与 A2A (Ch15) 互补：MCP 管"LLM ↔ 工具"，A2A 管"Agent ↔ Agent"。在 Multi-Agent (Ch7) 系统里，每个 Agent 可以是一个 MCP client，共享同一组 MCP servers 提供的工具池。

🎯 一句话定位

给 Agent 一个明确目标 + 进度监控机制——把"被动响应任务"的反应式 Agent，升级为"主动追逐目标 + 自我评估"的目标导向 Agent。是 autonomous operation 的核心。

🧠 核心机制：SMART 原则 + 三大监控

书中明确借用经典 SMART 原则：

• Specific（具体）— "总结报告" ❌ vs "总结这份 5 页的 Q1 销售报告" ✅
• Measurable（可衡量）— 必须有判断"做完了没"的客观标准
• Achievable（可达成）— 工具 / 数据 / 时间在能力范围内
• Relevant（相关）— 与上层目标对齐
• Time-bound（限时）— 设 deadline 防止无限 looping

三大监控组件：① Progress Tracking（每个 subgoal 完成度）；② Deviation Detection（偏离目标的动作早期报警）；③ Self-Evaluation（完成后自评是否真达成）。

🛠 实战要点（Google ADK 视角）

• 目标通过 agent instructions 传达：在 system prompt / instructions 里明确写 SMART 目标
• State management + Tool interactions 实现监控：每个工具调用都更新 state 里的进度字段
• 反馈循环触发 replan：监控发现偏离时，触发 Ch6 Planning 的 replan 逻辑
• 典型用例：客服 Agent 必须"30 秒内回应" + "解决问题" + "不能透露隐私"——三类目标同时监控

⚠️ 易错点

• 目标模糊："做个好报告" → Agent 行为也模糊。vague goal in, vague behavior out
• 没有进度可视化 → 用户不知道 Agent 在干啥，体验差
• Self-evaluation 用同一模型 → self-preference bias 又来了（同 Reflection）
• Deviation Detection 阈值太松 / 太紧：松了任 Agent 漂；紧了频繁误报

🔗 与其他章节

Goal Setting 是 Planning (Ch6) 的输入。Monitoring 是 Evaluation (Ch19) 的实时版（线上 vs 离线）。与 Guardrails (Ch18) 紧密配合——deviation detection 触发 guardrail 干预。

🎯 一句话定位

让 Agent 在真实世界的各种故障下不崩——从 tool 失败、API 限流、模型超时、context 溢出到权限不足，每种异常都有标准处置策略。是 Agent 从 demo 推向 production 的硬门槛。

🧠 核心机制：错误检测 + 处理 + 恢复

书中把 Exception Handling 拆解为三阶段：

• ① Error Detection：识别异常——invalid tool output、API 错误码（404、500）、超长响应、不合预期 schema、其他 Agent 的监控信号
• ② Handling Strategies：① Logging（记录便于诊断）；② Retries（指数退避）；③ Fallbacks（降级到备用工具）；④ Graceful Degradation（降级输出）；⑤ Notifications（通知运维或用户）
• ③ Recovery：① State Rollback；② Diagnosis（找根因）；③ Self-Correction（Agent 自己调整 plan）；④ Escalation（转人工）

🛠 5 种典型异常 + 对策

• ① Tool 失败（429 / timeout）→ 指数退避重试 + 降级到备用工具
• ② LLM 输出格式错（不合 JSON Schema）→ 把错误信息反馈给 LLM 让它自纠
• ③ 逻辑死循环（反复调用同一工具）→ 最大步数 + 模式检测 → 中断 + replan
• ④ Context 溢出→ 触发 memory 压缩 / 任务拆分
• ⑤ 权限不足→ 抛给 Human-in-the-Loop（escalation）

⚠️ 核心原则

• 能自己解决就别打扰人，解决不了立刻寻求人类协助，永远不要静默失败
• 每次失败都要 log——便于后续 root cause 分析和 retroactive testing
• 区分 transient vs permanent 错误：transient（如 network blip）适合 retry；permanent（如 invalid API key）retry 没意义，直接 escalate

📚 典型应用

• 客服 Bot：数据库连不上时降级到 cached FAQ
• 交易 Bot：金融 API 错误时立即停止并通知交易员
• 智能家居 Agent：设备掉线时尝试重连 + 用户提示

🔗 与其他章节

Exception Handling 是 Planning (Ch6) 中 Replan 的触发器。Escalation 直接对接 Human-in-the-Loop (Ch13)。与 Goal Setting (Ch11) 的 monitoring 共享同一套基础设施（state tracking + alerting）。

🎯 一句话定位

承认"AI 不该完全自治"——把人类智慧、判断力、责任感有机嵌入到 Agent 工作流，在高风险、伦理敏感、复杂决策场景下保持人类最终掌控。是负责任 AI 部署的核心机制。

🧠 核心机制：5 种 HITL 形态

书中明确列出 5 种 human 嵌入方式：

• ① Human Oversight：监控 Agent 表现（log review、real-time dashboard），不直接干预但有审计权
• ② Intervention and Correction：Agent 遇到困惑时主动请求人介入，人修正错误 / 补数据 / 指导后续
• ③ Human Feedback for Learning：人对输出打分（赞/踩）作为模型改进的 reward signal（RLHF 的精神）
• ④ Decision Augmentation：Agent 出分析和建议，最终决策权在人——典型如医疗诊断辅助
• ⑤ Human-Agent Collaboration：双向合作——日常处理交 Agent，创意 / 复杂判断交人

🛠 三种典型触发模式

• Approval Mode：高风险动作前必须人审（如转账、发邮件、写数据库）
• Confidence Mode：Agent 置信度低于阈值时自动请求人类
• Explicit Mode：用户主动按"暂停 / 接管"按钮

📐 实战要点

• UI 反馈必须即时：人等 30 秒没反应就失去耐心。给"思考中..."状态提示
• 上下文要足量：给审核者完整背景，不要让人当 ML 黑盒
• Escalation 政策必须明确：什么情况升级、升级给谁、SLA 多久回复
• 审核结果反哺训练：人的纠正信号要回流到模型 / memory，让 Agent 下次少打扰

⚠️ 易错点（书中重点警示）

• Scalability vs Accuracy trade-off：HITL 越多越准，但人手是瓶颈——必须设计"何时一定要人"的明确规则
• 依赖高技能领域专家：医疗 / 法律 HITL 需要专业人员，不是随便招个 reviewer
• 隐私问题：把数据展示给人审核可能涉及 PII，需要 anonymization
• Trainer fatigue：长时间审核 AI 输出会让人疲劳，准确率下降——需要轮岗机制

🔗 与其他章节

HITL 是 Exception Handling (Ch12) 中 escalation 的去处。与 Guardrails (Ch18) 互补——前者是兜底机制，后者是预防机制。Human feedback 是 Learning & Adaptation (Ch9) 的高质量信号源。

🎯 一句话定位

让 LLM "先查书再答"——通过检索外部知识库（文档、数据库、web），把实时、领域特定、可溯源的信息注入 prompt，克服 LLM 静态训练知识的局限，大幅减少幻觉。RAG 是 2023+ 最重要的 Agent 模式之一。

🧠 核心机制：Retrieval + Augmentation + Generation

书中给的标准流程：

1. Query 进来：不直接送 LLM
2. 语义检索：把 query 转 embedding → 向量库找最相似的 chunks
3. Augmentation：检索结果 + 原 query 拼成"增强 prompt"
4. LLM 生成：基于增强 prompt 输出回答（可附引用）

🌟 RAG 的 4 大收益

• ① 实时知识：突破训练时间 cutoff
• ② 减少幻觉：让模型基于检索内容回答而非凭空编造
• ③ 领域专精：用企业内部文档让通用 LLM 变专家
• ④ 可溯源：每个答案能指出来自哪份文档

📐 Advanced RAG（超越 Naive RAG）

• Query Rewriting：用 LLM 改写用户原始 query 让检索更准
• Hybrid Search：dense (embedding) + sparse (BM25) 融合，对术语 / 缩写更友好
• Reranker：粗排返回 100 条 → 用 cross-encoder 精排选前 5
• HyDE：先让 LLM 生成"假设答案"，用假设答案的 embedding 去检索
• GraphRAG（书中专门介绍）：构造知识图谱表达实体关系，能回答多跳推理问题（如"X 和 Y 有什么关联？"）
• Agentic RAG（书中重点）：用 Agent 主动 reason + validate + refine 检索结果，而非被动用之

⚠️ 常见失败模式

• ① 检索召回差：embedding 选错或没 reranker → 相关文档进不来。这是最常见的 RAG 故障
• ② Chunk 切坏：把"金额是" + "100 万"切两半 → 事实丢失。解药：重叠 chunking 或 parent doc retrieval
• ③ LLM 不用检索结果：仍按训练知识答。解药："你只能基于以下文档回答"的严格 prompt
• ④ 引用幻觉：检索回来了 ABC，LLM 编造"根据文档 D"。解药：output validation——用 NLI 模型逐句对照 source

📚 典型应用

企业搜索、客服知识库、法律研究、个性化推荐、医疗文献查询。

🔗 与其他章节

RAG 与 Memory (Ch8) 技术栈高度重叠但目的不同：RAG 检索外部知识，Memory 检索自身经验。在 Multi-Agent (Ch7) 里一个 Retrieval Agent 经常独立存在。Agentic RAG 把 Reflection (Ch4) + Planning (Ch6) 引入检索流程。

🎯 一句话定位

Google 主导的开放跨框架 Agent 通信协议——让 LangChain Agent、CrewAI Agent、Google ADK Agent、自研 Agent 能通过同一套 HTTP 标准互相调用、协作完成任务。是 Agent 生态走向"互联互通"的关键基础设施。

🧠 核心机制：6 大概念支柱

书中详细介绍 A2A 的六大基础概念：

• ① Core Actors：Client Agent（发起方）+ Remote Agent（响应方）
• ② Agent Card：Agent 的"数字身份证"——JSON 文件，描述 capabilities、skills、endpoint、auth 等。其他 Agent 通过它发现你
• ③ Agent Discovery：根据 Agent Card 自动发现网络中的可用 Agent
• ④ Communication & Tasks：用 tasks/send（同步请求-响应）和 tasks/sendSubscribe（流式更新）
• ⑤ Interaction Mechanisms：支持同步、异步、流式、多轮对话（input-required 状态让 Agent 能要求补充信息）
• ⑥ Security：认证、授权、加密的标准做法

🌟 生态支持

书中列出的支持者（这是协议生死的关键）：Atlassian、Box、LangChain、MongoDB、Salesforce、SAP、ServiceNow。Microsoft 计划集成到 Azure AI Foundry 和 Copilot Studio。Auth0、SAP 也在做 A2A 集成。

🛠 实战要点

• 每个 Agent 一个独立 port：模块化、独立部署、可水平扩展
• Trickle AI：可视化 + 追踪 A2A 通信的工具，对 debug 多 Agent 系统极有帮助
• 典型用例：你的 Agent 需要发邮件 → 调用 Salesforce 的 A2A Agent；需要订机票 → 调用旅行平台的 A2A Agent

⚠️ 易错点

• 认证 / 信任问题：跨组织调用 Agent 时如何确认对方身份、如何限制权限——A2A 提供协议但不解决信任本身
• 失败处理：远程 Agent 挂了 / 慢了 / 给错答案——必须有 timeout、retry、fallback
• 语义不一致：你的 Agent 理解的"订单"和别家 Agent 不一样——需要 shared ontology

📐 A2A vs MCP（关键区分）

• MCP：管"LLM ↔ 工具 / 数据"（Agent 内部能力扩展）— 类比 USB-C
• A2A：管"Agent ↔ Agent"（不同 Agent 跨组织 / 跨框架协作）— 类比 HTTP
• 不冲突，互补：一个 Agent 内部用 MCP 接工具，对外用 A2A 暴露能力

🔗 与其他章节

A2A 是 Multi-Agent (Ch7) 跨组织 / 跨技术栈的标准化形态。与 MCP (Ch10) 互补。在 Resource-Aware Optimization (Ch16) 中可用 A2A 做"远程便宜 Agent 处理简单任务"。

🎯 一句话定位

让 Agent 会"省钱省时"——根据任务复杂度动态选模型 / 工具 / 路径，平衡输出质量与计算 / 时间 / 金钱资源消耗。在 GPT-4 / Claude Opus 一次调用动辄几毛甚至几块的时代，资源优化是规模化部署的命脉。

🧠 核心机制：多 Agent 路由架构

书中给的经典架构：

• ① Router Agent：先对 incoming query 做 complexity classification
• ② Specialized Agents：根据复杂度路由到合适模型——简单 query 用便宜小模型（如 Gemini Flash），复杂推理用大模型（如 Gemini Pro）
• ③ Critique Agent：评估回答质量，给 router 反馈，持续优化路由策略

🛠 4 大优化维度

• ① Token 成本：动态选模型 + prompt compression + 用 prompt caching（Anthropic / OpenAI 都支持）
• ② Latency：能并行就并行；常见 query 做预测式缓存
• ③ 内存：长任务用 streaming summary 而非全量历史
• ④ API 配额：限速器 + 调用预算追踪

💰 模型路由的实战公式

书中暗示的 cost-saving 套路：

• 路由前置：先用 GPT-3.5 / Haiku / Flash 这种便宜模型（成本是大模型的 1/10-1/30）判断任务难度
• 根据难度调用：简单 → Haiku；中等 → Sonnet；最复杂 → Opus
• 实际效果：可把 token 成本降 60-80% 而效果几乎不变（前提是 router 准）

⚠️ 易错点

• Router 自己很贵：如果 router 用 GPT-4 来判断难度，加起来比直接用 GPT-4 还贵——router 必须用便宜模型
• 难度分类错误：把复杂任务 route 到小模型 → 答案差。需要 critique 反馈持续校准
• 忽略 latency tail：平均延迟低 ≠ p99 延迟低，p99 才决定用户体验
• 缓存命中率监控：缓存设了不监控 = 不知道实际收益

📐 Critique Agent 的角色

书中强调 critique 不只是给最终用户的"我说得好不好"——它是反哺 router的关键：当 critique 频繁报告"小模型答得不够好"时，router 自动提升下次相似 query 的模型选择。这是 self-correcting routing。

🔗 与其他章节

Resource-Aware Optimization 大量复用 Routing (Ch2) 思想。Critique Agent 本质是 Reflection (Ch4) 的应用。在 Multi-Agent (Ch7) 框架内自然实现。Evaluation (Ch19) 提供长期的 router 性能数据。

🎯 一句话定位

把 LLM 的"思考过程"显式化、结构化、可纠错——通过 CoT、ToT、Self-Consistency、Self-Correction、Program-Aided、ReAct 等技巧，让 Agent 处理需要多步逻辑、决策权衡、外部交互的复杂任务。这是 Agent 智能上限的决定性章节。

🧠 核心范式速览（按从简单到复杂排列）

• ① CoT (Chain-of-Thought)：让模型显式写"我先想 A，再想 B，所以是 C"——Agent 的"内心独白"。简单加一句"Let's think step by step"就有效
• ② Self-Consistency：CoT 跑 N 次（高 temperature），选多数投票答案。对推理 / 数学题特别有效
• ③ ToT (Tree-of-Thoughts)：搜索多个 reasoning 分支并剪枝，能"回溯"——避免单链推理一错到底。代价：token 5-10×
• ④ Self-Correction：Agent 先答 → 自检 → 修正（Reflection 的推理版）
• ⑤ Program-Aided Reasoning：LLM 写 Python 代码 → 执行 → 拿结果。对算术 / 统计 / 数据处理近 100% 准
• ⑥ ReAct (Reason + Act)：交替输出 Thought / Action / Observation，让推理过程可见可纠，是整本书最重要的范式之一
• ⑦ Reasoning Models：o1 / o3 / Claude thinking——模型内置 reasoning，不需要 CoT prompt 也能深度思考

📈 Scaling Inference Law（书中重要概念）

"Agent 的表现不只取决于模型大小，更取决于 allocated thinking time"——给 Agent 更多推理预算（更多 token 、更多步、更多 ToT 分支），即便用同样模型，结果质量显著提升。这彻底改变了"必须用最大模型"的固有思路。

🛠 实战选型

• 算术 / 逻辑 / SQL / 数据处理→ Program-Aided（让代码执行做精确计算）
• 开放分析 / 文本理解→ CoT + Self-Consistency
• 需要工具交互的任务→ ReAct
• 战略决策 / 路径规划→ ToT
• 多步任务 + 不确定→ ReAct + Self-Correction 组合

⚠️ 易错点

• 用 CoT 做算术—— LLM 算 7×13=91 有时也错。Program-Aided 才对
• ToT 不剪枝—— token 爆炸，成本失控
• ReAct 没设最大步数—— Agent 在工具间"鬼打墙"
• Reasoning Models 上当成普通 LLM 用——o1/o3 这类模型不该再加 CoT prompt，会冗余

🔗 与其他章节

Reasoning Techniques 是 Planning (Ch6)、Tool Use (Ch5)、Reflection (Ch4) 的"技巧集合"。ReAct 是 Planning + Tool Use 的具体范式。Self-Consistency 是 Parallelization (Ch3) 在推理上的应用。Program-Aided 实质是 Tool Use 的特例。

🎯 一句话定位

给 Agent 装"多层防护栏"——防 prompt injection、防有害输出、防数据泄露、防越权操作、防越狱。Guardrails 是负责任 AI 部署的最低门槛，没有它任何 Agent 都不应该上线。

🧠 核心机制：三层防御

书中明确列出 Guardrails 的三层架构：

• ① Input Guardrails：检测 prompt 注入、PII 泄露请求、违规内容、越狱尝试（如经典"ignore all previous instructions"）
• ② Output Guardrails：检测幻觉、敏感信息泄露、JSON schema 违规、有害言论、品牌敏感词
• ③ Action Guardrails：高风险动作前的策略检查——白名单（如只能调特定 API）、金额上限（转账≤500）、权限校验（用户身份核验）

🛡 5 大实现手段

• ① Input validation：分类器 + 规则检测恶意 query
• ② Output filtering：用专门模型（如 Llama Guard、OpenAI Moderation）筛选输出
• ③ Behavioral prompting：在 system prompt 里明确写"绝不讨论 X"、"必须用礼貌语言"等
• ④ Tool use restrictions：限制 Agent 能调用哪些工具、什么参数范围
• ⑤ External moderation：把内容送给独立审核服务

📐 黄金原则（书中反复强调）

• Guardrails 必须独立于主 Agent 模型——同一个 LLM 既当"裁判"又当"运动员"等于没护栏。同样的偏见 / 漏洞 / 攻击面会同步存在
• 多种技巧组合使用比依赖单一手段更稳——纵深防御
• 持续监控 + 迭代：攻击方式在演化，guardrails 也要
• 把 Agent 当传统软件工程对待：fault tolerance、state management、robust testing——这些经典工程实践不能因为是 AI 就忽略

🔧 可选工具栈

• NVIDIA NeMo Guardrails：开源 framework，用 Colang 语言定义对话流和安全规则
• Guardrails AI：Python 库，校验 LLM 输出结构和内容
• Llama Guard：Meta 开源的内容审核模型，专门做 Input/Output filtering
• OpenAI Moderation API：成熟的有害内容分类服务

⚠️ 易错点

• "对抗性输入"考虑不足：jailbreak prompt、间接注入（如让 Agent 读一封含恶意指令的邮件）
• 过度防护：把 Agent 锁太死导致正常需求被拒，用户体验差
• Guardrail 自己出错：分类器误判正常内容为违规（false positive）
• 没 audit log：被攻击后无法追踪手段

🔗 与其他章节

Guardrails 与 Goal Setting / Monitoring (Ch11) 的 deviation detection 联动——前者预防，后者侦测。Action guardrails 与 Human-in-the-Loop (Ch13) 的 approval mode 紧密配合。Evaluation (Ch19) 测的是 guardrails 是否有效。

🎯 一句话定位

让 Agent 不是"上线了就完事"——通过结构化评估 + 实时监控，持续衡量 Agent 的有效性、效率、合规性，发现退化、捕获异常、为持续改进提供数据。是 Agent 生命周期管理的最后一块拼图。

🧠 核心机制：3 层评估

书中强调评估必须分层做，只测端到端是不够的：

• ① Component-level：单步 LLM 调用、单个工具的准确率（用静态数据集做单元测试）
• ② Trajectory-level：整个执行轨迹是否合理——步骤数、工具选择、是否绕路。这是 Agent 特有的评估维度，对照"理想 ground-truth 轨迹"找偏差
• ③ End-to-end：最终输出是否满足用户目标（任务成功率、用户满意度）

📐 LLM-as-Judge（重点技巧）

用 LLM 自动评估输出已是工业标配，但有坑：

• 不要用同一个模型同时生成和判断 — self-preference bias 又来了
• 给 judge 明确的 rubric："评分 1-5，依据下列 5 个维度"
• 让 judge 必须说理由（chain-of-thought judge）— 提升准确性 + 可审计
• 定期用人类标注校准 — 防止 judge drift

🛠 实战要点（ADK 视角）

• Test Files：定义单条用例，做单元测试（component-level）
• EvalSet Files：定义场景，做集成测试（trajectory + end-to-end）
• 3 种执行方式：① Web UI（交互式 debug）；② pytest（CI/CD 集成）；③ CLI（批量自动化）
• 核心指标：accuracy（响应正确率）+ latency（响应延迟）+ token usage（成本）+ trajectory quality（路径合理性）

📊 监控的实战指标

• 任务成功率（最终输出是否满足目标）
• 平均步数 / 平均成本（resource consumption）
• p99 延迟（tail latency 决定用户体验）
• Tool error rate（工具失败率）
• Loop detection rate（死循环触发率）
• HITL escalation rate（升级人工率）
• User satisfaction score（用户主动评分）

⚠️ 常见错误

• 只测最终输出——失败的 trace 不知道哪步坏；好的输出也可能来自"坏轨迹+运气"
• 没有 A/B testing——模型 / prompt 改了不知道改善还是退步
• 没监控 data drift——线上输入分布偷偷变化，模型悄悄退化
• 评估集不更新——3 个月前的 test cases 已经不能代表当前场景

🔗 与其他章节

Evaluation 是 Goal Setting (Ch11) 的离线 / 长期版本。是 Learning & Adaptation (Ch9) 的反馈源（评估结果驱动学习）。监测 Guardrails (Ch18) 的实际效果。在 Multi-Agent (Ch7) 中特别难做（要评估"整体协作质量"而非单个 Agent）。

🎯 一句话定位

让 Agent 在"多个相互冲突的任务和目标"面前做出合理选择——综合 urgency、importance、dependencies、resource cost 等维度，决定先做什么、跳过什么、停掉什么。是 Agent 从"按命令执行"升级为"自主决策"的关键能力。

🧠 核心机制：4 大评估维度

书中明确列出 prioritization 的判断标准：

• ① Urgency（紧急度）— deadline、时效性
• ② Importance（重要性）— 对主目标的影响程度
• ③ Dependencies（依赖）— 这个任务是否是其他任务的前提
• ④ Resource Availability（资源可用性）— 需要的工具 / 数据 / 算力是否就绪
• ⑤ Cost/Benefit（成本-收益分析）— 投入产出比
• ⑥ User Preferences（用户偏好）— 个性化场景下用户的偏好排序

🛠 实现 4 步法

1. Criteria Definition：明确各维度的定义和权重
2. Task Evaluation：对每个候选任务按 criteria 打分（用规则 / LLM reasoning / hybrid）
3. Scheduling / Selection Logic：算法（queue、A*、heuristic）选出下一步
4. Dynamic Re-prioritization：环境变化时重新评分——这是关键能力，让 Agent 能在 deadline 临近、紧急事件出现时立刻调整

📐 两层优先级

• Strategic（战略层）：长期目标排序——比如季度 OKR
• Tactical（战术层）：当下下一步动作选择——比如"先回复邮件还是先开会"

🛠 实战 prompt 模板

书中暗示的工业实践：让 Agent 在 plan 阶段就输出每个 task 的 priority 字段，executor 按综合分数取任务。

{
  "task": "...",
  "urgency": 0.9,      // 0-1
  "impact": 0.7,
  "uncertainty": 0.3,
  "deps": ["task_id_1"],
  "score": 0.78        // 综合分
}

⚠️ 易错点

• 权重设错：所有任务 urgency 都打满 → 退化为先到先做
• 不做 dynamic re-prioritization：环境变了 Agent 还在执行老优先级
• 循环依赖：A 等 B，B 等 A → 死锁。需要 cycle detection
• 过度重排：每个 tick 都重新排，本身就是 overhead。需要事件触发式重排

📚 典型应用

• 个人助理 Agent：邮件 / 日历 / 待办综合排序
• 客服 Agent：多通道工单并发时决定先处理谁
• 运维 Agent：多告警同时到来时按 severity + impact 排
• 电商推荐 Agent：多商品候选时按用户偏好 + 库存 + 利润排

🔗 与其他章节

Prioritization 是 Planning (Ch6) 的执行层细化——plan 给出 task 列表，prioritization 决定顺序。与 Goal Setting (Ch11) 紧密关联（goal 决定 importance 权重）。在 Multi-Agent (Ch7) Supervisor 内部往往就是个 prioritizer。

🎯 一句话定位

让 Agent "主动探索未知"——不再被动等指令，而是自主识别知识盲点、生成假设、设计实验、发现"unknown unknowns"。这是真正的 Agentic AI 的终极形态，预示了未来 3-5 年 Agent 的发展方向。

🧠 核心机制：三种探索范式

• ① Curiosity-driven Exploration：识别知识盲点（"我不知道的部分"），主动检索 / 提问。类比一个好奇的研究员
• ② Hypothesis-driven Discovery：先生成假设 → 设计实验 → 收集数据 → 验证 / 推翻。这是科学方法的自动化
• ③ Anomaly Detection-driven：发现数据中的异常作为后续动作的触发器——典型如运维 Agent 看 metric 异常 → 自动追查根因

🌟 前沿案例（书中重点）

• Google Co-Scientist：能自主生成科研假设、设计实验、辅助人类科学家——已经在生物医学领域帮研究者找到新候选药物
• Agent Laboratory：多 Agent 框架，分饰研究员、实验员、写作员等角色，自动完成文献综述 → 实验 → 报告全流程
• AlphaEvolve（与 Ch9 学习章呼应）：探索 + 进化算法发现新算法

🛠 实现模式：多 Agent 模拟科学方法

书中描绘的典型架构：

• Hypothesis Generator Agent：基于已知文献生成多个假设
• Critic Agent：对假设的合理性、可验证性、新颖性打分
• Experiment Designer Agent：把假设转换为可执行的实验 / 查询 / 测试
• Evolver Agent：从结果中挑出 promising 假设，进化（变异 / 组合）成下一代
• Report Writer Agent：把整个过程整理成可读报告

📐 典型应用

• 科学研究助手：自动文献综述、假设生成、实验设计
• 自动数据洞察（DataAgent 类）：从公司数据中主动发现异常和机会，而非等人提问
• 漏洞挖掘 Agent（fuzz Agent）：自主探索代码 / 系统的脆弱点
• A/B 测试设计助手：根据业务指标自动提出值得测的假设
• 自动 prompt 工程：尝试新 prompt 变体并自评效果

⚠️ 易错点

• 探索 vs 利用平衡：纯探索浪费资源，纯利用没新发现。需要 ε-greedy / UCB 类算法平衡
• 假设质量不可控：生成的假设很多是低质量的——必须有强 Critic 过滤
• 无法验证的假设：超出可用工具 / 数据范围。需要先评估"是否可测"
• 计算成本爆炸：探索可以无限消耗资源 — 必须设 budget

🌌 哲学意义

书中把这一章放在最后，是因为 Exploration & Discovery 代表了 Agent 的真正"能动性"——从"完成任务"到"发现任务"，从"按指令做"到"自主探索"。这才是 Antonio Gulli 心目中"真正 Agentic"的样子。

🔗 与其他章节

Exploration 是 Planning (Ch6) + Reasoning (Ch17) + Multi-Agent (Ch7) + Learning (Ch9) 的集大成应用。Hypothesis generation 是 Reflection (Ch4) 的反向——从"批判已有"转向"提出新的"。这一章是整本书的高潮，所有前 20 个模式在这里融汇。