从Claude Code源码泄露，读懂12个可复用的Agentic Harness设计模式（生产级落地指南）

前段时间，Claude Code源码意外泄露，在技术圈掀起了一场学习热潮。不同于普通开发者只关注代码本身的实现细节，真正有价值的，是藏在代码背后的设计思路，那些支撑Claude Code成为生产级AI编码助手的核心架构逻辑，并不是某个产品的专属功能，而是可以复用到所有Agent开发中的通用模式。

我们都知道，AI模型会迭代更新，工具会不断升级，但好的设计模式会一直沉淀下来，成为支撑Agent长期稳定运行的基石。就像Kubernetes Patterns和Prompt Patterns的作者Bilgin lbryam，从泄露的源码中提炼出12个可直接复用的Agentic Harness设计模式，按功能分成了四大类：记忆与上下文、工作流与编排、工具与权限、自动化。

这12个模式，每一个都对应着Agent开发中最常见的痛点，比如上下文不够用、记忆混乱、权限失控、流程混乱等。今天，我们就用最通俗的语言，把这些生产级的设计模式拆解开，从原理、落地方式、适用场景到权衡点，一步步讲清楚，让无论是刚入门Agent开发的新手，还是有经验的开发者，都能直接借鉴、落地使用。

毕竟，这次Claude Code的泄露，给了我们一个难得的窗口，让我们能窥见顶级AI编码助手的内部架构。这些从真实场景中打磨出来的模式，不是空谈的理论，而是能解决实际问题的架构智慧，值得每一个做Agent应用的人认真研究。

一、记忆与上下文：让Agent"记对事、记牢事"，不浪费每一个Token

Agent的核心能力之一，就是"记忆"，记住规则、记住上下文、记住用户偏好。但很多开发者在做Agent时，都会陷入一个误区：要么让Agent"什么都记"，导致上下文臃肿、Token浪费，甚至触发窗口限制；要么让Agent"什么都不记"，每次会话都从零开始，重复踩坑、效率低下。

Claude Code提炼的5个记忆与上下文模式，本质上是一条逐步演进的路径：从固定规则文件，到按范围限制规则，再到分层记忆、后台清理，最后到上下文压缩，一步步解决"记不住、记太乱、记太多"的问题。

1. 持久化指令文件模式：让Agent每次会话都"带着规则开工"

做过Agent开发的人都有过这样的体验：每次开启新的会话，都要重复告诉Agent同样的约定，比如代码构建命令、测试方式、架构规则、命名约定，甚至还要反复纠正Agent之前犯过的错误。就像一个新员工每次上班都要重新问一遍工作要求，效率极低，还容易出错。

持久化指令文件模式，就是为了解决这个问题而生的，做法其实非常简单：在项目根目录下，放一个固定的配置文件（比如instruction.json或.claude-instructions），里面详细写清楚项目的所有通用规则，包括但不限于：

代码构建命令：如npm run build（前端项目）、mvn clean package（Java项目）；
测试方式：单元测试命令pytest、集成测试流程、测试覆盖率要求；
架构规则：比如微服务项目的分层规范（Controller→Service→Dao）、禁止使用的依赖；
命名约定：变量名采用小驼峰、类名采用大驼峰、接口名以I开头；
边界限制：比如禁止修改核心配置文件、禁止执行高危Shell命令。

这个配置文件跟着代码仓库一起管理，每次Agent开启会话时，会自动加载这个文件，不需要用户再重复输入规则。这样一来，无论多少次会话，Agent都能保持一致的行为，避免重复踩坑，也减少了用户的沟通成本。

适用场景非常明确：需要在多个会话里反复处理同一个代码库的场景，比如长期维护一个项目、持续迭代某个产品的代码。

但这个模式也有明显的权衡点：需要承担一定的维护成本。这个指令文件必须跟着项目一起更新，如果项目架构调整、命名规范变化，而指令文件没有及时更新，反而会误导Agent，让Agent按照旧规则做事，效果还不如没有这个文件。所以，一定要建立"项目更新同步更新指令文件"的机制，避免规则过时。

2. 作用域上下文组装模式：解决"规则太杂、不适用"的痛点

持久化指令文件在小项目里很好用，但项目一旦变大，问题就来了。比如一个Monorepo项目，里面包含前端、后端、移动端多个模块，每个模块的规则都不一样，前端需要遵循React代码规范，后端需要遵循Java代码规范，移动端需要遵循Flutter规范。如果把所有规则都写在一个指令文件里，要么文件越写越长，最后没人愿意看、没人维护；要么写得太笼统，对具体模块没有实际指导意义。

