这六篇里如果只能记住一句话，我选这句：换个更强的模型，不代表你的 Agent 就好用了。

模型是发动机，Harness 是套在它外面的那整套传动和控制。发动机再猛，没有变速箱和方向盘，车也上不了路。关键在于，发动机决定能跑多快，传动和控制决定跑不跑得成。

六篇拆的其实是同一个问题的六个面

第一篇讲是什么，第二篇拆 DSH 的架构，第三篇看执行循环怎么转，第四篇上实测数据，第五篇讲自进化，第六篇抬头看生态。

排这个顺序是刻意的：先有概念，再拆一个真的，然后看它动起来，接着量化它值多少分，最后看它能不能自己变好、生态里怎么选。

为什么从「马具」这个词讲起？因为 harness 最早就是马具——缰绳、马鞍、笼头那一整套。没套马具的马跑得再快也只是脱缰的野马，套上之后，力气才变成可控的前行。

这个词的语义到今天没变过：把强大但可能失控的东西纳入控制。大模型就是那匹好马，缺的是外面的马具。

为什么说模型有四个天生短板？

第一篇里我把模型的短板排了一下：缺感知，它只认喂进去的文字；不能动，它只会输出文字，变成动作得有人执行；没记忆，每次调用都是独立的；会瞎编，它不保证对错。

Harness 存在的本质就是补这四个洞——它不提高模型的智力，只补它缺的那几样。拆开看是五个子系统：指令、工具、环境、状态、反馈，落到关键词只有三个，约束、反馈、稳定。

这里有个区分对团队推广特别关键：Harness 其实有两层。厂商那层叫 Builder，系统提示词怎么设计、安全边界设在哪，你介入不了；你自己那层叫 User，工作目录怎么组织、规矩怎么定，归你管。

厂商那层动一次，可能某个业务场景就悄悄变差了，你几周后才从员工的抱怨里知道。

别盯着模型，先盯着循环的三本账

第三篇讲的是 Harness 里最像心脏的部分：执行循环。

循环怎么转、什么时候停，决定长任务是跑完还是跑偏。有三个控制动作——带新证据继续、转到统一收尾、直接结束；四类退出——正常回答、用户中断、预算耗尽、护栏拦截。

我现在的习惯是长任务开跑前先定三样：停止条件写死，预算按 Agent 分开算（父子各自计数，不是整树共享），每 N 轮强制对账一次，只看当前证据和原始目标还对不对得上，对不上就停，人接手。

循环转得好不好，看三个信号：证据每轮有没有新增，没有新增就是在空转；指令有没有跟着证据变，没变说明在偷懒；预算消耗和进度匹不匹配。

第三篇里还有个数据挺说明问题：有个评测把 Coding Agent 拆开测，Worker 固定只换指挥，27 道仓库级题每题跑 3 次，最好的指挥成功率不到 25%。会写代码和会指挥，确实是两回事。

实测那篇把话说死了：同模型换壳差 55 分

第四篇是这六篇里最有分量的，因为它上的是实测：10 个 Coding Harness 分别搭载两个模型，从零做一个原生 iOS App，20 个运行案例，两轮独立复测。

结果从 40 分到 95 分，7.86 亿 token 花了 126 元。最终结果至少取决于四个乘数——模型、Harness、工具环境、验证体系。

模型定下限，壳定上限。说到底，这不是换个更贵的模型就能补上的差距，而是壳的差距。我用 Claude Code 接 DeepSeek 的时候总有种隔了一层的感觉：它下意识按 Claude 的思路来，任务一复杂就容易绕。换成 DeepSeek Harness，同样的活体验就不一样。

那篇里还有个国产例子我挺喜欢：蜂群拆任务并行干，加上自进化越用越懂你。它接的两个活——每天自动抓岗位出候选池报告、把散在各处的信息攒成一份旅游手册——用的都不是最顶级的模型，但闭环完整：需求确认、自动执行、人工拍板、结果推送。

但自进化还差两步

第五篇讲的是最有想象力也最虚的一段：让 Agent 改承载自己运行的系统。

进化是分阶梯的：最早改提示词，调措辞换例子；然后改工作流；再往上是改脚手架代码；到顶是端到端改整个 Harness。四级台阶，越往上越难验。

DSH 已经给了自我修改的底座——组件可定位可替换、能热重载、能彻底删除。但离真正的自进化还缺两样：一样是学习循环，回答「怎么改」；一样是评估基准，回答「改得好不好」。

现在的状态是第一步做完了，刻度还没建起来。所以我的建议是先上手玩，别在生产要害上 All in——版本还是开发者预览，官方明说未来会有破坏兼容的变更。

选型只剩三个问题

第六篇抬头看生态，三条路线摆在桌上：成品全家桶，以任务为入口，桌面、终端、插件、云端、手机全包；开放底座，给你积木自己搭；论文级通用架构，研究下一代执行语义。

三条路线的差别不在功能多少。成品赢在现在，开箱即用；底座赢在以后，能改能换；论文路线赢在可能性。

300 行代码就能重建一个最小循环，这话听着吓人，对用的人是好事——牌面公开了，选型不用玄学。我自己的顺序是四步：先问场景，赶活还是搭底座；再问团队，有没有人玩得转，没人就先上成品；然后问长短，要短期结果还是要长期复利；最后小步试，先跑通一个完整闭环再铺开。

模型会继续变强，但组织能力的差距只会越拉越大。这句放在最后，因为它是这六篇的落点：别问模型什么时候变强，问你的壳能不能改、敢不敢改、改完能不能验。

如果你打算动手，我的建议是从最小闭环开始：挑一个每天都跑的小任务，把停止条件和验收方式写清楚，看它能不能自己跑完三次。这一步值得花一周时间，比先挑框架划算得多。