为何像Claude Code这样的编程智能体需要治理机制，而非更优的提示词。
提示词决定单次交互的结果，而非整个工作流程。规则、限定上下文、权限限制以及完成度验证等治理机制如何让Claude Code具备可靠性。
来源: Your AI Agent Needs a Governance Layer, Not Another Prompt
更明确的提示确实能获得更好的回复。它们能减少误解，让指令更加清晰，为单次交互指明方向，短时间内会让人感觉自己与人工智能的协作方式得到了提升。但一旦这些智能体成为日常工作的一部分，这种感觉就会消失。你不再要求针对单个请求得到一个令人信服的回复，而是期望智能体了解项目情况，尊重已做出的决策，选择正确的流程，在权限范围内行事，使用合适的工具，并留下可供核查的依据。
提示仅能塑造你面前的交互过程，却无法掌控该交互之外的所有事物。
Codex和Claude Code已经提供了许多实用的功能。所欠缺的是一个完整且可移植的系统，用以决定适用哪些规则、哪些上下文重要、编码智能体能做什么、工作如何分配以及什么算作证据。必须有人在运行时环境之上构建这样的层。这种层有一个名称叫内核：它是一个由你掌控的治理层，负责将人类的意图转化为具体的证据。内核内部没有模型，也不会自行执行任何操作。
具体而言，这样的内核可以最初以一组可移植的、结构化的Markdown文件形式存在：包括规则、协议、索引、已确定的决策、项目状态以及内存管理策略。当书面指令不够用时，技能、脚本、快捷方式以及钩子功能就能填补空白。
上下文只是表面现象
第一个明显的问题是上下文缺失。新的会话通常不了解系统架构、最近的变更以及某项任务背后的原因，因此必须再次进行审计才能继续开展有意义的工作。这种重复操作会耗费时间、资源以及人们的耐心。
更多的上下文固然有帮助，但依然无法解决更深层次的问题。智能体仍可能遵循错误的流程，越权行事，引入无关信息，或在没有证据的情况下宣称任务已完成。
显而易见的解决办法是将缺失的规则和背景信息放入 AGENTS.md、CLAUDE.md 或类似的引导文件中。这虽然合理，但并不全面。这些文件确实有助于提升新用户的上手体验，但期望它们能管理整个工作流程则是错误的。引导文件可以规定稳定的规则并指向可靠的来源，却无法独自保持项目状态的最新性、为每项任务选择合适的上下文、决定智能体可执行的操作或检查最终结果。
有一条原则至关重要：在执行之前先明确“完成”的标准，然后在执行结束后要求提供相关证据。
消除重复从来都不是最终目标。人工智能已从偶尔的实验转变为日常必需，有趣的问题在于：用常规的软件设计方法构建的环境究竟能带来多大的价值。人工智能通过多种途径进入我们的工作流程，比如各种编辑器、Xcode与VS Code，以及Codex和Claude Code这样的工具。这些工具虽然让调用强大模型变得更加容易，但更便捷的访问方式并不能改善模型调用过程中的整体秩序。
在状态良好的情况下，智能体可以检查代码、解释陌生的框架、提出架构设计或协助发布新功能，这很像与另一名开发者协作。你越依赖这种方式，周边相关问题就越重要。当两个信息源存在分歧时，以哪个为准？这项任务适用哪些规则？是由智能体做出决定还是仅提供建议？如果它表示工作已完成，你应该期待看到什么结果？
上下文能够回答前一部分问题，因为它能为智能体提供相关知识。其余部分则涉及如何运用这些知识。所谓治理，其实就是对这一整套机制的恰当表述——即意图、可信知识、规则、权威、执行与验证之间的实际关联。只要工作流程中的各个环节足够明确，便于检查、修正和重复使用，它就始终具有实用性。
对于那些喜欢设计各组件能够高效协作的系统的工程师来说，让围绕智能体的工作流程靠即兴方式处理似乎是一种浪费。这应该被视为一项需要设计的内容，而非只需简单监督的一系列对话。要做好这一点，就需要长期观察自己的习惯：在开始处理项目前会检查什么、会重复使用哪些模式、何时会放慢节奏，以及哪些检查能真正让你确信任务已完成。其目标是将这些隐性习惯转化为智能体可以遵循、人类可以审核的行为。
Bootstrap 能做什么与不能做什么
加入已有项目的开发者需要的不仅仅是才华，他们还必须了解代码的组织结构、已做出的决策、近期有哪些变化以及各部分的边界所在。如果没有这些了解，即便是最优秀的新人也需要花费数天时间来重新熟悉环境。
智能体会遇到该问题的简化版本。你需要解释系统的架构、目标、当前状态以及限制条件，智能体能够完成不错的任务，但下次会话时却需要重新构建大部分相关内容。
将相关内容放入 AGENTS.md 或 CLAUDE.md 文件中，能大幅降低入门成本。“bootstrap”一词仅用于划分界限，并非负面表述：一份优秀的文档会明确最低操作规范，并告知智能体可靠信息的存放位置。Codex会对 AGENTS.md 文件进行分层管理，控制其总大小；而 Claude Code则会提供简短的项目说明，那些极少用到的流程会被单独提取为技能。这些内容均在供应商的文档中有详细说明：Claude Code的记忆功能相关文档以及Codex的AGENTS.md指南。技能用于封装可重复执行的流程，以便在不同项目间复用，而钩子则可以确保每次都触发特定行为。即便如此，仍需有其他机制来决定何时适用这些功能，以及如何检查其输出结果。
当人们期望一个文件就能涵盖整个工作空间时，问题就出现了。这样的文件既无法保持简洁，又必须包含所有的架构决策、当前计划、过往报告、规范以及任务细节。即便上下文窗口能够容纳所有内容，将所有信息都塞进每次会话中也会导致问题：重要的指令会与过时或无关的文本相互干扰。修复漏洞需要不同的上下文，而审查架构则另需不同方式；产品发布与早期产品会议也有不同流程，一个简单的问题不应让大型功能的协调工作白费精力。
因此，引导工具应仅为进入系统提供路径，而不应试图成为整个系统。
从引导工具到地图
在这种设计中，引导框架会保存一份简短的运行契约，随后在相关内容出现时指向不同的来源。已被采纳的决策会保留在项目中。协议用于描述重复出现的工作类型，技能则包含可重复执行的流程，快捷方式可简化频繁出现的请求，而当前计划则用于保存下一次会话可能需要的状态信息。
内核内部并没有任何智能机制。它的价值在于如何在不同会话和运行时之间对文件进行分离、关联、选择和维护。
这种分离也有助于保持信息的清晰性。已被采纳的决策决定了项目的发展方式，状态报告描述某一特定时刻的情况，测试结果则用于记录证据。如果将这三者混同存储在同一个无差别的内存中，过去的观察结果就可能会被误认为是当前的指令。
随着该框架的不断完善，它逐渐涵盖了内存管理策略、任务复杂度、所需思考力度及应使用的模型、快捷方式、会话间的连贯性，以及多个智能体之间的验证与协调机制。若列出所有细节反而会掩盖其架构本质。重要的是，智能体能够根据工作需求逐步发现这些要素。在这套框架背后有四项核心职责，它们虽无法解释所有机制，但能说明为何这些机制会组合在一起。
有些知识需要超越单次对话而存在
在任务进行过程中可以进行聊天，但它不应作为项目决策的正式记录。已被采纳的架构设计、约束条件及编码选择应保存在受管控的文档中，以便后续会议查阅，而正在执行的计划则需要具备可恢复的状态。保持持久不变的真相并不等同于存档所有对话，因为其中大部分只是临时性的辅助内容。应当思考的是，在会议结束后哪些内容仍应被视为权威依据。
加载任务所需的内容
一个智能体只需具备完成任务所需的足够信息，而非系统存储的所有内容。一个小的代码修改可能只需要项目规则和几份文件；而一个复杂的功能则可能需要了解产品目标、架构决策、专家意见以及验证计划。关键在于提供最少的必要上下文，而非尽可能多的信息。持续性意味着能够在恰当的时刻找到合适的资料，而非将全部历史记录都带入每项任务中。
找到某样东西并不等同于拥有使用权限
找到某个文件、消息或推荐内容并不意味着就有权限对其采取行动。系统必须将信息与权限分开，尤其是对于那些具有破坏性的操作、最终确认、发布以及任何涉及工作区之外的内容而言。这一层比模型智能更不为人所见，但每当因贸然决策而造成的损失超过稍作停顿作出判断所带来的代价时，它就显得至关重要。
完成操作需要证据
流利并不等同于正确，合理也并不意味着工作已完成。因此，内核会要求明确需要验证的内容、应保留的证据以及将确认状态记录在何处。如果某个智能体编辑了代码并报告“已完成”，那只不过是收到了一条声明而已。验证可能意味着测试通过、构建成功、运行中的应用程序表现出预期行为以及状态已被记录。其他领域则需要不同的证明方式，但原则是一样的：对话结束并不意味着工作已经结束。
以组织作为类比
想象这样一家公司：它拥有办公大楼、计算机以及先进的设备，但却没有统一的协作方式。虽然具备相应能力，却缺乏整体性。人们仍然需要通用知识、标准流程、决策权、明确的职责以及质量管控机制。这种类比并不完全准确，因为代理并非员工，而运行环境的作用也远不止是让人们坐在办公桌前。但它确实展示了各组成部分之间的关联：代理承担特定的角色，工具则是各种设备，而运行环境则是任务执行的地方。核心层则是由规则、知识、方法及检查机制构成的共享层，正是它让这些组件能够协同工作。更完善的模型并不必然意味着系统就会更好。
该层的位置
内核并不与 Codex、Claude Code、Gemini 或未来出现的其他运行时竞争。后者提供完整的运行环境：模型、工具、会话、推理设置，以及日益丰富的子智能体、钩子函数和技能。治理层在該环境中发挥作用，确定三件事：哪些内容需要保留、智能体被允许执行什么操作，以及何种证据可视为任务已完成。
每当运行时系统推出与手工实现功能类似的新特性时，这种分离模式的价值就会提升。若要重新构建每一个运行时功能，就会占用本可用于服务相关项目的宝贵时间。让运行时负责执行任务，同时保持治理层具有可移植性，才是更可持续的方案。不同提供商在模型、工具、接口及输出风格上存在差异，而可移植性能让你的规则独立于任何特定提供商，无需假装这些差异已消失。
治理无法确保确定性
仅仅把规则写下来，并不能保证智能体会读取它、理解它，或在恰当时机应用它。引导文件即便指明了正确的协议，也可能会被忽略。某个标准决策虽然被完美保存，但其内容却可能悄然过时。某个钩子功能可能在规则早已失去作用后，仍会继续忠实执行该规则。
经验表明这种情况会很快出现。为工作树和钩子添加的规则开始相互重叠、冲突，进而阻碍它们本应保护的任务，因此必须对这些规则进行简化与修正。治理机制需要持续维护，而成本远不止于此：接口和索引的运行会消耗时间和资源，还可能无法反映最新状态；随着系统规模扩大，智能体可能会跳过某些指令；而在工作流声称成功却缺乏预期证据时，信任也很难重建。
这样的系统永远不可能做到完美或通用。它只是一个需要经过数月测试、修正的个性化设置。虽然它能提升你监控和调整智能体行为的能力，但没有任何规则、协议、快捷方式或记忆机制能够被完美遵循。治理机制或许能让行为更易于检查和修正，但却无法让概率性的智能体变得确定性强。
首先应问的三个问题
语境丢失正是让人们走上这条道路的根源。而让他们继续走下去的，则是一个更重大的工程学问题：如何设计一个能够处理复杂任务的模型架构，同时给予其他重要架构同等的重视？
那么，你能证明工作已经完成吗？只有当在开始执行之前就明确了“完成”的标准，并且结果呈现出符合该任务要求的证据时才行。否则，你所拥有的只是主张，而主张并非证明。
无需这样的系统就能开始这种思考方式。在添加新的提示或文件之前，先问自己：
- 哪些来源有资格定义什么是真实的？
- 哪些决策和行动需要人工授权？
- 什么证据能表明工作已经完成？
这些问题将独立的 AI 功能转化为可靠工作流程的组成部分，而非仅仅共存的功能。并非每个小请求都应拖垮整个系统。控制措施应与后果相匹配：风险较低时采取宽松措施，一旦出错会造成严重损失时则需更严格的管控。模型提供功能，而从意图到成果的规范流程则是围绕这些模型构建的。
相关阅读
- 为何编程智能体的内存只需存储差异信息及存储方法：智能体内存应仅记录模型无法预测的内容。每条记录需经过四项测试，存储时需满足三项要求，以及为何 git 中的 markdown 非常合适。