2025年冬季假期期间发生了一件令所有人意想不到的事情。人们本应与家人放松身心、互赠礼物，但一场悄然发生的变革却在悄然进行——而这场变革也体现在了各项指标中。

改变一切的圣诞节

“Awesome Agentic Patterns”的GitHub代码库^[1]自上线以来一直稳步增长。但圣诞节前后，其增长曲线突然飙升。短短几天内，该代码库就从默默无闻一跃成为拥有近2500个星标的项目。网站^[2]流量也随之激增。显然，某种契机出现了。

但真正的重点不在于指标，而在于谁在谈论AI智能体。

当传奇人物公开亮相

Linux 和 Git 的创始人 Linus Torvalds 曾撰文探讨使用 AI 编码代理进行“氛围编程”和吉他效果器编程。想想看，这位发明了支撑现代软件开发的版本控制系统的人，竟然公开拥抱了智能代理。

Shopify首席执行官Tobias Lütke，一位已深入开展代理辅助开发的人士，称这是他“效率最高的时期”。要知道，他可是运营着全球最大的电子商务平台之一。

或许最能说明问题的是 Flask 的创建者 Armin Ronacher，他是 Python 领域最受尊敬的人物之一。他曾对代码代理持怀疑态度，并公开表达了对它们局限性的担忧。然而，一夜之间，他的态度发生了转变。他开始推广代理辅助工作流程，记录自己的学习心得，并承认这项技术已经跨越了一个重要的门槛。

真正的瓶颈：时间

所有这些故事的共同之处在于：假期给了人们日常生活中很少能提供的东西——专属的时间。

学会有效地与AI智能体合作并非在会议间隙花五分钟就能掌握的技能。它需要：

• • 探索时间：试验智能体能做什么和不能做什么。
• • 失败循环：观察智能体走上错误道路并了解其原因
• • 模式识别：培养对哪些问题适合智能体的直觉
• • 工作流程重新设计：重新思考如何构建您的开发流程
• • 工具构建：创建使智能体高效工作的框架

在工作日，这些活动要与截止日期、会议以及持续不断的交付压力争夺时间。而在假期，会议暂停，项目紧迫性降低，开发人员终于有精力真正学习了。

这个包含 113 个从真实生产系统中收集的模式的代码库，成为了加速学习的教材。每个模式都代表了一种经过实战检验的解决方案——它们不仅能在演示环境中运行，还能在生产代码的复杂环境中发挥作用。

“拉尔夫·维格姆”现象

假期期间爆发的另一个现象是“拉尔夫·维格姆编码循环”——这个名字来源于《辛普森一家》中那个好心办坏事的角色。正如Ghuntley所描述的^[3]，这种循环指的是智能体开始工作，看似高效，但逐渐偏离正轨，因为它缺乏人类能够隐式理解的深层背景。

假日期间的激增反映了人们正在共同努力打破这种恶性循环。本系列作品中的模式——尤其是在人机协作、监控和控制权转移方面——体现了开发者们发现的解决方案。（如需了解更多关于如何避免陷入“拉尔夫·维格姆陷阱”的信息，请参阅ghuntley的指南^[4]）。

为什么这一刻如此重要

2025 年圣诞节期间的激增不仅仅是因为更多人尝试使用AI智能体，更是因为大量开发者对AI智能体的理解达到了“生产模式”阶段。他们已经超越了以下阶段：

• • “哇，这居然会写代码！”
• • “这很酷，但也会出错……”
• • “我该如何用它进行实际搭建呢？”

到：

• • “以下是生产中行之有效的模式”
• • “以下是如何将代理集成到实际工作流程中的方法”
• • “以下是如何让经纪人不仅令人印象深刻，而且值得信赖的方法”

本指南是对这113种模式的综合总结，堪称假日探索者们绘制的地图，全面展现了他们所探索的领域。无论您是刚刚踏上旅程，还是希望加深理解，这些模式都代表了众多成功将代理部署到生产环境的团队所积累的智慧。

什么是代理模式？

智能体模式是可重复的解决方案、工作流程和微型架构，可以帮助自主或半自主人工智能智能体在生产环境中完成有用的工作。

这个定义值得进一步解读。

它们填补的空白

如果你曾使用过AI智能体，你可能已经体会过演示与生产环境之间存在差距带来的挫败感：

• • 教程展示的是一次性成功案例：“以下是代理如何编写 REST API”
• • 演示突出了最佳情况：精心挑选的输入、顺利的路径、完美的输出
• • 真正的产品隐藏了让代理真正发挥作用的繁琐实现细节。

