先说观点Agent能力并不等于模型能力。模型决定能力的上限Harness则决定任务的交付。DeepSeekHarness它其实是一个开源框架设计理念是“EverythingisaPlugin”简单理解就是上下文、工具和工作流程都可以通过插件来组合。图DeepSeekHarness开发者预览版页面为什么现在模型能力越来越强反而大家都去搞模型外边的Harness呢Harness原本是“马具、挽具”的意思。放到Agent里理解就是把模型、上下文、工具和执行环境“套”在一起。如果一定要类比它有点像Agent的操作系统。一开始我也不太相信模型外面这层东西能有多大影响。但是LangChain团队在2026年2月做过一次实验。他们固定使用GPT-5.2-Codex没有改模型权重只调整外面的系统提示、工具和中间件Terminal-Bench2.0的成绩就从52.8提升到66.5排名也从30名开外进了前5。图LangChain《ImprovingDeepAgentswithHarnessEngineering》2026年2月这组数据最让我意外的是只改模型外面的东西差距就能这么大。平时只盯着哪个模型更强很可能漏掉了真正影响任务表现的另一部分。拿“帮我做一个网页版俄罗斯方块”来说如果只是聊天模型它通常只会给我一段代码。Codex这类Agent还会进入项目目录、创建文件、启动服务然后打开浏览器看结果。这张图基本把中间的过程说清楚了图网页版俄罗斯方块任务中Model与Harness的简化分工模型会判断下一步做什么Harness就把这个判断变成操作再把报错和页面反馈送回来。模型接着改Harness再执行。它们就是这样一轮一轮往下跑。比如第一轮模型只知道我要做俄罗斯方块它会先判断应该看看当前目录。真正去扫描文件、读取内容的是Harness。目录结果回来以后模型才知道这里是一个空文件夹还是已经有了一个网页项目然后决定新建文件还是接着修改。写完也一样。模型提出要启动服务Harness去执行浏览器打不开端口报错或者页面样式跑偏这些结果再被送回来。模型本身并不直接操作我的电脑它根据当前拿到的上下文做判断再由Harness调用相应工具执行。图Codex中模型、Harness和外围能力的关系示意Skill、MCP和沙箱也都在这个循环里只是各管一块。Skill像操作手册MCP负责连接外部服务沙箱给Agent划出一个能干活的范围。Harness把这些东西接在一起。这里还有一个很容易被忽略的东西就是上下文。Agent不可能把电脑里的所有文件一股脑都塞给模型它得知道这一轮该给模型看什么是项目规则、相关代码、刚才的报错还是前面已经做过的修改。给少了模型不知道发生过什么给太多了真正有用的信息又容易被淹掉。模型明明会写为什么还是会翻车麻烦也出在这里。俄罗斯方块的代码写完了游戏却不一定真的做好了。有时Codex刚创建完HTML、CSS和JavaScript就告诉你任务已经完成可页面根本没有打开过。还有时候页面能显示但方向键没反应重新开始按钮也是坏的它仍然会说“测试通过”。模型本来有能力把游戏写出来只是Agent太早停了。Harness如果没有要求它启动项目、操作页面、对照验收标准检查它就很容易把“代码写完”当成“事情做完”。它不一定是在故意虚标。站在模型的角度文件已经生成代码看起来也完整眼前又没有新的报错它很容易判断任务到这里就结束了。问题是外面没有一道真正的完成门槛。如果Harness规定得更细情况就不一样了。页面必须成功打开方向键要实际按过分数变化和重新开始也得测试几项都通过以后才能宣布完成。反过来如果Agent围着同一个错误改了很多遍Harness也要能发现它在原地打转提醒它换办法或者停下来找用户确认。LangChain在前面的实验里也提到过类似问题Agent写完代码重新读一遍觉得看起来没问题就结束了。后来他们加入规划、构建、验证、修复的流程还增加了完成前检查效果才上去。我现在再看一个Agent已经不太会只盯着它用了什么模型了。我更关心它出错以后会不会接着改以及它说“完成”之前到底有没有真的测过。普通用户其实不用研究很多底层术语给它一个需要连续做几步的真实任务很快就能看出来。让它做网页也行让它把本地文档备份到飞书也行。中间只要碰到权限确认、跨平台调用或者执行失败就能看到它会不会把任务接着往下做最后又会不会重新读取结果确认东西确实已经交付。模型升级很容易被看见产品会直接把新模型名字写出来。Harness的变化往往藏在小地方比如出错后能不能换个办法完成以后会不会真的回头检查。单看聊天时可能感觉不明显任务稍微长一点差距就出来了。所以有人说Codex、WorkBuddy只是给大模型套了一个聊天界面我觉得不太对。聊天界面只管把话传进去、把答案显示出来Harness还要管这件事到底有没有做完。对用户来说最后看的就是这个。
先说观点Agent能力并不等于模型能力。模型决定能力的上限Harness则决定任务的交付。DeepSeekHarness它其实是一个开源框架设计理念是“EverythingisaPlugin”简单理解就是上下文、工具和工作流程都可以通过插件来组合。图DeepSeekHarness开发者预览版页面为什么现在模型能力越来越强反而大家都去搞模型外边的Harness呢Harness原本是“马具、挽具”的意思。放到Agent里理解就是把模型、上下文、工具和执行环境“套”在一起。如果一定要类比它有点像Agent的操作系统。一开始我也不太相信模型外面这层东西能有多大影响。但是LangChain团队在2026年2月做过一次实验。他们固定使用GPT-5.2-Codex没有改模型权重只调整外面的系统提示、工具和中间件Terminal-Bench2.0的成绩就从52.8提升到66.5排名也从30名开外进了前5。图LangChain《ImprovingDeepAgentswithHarnessEngineering》2026年2月这组数据最让我意外的是只改模型外面的东西差距就能这么大。平时只盯着哪个模型更强很可能漏掉了真正影响任务表现的另一部分。拿“帮我做一个网页版俄罗斯方块”来说如果只是聊天模型它通常只会给我一段代码。Codex这类Agent还会进入项目目录、创建文件、启动服务然后打开浏览器看结果。这张图基本把中间的过程说清楚了图网页版俄罗斯方块任务中Model与Harness的简化分工模型会判断下一步做什么Harness就把这个判断变成操作再把报错和页面反馈送回来。模型接着改Harness再执行。它们就是这样一轮一轮往下跑。比如第一轮模型只知道我要做俄罗斯方块它会先判断应该看看当前目录。真正去扫描文件、读取内容的是Harness。目录结果回来以后模型才知道这里是一个空文件夹还是已经有了一个网页项目然后决定新建文件还是接着修改。写完也一样。模型提出要启动服务Harness去执行浏览器打不开端口报错或者页面样式跑偏这些结果再被送回来。模型本身并不直接操作我的电脑它根据当前拿到的上下文做判断再由Harness调用相应工具执行。图Codex中模型、Harness和外围能力的关系示意Skill、MCP和沙箱也都在这个循环里只是各管一块。Skill像操作手册MCP负责连接外部服务沙箱给Agent划出一个能干活的范围。Harness把这些东西接在一起。这里还有一个很容易被忽略的东西就是上下文。Agent不可能把电脑里的所有文件一股脑都塞给模型它得知道这一轮该给模型看什么是项目规则、相关代码、刚才的报错还是前面已经做过的修改。给少了模型不知道发生过什么给太多了真正有用的信息又容易被淹掉。模型明明会写为什么还是会翻车麻烦也出在这里。俄罗斯方块的代码写完了游戏却不一定真的做好了。有时Codex刚创建完HTML、CSS和JavaScript就告诉你任务已经完成可页面根本没有打开过。还有时候页面能显示但方向键没反应重新开始按钮也是坏的它仍然会说“测试通过”。模型本来有能力把游戏写出来只是Agent太早停了。Harness如果没有要求它启动项目、操作页面、对照验收标准检查它就很容易把“代码写完”当成“事情做完”。它不一定是在故意虚标。站在模型的角度文件已经生成代码看起来也完整眼前又没有新的报错它很容易判断任务到这里就结束了。问题是外面没有一道真正的完成门槛。如果Harness规定得更细情况就不一样了。页面必须成功打开方向键要实际按过分数变化和重新开始也得测试几项都通过以后才能宣布完成。反过来如果Agent围着同一个错误改了很多遍Harness也要能发现它在原地打转提醒它换办法或者停下来找用户确认。LangChain在前面的实验里也提到过类似问题Agent写完代码重新读一遍觉得看起来没问题就结束了。后来他们加入规划、构建、验证、修复的流程还增加了完成前检查效果才上去。我现在再看一个Agent已经不太会只盯着它用了什么模型了。我更关心它出错以后会不会接着改以及它说“完成”之前到底有没有真的测过。普通用户其实不用研究很多底层术语给它一个需要连续做几步的真实任务很快就能看出来。让它做网页也行让它把本地文档备份到飞书也行。中间只要碰到权限确认、跨平台调用或者执行失败就能看到它会不会把任务接着往下做最后又会不会重新读取结果确认东西确实已经交付。模型升级很容易被看见产品会直接把新模型名字写出来。Harness的变化往往藏在小地方比如出错后能不能换个办法完成以后会不会真的回头检查。单看聊天时可能感觉不明显任务稍微长一点差距就出来了。所以有人说Codex、WorkBuddy只是给大模型套了一个聊天界面我觉得不太对。聊天界面只管把话传进去、把答案显示出来Harness还要管这件事到底有没有做完。对用户来说最后看的就是这个。
