谈谈智能体设计模式——写在读完《Agentic Design Patterns》之后

发表于 更新于 分类于 本文字数： 15k 阅读时长 ≈ 13 分钟
本文是对Google《Agentic Design Patterns》一书的深度解读，系统性地介绍了七种核心智能体设计模式：提示链、路由、并行化、反思、工具使用、规划和多智能体。文章还深入探讨了记忆力管理、学习与适应、MCP协议、目标管理、A2A协议等高级主题，以及防护机制、评估监控等生产级系统必备能力，为智能体开发者提供了全面的设计模式参考。

解读《Agentic Design Patterns》：智能体设计模式

上个世纪末，程序员还是一种神秘、多金、高科技职业的时候，在面试时通常会被问到软件工程中的设计模式。时隔 20 多年之后，Google 公司 Antonio Gulli 又发布了《Agentic Design Patterns》——智能体设计模式（其实我更倾向于 “智能体化的设计模式”）。可以说，内容的输出非常结构化（中性的评价），有些也非常接地气。本次文章做一个归纳解读，最后也说说自己的一些看法和思考。

7 种核心模式

所谓模式（Pattern）的出现主要是为了解决反复出现的问题，Antonio 写这些内容也出于同样的初心，期望能帮助智能体开发者解决如下问题：

  • 系统地构建智能系统（Structure intelligent systems systematically）
  • 结合多种 AI 能力来构建，比如推理、规划
  • 记忆、上下文以及适配（Adaptation）
  • 安全、一致以及鲁棒性
  • 从单智能体到多智能体生态系统

提示链（Prompt Chaining）

在制作智能体或想要 “智能体化” 一套系统时，需要意识到单一提示词所能解决的问题有限，且很容易发生因为大模型认知过载导致的 “指令忽略”、“上下文漂移” 等问题。

尤其在处理复杂问题、描述复杂需求时，我们应主张分而治之的策略，将单一、整体的步骤分解为更小、更易于理解的子问题。究其原因，目前大模型还是会有幻觉问题和上下文窗口问题，更何况，人类在描述一项复杂任务时本身就很有可能忽略重点，表达思路上不清晰（想想你的老板给你安排任务时的样子吧！）。从工程角度而言，做这种拆分既可以迫使需求被澄清，同时也能在多个步骤中进行用户意图确认和工具调用。同时需要注意的是，一个步骤的输出作为下一个步骤的输入至关重要，这会让信息形成依赖链，使得大语言模型能够在之前的工作基础上持续理解需求，并逐步接近预期方案。

在执行需求链的过程中，则可以引入其它工具进行辅助处理，如发票读取例子中使用到的 OCR，或对 Web 进行检索，或进行多模态处理。

在上下文长度成为大模型先进性特征之一的今天，上下文工程会成为智能体开发工程师所需要具备的基本技能，也是需要做归纳、做方法论的最核心技能。

路由（Routing）

路由模式通过在智能体的操作框架中引入条件逻辑，提供了一种标准化的解决方案。它使系统能够首先分析传入的查询，以确定其意图或性质。

基于此分析，智能体动态地将控制流导向最合适的专用工具、函数或子智能体。这一决策可通过多种方法实现，包括提示大语言模型、应用预定义规则或使用基于嵌入的语义相似度。最终，路由将静态的、预先确定的执行路径转变为能够选择最佳可能行动的灵活且具有上下文感知能力的工作流。

在一些跟风讲概念的公司中，经常可以听到所谓” 意图理解 “，但通常停留在单一线性的 if else 这种较为初级的阶段。Routing 不仅需要理解意图，还需要根据理解后的意图进行后端决策和执行。从另一个层面讲，这也是为提示链、多智能体等模式做顶层设计上的准备。最终，路由提供了逻辑仲裁的能力，这对于创建功能多样且具有上下文感知能力的系统至关重要。它将智能体从预定义序列的静态执行者转变为一个能够做出（决策的）动态系统。

这里有一条非常有用的经验法则：当智能体必须根据用户输入或当前状态在多个不同的工作流、工具或子智能体之间做出选择时，使用路由模式。这对于需要对传入请求进行分类或归类以处理不同类型任务的应用程序至关重要，例如客户支持机器人要区分销售咨询、技术支持和账户管理问题。Routing 模式可以让智能体从 “听懂人话” 到 “办成人事”，体感上真正像人类一样在思考、决策和执行。

并行（Parallelization）

这个不想讲特别多，有一些编程经验的小伙伴能很快理解，其核心是在智能体工作流中识别无依赖关系的子任务（如多源信息检索、独立数据分析），借助一些工具框架（如 LangChain 的 RunnableParallel、Google ADK 的 ParallelAgent 等）实现并发执行而非顺序等待，最终聚合结果以显著降低总耗时，适用于多源信息收集、批量数据处理、多 API 并行调用等场景。