作用域上下文组装模式，就是把指令拆分成不同的作用域，让Agent根据当前所在的位置，动态加载对应的规则。简单来说，就是"哪里需要，就加载哪里的规则"，既保证全局一致，又允许局部差异。

具体的做法是，将指令文件按作用域分层，常见的分层方式有5级：

组织级：整个公司或团队的通用规则，比如代码提交规范、安全底线；
用户级：用户个人的偏好，比如喜欢的代码风格、常用的工具；
项目根目录级：整个项目的通用规则，比如项目的构建流程、依赖管理规范；
父目录级：某个模块的通用规则，比如后端模块的整体架构规范；
子目录级：具体文件或子模块的规则，比如某个接口的开发规范、某个组件的编码要求。

Agent在工作时，会先判断自己当前操作的文件所在的目录，然后自动加载该目录及以上所有作用域的规则，忽略无关的规则。比如Agent在修改前端目录下的文件时，只会加载组织级、用户级、项目根目录级、前端父目录级和当前子目录的规则，不会加载后端的规则，避免规则干扰。

另外，通过"导入"的方式，还可以把大的指令集拆开管理，避免重复。比如组织级的代码提交规范，可以被所有项目导入，不需要每个项目都重复写一遍，减少维护成本。

适用场景：Monorepo项目、多语言项目，或者不同目录有不同规范的代码库。比如一个大型互联网公司的项目，包含多个业务模块，每个模块的技术栈和规范都不同，用这个模式就能很好地管理规则。

权衡点也很明显：可读性会变差。规则分散在多个文件、多个目录下，很难一眼看清Agent实际加载了哪些规则，不同作用域之间也可能出现规则冲突。比如父目录的规则和子目录的规则不一致，Agent需要有明确的优先级判断逻辑（通常是子目录规则优于父目录规则），否则会出现行为混乱。

3. 分层记忆模式：让Agent"记重点、不浪费Token"

很多开发者做Agent时，会把所有记忆都塞进上下文里------用户的提问、Agent的回复、代码片段、规则文件，不管重要与否，全部堆在一起。这样做的后果很明显：Token消耗飞快，很快就会撞上上下文窗口的上限，而且重要信息会被大量无关信息淹没，Agent反而记不住关键内容。

分层记忆模式的核心思路，就是"把记忆分等级，按需加载"，就像我们人类的记忆，大脑里会记住最关键的信息（比如自己的名字、家庭住址），不太重要的信息（比如昨天吃了什么）会暂时存在短期记忆里，需要时再回忆，更详细的信息（比如小时候的事情）会存在长期记忆里，不常用就不会轻易调取。

具体的做法是，把Agent的记忆分成三层：

索引层：最精简的核心信息，始终放在上下文里，控制在几百行以内。比如项目的核心规则、当前任务的目标、用户的核心偏好，这些信息是Agent每次工作都需要用到的，必须随时可用；
活跃层：和当前任务相关的内容，按需加载到上下文。比如当前正在修改的代码文件、相关的依赖信息、近期的对话记录，这些信息只在当前任务中有用，任务结束后可以卸载；
持久层：完整的历史记录和详细信息，存在磁盘或数据库里，不放入上下文。比如所有的对话记录、完整的规则文件、历史代码修改记录，这些信息平时用不到，只有需要回溯历史、查询细节时，Agent才会去磁盘调取。

举个例子：如果Agent正在修改一个Java接口，索引层会包含"Java接口命名规范、当前任务目标（修改接口参数）"；活跃层会包含"该接口的现有代码、相关的依赖类、用户最近的修改要求"；持久层会包含"该接口过去半年的修改记录、整个项目的完整规则文件、之前所有的对话记录"。这样一来，上下文里只保留最关键、最常用的信息，既节省Token，又能避免信息混乱。

适用场景：需要跨多次会话保留偏好、决策或状态的Agent。比如长期维护一个项目的编码助手，需要记住用户的编码偏好、项目的历史修改记录，同时又不能让上下文过于臃肿。

权衡点：实现会更复杂。需要开发者想清楚，哪些信息该放在索引层、哪些该放在活跃层、哪些该放在持久层，还要设计好信息的"上升"和"下沉"机制，比如某个活跃层的信息被频繁使用，就可以上升到索引层；某个索引层的信息长期不用，就可以下沉到持久层。同时，还要保证索引层的信息和持久层的实际数据是同步的，避免出现"索引和实际内容不一致"的问题。

