01 触发事件

Lenny's Newsletter 这篇节目摘要，核心其实不是标题里的 GPT-5.6，而是 Claire 用 Claude Agent SDK 做了一个 bug triage harness：它可以小到只有 8 个文件和一个 terminal UI，但已经能把 Sentry 调查、Linear 关联、权限约束、报告输出串成一条固定流水线。

这件事表面看像开发者 productivity 小技巧。

我更愿意把它看成一个 product boundary 的显形：agent 不再只是聊天框里的“大模型”，而是被代码包起来、被权限约束、被工作流固化、被 artifact 标准化的执行单元。

如果我没高估这条信号，这比又多一个 IDE 插件重要得多。

因为它说明，builder 开始把“可复用的 agent 行为”从 prompt 里拿出来，写进自己的系统里。

02 这事的真正含义

这才是它在说的事：通用 agent 工具正在被下沉为 runtime，而 harness 正在上浮成产品层。

文章里最关键的判断，不是 Claude Code 很强，也不是 Codex 很强，而是 Claire 明说：Cursor 是复杂 harness，Claude Code 是复杂 harness，你自己的 harness 也可以很小。这个定义一旦成立，市场边界就变了。

过去很多团队买的是“一个更聪明的 agent 界面”。

接下来很多团队真正会买、会自己写、会形成 switching cost 的，是“一个对特定任务更稳定的 harness”。

A harness is code you write to make an AI agent more effective at a specific job.

这句话很硬。

它把神秘感拆掉了，也把 moat 的位置说清楚了。moat 不在“你接了哪个最强模型”，而在三层：

第一，任务拆解是否足够 opinionated。
第二，权限和 tool policy 是否内生到系统，而不是每次靠 prompt 提醒。
第三，输出 artifact 是否结构化，能进入团队协作系统，变成组织记忆。

我没在内部跑过 Claire 这套系统，所以对它的长期鲁棒性保留一点怀疑。
但方向很明确：通用 MCP access 不是终局，专用 adapter 才更像生产环境。

原因很简单。广泛 access 带来探索自由，也带来 token 浪费、路径漂移、权限风险和结果不稳定。专用 adapter 则是把搜索空间压缩，把 agent 从“会逛工具”变成“会完成任务”。

问题不在模型会不会思考。

问题在你有没有把它放进一个可控的壳里。

03 历史类比 / 结构对照

这让我想到 2014 年后的 AWS。

早期云计算的价值主张是“把机器租给你”。但真正吃到结构性利润的，不只是裸算力，而是围绕算力长出来的 opinionated primitives：IAM、RDS、Lambda、CloudWatch。也就是把原本需要工程师临时拼装的动作，做成带权限、带边界、带默认路径的系统能力。

agent 现在也在走这条路。

foundation model 像 EC2。
Claude Code、Codex、Cursor 像 first-party console。
而 harness，更像团队自己写出来的内部 platform primitive。

如果这个类比成立，那么下一阶段竞争不会只是 benchmark 排名，而是谁能更快沉淀出一组高频任务的 harness library：bug triage、sales research、support escalation、PR review、incident postmortem、compliance check。

我可能会低估通用工具持续进化的速度。也许 12 个月后，Claude Code 或别的 agent IDE 已经把这些场景 productize 得很好。
但即便如此，拥有 harness 仍然重要，因为它天然支持 multi-model routing、差异化 tool policy，以及将来替换底层模型而不改上层接口。

这就是 aggregation theory 在这里的一个变体：上游模型会被持续商品化，真正重新聚合需求的，是离 workflow 最近、离 distribution 最近、离 artifact 最近的那一层。

不是 model layer 吃掉一切。
是 harness layer 重新定义谁拥有用户关系。

04 对 AI builder 意味着什么

对 builder 来说，这周就该调整的，不是再试一个新模型，而是先盘点哪些任务已经满足 harness 条件：步骤部分确定、工具集合确定、输出格式确定，但中间判断仍需模型完成。

Sentry bug triage 是一个好例子。
Support ticket 分类也是。
Sales lead enrichment 也是。
PRD 初稿生成、合规文档比对、失败任务复盘，也都很像。

我会给三个很具体的动作。

第一，别先做“全能 agent”，先做单任务 harness。
任务越窄，tool adapter 越容易写，artifact 越容易标准化，评估也越容易闭环。我可能偏保守，但现在追求 generality，通常只会把 failure mode 一起放大。

第二，把权限写成系统状态，不要写成 prompt。
文中那个 investigate only 的 flag 很关键。因为 prompt 权限是易失的，UI/状态机权限才是可审计的。对 API 消费者来说，这直接决定事故率，也直接决定能不能进团队工作流。

第三，优先设计 artifact，不要先迷恋 agent 的“智能感”。
task log、issue brief、logs、worker report、HTML summary，这些东西才是组织可复用资产。没有 artifact，agent 只是一次性的 token 消耗器；有 artifact，它才开始形成内部 distribution。

如果你是 model gateway、AI infra、或者多模型路由玩家，这里还有一个更直接的启发：harness 会天然推高 model routing 需求。
因为不同步骤对 latency、cost、reasoning depth、tool-use reliability 的要求不同。一个固定聊天框做不到精细路由，harness 可以。

那个真正会被定价的，不只是 token。
而是每一个 workflow step 背后的最优模型选择权。

05 反方观点 / 风险

反过来说，我也可能把 harness 的战略意义讲得太大了。

第一种可能，是它其实只是 agent 时代的“高级脚本”。
很多团队会发现，写 harness、维护 adapter、处理权限边界、做 eval，最后成本比人工还高。尤其当任务频率不够高时，定制层未必划算。

第二种可能，是第一方工具会迅速吞掉这层价值。
如果 Claude Code、Codex、Cursor 把权限模板、artifact 模板、tool policy、模型切换、审计日志全部做进产品，那很多自建 harness 的 moat 会很薄。我没法排除这个结果，而且它发生的概率并不低。

第三种可能，是 MCP 生态自己进化出更强的中间层。
今天文章强调 opinionated adapter 优于通用 MCP access，但如果未来 MCP server 开始原生提供 task-specific schema、policy、cost guardrail、artifact contract，那么“自己包一层”的必要性会下降。

第四种可能，也是最现实的：builder 高估了模型稳定性。
一个 harness 只有在任务边界稳定、工具接口稳定、模型行为相对稳定时才成立。现在这三件事都还在变。我可能误判了拐点时间，尤其在 developer tooling 这条线上，半年就是一代产品。

但即便把这些反方都算进去，我还是会保留一个判断：
harness 至少不是一个 feature，它更像 agent 时代的 application architecture。

它未必总是你的 moat。
但如果你完全没有它，你大概率也没有真正属于自己的 agent 产品。