差距确实存在。一位在演示中表现出色、但在正式演出中却可能惨败的经纪人，原因如下：

• • 大规模出现极端案例
• • 上下文窗口被填满
• • 安全限制措施的影响
• • 人类工作流程需要整合
• • 可靠性要求需要安全保障措施

智能体模式是弥合这一鸿沟的桥梁。每一种模式都代表着多个团队已经实现和验证过的成果。它们并非纸上谈兵，而是源于生产经验。

三个标准

本系列中的每一种图案都符合三个标准：

1. 1. 可重复使用——多个团队已成功使用它
2. 2. 以智能体为中心——它专门改进人工智能智能体的感知、推理或行动方式。
3. 3. 可追溯——它有公开来源支持：博客文章、演讲、论文或存储库。

这并非一系列“巧妙的提示思路”或“优化技巧”，而是构建可在现实世界中运行的AI智能体的架构模式。

为什么模式很重要

软件行业早在几十年前就认识到了模式的价值。设计模式为我们提供了一套通用的词汇——一种高效地传达复杂架构理念的方法。与其说“让我描述一下我们是如何构建这些对象的”，不如说“我们正在使用工厂模式”。

代理模式具有相同的目的：

• • 共享词汇：“我们采用的是先计划后执行^[5]”这句话传达了一种完整的架构。
• • 积累智慧：从他人的生产失败和成功中学习
• • 避免重复发明：不要重新推导他人已经验证过的解决方案。
• • 设计论述：模式为我们提供了批判和改进的空间。

截至2026年初，该存储库包含113个模式，分为8个类别。让我们来探讨一下这些类别分别代表什么。

八种代理模式

这些模式自然而然地归纳为八类，每一类都针对建筑生产代理的不同维度：

1. 编排与控制

**智能体的大脑。**智能体如何决定做什么、按什么顺序做以及何时停止？

这是最大的类别，因为它代表着最根本的挑战：协调。智能体需要制定计划、执行任务、灵活应变，并且知道何时寻求帮助。

主要模式包括：

• • 先计划后执行^[5]：为了安全性和可靠性，将计划与执行分开。
• • 控制反转^[6]：给予智能体工具和目标，而不是循序渐进的指令。
• • 群体迁移^[7]：协调 10 个以上的并行子智能体执行大规模任务
• • 语言代理树搜索（LATS）^[8] ：将蒙特卡洛树搜索应用于推理问题
• • 思维之树^[9]：结构推理作为探索性树搜索

2. 工具使用及环境

**代理的交互方式。**代理如何与外部系统（例如 API、数据库、文件系统、浏览器）进行交互？

构建智能体不仅关乎模型，也关乎工具。糟糕的工具设计会导致智能体无法使用，而优秀的工具设计则能释放其全部潜能。

主要模式包括：

• • 代码优于 API^[10] ：生成并执行代码，而不是调用 REST API
• • 逐步发现工具^[11]：不要一次性向代理展示所有工具，以免其不知所措。
• • 出口锁定^[12]：一种针对不应泄露数据的代理的安全模式
• • 面向语言模型的 API 设计^[13]：设计语言模型能够真正有效使用的 API。

3. 背景与记忆

**智能体的思维模式。**智能体如何在有限的上下文窗口中积累知识？

在智能体系统中，上下文是最稀缺的资源。这些模式阐述了如何策略性地决定上下文中包含哪些信息、检索哪些信息以及持久化哪些信息。

主要模式包括：

• • 上下文窗口焦虑管理^[14]：处理因令牌限制而出现恐慌的模型
• • 情景记忆提取^[15]：在多个会话中建立长期记忆
• • 精选代码上下文^[16]：仅在上下文中选择性地包含相关代码
• • 大型文件的渐进式披露^[17]：逐步加载文件内容

4. 反馈回路

**智能体的成长机制是什么？**智能体如何通过迭代和评估来改进其输出？

最优秀的经纪人并非第一次就能成功——他们会不断迭代、反思和改进。这些模式构成了改进过程的基础。

主要模式包括：

• • 反思循环^[18]：生成、评估、改进，直至达到质量阈值
• • 丰富的反馈循环 > 完美的提示^[19]：与其纠结于初始提示，不如不断迭代。
• • 编码代理持续集成反馈循环^[20]：将测试失败用作学习信号
• • 思维图（权力的游戏）^[21] ：将推理结构化为一个包含相互关联思维的图。

5. 用户体验与协作

**人与智能体之间的伙伴关系。**人与智能体如何才能有效协作？