这里提到的并行模式与传统并行编程高度相似，二者均以 “并发处理独立任务” 为核心思想，目标都是突破顺序执行的效率瓶颈，实现逻辑上均需先拆分独立任务单元、再通过专门机制（智能体框架的并发组件 vs 传统编程的多线程 / 多进程库）管理并发，最后整合结果，本质是将传统并行的 “代码任务并发” 迁移到智能体的 “子任务 / 工具调用并发” 场景。

反思（Reflection）

如果智能体设计模式中的并行和传统编程中的并行几乎是同一个概念，那 Reflection 基本就只是名字相同了。传统编程中我们有时会把 Reflection 叫做映射，可以干一些危险的事情。但此处更应理解为” 反思 “，或者说修订。

我在使用 ChatGPT 时，会预置一个前提，要求每次的回答需要具备” 批判性思维 “，这对于常规的、标准化的回答时可能会有一些比较有创意的输出。反思模式常采用 “Producer-Critic（生产者 - 批评者）” 双智能体模型 ——Producer 生成初始输出，Critic 按预设标准（事实准确性、代码健壮性、内容完整性等）评估并提供结构化反馈，Producer 再基于反馈修订，直至满足要求或达最大迭代次数。当然了，伴随反思会带来更多的 token 消耗，在智能体系统的核心和非核心模块，开发者或产品经理需要做出取舍以达到资源消耗的均衡。

工具使用（Tool Use）

这里的工具使用（Tool Use）确切说是指的 Function Calling 而不是 MCP，当智能体需要跳出大语言模型的内部知识并与外部世界交互时，使用工具使用模式。这对于需要实时数据的任务（例如，查看天气、股票价格）、访问私人或专有信息（例如，查询公司数据库）、执行精确计算、运行代码或触发其他系统中的操作（例如，发送电子邮件、控制智能设备）至关重要。

好吧，我知道你想说 MCP，我摊牌了，我不同意其它人说的 Function Calling 和 MCP 是互补关系，我认为它们两个只保留一个就好了，而 MCP 更加规范一些。但从另一个层面看，短期内 Function Calling 的效率绝非 MCP 可比，就好像 Claude Code 回过头来使用 grep 而非向量查询做代码搜索。所以短期看，MCP 和 Function Calling 还会使一个相辅相成的局面。

规划（Planning）

当用户的请求过于复杂，无法通过单一操作或工具处理时，可使用规划模式。它非常适合自动化多步骤流程，例如生成详细的研究报告、新员工入职培训或执行竞争分析。只要任务需要一系列相互依赖的操作以达成最终的综合结果，就可以应用规划模式。

非常典型的例子就是深度研究（DeepResearch），文中举例 Gemini DeepResearch，通过 “反思 - 规划 - 执行” 循环实现深度研究。用过类似深度研究产品的小伙伴会知道，它主要实现自主信息检索与合成，通过多步骤的智能体流程运行，能动态且迭代地查询谷歌搜索，从而系统地探索复杂主题。该系统经设计可处理大量基于网络的来源，评估收集到的数据的相关性和知识缺口，并开展后续搜索以填补这些缺口。最终输出会将经过审核的信息整合为结构化的多页摘要，并附有原始来源的引用，就像你写了一篇论文一样。

当你的智能体化的系统需要处理非常复杂的问题、没有明确实现路径以及依赖信息是动态变化时，规划模式对于输出结果质量的影响显而易见，既包含链，也包含修订，还可以批判性思维。当然，规划模式对于算力的消耗惊人，这也是为什么有一段时间即使你开了订阅，深度研究也是会被限量的。

多智能体（Multi-Agent）

多智能体模式在国内也广为熟知，经验法则：当一项任务过于复杂，单个智能体难以完成，且可分解为需要专业技能或工具的不同子任务时，可采用此模式。对于那些能从多样化专业知识、并行处理或多阶段结构化工作流程中受益的问题，例如复杂的研究与分析、软件开发或创意内容生成，这种模式尤为适用。

武断一点说，但凡你的智能体系统对应到人类角色中是跨工种的（比如 IT、财务和法务），那么你就可以考虑在该系统中使用多智能体模式。这种场景下甚至可以直接复用原有的流程，主要的工作量会集中在制作这些” 专业 “智能体本身。

当然，从客户层面看，这些内容应该是透明的。客户只需要认识一个主理人，而不需要认识其背后的” 团队 “。

核心模式之后：让智能体更聪明的 4 种手段

1. 记忆力管理（Memory Management）

有次和大神朋友聊天，总结出了一个类比，上下文就好比内存，长记忆则是硬盘。

