Harness 半年保质期：AI Agent 架构反思

"每六个月，删掉你的 CLAUDE.md、删掉你的 skills、删掉你的 hooks。"这是 Claude Code 之父 Boris Cherny 在 YC 7 月 28 日访谈《We Cut 80% of Claude Code's Prompt》中给所有 AI 产品建设者下的一道激进口令。它的潜台词比字面更重：在大模型以月为单位跃迁的今天，Agent 产品的 harness（脚手架、约束、提示工程）已经不能像传统软件那样按年规划——它有保质期，而且保质期只有半年。这条反思值得每个认真做 Agent 的人重新审视自己的架构。

一、Harness 是什么？为什么它在"过期"？

在 LLM Agent 的语境里，harness 指一切包裹在模型外面的东西：system prompt、工具描述、权限策略、skills 模板、hooks 回调、guardrails、安全检查、上下文压缩策略、子 Agent 编排逻辑……Boris 自己的原话是："今天 Claude Code harness 里的代码，几乎只剩下安全、权限和静态分析的部分。"

之所以要大面积瘦身，是因为新一代模型对 harness 的依赖在快速下降。Anthropic 在 7 月 24 日发布 Claude 5 上下文工程新规，针对 Opus 5、Fable 5 等新模型，把 Claude Code 的 system prompt 砍掉了 80% 以上——不是因为追求极简，而是因为模型"已经不需要了"。

Boris 给出的迭代心法只有一条：不要去猜模型需要什么指令，因为你根本猜不对。能做的，是一行一行地删除、测试、找出模型反复卡住的地方。这意味着 harness 不是"设计"出来的，而是"消融"出来的。

二、消融实验：把 Agent 架构当实验对象

Boris 在访谈中反复强调的概念是 ablation study（消融实验）：在控制其他条件不变的前提下，移除、替换或关闭一个模块，比较性能、稳定性、效率、成本的变化。他的建议是——"把整个系统提示词全删掉，然后一行一行加回来，看看每一行到底有什么影响。"

这条原则的反直觉之处在于：我们习惯把 system prompt 视作产品规格的一部分，越多越"完整"。但在 LLM 时代，每多一行 prompt 都在抢 token 预算、引入潜在冲突、掩盖模型的真实能力边界。一行写错的规则，可能让模型在 90% 的简单任务上都打折扣。

更残酷的是 Eval 的失效。Boris 直言："Eval 也未必能稳定使用——尽管它确实比 harness 和 prompt 耐用，但眼下模型进化太快，一套评测会被很快刷到满分。"这意味着 Agent 团队不能再像传统软件那样把测试集当成铁律，而要持续观察模型在哪些场景"挣扎"，并据此动态设计新的 Eval。

三、Product Overhang：模型能力总是溢出产品边界

访谈中 Boris 提出的第一个概念是 Product Overhang——直译"产品悬余"。它描述的是一种系统性的"错位"：大模型以不连续的跳跃式速度跃迁，而产品集成以连续的增量式节奏推进。模型所具备的能力，几乎任何时候都会超出现有产品所能释放的边界。

他举了一个 2024 年底的例子：Sonnet 3.5 推出时，这个模型已经能一次性写出整个文件的代码，但当时的主流编程产品 Copilot、Cursor 早期版还在做"补全代码"这样的小事。拥有完整终端权限的 Claude Code 之所以能后来居上，正是因为它在 harness 上做了大幅"解缚"，让模型原本就有的能力被释放出来。

这条规律对 2026 年的 Agent 团队同样适用：如果你今天还按"模型能完成 X 任务"的最小假设来设计产品，三个月后你就会发现自己做出了 6 个月前的产品。

四、Unhobbling：给模型"解缚"的三条路径

Boris 提出的第二个概念是 Unhobbling（解缚），指的是通过提示词、上下文、工具或产品形态的设计，在不改变模型权重的前提下，激发出模型本已具备、但此前未被调用的能力。

他在访谈中分享了 Anthropic 内部的真实案例：有人尝试给 Opus 5 接入 OpenCV，结果发现模型能自己画出人物肖像、动物风景——而在此之前，团队从未专门训练过模型去做这件事。这个现象叫 model elicitation（模型激发）。它和"模型学会新技能"难以严格区分，但 Boris 并不在意归因，更在意的是其中隐藏的商业机会。

基于这一思路，Boris 给出了三条"解缚"方法：

1. 给模型比你想象中更难做的任务。描述清楚目标、边界和退出条件，然后就放手。别替它把任务拆碎。
2. 多做实验、允许模型"玩"。不必每件事都有明确商业目的，给自己一点空间去尝试有创意的玩法。
3. 让模型自己验证成果。这可能是今天大家做得最不尽如人意的一件事——如果模型不能自我验证，它就没法长时间独立运行。

第三条尤其关键。它指向的是一个新指标：模型在长任务中"自检"的能力，决定了 Agent 能跑多长。

五、两个多星期还在跑的 Prompt

Boris 在访谈中分享了自己的一个真实使用案例，颇能说明第三条的价值：

"好吧，我要你做的是——把 Electron 应用重写成 Swift。我要你在 Mac 虚拟机里运行 Electron 应用，截屏，然后逐像素对比，跟 Swift 版本比，没做完就不要停。"

这就是 prompt 的全部。主持人问跑了多久，Boris 答："已经跑了两个多星期了，大概 14 天、15 天……Claude 还决定做直播——它在内部建了一个 Slack 频道，每隔几分钟发一张进度截图。"

这个案例的启示不在于"模型有多强"，而在于"harness 可以多简单"：没有子 Agent 编排、没有工具链包装、没有定时 checkpoint——只是一条朴素的 prompt 加一个长任务。模型自己解决了进度可视化、运行环境管理、对比验证等一系列工程问题。

这条 prompt 是 Unhobbling 第三条原则的极致体现：把验证逻辑内置到任务里，让模型自己"知道怎么算完成"。

六、给 Agent 实践者的反思清单

把 Boris 的访谈浓缩成一份给 Agent 团队的可操作清单：

实践	反向操作
半年一次删光所有 prompt/skills/hooks，再按行加回	永远加规则、从不删规则
把 harness 当消融实验对象，每行 prompt 都要可证伪	把 system prompt 当产品规格文档
假设模型能力"始终大于产品边界"	按当下模型能力最小集做产品
任务描述里写清楚"完成"的判定条件	替模型决定怎么算做完
允许模型跑长任务、跑失败、跑偏，再复盘	给模型加 guardrail 限制单次任务长度
Eval 是动态的，发现模型挣扎就重写	守住固定测试集不放

最后一条建议给个人：Boris 呼吁"放下对模型的'控制欲'，把模型当同事一样相处，不过度指定，不试图让它完全按照你会做的方式完成任务。因为模型不是那样工作的。"

这句话或许才是 Harness 半年保质期的真正含义——不是技术问题，而是产品心智的问题。

参考来源：

1. 量子位《Claude Code 之父：Harness 保质期只有半年，解开缰绳吧》，2026-07-30
2. 量子位《Claude Code 狂删 80% 提示词，Opus 5 反手加回去了》，2026-07-24
3. YC Library《Boris Cherny: We Cut 80% of Claude Code's Prompt》，2026-07-28