优秀的智能体能够增强人类的能力，而不是取代人类。这些模式注重协作、控制权转移和透明度。

主要模式包括：

• • 思维链监控与干预^[22]：观察智能体的推理过程并尽早进行干预。
• • 控制谱^[23]：在人类控制和智能体控制之间灵活切换
• • 详细推理透明性^[24]：使智能体的思考过程可见，以增强信任和便于调试
• • 用于代码审查的抽象代码表示^[25]：提供更高层次的摘要而非原始差异

6. 可靠性与评估

**经纪人的服务质量保证。**如何确定您的经纪人工作正常？

智能体测试与传统软件测试有着本质区别。这些模式主要关注评估、可复现性和可观察性。

主要模式包括：

• • 致命三重威胁模型^[26]：代理能力的安全框架
• • 反奖励作弊评分器设计^[27]：防止智能体操纵评估指标
• • 延长连贯性工作环节^[28]：在长时间互动中保持代理的专注力
• • 使用模拟工具进行工作流评估^[29]：无需实际工具调用即可测试代理逻辑

7. 学习与适应

**智能体的演化。**智能体如何随着时间的推移而改进并积累机构知识？

这是规模最小但或许对经纪人的长期成功至关重要的一个类别。这些模式能够带来持续的改进。

主要模式包括：

• • 技能库演进^[30]：将可重用代码持久化为功能
• • 智能体强化微调（Agent RFT）^[31] ：基于成功的工具交互进行训练
• • 复合工程模式^[32]：基于先前的代理工作
• • 基于方差的强化学习^[33]：根据不确定性选择训练样本

8. 安全保障

**智能体的安全保障措施。**如何防止智能体造成伤害？

这一类别虽然规模较小，但至关重要。随着特工能力的提升，安全考量变得至关重要。

主要模式包括：

• • 个人身份信息令牌化^[34]：通过令牌化敏感数据来保护隐私
• • 每个强化学习部署都使用独立的虚拟机^[35]：强化学习沙箱
• • 确定性安全扫描^[36]：循环中的自动化安全检查

每个开发者都应该知道的基础模式

面对 113 种模式，您应该从哪里入手呢？这四种模式代表了基础——它们简单易懂、应用广泛，并且能够解决智能体开发早期出现的核心挑战。

先计划后执行模式

**问题在于：*如果代理的工具输出能够改变其后续操作的选择*，恶意指令就可以将代理引导至有害步骤。这是一种提示注入的变体，但发生在工具使用层面。

**解决方案：**将推理过程分为两个不同的阶段：

1. 1. 计划阶段——LLM 在看到任何不可信数据之前，会生成一个固定的工具调用序列。
2. 2. 执行阶段——控制器运行指定的程序序列。工具输出可以影响参数，但不能改变运行的工具。

Claude Code 的“计划模式”实现了这种模式，并且通过在执行前统一方法，已证明可以将复杂任务的成功率提高 2-3 倍。

**何时使用：**任何操作集已知但参数会变化的任务——电子邮件/日历机器人、SQL 助手、代码审查助手。

**关键洞察：**需要规划的边界会随着模型的迭代而变化。随着模型功能的增强（例如 Sonnet 4.5 与 Opus 4.1），简单的任务可以一次性完成，而规划则只用于真正复杂的流程。

控制反转

**问题在于：**传统的“提示即操控”工作流程迫使人们详细说明每个步骤，限制了规模和创造力。你会成为自己智能体的瓶颈。

解决方案：为智能体提供工具和高级目标，让它自行决定流程编排。人工负责提供必要的保障措施（前 10% 和后 3%），而智能体则处理中间的 87%。

**例如：**而不是：

"Read the file, extract the UploadService class, check if it has async methods,if not, add them, then update the tests to handle async..."

你会说：

"Refactor UploadService to use async patterns. I've given you tools to read files,run tests, and make edits. Let me know when you have a PR ready for review."

AI智能体**适用场景：**几乎所有生产工作流程。你越是试图微观管理代理的执行，它的价值就越低。一旦你定义了“做什么”，就应该相信代理会去解决“怎么做”。

**关键洞见：**这种模式源自软件开发的依赖注入原则，但方向相反。不是框架控制流程，而是代理控制流程——但必须遵守你提供的约束条件。

反射环

**问题在于：**生成模型如果不对自身工作进行审查或评估，就会产生质量低下的输出。一次性生成错失了迭代改进的机会。

**解决方案：**生成草稿后，让模型根据给定的指标对其进行评分，并利用这些反馈改进回复：