记忆力的管理，简单说就是教 AI “怎么记东西”—— 毕竟 AI 不像人，不刻意设计 “记忆”，聊完天就忘，也记不住你的偏好。这份文档把 AI 的记忆分成两种，就像人一样：

  • 上下文：记 “当下的事”，比如你正在和 AI 聊的内容、刚用工具查的结果。但 AI 的短期记忆有 “容量上限”（比如只能记住最近 100 句话），所以得想办法精简（比如总结老对话、突出重点）。比如你和 ChatGPT 聊天，它能接得住你上一句的话，靠的就是短期记忆。
  • 长期记忆：记 “跨场景的事”，比如你的名字、喜欢的风格、之前提过的需求（比如 “我对芒果过敏”）。这些内容会存在专门的存储里（比如能按 “意思” 找数据的数据库，不是按关键词硬搜），AI 需要时就调出来用，比如下次你再聊 “推荐水果”，它会记得避开芒果。

比如用 Google 的 ADK 框架时，“Session” 就是单轮聊天的 “记忆本”（记聊天记录），“State” 是这本子里的 “便签”（记临时数据，比如 “当前任务进度”）；“MemoryService” 就是长期记忆的 “储物柜”，负责存和取跨聊天的数据。另外也提了 LangChain 这类框架，比如用 “ConversationBufferMemory” 让 AI 自动记聊天历史，不用手动管。

当智能体需要完成的任务不止是回答单个问题时，就使用这种模式。对于那些必须在整个对话过程中保持语境、跟踪多步骤任务进度，或者通过回忆用户偏好和历史来实现个性化互动的智能体而言，这一点至关重要。当智能体需要根据过去的成功、失败或新获取的信息进行学习或调整时，都要实施记忆管理。

目前也有不少开源框架可以实现长短记忆服务，比如 mem0。体现到产品上时，比如 ChatGPT，用户授权后则会不停更新记忆，越来越认识你。

2. 学习和进步（Learning and Adaptation）

讲 AI 怎么 “越用越厉害”，不是一开始写死代码就不变了，而是能从经验、数据里学东西，适应新情况。首先说 AI 有几种 “学习方式”，比如：

  • 强化学习：像训宠物，做对了给 “奖励”（比如游戏得分高），做错了给 “惩罚”（比如输了游戏），慢慢学出最优策略（比如机器人学走路、游戏 AI 学通关）；
  • 监督学习：给 AI 一堆 “例子”，让它学规律（比如给 1000 张猫图，让它学会认猫）；
  • 还有更灵活的 “少样本学习”：不用给很多例子，跟 AI 说清楚规则，它就能上手（比如让它 “按‘姓名 - 年龄’格式整理列表”，说一次就会）。

还举了几个真实的 “会自学的 AI” 例子：

  • SICA（自改进编程 AI）：自己改自己的代码变厉害 —— 比如一开始只会简单改文件，后来自己开发出 “智能编辑器”，能精准改代码，还会用代码结构找错误，靠的就是每次改完后测试、记教训；
  • AlphaEvolve（谷歌的 AI）：专门优化 “算法”，比如让数据中心更省电（省了 0.7% 的全球算力）、让 GPU 运算更快，甚至在数学领域找到新的解题方法；
  • OpenEvolve：帮人优化代码，支持多种编程语言，能反复改代码直到满足需求（比如 “运行更快”“bug 更少”）。

3. MCP（Model Context Protocol (MCP)）

解决一个大问题：以前 AI 想连外部工具（比如查数据库、发邮件、调摄像头），得针对每个工具写一套 “专属接口”—— 比如给 AI 写 “查天气” 的接口，再写 “发邮件” 的接口，很麻烦。MCP 就是给 AI 和工具造了个 “通用插座”：只要 AI 和工具都符合 MCP 标准，不管是哪款 AI（比如 Gemini、GPT），哪款工具（比如公司数据库、家里的智能灯），都能直接连，不用再定制接口。打个比方：普通的 “工具调用” 是给 AI 一把 “特定的扳手”，只能拧一种螺丝；MCP 是给 AI 一个 “万能插座”，任何带 “MCP 插头” 的工具都能插上去用。还讲了怎么用：比如用 Google 的 ADK 建一个 “文件管理 MCP 服务器”，AI 就能通过这个服务器读 / 写电脑文件；用 FastMCP（简化工具）建一个 “打招呼服务器”，AI 就能调用这个服务器给人发 “Hello，XX”—— 全程不用写复杂接口，按标准配就行。

4. 目标管理（Goal Setting and Monitoring）

让 AI “不瞎忙”—— 以前 AI 可能只会 “你让做什么就做什么”，比如你说 “写代码”，它写完就完了，不管好不好用、有没有满足需求。这份文档教 AI“先定目标，再盯着目标做，没做到就改”。核心是 “目标明确 + 实时监控”：

  • 目标要具体，比如 “写一个找‘二进制间隙’的 Python 代码，要求：简单好懂、能处理所有正整数、带例子输出”（不是模糊的 “写个好代码”）；
  • 监控就是 AI 做完一步后 “自查”：比如写完代码后，AI 自己对照目标检查 “是不是简单？有没有漏了边缘情况？”，如果没达标就返工，直到符合目标，或者到了最大尝试次数（比如最多改 5 次）。

