本文来自微信公众号： AIGC从0到1 ，作者：王零壹，原文标题：《DeepSeek Harness 真正赌的不是插件，而是 AI 能不能修改自己》
我看DeepSeek Harness的第一反应不太好，很失望，甚至有点不耐烦。
模型、工具、记忆、Skill、Session、Sandbox、调度、UI，连Agent loop，都被它往“插件”这个抽象里塞。再加上Cordis那套关于可逆effect、依赖关系和动态组合的理论，整件事很像一座还没住人、先把每一面墙都设计成可拆卸的房子。
有必要吗？
普通用户不想配置插件。律师只想把一份案卷交出去，老师只想出题、改作业；企业买Agent，也不会因为“这里有七十多个可替换组件”就愿意多付钱。给开发者的自由，常常会在产品端变成一排需要用户自己理解的选项。
于是我很快把DSH归进一类熟悉的东西：底层工程师很兴奋，最终用户却未必能感到任何好处。至于Cordis用形式化语言去证明插件如何组合，我还多了一层怀疑：会不会只是给一套复杂设计披上理论外衣？
后来读到一篇对Cordis的批评，我一度觉得自己判断得没错。
那篇批评问得很直接：一套形式模型可以在若干前提下证明组件可组合，但这些前提，谁来替真实世界担保？插件写出来的inverse真能撤销此前的操作吗？两个effect在工程里真互不影响吗？插件要是绕开框架，直接写数据库、发邮件、触发支付，定理还管得着吗？
这几句话几乎把我的结论钉死了。直到我顺着DSH仓库里的自修改能力、再去看Self-Harness和Darwin Gödel Machine这些研究，才在一个很小的细节前停住。
DSH里有一个单独的`self-modification`能力组。Agent可以检查自己正在使用的runtime，查看和挂载插件；仓库甚至放了一个“agent modifies its own runtime”的示例。
我才意识到，自己一直在用“这房子住起来舒不舒服”的标准，去评价一套可能是给机器造的建筑系统。
DeepSeek在押的是另一件事：未来的Agent，可能会开始修改自己周围的运行系统。
这个判断让我一下子把DSH看开了。但看开，不等于放下警惕。恰好相反，问题到这里才真正变难。
一、我为什么一开始差点把它判死刑
先把DeepSeek Harness说清楚。
它现在仍处于developer preview。官方把它定义为开源的agent harness，也就是包在模型外面的那层运行系统。模型看到什么上下文，能用什么工具，记忆如何保存，任务怎样循环，权限在哪一步生效，子Agent怎么协作，基本都由这一层决定。
模型负责生成下一步。Harness决定这一步看得见什么、做不做得成、做完以后留下什么。
DSH的做法很激进：尽量把这些能力都做成插件。开发者不必改动Harness本体，就可以替换模型、工具、存储、记忆、loop、UI，也可以把它们重新拼起来。
如果把它当成面向终端用户的产品，这套设计确实显得过头。没有人希望刚打开一个Agent，就得理解profile、bundle、依赖、插件所有权和配置层级。人们需要的是一个已经能工作的默认Agent。
这部分直觉没有错。
但DSH目前并不在和程序员、老师、律师、普通职场人争夺入口。它面对的是做Agent Harness的开发者，以及将来会在它之上交付具体Agent的团队。
一个成熟产品内部可以非常模块化，外部却一点也不让用户看见模块。汽车的发动机、底盘和电子系统都高度可拆，车主不必因此学会换变速箱。
我一开始把“用户不想折腾插件”和“底层不该插件化”混成了一件事。这是第一个误判。
问题变成了：DSH为什么要把底层拆到这个程度？
二、那份批评为什么让我更确信自己是对的
Cordis想解决的是一类很具体的软件问题：插件在运行时被加载、卸载、替换时，怎样不留下垃圾，不把依赖关系搅乱，也不因为加载顺序不同得到不同的系统状态。
换成日常语言就是，一个插件进来后注册了命令、监听了事件、改了状态；它离开时，这些影响能不能一并收回？两个插件同时存在时，会不会互相踩脚？依赖变动后，系统能不能重新排好加载与卸载的顺序？
Cordis给这类问题建立了一套形式模型。在effect可逆、依赖无环、组件会结束、不同effect相互独立等前提下，它可以证明组件组合后会保留某些性质。
这个“在前提下”非常重要。
一个插件写的inverse，是不是真的把此前的操作反着做了一遍？两个effect在TypeScript工程里真的独立吗？论文中的calculus，和正在跑的实现之间，有没有一座可以验证的桥？
形式化并不因此失去价值。恰恰相反，它逼着系统把过去藏在“我们约定如此”里的条件摊在台面上。一个框架说自己支持热重载很容易；它继续追问“在什么条件下，热重载才是可组合的”，这就比口号多走了一步。
只是定理成立，不等于正在运行的系统已经满足定理的前提。
DSH还在preview。第三方插件的设置能不能自然进入UI，自己的Session event能否安全持久化，某个extension seam是不是真正稳定的接口，这些琐碎问题都还在等工程实现去回答。架构上说“任何东西都可以是插件”，离生态里“任何东西都已经能作为一等插件工作”，中间隔着一段很长的路。
读到这里时，我原来的判断反而更坚定了：Cordis说得再漂亮，也只是软件组件的可组合性；它没有证明Agent会因此变得可靠。
这个判断到现在仍然成立。只是它漏掉了DSH想做的另一半事。
三、一个被我当成demo的目录
真正让我改观的，是那个`self-modification`目录。
此前我把“Everything is Plugin”理解成一种开发者偏好：把复杂系统拆成很多可替换的零件，方便人类维护。可当Agent本身可以检查runtime、给自己挂载或卸载组件时，插件就不只是人类的扩展机制了。
它变成了机器能够理解和操作的对象。
假设未来的Agent只能使用人类预先写好的工具，那么Tool、Memory、Planner、Loop是否插件化，主要是开发体验问题。可如果一个Agent发现自己总在某类任务上失败，想加一项能力、调整上下文策略、替换记忆模块，甚至试另一种任务循环，底层首先得是它看得懂、摸得着、改得动的东西。
DSH在赌的，是Harness不会一直是一坨只能由工程师手改的代码。
它可能会成为Agent可以修改的运行状态。
写到这里，我才明白前面的“产品复杂”批评为什么有点使错了力。批评对象放错了位置。拿一个精装公寓的标准去审一套建筑工业系统，当然会觉得它哪里都不对：住户为什么要关心墙体、水电和电梯？可如果这套系统的任务，是让建筑本身能被持续调整，那些看上去多余的接口，就有了原因。
不过，看到DSH的野心，也不能直接跳到“这就是自进化的正确路线”。
“Agent能自进化”和“Agent必须在运行中热插拔自己的组件”，中间还隔着一大段没有被证明的推理。
四、自进化里，真正难的是后半句
我后来觉得，理解这件事最有用的办法，是把“自进化”拆开。
一半是变异。
Agent发现自己在某类任务上老失败，于是改提示词、加一条工具规则、调整记忆检索方式、换一个规划策略，或者重写一段Harness代码。它产生了一个候选版本。
另一半是选择。
这个版本真的更好吗？它是在当前benchmark上更好，还是在真实任务里也更好？它解决了一类问题，会不会让另一类任务退化？它应该只在这个会话里生效，还是可以交给一个团队，甚至升级成产品的默认版本？
没有选择，变异就只是变化。
所以我会把自进化先写成一个有点粗暴、但足够有用的式子：
`自进化=变异×选择`
DSH目前最有力量的部分，恰好在变异基础设施上。它让模型周围的工具、记忆、服务、上下文和loop尽可能具备可读、可写、可拆、可装、可回退的性质。对于一个要尝试自我修改的Agent来说，这很像一套先进的基因编辑工具。
但谁来决定哪一次编辑值得留下来，不是Cordis能回答的问题。
到这里，那份批评和“自进化”的叙事反而在同一个地方相遇了。
批评说，软件组件能组合，不代表Agent的行为就能组合。
自进化研究说，Agent完成一次修改，也不代表它真的变好了。
前者问组件怎样安全装卸，后者问改完以后能否得到更可靠的任务轨迹。它们有关，但不能互相代替。
Cordis可以提高mutation safety，尽量让一次修改不在软件层留下脏状态。自进化真正难的地方却是selection quality：怎样判断一次修改带来的，是进步，还是一次更隐蔽的退化。
五、现在最有效的自进化，靠的仍然是“改完再验”
这不是一段哲学式的担心。2025到2026年的一批自进化研究，几乎都在走同一条更克制的路线。
Darwin Gödel Machine会让一个coding agent修改自己的代码，再把候选版本放到benchmark上运行，保留更好的版本，继续从保留下来的版本上探索。它展示了自我修改可以带来累计提升。
但它更像一次软件发布，不像在手术台上边做边换器官。
旧版本运行，发现问题，产生新版本，测试新版本，确认有效，再把它留下来。它不会在一项任务做到第37步时，突然卸掉自己的Agent loop，换一套loop，再像什么也没发生过那样继续执行。
今年6月的Self-Harness，更接近今天工程师理解的Harness Engineering。它从执行轨迹里找弱点，提出尽量小的Harness修改，再做验证和回归测试；确认改善、也没有明显伤害已有能力的修改，才会进入下一轮。
论文在Terminal-Bench-2.0上报告了明显提升。以其中一个模型为例，held-out任务通过率从40.5%升到61.9%。这当然不能直接翻译成生产环境里的“持续自进化”，但至少说明了一件事：不换底座模型，Harness也可能是一个很有价值的优化表面。
它的流程：
`执行轨迹->找到失败模式->提议修改->评测与回归->晋升版本`
这里最贵的不是前半段。
让模型写出一段插件、一个提示词或一份配置，越来越便宜。证明它值得活下来，才昂贵。你需要可靠的Eval，需要能回放现场的Observability，需要能拦住回归的测试集，也需要一套决定“谁有权推广这次修改”的治理机制。
我之前把Eval、Observability、Regression、Governance当成Harness外面的配套。现在看，它们更像自进化里的选择系统。
没有这套系统，所谓自修改，只是一台不停给自己换零件、却从不做路试的机器。
六、软件状态干净，Agent的行为却未必干净
即使我们暂时假设Cordis完美工作，难题也没有消失。
Plugin A能正确卸载，Plugin B能恢复状态，Plugin C和D的软件effect互不冲突，依赖图也没有环。软件状态最终可以回到一个干净、可预测的位置。
模型的行为不一定会因此收敛。
加入一个工具，会改变模型看到的tool schema；加入记忆，会改变它对任务背景的理解；加上规划模块，会影响它下一步怎么走；再加一层反思，后面的轨迹又不一样。它们不会像传统依赖图那样老老实实地排在纸上，而是通过模型的表示、注意力和上下文彼此牵动。
2026年一篇组合实验把工具、规划、记忆、自我反思、检索五类组件做了完整组合。结果有点反直觉：五件套全开并不总是最强。在HotpotQA上，一个只用了工具的Agent超过“全都装上”的版本；在GSM8K上，某个三组件组合也明显好于五组件全开。
这项研究有benchmark、模型和任务范围的限制，不能据此宣告“复杂Harness没用”。它只是把一个常识摊得很清楚：Agent组件不是乐高。
A有用，B有用，C有用，不代表A、B、C一起装上就更强。
这正是Cordis的component composability不能直接推出Agent behavioral composability的原因。前者关心组件能不能在软件世界里共存、加载和回收；后者关心模型在这些组件共同作用下，会不会走出更好的任务轨迹。
软件状态可以收敛，Agent的行为路径仍可能走到另一个世界。
七、DSH要面对的，也不只是复杂度
如果DSH真要成为自修改Agent的底盘，它要付出的代价会比普通插件框架大得多。
先是可信边界。
在DSH这样的架构里，插件不是一个远处的扩展包。它可能运行在同一进程里，拿到文件系统、Shell、网络或Session的能力。官方对这类扩展点本身就相当谨慎，很多能力被描述为trusted same-process contract，不是把第三方代码隔离在安全边界之外。
开发者会把这叫作extensibility。企业安全负责人会问得更直白：哪些代码已经被放进了我们的可信计算基？
然后是治理。
假设某个Agent找到一种更好的记忆策略。它能不能立刻替换当前用户的版本？能否推广给一个团队？谁批准它成为企业默认？出了问题回滚到哪里？不同业务线的Agent演化出冲突策略时，谁负责收拾？
还有产品责任。
一个会修改自己的Agent，越需要清楚的责任主体。用户不会在出问题后接受这样的解释：“这是第14个插件和第5个插件组合后的副作用。”用户只会问：谁允许它这么做，谁能把问题修好？
DeepSeek自己其实没有表现得像一些讨论里那么激进。自修改是刻意opt-in的能力，不是每个Agent默认都会拥有的权限。这一点反而很诚实：让Agent能修改自己，已经可以做到；让它可以放心地修改自己，远没有做到。
八、“别墅”和“大平层”，应该放在不同楼层
一开始我觉得，DSH像别墅，Claude Code一类产品像大平层：一个给你无限改造自由，一个把大部分选择替你完成。现在回头看，这个比喻少了一层。
DSH更像一套能重新安排承重结构、水电、墙体乃至电梯系统的智能建筑底盘。
大平层才是用户最终住进去的房子。
两者并不冲突。
自进化走得很慢时，DSH这种动态化架构可能会显得过重。人类工程师持续改Harness，按版本发布，一个固定但足够好的系统已经能解决大量问题。
自进化走得很快时，用户也不会需要一个裸露的底层系统。恰恰相反，他们会更需要稳定界面、统一权限、明确升级策略和可追责的服务。区别只在于：这套“大平层”的背后，可能正在悄悄调记忆、改工具、重组工作流，甚至更新自己的loop。
用户不必知道这些。他只需要知道，今天交给它的事，它能不能做好；如果做错，系统能不能解释、回滚，并在下次避开同一个坑。
九、DeepSeek买的，其实是一张期权
现在再回头看DSH，不是“对”或“错”的结论。
它更像一笔架构期权。
DeepSeek在今天付出更高的抽象复杂度、插件契约成本、安全和治理压力，也要持续处理形式模型与真实实现之间的对齐问题。它换来的是一个未来可能性：如果Harness自进化会成为Agent的核心能力，而且这种自进化确实需要细粒度、运行时、可回退的修改，那么它已经提前有了一块合适的底盘。
这张期权什么时候真正值钱，取决于两个问题。
自进化会不会成为主流能力？
即使它成为主流，是否真的需要在线、运行中的自我修改？跨任务的版本迭代、离线评测、灰度发布，会不会已经足够？
第一个问题已经有越来越多积极信号。Harness作为模型之外的优化表面，正被研究和产品实践反复验证。
第二个问题，目前没有答案。
这也是我最后对DSH的看法。
它已经把“变异机器”做得很像样：让Agent周围的系统可以被看见、拆开、改写、替换。
整个行业还没把“自然选择机器”做明白：一次修改怎样被判断，怎样避免局部变好、整体变坏，怎样决定谁有资格推广它，怎样让真实用户的反馈进入下一代系统。
Agent能修改自己，离Agent会进化，中间还隔着一整套选择机制。