夜雨聆风DeepSeek最近开源了一套Agent Harness：DeepSeek Harness，简称DSH。
DSH目前仍处于Developer Preview，官方明确提醒未来可能出现破坏兼容性的变化。但它提出的架构口号已经足够特别：
Everything is a Plugin——一切皆插件。
当Claude Code、Codex、OpenCode和Pi都已经拥有工具、Skill与扩展机制时，DeepSeek为什么还要用插件重新组织一次Agent？
真正值得讨论的，不是DSH今天拥有多少功能，而是它把组成Agent的许多部分，都变成了可以通过配置重新组合的运行时组件。
一、从文件到插件，改变的究竟是什么？
Agent领域正在形成一种越来越常见的实践：把上下文和经验表示成文件。
任务要求可以写进AGENTS.md，专业方法可以写成SKILL.md，用户偏好、执行计划和失败经验也可以保存为Markdown或JSON。文件简单、透明、可审计，模型也已经熟悉搜索、读取和编辑文件的方式。
Agent犯过一次错误，我们可以把纠正方法写进Skill。下一次执行时，它重新读取文件，就表现得像“记住”了这次经验。
但这里存在一个重要边界：
文件里描述了一种做法，不等于这种做法已经成为运行时能力。
一份财报分析Skill可以要求Agent先统一口径，再检查同比和环比，但它仍然主要是一份操作说明。若要增加真正的财报解析器、审批规则或数据校验器，系统还要处理工具注册、服务依赖、生命周期和权限问题。
“一切皆插件”关注的正是这一层
普通插件系统通常由固定产品加外围扩展组成；DSH则把插件化的边界进一步向内推进。根据官方架构文档，模型适配器、工具注册表、Session Log和Agent Loop本身也都是插件。运行中的DSH，是多层配置在启动时组合出的一棵插件树；官方称其不存在一个必须通过修改源码来扩展的“特权核心”。
因此，更准确的说法不是“文件被插件取代”，而是两者承担不同作用：
文件与Skill主要承载上下文、经验和操作说明； 插件向运行时注册工具、服务、事件和策略； Cordis管理这些运行时贡献如何组合、依赖和退出。
“一切皆文件”降低了Agent保存和读取经验的门槛；“一切皆插件”试图降低系统重新组合能力组件的门槛。
前者更接近信息组织，后者更接近运行时组织。
二、为什么DSH的底层是Cordis？
插件能够动态加载并不新鲜，真正困难的是：一个持续运行的系统，如何承受组件不断进入、退出和更换？
一个插件可能注册工具、事件监听器和提示词，也可能依赖文件系统、浏览器或其他服务。卸载时，仅仅删除插件代码并不够：已经注册的监听器是否仍在运行？工具是否残留？依赖被替换后，其他组件是否需要重新调整？
Cordis用“时空可组合性”描述这类问题
时间可组合性关注组件退出后，它通过运行时机制登记的影响能否随之撤回；空间可组合性关注组件依赖的服务出现、消失或改变后，系统能否重新协调关系。
通俗地说，插件不仅要能“装进去”，系统还要知道它依赖谁、注册了什么，以及退出时应该撤下什么。
这里也可以与Pi进行对比
DSH与Pi并不是“一个支持插件、另一个不支持插件”。真正的区别在于插件化边界和生命周期管理方式：
Pi强调用扩展塑造一个极简Harness；DSH则进一步尝试用插件树描述Harness本身
这不代表DSH的产品体验一定更好，也不代表它在所有场景下都比小核心架构先进。它只是选择了更强调运行时组合的一条路线：先提供一套可替换的组件和依赖机制，再由不同配置组合出不同Agent。
三、部分Agent可以在专门模式下修改运行时
DSH最容易被过度解读的，是它提供的五个自引用工具：
cordis_inspect、cordis_define、cordis_run、cordis_stop和cordis_undefine。
它们形成了一条流程：
检查运行时 → 定义动态插件 → 装入运行 → 观察效果 → 停止或撤下
但必须先说明一个关键边界：这些工具不是普通DSH Agent默认拥有的能力。
官方将它们放在独立的cordis预设中。这个预设是在标准Coding Agent的基础上，额外加入自引用工具、插件编写Skill和相关提示词，目的是让用户可以要求一个Agent“创作另一个Agent”。标准预设中并没有tool-cordis。
在这个专门模式下，Agent可以检查当前服务，定义一个临时动态包，并将它装入正在运行的系统。动态包能够注册工具、提示词贡献、事件监听器和部分UI组件，从而影响后续任务。
这确实比读取一份新Skill更进一步：Skill主要改变模型参考的说明，动态插件则可能改变模型能够调用的运行时接口。
但它不能被称为“自我进化”
动态包只存在于进程内存中，重启后消失；它不会自动写入正式配置，也不能自动晋升为长期插件。若要保留结果，仍然要经过常规开发、测试和审批。
官方还明确说明，其VM沙箱不是安全边界，应当像Bash权限一样对待这套工具。Cordis可以撤下插件向运行时注册的工具、监听器和服务，却不能自动撤销已经改写的文件、发出的网络请求或外部系统变化。
因此，比“自修改Agent”更稳妥的表述是：
DSH提供了一套由高权限Agent临时编写、加载和撤下运行时组件的机制。
它解决了“变化如何进入运行时”，没有解决“什么变化值得保留”。
四、这是不是持续学习？
真正的持续学习系统，至少要形成这样的闭环：
任务轨迹 → 发现稳定问题 → 提炼经验 → 生成候选能力 → 独立评测 → 部署观察 → 长期保留或回滚
DSH已经具备其中一些可以被利用的基础设施。
它使用追加式Session Log保存任务事件，并要求进入模型上下文的信息能够从日志中重建。会话恢复、Fork和上下文压缩都建立在这条事件流之上。
同时，文件和Skill可以保存经验；动态Cordis工具可以加载候选组件；插件生命周期机制可以撤下运行时贡献。
由此可以推演出一种可能的未来路径：
经验先被写入文件或Skill，经过多次任务验证后，再被实现为候选插件；候选插件进入受控环境测试，确认有效后才通过正式流程长期保留。
文件中的Skill像一份可以反复修改的操作手册，插件则像把经过验证的手册实现成可以直接调用的机器。
但必须强调：这是根据DSH架构作出的推演，不是DeepSeek已经实现的功能。
从“可以修改运行时”到“能够持续学习”，至少还隔着四道门：
第一是评价。谁来判断新能力真的更好，而不是执行Agent自己宣布成功？
第二是归因。表现提升究竟来自新插件、上下文变化，还是模型输出的随机性？
第三是验证。插件能够被撤下，不代表它已经造成的外部副作用能够恢复。
第四是治理。临时能力什么时候可以获得长期权限，谁来审批版本、安全性和接口兼容性？
因此，DSH不是持续学习系统，也不能直接证明Agent正在走向自动进化。
它更像是在处理一个容易被忽略的工程问题：
如果未来的Agent真的可以从经验中生成新能力，这些变化应该怎样进入运行时、接受观察，并在出现问题时被撤下？
DeepSeek Harness最值得关注的，不是它已经让Agent学会成长，而是它把Agent的组成方式和临时能力变化，暴露成了可以配置、检查和管理的运行时接口。