for attempt in range(max_iters):    draft = generate(prompt)    score, critique = evaluate(draft, metric)    if score >= threshold:        return draft    prompt = incorporate(critique, prompt)

AI智能体**适用场景：**任何对质量要求较高的任务——写作、推理或编码。循环会持续进行，直到达到质量阈值或达到最大迭代次数。

**关键洞察：**这是许多“神奇”智能体功能背后的驱动力。平庸的智能体输出和优秀的智能体输出之间的区别，往往仅仅在于2-3次反射迭代。状态：已“成熟”，在多种实现中展现出卓越的价值。

思维链监控与打断

**问题在于：**智能体在产生最终输出之前，可能会长时间沿着错误的推理路径前进。等到意识到方法错误时，已经浪费了大量时间和代币。

**解决方案：**对智能体的中间推理过程进行主动监控，并具备早期中断和重定向的能力。实时监控思维链输出、工具调用和中间结果。

Vulcan公司的Tanner Jones建议：“时刻准备着，以便逃脱和阻止任何不良行为。”

**何时使用：**复杂的重构、对代码库的深入理解、高风险操作（数据库迁移、API 更改），或者当代理可能误解模糊的需求时。

**关键洞察：**客服人员首次使用工具进行操作往往能反映出他们是否理解问题。密切监控客服人员的首次决策——如果决策错误，立即打断。不要等到错误的操作流程完成才采取行动。

多智能体系统的架构

单个智能体存在局限性。它们容易陷入局部最优解，难以处理复杂的并行化问题，并且在需要多种专业知识的问题上会失效。多智能体系统通过专业化和协调来克服这些局限性。

为什么需要多个代理？

从单智能体系统到多智能体系统的转变遵循着一个自然的发展过程：

• • 单代理：适用于简单、顺序性的任务
• • 多智能体：对于复杂、可并行化或多领域问题而言是必要的。

关键洞见：专业化优于通用化。一个针对代码审查优化的智能体，在执行代码审查任务时，其表现将优于一个通用智能体。一群经过适当协调的专业化智能体，其性能甚至可以超越任何单个智能体。

集群迁移模式

**问题：**大规模代码迁移按顺序进行时非常耗时——框架升级、lint 规则部署、跨数百个文件的 API 迁移。

**解决方案：采用集群架构，**其中主代理协调 10 个以上的并行子代理同时处理独立的数据块：

1. 1. 主代理创建迁移计划（列出所有需要更改的文件）
2. 2. 创建待办事项列表并将其拆分成可并行处理的小块
3. 3. 生成子智能体群（10 个以上的智能体同时运行，每个智能体获取 N 个物品）
4. 4. MapReduce 执行（每个子代理独立迁移其数据块）
5. 5. 主智能体核实结果并汇总

**Anthropic 的实际使用情况：**内部用户每月在数据迁移上花费超过 1000 美元。常见的模式是：“主代理会列出一个长长的待办事项清单，然后对多个子代理进行 MapReduce 操作。先启动 10 个代理，然后每次迁移 10 个，把所有数据都迁移过去。”

**结果：**速度比传统方法提升 10 倍以上。原本需要数周才能完成的手动迁移，现在只需数小时即可完成。

**关键要点：**这种方法仅适用于原子性的迁移操作——即每个文件都可以独立迁移。清晰的规范和良好的测试覆盖率是前提条件。

语言代理树搜索（LATS）

**问题在于：**单个智能体难以应对需要探索多条解路径的复杂推理任务。简单的线性方法容易陷入局部最优解，或者忽略了其他策略。

**解决方案：**将蒙特卡洛树搜索（MCTS）与语言模型反射相结合：

• • 节点代表状态（部分解决方案或推理步骤）
• • 边代表动作（推理的下一步）
• • 利用LLM的自反能力对叶节点进行评估。
• • 反向传播会更新整个决策树中的值估计。

代理会更深入地探索有前景的分支，同时保持广度以避免陷入困境。

**结果：**在复杂推理任务中优于 ReACT、Reflexion 和Tree of Thoughts^[9] 。

**何时使用：**战略规划、数学推理、多步骤问题解决，其中早期决策会对后期结果产生重大影响。

**关键见解：**这种方法计算成本很高，但对于真正棘手的问题非常有效。对于简单的任务来说，这种方法并不值得——开销大于收益。

Oracle/Worker模式

**问题在于：**不同的模型各有优势和成本。对所有事情都使用功能最强大的模型在经济上是不可持续的。

**解决方案：**对工人使用“低成本”模型，对预言机使用“高成本”模型：

