“万物皆为插件”:为何 Cordis 才是真正的赌注,而非模型本身
DeepSeek 对 Harness 的宣传重点在于架构,而不仅仅是一个模型封装器。所有功能,包括模型、工具、技能、会话、沙箱、存储、代理循环、调度和 UI,均作为可替换插件实现,运行在 Cordis 元框架之上 [1]。这种模块化体现在四种预设运行模式中:标准模式用于完整代理工具包,代码模式用于基于 TypeScript 的多步工具编排,最小模式(bash 加文件编辑器)用于干净的基准测试,创建者模式用于在运行时编写和检查自定义预设 [1]。实际上,开发者仅通过配置即可选择、替换或扩展任何功能,而无需修改 Harness 源代码本身 [1]。
这一设计选择正是技术观察者关注的焦点。Hacker News 评论者将 Cordis 的热重载和动态启用/释放插件模型与 Java 长期存在的模块化运行时 OSGi 以及 React 的组件模式相提并论,同时也指出了跨插件依赖方面的实际局限 [2]。这种比较之所以重要,是因为它将 Harness 的野心定位为一个平台而非单一工具:一个已采用 MIT 许可 [3]并允许社区在专用 GitHub 主题下发布插件的仓库 [9],正试图成为其他代理工具构建的基础,而不仅仅是另一个与 Claude Code 竞争的 CLI。



