深度解析DeepSeek Harness的Cordis插件架构

在构建现代AI Agent运行时时，如何让模型、工具、沙箱、UI等核心能力既能独立演进，又能可靠地协同工作，一直是架构设计中的关键挑战。传统的插件架构虽然解决了模块化问题，但往往陷入注册容易撤销难、初始化容易回滚难的困境。DeepSeek Harness采用了一种名为Cordis的元框架，通过「时空可组合」的设计理念，为Agent运行时提供了一套灵活的插件化基础设施。

概述

插件架构并非新鲜事物。二十多年前，Eclipse就已经将IDE拆分为插件、扩展点和扩展的组合，允许其他组件通过清单贡献菜单、编辑器和处理逻辑。OSGi则更进一步，为bundle配置了完整的生命周期管理，并通过共享服务注册表完成动态服务的发布、查找和绑定。Cordis的设计正是建立在这些成熟实践之上，但它针对TypeScript应用内的细粒度组装进行了简化与重新组合。

从Eclipse到OSGi：插件架构的演进历程

Cordis的核心是一个名为Context的对象，它同时承担依赖容器、插件挂载入口和事件入口的角色。服务通过稳定名称出现在Context上，例如ctx.tools、ctx.llm、ctx.sessions。插件声明inject后，Cordis只在所需服务可用时才激活它；服务消失，依赖插件也会进入卸载或等待状态。这种设计彻底解决了传统插件系统的第一个顽疾：隐含初始化顺序。通过将依赖关系显式化，Cordis让配置文件中条目的顺序不再承担启动顺序的职责，依赖关系本身成为唯一的组织依据。

最小内核：Context作为统一入口

在同一个进程里，服务名称必须稳定，但实例又不能全局唯一。两个Agent可能需要选择不同的模型、不同的工具集、不同的persona和不同的沙箱环境。Cordis的Context.isolate方法为指定服务名创建一个realm标签，同名服务可以在不同子上下文里各自存在。DeepSeek Harness在此基础上又增加了dsh-scope，用不透明对象作为scope key来维护父子关系，解决了「同一工具注册表里，哪些注册项对当前Agent可见」的问题。这套双层空间模型把实例隔离和内容路由分开，让插件作者能够精确控制能力的作用范围。

空间可组合：作用域与隔离的艺术

时间可组合则是插件能够可靠启停的关键。每次插件应用都会产生一个Fiber，它记录父上下文、配置快照、依赖实现、生命周期状态和disposables。插件调用ctx.effect()注册副作用，effect的执行结果返回disposer。Fiber卸载时按注册的逆序执行清理，并等待异步清理达到静止状态。这种机制把资源清理统一成effect，让子插件、服务、监听器都归属于同一个Fiber的生命周期管理。 在事件系统方面，Cordis提供类型化事件并区分emit、parallel、serial、bail和waterfall等多种分发模式。waterfall模式尤为关键：监听器拿到next后，调用则把控制权交给下一层，不调用则截断链条。这意味着模型请求、工具执行和轮次控制都能被插件包裹，实现审批策略在工具执行前拒绝、重试插件包围模型流、日志插件观察前后状态等能力。

如有侵权，请联系删除。