4. 记忆整合模式：给Agent做"记忆垃圾回收"，保持记忆干净可用

即使做了分层记忆，Agent的记忆用久了还是会"变乱"。比如：重复的信息越来越多（比如用户多次提到同一个规则，Agent都记了下来），旧信息和新信息打架（比如项目规则更新后，旧规则还留在记忆里），索引层的信息慢慢膨胀，最后还是会占用大量Token。

记忆整合模式，就相当于给Agent做一次"垃圾回收"，通过后台整理机制，在Agent空闲时定期清理记忆，让记忆保持干净、可用。Claude Code源码中提到的autoDream功能，本质上就是在实现这个模式------自动合并重复的记忆、处理新旧信息的冲突、控制索引层的规模，让Agent的记忆始终处于"有用、简洁"的状态。

具体的整理逻辑主要有三点：

去重：识别并删除重复的信息，比如重复的规则、重复的对话片段，避免占用多余的Token；
删旧：删除过期、无用的信息，比如已经过时的项目规则、长期不用的历史记录，优先保留最新、最有用的信息；
重组：优化记忆的结构，比如把分散的规则整合到一起，把碎片化的对话总结成连贯的摘要，让Agent更容易调取和使用。

举个例子：用户在多次对话中，反复提到"代码命名要采用小驼峰"，Agent的记忆里会出现多次这句话，记忆整合机制会自动合并这些重复内容，只保留一句；如果项目更新了命名规范，从"小驼峰"改成"下划线"，记忆整合机制会删除旧的"小驼峰"规则，保留新的"下划线"规则，避免新旧规则冲突。

适用场景：Agent会长期运行、持续积累记忆，而且不方便靠人工去维护的场景。比如一个面向企业的AI编码助手，需要服务多个用户、处理多个项目，长期积累的记忆会非常多，靠人工清理不现实，就需要自动整合机制。

权衡点：整理本身也要消耗Token，而且整理结果不一定完全准确。如果清理太激进，可能会把有用的信息一起删掉，比如把用户偶尔提到的、但很重要的偏好删掉；如果清理太保守，又起不到"垃圾回收"的效果，记忆还是会变乱。所以，需要根据实际场景，调整整理的频率和强度，找到一个平衡点。

5. 渐进式上下文压缩模式：对话再长，也不会触发窗口上限

无论怎么优化记忆，只要对话轮次多了，比如超过20～30轮，上下文还是会慢慢膨胀，最终撞上窗口上限。要么早期的对话内容被挤掉，Agent忘记之前的约定；要么任务直接无法继续，只能重新开启会话，之前的工作全部白费，这两种情况都非常影响体验。

渐进式上下文压缩模式，就是通过"分层压缩"的方式，解决上下文膨胀的问题，核心思路是：越久远的信息，保留得越粗略；越新的信息，保留得越详细。就像我们人类回忆事情，最近发生的事情能记得很多细节，很久之前的事情，只能记得一个大概的轮廓。

具体的做法的是，将对话内容按时间顺序分成多个层级，每个层级采用不同的压缩强度：

最新层（0～5轮对话）：不压缩，完整保留所有细节，包括用户的提问、Agent的回复、代码片段、修改建议，因为这些信息是当前任务最需要的；
近期层（6～15轮对话）：轻量压缩，保留核心内容，删除无关的语气词、重复的表述，比如把"你好，我想修改这个代码，具体要求是......"压缩成"用户要求修改某代码，具体要求为......"；
远期层（16轮以上对话）：深度压缩，只保留最核心的摘要，比如把10轮关于"项目规则调整"的对话，压缩成"用户在第8～18轮对话中，调整了项目的命名规范和构建流程"。

Claude Code源码中，就采用了类似的多层压缩思路，甚至把压缩层级分得更细，根据对话轮次的多少，动态调整压缩强度，既保证了当前任务能用到的信息足够详细，又避免了上下文过于臃肿，突破窗口限制。

适用场景：对话轮次比较多的任务，比如复杂的代码重构、多阶段的项目开发，需要Agent持续跟进，对话轮次可能达到几十甚至上百轮。

