Skill 不够了，Agent 需要拼“生产系统”

本文来自微信公众号： AIGC从0到1 ，作者：王零壹

最近常能听到一种说法：Skill要被Harness替代了。

Skill没有要退出。它解决的问题依然存在，而且会越来越重要：怎样把一个团队做事的方法、行业里的经验、某个岗位的流程，交给Agent，并且让它在合适的时候拿出来用。

真正被证明行不通的，是另一种更朴素的想法：把正确步骤写进一份Markdown，Agent就会照着把事情做完。

很多用过Coding Agent的人，应该都碰到过类似场面。你写了一份很认真的规范：改数据库之前先备份，跑测试，检查schema，执行migration，最后再看日志。Agent也许读过了，但它仍可能觉得“改动不大”，跳过测试；也可能在缺少一个参数时自己猜；还有一种更常见，它完成了一半，语气很笃定地告诉你“已经处理好了”。

这件事有点像给一个新同事一本SOP。SOP很有用，但它不能替代权限、复核、测试环境和交接制度。尤其当这个同事可以同时打开十个系统、连续工作六小时、还会在不确定时自己找路时，只给一本手册，多少有点不放心。

Harness讨论的就是这部分。

模型提供理解、推理和生成。Skill提供某一类工作的经验。Harness则把模型放进一个能干活的环境里：给它文件、工具和记忆，规定它能进入哪些系统，在高风险操作前卡住它，给它看得见的验证结果，并且在它迷路、超时或做错时留下一条能回去的路。

它听起来很工程化，确实也是。Agent一旦从“帮我写一段”变成“把这件事办完”，产品竞争就会被推到这里。

一、一份Skill，为什么不等于一项能力

先说Skill为什么会火。

大模型的上下文再长，也不可能把一家公司的所有经验都放在里面。代码规范、产品原则、内部工具说明、合规要求、项目历史、常见事故，什么都塞进去，模型首先会被信息淹没。早一点接触Agent的团队，大多都经历过这种过程：一份`AGENTS.md`或`CLAUDE.md`起初几十行，后来越来越长，最后像一本很少有人完整读完的员工手册。

文件一大，问题不止是token多。真正麻烦的是，过时的规则和当前任务混在一起，模型很难判断什么该优先；人也很难维护。它看上去像知识库，实际上常常是一座小型规则坟场。

Skill的思路好很多。它把经验拆开，按任务装进不同的包里。做代码审查时加载代码审查的流程和脚本；做研究时加载检索与核验的方法；处理特定业务时，再去取相应的规则和模板。Anthropic把这种按需展开的方式称为progressive disclosure，意思很简单：别在任务开始前塞给模型一整个图书馆，先给它目录，等它走到相关问题时再打开那本书。

这是Skill最实际的价值。它把“这类事通常怎么做”变成了可以复用的东西。

所以我不太认同“Harness出来后，Skills就没价值了”的说法。Skill会越来越像Agent世界里的package。它可能是Markdown，也可能带着脚本、模板、数据源说明和小工具。格式越标准，复用范围越大。对个人开发者、小团队和垂直领域来说，这仍然是一种很有用的能力封装。

问题出在另一头。

Skill能告诉Agent正确方法，却很难保证Agent真的照做。因为对模型来说，一条写在文本里的“必须”，和用户在下一轮临时提出的要求、工具返回的一段内容、它自己刚刚形成的判断，都会一起进入上下文。它会权衡，也会遗漏，还会自作主张。

短任务里，这种不可靠通常能忍。写错一封邮件，人工改一下就好。任务拉长之后，事情开始变样。

一个Agent修改多个模块时，漏掉一次测试，后面几步就可能都建立在错误前提上。它跨系统找数据时，某个字段理解错了，最后给出的报告仍然可能写得很好看。它遇到失败后如果没有明确的停止条件，就容易在一个无效路径上反复尝试，消耗时间和token，还让人不容易看出它到底卡在哪儿。

这时我们真正想问的已经不是“它知不知道该怎么做”。而是：系统能不能让关键步骤发生，并且知道它们有没有发生。

二、Harness到底管了什么