• • Oracle ：高端型号（例如 Opus）具备计划、审核和纠错功能。
• • 工人：较小的模型（例如 Haiku）执行单个任务

**权衡取舍：**您可以用极低的成本获得最佳模型的智能——大部分工作都可以并行化，并可以由更小的模型完成。但协调复杂性会增加，因此您需要强大的任务分解能力。

**关键洞察：**这种模式已在大规模生产环境中得到验证。它能帮助企业部署功能强大的代理，而无需将全部计算预算都投入到为每个请求都使用的最昂贵模型上。

从单智能体系统到多智能体系统的转变遵循着自然的发展规律。专业化优于通用化。一个针对代码审查优化的智能体，在执行代码审查任务时，其表现将优于一个通用型智能体。

人机协作谱系

尽管“完全自主代理”备受追捧，但最成功的系统本质上都是协作式的。最佳模式是增强人类能力，而不是取代人类。

这是编排，而非替代

框架很重要。如果你把智能体视为“替代品”，你就会设计成自主的，结果只会令人沮丧。如果你把智能体视为“协调者”，你就会设计成协作的，从而获得优势。

实现有效协作的关键模式：

控制范围/混合主动性

**问题在于：**将人机交互视为二元对立——要么人控制，要么智能体控制——忽略了有效协作的微妙现实。

**解决方案：**设计流畅、可控、可逆的控制转移：

• • 人主导：人指挥，智能体执行（例如，“帮我重构这个函数”）
• • 由智能体主导：智能体提出建议，人工审核（例如，“我发现了 10 个潜在的错误，请审核它们”）
• • 混合式：基于信心和语境的流畅互动

**实施方案：**智能体应明确标明置信水平以及何时越过控制边界。人类应具备清晰的干预或重新控制机制。

**关键见解：**最高效的状态既不是完全自主的，也不是完全手动的——而是动态的中间状态，在这种状态下，控制能够根据上下文、信心和能力平稳地流动。

思维链监控

我们在基础模式部分已经介绍过这一点，但在协作的背景下，这一点值得再次强调。可见性等于控制力。

当您能够实时看到智能体的推理过程时：

• • 你及早发现了错误的假设。
• • 你明白它为什么会做出这些决定。
• • 你可以介入，防止资源浪费。
• • 通过透明度建立信任。

“时刻准备着”的理念是字面意义上的——你不是被动地旁观，而是在事情偏离轨道的那一刻随时准备介入。

用于审查的抽象代码表示

**问题在于：**传统的代码审查只显示原始差异——逐行查看更改，而忽略了整体问题。而智能体生成的更改往往跨越多个文件，使得传统的代码审查难以应对。

**解决方案：**生成更高级别的表示以供审查：

• • 变更的伪代码摘要
• • 意图描述（“此操作重构 X 以启用 Y”）
• • 架构原理（“重新组织以分离关注点”）
• • 前后行为描述

**结果：*审核变得更快、更高效。您评估的是更改是否正确*，而不是逐行审查。

**关键洞察：**智能体擅长生成自身工作的总结。利用这一点，可以使人机协作的评审模式真正实现规模化。

智能体时代的安全模式

随着智能体能力的提升，安全问题也变得愈发紧迫。“致命三重威胁模型”为思考智能体安全问题提供了一个框架。

致命三重奏

**问题在于：**三种功能的结合为提示注入攻击提供了直接途径：

1. 1. 访问私有数据（机密信息、用户数据、内部系统）
2. 2. 接触不受信任的内容（用户输入、网页内容、电子邮件）
3. 3. 具备对外沟通能力（API调用、Webhook、消息发送）

当三个圆圈重叠时，攻击者可以注入指令，使代理程序窃取敏感数据。一旦指令出现在同一个上下文窗口中，LLM 就无法可靠地区分“正常”指令和恶意指令。

**解决方案：**保证在任何执行路径中至少缺少一个圆圈：

• • 移除外部网络访问权限（防止数据泄露）
• • 拒绝直接读取文件/数据库（不涉及私人数据）
• • 对不受信任的输入进行清理或隔离（不含恶意指令）

**实施：**在编排阶段，通过每个工具的能力矩阵来强制执行此操作，而不是通过脆弱的提示保护措施。

**状态：**最佳实践——这是团队应该为生产代理采用的安全框架。

区隔化

**原则：**在智能体工具设计中应用最小权限原则。智能体应该只拥有完成其特定任务所需的工具访问权限。

执行：