权衡点：压缩一定是有损的。信息在一轮轮总结和压缩中，必然会丢失一些细节，比如用户之前提到的某个细微的偏好、某个代码的细节要求，可能会在压缩过程中被忽略。如果后面的任务又需要这些细节，Agent可能会"编造"信息，而不是承认自己不知道，这会影响任务的准确性。所以，在压缩时，需要优先保留关键信息，同时给Agent设置"无法回忆时，主动询问用户"的逻辑，避免编造信息。

二、工作流与编排：让Agent"有条理地做事"，不混乱、不返工

很多Agent的默认做法，是把"查资料、做规划、改代码、测效果"这些步骤混在一起，一上来就动手改代码，看似高效，实则很容易出问题，比如理解不完整，改错文件，漏掉依赖，或者忽略现有的实现方式，最后导致返工，反而浪费更多时间。

Claude Code提炼的3个工作流与编排模式，核心就是一个词：分离。把读取和写入拆开，把"查资料"和"改代码"的上下文拆开，把顺序执行和并行执行也拆开。这样做的好处是，即使任务变得越来越复杂，Agent的工作流程也不会混乱，能始终保持高效、准确。

6. 探索-规划-行动循环模式：先搞清楚，再动手，不盲目

做过开发的人都知道，拿到一个需求，最忌讳的就是一上来就写代码。如果连需求都没理解清楚、连现有代码的结构都没摸清，很容易写出不符合要求、甚至无法运行的代码，最后只能返工。Agent也是一样，一上来就让它改代码，很容易出现各种问题。

探索-规划-行动循环模式，就是把Agent的工作流程拆成三步，而且权限逐步放开，让Agent"先搞清楚、再做决定、最后动手"，避免盲目操作。这三步具体是：

探索阶段：只读不写，摸清情况。Agent只能读取代码、查询相关信息，不能修改任何文件、不能执行任何写操作。这个阶段的核心目标，是理解当前的代码结构、依赖关系、现有问题，以及用户的具体需求。比如用户让Agent修改一个接口，探索阶段Agent会先读取该接口的代码、相关的依赖类、测试用例，搞清楚接口的功能、参数、返回值，以及当前存在的问题；
规划阶段：沟通对齐，明确方案。Agent根据探索阶段获取的信息，制定详细的修改方案，包括修改哪些文件、修改哪些代码、如何测试，然后把方案反馈给用户，和用户对齐思路。如果用户有不同的意见，Agent再调整方案，直到双方达成一致；
行动阶段：执行操作，完成任务。方案对齐后，Agent再获得写权限，按照规划的方案修改代码、执行测试，完成用户的需求。如果执行过程中遇到问题，比如修改后代码报错，Agent会回到探索阶段，重新查看相关信息，调整方案后再继续行动。

这个模式的本质，就是"先调研、再规划、后执行"，和我们人类做开发的流程完全一致。比如我们拿到一个需求，会先看现有代码、查相关文档，然后制定开发方案，最后再写代码、做测试，这样能最大程度避免返工。

适用场景：不熟悉的代码库，或者涉及多个文件的复杂修改。比如Agent第一次接触某个项目，或者用户要求修改一个涉及多个模块、多个文件的功能，用这个模式能让Agent更准确地理解需求、完成任务。

权衡点：会慢一点。相比一上来就动手改代码，多了探索和规划这两步，对于一些简单的小任务，比如修改一个变量名、调整一行代码，会显得有点"流程过重"，浪费时间。所以，在实际落地时，可以根据任务的复杂度，动态调整流程------简单任务可以跳过探索和规划，直接行动；复杂任务则严格执行三步流程。

7. 上下文隔离子智能体模式：避免"信息污染"，让Agent专注做事

很多Agent在处理长会话、多阶段任务时，会出现"上下文污染"的问题------会话一长，所有东西都会堆在同一个上下文里：调研内容、规划讨论、代码修改、日志输出，全混在一起。等真正开始改代码时，很多无关信息已经在干扰Agent的判断，导致Agent出错。

比如，Agent先做调研，上下文里充满了各种调研资料、文档链接；然后做规划，又把规划方案、讨论记录加到上下文里；最后改代码时，上下文里已经堆满了无关的调研和规划信息，Agent很容易被这些信息干扰，写错代码、漏改内容。

上下文隔离子智能体模式，就是把任务拆给不同的子Agent，每个子Agent都有自己独立的上下文和权限，只处理自己负责的阶段，避免"信息污染"。简单来说，就是"专人专岗"，每个子Agent只做自己擅长的事情，不接触无关的信息。

