很多团队讨论 Agentic Coding 时，第一反应还是"哪个模型最强"。这个问题当然重要，但放到真实工程里，它不是最先决定成败的变量。真正难的是：怎样让模型不只会给建议，而是能在受控环境里读现场、改代码、过评审、走发布，并且在关键节点把决定权交还给人。
我的判断很简单：Agentic Coding 不是把一个聊天窗口升级成"万能工程师"，而是把一组能力不同、失败模式不同的模型，编排成一条可验证的执行链路。模型负责判断和执行，workflow 负责顺序和门禁，人负责风险决策。三者少一个，系统都会变形。
Model Routing：不要把所有任务塞给同一个模型
单模型路线最省心，也最容易遇到天花板。一个模型从需求拆解、实现、评审、发布一路做到底，看似上下文完整，问题也很明显：它会把自己的假设带到每一步。前面看漏的约束，后面往往不会自己补回来。
多模型协作的价值不在"热闹"，而在于故意制造认知差。负责执行的模型刚写完补丁，很容易停在"代码已经按意图运行"的局部视角；换一个模型只看 diff、日志和验收条件，反而更容易发现闭环之外的回路。这里的关键不是模型名，而是 execution 和 review 必须拆开 。
图：多模型协作的价值，在于把执行、评审和风险判断放到不同视角里
比较稳的分工方式，是把模型能力按风险和任务长度分层：
| 环节 | 更适合的模型能力 | 主要判断 |
|---|---|---|
| 任务拆解与 Plan | 长上下文、强推理、能处理不确定性 | 任务边界、依赖顺序、风险点 |
| 高危执行 | 稳定工具调用、谨慎确认、能读懂系统反馈 | 是否可触达生产、是否需要人工确认 |
| 代码实现 | 快速补丁、局部上下文理解 | 是否按接口和测试约束完成 |
| 独立评审 | 对 diff 敏感、能反查隐含假设 | 是否有漏测、竞态、回滚缺口 |
| 总控收口 | 能合并多方结论 | 是否进入下一步 |
长任务上尤其别省主力模型。短任务目标清楚，轻量模型往往够用；但链路一长，需求理解、边界条件、错误恢复会层层累积。便宜模型省下的成本，最后经常变成返工、补测和人工救火。成本当然要算，但应该按环节算，而不是简单地把所有步骤都交给最低成本的模型。
Cross-Model Review：用模型差异打掉同源盲区
自审最大的问题不是态度，而是惯性。一个模型刚完成实现，它对自己的方案天然有上下文偏爱，容易验证"自己想做的事有没有做成"，不容易追问"系统会不会从别的路径把结果抵消掉"。
跨模型评审要看的不是格式，也不是挑语法。它应该盯住四类问题：状态是否真的改变，外部系统会不会重建被清理的状态，失败后能不能回滚，观测指标能不能证明动作有效。评审模型和执行模型不同源，盲区就不完全重叠。
我更愿意把这件事看成工程上的 N 版本检查，而不是"多叫几个 Agent 投票"。投票解决不了复杂 bug，差异化视角才有用。一个模型负责写，另一个模型负责怀疑；怀疑必须有输入材料，包括 diff、测试结果、运行日志、发布边界和"不允许发生什么"。
图：从需求约束、执行验证，到异源评审和人工确认的闭环
这张图里，最容易被忽略的是"只读验证"。模型不能只相信命令返回的第一屏输出。真实系统里，查询入口会抖、缓存会延迟、指标维度会缺失。让 Agent 接触现场之前，先要求它用只读命令重复确认，并把结论绑定到可定位的维度上，这比多写几句 prompt 有用得多。
Agent Harness：CLI、权限和反馈回路才是手脚
模型本身没有手。它能做多少事，取决于你给了它哪些工具、权限和反馈回路。Agentic Coding 的工程化重点，不是把 prompt 写得更像指令书，而是把执行环境做成模型可以安全操作的 harness。
最可靠的入口通常是已有 CLI 和 API。发布、打包、服务查询、变更单、日志检索、指标读取，这些能力本来就在工程体系里，只是过去由人手动串起来。把这些入口暴露给 Agent，等于让它站在现有操作系统上工作，而不是让它绕过系统另造一套流程。
权限边界要早设计。凭证只在本地执行环境和既有鉴权链路里流转，不进入对话和工单；写操作必须有显式确认；生产动作要绑定窗口和变更单；能只读就先只读，能 dry-run 就不直接写。模型越能干，越不能靠"它应该懂"来保证安全。
有些场景没有 CLI，只能走网页控制台。这里也要分层：能用 DOM 或浏览器协议，就不要上屏幕级操作；能定位元素，就不要靠坐标点击；必须兜底时，也要让 Agent 每一步截图或读 DOM 状态，不要让它凭记忆连续点下去。
图：CLI、API、鉴权与只读验证共同构成 Agent 的行动外壳
Workflow Kernel：判断交给模型，顺序写死
我见过不少失败的 Agent 流程，问题不在模型回答错，而在流程太自由。模型很擅长判断"下一步可能是什么"，但生产系统不应该让"可能"直接变成动作。
更稳的做法是把 workflow 拆成两层。需要理解和权衡的部分交给模型，比如风险在哪里、测试该补什么、diff 是否合理；必须按顺序发生的部分写成固定流程，比如先开变更单，再执行动作，再做回归，再验证指标，最后签字。模型可以解释为什么暂缓，但不能跳过门禁。
一个可复用的执行内核大致长这样：
- 读取需求和约束，明确不可做事项。
- 拆成可独立验证的小任务，每个任务有退出条件。
- 实现前先写计划，计划通过后再改代码或执行命令。
- 每个 diff 独立评审，评审模型不能和执行模型相同。
- 写操作前检查确认门禁，高风险动作必须等人工确认。
- 发布后用只读数据复核，不只看"命令成功"。
- 把跑通过的流程沉淀成 skill，下次不要重新摸索。
这里的 skill 不是"提示词收藏夹"。它应该记录入口、命令、权限、失败处理、确认点和验收方式。第一次探索会慢，第二次还慢就说明没有沉淀。Agent 团队的复利，来自把一次性的试错变成可重复的执行协议。
Control Plane：多 Agent 必须有主控
多 Agent 协作最怕每个都很积极。一个 Agent 正在实现，另一个 Agent 抢先改了方向，第三个 Agent 根据过期上下文下结论，最后主流程被跑快的人带偏。速度不是问题，失去主控才是问题。
主控 Agent 的职责不是亲自做所有事，而是派活、收口和裁决。子 Agent 只处理被分配的范围，返回证据和结论，不擅自扩大任务。所有写操作归一个执行者认领，避免并行写冲突。所有进入下一阶段的决定，由主控汇总后再交给人工或固定 workflow。
可以把这套结构理解成一个很小的控制面：
| 控制点 | 约束 |
|---|---|
| 任务所有权 | 每条写路径只有一个 owner |
| 上下文所有权 | 主控维护当前状态，子 Agent 不改全局判断 |
| 证据格式 | 结果必须带命令、diff、日志或验证口径 |
| 风险升级 | 遇到权限、生产、删除、发布，立即回到人工确认 |
| 失败处理 | 不靠猜测修复，先复现、定位、再改 |
这套控制面会牺牲一点速度，但换来可追责和可恢复。Agentic Coding 真正进入生产后，最重要的不是"跑得像不像人"，而是出问题时能不能知道它做过什么、为什么做、做到哪一步。
Cost Loop：Token 要花在能放大正确率的地方
多模型协作会把成本问题摆到台面上。我的看法是，token 成本不该被当成一个总账来粗暴压缩，而应该进入调度策略。长链路、强推理、高风险动作、跨模型评审，值得花；目标明确的小补丁、格式整理、局部替换，可以交给便宜模型。
成本可视化也很重要。没有用量看板时，团队很容易凭感觉省 token，最后省在不该省的地方。真正该看的不是"今天花了多少"，而是哪些环节用量高、哪些模型在返工、哪些任务因为模型能力不足导致人工介入增加。
一旦用量被看见，调度就能动态调整。某个模型当前不稳定，就退出关键路径；某个模型适合快速实现，就让它吃局部任务；最强模型留给拆解、长任务和风险判断。模型选型不应该写死在流程里，角色和能力才应该写死。
图：Token 成本应该进入调度策略，而不是被当成一个总账粗暴压缩
Theory Backfill：实践先跑，理论再校准
这套方法和 LLM 理论并不冲突，只是顺序经常反过来。很多团队还没系统读完推理优化、测试时计算、后训练和 Agent 架构，就已经在工作流里用上了类似思想：给难步骤多一次推理，让不同模型互相校验，用外部工具形成反馈闭环。
这更像 harness engineering，而不是 prompt engineering。prompt 解决的是一次回答怎么更好；harness 解决的是模型如何接触真实环境、如何拿到反馈、如何被门禁约束、如何在失败后回到安全状态。前者重要，但后者决定它能不能做正经事。
AI 提效也不是模型一上线就自然发生。电力早就出现过类似故事：发电机装进旧厂房时，生产率不一定立刻提升；只有当产线围绕电力重新设计，收益才显出来。Agent 也是这样。只把模型塞进原来的流程，最多省几段文字；围绕模型重写执行链路，才可能改变吞吐。
Minimum Path：从一条只读链路开始
如果要复制这套做法，别从"大而全平台"开始。先选一个能驱动 CLI 的终端 Agent，让它完成一条只读链路：查服务状态、读日志、拉指标、给出判断，并要求它重复验证关键结论。
第二步再加入一个低风险写操作，前面加确认门禁，后面加只读复核。写操作不一定复杂，重要的是把"模型提出动作、系统要求确认、执行后验证结果"这条回路跑通。
第三步引入跨模型评审。让一个模型实现，另一个模型只看 diff 和验收条件。不要让评审变成礼貌性总结，要让它明确回答：状态是否真的改变、边界条件有没有漏、失败后怎么回滚、监控能不能证明动作有效。
最后，把这条流程写成 skill。入口、权限、命令、检查点、失败处理、禁止事项，都写进去。之后再扩展到多任务、多模型和更复杂的发布链路。Agentic Coding 的门槛不在"会不会用模型"，而在能不能把一次成功变成下一次的默认能力。
结语
Agentic Coding 的核心不是让模型看起来像一名更聪明的工程师，而是给它一套可以工作的工程系统。模型分工解决能力差异，跨模型评审解决同源盲区，CLI 和权限提供手脚，workflow 和人工卡点提供边界。
这件事做成以后，团队得到的不是一个会聊天的助手，而是一条能被复用、能被审计、能逐步放大的执行闭环。它不会替代工程纪律，恰恰相反，它会逼着工程纪律变得更明确。