• • 每个代理类型的范围工具集
• • 权限边界（只读与读写）
• • 环境隔离（沙盒执行）
• • 所有工具访问的审计日志记录

**关键洞察：**通过隔离实现的安全比通过监控实现的安全更可靠。如果代理程序一开始就无法访问敏感数据，那么快速注入攻击就无法窃取数据。

个人身份信息标记化

**问题：**代理商需要处理敏感数据，但在提示中包含原始个人身份信息会带来隐私和合规风险。

**解决方案：**使用基于 MCP 的令牌化技术，在代理看到敏感数据之前将其替换为令牌：

Original: "Send email to john@example.com"Tokenized: "Send email to [EMAIL_TOKEN_123]"

AI智能体代理程序使用令牌进行操作。下游服务在执行操作时将令牌解析为实际值。

好处：

• • 对智能体推理透明
• • 个人身份信息永远不会进入模型上下文
• • 符合监管工作流程的要求
• • 必要时可逆

**关键见解：**保护隐私并不需要阻止代理处理数据，只需要谨慎地呈现数据。

2025 年圣诞节期间的激增不仅仅是因为更多人尝试使用AI智能体，更是因为大量开发者对AI智能体的理解达到了“生产模式”阶段。

其他人惨痛教训才学到的生产模式

有些模式只有在将代理部署到生产环境并观察其故障后才会显现。这些模式代表了那些身处一线团队来之不易的经验教训。

情境窗口焦虑

**发现：**像 Claude Sonnet 4.5 这样的模型表现出“情境焦虑”——它们会意识到情境窗口即将达到极限，并主动总结或提前结束任务，即使还有足够的情境。

症状：

• • 任务进行中突然总结
• • 仓促做出“收尾”决定
• • 明确提到“空间不足”
• • 尽管具备足够的背景信息能力，但工作仍未完成。

解决方案：

1. 1. 启用较大的上下文窗口（例如，100万个令牌），但将实际使用量限制在20万个令牌——这提供了心理上的“缓冲期”。
2. 2. 积极反问：“你还有很多信息需要了解——不要着急。”
3. 3. 提示信息中明确代币预算透明度

来源： Cognition AI 与 Claude Sonnet 4.5 构建 Devin 的经验。

**关键洞见：**模型行为包含一些在确定性系统中不存在的心理特性。理解这些特性是生产代理工程的一部分。

智能体强化微调（Agent RFT）

**问题在于：**传统的强化学习需要数百万个训练样本。对于特定智能体的任务而言，收集如此庞大的数据量是不切实际的。

**突破性进展：**基于实际工具交互的端到端训练能够高效利用样本。实际结果表明，仅需 100-1000 条成功轨迹，性能即可提升 50-72% 。

工作原理：

1. 1. 收集成功执行代理操作的轨迹（工具名称、中间推理、最终结果）
2. 2. 微调模型以模仿这些成功的模式
3. 3. 该模型学习的是工具使用策略，而不仅仅是反应策略。

**关键在于：*训练模型的关键在于处理代理的工作流程*，而不仅仅是输入输出对。模型需要学习何时调用工具、如何安排工具的顺序以及如何从故障中恢复。

技能库演变

**问题在于：**智能体经常在不同的会话中解决类似的问题。如果没有持久化机制，它们每次都必须重新寻找解决方案，从而浪费代币和时间。

**解决方案：**将可行的代码实现保留下来，使其成为可重用的技能，并随着时间的推移不断发展：

进化路径：

1. 1. 代理编写代码以解决当前问题
2. 2. 如果解决方案有效，请保存到 skills/ 目录。
3. 3. 重构以实现通用化（参数化硬编码值）
4. 4. 添加文档（用途、参数、返回值、示例）
5. 5. 智能体在后续会话中发现并重用技能

渐进式披露优化：不再将所有技能加载到上下文中，而是注入技能描述并提供按需加载。在一次实现中，这种方法减少了 91% 的令牌（26 个工具，17k 个令牌 → 4 个选定的工具，1.5k 个令牌）。

**关键洞察：**企业希望员工能够随着时间的推移不断提升能力，而不是每次都从零开始。技能最终会成为企业知识。

The Maturity Model

并非所有模式都经过同等验证。该存储库使用状态系统来跟踪成熟度：

• • 提议——已提出但尚未被广泛采纳
• • 新兴领域——早期采用，前景可观但尚未证实
• • 已确立——广泛使用、易于理解
• • 已在生产环境中验证——已在实际生产系统中大规模验证。
• • 最佳实践——业界共识，认为这是正确的方法
• • 快速改善——该领域发展迅速，模式频繁演变
• • 实验性但很棒——尚未证实，但太有趣了，不容忽视。