具体的做法是，拆分出三个核心子Agent，各自负责不同的阶段：

探索子Agent：只负责调研，没有写权限，只能读取代码、查询信息、分析结构。它的上下文里，只包含调研相关的内容，比如代码片段、文档信息、问题分析，不涉及规划和执行的内容；
规划子Agent：只负责制定方案，没有写权限，只能根据探索子Agent提供的调研结果，制定修改方案、和用户对齐思路。它的上下文里，只包含调研结果、用户需求、规划方案，不涉及调研细节和执行操作；
执行子Agent：只负责执行，拥有完整的写权限和工具权限，只能根据规划子Agent提供的方案，修改代码、执行测试。它的上下文里，只包含规划方案、需要修改的代码、测试结果，不涉及调研和规划的无关信息。

三个子Agent之间，通过主Agent进行协调：主Agent负责接收用户需求，把需求分配给探索子Agent，然后把探索结果传递给规划子Agent，再把规划方案传递给执行子Agent，最后把执行结果反馈给用户。每个子Agent只接触自己需要的信息，不会被无关信息干扰，能更专注、更准确地完成自己的任务。

适用场景：长会话、多阶段流程，或者不同阶段对上下文要求差异很大的任务。比如一个复杂的代码重构任务，需要先调研现有代码的问题、再规划重构方案、最后执行重构和测试，每个阶段的上下文需求都不同，用这个模式能有效避免信息污染。

权衡点：需要额外协调。主Agent要负责各个子Agent之间的信息传递，决定每一步传递什么信息、传递多少信息。如果传递的信息太少，子Agent可能会因为缺少细节而无法完成任务；如果传递的信息太多，又会回到"上下文污染"的问题，失去隔离的意义。所以，需要设计好信息传递的规则，确保每个子Agent只拿到自己需要的核心信息。

8. 分支-合并并行模式：让Agent"多线并行"，提高效率

有些任务其实可以拆成多个互不依赖的子任务，但很多Agent的默认做法是"顺序执行"，一次只能处理一个子任务，最后导致整体效率很低。比如，用户要求修改10个互不相关的代码文件，Agent只能一个一个修改，浪费大量时间；再比如，一个项目需要同时优化前端和后端的代码，Agent只能先优化前端，再优化后端，无法并行处理。

分支-合并并行模式，就是把任务拆成多个分支，让多个子Agent并行处理，最后再把结果合并回来，提高整体效率。这个模式的思路，和我们平时用Git做分支开发很像------每个人在自己的分支上开发，互不干扰，开发完成后再合并到主分支。

具体的做法是：

拆分任务：主Agent把一个复杂任务，拆成多个互不依赖的子任务。比如，把"修改10个互不相关的代码文件"拆成10个子任务，每个子任务对应修改一个文件；
并行执行：为主每个子任务分配一个子Agent，每个子Agent在独立的代码副本里工作（比如用git worktree创建独立的工作目录），互不干扰。多个子Agent同时执行自己的子任务，实现并行处理；
合并结果：所有子Agent完成自己的子任务后，主Agent把各个子任务的结果合并回来，比如把10个修改后的文件合并到主代码库，然后执行整体测试，确保合并后的代码没有冲突、能正常运行。

举个例子：用户要求优化一个项目的性能，需要修改前端的加载速度、后端的接口响应速度、数据库的查询效率，这三个子任务互不依赖。主Agent可以拆分出三个子Agent，分别负责前端优化、后端优化、数据库优化，三个子Agent并行工作，原本需要3小时完成的任务，可能1小时就能完成，效率提升非常明显。

适用场景：可以拆成多个互不依赖子任务的场景。比如，批量修改多个互不相关的文件、同时优化项目的多个模块、并行执行多个测试用例等。

权衡点：合并会更复杂。如果不同分支的子任务，修改了同一个代码文件的同一部分，就会出现合并冲突，而且这种冲突可能比顺序处理更难解决。比如，两个子Agent同时修改同一个接口的代码，一个修改了参数，一个修改了返回值，合并时就会出现冲突，需要主Agent或用户手动解决。所以，在拆分任务时，要尽量避免子任务修改同一部分内容，同时做好冲突处理机制。

三、工具与权限：让Agent"能做事、不闯祸"，控制风险

如果说记忆与上下文模式，解决的是"Agent知道什么"的问题，工作流模式解决的是"Agent怎么做事"的问题，那么工具与权限模式，解决的就是"Agent能做什么"的问题。

