夜雨聆风
最近，Deepseek Harness 火了，一切皆扩展的设计在 Agent Harness 身上看起来理所当然，但事实上之前没有哪家的 Harness 采用这种设计，即便是以极简开放著称的 pi 也采用的是主流程+扩展的形式。
DSH 一切皆扩展的机制实现在另一个关注度没那么高的项目：Cordis。
如果说 Harness 展示的是“一套 Agent 应该如何运行”，那么 Cordis 探索的是另一个问题：
当未来的软件能力越来越复杂、越来越动态，一个系统应该如何组织自己的能力？
这个问题其实并不是 AI 时代才出现的，但 AI 的快速发展让它变得越来越突出。
从主程序 + 插件，到动态能力运行时
过去几十年的软件设计，大多建立在一个稳定的假设上：
软件的核心功能是明确的，未来变化主要发生在外围。
因此最经典的软件结构就是：
主程序|-----------------------| | |插件 A 插件 B 插件 C
主程序负责核心逻辑，插件负责扩展能力。
例如浏览器：
Chrome├── 广告拦截插件├── 翻译插件└── 密码管理插件
例如开发工具：
VS Code├── Python 插件├── Git 插件└── Docker 插件
例如企业软件：
ERP├── 财务模块├── 库存模块└── 生产模块
这种设计非常成功，因为它符合传统软件的特点：
核心边界稳定，变化主要来自外部需求。
因此系统通常是：
Application|+-- Module+-- Plugin
插件只是扩展，而不会改变系统本身。
AI Agent 带来了新的问题
问题在于，AI Agent 的能力边界并不稳定。
例如，一个传统 CRM 系统，它的功能范围基本明确：
客户管理 销售流程 订单跟踪
但是一个 AI 销售助手可能今天需要：
读取邮件分析客户信息查询 CRM生成销售方案
过一段时间，它可能又需要：
市场调研竞争分析自动跟进客户参与销售会议
未来甚至可能：
自主寻找客户制定销售策略执行营销活动
这里发生了一个变化：
过去的软件：
先定义系统，再增加功能。
未来的 AI 系统：
先提供一个运行环境，然后不断组合新的能力。
系统的问题不再是：
“这个软件有哪些功能？”
而变成：
“这个系统当前需要哪些能力？”
这正是 Cordis 这类设计出现的背景。
Cordis 的核心思想：能力组合，而不是功能扩展
传统插件系统的思路是：
应用程序|+-- 插件
应用是主体，插件服务于应用。
而 Cordis 更接近：
Runtime|+-- 能力 A+-- 能力 B+-- 能力 C
这里的 Runtime 本身并不代表一个具体应用。
它更像一个“能力运行环境”。
例如加载：
模型能力+知识库能力+搜索能力+浏览器能力
它可以成为一个研究助手。
换一组能力：
代码执行能力+终端能力+Git 能力+测试能力
它又可以成为一个编程助手。
Runtime 本身没有固定身份，它的最终形态由当前组合的能力决定。
Cordis 如何让能力组合起来？
其中一个重要设计是：
插件之间不直接依赖具体实现，而依赖运行时提供的能力。
传统方式：
payment.pay(order)调用方需要知道：
payment 模块是什么； 它在哪里实现； 如何初始化。
随着系统扩大，模块之间会越来越紧密。
Cordis 更像：
ctx.service("payment")调用者只关心：
“有没有支付能力？”
而不关心：
“是谁提供这个能力？”
今天可能：
Payment Plugin|vStripe
明天可能：
Payment Plugin|v企业内部支付系统
上层逻辑无需修改。
这种思想和操作系统类似：
应用程序不直接操作硬件，而通过抽象层访问资源。
事件机制：让插件形成协作网络
Cordis 另一个重要思想是事件机制。
传统软件中，模块之间通常是直接调用：
模块 A → 调用 → 模块 B这种方式简单，但系统规模扩大后，依赖关系会越来越复杂。
Cordis 更倾向：
事件发生|----------------| | |插件 A 插件 B 插件 C
例如 Agent 即将执行任务：
before_execute此时：
Memory 插件可以补充历史上下文；
Security 插件可以检查权限；
Logging 插件可以记录操作。
每个插件只关注自己的职责，而不需要知道其他插件存在。
Cordis 和传统插件系统的区别
很多人可能会认为：
“这不就是插件系统吗？”
确实，Cordis 继承了插件系统的思想。
但两者的关注点不同。
传统插件：核心系统 + 扩展功能
核心系统是确定的。
例如 VS Code 永远是一款代码编辑器。
插件只是增加能力。
而 Cordis：运行时 + 动态能力组合
能力组合决定系统形态。
同一个 Runtime：
加载：
Memory+Research Tool+Browser
可以成为研究助手。
加载：
Code Tool+Terminal+Git
可以成为编程助手。
系统不是先存在，然后添加能力。
而是能力组合后形成系统。
为什么现在出现 Cordis 这种设计？
Cordis 出现的根本原因，是软件系统的变化速度发生了改变。
过去：软件的核心能力通常由人提前设计。
例如：
一个银行系统，它的业务模型可以经过长期分析后确定。
一个 ERP 系统，可以经过多年实践形成稳定模块。
但是 AI 时代：模型能力在变化、工具生态在变化、用户需求在变化、Agent 的行为方式也在变化。开发者很难提前定义一个完整系统。
因此软件架构需要从：
设计一个完整应用
转变为：
构建一个能够持续演化的运行环境。
这也是为什么 AI Agent 比传统软件更需要类似 Cordis 的架构。
哪些场景适合 Cordis？
Cordis 并不是所有软件的最佳选择。
如果一个系统核心流程稳定，例如：
财务系统； ERP； 电商系统； 数据库；
传统的主程序 + 模块方式通常更简单、更可靠。
Cordis 更适合那些未来能力边界无法确定的系统。
最典型的是 Agent Runtime。
因为 Agent 的能力组合天然变化：
不同任务需要不同工具、模型、记忆和执行方式。
企业 AI 平台也是类似。
未来企业可能不会购买一个固定 AI 应用，而是拥有一个 AI Runtime：
Enterprise AI Runtime+ ERP 数据能力+ CRM 数据能力+ 知识库能力+ 审批能力+ Agent 能力
不同企业通过组合不同能力形成自己的智能系统。
个人 AI 助手也是类似。
未来个人助手可能不是一个固定 App，而是一套个人能力环境：
邮件日历文件知识任务财务
每个人拥有不同的能力组合。
Cordis 代表的软件趋势
软件架构一直在演进。
最初：单体应用→功能写死； 后来：模块化系统→核心 + 插件； 再后来：平台生态→API + 第三方能力； 未来可能：能力运行时→动态组合能力；
Cordis 的意义并不是取代传统软件架构。
它探索的是另一种可能：
未来的软件可能不再是一个提前设计好的功能集合，而是一个能够持续吸收新能力、重新组合自己的运行环境。
DeepSeek Harness 展示的是 Agent 如何工作。
而 Cordis 更进一步探索：
在一个能力不断变化的时代，软件本身应该如何组织。
这可能才是它更长期的技术价值所在。
