编程代理的质量下降，往往不是因为模型的能力变弱，而是因为项目缺少明确的运行系统，来规范代理读取什么、执行什么，以及如何审查其变更。随着工作持续数周并累积数千次修改，如果不强制要求这些步骤，代理可能会反复发现相同文件、与先前的决定相矛盾、猜测测试命令，或停止编写测试。
在《在生产环境中运行 LLM 系统》系列的第六部分中，Stack Overflow Blog 建议围绕模型构建一层组织架构，包括简明的项目章程、自主权限边界、多层级上下文、持久记忆、审查委员会，以及每次修改后运行的钩子。当多个代理在同一代码仓库上运行时，还应加入文件所有权图、提示词日志和共享决策记录。
问题在于运行带，而不只是模型本身
文章将代理定义为：模型加上指令、工具、上下文策略、钩子、隔离机制、子代理和监控机制。文章引用了 Terminal-Bench 2.0 基准的一项普遍性结果：LangChain 仅通过改变运行带，就将一个代理从前 30 名之外提升到前 5 名，得分从 52.8% 提升至 66.5%，增加了 13.7 个百分点，而模型本身保持不变。
实际意义在于，不完整的工具、模糊的规则或拥挤的上下文，可能是最容易解决的失败原因。与模型不同，开发团队可以调整这一层，并使其适配自己的代码仓库。
一个受约束的单代理的六个要素
- 项目章程：使用 CLAUDE.md 或 AGENTS.md 之类的文件规定工作流程：规划、记录、实施、测试、审查，然后提交。文件还应包含质量标准和供应商软件包的使用边界，并且应保持简短，因为每次会话都会读取它。
- 自主权限边界：允许代理执行可逆操作，例如读取、编辑、测试和创建提交；而推送、部署和应用基础设施变更则需要批准。还必须核验命令匹配的语义，以免 npm:* 之类的宽泛规则意外允许部署。
- 多层级上下文：根目录的 CONTEXT.md 包含项目结构图及其运行和测试方式，而每个模块的文件则说明该模块的职责、文件和依赖关系。DECISIONS.md 记录决策、决策原因以及被拒绝的替代方案。过时的上下文属于错误，应在同一次变更中修复。
- 持久记忆：文章建议为每条事实分别建立记忆文件，配备简明索引，并使用 graph.jsonl 文件，通过“依赖于”或“替代”等关系连接模块与决策。
- 多视角审查委员会：由子代理从产品、工程、基础设施、安全和测试等角度审查变更。只有高置信度的阻碍或严重问题才会阻止变更。
- 修改后钩子：PostToolUse 会在每次 Edit、Write 或 MultiEdit 后运行，并输出一份清单，提醒在同一次变更中更新上下文、记忆和决策记录，而不是悄无声息地重写文件。
运行代理集群时
当多个代理在同一代码仓库上工作时，会出现新的问题：修改相同文件，或撤销其他代理的决定。文章不建议依赖代理之间的直接对话，而是依赖可审计的书面共享状态，包括路径所有权图、CLAIM 和 RELEASE 记录、进度日志，以及每项任务的独立分支，并由人工进行合并。
这些声明并不是真正的锁；两个代理可能同时读取相同状态，并在同一时间声明同一路径。当需要真正隔离时，文章建议采用原子机制，例如使用唯一名称的 Git 分支，或在协调存储中进行条件写入。
为什么这种方法很重要？
这里真正的变化，是将重点从代理编写函数的能力，转移到周围系统能否让代理长期保持有方向性并可供审查。决策记录不仅具有记录作用，还具有契约作用：不修改旧决策，而是添加新的决策来替代它们，并说明原因和被拒绝的替代方案。这样，设计历史始终可见，并且可以与自动化检查关联起来，例如禁止特定导入。
这种方法仍然是组织性指导，而不是对输出正确性的保证。文章还承认，当冲突同时发生时，基于文件的声明只是建议性的；在合并、推送和部署环节，人工审查仍然是控制点。文章的结论是：限制模型并构建可审计的痕迹，可能比等待更智能的模型，对长期工作的可靠性产生更大的影响。