如何在不确定的大模型上，构建可靠的系统？——读《Agent 设计模式》

大模型的本质是预测下一个 token，它是概率性的。同样的输入，可能给出不同的输出；它会一本正经地胡说，也会在关键时刻掉链子。可我们偏偏想用它来搭建可靠的系统——能被信任、能上生产、能对结果负责的系统。

这就是横亘在整个 Agent 工程面前的核心命题，也是这篇文章的主线：

如何在不确定的大模型之上，构建确定性的可靠系统？

《Agent 设计模式：图解可复用智能体架构》（人民邮电出版社，黄佳著）给出的答案，不是某个技巧，而是一整套方法论。下面我会沿着这条主线，把全书拆成四个环环相扣的问题：

1. 为什么是 Agent？（上篇）——软件工程三十年，如何一步步逼近"用不确定性构建可靠系统"这个答案
2. Agent 靠什么运转？——目标、上下文、记忆、反思……五条设计原则撑起整个范式
3. 可靠性从哪来？（下篇）——感知、记忆、推理、行动、反思、协作，六大类能力如何各自消解一部分不确定性
4. 落到实处是什么？——21 个可复用的设计模式，把上面的答案变成能抄的工程范式

引子：当"故障"从意外变成常态

2012 年，Netflix 开源了一个"疯狂"的项目：Chaos Monkey——专门在生产环境中随机杀死自己的服务器。这在传统软件工程时代不可想象，但 Netflix 的逻辑很简单：既然故障不可避免，就让系统通过持续的小创伤进化出真正的免疫力。

同年，Google 发表论文"Datacenter as Computer"，宣告硬件故障不再是意外，而是统计学必然。软件设计的目标从"防止故障"转向"在故障常态化中依然可靠"。

请记住这个转折——它其实就是核心命题的第一次预演：当年是"在会宕机的硬件上构建可靠系统"，今天是"在会胡说的大模型上构建可靠系统"。同一道题，换了一层。

这两个信号共同指向一个深刻的范式迁移：确定性时代落幕，软件工程正在从精密的瑞士手表，变成自组织的生物群落。 而这场变革最耀眼的主角，就是 Agent。

五条 Agent 设计原则：范式的地基

在展开历史与模式之前，先立住一个"元框架"。如果说核心命题是"在不确定上求可靠"，那么这五条原则就是通往答案的五个方向盘——它们贯穿全书，也贯穿下文每一个设计模式：

• 目标优先：一切从"要达成什么目标"出发，而非先考虑"能调用什么工具"
• 上下文为王：提示只是冰山一角，真正决定智能体行为的是上下文工程与记忆治理
• 显式反馈：将反馈、反思与改进视为核心能力，内建于系统设计之初
• 渐进自治：让系统在安全护栏内逐步提升自主决策能力
• 涌现优于规定：设计让智能体自然涌现行为的机制，而非硬编码每一步

上篇：智能设计的哲学 —— 为什么答案会是 Agent？

主线定位｜第 1 个问题：为什么是 Agent？ 上篇不谈具体模式，而是回答一个前置问题：软件工程走了三十年，为什么最终会把"用不确定性构建可靠系统"这个答案，交到 Agent 手上？答案藏在一条清晰的演进线里——确定性失效 → 范式迁移 → 物种诞生。

第1章：从结构到智能——设计模式的世纪旅程

1.1 模式思想的起源

“模式"概念并非 GoF 首创，灵感来源于建筑师克里斯托弗·亚历山大的《建筑模式语言》——优秀建筑是"永恒形式"的发现与组合。1994年 GoF（Gang of Four，四人组） 出版《设计模式》，由 Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 四位作者提炼出23种经典模式，构建了系统化的面向对象设计世界观。

当手段被神圣化，“模式病”(Patternitis) 随之出现——过度设计让简单功能淹没在抽象海洋中。

黄金时代的四次革命：

然而，追求代码"纯洁性"也筑起了高墙——软件工程走向象牙塔，开发者沉醉于打造完美的水晶球，却忽视了应对现实世界复杂性的灵活性。

1.2 诸神的黄昏：当确定性遇到不确定性

GoF 设计模式诞生于"静态世界”——系统边界清晰、需求变更可预测、运行环境稳定。然而 21 世纪，一切都变了。

第一声警报：Twitter 2008 年宕机

服务器仍在运行，每个组件看似正常，但整个系统陷入泥潭，响应时间从毫秒级退化至分钟级。开发者发现每个设计模式都待在它该在的位置——但"正确的设计"无法解决"规模"带来的问题。

不确定性的三重奏：

