很多团队讨论Agentic Coding时第一反应还是“哪个模型最强”。这个问题当然重要但放到真实工程里它不是最先决定成败的变量。真正难的是怎样让模型不只会给建议而是能在受控环境里读现场、改代码、过评审、走发布并且在关键节点把决定权交还给人。我的判断很简单Agentic Coding 不是把一个聊天窗口升级成“万能工程师”而是把一组能力不同、失败模式不同的模型编排成一条可验证的执行链路。​模型负责判断和执行workflow 负责顺序和门禁人负责风险决策。​三者少一个系统都会变形。Model Routing不要把所有任务塞给同一个模型单模型路线最省心也最容易遇到天花板。一个模型从需求拆解、实现、评审、发布一路做到底看似上下文完整问题也很明显它会把自己的假设带到每一步。前面看漏的约束后面往往不会自己补回来。多模型协作的价值不在“热闹”而在于故意制造认知差。负责执行的模型刚写完补丁很容易停在“代码已经按意图运行”的局部视角换一个模型只看 diff、日志和验收条件反而更容易发现闭环之外的回路。这里的关键不是模型名而是 ​execution 和 review 必须拆开​。图多模型协作的价值在于把执行、评审和风险判断放到不同视角里比较稳的分工方式是把模型能力按风险和任务长度分层环节更适合的模型能力主要判断任务拆解与 Plan长上下文、强推理、能处理不确定性任务边界、依赖顺序、风险点高危执行稳定工具调用、谨慎确认、能读懂系统反馈是否可触达生产、是否需要人工确认代码实现快速补丁、局部上下文理解是否按接口和测试约束完成独立评审对 diff 敏感、能反查隐含假设是否有漏测、竞态、回滚缺口总控收口能合并多方结论是否进入下一步长任务上尤其别省主力模型。短任务目标清楚轻量模型往往够用但链路一长需求理解、边界条件、错误恢复会层层累积。便宜模型省下的成本最后经常变成返工、补测和人工救火。成本当然要算但应该按环节算而不是简单地把所有步骤都交给最低成本的模型。Cross-Model Review用模型差异打掉同源盲区自审最大的问题不是态度而是惯性。一个模型刚完成实现它对自己的方案天然有上下文偏爱容易验证“自己想做的事有没有做成”不容易追问“系统会不会从别的路径把结果抵消掉”。跨模型评审要看的不是格式也不是挑语法。它应该盯住四类问题状态是否真的改变外部系统会不会重建被清理的状态失败后能不能回滚观测指标能不能证明动作有效。评审模型和执行模型不同源盲区就不完全重叠。我更愿意把这件事看成工程上的 N 版本检查而不是“多叫几个 Agent 投票”。投票解决不了复杂 bug差异化视角才有用。一个模型负责写另一个模型负责怀疑怀疑必须有输入材料包括 diff、测试结果、运行日志、发布边界和“不允许发生什么”。图从需求约束、执行验证到异源评审和人工确认的闭环这张图里最容易被忽略的是“只读验证”。模型不能只相信命令返回的第一屏输出。真实系统里查询入口会抖、缓存会延迟、指标维度会缺失。让 Agent 接触现场之前先要求它用只读命令重复确认并把结论绑定到可定位的维度上这比多写几句 prompt 有用得多。Agent HarnessCLI、权限和反馈回路才是手脚模型本身没有手。它能做多少事取决于你给了它哪些工具、权限和反馈回路。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 LoopToken 要花在能放大正确率的地方多模型协作会把成本问题摆到台面上。我的看法是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 和人工卡点提供边界。这件事做成以后团队得到的不是一个会聊天的助手而是一条能被复用、能被审计、能逐步放大的执行闭环。它不会替代工程纪律恰恰相反它会逼着工程纪律变得更明确。