Harness常被译成“挽具”，这个词有点别扭，但比“框架”更接近原意。它不是又一个插件，也不是某个比Skill更高级的Skill。它是一整套把模型拴进现实工作里的运行装置。

LangChain对它有个很直接的说法：模型之外，所有用来让模型成为Agent的代码、配置和执行逻辑，都属于Harness。这个边界确实很宽。系统提示词、工具、MCP、文件系统、浏览器、沙箱、状态管理、子Agent、hooks、验证和日志，都可能在里面。

不过，普通读者没有必要把这些名词背下来。把它想成一个工作台会更容易。

模型坐到工作台前，首先要拿到材料。它应该看到哪份文档，历史任务留下什么，工具返回的长内容如何保存，工作做到一半后怎样接上，这是上下文和状态的问题。

然后是手边有什么工具。它能不能运行代码，能不能调用浏览器，能不能读取内部数据库，工具做完之后会回传什么，这些会直接影响它能不能判断下一步。很多Agent失败，并非模型完全不会推理，而是它面对的是几个模糊按钮，点完以后也看不清发生了什么。

接着是边界。写一段文案、修改测试环境、删一张生产表，显然不该用同一套权限。Harness要做的，是让系统在该放行时放行，在该确认时确认。它不是“提醒Agent注意”，而是让某些动作没有权限就根本走不下去。

最后是验证和恢复。代码改完了，要跑测试；页面改完了，要能打开看看；一笔数据写入后，要确认目标记录真的存在；报告里的引用，要能点得开。模型说“完成”没有太大意义，系统能观察到结果才有意义。失败时也一样：是可以重试，应该回滚，还是该把问题交给人，最好不要临场凭模型心情决定。

还是拿migration举例。

Skill可以写：备份、测试、检查schema、执行、复测。

Harness可以把其中一些步骤变成过不去的门：没有备份记录，不能进入下一步；测试没过，不允许提交；碰到生产库，权限自动收窄并要求二次确认；调用中断后，系统根据任务状态和幂等键判断能不能再试一次。

差别并不神秘。一边是“希望它记得”，另一边是“系统会检查”。

2026年7月30日，一篇叫SIGIL的预印本论文做了一个很直白的对照：同一套流程，分别写成自然语言Skill，和编译成带类型与前置条件的Harness。在那组实验里，前者完成规定步骤的比例是56%，后者是86%。完整流程完成率也更高，token用得更少。

这还不足以得出“所有Skill都应该编译成Harness”的结论。论文很新，任务范围也有限。但它把一个大家已经隐约感到的问题测出来了：写在说明里的步骤，是软约束；真正被检查和阻塞的步骤，才更接近工作规则。

8月5日的Skill-Use benchmark又补了一层证据。研究者发现，同一个Skill、同一个模型，换一套Harness，表现会明显变样，模型之间的排名也可能跟着变化。

于是，“哪个模型最会用Skill”这句话开始显得不够完整。更接近现实的问法是：这个模型放在这套环境里，能不能把这份Skill用出来。

三、为什么到了2026年，大家突然开始谈Harness

其实每个Agent产品一直都有Harness。

聊天记录怎么保留，工具怎么被调用，模型输出后要不要再跑一次循环，这些都是最早期的Harness。只不过以前大家把它当作模型外面那层不太起眼的胶水。现在，胶水开始决定产品能不能站住。

最直接的原因，是Agent被交给了越来越长的活。

模型只回答一个问题时，出错了就重新问。Agent连续跑几个小时就不一样了。它会跨多个上下文窗口，要读文件、执行代码、修改结果、再看反馈。中途的状态放在哪里，任务进度谁来记，换一个Agent是否看得懂前一段工作，错误怎样恢复，不能再靠一段聊天记录凑合。

Anthropic在长程Agent的工程实践里谈的内容，就很能说明这一点。他们关注的不只是提示词怎么写，而是初始化Agent、进度文件、feature list、Git状态和增量验证。听上去像传统软件工程，甚至有点笨。但做过复杂项目的人都知道，很多看起来笨的东西，正是为了不让人半路忘记自己在干什么。

Coding Agent进入生产环境后，这件事更明显。