还提了更靠谱的做法：让多个 AI 分工 —— 比如一个 “程序员 AI” 写代码，一个 “审查 AI” 找 bug，一个 “文档 AI” 写说明，一个 “测试 AI” 写测试用例，这样比单个 AI “又写又查” 更客观，不容易出错。最后强调目标要符合 “SMART 原则”：具体、可衡量、能实现、和需求相关、有时间 / 次数限制（比如 “3 次内改好代码”）。

关于可靠性和人机协同

异常处理和恢复（Exception Handling and Recovery）

AI 在实际用的时候，总免不了出岔子：比如调用工具时输入错了、连不上数据库、API 报错（像 404 找不到页面、500 服务器出错），或者拿到的结果乱七八糟。如果 AI 一遇到这些问题就崩溃、停摆，根本没法在真实场景里用 —— 比如客服机器人查不了用户数据就卡死，用户体验会很差；交易机器人遇错就停，可能耽误事。所以必须做 “异常处理和恢复”，让 AI 遇到问题不慌，能应对、能恢复，保障稳定运行。

实操方面，整个过程分三步：先 “detect 错误”，让 AI 能发现不对劲 —— 比如盯着工具输出是不是有效、API 有没有报错代码、响应时间是不是太长，甚至用专门的监控系统提前找异常；再 “ handle 错误”，发现问题后有应对办法：先把错误细节记下来（方便后续修），如果是临时问题（比如网络波动）就重试几次，重试不行就用备用方案（比如查不了精确位置就查大概区域），实在没法全恢复就 “降功能”（比如客服机器人查不了数据，就先简单安抚用户，不崩溃）；最后 “ recover 恢复”，要么退回到之前没出错的状态（叫 “状态回滚”），要么查出问题原因（比如是工具坏了）避免再犯，实在搞不定就告诉人类来帮忙（比如把复杂错误升级给工程师）。

人机协同（Human-in-the-Loop）

AI 虽然厉害，但有很多事做不好：比如遇到模糊的情况（像判断一段内容算不算 “仇恨言论”）、需要伦理或高风险决策（比如给企业批大额贷款、决定法律案件的量刑），或者需要同理心（比如安抚特别生气的客户）—— 这些事得靠人类的判断和情感理解。如果让 AI 单独做这些事，很容易出错，甚至引发严重后果。所以要搞 “人机协同”，用人类的优势补 AI 的短板，让 AI 在复杂、高风险场景里更靠谱，还能通过人类反馈让 AI 越用越好。

在这部分的落地建议中，核心是 “AI 做简单的，人类管复杂的，还能帮 AI 进步”。第一步，让 AI 承担常规、重复的活：比如用 AI 快速筛选海量内容（像初步过滤垃圾信息）、处理简单客服问题（比如回答 “怎么改密码”）、给数据打基础标签，省人类的力气；第二步，遇到 AI 搞不定的，就转给人类：比如 AI 拿不准的内容审核、复杂的技术故障，或者用户情绪特别激动的情况，触发 “ escalation 升级”，让人类接手处理；第三步，人类给 AI 反馈：比如 AI 写的文案不符合要求，人类修改后，把修改逻辑告诉 AI；AI 标错的数据，人类纠正后，AI 能学习正确的判断，慢慢变得更准 —— 形成 “人类帮 AI 优化” 的循环。

知识检索（Knowledge Retrieval (RAG)）

RAG 这个大家就比较熟悉了，平时的 AI（比如 LLM）虽然能生成像人一样的文字，但知识有两个大短板：一是知识 “过时且固定”，只限于训练时的数据，没有实时新闻、公司内部文档这类 “新的、专属的信息”；二是容易 “瞎编”（也就是文档里说的 “hallucination”），给出没根据的答案。为了让 AI 的回答更准、更有依据，还能用到最新或专属的知识，就需要 RAG—— 简单说就是让 AI “先查资料再说话”，把外部知识整合进来，解决自身知识局限的问题。

RAG 的落地方面，核心流程分两步：先 “检索” 再 “增强”。第一步检索，AI 接到用户问题后，不会直接回答，而是先去查外部知识库（比如文档库、网页）—— 而且不是简单搜关键词，是 “语义搜索”：先把问题和知识库的内容都变成能代表 “意思” 的数字（叫 “嵌入”），存在 “向量数据库” 里，通过算 “语义距离” 找到最相关的内容片段（比如把长文档拆成小 “块”，只找有用的块）；第二步增强，把找到的相关片段附在原问题里，一起交给 AI，让 AI 结合这些 “证据” 生成回答。同时，还能通过高级玩法优化，比如用 GraphRAG（靠知识图谱找关联信息）或 Agentic RAG（加个 “小助手” 先检查检索到的资料对不对、有没有矛盾），让检索更准。