成熟为何重要

在智能体人工智能这样快速发展的领域，成熟度跟踪至关重要，原因如下：

• • 早期采用风险：新兴模式可能存在隐藏的失效模式
• • 稳定性与创新：生产系统需要既定模式；研发需要实验模式
• • 投资决策：您将工程资源投资于何处？
• • 预期设定：你对某种模式可以抱有怎样的合理预期？

“快速改进”类别

这种现状承认，智能体开发的某些领域发展如此迅速，以至于模式的生命周期很短。今天的最佳实践可能在六个月后就被取代。

例如推理优化、令牌预算策略以及工具设计的某些方面。

“实验性但很棒”类别

尽管验证有限，但有些模式极具潜力，不容忽视。它们可能是：

• • 来自前沿研究的新方法
• • 一个富有远见的团队所展现的模式
• • 在特定情况下效果显著的技术

标签上写着：“这令人兴奋，但请谨慎行事，并根据您的使用场景进行验证。”

实用要点：如何开始

你刚刚全面了解了代理模式。那么，你究竟该从哪里入手呢？

第一步：选择三种图案

不要试图一次性采用 113 种模式。选择三种能够解决你当前挑战的模式：

如果你正在构建你的第一个代理：

• • 控制反转^[6]（编曲）
• • 反射循环^[18]（质量）
• • 思维链监控^[22]（可见性）

如果您正在扩展现有代理：

• • 技能库演进^[30]（知识持久化）
• • 先计划后执行^[5]（可靠性）
• • 控制谱^[23]（合作）

如果您注重安全性：

• • 致命三重威胁模型^[26]（安全框架）
• • 分隔^[37]（工具设计）
• • 个人身份信息令牌化^[34]（隐私）

步骤二：实施、观察、迭代

模式并非即插即用，需要根据具体情况进行调整：

1. 1. 在您的环境中实现该模式
2. 2. 观察它在实际工作负载下的表现。
3. 3. 根据你的学习成果迭代改进实现方式。
4. 4. 记录你的学习成果——即使是失败的经验也很有价值。

步骤 3：构建模式库

随着经验的积累，你会发现自己的行事模式：

1. 1. 注意代理实现中反复出现的解决方案
2. 2. 提取核心模式（问题→解决方案→权衡取舍）
3. 3. 包含示例和参考文献的文档
4. 4. 回馈社区

这个代码库从 0 个模式增长到 113 个模式，是因为团队分享了他们的经验。你的模式或许也能帮助到其他人。

第四步：保持与时俱进

这个领域发展迅速。今天“快速改进”的模式，明天可能就成了“既定模式”或“最佳实践”，甚至完全被取代。

• • 请关注代码库中的新模式
• • 关注那些乐于分享的思想领袖（Anthropic、Sourcegraph、Cognition、Will Larson、Simon Willison）
• • 在低风险情境下尝试探索新兴模式
• • 分享你的发现

未来：缺失的是什么，下一步是什么

本合集中的113个模式代表了2026年初智能体人工智能的发展现状。但前沿领域在不断拓展。还缺少什么？

差距与机遇

应该发展壮大的小类别：

• • 安全保障——随着特工部署的增加，保障范围将扩大。
• • 学习与适应——真正能够提升智能体性能的圣杯

未充分开发的地区：

• • 多模态代理（超越文本和代码）
• • 长时间运行的自主代理（以小时/天为单位，而非分钟）
• • 代理间通信协议
• • 智能体资源分配的经济模型
• • 智能体行为的法律和合规框架

下一波

下一个重大发展方向很可能是智能体学习。目前的智能体大多是静态的——它们无法从经验中获得根本性的提升。智能体 RFT^[31] 、技能库^[30]和复合模式^[32]都指向这样一种智能体：

• • 从每一次互动中学习
• • 随着时间的推移，积累机构知识。
• • 在代理实例之间共享技能
• • 无需手动微调即可改进

这是从“智能工具”向“真正智能系统”的过渡。

结论：假期结束了，革命仍在继续

2025 年圣诞节期间的关注度激增是真实存在的，但这仅仅是个开始。GitHub 上 2500 个星标以及开发者们兴趣的爆发，代表着一个集体性的“顿悟时刻”——人们意识到，只要拥有正确的模式，AI智能体就可以投入生产使用。

但光靠模式是不够的。真正的工作是：

