DeepSeek Harness 背后的 Cordis：一套“时空可组合”的插件框架

在 AI Agent 的开发实践中，如何设计一套既能保持灵活性又具备高度可扩展性的系统架构，一直是开发者面临的核心挑战。DeepSeek AI 开源的 Agent Harness（简称 dsh）给出了自己的答案：采用「一切皆插件」的架构思路，将 Tool、LLM、Session、Agent、Prompt 等核心能力全部通过插件机制实现扩展。而真正支撑这一设计的底层框架，正是 Cordis——一个专注于「时空可组合性」的元框架。

Temporal Composability：让组件「做过的」都能撤回

传统插件系统的工作模式相对直接：Host 启动后依次加载各插件，插件在 activate() 中注册所需能力，卸载时调用 dispose() 或 deactivate() 进行清理。然而，随着系统复杂度不断提升，这种依赖插件作者「自觉记忆所有副作用」的模式逐渐暴露出严重问题。一个插件可能注册了五个 Listener、启动了 Timer、向 Tool Registry 添加了 Tool，同时还设置了 Prompt 和缓存资源——这些副作用必须在卸载时逐一撤销，任何遗漏都会导致系统状态泄露。

Spatial Composability：组件依赖的动态响应

Cordis 论文将上述问题定义为动态组合系统的核心限制，并提出了 Temporal Composability（时间可组合性）的解决方案。其核心思想是：插件产生的每一次环境修改都应该携带对应的「撤销函数」，系统不再依赖作者事后回忆「我当初注册了什么」，而是在副作用发生时就同步记录「这个操作以后应该怎样恢复」。这种可撤销的 Effect 机制使得组件可以在运行时安全地加入和退出，而无需触发整个应用重启。

Context：超越依赖注入的运行时中枢

仅仅解决 Effect 追踪还不够。Agent Harness 中另一个常见挑战是组件间的依赖关系。假设 Agent Loop 依赖 ctx.llm、ctx.tools 和 ctx.sessions，当某个 Provider 被动态卸载时，相关组件应该如何响应？Cordis 的答案是让组件直接声明依赖（inject），而非自行判断依赖是否可用。当依赖消失时，Cordis 自动触发组件停用；依赖重新就绪后，组件又能自动激活。这种响应式的依赖注入机制，使得启动顺序不再需要手工编排，而是通过依赖关系自然推导。

类型安全事件与热加载：面向未来的架构

在 Cordis 中，Context 不仅是简单的依赖注入容器，更是运行时信息的统一载体。它需要追踪：谁提供了某个 Service、谁声明了依赖、谁注册了 Listener、某个 Effect 属于哪个 Component、Provider 消失后哪些组件会受影响、以及组件移除时哪些修改必须一起撤销。这种设计确保了组件间的边界清晰——依赖方只需要知道自己需要 ctx.llm，而无需了解背后究竟是 DeepSeek Provider 还是 OpenAI Provider，实现了真正的解耦。

如有侵权，请联系删除。