• 规模不确定性：用户量从千人跃升至亿人，分布式成为常态
• 行为不确定性：Web 2.0 时代用户行为不再可预测
• 需求不确定性：花数月画 UML 按图施工的模式被打破

经典模式的失效：

转折点 2012-2014：四次关键变革

• Google “Datacenter as Computer”(2012)：从"单机精修"到"宏观概率"——硬件故障是统计学必然，软件为"故障常态化"设计
• Netflix Chaos Monkey(2012)：从"鲁棒性"到"反脆弱"——系统像免疫系统，通过持续小创伤进化
• Docker(2013)：不可变基础设施——服务器从"需要维护的资产"变成可销毁的"耗材"
• Kubernetes(2014)：声明式 API + 调解循环——K8s 的 Controller 本质上就是原始的、针对特定任务的 Agent

确定性时代就此终结——设计的重心，从"防止故障"彻底转向"在故障常态化中依然可靠"。

第2章：从模式到意图——软件工程的范式迁移

GoF 模式只告诉我们"怎么做"，Agent 时代意图比模式更重要——Agent 首次将"意图"显式嵌入系统。

2.1 函数与流：计算的原子化

无状态 → 纯函数：LLM 本质是一个庞大且无状态的纯函数——给它一个 Prompt，它输出一串 Token，然后恢复空白状态，等待下一个输入。

函数式编程（FP）的"引用透明 + 管道"思想与 Agent 数据处理管道完全吻合：

输入 Prompt → 检索增强 → 思维链推理 → 格式化输出

软件工程跳出"对象身份"的执念，回归数据变换的本质。

响应式流 → Agent 协作：背压（Backpressure）机制让多 Agent 协作中"搜索 Agent"不会压垮"写作 Agent"——就像现实中的编辑不会任由采访材料淹没自己。

智能的本质，是对变化的响应。 神经网络响应 Tensor 流，强化学习响应 Reward 流，LLM 响应 Token 流。

2.2 分布式的解耦：从单体到生态

到这里，一个问题自然浮现：这些技术演进和 LLM Agent 到底有什么关系？

答案是：它们是 Agent 得以运行的"操作系统"。正如 Linux 让互联网应用成为可能，微服务、容器化和 Serverless 让 Agent 得以"长出"手脚，在真实世界中行动。

微服务 API = Agent 的工具箱

微服务将大型应用拆散为独立可部署的服务单元，并通过 HTTP/gRPC API 互联。这意味着：当 Agent 需要执行一个操作时，它不需要调用一个静态函数，而可以访问一个网络可达的服务端点。每个外部工具对 Agent 而言就是一个可寻址的 API——Agent 的"手"延伸到了整个互联网。

Kubernetes = Agent 的架构蓝图

K8s 的核心抽象是 Controller（控制器）：你声明期望状态（YAML），Controller 持续调谐直到达成。这和 Agent 的思考-行动循环高度一致，只是 Agent 的输入从 YAML 变成了自然语言 Prompt。

关键洞察：K8s 的 Controller 已经在实践 Agent 的核心思想——声明期望状态，持续调谐直到达成。LLM Agent 不过是把这个模式从基础设施层搬到了业务逻辑层。

2.3 Serverless：极致的原子能力

Serverless 将计算粒度从"服务"细化为"函数"。函数平时"沉睡"在云端，事件触发时才激活——从"维护一口永不干涸的井"到"按杯取水"。

在 Agent 架构中，Serverless 函数如同**“沉睡的技能”**——成千上万个工具部署为函数，Agent 在产生特定意图的瞬间通过 API 唤醒。

软件不再是以"大教堂"形态存在的固态结构，而是演变为流动不息的**“海洋”**——如同液体一般自由流动、动态组合与即时拆解。

2.4 软件 2.0：当概率遇见代码

2017 年，安德烈·卡帕西（Andrej Karpathy）发表"Software 2.0"：此前软件工程致力于消除不确定性；此后，软件工程开始学会利用不确定性。

当代码本身演变为数据（模型权重），DevOps 的核心假设便轰然倒塌——你无法再用传统的服务器指标来定义"正常运行"，因为系统的行为不再由代码决定，而由权重决定。MLOps（Machine Learning Operations） 正是行业对这一变化的回应：它借鉴 DevOps 的思路，为机器学习系统建立了从实验到生产的标准化流水线，也为 AgentOps 铺平了道路。

第2章小结：范式迁移全景

范式迁移不是单一事件，而是三条技术演进路线共同作用的结果：