从Claude Code的源码来看，它在工具设计和权限控制上，已经细到了非常具体的粒度，远比现在大多数Agent框架要严格。毕竟，Agent一旦拥有了工具权限，比如执行Shell命令、修改文件、访问外部系统，就可能出现风险，比如误删文件、执行高危命令、泄露敏感信息。所以，工具与权限的设计，核心是"既要让Agent能完成任务，又要控制风险，避免闯祸"。

9. 渐进式工具扩展模式：按需开放工具，不浪费、不混乱

很多开发者在做Agent时，会一开始就把所有工具都开放给Agent，比如文件操作工具、Shell命令工具、搜索工具、数据库操作工具，不管Agent用不用得到，全部开放。这样做的后果是，工具太多，Agent的选择成本变高，很容易选错工具；而且很多工具Agent很少用到，开放后反而增加了风险和维护成本。

渐进式工具扩展模式，就是"按需开放工具"，先给Agent最基础、最常用的工具，够用就行；其他工具，根据任务需求，再逐步开放。这样既能减少Agent的选择成本，又能降低风险，避免不必要的工具带来的麻烦。

具体的做法是，把工具分成两类：

基础工具：默认开放，满足大多数简单任务的需求。比如，文件读取工具（读取代码文件、配置文件）、文件写入工具（修改代码、保存文件）、基础搜索工具（查询项目内的文档、代码），这些工具风险低、使用频率高，默认开放给Agent；
扩展工具：按需开放，只有在需要时才开放。比如，Shell命令工具（执行构建、测试、部署命令）、数据库操作工具（查询、修改数据库）、外部API调用工具（访问第三方服务），这些工具风险较高、使用频率较低，只有当任务需要时，才开放给Agent，任务完成后，立即收回权限。

举个例子：Agent默认只有文件读取和写入工具，当用户要求"构建项目并测试"时，主Agent会临时开放Shell命令工具，允许Agent执行npm run build和npm run test命令，构建和测试完成后，立即收回Shell命令工具的权限，避免Agent误执行其他高危命令。

适用场景：工具很多，但大多数任务其实只用到一小部分的场景。比如，一个AI编码助手，平时主要做代码修改、代码优化，很少用到数据库操作和外部API调用，就可以采用这种模式，按需开放工具。

权衡点：需要额外判断什么时候该开新工具。如果开放工具的时机太晚，Agent可能已经走了弯路，浪费了一些对话轮次。比如，Agent需要执行构建命令，但Shell工具没有及时开放，Agent可能会尝试用其他方式构建，结果失败，浪费时间。所以，需要设计好工具开放的判断逻辑，比如当Agent明确提出需要某个工具时，或者当任务中包含需要某个工具的操作时，自动开放对应的工具。

10. 命令风险分类模式：自动判断风险，不麻烦、不闯祸

如果让Agent随便执行Shell命令、修改系统配置，风险会非常高，比如Agent误执行rm -rf /命令，会删除整个系统的文件；如果让Agent每执行一个命令都需要用户确认，用户很快就会点到麻木，失去耐心，而且效率很低。

命令风险分类模式，就是在Agent执行命令前，做一层"风险判断"，根据命令的风险等级，采取不同的处理方式：低风险的命令自动放行，中风险的命令提示用户确认，高风险的命令直接拦截，既控制风险，又不影响效率。

具体的实现步骤是：

命令解析：Agent在执行命令前，先对命令进行解析，识别命令的操作类型、参数、影响范围。比如，解析Shell命令ls -l，会识别出这是"查看目录文件"的操作，参数是-l，影响范围是当前目录，没有破坏性；解析rm -rf /home/user，会识别出这是"删除目录"的操作，参数是-rf，影响范围是/home/user目录，有破坏性；
风险分级：根据解析结果，将命令分成三个风险等级：
- 低风险：无破坏性、影响范围小的命令，比如ls、cat、pwd，这些命令只会读取信息，不会修改、删除内容，自动放行；
- 中风险：有一定破坏性、影响范围中等的命令，比如rm filename（删除单个文件）、mv filename newname（移动文件），这些命令会修改或删除内容，但影响范围有限，提示用户确认后再执行；
- 高风险：破坏性强、影响范围大的命令，比如rm -rf /（删除根目录）、sudo reboot（重启系统）、rm -rf *（删除当前目录所有文件），这些命令会造成严重损失，直接拦截，不允许执行，同时提示用户风险。
执行处理：根据风险等级，执行对应的操作，低风险自动执行，中风险确认后执行，高风险拦截。

