摘要
看到 DeepSeek Harness（dsh）"一切皆插件"的定位，最值得追问的问题是：到底能替换到哪一层？是增加一个工具、接入一个模型，还是连 Agent 的执行方式都能改？顺着 dsh 的公开文档往下看，会发现模型适配器、工具注册表、会话日志，甚至 Agent loop 本身，都被放进了同一套插件组合机制。开发者能够调整的范围，因此从"Agent 有什么能力"延伸到了"Agent 怎样运行"。这是理解 dsh 的起点，也是它最值得展开讲的部分。本文围绕执行循环替换、插件正确退出、分层装配、日志与上下文分离、判断与执行分工五个主题，梳理 dsh 的架构设计，并用上下文压缩这一具体功能检验组合设计的价值。
一、执行循环也能替换
一个 Agent 的基本工作过程可以画得很简单：接收输入，准备上下文，请求模型；模型提出工具调用，程序执行并记录结果，再把结果交给模型继续处理。一次用户输入，可能在内部触发多次模型请求。Agent loop 负责组织这些步骤。
模型与框架的接力流程大致如下：
- 框架执行：准备本次输入，内容为有效历史、提示词与可见工具。
- 任务模型生成：请求模型 Mₙ，模型给出回答，或提出工具名称与参数。
- 若直接回答，本轮结束，框架保存模型回答。
- 若请求工具，框架校验参数与策略，执行允许、拒绝或按策略询问。
- 拒绝调用时跳过执行步骤，直接进入结果记录。
- 允许执行后，框架分发给工具插件，运行对应实现，取得结果。
- 框架记录最终结果，成功、失败或拒绝原因写入 Session。
- 随后进入下一次模型请求。
单看这个循环，并没有特别神秘的地方。dsh 值得关注的是：组织循环的组件，本身也是插件。模型适配器、工具注册表、会话日志和默认执行循环，都可以通过配置组合与替换。它们共同依赖的插件底座是 Cordis。
这让扩展有了不同深度。增加工具，可以扩充能力；接入模型请求事件，可以调整请求行为；替换压缩组件，可以改变上下文处理方式。默认循环确实无法满足需要时，还可以实现自己的 Agent 驱动。
当然，能替换不代表可以忽略接口约定。新实现仍然需要正确处理输入、状态、取消和资源释放等问题。这里的价值在于，框架给出了可替换的位置，开发者不必把所有变化都塞进同一个核心实现。连默认运行方式都保留扩展空间，是 dsh 插件架构最有辨识度的一点。
二、插件怎样正确退出
插件加载成功，只完成了一半。它可能注册了工具，添加了监听器，又往提示词里贡献了一段内容。卸载时，这些注册也需要清理。否则，重新加载几次以后，旧监听器和重复注册就可能留在运行环境里。
Cordis 为此提供了依赖注入和生命周期机制。插件通过稳定的服务名使用能力，例如 ctx.llm、ctx.tools 和 ctx.sessions，通过依赖声明等待服务就绪。工具、监听器和提示词片段等注册，则跟随所属插件的生命周期清理。
这样，组件替换就有了明确的归属：谁注册，谁拥有，退出时由谁撤销。使用服务的插件，也不需要到处绑定某个具体实现。
这里的"可逆"有准确范围。撤销一个工具注册，不会自动撤销它已经修改的文件；释放运行资源，也不等于回滚所有外部操作。这部分底层能力来自 Cordis。dsh 的设计价值，是把它贯穿到 Agent 的主要运行组件中。讨论它的创新，应该把这层来源讲清楚。
三、共享能力，分层装配
组件能替换以后，还要回答一个问题：这次替换影响谁？dsh 使用 Profile、Agent preset 和作用域表达不同范围。
| 概念 | 主要职责 |
|---|---|
| Profile | 定义启动哪一套应用组合 |
| Agent preset | 定义创建 Agent 时使用的插件组合 |
| Agent | 实际工作的运行实例 |
| Session | 保存会话事件，提供模型历史的来源 |
Profile 是具名的启动组合。web、headless、sdk 等入口，通过同一个启动器加载不同组合，并应用配置覆盖。它不能直接等同于开发、测试、生产环境。
preset 更接近装配模板。同一套模板可以创建多个 Agent，也可以声明多套模板，供不同会话选择。加载了模板，不代表候选 Agent 已经全部启动。已有 Agent 的组合保持稳定，修改后的模板供后续创建的 Agent 使用。这个约定能避免一次模板编辑，让正在执行的实例突然换掉整套能力。
作用域进一步控制注册的可见范围：可以提供宿主级公共能力，也可以只向特定 Agent 注册工具和监听器。不过，作用域本身不构成操作系统沙箱。
因此，"共享"需要说具体。多个 Agent 可以复用插件代码和公共服务，同时保留各自的配置与会话历史。复用了同一份代码，不等于运行状态和模型上下文也合成了一份。
四、日志与上下文分开管理
这一点不如插件口号显眼，却直接影响系统能不能解释清楚自己的行为。dsh 的 Session 使用仅追加的事件日志，再从日志中派生模型可见的消息历史。发生过什么，与下一次让模型看到什么，可以分别管理。
一次工具返回的原始文本，可以保留在日志中；后续请求使用经过修剪的版本。较早的一段对话，也可以在模型可见的历史里被摘要替代，而原始事件仍然存在。
数据流转分三层：
- 框架记录：仅追加的会话事件日志。原始消息、工具结果与替换关系全部保留，支持检查与恢复。
- 框架派生：模型可见的有效历史。修剪与摘要按事件更新消息视图，原始事件仍然保留。
- 组装：本次请求的上下文。由有效历史、提示词与可见工具组成，模型据此继续处理当前输入。
Session 文档将"模型可见即已记录"作为约束：模型请求中的内容，应当能够从日志重建。模型漏掉某个信息时，就有了更具体的检查方向：信息有没有进入会话？进入了原始日志，还是也进入了当前消息视图？中间是否发生过修剪或压缩？
屏幕上看得到一段内容，并不能充分说明模型当时也看到了它。重建输入，也不保证重新调用模型会生成完全相同的输出。跨进程保留记录，则需要配置持久化后端；Session 组件本身使用内存存储。这套设计给上下文处理留出了空间：既能控制当前输入长度，又能保留检查内容来源的依据。
五、判断与执行各司其职
"一切皆插件"不意味着所有插件都由模型挑选，也不存在每轮必须执行一遍的固定插件清单。读取文件这样的工具，可以由模型选择。上下文压力检查、会话记录和执行策略，则有自己的程序触发点。
以原生工具调用为例，模型看到当前可见工具的名称、描述和参数结构。模型提出调用后，框架校验参数、执行允许/拒绝/询问策略，再分发到具体实现。dsh 还区分了会话事件、Agent 事件和能力事件，供插件接入不同阶段的行为。扩展者需要选择合适的接口，遵守其分发与调用约定。
这条边界很重要。模型可以承担语义判断和内容生成，已经明确的执行约束则需要程序落实。不能只在提示词里写一句"请遵守规则"，就认为框架已经完成了控制。
六、用压缩检验组合设计
架构最终要落到具体功能上。上下文压缩就是一个很好的观察点。当会话越来越长，基础压缩实现会根据窗口容量、输出预算和预留空间判断压力。组合了工具结果修剪器以后，处理过程大致如下：
- 框架检测到上下文压力，按窗口、输出预算与预留空间判断。
- 框架调用修剪器，缩短超大的工具文本，按规则保留头尾，不调用模型。
- 框架重新测量，判断是否仍超阈值。若空间够用，跳过摘要步骤，直接继续。
- 仍超阈值时，框架选取较早的完整历史范围，保留近期内容，避免拆散工具调用组。
- 框架发起额外模型请求，由模型生成历史摘要，该请求只取摘要文本。
- 框架检查并继续任务，使用处理后的上下文。有摘要时校验并提交替换后继续；仅修剪时跳过摘要直接继续。
- 原始会话事件始终保留。
修剪器按规则缩短超大的工具文本结果，保留头尾并加入标记。这一步不调用模型。如果修剪后空间已经足够，就可以跳过摘要。仍然过大时，才需要额外调用模型提炼较早历史，同时保留近期内容。压缩组件还要负责范围选择、结果验证和状态提交。
这里能看出组合的价值：压力测量、规则修剪、模型摘要，各自承担明确职责。改变摘要方式时，可以复用已有的状态管理和校验机制，把定制集中在摘要实现上。
摘要毕竟会丢失细节。保留日志，提供了追查来源的条件，却不能保证模型压缩后仍然掌握全部信息。压缩也不等于提取跨会话的长期记忆，那需要另外设计存储、写入和检索链路。
七、怎样看 dsh 的创新
更值得看重的，是这些机制组合起来后的结果。核心运行组件可以替换，依赖和生命周期有统一管理，公共能力与局部配置能够分层，会话记录又为上下文变化保留了来源。开发者于是有机会调整 Agent 的运行方式，同时沿用已有的接口、记录和控制机制。
这里有来自 Cordis 的底层能力，也有 dsh 面向 Agent 场景作出的具体设计。将它们贯穿成一套可组合的运行架构，是 dsh 最值得研究的地方。
接下来值得观察的，是这套设计能否经受真实扩展的检验：换掉一个核心组件后，其他部分还能否沿着原有接口工作；加入新插件后，依赖、状态和退出行为是否仍然说得清楚。这些问题，比插件数量更能说明架构的成色。
八、实践启示
对正在搭建 Agent 系统的团队，这套架构带来几个可迁移的结论。
第一，把运行机制纳入可配置范围，而不是写死在核心代码里。Agent loop、上下文处理、工具分发都应当有明确的替换点。
第二，生命周期与归属规则先行。谁注册谁清理，依赖通过服务名声明，避免重复加载后的监听器残留。
第三，日志与上下文分离。保留原始事件，派生模型可见视图，让"模型看到了什么"可检查、可归因。
第四，判断与执行分层。模型负责语义判断，程序负责确定性约束，防止提示词软约束替代硬边界。
对于需要同时接入多个模型供应商的 Agent 部署，请求侧的统一管理同样属于架构的一部分。通过一个 API 网关集中处理模型路由、凭证与配额，可以让 dsh 的插件组合专注于 Agent 能力本身，而不是分散在各家接口适配上。团队在这一层做好集中化，后续替换模型或调整供应商时，影响面可以控制在网关之内，这与 dsh"在少量组合点替换能力"的设计思路是一致的。
结语
dsh 的创新不在于插件数量多，而在于把 Agent 运行的关键环节都变成了可组合、可替换、可退出的组件，同时保留了接口约定与状态来源。压缩流程展示了这种组合如何落地：压力测量、规则修剪、模型摘要各司其职，原始日志始终可追溯。这套设计是否成熟，最终要看真实扩展的检验——组件替换后接口是否仍然成立，新插件加入后生命周期是否说得清楚。这些问题，才是衡量 Agent 架构成色的真正标准。