• • 充分了解你的领域，以便知道代理商应该扮演什么角色。
• • 构建提高代理商生产力的工具和基础设施
• • 培养判断力，知道何时应该信任智能体，何时应该介入。
• • 培养耐心，反复尝试，克服失败，最终建立可靠的系统。

这 113 种图案的集合就像一张地图，但你仍然需要亲自去探索这片区域。

这仍然是第一天

尽管目前智能体人工智能的发展水平令人印象深刻，但我们仍处于非常早期的阶段。2026年验证过的模式，到2028年就会显得非常原始。今天看似尖端的技术，明天可能就成了标配。

获胜的队伍将是那些：

• • 通过公开分享模式更快地学习
• • 快速迭代，更快地失败
• • 利用已有的知识而不是重新发明轮子
• • 保持好奇心，不断探索未知领域。

引用链接

[1] GitHub代码库:https://github.com/nibzard/awesome-agentic-patterns[2]网站:https://agentic-patterns.com/[3]Ghuntley所描述的:https://ghuntley.com/ralph/[4]ghuntley的指南:https://github.com/ghuntley/how-to-ralph-wiggum[5]先计划后执行:https://agentic-patterns.com/patterns/plan-then-execute-pattern/[6]控制反转:https://agentic-patterns.com/patterns/inversion-of-control/[7]群体迁移:https://agentic-patterns.com/patterns/swarm-migration-pattern/[8]语言代理树搜索（LATS）:https://agentic-patterns.com/patterns/language-agent-tree-search-lats/[9]思维之树:https://agentic-patterns.com/patterns/tree-of-thought-reasoning/[10]代码优于 API:https://agentic-patterns.com/patterns/code-over-api-pattern/[11]逐步发现工具:https://agentic-patterns.com/patterns/progressive-tool-discovery/[12]出口锁定:https://agentic-patterns.com/patterns/egress-lockdown-no-exfiltration-channel/[13]面向语言模型的 API 设计:https://agentic-patterns.com/patterns/llm-friendly-api-design/[14]上下文窗口焦虑管理:https://agentic-patterns.com/patterns/context-window-anxiety-management/[15]情景记忆提取:https://agentic-patterns.com/patterns/episodic-memory-retrieval-injection/[16]精选代码上下文:https://agentic-patterns.com/patterns/curated-code-context-window/[17]大型文件的渐进式披露:https://agentic-patterns.com/patterns/progressive-disclosure-large-files/[18]反思循环:https://agentic-patterns.com/patterns/reflection/[19]丰富的反馈循环 > 完美的提示:https://agentic-patterns.com/patterns/rich-feedback-loops/[20]编码代理持续集成反馈循环:https://agentic-patterns.com/patterns/coding-agent-ci-feedback-loop/[21]思维图（权力的游戏）:https://agentic-patterns.com/patterns/graph-of-thoughts/[22]思维链监控与干预:https://agentic-patterns.com/patterns/chain-of-thought-monitoring-interruption/[23]控制谱:https://agentic-patterns.com/patterns/spectrum-of-control-blended-initiative/[24]详细推理透明性:https://agentic-patterns.com/patterns/verbose-reasoning-transparency/[25]用于代码审查的抽象代码表示:https://agentic-patterns.com/patterns/abstracted-code-representation-for-review/[26]致命三重威胁模型:https://agentic-patterns.com/patterns/lethal-trifecta-threat-model/[27]反奖励作弊评分器设计:https://agentic-patterns.com/patterns/anti-reward-hacking-grader-design/[28]延长连贯性工作环节:https://agentic-patterns.com/patterns/extended-coherence-work-sessions/[29]使用模拟工具进行工作流评估:https://agentic-patterns.com/patterns/workflow-evals-with-mocked-tools/[30]技能库演进:https://agentic-patterns.com/patterns/skill-library-evolution/[31]智能体强化微调（Agent RFT）:https://agentic-patterns.com/patterns/agent-reinforcement-fine-tuning/[32]复合工程模式:https://agentic-patterns.com/patterns/compounding-engineering-pattern/[33]基于方差的强化学习:https://agentic-patterns.com/patterns/variance-based-rl-sample-selection/[34]个人身份信息令牌化:https://agentic-patterns.com/patterns/pii-tokenization/[35]每个强化学习部署都使用独立的虚拟机:https://agentic-patterns.com/patterns/isolated-vm-per-rl-rollout/[36]确定性安全扫描:https://agentic-patterns.com/patterns/deterministic-security-scanning-build-loop/[37]分隔:https://agentic-patterns.com/patterns/tool-capability-compartmentalization/