可扩展的智能体系统

从 15 章 - 21 章，基本就在讲智能体化系统的 Scaling 了。对于关注工程化、企业级和智能体产品差异化的朋友，可以多读一读这部分，内容和实操上都相对要高阶一些。

智能体间通信（A2A）

先说说 A2A 协议。其实 Google 一派向来对顶层话语权（底层技术）尤为重视。Anthropic 的 MCP，Google 本地的 A2A，既是技术场景催生的技术产物，也是为自己在 AI 领域的主导地位铺路。虽然笔者个人认为 Function Calling、MCP 和 A2A 过于繁杂，迟早会有新的融合替代方案，但当下阶段，还需要考虑业务苟且的问题。

整体上看，A2A 的设计比 MCP 要更精致和深思熟虑，Inter-Agent Communication (A2A) 协议是谷歌推出的开放 HTTP 标准，旨在解决不同框架（如 LangGraph、CrewAI、Google ADK）AI 代理的协作难题，通过核心 Actors（用户、A2A Client、A2A Server）、Agent Card（含代理身份、能力等信息的 JSON 文件）、多类交互机制（同步请求 / 响应、异步轮询、SSE 流、Webhooks）及 mutual TLS (mTLS) 等安全机制，实现代理间无缝协调、任务 delegation 与信息交换，可应用于多框架协作、自动化工作流编排等场景，且提供 Java/Go/Python 代码示例（仓库： https://github.com/google-a2a/a2a-samples ），与聚焦 “代理与外部数据工具交互” 的 Model Context Protocol (MCP) 互补，共同推动模块化、可扩展的多代理 AI 系统发展。

当你需要协调两个或多个人工智能智能体之间的协作时，可使用此模式，尤其是当这些智能体是基于不同框架构建时。它非常适合构建复杂的模块化应用程序，在这类应用中，专门的智能体处理工作流的特定部分，例如将数据分析委派给一个智能体，将报告生成委派给另一个智能体。当一个智能体需要动态发现并利用其他智能体的能力来完成任务时，此模式也必不可少。

资源感知优化（Resource-Aware Optimization）

资源感知优化这一章深谋远虑，有些智能体系统话题中 AIOps & FinOps 的意味，也非常考验一个团队的软实力。什么情况下适合做资源感知优化呢？API 调用或计算能力有严格的财务预算；构建对延迟敏感、快速响应至关重要的应用程序；在资源受限的硬件（如电池寿命有限的边缘设备）上部署智能体；通过编程平衡响应质量与运营成本之间的权衡；以及管理复杂的多步骤工作流，其中不同任务有不同的资源需求。

本质上讲，资源感知优化需要在智能体运行过程中，动态监控和管理计算、时间和财务三类核心资源。例如动态选择高精度高成本模型 vs. 快速低成本模型，或是不是应该为响应需求更高的 Module 分配额外计算资源等等。文章举了个例子，若金融分析师需即时初步报告，智能体用快速低成本模型总结数据趋势；若需高精度投资预测且预算 / 时间充足，则调用高算力但缓慢的预测模型。同时，“fallback 机制” 是核心保障策略 —— 当首选模型因过载或限流不可用时，系统自动切换至默认 / 低成本模型，确保服务连续而非完全失效，实现 “优雅降级”。

总结起来，文档明确了资源感知优化的六大核心应用方向，覆盖不同资源约束场景，具体包括：

  1. 成本优化的 LLM 使用：基于预算约束，为复杂任务选择大型高成本 LLM，为简单查询选择小型低成本 LLM；
  2. 低延迟敏感操作：实时系统中，选择更快但推理范围可能较窄的路径，确保响应及时；
  3. 能效优化：针对边缘设备或低电量场景，优化处理流程以节省电池寿命；
  4. 服务可靠性 fallback：主模型不可用时自动切换备用模型，保障服务连续性；
  5. 数据使用管理：优先获取汇总数据而非完整数据集，节省带宽与存储；
  6. 自适应任务分配：多智能体系统中，智能体根据自身当前计算负载或可用时间自主分配任务。

推理技术

文中所讲的推理技术更高级一些，主要围绕智能体的多步逻辑推理与问题求解展开，核心原则是：在推理过程中分配更多计算资源（如延长处理时间、允许迭代优化、调用外部工具），替代 “单轮快速生成” 模式。这一原则可显著提升智能体在复杂任务中的准确性、连贯性与鲁棒性，并使内部推理过程 “显性化”，便于问题分解与中间步骤验证。