Claude Code源码中，就包含了这样的风险分类逻辑，甚至对不同类型的命令，制定了详细的风险判断规则，比如对文件操作命令，根据操作的文件路径、操作类型，进一步细化风险等级，确保风险控制的准确性。

适用场景：Agent能执行Shell命令，或者会操作外部系统的场景。比如，AI编码助手需要执行构建、测试命令，AI运维助手需要操作服务器，都需要用到这个模式来控制风险。

权衡点：规则不可能覆盖所有情况。世界上的命令有无数种，而且不同的场景下，同一个命令的风险等级也可能不同，比如rm -rf test，如果test目录是空的，就是低风险；如果test目录里有重要的项目文件，就是中风险。所以，风险判断规则需要不断调整、优化，而且有时候会出现误判，要么放过风险操作，要么拦住本来安全的命令，需要结合实际场景不断打磨。

11. 单用途工具设计模式：工具专用，好理解、好控制

很多Agent框架，会让Agent直接使用通用Shell命令（比如cat、sed、grep）来完成文件操作、搜索等任务。这种方式虽然灵活，但问题也很多：命令不直观，比如sed -i 's/old/new/g' filename，很多用户和Agent都不容易理解；不好审查，很难判断Agent执行这个命令的真实目的；更难做权限控制，比如允许Agent执行grep命令，就无法阻止它用grep命令搜索敏感信息。

单用途工具设计模式，就是把常见的操作，拆成专门的工具，每个工具只做一件事，有明确的输入、输出和边界。这样不仅 Agent 和用户更容易理解，也更容易做权限控制，避免风险。

具体的做法是，将通用操作拆分成多个单用途工具，比如：

读文件工具：专门用于读取文件内容，输入是文件路径，输出是文件内容，只能读取，不能修改、删除；
写文件工具：专门用于修改文件内容，输入是文件路径、修改内容，输出是修改后的文件内容，只能修改指定文件，不能删除文件；
搜索工具：专门用于搜索项目内的代码、文档，输入是搜索关键词、搜索范围，输出是搜索结果，只能搜索，不能修改内容；
路径匹配工具：专门用于匹配文件路径，输入是路径规则，输出是符合规则的文件列表，只能查询，不能操作文件。

这些单用途工具，每个都有明确的功能边界，比如读文件工具只能读，不能写；写文件工具只能修改指定文件，不能删除。这样一来，权限控制就变得非常简单，比如只允许Agent读取文件，不允许修改，就只开放读文件工具，关闭其他工具即可。

同时，单用途工具的输入和输出都很规范，Agent更容易使用，不容易出错。比如，读文件工具只需要输入文件路径，就能返回文件内容，不需要Agent记住复杂的cat命令参数；写文件工具只需要输入文件路径和修改内容，就能完成修改，不需要Agent记住sed、echo等命令的用法。

适用场景：需要频繁做文件操作或搜索的Agent。比如，AI编码助手、AI文档助手，每天都需要大量读取、修改文件，搜索相关信息，用单用途工具能提高效率、降低风险。

权衡点：灵活性会受限。单用途工具只能完成固定的操作，不可能覆盖所有情况。比如，某个特殊的文件修改操作，单用途工具无法完成，就需要保留通用Shell命令作为兜底，在特殊情况下开放给Agent使用。所以，在设计单用途工具时，要覆盖大多数常见操作，同时保留通用工具作为兜底，平衡灵活性和安全性。

四、自动化：让Agent"不偷懒、不遗漏"，系统兜底更可靠

最后这一类模式，可以单独拿出来说，因为它贯穿了前面的记忆、工作流、工具三个部分。不管是记忆的整合、工作流的执行，还是工具的调用，本质上都有一个共同的问题：有些步骤是每次都必须执行的，但不能指望模型每次都记得。

比如，改完代码后必须执行格式化，执行命令前必须做风险校验，切换目录时必须重新加载配置。这些步骤如果只是写在提示词里，基本不可靠，模型会忘、会跳过，甚至在复杂上下文里"理解偏了"，导致步骤遗漏，出现问题。

确定性生命周期钩子模式，就是用系统层面的逻辑，代替模型的记忆，把这些"必须执行、不能遗漏"的步骤，挂到Agent生命周期的关键节点上，自动执行，完全不依赖提示词。简单来说，凡是"不能出错、不能漏"的事情，都不该交给模型记，而应该交给系统兜底。

