DeepSeek 把 Agent 架构之争，降级成了一个配置项

8 月 13 日，DeepSeek 开了一个新仓库。叫 deepseek-harness，MIT 协议，一天时间冲到四万多颗星。

中文这边跟得很快。爱范儿发了首发体验，掘金出了上手指南，凤凰网也报了。怎么装、怎么配、四种模式各干什么，写得都对。

我关心的是 README 里的一句话。它说，每一样能力都是插件，都可以替换或者重新组合。后面跟了一串清单：模型、工具、技能、会话、沙箱、存储、循环、调度、界面。

"循环"也在里面。

Agent 的主循环是一个插件，可以换掉。如果这句话是认真的，那么过去一年多的那场架构辩论，就不用接着吵了。

先说那场辩论吵的是什么

Harness 是模型外面那层壳。

它负责把模糊的需求拆成步骤。决定什么时候调哪个工具。在多轮之间搬运上下文。检查结果对不对。在模型犯错的时候拉住它。

没有这层壳，模型就是一个很聪明、但干不完整活的大脑。这层壳该做多厚，两家公司给了相反的答案。

Anthropic 做厚。一个 agent 拆任务。一个 agent 写代码。第三个 agent 当质检员。三者之间有交接标准。

他们做厚是有理由的。他们发现，让模型评价自己的产出，它几乎总是夸自己。所以评估必须从执行者手里拿走，交给另一个 agent。

OpenAI 的 Codex 做薄。Codex 那层壳是 Michael Bolin 带人写的。他的决定很干脆：只给模型一个终端，别的什么都不给。

他的说法是，壳要尽可能小，模型要尽可能强。给一个沙箱，给一个终端，剩下的让模型自己想。

今年 4 月我写过这场辩论。当时我的看法是，这不是技术问题，是信任问题。你信模型，就做薄。你信流程，就做厚。

我还写了一句话。harness 工程真正的竞争力，不在于今天做厚还是做薄。在于你能多快把不需要的那层拆掉。

现在有人给了这个问题一个我没想到的答案。

两种立场都成了预设

deepseek-harness 提供四种模式。

标准模式是完整的编码 agent。该有的都有：改文件、跑 shell、搜网页、子 agent、计划、工作流。

最小模式只有两个工具。一个常驻的 bash，一个叫 str_replace_editor 的文件编辑器。

没了，就这两个。

最小模式就是 Bolin 那套主张的样子：给个终端，别的不给。而标准模式里那些计划、目标、子 agent，就是 Anthropic 那套主张的形状。

两个吵了一年多的立场，现在是同一个系统里的两个预设。换一个，是改配置的事。

还有第三种，它根本不在厚薄这条线上

第三种叫 code mode。

它把工具通过 SDK 暴露给模型。模型自己写一段程序。多步操作在这段程序里串起来。

这个做法很有意思。厚薄之争默认了一个前提：编排这件事，要么由壳来做，要么由模型在对话里一步一步做。

code mode 说，让模型把编排写成代码。

它不是厚，也不是薄。它把"多步操作怎么组织"这个问题，从壳里挪到了模型的输出里。一条被认为只有两端的线，现在有一个点跳出去了。

可配置不是重点，没有内核才是

到这里会有人说，这不就是把两条路都实现了一遍吗，有什么稀奇的。

稀奇在没有特权内核。

大部分框架都支持插件，但它们有一个核心，插件挂在核心外面。核心不能动。那是框架作者替你做的判断，也是你必须接受的部分。

deepseek-harness 用的内核叫 Cordis。在这套设计里，主循环自己也是挂上去的插件之一。框架作者没有替你留下任何一个"这块你不许改"的位置。

回到我 4 月那个问题。我说竞争力是拆的速度，插件化给的答案是：你不用拆，你换。

拆积木需要先知道哪一块承重。换插件不需要，因为设计上就没有承重的那一块。

代价在哪

这套东西我没有在真实项目里跑够时间，所以下面是猜测。我猜代价在于，谁来保证这些插件配在一起是对的。

厚 harness 有一个好处，这个好处经常被当成缺点骂：它把一套判断写死了。

Anthropic 把评估权从执行者手里拿走，不是随便定的。那是他们观察到模型会自夸之后做的决定。你用他们的框架，就自动继承了这个决定，哪怕你根本不知道有这回事。

全插件化把这个决定还给了你。听起来是好事。

但它同时把"做错这个决定"的可能性也还给了你。一个企业客户拿这套东西搭系统，他很可能不知道该不该把评估器换掉。他甚至可能不知道有评估器这个东西。

4 月那篇里我写过，企业客户问的第一个问题从来不是模型够不够聪明。他们问的是三件事：这个决策能不能回溯，谁批准的，出了事谁负责。

一个可以整体替换的主循环，对这三个问题都不友好。

你把循环换掉之后，之前那批审计记录还成立吗。两个季度前的一次自动决策，是在哪套插件组合下做出来的，有没有地方能查。

这些问题不是没有答案。但答案得有人去写，而它们现在不在框架里。

README 里有一行全大写的警告：会有破坏性变更。这行字很诚实，也说明现在讨论这套架构在生产环境里的表现还太早。

全插件化是一个赌注

README 里还有一句容易被略过的话。它建议你把自己写的插件仓库打上 dsh-plugin 这个标签，方便别人找到。

这句话暴露了这套设计的前提。

全插件化只有在真的有人写插件的时候才成立。

如果没人写呢。那"什么都能换"就等于"什么都得你自己配"。用户拿到的不是自由，是一份没做完的作业。

厚 harness 有个隐藏的好处。它替你做完了几十个决定，而你不需要知道这些决定存在。

插件化把这几十个决定摊开在你面前。摊开是诚实的。但诚实和好用是两回事。

DeepSeek 显然知道这一点，所以它给了四个预设。预设就是替你先配好一套。

有意思的地方在于，一旦预设做得够好，大部分人就永远停在预设上了。对这些人来说，"没有特权内核"跟有内核没区别。

真正吃到这个设计好处的，是那一小撮愿意自己动手的人。

前端那边在往同一个方向走

同一周，Latent Space 采访了 Fred Schott。

他是前端框架 Astro 的作者。他刚给自己那个叫 Flue 的项目加了 hooks，做法照着 React 抄。他说了一句话：agent 是由它的 harness 定义的。

一个做前端框架的人，和一家做模型的公司，在同一周说了同一件事的两面。

harness 正在从"模型外面的辅助结构"，变成"agent 这个东西本身的形状"。如果 harness 就是形状，那它当然应该可以整个换掉。

四万颗星里，会去换主循环的人有多少

那个数字一天就到了。

但大部分点星的人不会去改 loops 插件。他们会用标准模式，跟用 Claude Code 差不多。真正会去换主循环的人很少。

这件事的意义不在于多少人去换。在于从现在开始，厚还是薄不再是一个需要选边站的问题。

它变成了一个可以事后反悔的问题。

我不确定这对企业客户是不是好事。他们要的从来不是能改，是不用改。