Agent 活里最值钱的技能：同时跑多个 harness
大家好，我是珂抖屁。
很多人以为 Agent 时代的进阶，是把一个壳用到极致：开满 subagents、挂齐 MCP、skills 写到发烧。听起来很专业。我自己也走过这条路——然后发现瓶颈换了位置：单壳再强，也还是一个偏见源。
Machina（@EXM7777）把话说得很冲：现在 Agent 工作里最重要的技能，是同时跑多个 harness；一个 harness 加上它自己的 subagents 不够。他举的基本例子很具体——从 Claude Code 把计划丢给 Codex 和 GPT-6 Astra 做审查；从 Codex 一侧，写作类活交给 Fable……重点不是安利哪几个名字，是别让同一套上下文既写判决书又当法官。
为什么「一个壳 + 子代理」仍不够
子代理解决的是并行与分工，不解决同源偏见。
同一 harness 里孵出来的子会话，通常共享：
•同一套系统提示与工具哲学；
•同一类「什么叫完成」的默认；
•同一条权限与日志习惯。
于是你看到的「多 Agent」，常常是一个剧组换马甲。写计划的声音、执行的声音、复查的声音，口音太像，错也会像。
一人公司没有第二个工程师盯着。你需要的不是更多标签页，是至少一条会唱反调的产线——最好来自另一套壳、另一家模型默认、另一份工具面。
多 harness 不是清单，是路由纪律
三条路由：审查 / 写作隔离 / 便宜后台
别做成工具 listicle。我自己用的是路由，而不是收藏夹。
路由 A：计划 ↔ 异壳审查 Claude Code（或你的规划壳）写出步骤与边界后，把同一份计划扔进 Codex / Astra 一类执行气质更硬的通道，只问三句：哪步不可测？哪步权限过大？哪步在偷换验收标准？审查通道不允许「帮忙把计划写得更感人」，只允许找茬。
路由 B：实现 ↔ 异模型写作/说明 代码在 Codex 一类壳里落地时，对外说明、changelog、用户向文案，可以交给更擅长长文气质的模型路线（公开讨论里常点名 Fable 一类）。不是因为「写作模型更神圣」，是因为实现上下文会污染对外语气——工程师会话里的妥协，不该原样流进用户文档。
路由 C：便宜后台 ≠ 主路径 批量扫仓、跑回归、整理日志，可以丢给更便宜的模型与更薄的壳；主路径的架构决策与合并权，仍留在你指定的高压组合。多 harness 的意义也包括：别让贵模型干搬运。
三条路由的共同点：每条都有入口角色、出口角色、禁止事项。没有禁止事项的「多开」，只是多付一份订阅。
一人公司最小可行：两壳三闸
两壳三闸：异壳审查 · 权限 · 人审
你不需要五套全家桶。最小集合我建议：
•规划/编排壳（强说理、肯追问边界）；
•执行壳（少废话、改文件跑测试干脆）；
•可选第三路：专门复查或专门写对外文字。
三道闸钉在合并前：
•异壳审查闸：合并前至少一次非同源复查；
•权限闸：远程/合盖长跑环境默认最小权限；
•人审闸：对外发布、删数据、动密钥，仍是人按。
缺人审闸的多 harness，只是加速翻车。
真正难的技能，不在安装，在编排
同时跑多个 harness，难的是这几件事：
•任务切片：什么必须串行，什么可以并行；
•上下文投喂：审查通道该看到什么、不该看到什么（有时刻意不让它见原计划，只见 diff 与验收）；
•归因：哪次变好是模型，哪次只是多付了协调税；
•失败回收：异壳否决时，结论写回笔记库，而不是留在某个聊天气泡里蒸发。
会装两个 CLI，不叫技能。会让两个 CLI 互相拆台又不互相污染，才叫技能。
判断钉死
我的现场结论很明确：
单 harness 极致化，上限是「很强的一位同事」；多 harness 编排，才接近「最小团队」。 一人公司买不到第二个自己，但可以买到第二条偏见不同的产线。
别再问「我该忠于哪个壳」。问：这一步该谁写，该谁拆，该谁否决——以及否决权能不能落在同源会话里。
同源子代理再多，也只是同一张嘴的回声。异壳同时跑，才是现在 Agent 活里最值钱的那一下。
（信号备注：主张对齐 @EXM7777 公开帖「同时跑多个 harness / 单壳+subagents 不够」及计划→Codex/Astra 审查、写作→Fable 等示例；本文展开为一人公司路由纪律，不把示例写成必须跟买的清单。）