选完模型还不够：AI 编程开始进入 Harness 路由时代

最近看 GitHub Trending 和开发者社区，有个变化挺明显。

大家还在比较模型，也还在聊 Claude Code、Codex、OpenCode、Pi。可聊天的重点慢慢挪了。有人会把同一模型放进两个命令行 Agent 里跑，再回来看它读了什么文件，调了几次工具，测试卡在哪儿，最后留下多大一块 diff。模型的名字没换，干出来的活却差得很远。

这不是工具控才会在意的细节。一个 Agent 只拿到局部目录、默认只能读、失败两次就停，和另一个能扫完整仓库、带着宽泛 shell 权限、能不断重试的 Agent，做出来的东西很可能不一样。前者的动作小，出错时也好收拾。后者更适合摸索复杂问题，不过它跑偏以后，留下来的东西也更多。

本文的线索来自 GitHub Trending，以及 Reddit 和 X 上的讨论。这些来源能说明开发者最近在关心什么，不能替任何模型或 Agent 做排名。社区帖里的跑分尤其要谨慎看。任务集、提示词、重试规则和验收方式往往没有交代完整，拿它直接做采购判断并不稳。

团队已经开始给任务分模型之后，还要补一个问题。模型选好了，它该在怎样的运行环境里做事。

模型决定谁来判断，Harness 规定它怎么做事

模型路由并不复杂。整理日志、补文档、按既有规则改配置，通常可以交给成本较低的执行模型。跨模块重构、根因分析、涉及权限或数据的改动，则需要能力更强的模型，必要时由人接手。前文《DeepSeek V4-Flash 正式版之后，AI 编程该按任务分层，而不是按模型站队》谈的是这件事。

模型负责推理，Agent Harness（智能体运行时）负责安排它手里的材料和动作。运行时决定它从仓库里看到哪些文件，能运行什么命令，改动放在当前目录还是独立 worktree（工作树），测试失败后还能试几次，做完以后留下哪些证据。

拿一次代码修复来说，模型会根据上下文提出修改。可它看到的是最近一次报错，还是连同项目规范、Git 历史和相邻模块一起看到，差别很大。它能运行测试，却不能直接部署，和它拿到一把什么都能干的 shell，也不是一回事。遇到失败后，它停下来交出现场，还是继续猜三十轮，同样由运行时规则影响。

模型路由选的是判断能力。Harness 路由选的是工作条件。两层都要有，任务才不会因为一次模型选择而变成一场不受控的尝试。

OpenAI Codex 官方仓库中的命令行界面示意

图片来源为 OpenAI Codex GitHub 仓库。该图展示 Codex CLI 的官方界面素材，不用于证明本文中的运行时比较结论。

同一个模型会干出两种活

假设要修复一个结算页问题。窄屏下，优惠券输入框被遮住了。

一种常见做法是给 Agent 完整仓库的读写权限。它自己搜索、改代码、构建、打开浏览器，一直试到页面看着正常。这样跑得顺时很省事。问题在于，它也可能顺手改到无关组件，更新锁文件，构建失败后不断换方向，最后让 review 面对一个很难拆开的大 diff。

另一种做法会把工作切得更细。任务只允许访问结算页相关目录。Agent 先读代码，把可能涉及的组件和样式列出来。修改在独立 worktree 中完成，能执行的命令限定为指定单测、类型检查和预览构建。两次失败后，它必须提交当前 diff、报错和自己的假设，等人决定下一步。需要看页面时，只进 staging 环境，只用测试账号。

两边可以用同一个模型，甚至给出近似的提示词。结果仍会不同，因为模型没有脱离环境单独工作。

同一个模型进入不同 Harness 后，上下文、工具权限、工作树与测试验证路径都会变化

前一种方式适合先摸清仓库、需要较大探索空间的任务。后一种方式适合目标明确、希望把改动半径压住的修复。选择取决于任务，不取决于某个产品名听起来够不够先进。

