Agent AI 生产级设计模式手册
系统化总结构建生产级 Agent 系统的核心模式和最佳实践，对实际开发有高度指导价值。
完整中文译文
开始前：本文是什么（以及不是什么）
本文是一份关注生产实际的指南，包含：
GitHub 仓库：Awesome Agentic Patterns
配套网站：agentic-patterns.com
综合梳理了在公开文章、仓库、论文和演讲中反复出现的模式。
对"演示到生产的差距"的实践性地图：什么会断裂、为什么会断裂、团队如何应对。
不是声称"AI 智能体可以端到端地完成所有事情"。
不是声称每个模式都是普遍正确的、必需的或稳定的。
不是承诺你可以将"AI 智能体模式"简单添加到任何工作流中并立即加速交付。
如果你试过 AI 智能体并感觉像是"蛮干"，你并不孤单。开发者讨论中的一个反复出现的主题是，工具和工作流通常在模型失败前就已经失败了：令人困惑的"变更堆栈"、上下文管理的摩擦，以及 AI 智能体重复进行相同编辑。本文明确针对这些失败模式进行说明。
如果 AI 智能体让你感到无用，从这里开始
如果你当前的工作流是"复制粘贴到聊天、粘贴回来"，说明你还没有掉队。这种工作流对许多任务仍然有效。
但"AI 智能体"工作流只有在你养成两个习惯后才能真正带来收益：
Diff 优先：每个变更都作为 diff 审查（git、patch 视图、PR）
循环优先：AI 智能体运行带有明确退出条件的循环（测试通过、lint 清空、eval 阈值满足）
这是一个 30 分钟内可以在真实仓库上运行的简单上手方案。
实际可行的 30 分钟 AI 智能体工作流
选择一个小的、有界限的任务：
- 为你已经修复的 bug 添加缺失的单元测试
- 在测试保护下重构一个函数
- 更新一个依赖并修复编译错误
给出一个单一命令来证明正确性
- "Run npm test" / "Run pytest" / "Run go test ./..."
如果你没有这样的命令，把创建单一绿/红信号作为你的第一个任务。
限制修改范围
- "Touch only these files: …"
- "No unrelated refactors."
- "If you need new files, ask first."
要求明确的计划 + 检查点
- "Propose a plan in 5–10 steps."
- "Wait for approval before edits."
- "If new information changes the plan, stop and replan."
只接受通过 diff 的变更
- "Summarize why each hunk exists."
如果你只做这些——仅此而已——你已经在实践生产级 AI 智能体设计的核心：受限的行为 + 确定性的检查 + 可审查的输出。
成本、限制与何时 AI 智能体不划算
生产级 AI 智能体不是"免费的"。它用一种成本换另一种成本：
- 减少了输入和搜索时间
- 增加了审查、协调和安全工程
AI 智能体通常不划算的情况：
- 手动完成比精确指定要快
- 你没有测试/没有确定性验证
- 域名模糊且你无法定义"完成"
- AI 智能体拥有广泛权限且犯错的代价很高
AI 智能体通常划算的情况：
- 你可以写出清晰的验收标准
- 有客观信号（测试、lint、编译器、查询、eval）
- 工作是重复的（迁移、样板代码更新、大范围重命名）
- 你可以限制范围（工具、文件、权限）
在阅读下面的模式时牢记这个框架。大多数"AI 智能体失败"不是模型失败——它们是循环设计失败。
为什么兴趣在 2025 年 12 月末激增
"Awesome Agentic Patterns"仓库在假期期间急剧加速，到 2026 年 1 月达到大约数千颗星。（截至 2026 年 1 月中旬，约 2.8k 星。）配套网站的流量似乎反映了这种关注。
将其转化为单一原因的故事很诱人（"假期改变了一切"），但实际上这样的激增通常来自多个因素：
- Hacker News 和社交媒体上的可见度
- CLI/IDE AI 智能体工具生态的成熟
- 越来越多人终于花足够的不间断时间来建立肌肉记忆
最有说服力的结论很简单：
AI 智能体奖励在座时间。它们有学习曲线——特别是围绕约束、上下文和审查循环。
公开信号：严肃的开发者认真对待 AI 智能体（但有保留意见）
四个公开信号帮助"规范化"了 AI 智能体工作流：
Linus Torvalds：个人项目的 AI 辅助编程，不用于关键系统
Torvalds 在假期期间在一个个人音频相关项目（AudioNoise）上尝试了 AI 辅助"凭感觉编程"，同时也对在 Linux 内核中使用这些技术持怀疑态度。核心要点不是"Linus 喜欢 AI 智能体"。核心要点是：
- AI 辅助在低风险、自包含的上下文中很有用
- 即使热情者也在高风险基础设施处划出了一条硬线
Tobias Lütke（Shopify）：AI 使用作为基线期望
Lütke 在外部发布了一份内部备忘录，主张反射性 AI 使用现在是 Shopify 的基线期望，内部提供多个工具的访问权限。这对"炒作"的影响较小，但作为一个信号——组织正在为采用和实验预算时间——很重要。
Armin Ronacher：积极的、批判的，明确推荐"假期时间"来尝试
Ronacher 在关于 AI 智能体编程的公开文章中既很热情又尖锐批判。值得注意的是，他明确建议在圣诞节假期有时间的 AI 持怀疑者应该尝试付费的 Claude Code 订阅作为对自己的"礼物"——直接对应"在座时间"的采用曲线。
Ryan Dahl："人类编写代码的时代已经结束"
Node.js 创建者、Deno 联合创始人 Dahl 声称，虽然软件工程师仍有工作，但"直接编写语法不是"。这代表了一个比大多数人都更强的立场——甚至在 AI 积极社区内——即软件工程的根本活动已经改变。
核心要点不是每个人都同意。核心要点是严肃的、受尊敬的工程师正在公开表达一个世界观，其中代码创作不再是人类的主要活动——即使他们承认判断、架构和监督仍然至关重要。
什么是 AI 智能体模式？
AI 智能体是一个包裹在循环中的 LLM，它可以观察状态、调用工具、记录结果，并决定何时完成（或何时寻求帮助）。
AI 智能体模式是构建这些循环的可重复的微架构，使其在生产中运行：受约束、可测试、可观察和安全。
演示到生产的差距（为什么模式重要）
演示会作弊——通常是无意的：
- 没有权限边界
- 没有事件响应计划
生产迫使你处理：
- 人类工作流（批准、可审计性）
- 正确性要求
模式很有价值，因为它们不是"提示技巧"。它们是：
- 控制结构（循环、门、停止条件）
- 上下文/记忆策略
- eval 和监控方法
此库的纳入标准
模式库的目标是：
- 可重复：在多个独立实现中出现或有强大的主要来源
- AI 智能体特定：它改变循环推理/行动/验证的方式
- 可追踪：链接到公开文章、论文、演讲或仓库
AI 智能体模式的八个类别
模式聚类为八个类别。将这些视为问题类型的地图。
1. 编排 & 控制
循环如何决定做什么、何时停止以及如何恢复。
- Language Agent Tree Search (LATS)
2. 工具使用 & 环境
AI 智能体如何与系统交互而不造成混乱。
- Progressive Tool Discovery
- LLM-Friendly API Design
3. 上下文管理
如何在上下文限制下运行同时保持接地气。
- Progressive Disclosure for Large Files
- Episodic Memory Retrieval
- Context Window Anxiety Management
4. 输出质量 & 迭代
如何通过迭代和检查获得更好的输出。
- Coding Agent CI Feedback Loop
- Rich Feedback Loops > Perfect Prompts
5. UX & 协作
人类和 AI 智能体如何在不混乱的情况下共享控制。
- Abstracted Code Representation for Review
注：暗示"监控思维链"的模式应解释为监控动作轨迹和中间产物（工具调用、diff、测试输出），而不是依赖隐藏的推理文本。
6. 可靠性 & Eval
你如何知道它在工作——以及检测退化。
- Workflow Evals with Mocked Tools
- Anti-Reward-Hacking Grader Design
7. 学习 & 适应
系统如何随时间改进。
- Skill Library Evolution
- Agent Reinforcement Fine-Tuning (Agent RFT)
8. 安全 & 护栏
如何防止 AI 智能体成为数据泄露或事件生成器。
- Lethal Trifecta Threat Model
- Deterministic Security Scanning
你可以立即使用的基础模式
如果你忽视其他一切并采用四个想法，从这里开始。
1) 先计划后执行（如在生产中使用，而非刚性脚本）
问题 当 AI 智能体看到不信任的内容（用户输入、网页、电子邮件、日志）时，该内容可以引导 AI 智能体的下一步行动。工具输出可能成为提示注入向量。
生产级解决方案 将工作分为计划、受控执行和重新规划门：
规划阶段
AI 智能体提出计划：目标、步骤、预期使用的工具、约束条件以及“完成”检查项。计划由人工审核，或交由策略控制器评估。
AI 智能体提出计划：目标、步骤、预期使用的工具、约束条件以及“完成”检查项。
计划由人工审核，或交由策略控制器评估。
执行阶段（受控）
控制器强制执行：工具白名单、权限范围（只读与写入）、文件边界、速率限制、日志记录和审计。
执行阶段（受控）
控制器强制执行：工具白名单、权限范围（只读与写入）、文件边界、速率限制、日志记录和审计。
权限范围（只读与写入）
工具输出可以影响参数和局部决策。
重新规划检查点
如果工具输出推翻了原有假设，AI 智能体必须停止并重新规划。重新规划是一项功能，而不是失败。
如果工具输出推翻了原有假设，AI 智能体必须停止并重新规划。
重新规划是一项功能，而不是失败。
这一模式不是什么
不是“生成一套固定的工具调用序列，然后永不偏离”。
其本身并不能保证抵御所有提示词注入。
除非控制器真正强制执行约束，否则毫无用处。
适用于任何读取不可信输入并能够执行操作的场景（尤其是写入操作）。
适用于能够清晰定义“完成”和“允许执行的操作”的工作流。
2）控制反转
问题：如果你对每一步都进行微观管理，自己就会成为瓶颈，同时还会阻碍 AI 智能体进行探索。
解决方案：向 AI 智能体提供：
- 约束条件（绝不能做什么）
- 审查流程（差异优先）
然后让它自行选择中间步骤。
何时会失败：没有约束的控制反转会变成“AI 智能体肆意行动”。这一模式只有与以下内容配合时才安全：
3）反思循环（依靠真实检查，而非感觉）
问题：一次性生成非常脆弱。但缺少客观检查的“自我批评”同样脆弱——模型可能会为自己的结果强行找理由。
解决方案：反思循环应以某种信号为依据：
for attempt in range(max_iters):
draft = generate()
results = run_checks(draft) # tests/lints/validators/evals
if results.pass:
return draft
draft = fix_from(results)
适用于任何正确性至关重要的场景。
适用于任何能够定义检查项的场景。
4）操作轨迹监控与中断
问题：AI 智能体会逐渐偏离目标。等你看到最终输出时，早已为这种偏离付出了代价。
解决方案：监控那些你真正能够观察并强制约束的内容：
- 工具调用（类型、参数）
- 差异规模和风险等级
- 执行过的测试及其输出
- 中间产物（计划、摘要、检查清单）
添加明确的“终止开关”：
- 使用意外工具时停止
- 差异超过 N 行时停止
- 触碰禁改文件时停止
- 测试连续失败两次且未缩小范围时停止
核心思想：你不需要阅读私有推理过程也能保持控制。你需要的是可观察的行为和硬性关卡。
工具的现实：为什么“智能体模式”经常让人觉得不好用
如果界面让你处处和工具较劲，模式库也帮不上忙。以下三个实用修正能够解决大多数挫败感：
如果你的工具带有内部“变更栈”界面，最终仍应以 git diff 或 PR diff 作为裁决依据。
2）小任务胜过大而泛的要求
AI 智能体更擅长：
“更新这 8 处调用点”
而不是：
“重构整个架构”
3）持久化的项目规则胜过反复在聊天中提醒
创建一个 AGENTS.md、CLAUDE.md 或“Rules”文件（名称取决于具体工具），其中包含：
- “绝不能做 X”之类的约束
- “完成”的判定标准
这往往决定了最终体验是“像魔法一样顺畅”，还是陷入“合并地狱”。
“Ralph Wiggum”偏离陷阱
Geoffrey Huntley 为一种常见失败模式起了一个很形象的名字：AI 智能体一开始看起来效率很高，但随着它不断遗漏隐含的上下文和约束，便会逐渐偏离目标。
更聪明的提示词解决不了这个问题。真正的解决方式是：
- 持久化项目约定
（参见 ghuntley 的相关文章和 how-to-ralph-wiggum。）
多智能体系统的架构（以及何时应该避免使用）
多智能体系统在以下情况下可能会有所帮助：
- 任务可以清晰地分解为相互独立的部分
- 合并过程可预测
- 验证具有确定性
在以下情况下应避免使用：
- 任务之间高度耦合
- 共享上下文至关重要
- 缺少可靠的测试或评估
群体迁移模式（实用版）
用例：规模庞大、以机械性修改为主的迁移：
- 主 AI 智能体列举工作项（文件、符号、调用点）。
- 将工作拆分为原子化的小块。
- 为每个小块启动子智能体。
- 通过严格检查（测试、lint 和编译）合并结果。
- 如果出现失败，则缩小范围并重试。
- 将并行度限制在代码审查和 CI 能够处理的范围内
- 要求每个子智能体都提交摘要和 diff
- 始终准备好回滚方案
LATS（Language Agent Tree Search）：强大但昂贵
LATS 将树搜索（类似 MCTS 的探索）与 LLM 评估及反思结合起来，以探索多条推理路径。对于困难的决策任务，它可能优于线性的“单路径”方法——但代价是更高的计算成本和复杂度。
适用于以下情况：
- 任务确实需要探索多种策略
- 前期的错误决策代价高昂
- 你能够承担额外开销
不适用于以下情况：
- 只需运行测试或验证器循环即可解决
人类与 AI 智能体的协作光谱
许多“AI 智能体将取代人类”的论调在实践中都站不住脚。生产环境中的成功通常表现为：
- AI 智能体完成中间的机械性工作
- 人类定义目标和约束
- 人类审查风险并进行审批
- 系统强制执行安全边界
控制光谱（混合主动权）
设计顺畅的控制权移交流程：
- 人类主导（AI 智能体执行）
- AI 智能体主导（人类审批）
- 混合模式（双方来回协作）
需要明确：
- AI 智能体认为什么叫“完成”
- AI 智能体对哪些内容没有把握
用于审查的抽象代码表示
对于大型 diff，应要求提供：
- 行为变更摘要
- 变更文件及其原因的检查清单
- 变更前后的语义
- “风险热点”（身份验证、资金、权限、迁移）
然后再审查 diff。
真正重要的安全模式
AI 智能体系统的一种实用安全模型，是关注以下三类风险能力的交集：
- 访问私有数据
- 接触不可信内容
- 能够向外部泄露数据
如果你的 AI 智能体同时具备这三项能力，提示词注入就像一场随时可能发生的数据泄露。
生产环境中的正确做法不是“改进提示词”，而是从任何一条执行路径中至少移除一个风险圆：
- 禁止访问外部网络
- 禁止直接访问密钥
- 严格隔离输入并使用沙箱
- 对工具能力进行分区隔离
PII Tokenization（以表示替代限制）
不要把原始个人身份信息（PII）放入模型上下文，而应将其替换为令牌：
- AI 智能体基于令牌进行推理
- 可信执行器在执行操作时解析令牌
- 日志更加安全，也更容易满足合规要求
生产环境现实检查：瓶颈在于判断力（AI 智能体无法消除它）
一种常见的失败模式是“劣质产物引力”：
- 前期开发速度很快
- 架构债务不断累积
- 后续变更变得既危险又缓慢
AI 智能体会放大这一问题，因为它们让更快地产出更多代码变得轻而易举。
为防止系统变成乱麻：
- 增加架构检查点
- 将“完成”定义为通过确定性检查
- 要求结构性变更必须附带由人类负责的设计说明
- 优先进行能够缩小表面积的重构，而不是扩大表面积
把 AI 智能体视为一种电动工具：
- 它们会放大你的产出
- 如果没有约束，它们也会放大你的错误
实用的采用路径
第 1 步：选择三种模式
不要一次采用 113 种模式。选择三种与你当前痛点最匹配的模式。
如果你正从复制粘贴式工作流起步：
- diff 优先工作流（这是一种流程，而非模式）
- 带测试的反思循环
- 操作轨迹监控和停止条件
如果你已经在交付 AI 智能体：
- 带真实关卡的先规划后执行
- 工具能力分区隔离
- 使用模拟工具进行工作流评估
第 2 步：实施 → 观察 → 迭代
将模式视为假设。为其添加监测机制，并衡量：
- AI 智能体需要人工干预的频率
- 反复出现的失败模式
- 哪些约束能够减少失败
第 3 步：写下你的“项目规则”
这是大多数团队都会跳过、但投资回报率最高的一件事：
- 哪些内容绝不能改变
第 4 步：保持关注，但不要追逐每一种趋势
有些模式会被工具吸收，最终变得不可见。你的优势不在于知道某种模式叫什么，而在于知道：
方法论与成熟度（如何理解这个模式库）
并非所有模式都经过了同等程度的验证。应将成熟度标签视为指导，并明确其判定标准。
一套实用的成熟度分级标准：
- 提议阶段：具有合理性，但证据有限
- 涌现阶段：至少有一篇严肃的实现经验文章
- 成熟阶段：存在多个独立参考来源，并已得到普遍使用
- 已在生产环境验证：有真实部署的公开证据，并记录了观察到的失败模式
- 最佳实践：多个可信来源形成了趋同共识
如果你正在构建生产系统，应优先选择：
成熟、已验证或最佳实践级别的模式，并将涌现阶段的模式视为实验。
结论：真正交付成果的不是模式，而是循环
智能体式工作之所以对一些人而言“神奇无比”，而对另一些人而言“毫无用处”，原因通常不在模型，而在循环。
生产环境中的智能体需要：
- 可观测性和停止条件
这个模式库中的 113 种模式既是一套词汇体系，也是一个工具箱。真正的工作，是根据你的约束条件、代码仓库和风险承受能力来应用它们。
如果你想采取下一步行动：
- 运行这套 30 分钟工作流
- 记录出现的问题
这正是你从演示迈向生产环境的方式。
致力于为 AI 驱动的产品构建目标明确的市场进入引擎。曾与 Numarics、Codeanywhere、Daytona 和 Steel 等创新型初创公司合作，制定增长战略和市场定位。任教于斯普利特大学，研究 AI 应用模式和开发者工具。