Deepseek Harness分享（二）
Agent换沙箱，为啥不用改Tool？

继昨天的 DeepSeek Harness 的 Event Log，今天继续下一部分。

先提出一个问题：同一个 Bash Tool，想从本机执行切到沙箱执行，难道要改 Tool 代码？

答案藏在 Capability Seam（能力接缝）里。

它把一件事拆成三种角色：
① Service Definition：先约定“执行命令”这个能力；
② Provider：本机、沙箱等各自实现它；
③ Consumer：Bash Tool 只调用 ctx.shell.execute()。

这样换执行环境，主要换 Provider，Tool 不必认识具体实现。读到这里我想到 Java 的接口和依赖注入，但还有个问题：运行中的系统，谁负责把这些插件接起来？

这就是 Cordis。

插件通过 inject 声明需要的 Service；依赖没就绪就等待，就绪后才启动。ctx.shell 看着像普通属性，背后其实是按当前 Context 解析到的能力。

这个地方我觉得我有一些特别的理解，我感觉就好像看到了Spring框架一样，检测依赖注入是否完成，哪些Bean里面需要哪些类型的东西，完全交给Spring框架去，就正像这里的Cordis。

更容易漏的是卸载。插件注册过事件监听、工具等东西，换 Provider 时不能只换个对象引用。Cordis 用 Fiber 管一个已加载的插件实例，用 Effect 记录可撤销的注册；卸载时把这些注册清掉，避免旧监听器还在运行。

所以我的总的理解是：Seam 画清“谁用、谁提供”，Cordis 管“何时接上、何时拆掉”。所谓可替换，不只是接口写得漂亮，还得把依赖和生命周期一起管住。

下次再看 Agent 框架，我会先找：Tool 是否直接绑死本机实现？Provider 卸载后，旧注册有没有清理？如果这些东西都变成可插拔的方式，上层Agent不需要在意底层的具体实现细节，那么对于后续的扩展是有非常大的帮助的

Agent开发 DeepSeekHarness Cordis 插件架构 后端开发 27届秋招 面经 面试