在这一节中主要系统性的介绍了 6 种推理技术：

1. Chain-of-Thought（CoT，思维链）

  • 定义：通过引导 LLM 生成分步推理步骤，替代直接输出答案，模拟人类思考过程（见图 1）。
  • 核心优势：将 “单步复杂问题” 拆解为 “多步简单子问题”，提升推理透明度（便于调试）与准确性。
  • 实现方式：
    • 提供 few-shot 示例（展示分步推理）；
    • 直接指令 “think step by step”。
  • 示例：解释 “经典计算机与量子计算机差异” 时，先分析查询需求→生成搜索词→模拟信息检索→合成内容→审核优化（见文档中 “Information Retrieval Agent” 案例）。

2. Tree-of-Thought（ToT，思维树）

  • 定义：在 CoT 基础上扩展为多路径推理树结构（见图 2），允许 LLM 探索多个中间步骤分支。
  • 核心优势：支持回溯（放弃无效路径） 、自校正与多方案评估，适用于需要战略决策的复杂任务。
  • 关键逻辑：先生成多个推理轨迹，再评估各轨迹合理性，最终选择最优路径输出答案。

3. Self-Correction（自校正）

  • 定义：智能体对自身生成的中间结果 / 最终输出进行内部批判性评估，迭代修正漏洞（如事实错误、信息缺失、表达模糊）。
  • 核心流程（5 步）：
    1. 理解原始需求（明确目标与约束）；
    2. 分析当前内容（定位问题）；
    3. 识别差距（准确性 / 完整性 / 吸引力等）；
    4. 提出具体改进方案；
    5. 生成修订内容。
  • 示例：优化 “GreenTech Gadgets” 社交媒体文案时，将 “ generic 表述” 改为 “强调 eco-friendly + 动态动词 + emoji + 话题标签”（字符数控制在 150 以内）。

4. Program-Aided Language Models（PALMs，程序辅助语言模型）

  • 定义：整合 LLM 的自然语言理解能力与符号推理工具（如 Python 代码） ，将复杂计算 / 逻辑操作 “卸载” 给代码执行环境。
  • 核心优势：弥补 LLM 在精确计算（如数学公式、数据处理）上的不足，提升结果确定性。
  • 示例：Google ADK 框架中，“CodeAgent” 通过 BuiltInCodeExecutor 执行代码，验证数学计算或代码生成结果。

5. Reinforcement Learning with Verifiable Rewards（RLVR，可验证奖励强化学习）

  • 定义：针对 CoT 的 “单一路径局限性”，训练 LLM 生成动态长推理链（可达数千 token），通过 “已知正确答案”（如数学题、代码题）进行奖励反馈。
  • 核心优势：实现无人工监督的推理能力进化，支持自校正、回溯等复杂行为（难题分配更多 “思考时间”）。

6. ReAct（推理与行动结合）

  • 定义：以 “Thought-Action-Observation” 为核心循环（见图 3），将 CoT 推理与外部工具交互（如数据库查询、API 调用）结合。
  • 核心优势：突破 “纯生成模型” 的局限，使智能体能动态适应环境反馈（如搜索补全信息、修正错误操作）。
  • 关键逻辑：思考（规划步骤）→行动（调用工具）→观察（获取反馈）→再思考（调整计划），直至完成任务。

当问题过于复杂，无法通过单次回答解决，且需要分解、多步骤逻辑、与外部数据源或工具交互，或者需要战略规划和调整时，可使用这些推理技巧。对于那些展示 “推导过程” 或思考过程与最终答案同样重要的任务，它们是理想之选。更多的，可以体味一下其中所述的 Scaling Inference Law（推理缩放定律，指出小模型配更多推理资源可能超越大模型），参数量大的模型更强大，但在智能体实际体验中，未必。

防护机制 / 安全模式（Guardrails / Safety Patterns）

很多人在 AI 时代大谈 AI 安全，其主要出发点是限制智能体 / 大语言模型能力。但实际上，这一章的立意更为宏大，其模式目标是构建负责任 AI 系统，确保行为可预测、合规，防操纵。实操层面却也更落地，比如结合上面所讲的资源感知优化模式，利用 “Flash” 模型作为额外防护模型，预筛选输入或复核主模型输出。