所有关键技术的"积木"——Transformer（注意力机制）、Docker（容器化）、API（服务互联）、向量数据库（语义检索）——如今都已准备就绪。我们需要的，是将它们整合，构建出具备感知、记忆、思考与行动能力的"新物种"。

用一张图把这条「进化链」串起来：

flowchart TB
    F["路线一：函数与流<br/>LLM 无状态纯函数 · 管道契合数据流"]:::route
    S["路线二：分布式 + Serverless<br/>微服务 API · 按需唤醒的技能单元"]:::route
    W["路线三：软件 2.0<br/>概率性取代确定性 · 园丁思维取代建筑师"]:::route

    F --> A
    S --> A
    W --> A

    A["Agent 时代<br/>寒武纪大爆发"]:::agent
    A --> C["感知 · 记忆 · 思考 · 行动"]

    classDef route fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f
    classDef agent fill:#1e3a8a,stroke:#1e40af,stroke-width:2px,color:#fff

三条技术路线不是串行替代，而是平行演进、殊途同归——它们各自从不同方向解决了智能体落地的一个基础问题：函数与流解决了「如何与 LLM 协作」，分布式与 Serverless 解决了「如何拥有无限延展的手脚」，软件 2.0 解决了「如何在不确定性中建立信心」。

这不是一场革命，而是一场进化。是三十年的软件工程积累，终于等到了自己的"寒武纪大爆发"

第3章：从设计到演化——欢迎来到 Agent 时代

我们不再是在设计(design)一个系统，而是在培育(cultivate)一个物种。

把 LLM 引入软件架构的核心，软件不再仅仅是对人类指令的响应(response)，而是开始展现出意图和自主性(agency)。

3.1 Agent 的本质：从工具到伙伴

交互原语的升维：从"命令与控制"转向"意图与协作"——Agent 更像一位经验丰富的同事，而非机械的命令行工具。

意图的理解：模糊与精确的桥梁

Agent 的核心能力是充当**“模糊翻译器”**，搭建"人类模糊的自然语言"与"机器精确的 API 调用"之间的桥梁，包含四层：语义理解 → 目的识别 → 上下文关联 → 风险评估与澄清。

记忆与身份：Agent 的自我连续性

工具是"用完即走"，Agent 有记忆——它在每次对话之间延续"身份"，逐渐形成对用户的深入理解。

上下文工程：理解世界状态

对 Agent 而言，上下文就是它的整个世界——“Garbage in, garbage out”。Agent 失败的原因，往往不是模型能力不足，而是上下文信息有误。

任务分解：把"目标"变为"计划"

任务分解(Task Decomposition)是衡量 Agent 智能化水平的关键指标。

工具、技能与 ReAct

2024 年兴起的 MCP（Model Context Protocol） 使 Agent 能像插拔 USB 设备一样灵活挂载外部能力。

MCP 的核心价值：把 AI 连接外部世界的方式标准化——就像 USB-C 统一了设备连接，MCP 正在统一 AI 与工具、数据的交互协议。

Anthropic 2025 年发布的 Agent Skills 进一步区分：

• 工具(Tool)：原子化操作，如"执行 SQL"“发送 HTTP 请求”——是 Agent 的**“手”**
• 技能(Skill)：能力单元 = 工具 + 领域知识 + SOP——是 Agent 的**“技能书”**

ReAct 范式（Thought → Action → Observation）已成为现代 Agent 行动的标准心智模型。

3.2 Agent 心智架构：感知—推理—行动循环

传统软件架构本质是线性管道（输入→处理→输出），Agent 则运行在 while(alive) 的无限循环中：

3.3 协作的"语法"：多 Agent 系统的编排

从单体 Agent 转向多 Agent 网络，软件架构的隐喻从"机械装置"跃迁为"社会组织"。

认知负荷的分流：2023 年 GPT-4 发布当天，AutoGPT 诞生——智能并非单个模型的固有属性，而是"互动"的产物。

A2A + MCP：双轨制协议：如果说前面提到的 MCP 解决的是"Agent ↔ 工具"的连接，那么 A2A（Agent-to-Agent） 解决的就是"Agent ↔ Agent"的连接——两者一横一纵，共同构成多 Agent 系统的双轨制协议。

一句话记住二者分工：MCP 是 Agent 对外的"USB-C 接口"，A2A 是 Agent 之间的"对讲机协议"。

编排器（Orchestrator）：当 Agent 数量增加，系统需要"大脑"来维持秩序——这就是 Orchestration 的核心使命。

3.4 新的契约：人机协作的设计原则

人类与 AI 的关系不再局限于调用 API，而是转向设计协作模式。人类从代码的"建筑师"转变为 Agent 系统的"设计师与协作者"。