OpenAI今年2月写过一篇很有意思的内部实践。他们让一个小团队用Codex做出一个有真实用户的产品，五个月里大约产生了百万行代码和1500个PR，人工不直接写代码。数字是OpenAI自己的估算，不能直接外推成行业速度，不过文章里最值得看的不是“百万行”，而是他们前期为什么慢。

答案是环境没有讲清楚。

后来他们做的事，几乎都和让Agent看懂工作现场有关：每个worktree可以启动独立应用；Agent能查看浏览器、DOM、截图、日志和指标；代码库里的文档、计划、质量要求被整理成可检索、可校验的资料。那份巨大的`AGENTS.md`也没有留下来，变成了一张短目录，真正的内容被拆进文档和工具里，由CI、linter和其他Agent共同维护。

这很像一个变化中的工程师角色。过去，工程师主要把正确代码写出来；现在，一部分工作变成把环境整理得足够清楚，让Agent能找到资料、运行验证、理解失败，然后继续干下去。

还有一个产业层面的原因：Skill正在变得可移植。

这本来是好事。经验不必锁死在某个产品里，团队不用在每个Agent上重写一遍SOP。可一旦格式变成标准，格式本身也就很难继续构成壁垒。未来“支持500个Skills”可能会像“支持Markdown”一样，只是基础能力。

到那个时候，差别落在很具体的地方：系统会不会在对的时刻找到对的Skill；模型读完之后是否有足够上下文；关键步骤有没有被验证；失败时是否会留下可用的痕迹。

这也是为什么同一个前沿模型，放在不同Coding Agent里，使用感常常像两个产品。有的会自己跑测试、看报错、继续改；有的写出一段看起来没问题的代码就停了。模型当然有差异，模型周围的工具、状态、反馈和约束也有差异。

LangChain曾说，他们只优化Harness，就把一个Coding Agent在Terminal-Bench 2.0上从30名以外做到了第5名。这是厂商自己的表述，应该谨慎看待。但它至少说明了一件事：模型能力进入可用区间以后，围绕模型的系统仍有很大的优化空间。

四、价值会往哪里走

如果这件事继续发展，Skill商店当然还会有位置。它会是分发层，也会是经验流通的地方。就像模板市场、插件市场一样，有些人会因此赚到钱。

但单独的一份Skill，大概率很难变成很厚的长期壁垒。它可以被复制、改写、迁移，甚至被更强的模型自己生成。真正难复制的，通常不是“这份SOP写得多完整”，而是你到底知不知道这份SOP在真实工作中会在哪一步失效。

我更愿意把垂直Agent的机会放在这里看。

做法律Agent，难处不只是写一份“如何检索法条”的Skill。它要知道不同法域该查什么，什么时候存在利益冲突，哪些材料绝不能带出企业，引用怎么核验，结论该在哪个节点交给人复核。

做财务Agent，也不是把读报表的方法塞进去就够了。对账怎么做，异常项何时升级，谁能批准，凭证怎么留，最后如何回溯，才是企业愿意接入它的前提。

这些事看起来不像模型能力，甚至有点琐碎。可它们决定的是：这个Agent在公司里是一个随时要盯着的演示品，还是一套可以交班的工作系统。

所以，下一批有价值的Agent资产，可能不在某个漂亮的Skill文件里，而在真实任务留下的失败记录、验证标准和业务整合里。

团队如果知道Agent经常在哪儿误判，怎么补救；知道什么算完成，什么只是看起来完成；知道怎样把权限、数据和审批接进来，它做出来的就不只是一个会回答问题的产品。

这也是“垂直Harness”比“垂直Skill”更有意思的地方。前者要求你理解一个行业实际怎么运转，后者有时只要求你知道这个行业怎么说话。

五、企业最后买的，是一套敢把活交出去的条件

企业试用Agent时，最开始总会问它能不能连接某个系统：能不能读合同，能不能连CRM，能不能改Salesforce，能不能帮开发团队写代码。

这些问题到了生产阶段，很快就会变味。

谁授权它查看客户？它能改字段还是只能读？批量操作是否允许？它发过哪些请求，调用了哪个Skill、哪个工具、哪个模型？一封邮件发错了，一批数据改错了，能不能把过程还原出来？员工离职或任务转交时，权限如何收回？