文章中有个较长的代码示例，通过 CrewAI（基于 Pydantic 模型、政策执行 Agent 及验证函数预筛选用户输入）与 Vertex AI（基于回调函数验证工具调用前的用户 ID 权限）两个代码示例演示实操。有兴趣的朋友可以去查阅其源代码，总结下来这个 demo 有 3 个核心设计要点：

  1. SAFETY_GUARDRAIL_PROMPT：提供 “政策执行 Agent” 的判断依据，明确 4 类安全政策（防越狱、禁有害内容等）、评估流程（违反任一政策即不合规）及输出格式，是合规判断的 “规则源头”；
  2. PolicyEvaluation（Pydantic 模型）：定义结构化输出模板，强制 LLM 输出含 compliance_status 等 3 个关键字段，避免输出格式混乱导致后续无法判断合规性，是 “结构化约束” 核心；
  3. validate_policy_evaluation 函数：技术层面验证 LLM 输出是否符合 Pydantic 模型，处理 markdown 清理、JSON 解析错误，确保输出可被系统识别，是 “格式校验与错误处理” 的关键屏障。

在任何人工智能智能体的输出可能影响用户、系统或企业声誉的应用程序中，都应实施防护措施。防护措施对于面向客户的自主智能体（例如聊天机器人）、内容生成平台以及在金融、医疗保健或法律研究等领域处理敏感信息的系统而言至关重要。应使用防护措施来执行道德准则、防止错误信息传播、保护品牌安全，并确保符合法律法规。

评估与监控（Evaluation and Monitoring）

在实时性能和可靠性至关重要的实时生产环境中部署智能体时，此模式是至关重要的。此外，当需要系统地比较智能体的不同版本或其底层模型以推动改进，以及在需要合规性、安全性和伦理审计的受监管或高风险领域运行时，也可使用此模式。当智能体的性能可能因数据或环境的变化（漂移）而随时间下降，或者在评估复杂的智能体行为（包括行动序列（轨迹）以及诸如有用性等主观输出的质量）时，此模式也适用。主要通过定义指标、建立反馈循环、实现报告系统，确保智能体在运营环境中符合预期。

要实现改进，需要先实现智能体系统的可观测性。文章总结了 5 点最佳实践：

  1. 定义清晰且可衡量的目标与指标：为评估提供明确基准，避免模糊性；
  2. 结合定量与定性数据：全面反映表现（如定量的 “响应时间”、定性的 “用户满意度”）；
  3. 定期且持续地收集数据：避免数据断层，确保评估的时效性与连续性；
  4. 激励智能体：通过奖励机制提升其主动优化性能的意愿；
  5. 提供反馈与指导：针对评估结果给出改进方向，帮助智能体迭代。

实现层面可以参考文中给出的源代码，另外，在实际构建一个智能体系统时，我们可以花更多的精力在智能体轨迹评估中，传统软件测试是 “确定的 pass/fail”，而智能体为概率性操作，需同时评估 “最终输出” 与 “轨迹”（达成解决方案的步骤序列）。这对于产品经理、研发人员和 QA 团队都有 “新时代” 的技能要求和 sense 要求。

总的来说，Evaluation and Monitoring 是对智能体的有效性、效率及合规性进行持续外部测量，区别于前面的目标设定和推理技术，这里提出了 “定义清晰可衡量目标与指标、结合定量和定性数据、定期持续收集数据、激励智能体、提供反馈指导” 这 5 大最佳实践，涵盖实时系统性能跟踪、A/B 测试、合规与安全审计、漂移检测等应用场景，介绍了响应准确性评估（含基础函数局限及 Levenshtein 距离、语义相似度等进阶 NLP 方案）、延迟监控（需存入持久化系统）、LLM 交互 token 跟踪（如 LLMInteractionMonitor 类）等技术，还提出 LLM-as-a-Judge 评估主观特质（如法律调查问题的质量），强调通过轨迹评估适配智能体的概率性操作，针对多智能体系统需评估协作有效性等，提出从简单智能体到 “承包商” 模型的演进（含正式合同、动态协商反馈等四大支柱），并介绍了 Google ADK 的 web UI、pytest、命令行 3 种评估方式，为智能体在动态、高风险环境中的可靠应用提供系统性框架。

优先级排序（Prioritization）

这一章内容非常简单易懂，但非常难执行。当智能体系统必须在资源限制下自主管理多个（通常相互冲突的）任务或目标，以便在动态环境中有效运行时，可使用优先级排序模式。其实在实际生活和工作中，从基层到高管，或多或少都存在优先级管理的问题。笔者认为，提出 Prioritization 更多是现实问题在智能体系统中的投射。在复杂动态环境中，AI 智能体常面临多潜在行动、冲突目标与有限资源的问题，优先级排序（Prioritization）模式通过明确任务评估标准（如紧迫性、重要性、依赖性等）、执行任务评估、应用调度逻辑及支持动态重排序，解决智能体效率低、延误或目标未达成的问题；该模式可作用于高层面目标选择、子任务排序、即时行动筛选三个层级，广泛应用于自动化客户支持、自动驾驶、 cybersecurity 等场景，且文档通过 LangChain 实现了项目管理 AI 智能体的代码示例（支持任务创建、优先级分配（P0/P1/P2）、人员指派），最终帮助智能体聚焦关键任务，提升有效性与目标对齐度。