从 GoF 的 23 个设计模式到 Agent 的无限可能，我们跨越了软件工程的一个世纪：设计模式并未消亡，而是在进化；软件工程未曾终结，而是在重生；人类的角色没有消失，而是在升华。

📖 上篇总结

从确定性工程到概率性工程的范式跃迁。

GoF 设计模式诞生于"静态世界"，2012 年是关键转折点——Netflix Chaos Monkey 宣告"故障常态化"，K8s 引入"声明式 API + 调解循环"（原始 Agent 思想）。从函数式响应式流、分布式 + Serverless 到 Software 2.0，每一步演进都在为 Agent 铺路：让软件具备感知、记忆、思考与行动能力。

核心洞见：意图比模式更重要。 Agent 时代不是 GoF 模式的终结，而是进化。

下篇：六大类 21 个核心设计模式 —— 可靠性从哪来？

主线定位｜第 3 & 4 个问题：可靠性从哪来？怎么落地？ 上篇论证了"为什么是 Agent"，但一个会胡说的模型，凭什么能撑起可靠系统？下篇给出的答案是：把可靠性拆解到六大类能力里，逐个消解不确定性——感知消解"信息噪声"，记忆消解"知识过期"，推理消解"逻辑跳步"，行动消解"纸上谈兵"，反思消解"错而不知"，协作消解"单点认知上限"。每一类能力，再落成 3～4 个可复用的设计模式。

Tencent WorkBuddy 和 Claude Code 都是目前大模型落地应用中非常典型的 Agent 设计模式集大成者。传统的 AI 助手（如早期 ChatGPT 网页版）是"问答式"的——你输入一条指令，它返回一段文字，属于单次交互。而 WorkBuddy 和 Claude Code 则运行在一个 while(alive) 的控制循环中，具备了感知、规划、工具调用、反思和协同的能力。它们具体运用了以下核心的 Agent 设计模式。

感知模式——系统与世界的接口层

→ 消解「信息噪声」的不确定性。 传统软件是被动的，Agent 则是主动的。感知的本质不是"看到所有"，而是"看到关键"并"主动寻找未知"。

落到实处：当你让 Claude Code 在一个几十万行的仓库里"找到并修复登录逻辑的 bug"，它不会把整个代码库塞进上下文——那既超窗口又全是噪声。它先用 grep、读目录结构做注意力聚焦，只拉取真正相关的几个文件；信息不够时，再主动感知去搜索调用链，而不是硬着头皮猜。这正是"看准关键 + 主动寻找未知"的工程化。

不要以"它能记住多少"为荣，而要以"它能精简多少"为傲。

记忆模式——平台与协议的一等组件

→ 消解「知识过期与遗忘」的不确定性。 感知给出现在，推理创造洞见，记忆实现持续。

落到实处：WorkBuddy 的记忆分了三层——当前对话是 L1 工作记忆，用完即弃；项目目录下的记忆文件是 L3 长期存储，跨会话延续"它记得你上次的技术选型"；而当你问"帮我查某项政策的最新细则"，模型训练数据早已过期，它就走 RAG：现查现用，把检索到的最新内容喂给推理，无需为一条新知识重训模型。三种记忆各司其职，才有了"它像个记得住事的同事"这种体验。

RAG 最深刻的洞见：将"推理能力"（CPU）与"知识存储"（磁盘）解耦。 以极低成本保持系统时效性，无需每次重新训练昂贵的 LLM。

推理模式——理性地编织

→ 消解「逻辑跳步」的不确定性。 记忆解决"知道什么"，推理解决"如何运用"。逻辑跳步是幻觉的温床——模型从 A 直接"跳"到结论 D，中间的 B、C 无人核对。推理模式的价值，就是把这条隐藏的推理链显式摊开，让每一步都可被检查、被回溯。

落到实处：让 Claude Code “把这个模块从 Redux 迁移到 Zustand”，它不会一步到位。思维链让它先列出"识别所有 store → 逐个改写 → 更新引用 → 跑测试"的线性步骤，像走钢丝一样步步踩实；若某一步有多个可行方案（比如状态该拆几个 store），它会用思维树分叉权衡、剪掉明显更差的分支，而不是随手押一个。

一位优秀的 Agent 架构师不应迷信单一推理模式，而应善于指挥整支认知"乐团"： 思维链适合数学推导（走钢丝），思维树适合多分支权衡（迷宫探路），思维图适合复杂整合（织布机）。

行动模式——决策的进阶之路

→ 消解「纸上谈兵」的不确定性。 如果说推理模式是 Agent 的"参谋部"，行动模式便是 Agent 的"远征军"——走出大脑，迈向现实世界。