12. 确定性生命周期钩子模式：系统兜底，不依赖模型记忆

Agent的生命周期，包含多个关键节点，比如会话开始、工具调用前、工具调用后、工作目录变化、会话结束等。确定性生命周期钩子模式，就是在这些关键节点上，挂对应的自动化动作，只要触发了节点，动作就会自动执行，不需要模型干预。

具体的实现方式，是定义多个生命周期钩子，每个钩子对应一个关键节点，以及一个需要自动执行的动作。常见的钩子和对应的动作有：

会话开始钩子：会话开启时，自动加载持久化指令文件、初始化分层记忆，确保Agent一开始就有规则可依、有记忆可用；
工具调用前钩子：Agent调用工具前，自动执行风险校验（比如检查命令的风险等级）、参数校验（比如检查文件路径是否存在），避免Agent调用错误的工具、执行错误的命令；
工具调用后钩子：Agent调用工具后，自动执行结果校验（比如检查代码修改是否正确、命令执行是否成功）、日志记录（记录工具调用的时间、参数、结果），方便后续回溯和问题排查；
工作目录变化钩子：Agent切换工作目录时，自动重新加载该目录对应的作用域规则，确保Agent使用的规则和当前目录匹配；
代码修改后钩子：Agent修改代码后，自动执行代码格式化（比如用Prettier格式化前端代码、用ESLint检查代码规范）、单元测试，确保修改后的代码符合规范、能正常运行；
会话结束钩子：会话结束时，自动执行记忆整合（去重、删旧、重组）、保存记忆到持久层，为下一次会话做准备。

举个例子：Agent修改完一个前端代码文件后，触发"代码修改后钩子"，系统会自动执行prettier --write filename命令，格式化代码，然后执行eslint filename命令，检查代码规范，如果有错误，自动提示Agent修改。这个过程不需要Agent记住"改完代码要格式化"，系统会自动完成，避免遗漏。

Claude Code源码中，就大量使用了这种生命周期钩子，比如代码修改后自动格式化、会话结束后自动整合记忆、工具调用前自动校验风险，这些自动化动作，保证了Agent的行为一致性和可靠性，也是它能成为生产级产品的重要原因。

适用场景：存在必须严格执行、不能遗漏的步骤的场景。比如，代码开发必须遵循规范、命令执行必须经过风险校验、记忆必须定期整合，这些步骤都可以通过生命周期钩子，自动执行。

权衡点：出了问题不太好排查。这些自动化动作是在对话之外运行的，Agent和用户都看不到执行过程，如果出现问题，比如代码格式化失败、记忆整合出错，很难快速定位问题所在。所以，需要做好日志记录，把每个钩子的执行过程、结果都记录下来，方便后续排查问题。

五、结语：这些模式，是Agent长期稳定运行的基石

看完这12个设计模式，你会发现，它们不是空谈的理论，而是从Claude Code这个生产级AI编码助手的源码中，提炼出来的架构智慧。这些模式，解决的都是Agent开发中最常见、最核心的痛点,记忆混乱、流程混乱、权限失控、步骤遗漏。

我们常说，Agent的核心是"智能"，但智能不仅仅是模型的能力，更是架构的设计。模型会迭代更新，今天用GPT-4，明天可能用更强大的模型；工具会不断升级，今天用Shell命令，明天可能用更高效的工具，但这些设计模式，不会很快过时。因为它们解决的是"Agent如何稳定、高效地完成任务"的本质问题，是Agent架构的基石。

这次Claude Code的泄露，给了我们一个难得的窗口，让我们能窥见顶级AI编码助手的内部架构。这样的窗口可能不会一直存在，但这些从真实场景中打磨出来的经验，会一直沉淀下来，成为每一个Agent开发者的宝贵财富。

如果你正在做Agent应用，不管是AI编码助手、AI运维助手，还是其他类型的Agent，都值得认真研究这些模式。它们不是"锦上添花"的优化，而是决定你的系统能不能长期稳定运行、能不能真正落地使用的基础。

当然，这些模式也不是一成不变的，你可以根据自己的实际场景，灵活调整、组合使用。比如，小项目可以用"持久化指令文件模式"+"单用途工具设计模式"，简单高效；大项目可以用"作用域上下文组装模式"+"上下文隔离子智能体模式"+"确定性生命周期钩子模式"，保证稳定和安全。