可以参考（不）紧急 /（不）重要四象限，但文章的总结更加复杂一些，还有算法、评估相关，总结起来有 4 大核心要素：

  1. 标准定义：建立任务评估的规则 / 指标，包括 6 类关键维度：
    • 紧迫性：任务的时间敏感性
    • 重要性：对核心目标的影响程度
    • 依赖性：是否为其他任务的前置条件
    • 资源可用性：必要工具 / 信息的就绪状态
    • 成本收益分析：投入精力与预期成果的权衡
    • 用户偏好：针对个性化智能体的定制需求
  2. 任务评估：基于上述标准对每个潜在任务进行评估，方法覆盖 “简单规则” 到 “LLM 复杂评分 / 推理”。
  3. 调度 / 选择逻辑：通过算法（如队列、高级规划组件）基于评估结果，选择最优的下一个行动或任务序列。
  4. 动态重排序：智能体可根据环境变化（如新关键事件出现、截止日期临近）调整任务优先级，保证适应性与响应速度。

探索与发现（Exploration and Discovery）

在解决方案空间未完全明确的开放式、复杂或快速演变的领域中操作时，应采用探索与发现模式。它非常适合需要生成新假设、策略或见解的任务，例如科学研究、市场分析和创意内容生成。当目标是揭示 “未知的未知” 而非仅仅优化已知流程时，这种模式至关重要。毕竟大语言模型的诞生都基于人类历史产生的数据，而且有一堆数据可能是假的。

核心内容算是 Google 的软文吧，重点介绍两大关键系统 —— 基于 Gemini LLM 的 Google Co-Scientist 与基于 MIT 协议的 Agent Laboratory（四阶段自动化科研流程，含 Professor、PostDoc 等角色分工）。

以 Co-Scientist 为例，包含 6 个 Sub Agent，采用 “生成 - 辩论 - 演化” 迭代模式，各智能体分工明确：

智能体（Agent） 核心功能
Generation Agent 通过文献探索与模拟科学辩论，生成初始假设
Reflection Agent 扮演同行评审角色，评估假设的正确性、新颖性与质量
Ranking Agent 基于 Elo 锦标赛机制，对比、排序并优先选择假设
Evolution Agent 优化顶级假设（简化概念、整合观点、探索非常规推理）
Proximity Agent 构建 “接近度图”，聚类相似观点，辅助探索假设全景
Meta-review Agent 综合所有评审与辩论结果，识别共性模式并提供反馈，推动系统迭代优化

探索与发现模式是 “智能体化”（agentic）AI 的核心，让智能体从 “被动执行指令” 升级为 “主动探索环境、设定子目标以发现未知”；其最有效实现路径是多智能体框架（如 Google Co-Scientist 的假设迭代、Agent Laboratory 的科研分工），通过各角色协同覆盖科研全生命周期；最终价值在于 “增强人类智力”——AI 处理常规计算任务，人类聚焦核心创意与判断，加速创新；同时需重视安全与伦理，确保技术负责任发展。

结语

至此，书中的主体内容就结束了。还有附录中的内容，例如高级提示词技巧和智能体框架的快速概述等等。推荐挑自己感兴趣的部分阅读。

近两年的工作经历中，有幸接触到非常多的团队和行业从业者。从传统软件开发人员的视角看，我真心觉得大家的开发范式和思维还未转变，即便 Kubernetes 设计思想已经如此普及的今天，开发范式从 “指令式” 转向 “目标驱动式” 依然困难重重。举个例子，很多 leader 痴迷于图形化、拖拉拽，认为这就是高级、先进，殊不知，将目标驱动（或者说声明式）的范式完整破坏掉的同时，也让其系统丧失专业性。图形化和拖拉拽如非以实用性和效率为首要目的，基本可以确定要么是设计源头上犯蠢或者在愚弄客户了。另一个层面，想谈一谈测试 / QA，传统软件测试依赖 “预期结果 vs 实际结果”，而 Agent 的行为具有概率性，需引入 “LLM-as-a-Judge”（用 LLM 评估输出质量）、“轨迹分析”（检查 Agent 执行步骤合理性）等新方法，需同时监控 “输出准确性” 与 “资源消耗”（如 Token 用量、 latency，类似性能测试），且多智能体系统需额外测试 “协作有效性”（如任务拆分是否合理、信息传递是否准确），类似传统集成测试但复杂度更高。

对于管理者而言，数据（或者私有化数据的治理）会成为智能体系统能否成功的关键，避免为智能体化而智能体化，同时调整组织架构（增设 AI Agent 产品经理），长期需规划 “效率提升 - 决策辅助 - 自主运营” 的 Agent 战略地图，建立差异化竞争力。在这个浮躁的时代，慢既是快，进而才能唯快不破。

共勉。