社区里那些“某模型换了 CLI 就变强了”或“换了工具反而变慢了”的说法，也该放在这里理解。上下文装配、工具描述、默认权限、超时、重试、子 Agent 编排和验证命令，都混进了最后结果。单看模型名字，解释不了这些差异。

更有用的问题是，某个模型在什么任务里，配上什么运行时和验收条件，能以可接受的代价完成工作。

先按任务分通道

小团队用不着先做一套庞大的 Agent 平台。把任务后果和验证条件分开，已经能少走不少弯路。

任务类型	模型能力层	运行时需要给什么	交付时看什么	何时停下或升级
只读探索（找代码、归类日志、梳理文档）	默认执行层	只读文件与检索工具，限定仓库范围，不给网络和写入权限	文件引用、搜索结果、结构化摘要	关键信息缺失，或结论彼此冲突时，请人补充上下文
局部且可回滚的修复	默认或中等能力层	独立 worktree，限定目录，指定测试命令，限制重试次数	diff、单测、类型检查、lint	同一方向连续失败两次，或改动越出范围
跨模块改造	高能力层加审查	先写计划，按阶段提交，隔离子任务，记录依赖假设	设计说明、分阶段 diff、集成测试、人工 review	影响面持续变大，测试覆盖不足，或架构约束冲突
生产、权限、数据和对外操作	高能力层加人工确认	最小权限，dry run（试运行），审批节点，禁止自动执行不可逆动作	审批记录、审计日志、目标环境和资源 ID	写生产、发消息、改权限、删除或付款前都暂停

表里的“模型能力层”没有绑定具体型号。型号会更新，项目里的任务风险、可回滚程度、外部验证是否充分，却不会随着榜单变化。任务能不能交给下一个人接着处理，也该在开始前想好。

只读探索被配置成全仓库可写，风险就已经被放大了。跨模块重构被塞进只能改单个文件、又没有集成测试的轻量通道，模型再强也会被错误的限制卡住。运行时的职责，就是把这些条件提前摆到台面上。

选运行时，先看四个地方

Claude Code、Codex、OpenCode 这些名字有各自的使用习惯。真要给任务做分流，先看下面四件事会更落地。

它从哪里拿上下文

“理解仓库”这四个字听着一样，实际做法可能差很多。

有的运行时会广泛搜索后自己挑文件，也有的主要依赖用户指定目录和任务说明。历史会话、项目规则和 Git diff 是否一并带入，则是另一项会显著影响结果的配置。上下文太少，Agent 只能猜。材料太杂，它又会把已经过期或无关的规则当成当前约束。

任务记录里最好留两项内容。本次允许访问的范围，以及它实际读过的关键文件。第二项不花哨，却能帮 review 的人理解它为何这样判断。任务失败时，也能分清模型推理出了问题，还是它根本没看到那条关键约束。

它能碰哪些工具

一个只需要读代码、跑测试的任务，默认没有理由带着生产凭证、部署权限和宽泛网络访问。工具越多，模型要处理的说明越多，误选工具时的后果也越难控制。

MCP 路线图那篇文章已经写过工具目录膨胀的问题。对 Coding Agent 也是同样的道理。读文件、写文件、执行测试、联网、访问浏览器、调用内部系统，可以按任务逐项打开，不必每次全给。

这样配置有个直接好处。Agent 能做什么不再只是产品宣传页上的能力，而是一次任务里明确写下的权限。出了问题，也能回头查是哪一项权限放得太宽。

它失败后会不会停

Agent 第一次猜错不算稀奇。麻烦常出在它已经猜错，还顺着同一方向继续改。

重试次数、重试前要检查什么、什么信号会触发停止，都应该写进运行时规则。测试失败后，先分清是环境基线有问题、测试本身不稳定，还是改动引起了失败。相同类型的失败连着出现两次，就留下日志和 diff，换更强的模型继续查，或者请人介入。