企业不一定需要最聪明的Agent。很多时候，它们更需要一个边界清楚的Agent：知道什么能做，什么必须等人点头；知道何时停；做完后能拿出证据。

这会让Agent的成本结构变得更像软件基础设施。Token只是其中一项。还要算沙箱、工具集成、日志和trace、评测、知识维护、安全扫描、权限治理、审批和运行维护。

这些投入看起来不够性感，却是Demo和生产系统之间最真实的那段距离。很多企业最终会发现，自己缺的不是又一个聊天入口，而是一套共用的Agent Runtime：各部门在上面接自己的知识、工作流和Skills，底下有统一的权限、日志和策略。

这也是Agent Control Plane开始被频繁提起的原因。它不是为了再造一个大后台，而是为了让组织至少知道，AI正在替谁做什么。

六、别把Harness也想得太美

Harness不是越厚越好。

把subagent、MCP、memory、planner、hooks、evaluator、retry、sandbox全都堆上去，很容易得到一个谁也维护不明白的系统。出一次问题，团队可能要花很久判断到底是模型错了、工具错了、策略错了，还是某个Agent之间的交接出了问题。有人把这种风险叫作“AI Kubernetes”，这个比喻虽然有点刻薄，倒也不算冤。

它也会带来成本。多Agent编排、反复验证、重试和大规模上下文都要消耗token与计算资源。Anthropic的多Agent研究系统就展示过这种两面性：复杂任务的效果会提升，消耗也会比普通对话大得多。更自主不必然更便宜。

还有过拟合。一套为某个benchmark、某个代码库、某一代模型打磨出来的Harness，可能换了任务就失灵。模型变强后，上一代留下的补丁甚至可能成为干扰。今天被奉为秘诀的上下文技巧，明天也许只是噪音。

Skill的安全问题同样会被放大。Skill里可以有脚本、外部依赖和工具调用。“安装一个Skill”越来越接近安装一个可执行包，不能只看介绍写得有没有道理。来源、版本、权限范围和安全扫描，都会变成正常流程。

所以，团队最好先问任务本身，而不是先问要上多少层Agent。

写生日祝福，风险低，用户自己一眼就能看出来好不好，薄一点的Harness完全够用。

让Agent修改线上服务，事情复杂得多，但测试和回滚相对明确，需要更完整的工具、验证和权限边界。

付款、医疗、金融交易、生产部署则是另一类任务。它们的共同点是不可逆，或者很难补救。这里需要的不是让Agent更放飞，而是让审批、事务、回滚和审计先站好。

自动化走多远，不该由模型演示有多惊艳来决定，而应当由任务风险和结果可验证性来决定。

七、模型更强以后，Harness会不会淡出

会有一部分淡出。

模型越来越会规划、反思、调用工具和管理上下文。过去需要手工塞进去的计划提醒、prompt小技巧、一些压缩策略，确实会慢慢失去价值。模型训练时也会吸收一部分今天还写在外部脚手架里的经验。

但这并不意味着Harness会消失。

一个非常聪明的人进公司，也仍然需要权限、代码审查、数据库事务、财务审批和审计记录。它们不是为了弥补这个人笨，而是为了让组织知道边界在哪里，责任由谁承担。

Agent也一样。

我更倾向于认为，Harness会发生迁移。帮助模型补认知短板的那部分会变薄，围绕现实世界行动的那部分会变厚。未来更重要的Harness，可能不再是教模型怎样一步步想，而是规定它能碰什么数据、在哪些动作前必须停下、结果要怎么验证、出了问题怎样撤回。

这也是为什么Harness不只是Coding Agent的话题。只要Agent真的开始进入业务，它都会遇到同一类问题。

Skill的出现，让很多团队第一次有机会把经验交给Agent。它把散落在人脑、文档和聊天记录里的做法，变成可加载、可复用的能力包。这一步没有白走。

只是走到今天，大家开始发现，经验被读到，离经验变成结果，中间还隔着很长一段路。

那段路里有工具，有状态，有验证，有权限，也有每一次失败后留下的痕迹。它们凑在一起，才是Harness真正的价值。