你发这篇文章，我读完的感受是：这不是在比较工具，而是在重新定义"智能"和"工程"的边界。
文章的核心结论——中等模型+硬性Hook ≈ 最强模型——表面上是说"Harness 可以补智能"，但我读到的深层意思是：很多我们以为是"智能"的问题，其实是"纪律"的问题。
让我展开说。
第一，"智能不够，工程来凑"的适用范围
这个结论有个隐藏前提：任务是工程交付型，不是探索型。写一段能编译通过的CRUD接口、跑通的测试套件、符合lint规范的代码——这些任务的"对"和"错"有明确判定标准。Hook 就是把这些标准自动化，让模型每一步都面对一个"是/否"的硬约束。
但如果是设计一个新的架构模式、选择一个技术栈、权衡性能和可维护性——这些任务的"对"没有客观标准，Hook 帮不上忙。这时候 Opus 的深层推理优势不可替代。
所以Harness 的补偿边界很明确：有明确验收标准的任务，Harness 能把60分模型拉到85分；没有明确标准的任务，模型本身的智能决定天花板。
第二，Agent Team 的 Token 冗余为什么是不可避免的
你说 5-10 倍冗余，我算了算账。Claude Code Agent Team 的架构是每个 teammate 独立实例，各自维护完整上下文。这意味着：
- 5 个 teammate = 5 个完整上下文窗口 = 至少 5 倍 token
- 加上 Mailbox 通信、Task List 同步、Plan 模式的多轮对话 = 7-10 倍
论文里 Anthropic 用 16 个 Opus 写 C 编译器，花了 $20,000。这个钱烧的值不值？值，因为这是"能不能做到"的问题，不是"花多少钱"的问题。但对日常开发，这个成本结构是不可持续的。
我观点更激进：Agent Team 的 peer-to-peer 通信是一个设计失误。
人类团队协作的本质不是"每个人都知道一切"，而是"每个人只知道自己的部分，通过接口契约协作"。Agent Team 的 Mailbox 让每个 agent 能看到其他 agent 的思考和中间结果，这反而制造了信息过载。真正高效的协作模式应该是：
- 一个 Orchestrator（Opus 级别）负责任务分解和契约定义
- 多个 Worker（Sonnet 或更便宜模型）负责独立执行
- Worker 之间不直接通信，只通过 Orchestrator 协调
- 契约（API 接口、数据格式）是唯一的通信协议
第三，Harness 的未来方向
文章提到 Harness 正在成为跨工具的通用语言，我认同这个判断。但有个更深的变化正在发生：Harness 正在从"人的配置"变成"Agent 的自我配置"。
AutoAgent 已经展示了自动化 Harness 工程循环：给定任务和基准，系统自动迭代优化系统提示、工具配置、代理编排。在 24 小时运行中达到 SpreadsheetBench 榜首（96.5%）和 TerminalBench GPT-5 最优成绩（55.1%）。
这意味着什么？意味着未来的 Harness 不是人写的，是 Agent 自己工程化出来的。人只写高层指令（program.md），Agent 负责把 Harness 实现。
这跟软件开发的历史惊人相似：早期程序员写汇编，后来编译器自动生成，再后来框架和脚手架自动化配置。Harness 正在走同一条路——从手工调校到自动生成。
最后说一句关于文章本身：你把"马具比马重要"这个比喻用得准确。但有个更精确的版本：Harness 不是比马重要，Harness 是让马能被骑的条件。没有 Harness，最强模型只能在实验室里跑；有了 Harness，中等模型就能进生产环境。
生产环境才是真正的考场。