我花了几个月构建一个与模型无关的框架，让编码 Agent 能真正完成软件工程工作。结果发现，功能的重要性远低于我的预期。真正起作用的，是一套改变了我对“与 Agent 协同构建”这一认知的核心理念，而不仅仅是给它们写提示词。
以下就是分量最重的那些理念。前三个真正重塑了我的思维模式，其余则是几乎可以立刻上手的实用技巧。
1. 在 Agent 开始工作前，先冻结验收标准
并且把它放在 Agent 无法修改的地方。
这对我来说可能是最大的转变。事后看来似乎显而易见，但直到亲眼见证它发挥作用，我才真正理解其重要性。
如果验收标准在工作完成后还能修改，它们就会慢慢向实际产出的结果倾斜。Agent 并非有意欺骗，只是它会根据一个仍可移动的目标来评判自己的工作。如果目标是可以移动的，那它最终就会移动。
这不是提示词的问题，而是结构性问题，所以解决方案也必须是结构性的。
先写验收标准。把它们放在可编辑的工作区之外，并自动阻止任何修改它们的尝试。现在，Agent 是在为一个无法重新谈判的契约而工作。任务完成与否，不是由 Agent 说了算，而是由它是否满足最初的契约来决定。
2. 没有人应该给自己的作业打分
写出代码的模型，是判断它是否正确的最差人选。当它完成工作时，它已经说服自己解决方案是合理的。
所以，把职责分开。
让确定性脚本验证所有机械性内容。脚本不会编造一个成功的退出码。把编码模型当作工程师，而不是评审者。然后，把结果交给一个全新上下文的评审者——一个从未目睹代码编写过程的人——来评判设计、意图和整体质量。
这种简单的分离，比我预想中能发现更多问题，而且做起来成本低得惊人。
3. 强制执行很容易，校准才是难点
这个认识改变了我对整个框架的思考。
大多数 Agent 系统，包括我早期的版本，都几乎以相同的方式对待每个任务。一行字的拼写修复和重大的架构重构走的是同一套流程。这样要么是浪费时间，要么风险太大。
关键在于投入要与任务匹配。
首先对工作进行分类。这是一个什么都不依赖的小改动，还是其他一切都依赖的核心基础设施？是业务逻辑还是通用工具代码？
然后让分类决定它需要多少审查、由哪个模型处理、以及允许多少自主权。
实施强制执行很容易。但让投入与任务匹配，才是价值真正开始累积的地方。
实用层面
一旦那些更大的理念落地，一些较小的实践几乎立刻带来了回报。
- 把你的规则放在框架里，而不是放在提示词里。 一个提示词说“不要在主仓库中编辑”只是建议。同样的规则，如果以阻止工具调用的方式强制执行，就变得无法忽视。重要的规则不应该依赖模型选择去遵守。
- 把状态保留在对话之外，每个任务使用全新的工作进程。 在外部存储任务记录，使用隔离的工作树，并通过合并队列处理变更。一旦状态存在于对话之外，上下文限制就不再是你最大的瓶颈。任务可以并行、可恢复，也更容易推理。
- 跨提供商评审优于同提供商评审。 模型对自己工作的容忍度通常高于对别人工作的容忍度。使用不同提供商的模型，是减少这种偏差的简单有效方法。
为什么这些原则有效
这些理念都不依赖于某个特定模型。它们关乎的是框架工程：协议、验证、评审流程以及职责分离。
基准测试排名第一的模型会不断变化。
但这些原则很可能不会。
持久的价值不在于模型本身，也不在于功能特性，而在于你围绕它们构建的脚手架。
