DeepSeek在押的是另一件事：未来的Agent，可能会开始修改自己周围的运行系统
我对 DeepSeek Harness 的判断，关键不在于它是不是一个好用的 Agent 产品，而在于它究竟为谁设计。
如果面对普通用户，把模型、工具、记忆、Skill、Session、Sandbox、调度、UI，甚至 Agent loop 都做成插件，确实过于复杂。律师只想处理案卷，老师只想出题和批改，没有人愿意先研究几十个组件怎么组合。
但 DeepSeek Harness 目前仍是 developer preview。它服务的首先是构建 Agent 的开发者，而不是最终用户。底层高度模块化，不等于产品界面也要把复杂度暴露出来。汽车可以拆成许多系统，车主并不需要学会更换变速箱。
我认为，真正值得关注的不是插件数量，而是这种架构为 Agent 自我修改留下了什么空间。
Harness 决定模型之外的一切
模型负责生成下一步，Harness 决定模型能看到什么、可以调用什么、权限何时生效、记忆怎样保存、任务如何循环，以及子 Agent 如何协作。
DeepSeek Harness 的激进之处，是尽量把这些能力都变成可替换组件。开发者不必修改 Harness 本体，就能更换模型、工具、存储、记忆、loop 和 UI，再把它们重新组合。
如果这些组件只由人类工程师维护，这主要是一个软件架构选择。但当 Agent 可以检查自己的 runtime，挂载或卸载组件，插件就从开发者的扩展机制，变成了机器能够识别和操作的对象。
这改变了问题的性质。
未来的 Agent 如果发现自己总在某类任务上失败，可能会调整上下文策略、更换记忆模块、增加工具、修改规划方式，甚至尝试另一种任务循环。要做到这些，它周围的运行系统必须可读、可写、可拆、可装，也能够回退。
DeepSeek Harness 押注的，正是 Harness 将从工程师手里的固定代码，逐步变成 Agent 可以修改的运行状态。
形式化解决不了全部可靠性
Cordis 试图解决插件动态加载、卸载和替换时的可组合性问题。一个插件注册了命令、监听了事件、改变了状态，卸载时能否把影响完整收回？多个插件会不会互相干扰？依赖变化后，系统能否按照正确顺序重新组织？
它的形式模型建立在一些明确前提上：effect 可逆、依赖无环、组件能够结束、不同 effect 相互独立。在这些条件成立时，系统可以证明某些组合性质仍然成立。
这种形式化有价值，因为它把过去隐藏在工程约定里的条件摆到了台面上。但定理成立，不等于实际运行的插件已经满足定理的前提。
一个 inverse 是否真的撤销了此前的操作？插件是否绕过框架直接写数据库、发邮件或触发支付？论文里的模型与 TypeScript 工程之间，是否存在可以验证的桥梁？这些仍是工程问题。
更重要的是，软件组件能够安全组合，不等于 Agent 行为也能可靠组合。
自进化必须同时包含变异和选择
我更愿意把 Agent 自进化写成一个简单的式子：
自进化 = 变异 × 选择
变异，是 Agent 根据失败轨迹修改提示词、工具规则、记忆检索、规划策略或 Harness 代码，产生一个候选版本。
选择，是判断这个版本是否真的更好。它可能只在某个 benchmark 上变好，也可能解决一类问题，却损害另一类能力。它应该只在当前会话生效，还是可以推广给团队，甚至升级为产品默认版本，也需要明确判断。
DeepSeek Harness 当前更强的是变异基础设施。它让模型周围的系统更容易被查看、修改、替换和回退。这像是一套先进的基因编辑工具。
但编辑能力不等于进化能力。谁来决定一次修改值得保留，不是插件框架和形式模型能够回答的。
真正有效的路径是改完再验
现有自进化研究走的仍是一条克制路线：先产生候选版本，再评测、回归和晋升，而不是让 Agent 在任务中途随意更换自己的核心器官。
Darwin Gödel Machine 让 coding agent 修改自身代码，把候选版本放到 benchmark 上运行，保留表现更好的版本，再继续探索。它更接近一次次软件发布，而不是在线热替换。
Self-Harness 也从执行轨迹中寻找弱点，提出尽量小的 Harness 修改，随后进行验证和回归测试。素材提到，其中一个模型在 Terminal-Bench-2.0 的 held-out 任务上，通过率从 40.5% 提升到 61.9%。这个结果不能直接等同于生产环境中的持续进化，但说明不更换底座模型，Harness 本身也可能是重要的优化表面。
这类系统的基本流程是：
执行轨迹 → 识别失败模式 → 提议修改 → 评测与回归 → 晋升版本
今天，让模型写一个插件、一段提示词或一份配置已经越来越便宜。昂贵的是证明这次修改值得留下。
Eval、Observability、Regression 和 Governance 不是自进化之外的配套，而是它的选择系统。没有可靠评测、现场回放、回归测试和升级治理，自我修改只是一台不停换零件、却从不做路试的机器。
组件越多，效果不一定越好
即使每个插件都能正确加载和卸载，Agent 的行为仍可能失控。
工具会改变模型看到的 schema，记忆会改变它对任务背景的理解，规划模块会改变下一步行动，反思模块又会影响后续轨迹。这些组件不是简单排列在依赖图上，而是通过上下文、注意力和模型表示相互作用。
素材提到的一项组合实验，把工具、规划、记忆、自我反思和检索五类组件进行完整组合。结果显示，五类组件全部开启并不总是最强：在 HotpotQA 上，只使用工具的 Agent 超过了全组件版本；在 GSM8K 上，某个三组件组合也优于五组件全开。
这不能证明复杂 Harness 没有价值，却说明 Agent 组件不是乐高。A、B、C 分别有用，不代表一起安装就一定更强。
Cordis 关心的是组件能否在软件世界里共存、加载和回收；Agent 真正需要的是这些组件共同作用后，能否形成更好的任务轨迹。前者是 component composability，后者是 behavioral composability，两者不能混为一谈。
自我修改首先是治理问题
如果 DeepSeek Harness 要成为自修改 Agent 的底盘，它面对的不只是架构复杂度。
第一是可信边界。插件可能与 Harness 运行在同一进程，获得文件系统、Shell、网络或 Session 权限。开发者看到的是扩展能力，企业安全负责人看到的是不断扩大的可信计算基。
第二是升级治理。Agent 找到一种更好的记忆策略，能否立即替换当前版本？谁有权把它推广给一个团队？发生问题回滚到哪里？不同业务线演化出冲突策略时，由谁裁决？
第三是产品责任。用户不会接受“第十四个插件与第五个插件组合后产生了副作用”这种解释。他只会问：谁允许系统这么做，谁能解释问题，谁负责修复？
DeepSeek 把自我修改设计成主动开启的能力，而不是默认权限，这一点很重要。它承认了一个现实：让 Agent 能够修改自己，已经开始成为可能；让它可以被放心地修改自己，还远没有解决。
DeepSeek 买的是一张架构期权
我现在更愿意把 DeepSeek Harness 看成一张期权，而不是一个已经得到验证的答案。
DeepSeek 今天付出更高的抽象复杂度、插件契约成本、安全压力和治理成本，换取一个未来可能性：如果 Harness 自进化成为 Agent 的核心能力，而且它确实需要细粒度、运行时、可回退的修改，那么这套系统已经提前准备了底盘。
但这张期权是否值钱，取决于两个尚未解决的问题。
第一，自进化会不会成为 Agent 的主流能力。第二，即使它成为主流，是否真的需要在线修改自身；跨任务版本迭代、离线评测和灰度发布，也许已经足够。
最终用户不需要看到裸露的插件系统。他需要的是稳定界面、统一权限、明确升级策略和可追责的服务。底层可以持续调整记忆、工具、工作流，甚至更新 loop，前台仍应像一个完成度很高的产品。
所以我的结论是：DeepSeek Harness 已经把“变异机器”做出了轮廓，但整个行业还没有做出可靠的“选择机器”。
Agent 能修改自己，离 Agent 会进化，中间还隔着评测、回归、权限、治理与责任这一整套机制。