8.0
热点
AI SCORE
技术实践2026-01-21 14:48
Agent AI 生产级设计模式手册
Hacker News · nibzard.com#Agent#最佳实践
Editor brief · 编辑速览
系统化总结构建生产级 Agent 系统的核心模式和最佳实践，对实际开发有高度指导价值。
系统化总结构建生产级 Agent 系统的核心模式和最佳实践，对实际开发有高度指导价值。
本文是一份关注生产实际的指南，包含：
GitHub 仓库：Awesome Agentic Patterns
配套网站：agentic-patterns.com
综合梳理了在公开文章、仓库、论文和演讲中反复出现的模式。
对"演示到生产的差距"的实践性地图：什么会断裂、为什么会断裂、团队如何应对。
不是声称"AI 智能体可以端到端地完成所有事情"。
不是声称每个模式都是普遍正确的、必需的或稳定的。
不是承诺你可以将"AI 智能体模式"简单添加到任何工作流中并立即加速交付。
如果你试过 AI 智能体并感觉像是"蛮干"，你并不孤单。开发者讨论中的一个反复出现的主题是，工具和工作流通常在模型失败前就已经失败了：令人困惑的"变更堆栈"、上下文管理的摩擦，以及 AI 智能体重复进行相同编辑。本文明确针对这些失败模式进行说明。
如果你当前的工作流是"复制粘贴到聊天、粘贴回来"，说明你还没有掉队。这种工作流对许多任务仍然有效。
但"AI 智能体"工作流只有在你养成两个习惯后才能真正带来收益：
Diff 优先：每个变更都作为 diff 审查（git、patch 视图、PR）
循环优先：AI 智能体运行带有明确退出条件的循环（测试通过、lint 清空、eval 阈值满足）
这是一个 30 分钟内可以在真实仓库上运行的简单上手方案。
选择一个小的、有界限的任务：
给出一个单一命令来证明正确性
如果你没有这样的命令，把创建单一绿/红信号作为你的第一个任务。
限制修改范围
要求明确的计划 + 检查点
只接受通过 diff 的变更
如果你只做这些——仅此而已——你已经在实践生产级 AI 智能体设计的核心：受限的行为 + 确定性的检查 + 可审查的输出。
生产级 AI 智能体不是"免费的"。它用一种成本换另一种成本：
AI 智能体通常不划算的情况：
AI 智能体通常划算的情况：
在阅读下面的模式时牢记这个框架。大多数"AI 智能体失败"不是模型失败——它们是循环设计失败。
"Awesome Agentic Patterns"仓库在假期期间急剧加速，到 2026 年 1 月达到大约数千颗星。（截至 2026 年 1 月中旬，约 2.8k 星。）配套网站的流量似乎反映了这种关注。
将其转化为单一原因的故事很诱人（"假期改变了一切"），但实际上这样的激增通常来自多个因素：
最有说服力的结论很简单：
AI 智能体奖励在座时间。它们有学习曲线——特别是围绕约束、上下文和审查循环。
四个公开信号帮助"规范化"了 AI 智能体工作流：
Linus Torvalds：个人项目的 AI 辅助编程，不用于关键系统
Torvalds 在假期期间在一个个人音频相关项目（AudioNoise）上尝试了 AI 辅助"凭感觉编程"，同时也对在 Linux 内核中使用这些技术持怀疑态度。核心要点不是"Linus 喜欢 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 智能体是一个包裹在循环中的 LLM，它可以观察状态、调用工具、记录结果，并决定何时完成（或何时寻求帮助）。
AI 智能体模式是构建这些循环的可重复的微架构，使其在生产中运行：受约束、可测试、可观察和安全。
演示会作弊——通常是无意的：
生产迫使你处理：
模式很有价值，因为它们不是"提示技巧"。它们是：
模式库的目标是：
模式聚类为八个类别。将这些视为问题类型的地图。
循环如何决定做什么、何时停止以及如何恢复。
AI 智能体如何与系统交互而不造成混乱。
如何在上下文限制下运行同时保持接地气。
如何通过迭代和检查获得更好的输出。
人类和 AI 智能体如何在不混乱的情况下共享控制。
注：暗示"监控思维链"的模式应解释为监控动作轨迹和中间产物（工具调用、diff、测试输出），而不是依赖隐藏的推理文本。
你如何知道它在工作——以及检测退化。
系统如何随时间改进。
如何防止 AI 智能体成为数据泄露或事件生成器。
如果你忽视其他一切并采用四个想法，从这里开始。
问题 当 AI 智能体看到不信任的内容（用户输入、网页、电子邮件、日志）时，该内容可以引导 AI 智能体的下一步行动。工具输出可能成为提示注入向量。
生产级解决方案 将工作分为计划、受控执行和重新规划门：
规划阶段
AI 智能体提出计划：目标、步骤、预期使用的工具、约束条件以及“完成”检查项。计划由人工审核，或交由策略控制器评估。
AI 智能体提出计划：目标、步骤、预期使用的工具、约束条件以及“完成”检查项。
计划由人工审核，或交由策略控制器评估。
执行阶段（受控）
控制器强制执行：工具白名单、权限范围（只读与写入）、文件边界、速率限制、日志记录和审计。
执行阶段（受控）
控制器强制执行：工具白名单、权限范围（只读与写入）、文件边界、速率限制、日志记录和审计。
权限范围（只读与写入）
工具输出可以影响参数和局部决策。
重新规划检查点
如果工具输出推翻了原有假设，AI 智能体必须停止并重新规划。重新规划是一项功能，而不是失败。
如果工具输出推翻了原有假设，AI 智能体必须停止并重新规划。
重新规划是一项功能，而不是失败。
这一模式不是什么
不是“生成一套固定的工具调用序列，然后永不偏离”。
其本身并不能保证抵御所有提示词注入。
除非控制器真正强制执行约束，否则毫无用处。
适用于任何读取不可信输入并能够执行操作的场景（尤其是写入操作）。
适用于能够清晰定义“完成”和“允许执行的操作”的工作流。
问题：如果你对每一步都进行微观管理，自己就会成为瓶颈，同时还会阻碍 AI 智能体进行探索。
解决方案：向 AI 智能体提供：
然后让它自行选择中间步骤。
何时会失败：没有约束的控制反转会变成“AI 智能体肆意行动”。这一模式只有与以下内容配合时才安全：
问题：一次性生成非常脆弱。但缺少客观检查的“自我批评”同样脆弱——模型可能会为自己的结果强行找理由。
解决方案：反思循环应以某种信号为依据：
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)
适用于任何正确性至关重要的场景。
适用于任何能够定义检查项的场景。
问题：AI 智能体会逐渐偏离目标。等你看到最终输出时，早已为这种偏离付出了代价。
解决方案：监控那些你真正能够观察并强制约束的内容：
添加明确的“终止开关”：
核心思想：你不需要阅读私有推理过程也能保持控制。你需要的是可观察的行为和硬性关卡。
如果界面让你处处和工具较劲，模式库也帮不上忙。以下三个实用修正能够解决大多数挫败感：
如果你的工具带有内部“变更栈”界面，最终仍应以 git diff 或 PR diff 作为裁决依据。
AI 智能体更擅长：
“更新这 8 处调用点”
而不是：
“重构整个架构”
创建一个 AGENTS.md、CLAUDE.md 或“Rules”文件（名称取决于具体工具），其中包含：
这往往决定了最终体验是“像魔法一样顺畅”，还是陷入“合并地狱”。
Geoffrey Huntley 为一种常见失败模式起了一个很形象的名字：AI 智能体一开始看起来效率很高，但随着它不断遗漏隐含的上下文和约束，便会逐渐偏离目标。
更聪明的提示词解决不了这个问题。真正的解决方式是：
（参见 ghuntley 的相关文章和 how-to-ralph-wiggum。）
多智能体系统在以下情况下可能会有所帮助：
在以下情况下应避免使用：
用例：规模庞大、以机械性修改为主的迁移：
LATS 将树搜索（类似 MCTS 的探索）与 LLM 评估及反思结合起来，以探索多条推理路径。对于困难的决策任务，它可能优于线性的“单路径”方法——但代价是更高的计算成本和复杂度。
适用于以下情况：
不适用于以下情况：
许多“AI 智能体将取代人类”的论调在实践中都站不住脚。生产环境中的成功通常表现为：
设计顺畅的控制权移交流程：
需要明确：
对于大型 diff，应要求提供：
然后再审查 diff。
AI 智能体系统的一种实用安全模型，是关注以下三类风险能力的交集：
如果你的 AI 智能体同时具备这三项能力，提示词注入就像一场随时可能发生的数据泄露。
生产环境中的正确做法不是“改进提示词”，而是从任何一条执行路径中至少移除一个风险圆：
不要把原始个人身份信息（PII）放入模型上下文，而应将其替换为令牌：
一种常见的失败模式是“劣质产物引力”：
AI 智能体会放大这一问题，因为它们让更快地产出更多代码变得轻而易举。
为防止系统变成乱麻：
把 AI 智能体视为一种电动工具：
不要一次采用 113 种模式。选择三种与你当前痛点最匹配的模式。
如果你正从复制粘贴式工作流起步：
如果你已经在交付 AI 智能体：
将模式视为假设。为其添加监测机制，并衡量：
这是大多数团队都会跳过、但投资回报率最高的一件事：
有些模式会被工具吸收，最终变得不可见。你的优势不在于知道某种模式叫什么，而在于知道：
并非所有模式都经过了同等程度的验证。应将成熟度标签视为指导，并明确其判定标准。
一套实用的成熟度分级标准：
如果你正在构建生产系统，应优先选择：
成熟、已验证或最佳实践级别的模式，并将涌现阶段的模式视为实验。
智能体式工作之所以对一些人而言“神奇无比”，而对另一些人而言“毫无用处”，原因通常不在模型，而在循环。
生产环境中的智能体需要：
这个模式库中的 113 种模式既是一套词汇体系，也是一个工具箱。真正的工作，是根据你的约束条件、代码仓库和风险承受能力来应用它们。
如果你想采取下一步行动：
这正是你从演示迈向生产环境的方式。
致力于为 AI 驱动的产品构建目标明确的市场进入引擎。曾与 Numarics、Codeanywhere、Daytona 和 Steel 等创新型初创公司合作，制定增长战略和市场定位。任教于斯普利特大学，研究 AI 应用模式和开发者工具。