上个月我们团队换了一次 agent loop。从 Claude Code 切到 OpenCode。
切换本身很轻——prompt 改改，工作流调调，两天上手。切完第三天，周一早上打开 dashboard，CI 全绿。我松了口气，泡了杯咖啡，随手点开一条 PR 的 review 记录。
空的。
再点开一条。还是空的。咖啡没喝完就放下了。
不是代码质量出了问题。是 pipeline 里有一条规则：检测注释里的 // Generated by Claude Code 标记，命中就触发额外的 AI 代码 review 流程。OpenCode 不打这个标记。于是这条规则永远不触发，review 流程形同虚设。CI 是绿的，但绿得没有意义。
一条规则，把整个团队锁死在一个工具上。不是我们选择了 Claude Code，是基础设施绑架了我们。
我在 代码是 AI 写的了，品味住在哪里 里说，品味从代码搬到了工程系统——CI pipeline、release 节奏、事故响应。但那篇文章用的词是「harness」，而且只讨论了 harness 和 agent loop 的关系。
三个月后我意识到，那个框架已经不够用了。
2026 年的前沿 Agent 系统，不再是「一个模型 + 一个循环」的结构。它是 Foundation Model、Agent Policy、Runtime 三层的协同设计。品味不住在任何一层里，它住在三层之间的契约里。
一、先看清今天的 Agent 长什么样
很多人对 Coding Agent 的心智模型还停留在 2024 年：
Prompt → Model → Answer
# generated by hugo AI
一次推理，一次生成，人肉验收。
但今天前沿的 Coding Agent——Claude Code、Codex、OpenCode、Devin——早已不是这个结构。它们是持续闭环：
Goal
↓
Plan（拆解任务、选择策略）
↓
Read（读代码、读文档、读测试输出）
↓
Edit（修改代码）
↓
Run（跑测试、跑 lint、跑构建）
↓
Observe（看结果、看 diff、看 log）
↓
Reflect（判断：对不对？够不够？要不要换方向？）
↓
Repeat（或者 Stop）
# generated by hugo AI
真正的软件开发能力来自这个闭环的转速和质量，而不是任何一次推理的精度。
这意味着「agent loop」这个词已经不够精确了。Loop 只是 Runtime 的一个组成部分。一个完整的 Agent Runtime 至少包括：
| 组件 | 职责 |
|---|---|
| Loop / Scheduler | 驱动 Plan→Edit→Run→Observe 的迭代 |
| Memory | 跨轮次、跨会话的状态保持 |
| Tool Registry | 管理可用工具、参数校验、失败处理 |
| Sandbox | 隔离执行环境，限制副作用半径 |
| Checkpoint / Recovery | 崩溃恢复、断点续跑 |
| Permission | 什么能做、什么要人确认 |
| Context Management | 上下文窗口优化、渐进式披露 |
| Parallel Execution | 多任务并发、子 Agent 编排 |
Loop 是心跳。但心脏不等于身体。
二、三层架构：Model、Policy、Runtime
2026 年，理解 Agent 系统需要一个三层模型：
┌─────────────────────────────────┐
│ Foundation Model │
│ 知识、推理、语言理解、代码生成 │
├─────────────────────────────────┤
│ Agent Policy │
│ 什么时候规划、搜索、调用工具、 │
│ 验证、反思、停止 │
├─────────────────────────────────┤
│ Runtime │
│ Memory / Tool / Sandbox / │
│ Checkpoint / Permission / │
│ Context / Scheduler │
├─────────────────────────────────┤
│ Environment │
│ 代码仓库 / CI / 浏览器 / │
│ 终端 / 文件系统 / 人 │
└─────────────────────────────────┘
# generated by hugo AI
Foundation Model 决定知识和推理能力——它知道什么是好的代码，能理解需求，能生成实现。
Agent Policy 决定行为策略——什么时候该规划而不是直接动手，什么时候该搜索而不是凭记忆，什么时候该验证而不是继续推进，什么时候该停下来问人。
Runtime 提供执行基础设施——状态管理、工具调用、权限控制、崩溃恢复、上下文优化。
Environment 是真实的软件工程环境——代码仓库、CI 系统、浏览器、终端、以及最终的人类审查者。
关键洞察： 未来 Agent 的竞争越来越来自 Policy，而不仅仅来自模型参数。
同一个 Foundation Model，配上不同的 Policy，行为完全不同：
- 一个 Policy 让 Agent 更主动——先搜索再动手，先跑测试再提交
- 另一个 Policy 让 Agent 更保守——每步都确认，不确定就停
- 第三个 Policy 让 Agent 更喜欢批量修改——一次改十个文件，统一验证
- 第四个 Policy 让 Agent 更喜欢增量迭代——改一个文件跑一次测试
这些不是模型能力的差异，是 策略选择的差异。
三、模型已经越来越 Agent Native
2024 年，模型是「被驱动的」。Harness 替模型思考：什么时候该搜索、什么时候该验证、什么时候该停。模型只负责在每一步生成文本。
2026 年，这个关系正在反转。
新一代 Foundation Model 已经内化了大量 Agent 能力：
- 长轨迹推理——不是单步问答，是跨几十步的连贯推理
- Tool Calling——原生理解工具调用的时机和参数
- 多轮规划——先拆任务，再逐步执行，中间能调整计划
- 自我验证——生成后主动检查，发现问题主动修
- Retry + Reflection——失败了不是简单重试，是分析原因后换策略
这意味着 Runtime 的职责正在发生根本变化：
2024: Runtime 替模型思考
「模型不会验证，所以我替它加一步验证」
「模型不会规划，所以我替它拆任务」
2026: Runtime 放大模型能力
「模型已经会验证，我提供验证的基础设施」
「模型已经会规划，我提供规划所需的上下文」
# generated by hugo AI
从「替模型思考」到「放大模型能力」——这是 Runtime 设计哲学的分水岭。
如果你的 Runtime 还在替模型做决策（硬编码「第三步必须跑测试」），你实际上是在限制一个已经会自己判断的模型。好的 Runtime 应该提供能力（「这是测试工具，你可以随时调用」），而不是规定流程（「你必须在第三步调用」）。
四、生成侧和验收侧
回到开头那个故事。现在可以更精确地描述问题了。
生成侧是三层协同。 Foundation Model 提供推理能力，Agent Policy 决定行为策略，Runtime 提供执行基础设施。三者共同把意图变成代码。
验收侧是独立的质量系统。 lint、type check、test suite、release gate、postmortem 模板——它们定义「什么算合格」，不关心代码是怎么生成的。
生成侧（可换、可演化） 验收侧（稳定）
───────────────────── ─────────────
Foundation Model（可换） lint rules
Agent Policy（可调） type check
Runtime（可升级） test suite
人（极端情况） release gate
postmortem 模板
# generated by hugo AI
这两侧的关系是 契约关系：不管你用什么模型、什么策略、什么 Runtime 配置，出来的东西必须过同一套关。
类比：造纸厂定义纸的规格——克重、白度、吸墨性。它不关心你用什么笔写。钢笔、圆珠笔、毛笔，写上去不洇不透就是合格。如果一种纸只能配一种笔，那不是纸好，是纸窄。
五、挑模型的验收系统长什么样
反面比正面更有教学意义。三种常见的耦合：
一、检查来源，不检查质量。
「我们加了一条规则，检测 AI 生成的注释风格。如果是 AI 写的，触发额外 review。」
这条规则的隐含假设是：AI 写的代码比人写的更需要审查。但 2026 年的现实是：模型已经会自我验证。真正需要审查的不是「AI 写的」，是「质量不够的」。一段人写的烂代码和一段 AI 写的烂代码，对系统的伤害是一样的。你按来源分流，等于放过了人写的烂代码，同时给 AI 写的合格代码加了不必要的摩擦。
正确做法：检查质量标准本身。覆盖率低于阈值就拦，不管谁写的。
二、把验收标准塞进 Agent Policy。
「我们的 prompt template 里规定了代码风格，所以 CI 里不再检查格式。」
这条比第一条危险得多——因为它看起来是绿的。你把验收标准从验收侧挪到了生成侧的 Policy 配置里。Policy 是生成侧的策略——换一个模型、调一次策略、升一次 Runtime，验收标准就无声无息地蒸发了。CI 还是绿的，但绿是因为没有人在检查。
正确做法：验收标准永远在验收侧。Policy 里可以写风格偏好（提高一次通过率），但 CI 里必须有独立的格式检查（兜底）。
三、测试适配 Runtime 的输出结构。
「这个集成测试只在 Claude Code 生成的代码上跑，因为 Cursor 生成的目录结构不一样，测试路径对不上。」
这是最隐蔽的耦合。你的测试在适配生成侧的输出特征，而不是验证系统行为。模型一换、Policy 一调、Runtime 一升级，测试就废。或者更糟——测试还在跑，但测的不是你以为的东西。
正确做法：测试验证行为，不验证结构。「调用这个 API 返回 200」是行为测试。「src/controllers/user.ts 文件存在」是结构测试。前者不挑工具，后者挑。
六、不挑模型的验收系统怎么搭
正面说。四条原则：
一、检查质量标准，不检查生成来源。
lint 规则不关心代码是人写的还是 AI 写的。type check 不关心类型标注是手打的还是模型补的。测试不关心实现是 Copilot 补全的还是你手敲的。
如果你的验收系统里有任何一条规则需要知道「这段代码是怎么来的」才能决定怎么检查，把它改成「这段代码是否满足质量标准」。
二、验收标准独立于生成配置。
Policy 里写的规则是 建议——提高一次通过率，减少返工。CI 里写的规则是 法律——不管你怎么生成的，过不了就不能合。
两者可以重叠（Policy 里说「用 4 空格缩进」，CI 也检查缩进），但不能只有前者没有后者。建议可以换，法律不能换。
三、测试验证行为，不验证结构。
✅ 行为测试（不挑模型）：
POST /api/orders → 201, body 包含 order_id
输入非法金额 → 400, error message 包含 "amount"
❌ 结构测试（挑模型）：
src/services/order_service.py 存在
类名是 OrderService
方法签名是 def create_order(self, data: dict)
# generated by hugo AI
结构是生成侧的选择。不同模型、不同 Policy、不同 Runtime 配置会给出不同的结构——有的拆三个文件，有的合一个文件，有的用 class，有的用函数。只要行为对，结构不该是验收标准。
四、验收系统的演进由事故驱动，不由工具驱动。
在 代码是 AI 写的了，品味住在哪里 里我说过：有品味的工程师，每次事故都让工程系统变厚一层。
这里补一条：变厚的方向应该是「堵住质量漏洞」，不是「适配新工具」。
✅ 事故驱动（稳定）：
上次因为没检查空指针，线上崩了 → 加 null check lint rule
上次因为没跑集成测试，API 契约破了 → 加 contract test
❌ 工具驱动（脆弱）：
换了 Claude Code，它生成的代码喜欢用 any → 加 no-any 规则
换了 Cursor，它爱生成 utils.ts → 加文件数量检查
# generated by hugo AI
第一种规则，不管用什么模型都有效。第二种规则，模型一换就过时。
七、Runtime 与模型的共同演化
到这里，文章的核心论点已经清楚了：验收侧不应该耦合生成侧。
但 2026 年还有一个更深的趋势，不讨论就不完整： Runtime 和 Foundation Model 正在共同演化（co-evolution）。
什么意思？
不同 Runtime 会让同一个 Foundation Model 呈现完全不同的行为。同一个 Claude Sonnet，在 Claude Code 的 Runtime 里更激进（大范围重构、批量修改），在 Cursor 的 Runtime 里更保守（小步修改、频繁确认），在一个自研 Runtime 里可能更像一个初级工程师（严格遵循 checklist）。
这不是模型变了，是 Runtime 的 Policy、上下文管理、工具编排 改变了模型的行为表达。
更深的趋势：Runtime 的执行反馈正在回流到模型训练。
Runtime 执行
↓
产生信号：Test Results / Logs / Git Diff / Human Feedback
↓
信号回流到模型训练（RLHF / RLAIF / Online Learning）
↓
模型行为改变
↓
Runtime 策略调整
↓
（循环）
# generated by hugo AI
这意味着：
- Model Team 和 Runtime Team 不会永远独立。 当 Runtime 的执行数据成为模型训练的核心输入，两个团队必须协同设计。
- Runtime 不只是「包装模型」。 它在塑造模型。一个提供丰富测试反馈的 Runtime，会让模型越来越擅长写可测试的代码。一个只有 lint 反馈的 Runtime，会让模型越来越擅长过 lint 但不擅长写正确的逻辑。
- Agent 的竞争不只是模型参数的竞争。 是 Model × Policy × Runtime 整个系统的竞争。
这对验收侧意味着什么？
验收侧的价值更大了，不是更小了。 当生成侧三层在共同演化、快速迭代时，验收侧是唯一稳定的锚点。模型会换，Policy 会调，Runtime 会升级——但「API 契约不能破」「覆盖率不能低于 80%」「安全漏洞不能进主干」这些质量底线不会变。
生成侧越动态，验收侧越重要。
八、和信任架构的同构
写到这里我发现，这个设计原则不是新发明——它和 Agent 时代的权限：从 RBAC 到五层信任架构 是同构的。
五层信任架构里，Agent Proxy 不关心 Agent 内部怎么推理。它只校验：你是谁（身份）、你能做什么（权限）、你替谁做（委托）、你怎么证明（凭证）。Agent 的推理过程是黑盒，Proxy 不介入。
验收系统对生成侧的关系一模一样：
| 信任架构 | 验收系统 |
|---|---|
| Agent Proxy 不关心 Agent 怎么推理 | 验收系统不关心代码怎么生成 |
| 校验身份、权限、凭证 | 校验质量、行为、契约 |
| Agent 被劫持了，Proxy 兜住 | 生成侧输出垃圾了，验收侧拦住 |
| 凭证不进入 Agent 运行环境 | 验收标准不进入生成配置 |
两侧解耦的核心收益是：任何一侧出问题，另一侧兜得住。
Agent 被 prompt injection 劫持了，Proxy 的短期凭证机制限制损害半径。生成侧三层协同出了 bug——模型幻觉、Policy 误判、Runtime 状态丢失——验收侧的质量门禁拦住它进入主干。你不需要信任生成侧，因为验收侧是独立的。
反过来，如果两侧耦合了——验收标准写在 Policy 里、测试适配 Runtime 的输出结构、检查规则按模型来源分流——那生成侧一出问题，验收侧同时失效。两道防线变成一道，而且是你看不见的那道。
九、一个思想实验
假设明天所有 Foundation Model 都退回到 2024 年的水平。没有长轨迹推理，没有原生 Tool Calling，没有自我验证。
你的验收系统还能用吗？
如果答案是「能」——lint 还在跑，测试还在过，release 节奏不变，postmortem 模板不变——说明你的验收系统是模型无关的。它检查的是工程质量，不是模型能力。
如果答案是「不能」——有些规则失效了，有些测试跑不了了，有些流程断了——说明你的验收系统里混入了模型适配逻辑。那些逻辑在模型能力变化的瞬间就变成了死代码。
这个思想实验的价值不在于「模型真的会退步」——当然不会。它是一块试金石：帮你把验收系统里的每一条规则分成两堆——质量底线 （永远需要）和 生成侧适配 （模型换了就该删）。如果你的验收系统经不起这个实验，说明第二堆混进了第一堆。
最后
回到开头那次工具切换。
那条检测 // Generated by Claude Code 的规则，我当天就删了。换成了一条不挑模型的规则：所有新增代码必须有对应的测试覆盖，覆盖率低于 80% 的 PR 不能合。不管代码是 Claude Code 写的、OpenCode 写的、还是实习生手敲的，标准一样。
切换工具的成本从「改 CI + 改测试 + 改流程」变成了「改 Policy 配置」。两天搞定。
但这次经历让我想明白了一件更大的事：
2026 年，Frontier AI 不再是单一模型的竞争，而是 Foundation Model、Agent Policy 与 Runtime 的协同设计。 模型在变，Policy 在调，Runtime 在升级——三者共同演化，越来越难分开。
在这个快速演化的生成侧面前，验收侧是唯一不动的锚。
Agent loop 是笔，Runtime 是纸的规格。好的纸不挑笔。而 2026 年的笔，正在自己学会写字。
去翻一遍你的 CI pipeline。有没有一条规则，只有当前模型在的时候才成立？有没有一条测试，只有当前 Runtime 的输出结构下才能跑？如果有，它们不是质量底线，是生成侧依赖。趁还没换模型，把它们改成不挑模型的版本。
换模型那天你会发现，最贵的成本不是学新工具，是拆旧耦合。
你在团队里换过 AI 编码工具吗？验收系统跟着改了多少？欢迎留言讨论。