无限重试会拉长上下文，也会扩大改动范围。有限重试能把失败保留成一个别人看得懂、接得住的现场。

它如何证明做完了

Agent 写一句“已完成”没有多少成本。交付要靠外部证据。

局部代码修复可以看单测、类型检查和 diff。跨模块改造需要集成测试和 review。浏览器任务还要留下页面状态、测试账号和环境标识。涉及外部系统时，审批、回执和审计记录都不能少。

运行速度只是一个维度。一个运行时早十分钟结束任务，却没有留下命令记录和验证结果，后面排查或 review 时，省下来的时间很容易又花回去。

从任务账本开始

很多人一听 Harness 路由，就会想到仪表盘、模型网关、任务队列、tracing（追踪）和大规模 benchmark（基准评测）。规模上来后，这些东西确实有用。刚起步时，先给每次 Agent 任务留一本小账就够了。

记录项	需要记下什么
任务边界	改什么，不改什么，是否允许联网或访问外部系统
模型与 Harness	哪个模型跑在哪个运行时，工具和权限如何配置
上下文	读过哪些关键文件、规则或历史记录
执行过程	调了什么工具，重试几次，在哪一步开始偏离
结果与验证	产生哪些 diff，哪些测试或审查通过
人工接手	失败后，下一位处理者需要看哪些日志和现场

这张账不需要拿来衡量员工，也不必算出一个精确的 ROI。它能把两类浪费区分开。

有些团队把旗舰模型放在大量确定性小任务上，结果和脚本或默认执行层相比没有明显变化。还有一些团队为了省调用费，让低成本模型在复杂任务里来回试错。API 账单看着不高，工程师随后却要清理无关 diff、补测试、恢复环境。

记录一段时间以后，团队会更容易看清问题出在模型、任务描述、测试条件，还是运行时规则。路由规则也才有机会跟着真实任务慢慢调整。

任务账本将范围、运行时设置、执行记录、测试证据和人工接手信息保留在同一任务中

小团队要有主路，也要能接手

同时维护五套 Agent 运行时，对多数小团队没有必要。工具多了，学习成本、凭证管理和任务交接也会跟着增加。

更实际的办法是选一条主路。它应该是团队熟悉的，能跑通日常任务，日志和验证方式也清楚。再留一条受控的替代路径，用来应对上下文限制、成本压力、长任务不稳定或特定工具兼容问题。

能否接手，取决于切换时有没有把现场留下来。任务说明、已读文件、运行命令、失败日志和当前 diff，应该跟着任务走，不该困在某个会话里。换模型或换 Harness 后，接手的人拿到的是能继续处理的工程现场，不是一句“刚才那个 Agent 没做出来”。

高后果操作的接手者往往就是人。发布、权限变更、删除、付款和对外发送，即便运行时支持自动执行，也应保留最后一次确认。模型可以准备方案，运行时可以限制动作范围，后果仍需要有人判断。

这两层分开以后，选择会更清楚

模型能力依然重要。复杂设计、模糊需求和异常排查，需要更好的推理能力。Harness 也无法把本来不可靠的模型变成可靠系统。

可当多家模型都能读仓库、调用工具、跑测试，任务结果已经不只取决于模型本身。上下文怎样准备，工具怎么收窄，失败时如何停下，证据如何保存，都会影响一项工作能不能被团队接住。

模型路由让团队把不同难度的判断交给合适的模型。Harness 路由让这些模型在合适的工作条件里行动，有对应的权限、反馈和验收方式。日常任务不必全用最贵模型，任何模型也不该默认进入高权限、难以复查的执行环境。

这样安排以后，AI 编程工具之间的比较才会回到具体任务上。团队也能把好用的经验留下来，而不是每隔几个月跟着新模型重新站队。

扩展阅读

参考来源

以上项目和文章用于观察 Agent 运行时的产品与工程趋势。Reddit 等社区讨论只反映用户关注点。帖中提到的模型能力、速度和成本，本文没有当成独立验证后的结论。