版本说明 · v0.1：这是我现阶段对 Harness 的理解，后续会随着实践和思考继续修改、补充。
前阵子听了 The Pragmatic Engineer 的一期播客，主持人 Gergely 和 Codex 负责人 Tibo Sottiaux 聊了一个多小时 ↗。其中有一小段，我听完之后想了很久。
Gergely 问：早期的 Codex 改完代码不会主动跑测试，几个月之后它自己会跑了，你们改的是提示词，还是模型？
Tibo 的回答大意是：Harness（围绕模型做的那部分工程，下一节会细说）总是比模型领先一点。模型其实有这个能力，只是还不够稳定，他们就先在外面加一句提醒；等下一代模型训练出来，它自己就会了，这句提醒也就可以删掉。时间一长，他们写给模型的说明越来越短，Harness 也越来越小。
节目最后，Gergely 说了一句很实在的话：作为开发者，这听起来有点让人泄气。今天认真做出来的东西，下一版模型自己就会了，然后就可以删掉。
Tibo 描述的这个现象我是认同的，我自己做 Agent 的体会也是这样。但我得出的结论和他们两位都不一样。Tibo 站在 Codex 核心 runtime 的位置上，看到 Harness 在变小；我站在「人和 Agent 怎么一起把事做完」的位置上，看到的是它一直在变大。两个观察都成立，只是看的不是同一样东西。Gergely 觉得泄气，我反而觉得这正是现在做 Agent 产品最有意思的地方。
这篇文章就借这段对话开头，只聊 Harness 这一件事：它指什么，哪些部分会被模型学走，哪些部分反而越做越大，以及做 Agent 产品的人该怎么算这笔账。
一、Harness 到底指什么#
我做 Agent 的时候，习惯把它拆成四个部分：大脑、记忆、工具、循环。
大脑就是模型，也是其中唯一一个我不需要做、也没有能力做的部分。我不会去训练一个模型，我能决定的只是调用哪一个。除此之外的全部工作都在模型外面：记忆怎么存，工具怎么接，上下文怎么管理，出错了怎么处理。
模型外面的这一整圈，业内叫 Harness。LangChain 的 Vivek Trivedy 有一个很干脆的说法：Agent = 模型 + Harness，模型之外的一切都是 Harness。
这个说法好记，但它是按位置来定义的：先划出模型，剩下的都算。它能告诉你 Harness 在哪里，却说不出 Harness 是干什么的，而且什么都装得进去。我更愿意按作用来定义：
Harness 是让人和 Agent 能够持续协作的一套机制：把人的意图、上下文和规则接到 Agent 的行动上，再把 Agent 做出来的结果交回人的工作流程。
打个比方，它是人和 Agent 之间的一座桥。不过「桥」只适合拿来解释，正式一点我还是叫它机制，因为它不只是把两头连起来，还要管桥上的事：什么可以过，谁来放行，过到一半断了怎么办。大家常说的「协议」，比如工具怎么声明、消息是什么格式、任务怎么交接，是这套机制的一部分，但不是全部。
按这个定义，写作 Agent 的编辑器和版本管理是 Harness，客服 Agent 接的知识库和工单系统是，你给自己的个人 Agent 写的那份很长的偏好说明也是。更早的 Prompt Engineering 和 Context Engineering 同样属于这个范畴，只是当时还没有人用这个词，做的事也主要是其中一种：教模型把某一步做对。
它也有边界：必须落到 Agent 参与的工作上。公司的请假制度、团队的周会，本身不是 Harness，那是人和人之间的管理。但当你让 Agent 替你提交请假，它需要知道该走哪个流程、谁来审批、批完通知谁，把这些接给它的那一部分才是。重点始终是人和 Agent 怎么一起把一件事做完。
这套机制有多重要？可以看两个例子，它们的共同点是模型没有换，只改了外面。
第一个就是开头那件事。早期的 Codex 改完文件不会跑测试，Tibo 的团队在提示词里加了一句提醒，它就开始跑了。
第二个例子方向相反。Claude Code 的作者 Boris Cherny 今年在 YC Startup School 的分享里提到（官方逐字稿 ↗），Opus 5 发布的时候，他们把 Claude Code 的系统提示词删掉了 80%。原因是其中很多内容是在纠正旧模型的问题，而新模型已经没有这些问题了。他还提到，去掉这些提示之后，模型的表现反而略有提升。
两个例子说明的是同一件事：这套机制做对了，模型的能力才发挥得出来；这套机制过时了，反过来会拖累模型。很多看起来是「模型不行」的问题，根源其实在 Harness。我自己用某个 coding 模型时就遇到过：它的工具调用经常失败，排查之后发现是参数格式没有对齐，和模型本身的能力没有关系。
二、补上去的东西，模型迟早自己会#
Tibo 描述的这个现象，在过去几年里反复出现过。
2022 年，大家发现只要在提示词末尾加一句「Let’s think step by step」，模型在推理题上的正确率就会明显提高。那两年流行的各种 magic words 都是同样的思路。到 2024 年推理模型出现，「先思考再回答」被直接训练进了模型，这句话也就没有人再写了。
工具调用也是一样。最早的做法是在提示词里约定一种输出格式，由外部程序解析文本、执行、再把结果交还给模型。后来各家把 function calling 做成了模型的原生能力，那一层解析代码就不再需要了。不过退场的只是解析文本的那层代码：工具依然在模型外面执行，执行的结果依然要由外面的程序取回来、核对过，才能算数。
最近的一个例子来自 Claude Code。团队在 9 月发布过一期 22 分钟的内部对谈 How the Claude Code team uses Claude Code ↗，出镜的是 Thariq Shihipar、Sid Bidasaria 和 Robert Boyce。他们讲到了 Todo List 的来历：大约在 Sonnet 3.5 的阶段，交给模型五件事，它往往做完三件就停了，于是团队加了一个待办列表，效果非常明显。一年之后，这个工具已经基本不需要了。
这一点有版本记录可以印证。8 月 14 日发布的 Claude Code v2.1.233 ↗ 在 release notes 里写明：TodoWrite 等五个待办和任务跟踪工具，在 Opus 4.8、Sonnet 5、Fable 5、Mythos 5 及之后的模型上不再提供，需要的话可以通过环境变量 CLAUDE_CODE_ENABLE_TODO_TOOLS=1 重新打开。原因不难理解：每个工具的定义，模型在每一轮都要读一遍；当模型自己已经能记住要做的事，这个工具带来的成本就超过了收益。
这里也要分清楚退场的是什么。退场的是「帮模型记住这一轮要做的五件事」的那个工具；一个要跑好几天、几个人都要看进度的任务，状态存在哪里、中断之后从哪一步继续，这个需求并没有跟着消失，下面还会讲到。
为什么总是先在外面做，之后才进到模型里？因为在外面试错的成本低。 改一句提示词只要几分钟，改一段循环逻辑只要一个下午，效果当场就能看到。训练一个模型要以月为单位，而且得先知道要训练什么。「要训练什么」这个问题的答案，恰恰是在模型外面、在真实用户的使用中一点点试出来的。
Tibo 在节目里也提到了他们内部的做法：发现一个问题之后，研究和工程团队会一起讨论，这个问题应该在 Harness 里解决，还是在模型里解决；如果改模型，需要一个月、三个月还是六个月。有时候他们会决定在 Harness 里什么都不做，直接等模型。
Tibo 把这些补丁比作拐杖，我觉得这个比喻不太准确。拐杖是伤好之后就扔掉的东西，而这些补丁做的事，更像是替下一代模型探路：今天在外面验证过的做法，就是明天模型应该具备的能力。而且探路的不只是模型厂商。「step by step」和早期的工具调用，最初都来自论文和开发者社区。我们平时摸索出来的那些技巧，也是其中的一部分。
退场的原因不止一种#
上面这些例子，退场的原因都是模型学会了。但我回头数自己删掉过的东西，发现旧实现退场其实有三种原因，混在一起说，很容易得出「Harness 迟早都会进模型」这种结论。
- 模型已学会。 主动跑测试、先思考再回答、做完五件事再停。这一类是真的被模型学走了，外面那句提醒可以直接删掉。
- 平台已承接。 前两年做 Agent，记忆要自己搭，接每一个外部系统都要自己写一套连接代码。现在记忆是各家产品的内置功能，MCP 是公共协议，常用的集成平台已经替你做好。自己写的那份可以删了，但这件事并没有进到模型里，只是换了一个承接的人。
- 协作方式改变。 Claude Code 团队那期视频里提到 AskUserQuestion 这个工具，作者花了很长时间设计，后来他自己也很少用了，而是直接让 Claude 生成一个带图表、可以交互的 HTML 页面来向他提问。固定的提问工具退场了，「Agent 需要向人把事情问清楚」这件事一点没变，变的只是人和 Agent 之间用什么形式来问。
三种原因都会让旧的实现退场，但只有第一种可以说是被模型吸收了。后两种情况下，需求原封不动地还在，只是实现换了地方，或者换了形式。
哪些东西模型学不走#
那么，这套机制最终都会被学走吗？不会。
我判断的方法很简单，只问一个问题：假如模型已经足够聪明，这段代码还有没有存在的必要？
提醒它跑测试，提醒它不要做到一半就停，这些都是在教模型完成某一步，在足够聪明的模型面前没有必要了，所以迟早会被学走。但下面这些事情不是模型哪一步做得不好，而是人和 Agent 一起做事本身就需要的，模型再聪明，也得有人在外面做：
- 取回真实的结果。「测试通过了」从模型口中说出来只是一句话，真实的退出码要由程序去取。模型越强，它写的完成报告读起来越可靠，也就越难靠读报告发现问题，所以 CI 是红是绿必须由程序来确认。
- 权限和边界。「它会选择不读这个目录」和「它读不了这个目录」是两回事，只有后者才是保证。规则可以让模型起草，执行必须交给沙箱和权限系统。
- 进度和触发。 模型只在被调用的那几秒存在。定时任务由谁触发，进程崩溃之后从哪一步继续，哪些操作已经执行过、不能重复，这些都发生在模型不在场的时候。
- 通往真实世界的接口。 模型再聪明，也接触不到没有接给它的东西：你的数据库、内部系统、IM、邮箱、支付。我之前给自己的 Agent 配了一个邮箱，补的就是这一块。
- 人在哪里介入。 怎么看到它正在做什么，在哪一步可以打断，哪些操作需要人确认。
- 成本。 用哪个模型，同时开几路，预算花到多少应该停。付账的是你，这笔账只能在模型外面算。
- 追查和撤回。 Agent 替你做的事情越多，事后能不能说清楚「它当时做了什么、为什么这么做」，做错了能不能撤回，就越重要。
而且模型越强，这些部分的分量越重。因为模型越强，我们就越敢让它在无人值守的情况下运行更长时间，需要核对的结果、需要管理的权限、需要衔接的断点，都会随之增加。
Boris 在那场分享里的一句话可以作为印证。他说团队每发布一个新模型，就会删掉一轮 harness 里的代码，到今天，Claude Code 的 harness 里剩下的代码，几乎全是安全、权限和静态分析，再加上大量 UI 代码。 安全和权限对应边界，静态分析对应真实的结果，UI 对应人的介入。
最后还有一样学不走的东西，也是后面两节的重点：只属于你、你的组织或企业的上下文。团队为什么这样决定，企业内部的流程为什么是现在这个样子，你的用户说「老样子」指的是什么，什么样的结果在你的场景里才算合格。
拿 Skills 来验证一下#
「假如模型已经足够聪明，它还有没有存在的必要」，这个问题也可以用来看最近很热的 Skills。
Superpowers ↗ 是过去一年最流行的开发流程 Skills 之一：先 brainstorm，再把计划拆成小任务，强制 TDD，做完之后 review，相当于给 coding agent 装上了一整套软件开发方法论。GPT-6 发布之后，我看到很多人不再用它，转向了 Matt Pocock 的 grill-me 系列 ↗。后者轻得多，核心只有一件事：在动手之前反过来追问你，直到方案里每一个没有想清楚的地方都问明白为止。
这个变化和前面讲的是同一件事。Superpowers 补的是模型在「怎么规划、怎么执行」上的判断；模型自己具备了这种判断，这套流程就从帮助变成了负担，很简单的问题也要走完整套流程。grill-me 留下的那一部分，是把只有你知道的信息从你这里问出来，这是模型自己推断不出来的。不过我认为它也未必能留很久：下一代 SOTA 模型出现之后，模型很可能自己就知道什么时候该停下来提问、该问什么，到那时今天大家追捧的 grill-me 同样会被淘汰。
我自己平时不用这类开发流程 Skills。在我看来，Skills 就是外部能力包。怎么开发、需求怎么拆分，这些我自己清楚，直接告诉 Agent 就可以，不需要再装一套流程替我做决定。
Skills 这种形式本身不会被淘汰，但它最后剩下的价值，很可能只有一点：方便传播。一份垂类领域的 know-how 打包成 Skill，别人装上就能用，这一点很难被替代。只不过别人给我一个垂类 Skill 之后，我也不会原封不动地只用它，而是会把它拆开，融进自己的 Agent 和 workflow 里。
把这一节提到的东西放在一起，换几代模型来看，规律会更清楚：
上一批实现基本都退场了，但原因不止一种：有的被模型学会，有的被平台接走，有的是协作方式变了。右边一项没少，而且每一项都更重了。
Todo List 工具模型已学会
- 补的是什么
- 交给模型五件事，它往往做完三件就停了。加一个待办列表，效果非常明显。
- 后来
- 2026 年 8 月的 Claude Code v2.1.233 起，待办工具在新一代模型上默认不再提供。
- 需求还在吗
- 「记住这一轮要做的几件事」不用管了。但跨几天、几个人都要看进度的任务，状态存在哪里、断了从哪里继续，仍然要在外面做，见右栏「进度和触发」。
三、教模型的部分在变小，协作的部分在变大#
补丁一个个被删掉，Harness 是不是就像 Tibo 说的那样越来越小？
先说清楚他指的是什么。Tibo 说的 Harness，是 Codex 团队自己维护的核心 runtime：沙箱、工具，以及每一轮开头写给模型的那段说明。在这个范围里，他说得对，这一部分确实在变小，而且应该变小。
我看的是另一个问题：人和 Agent 怎么一起把事情做完。在同一期节目里，Tibo 自己还讲了另外几件事：OpenAI 内部的 Codex 默认接入了 Slack、全部文档和全部代码，新人遇到问题，会先被问一句「你问过 Codex 了吗」；Codex 的使用场景也从写代码扩展到了 finance、marketing 等领域。这些事情没有一件是在教模型完成某一步，全都是在让更多的人、更多的工作能和 Agent 接上。
所以我的判断是：模型变强，减少的是教它完成某一步的机制；更多的人把更多的工作交给 Agent，增加的是让彼此协作的机制。 测试提醒、Todo 工具这些补丁，是当下为了让协作能进行下去而搭的支撑，模型学会了就可以拆；权限、状态、交接、反馈，是协作本身的长期需求，交出去的工作越多，它们就越重。
Claude Code 团队在那期视频里说得更直接。讲完 Todo List 的退场之后，另一位成员接着补充：这些功能当初是为了弥补模型的缺陷，模型变好了就可以拿掉；但与此同时，他们交给 Claude Code 的任务变得更大、更难，要在更大的任务上保持连贯，模型又需要新的工具。
删掉一批补丁，能交给 Agent 的任务变大，新的协作问题又冒出来。我之前写过 Prompt → Context → Harness → Loop 这条演进线，背后是同一个规律：前一个问题稳定了，大家着手的地方就移到下一个问题上，而原来那部分并没有消失，只是成了新问题的基础。
那么，现在协作的问题长到了哪里？先说我自己的变化。
无论是工作还是平时自己做开发，我直接面对 coding agent 的时间都在减少。现在更常见的情形是：我拿着手机，或者在电脑上开着一个 IM，在对话框里把事情交代出去。公司里用的是飞书，个人项目用的是 Telegram，QQ 粉丝群里也有一个 Agent。底层干活的依然是 Claude Code、Codex 这些 coding agent，这一点没有变；变的是我和它们之间多了一层，我工作的抽象层高了一级。
Claude Code 团队的情况也类似。视频开头，主持人问大家现在怎么用 Claude Code，一位成员说，他 70%—80% 的工作发生在 Claude Tag 上，这是他们做的一个运行在 Slack 里的 Agent；只有剩下的 20%，他才会打开终端或桌面端去做精细的修改。
为什么把 Agent 放进 IM 之后反而更好用？另一位成员的解释是：它在 Slack 里，可以查到团队的讨论，了解产品的背景和大家之前做过的决定，所以它做出的判断好了很多。他现在交给 Claude Tag 的问题，比「实现这个函数」要复杂得多。
这和我的体会一致。代码仓库记录的是系统现在是什么样，聊天记录里记录的是它为什么是这样。只有前者，Agent 很容易做出局部正确、整体却不合适的修改。
所以在我看来，Harness 已经不能只盯着单个产品来看了。我按「谁和谁在协作」，把它分成三种尺度：产品、Repo、组织。先说明一点：这不是一个严格嵌套的三层架构，也不是每个团队必须依次走过的三个阶段，只是我观察到的三种规模不同的协作场景。图里的每一种都可以点开看细节。
表达需求、补信息、调结果、确认执行
- Tool
- MCP
- 上下文
- 记忆
共享约定、感知彼此的工作、交接、验证合并
- AGENTS.md
- CI/CD
- 文档
- repo index
- 以前要问同事才知道的事
获取业务背景、跨角色推进、授权、反馈闭环
- 团队的决定记在哪里
- Agent 能代表谁发言
- 用户反馈怎么回到它手里
- 文中的例子
- 「改完记得跑测试」的提醒、被删掉的 80% 系统提示词、Todo 工具、AskUserQuestion。
- 会退场的
- 提醒类的补丁被模型学走；记忆和通用集成被平台做成标配；固定的提问工具被可交互的 HTML 取代。
- 长期要做的
- 你的工具、确认和撤回的方式，以及垂类里才有的做法。设计、剪辑、市场研究这些领域，才刚开始探索。
产品级：一个用户和一个 Agent#
这是大家最熟悉的一种。协作发生在一个用户和一个 Agent 之间：用户怎么把需求说出来，Agent 缺信息的时候怎么补，结果不满意怎么调，哪些操作要等用户确认了才能执行。判断一个 Agent 产品的 Harness 做得怎么样，我主要看四件事：Tool 怎么设计，MCP 怎么接，上下文怎么管理，记忆怎么存。前面讲的测试提醒、被删掉的 80% 提示词、Todo 工具，都发生在这个尺度上。
在 coding agent 这个领域，这个尺度已经相当成熟，其中通用的实现正在以前面说的三种方式退场：提醒类的补丁被模型学走，记忆和通用集成被平台做成标配，固定的提问工具被更灵活的交互形式取代。
但这只是 coding agent 的情况。coding 是现在最热的方向，大部分人和资源都投在这里，能试的东西很快就被试过了，所以这个尺度上剩下的提升空间才显得不大。换到其它领域，设计、剪辑、市场研究，各种垂类 Agent 的 Harness 才刚刚开始探索：一个剪辑 Agent 应该有哪些工具，一份市场研究报告的质量怎么交给程序验证，设计 Agent 的记忆里应该存什么。这些问题现在都没有公认的答案，谁先做出来，谁就能领先一段时间。
Repo 级：一个开发团队和各自的 coding agent#
这个尺度是在 coding agent 好用到人手一个之后才出现的。协作的双方变成了一个开发团队和他们各自的 Agent：大家共享同一套约定，要能感知彼此正在做什么，要交接，要验证，最后要合并到一起。Repo 是我最熟悉的一个具体场景，设计团队共用的设计文件、运营团队共用的内容排期，面对的是同一类问题。
设想一个 5 人的开发团队，每人配一个 coding agent。每个 Agent 单独看都没有问题，放在一起，新的问题就出现了，而且这些问题换一个更强的模型也解决不了：
- A 的 Agent 刚修改了一个接口的约定，B 的 Agent 并不知道，又按旧的约定写了三处调用。
- 两个 issue 单独看都合理，改的却是同一块逻辑，前提还互相矛盾。两个 Agent 分头做完，到合并的时候才发现冲突。
- 历史遗留的技术问题。这段代码为什么写得这么绕，哪个模块看起来可以删、实际上不能动，哪张表其实有两个地方在写。这些很少有人写下来，从代码里也看不出来。
- 每个 Agent 进入仓库都要重新熟悉一遍：模块怎么划分，入口在哪里，哪些目录是生成的、不需要读。这份成本每个会话都要付一次，再乘以 Agent 的数量。
- 规范只存在于人的脑子里。提交信息怎么写，哪些改动必须先跑 check，哪些文件不能动。人可以靠默契，Agent 只能靠写下来的东西。
在没有 AI 的时候，这些问题是怎么解决的？问同事。看不懂的代码，问一句旁边的人；两个需求可能冲突，开会的时候总会有人提出来。这些知识一直都在，只是存在人的脑子里和聊天记录里，从来不在仓库里。
现在干活的换成了 Agent，它没有可以随口一问的同事。所以要尽可能把这些东西变成 Agent 能读到、能用上的形式，也就是让仓库变得 agent friendly。最基础的是四样：一份 AGENTS.md（在 Claude Code 里是 CLAUDE.md）、CI/CD、文档，以及一份 repo index，也就是给 Agent 看的仓库地图。但需要做的远不止这些：怎么记录「当初为什么这样决定」，怎么让一个 Agent 知道另一个 Agent 正在改什么，怎么处理 issue 之间的依赖和冲突，大家都还在探索。
这些做法看起来很朴素，很多人不会把它们和 Harness 联系起来。但它们做的，正是把团队的约定和上下文接到每一个 Agent 的行动上，再让 Agent 的产出回到团队的验证和合并流程里，当然属于 Harness。
我自己这个博客的仓库就是一个例子。CLAUDE.md 里有一条规定：不要直接 push 到 main，先推到分支，等我看过预览再合并。 这条规定是出过一次问题之后才加上的：有一次 Agent 写完一篇文章，直接推到了 main，而 main 是自动部署的，那篇文章在我看过之前就上线了。Agent 并没有做错什么，是我没有告诉它。现在这条规定写在那里，每一个新会话进来都会先读到。
视频里，Robert 说他开发 Claude Tag 时的主要精力也放在这里。他们大量使用 Claude Tag 来开发 Claude Tag 自己，所以他最关心的是开发环境对 Claude 是否足够友好：它能不能自己把软件运行起来，能不能自己从头到尾完成验证。
Boris 讲的另一件事也说明了这个尺度的分量。Bun 从 Zig 重写为 Rust：Bun 团队的 Jarred 每逢新一代模型发布，就把这个任务交给它试一次，直到有一代模型做成了。按 Boris 的说法，那是一个 prompt 加上一个调度大量 Agent 的工作流，一共运行了 11 天。这件事能成，关键不在提示词，而在于 Bun 和 Node.js 本来就有一大套现成的测试，结果对不对随时可以验证。「能不能验证」比「指令怎么写」更重要，而能不能验证，取决于仓库本身。
顺着 agent friendly 再往前想一步。当一个人已经 AI native 了，习惯了把事情交给 Agent 去做，接下来要解决的问题，就是怎么让他所在的组织也变得 AI native。让一个仓库对 Agent 友好，和让一个组织对 Agent 友好，本质上是同一件事：把原来只在人和人之间流动的信息，变成 Agent 也能拿到的信息。区别只是范围从一个仓库，扩大到了整个组织。
组织级：不同角色的团队和他们的 Agent#
Repo 里那些写不进仓库的东西，大部分就留在这里：团队的聊天记录、文档，还有人的脑子里。这个尺度涉及的也不再只是开发团队，还包括运营、增长、设计。Agent 要拿得到业务背景，要能跨着角色把一件事推进下去，要清楚自己得到了谁的授权，做完之后还要有反馈回到它手里。
我把工作放进飞书、把个人项目放进 Telegram，本质上就是把 Agent 放到这些信息所在的地方。以前遇到问题要去问同事，现在 Agent 和同事在同一个 IM 里，它可以自己去翻之前的讨论，也知道一件事该去找谁。
Thariq 在视频里讲了一个完整的例子。他想做一个内部工具，需要很多人的支持。他先问 Claude Tag：我有这样一个想法，应该找谁聊？拿到名单之后，他让它出 mockup，整个过程都在 Slack 里，用手机就能看。接着由它来实现。他不确定这个工具是否真的好用，于是加了很多埋点，部署到内部；Claude Tag 替他留意，有人反馈就提醒他。后来他从数据里发现用户没有走完整个流程，想要改进。他原本打算直接说「我有个主意，你照着做」，后来改成了「你去想办法改进这个漏斗，给我几个方案」，自己的主意只作为其中一个例子。
在这个例子里，写代码只占中间的一小段。前面是找人、对齐想法，后面是埋点、看数据、收集反馈，这些原本是产品、运营和增长的工作。
到了这个尺度，Harness 要回答的问题变成了：团队的决定记录在哪里，Agent 能不能读到？它可以代表谁发言，可以主动联系谁，谁授权的？真实用户的反馈通过什么渠道回到它手里？我上一篇讲权限隔离的文章写的就是其中一个问题：同一个人背后的工作 Agent、个人 Agent 和群里的 Agent，各自能看到什么，能对谁说话。
三种尺度可以重叠#
三种尺度不是一层包着一层，也不需要按顺序走。我一个人做个人项目，没有什么五人团队，却早就在 Telegram 里让 Agent 跨着好几件事替我推进；一家公司也完全可能先在 IM 里把 Agent 用了起来，仓库那边还没来得及整理。同一件事也常常同时落在几种尺度上：Thariq 做那个内部工具，找人是组织级的，实现是 Repo 级的，他和 Claude Tag 来回调 mockup 又是产品级的。
它们之间当然互相影响。单个 Agent 不好用，五个 Agent 怎么配合就谈不上；仓库没有理顺，Agent 在组织里推进事情也会处处卡住。但这是互相支撑的关系，不是必须先做完一种、才能开始下一种。
每种尺度上旧实现退场的方式也相同：通用的做法会被模型和平台收走，只属于你、你的组织或企业的内容会留下来。产品级，工具调用的机制已经是原生能力，但你的工具是你自己的；Repo 级，读仓库、跑 review 会被 coding agent 内置，但团队的规范和历史要自己写；组织级，运行在 IM 里的 Agent 会成为平台出售的产品，但「当初为什么这样决定」只能由组织自己积累。
区别在于比例。协作的范围越大，属于自己的部分占比越高，也就越难被学走。 组织级的主体是一个组织、一家企业自己的决策历史，它不在任何人的训练数据里。
四、做 Agent 产品要算一笔账：Harness 要涨得比模型快#
把前面几节合起来，可以得到一个关于产品的判断。
用户为什么要用你的产品，而不是直接打开 ChatGPT 或 Claude？因为同一件事交给你的产品来做，会更省心，结果也更好。拆开来看，大致是这几样：
- 中途需要人工介入的次数更少，不用每走一步都回来确认。
- 前期不需要花额外的时间沟通需求，它已经了解你的场景和偏好。
- 最后交出来的结果更好，返工更少。
- 有些事情裸模型根本做不了，因为它接不到你的数据和系统。
这些加在一起，就是你的产品相对于裸模型多出来的那一部分。问题在于，模型每隔几个月就会变强一次，这一部分会被它一点点追平。
所以只是「现在比裸模型强」还不够，你的 Harness 必须增长得比模型快。 增长的速度就是斜率：Harness 的斜率要高于底层模型的斜率，否则每过一代模型，你领先的部分就会变薄一些。
示意图。B 的起点可以比 A 还高，但决定结局的是斜率。
Todo List 就是一个例子。在 Sonnet 3.5 的阶段，它带来的领先是实实在在的，有没有它差别很大。但这是一次性的领先，一年之后模型自己追平了。当前领先多少并不说明问题，能不能持续领先才是关键。
斜率由什么决定？我认为主要是三点：
- 试错的成本。 coding agent 的 Harness 这一年发展得这么快，很大程度上是因为代码非常适合试错：输出是文本，可以 diff，可以运行，有退出码，试一次几乎没有成本。
- 有没有别人拿不到的输入。 私有数据、真实用户的反馈、某个行业具体的工作方式。通用的技巧人人都会，也都会被模型学走。
- 多做出来的部分有没有人买单。 也就是有没有增量市场：Harness 每往前做一步，是不是就多出一批原来做不成这件事的用户。如果需求是一块固定的蛋糕，模型每进步一点就替代你一点，那么你增长得再快，也只是在防守。所以做 Agent 产品，一定要找有增量市场的方向。
为什么我不看好 AI 视频的衍生应用#
用这三点去看这半年最热的一类产品：基于 AI 视频、AI 生图做的各种衍生应用，包括做设计的、批量生成短剧的、做营销视频的。其中 To C 的那一大批，我并不看好。原因不是它们现在做得不好，而是它们的 Harness 几乎没有斜率。
先看试错成本。以字节的 Seedance 2.5 为例，它在火山方舟上按 token 计费，不含参考视频输入时每百万 token 70 元。按官方给的公式折算，480p 每秒约 0.67 元，720p 每秒约 1.51 元，比上一代 Seedance 2.0 贵了一半左右。2.5 支持单段最长 30 秒，一条 30 秒的 720p 片子，生成一次就是 45 元左右。coding agent 里「生成、检查、不合格就重来、同时开十路选最好的」这套做法，放到视频上，10 路、重来 3 轮，就是一千三百多元，而最后用上的只有其中一条。
比成本更根本的问题，是质量很难保证。代码改坏了，测试会告诉你；视频的输出是像素，没有 diff，也没有退出码。同一段提示词生成两次，得到的是两条不同的片子。想只改某个镜头里的一个细节，往往要整段重新生成，而重新生成又会带来新的问题：人物的脸变了，场景的光线对不上，前后两段接不起来。「这个镜头好不好」最后只能靠人一条一条地看。上一节说「能不能验证」比「指令怎么写」更重要，视频缺的恰恰就是这一环：没有一个程序能替你判断结果合不合格，「自动检查、不合格就重来」的循环也就转不起来。
结果是这类产品的 Harness 普遍很薄：提示词模板、分镜拆解、素材拼接，再加一个好看的界面。成片质量每一次明显的提升，比如人物一致性、时长、口型，都来自底层模型的换代，而不是产品自身。模型进步带来的好处，所有调用同一个 API 的竞品会同时得到。更麻烦的是，产品里投入最多的那几块工程，比如为了保持人物一致性做的各种变通、为了延长时长做的分段拼接，恰恰是下一代模型最先解决的问题。
再看有没有人买单。To C 这一侧，AI 确实降低了制作成本，但这个成本是给所有人同时降低的：内容的供给一下子多了很多，观众的时间和付费意愿却没有跟着变多，利润不会留在制作环节。
所以我的判断是：这半年视频生成的热潮里，最大的赢家是模型厂商。 以字节的 Seedance 为例，下游产品无论怎么打折、怎么换算成积分和会员，本质上都是在卖 token；而这些产品本身，并没有在模型之上做出一层足够好的视频生成和编辑 Harness。
生图为什么好一些#
同样的三点放到生图上，情况要好一些。图像 API 比视频便宜得多，能力也成熟得更早，Harness 的可操作空间因此大了很多：一次生成几张再挑选、局部重绘、用各种条件控制构图、搭建节点式的工作流，这些在生图上都试得起，也确实形成了一个规模不小的工具生态。
同样是视频模型，MiniMax-H3 为什么不一样#
所以问题不在「视频」这个品类，而在试错的成本压不压得下来。MiniMax-H3 ↗ 和 Seedance 一样是视频生成模型，但它走了另一条路：公开权重（Hugging Face ↗）。权重在自己手里，就可以量化，可以在低算力的机器上本地部署。按 ComfyUI 官方的说法，量化之后在 RTX 3060 这样的消费级显卡上就能运行。
它的意义在于，把「试一次」的成本从按次付费，变成了一次性的硬件投入加上电费。本地推理当然不是只有电费：显卡要买，消费级显卡的吞吐有限，一条片子要等得更久，环境也得自己维护。但多试一次的边际成本低了很多。多路生成再挑选、不合格就重来、围绕自己的素材搭一条流水线，这些在按量计费时算不过来账的做法，现在算得过来了。平民玩家第一次有条件在视频上认真做 Harness，成本也能真正压下来。
需要提醒两点。第一，开放权重的版本原生是 768p、单段最长 15 秒，用的是 MiniMax 自己的社区许可，对地区和商用都有限制，并不是无条件开源，使用之前请自行确认。第二，成本是给所有人同时降低的，它只解决了「试不试得起」的问题；质量怎么验证，有没有别人拿不到的输入，多做出来的部分有没有人买单，这些仍然要自己回答。
哪些情况仍然值得做#
- To B，或者手里有私有数据和流程。 品牌的素材库和视觉规范，电商的商品库，行业的合规规则。这些是别人拿不到的，而且模型越强，它们的价值越大。
- 本来就有 IP 或流量。 这种情况下 AI 只是降低成本的工具，护城河本来就不在 Harness 上。
- 把精力放在可以修改、可以检查的中间产物上，而不是像素上。 剧本、分镜、时间线、图层，这些都是文本和结构，可以 diff，可以检查，可以局部修改。
如果你见过反例，也就是一个 To C 的 AI 视频应用，在底层模型换了几代、竞品都能调用同一个 API 的情况下，依然能持续留住用户并且盈利，欢迎告诉我。
斜率没有办法精确测量，但可以粗略估计。准备一组你自己场景里的真实任务，每次底层模型换代时跑两遍：一遍用完整的产品，一遍用裸模型加最薄的一层封装。把两者的差距连续记录两三代，它是在变大还是变小，就很清楚了。
五、我自己的做法#
模型厂商可以选择「这个先不做，等下一代模型」，因为他们看得到训练计划。我看不到。我用的是别人的模型，不知道哪个问题正在被修复，而我的用户今天就有事情要完成。所以补丁还是要打，只是打法要变。我给自己定了三条。
第一，通用的补丁按短期来做。 从前面的例子看，一块通用的 Harness 能保持价值的时间，大概只有一两代模型，也就是一年左右。这不代表它不值得做：提前一代用上某种能力，在这个行业里就是实实在在的时间窗口。只是我不会再为它投入需要两三年才能回本的工程量。如果发现自己为了绕开模型的某个缺陷，已经写了成千上万行代码，我会先停下来，想一想是不是方向错了。
第二，加补丁的时候，同时留下一个可以重跑的失败案例。 案例要具体：「模型不够主动」没有用，「改完三个文件之后没有跑 check 就报告完成」才有用。新模型发布后，带补丁和不带补丁各跑几遍，不带补丁也能通过，就把它删掉。写给 Agent 的说明文件和 Skills 也一样，隔一段时间就应该清理一遍，而不是只加不减。
删不掉的补丁同样有信息量。很常见的一种情况是「请先向用户确认再执行」，它其实说明权限检查没有在程序里实现，只能写给模型看。这样的补丁不应该删，而应该从提示词移到代码里。
这组案例还有一个用途。我们依赖的平台本身也在变化：Claude Code 那次更新只是一次普通的版本升级，升级之后，Agent 可用的工具就少了五个。底层的模型或平台更新之后，在我自己的任务上是变好了还是变差了，也只能靠这组案例来回答。
第三，把长期的投入放在协作机制和只属于自己的上下文上。 权限、状态、交接、反馈，这些是人和 Agent 一起做事的长期需求，实现可以换，需求不会退场；上下文则是个人的、组织的、企业的。会被学走的，是几百万用户共有的行为：跑测试、不跑偏、正确使用工具。正面去做一个通用 Agent，没有数据也没有入口，模型一更新，价值就会缩水，这条路我一直不看好。
学不走的，是只属于你、你的组织或企业的上下文：行业里具体的工作方式，团队做过的决定，用户的习惯。这个定时任务为什么设成每小时一次，是为了节省成本，还是因为上游有限流？这些不在任何人的训练数据里，模型再强也推断不出来。智能可以租，上下文只能自己积累。
这也是为什么我认为垂类做得越深，越应该主动接入通用 Agent：把你的 know-how 做成 MCP、插件或者 Skill，接到别人已经在使用的 Agent 上，底层怎么更替都不受影响。前面说 Skill 最后剩下的价值是方便传播，指的就是这种用法。
最后：说回「泄气」#
回到 Gergely 的那句话：今天做的东西，下一版模型自己就会了，让人有点泄气。
我理解这种感受。但它背后有一个没有说出来的前提：一份工作的价值，取决于它产出的代码能存活多久。按这个标准，这一行确实让人泄气，因为模型外面的代码注定存活不了多久。
我不这样衡量。我在模型外面做的东西被模型学走了，说明这件事做对了，说明我比模型早一代看到了这种能力应该是什么样子。代码会被删掉，但「早一代看到」的经验会留在我身上，它还决定了我能不能看到下一个问题在哪里。亲手做过前一个问题的人，最先知道它什么时候稳定了，也最先遇到协作范围变大之后的新问题。
视频的最后，Thariq 问另外两位同事是否怀念过去写代码的方式。其中一位说，他以前喜欢打磨 UI 细节，曾经花一整天叠加径向渐变，只为在个人网站上复刻 Mac OS 10.4 的 Aqua 按钮，现在他不会再手工做这样的事了。但他接着说，这让他想起七八岁时想做游戏却不会写代码，只能用 PowerPoint 拼出可以点击的形状；而现在，整个软件工程对他来说都触手可及，不必再因为自己不掌握某项技术就放弃一个想法。
失去的是在某一件事上打磨到极致的手艺，得到的是去做更大的事的能力。
当然，如果你的整个产品只是一块通用补丁，除此之外什么都没有，那么泄气是合理的。它是一个很准确的信号：你的斜率已经落后于模型，该换到更大的协作尺度上去，或者往垂类里再深入一层。这句话也是说给我自己的。
所以对 Tibo 的那句话，我的看法是：在他说的核心 runtime 那个范围里，他是对的，补丁会被模型追上，该删就删。但 Harness 不只是教模型做事的那一部分。变小的是已经完成使命的补丁；人和 Agent 之间的协作机制一直在变多：一个用户和一个 Agent，一个团队和他们的 Agent，一个组织和它所有的 Agent。你把力气花在哪一部分，增长得有多快，决定了你的产品是在被模型取代，还是在被人需要。
如果你手边正好有自己的项目，可以用那个问题检验一下：假如模型已经足够聪明，这一块还有没有存在的必要？如果没有，它退场的时候，背后的需求会由谁来接？欢迎来 QQ 粉丝群讨论： ，群里的那个 Agent 也可以直接 @。
参考#
- The Pragmatic Engineer：Building Codex with Tibo Sottiaux ↗
- Claude Code 团队内部对谈：How the Claude Code team uses Claude Code ↗
- Boris Cherny 在 YC Startup School 2026 的分享：逐字稿 ↗ / 视频 ↗
- Claude Code v2.1.233 release notes ↗
- Skills：obra/superpowers ↗、mattpocock/skills ↗
文中对播客和视频内容的引用均为按原意概括，不是逐字引用。第四节涉及的价格和授权信息变化较快，请以各家官方页面为准。