最近AI工具圈出现了一个有意思的变化。

大家以前讨论的是：怎么写skill，怎么给Agent增加更多Skill。

现在，越来越多团队开始讨论另一个词：Harness。

这背后其实是一个很大的变化：Agent正在从“会回答问题”，变成“需要持续完成任务的软件系统”。

1️⃣ Skill和Harness，解决的不是同一个问题Skill更像一份任务说明。它告诉Agent，遇到某类问题时应该怎么处理、调用哪些工具，以及最后输出什么结果。

举个例子。当你写完一篇关于DeepSeek涨价的文案之后，想做一张4:3横图，放在小红书正文里。这时，可以自己写一份“科技文章配图Skill”，告诉Agent：先从文章里提炼一个能被看懂的判断，不要把整篇文章缩成一张海报，再挑出支持这个判断的两三组数据，并标明单位、时间和数据类型。如果文章同时讨论API和订阅，就把两者分成两个区域，不能混在一张账单里。画面采用左右对比，底部补充实际使用场景；最后输出图片标题、图内文案、数据来源、4:3版式草图，以及正文中的配图说明。如果价格缺少单位、来源日期不清楚，或者API和订阅的口径无法对应，就标记为“待补证据”，不能自行猜一个数字填上去。

它解决的是：遇到类似任务时，Agent应该先提炼什么、怎么组织信息、最后交付什么？

2️⃣ Skill的问题，是每次都要重新理解这份配图Skill看起来已经写得很详细了，但真正执行时，仍然可能出现问题。

比如，Agent找到了DeepSeek的新旧API价格，却把“每百万Token”的价格和包月订阅放在同一张表里比较。或者，它记得写涨价前后的数字，却漏掉了“输入Token”和“输出Token”的区别。

也可能图片已经生成了，底部却没有标注人民币单位，读者根本看不懂255元到底对应什么。

你提醒它之后，它再回头修改。

修改过程中，它可能又换了一套数据来源；重新排版时，又把原来标注好的日期删掉了。

这不是Skill完全没用，而是它本质上仍然是一段需要模型重新理解的文字。

它可以提醒Agent“应该核对来源”，却不能天然保证每个数字真的被核对；可以要求“输出4:3横图”，却不能自动判断最终图片是不是4:3。

Skill解决的是方法，不能独立承担交付。

它通常不负责：• 保存任务进行到哪一步；• 管理搜索、排版和绘图工具；• 检查图片和正文数据是否一致；• 处理生成失败或链接失效；• 判断哪些操作需要人工确认。

3️⃣ Harness管的是Agent的整个工作过程如果Skill像一份内容制作规范，Harness更像一个真正的制作工作台。

它不只是告诉Agent“应该怎么做”，还要负责：• Agent可以访问哪些资料；• 哪些工具可以调用；• 当前任务分成了哪些步骤；• 每一步是否已经完成；• 结果应该如何验证；• 失败后是重试、回退，还是交给人处理。

还是刚才那张配图。如果由Harness来管理，流程可能是这样的：第一步，读取文章，提炼出“涨价后，程序员是否仍然划算”这个核心判断。第二步，调用网页工具，核对DeepSeek官方价格页面，分别记录输入Token、输出Token、缓存价格、订阅价格和发布日期。第三步，生成一份结构化数据表，规定每个数字必须带单位和来源。第四步，调用排版工具，按照4:3横图生成初稿。第五步，用检查器确认图片尺寸、单位、日期、来源和API与订阅的分类是否完整。第六步，如果发现图片里漏了“元/百万Token”，就把任务退回排版步骤；如果原始链接打不开，就暂停任务，等待人工处理。第七步，所有数据和修改记录保存下来，最后再由人确认是否发布。

这里，Skill依然有用。它负责告诉Agent如何提炼观点、如何组织图文信息、哪些错误不能犯。

但真正把搜索、核验、排版、检查和返工串起来的，是Harness。

Skill负责告诉Agent怎么做，Harness负责让它把事情做完。

4️⃣ 国内Harness正在从新名词变成工程层过去，国内Agent项目更常强调模型能力、Prompt技巧和Skill数量。

但最近出现的几个项目，开始把重点放到另一层：如何让Agent在真实环境里持续运行。

DeepSeek开源的DeepSeek Harness。它采用“一切皆插件”的架构，模型适配器、工具注册、会话记录和Agent循环都可以被组合、替换和扩展。Skill只是其中一个插件，不再承担整个Agent的运行逻辑。字节跳动开源的DeerFlow，则直接把自己定义为“Super Agent Harness”。

它把sub-agents、memory、sandbox、tools和skills放在同一个系统里，目标是处理持续几分钟甚至几小时的复杂任务。

ModelEngine团队开源的Nexent，也把Harness Engineering写进了项目定位。

它把工具、技能、记忆、编排、约束机制、反馈循环和控制平面组合在一起，试图让Agent从“能调用工具”走向“可以在生产环境里运行”。

InfoQ整理的小红书Muse和得物推荐团队的实践里，小红书关注的是需求、设计、编码、测试和交付之间的上下文如何连起来；得物则用PDCA、工程护栏和混合Agent架构，区分哪些问题应该固定流程处理，哪些问题可以交给Agent探索。

量子位对灵犀智涌ROSS Harness的报道，则把这套思路放到了具身智能场景：模型、Skill、任务编排、安全监控、异常恢复和数据沉淀被放到同一套执行体系里。

这些案例目前主要来自媒体报道，不能据此推断整个行业已经形成统一做法，但它说明Harness的讨论正在从AI编程扩展到机器人等复杂任务。

这些项目的共同点，不是放弃Skill，而是把Skill放到了更大的执行系统里。

国内Harness的发展还谈不上形成统一标准，但方向已经比较清楚：Agent产品的竞争，正在从“谁有更多能力”，转向“谁能把这些能力稳定组织起来”。

5️⃣ Skill不会消失，但它会被重新赋予新的职责Skill仍然适合处理具体、可复用的任务。

比如前面那份“科技文章配图Skill”，可以规定如何提炼观点、筛选数据、组织版式，以及最后输出什么内容。

但当任务需要查资料、核数据、生成图片、检查尺寸、处理链接失效，最后还要等待发布确认时，单个Skill就不够用了。

这时，Skill负责提供方法，Harness负责安排执行。

它会决定先调用什么工具，下一步加载哪些上下文，哪些结果必须验证，失败后是否重试，以及什么操作需要人工审批。

所以，Skill并没有过时。真正过时的，是“多写几个Skill，就能解决复杂Agent任务”的想象。

当任务只是“把一篇文章整理成配图”，Skill可能已经够用。

但当任务变成“查资料、核数据、生成图片、检查结果、处理失败，最后等待发布确认”，单个Skill就明显不够用了。

Skill是能力模块，Harness是执行系统。

未来Agent产品的竞争，可能不再是谁的Skill库更大，而是谁能把工具、上下文、权限、验证和恢复机制做得更稳。