一套 Harness 打天下不够：按任务路由专用执行壳

很多团队默认只有一份全局 Harness：同一套提示词、同一套工具、同一套循环，跑完所有任务。异构任务一多，这份「通用壳」就会两边不讨好——简单任务被过重流程拖慢，复杂任务又缺专门策略。

10 月有一篇 OO-Harness 的工作把这个问题说得很直白：Agent Harness 是可执行代码，规定提示词、工具和控制流；单一全局 harness 很难同时伺候差异很大的任务。它的做法是用面向对象思路演化出一组专用 harness 子类，测试时再用 router 按任务选型。

一、全局壳的真实失败模式

全局 Harness 常见三种病：

第一，策略平均化。为了覆盖最难任务，常开规则越加越长，简单任务也被同一套重流程 拖累。

第二，工具面过大。所有任务共享全量工具，既抬高 preamble 成本，也放大误调用面。

第三，失败经验无法沉淀到「哪类任务该换壳」。线上只看到「偶发不行」，看不到「这类任务本就不该用这套循环」。

二、专用壳解决的是策略异构

OO-Harness 的关键不是再造一个框架名词，而是承认：不同任务需要不同执行策略。

训练或迭代期，根据执行记录演化出专用 harness——可以继承基类，只覆盖差异部分：更严的权限、更短的循环、不同的验收、不同的子 Agent 组合。

测试期，router 依据路由经验为每个任务选一个具体壳。这样改的是「哪套策略上场」，而不是每次都把特例塞进全局 prompt。

三、路由层必须可解释

没有解释的 router，最后会变成黑盒调参。更稳的要求是：

• 路由特征可读：任务类型、是否需要写文件、是否长程、是否高风险副作用
• 选择结果可审计：这次用了哪个 harness、为什么
• 失败可回流：某类任务连续失败时，是换壳，而不是只加重试

路由经验本身也应沉淀。否则每次都在重新猜测。

四、和「一切皆插件」怎么配合

插件化解决的是组件可替换；专用壳解决的是策略可组合。

更稳的落地是：权限、审计、验收仍是 mandatory 不变量；各专用 harness 只替换循环策略、工具白名单、压缩与委托配置。router 不能关掉验收，只能选择「用哪套可验证的执行路径」。

五、最小落地路径

1. 先按业务切出 2 到 3 类任务：只读调研、受控改写、高风险变更
2. 为每类准备一份差异化配置，而不是一份巨无 AGENTS.md
3. 入口增加显式路由：规则先于模型，模型只做不确定时的建议
4. 记录「任务类 → 所选壳 → 成败与成本」，每周回看是否该拆出新壳

一开始不必上复杂演化算法。先把「不同任务用不同壳」变成团队习惯，收益通常就很明显。

结语

一套 Harness 打天下，适合 demo；生产里任务异构才是常态。把专用执行壳和可审计路由做起来，优化对象才会从「再写长一点的全局提示词」变成「给对的任务选对的壳」。