ReAct：看图规划 → 采取行动 → 观察反馈——推理轨迹追踪中间决策，行动赋予探索环境获取外部信息的能力。

Claude Code 的 ReAct 循环：当你让 Claude Code"修复项目中所有过期的依赖并确保测试通过"时，它不会一次性把代码吐给你，而是进入 ReAct 循环：Thought：我需要先查看 package.json 哪些依赖过期了。Action：调用终端工具运行 npm outdated。Observation：终端返回了一堆过期的包和版本号。Thought：我知道该更新什么了，先更新 A 包，然后运行测试。Action：运行 npm install A@latest，接着运行 npm test。如此循环，直到所有测试通过。

WorkBuddy 的 ReAct 循环：在桌面办公场景下，你让它"把上个月的销售数据整理成图表并给老板发邮件"。它会先"想"去哪里找数据（Thought），然后去打开本地对应的 Excel 表格（Action），读取内容（Observation），再决定下一步是调用 Python 脚本画图还是直接在 Excel 内操作。

当 Agent 能够感知、记忆、推理，并以明智且适应性的方式行动时，它已近乎一个完整的智能系统。 但它仍存在致命弱点：可能对自己的错误深信不疑。

反思模式——AI 的灵魂工程学

→ 消解「错而不自知」的不确定性。 感知使其看见世界，记忆使其连接时间，推理使其构建逻辑，行动使其付诸实施，而反思则使其判断这一切是否正确。

自我修正（当下毫秒级，像橡皮擦）/反思记忆（下次分钟级，像错题本）/元学习（长远日/周级，像修订教科书）——三种时间尺度，构成 Agent 的完整反思闭环。

Claude Code 的反思场景：它写完了一段代码并自动运行了 pytest。结果终端报错了（SyntaxError 或断言失败）。在传统模式下，任务就死掉了。但在 Agent 模式下，Claude Code 会把"报错信息"作为新的上下文输入给自己，进行自我反思：“哦，我刚才漏掉了一个闭合括号 / 误解了 API”，然后直接修改代码重新运行，直到测试完全通过才向人类交付。

协作模式——协作的终局

→ 消解「单点认知上限」的不确定性。 智能并非孤独的函数，而是关系的网络。 AI 正从"工具时代"迈入"社会时代"。

WorkBuddy 的专家团模式：WorkBuddy 在后台其实往往不是一个 Agent 在单打独斗，而是编排了一个专家网络。**Orchestrator（编排器）**负责理解人类意图并分配任务；**Reader Agent（文档专家）**专门负责高效解析几百页的报表，提取关键数字；**Analyst Agent（分析专家）**负责写 Python 代码跑数据分析；**Writer Agent（文案专家）**负责把分析结果润色成高级的汇报邮件。它们通过类似"对讲机协议"的方式互相传递数据，最终合力完成工作。

委托模式如同军队的作战体系：命令层层下达，强调执行力与服从性。路由模式则如同综合医院的分诊系统：按需分诊，以专业度为先——“没有任何一个模型能在所有任务上都保持优势；关键在于让最合适的大脑去处理最匹配的问题。"（MoA 论文）

辩论（对抗）/委托（层级）/路由（分发）/群体（涌现）——智能的最高形态，不在于独立思考，而在于共同进化。

📖 下篇总结

下篇围绕可靠性这条主线，把 21 个核心 Agent 设计模式归入六大类——感知、记忆、推理、行动、反思、协作。它们对应着智能系统从「看见」到「记住」到「思考」到「行动」到「自省」再到「共事」的完整闭环：每一类都解决一个具体的可靠性瓶颈——感知决定信息从哪来、记忆决定经验如何留存、推理决定判断如何严谨、行动决定决策如何执行、反思决定错误如何修复、协作决定群体如何涌现。

后记：从"建筑师"到"园丁"

一句话概括这场变迁：软件正在生物化——它不再是被拧紧的机器，而是长出了生长性、适应性与自我修正能力的物种。对应到人，架构师的角色也随之改变：从精准摆放每一块砖的「建筑师」，变成打理整座生态的「园丁」——不能命令每一步都对，但能浇水施肥、修剪枝叶、营造环境，让系统在不确定中持续生长。

从 Netflix 主动杀死自己的服务器，到 Agent 主动反思自己的错误——三十年过去，工程师们学会的其实是同一件事：真正的可靠，从来不是没有故障，而是与不确定性共存的能力。 这，就是 Agent 设计模式的全部意义。

• AI
• Agent
• Design-Pattern
• Book-Notes
• 大模型