Pi 和 DeepSeek Harness 的核心设计有什么不同？
Pi 和 DeepSeek Harness（DSH）都允许大幅扩展 Agent 能力，但对不可替换核心的态度恰好相反。
- 共同起点：模型负责思考，harness 负责管工具、上下文、会 话、Agent Loop
- Pi 思路：4 层骨架 + 30 个扩展事件，深层替换受宿主接口限制
- DSH 思路：模型、工具、会话、默认 Loop 全是插件，底座只有 Cordis
- 时空可组合性：Cordis 用注册反向操作做时间可组合，用依赖图做空间可组合
- 自进化：DSH 创造模式让 Agent 自己写插件重组 Harness，可逆卸载是基础设施
共同起点：Harness 的边界
在讨论扩展性之前，先统一一个术语：harness。
模型负责思考，harness 负责把模型接到真实世界。它管工具、上下文、会话记录，也负责驱动模型不断思考、调用工具、读取结果，直到当前任务结束。
Pi 和 DSH 都属于这一层。二者都宣称灵活，都允许用户大幅扩展 Agent 能力，但拆解架构后可见：他们对“harness 应保留多少不可替换的核心”给出了截然相反的答案。
Pi：四层骨架 + 30 个事件
剥离表层封装，Pi 的核心结构可抽象为四层固定骨架：
Pi 的扩展性来自这套骨架在各层之间预留的丰富接缝。当前版本的 Pi 一共开放了 30 个扩展事件，覆盖用户输入、会话管理、模型请求、Agent 循环、消息流和工具执行等主要阶段。
下面三个钩子足以说明这些事件为何能深刻改变 Pi 的行为：
- 用户输入刚进来时：扩展可以改写这段输入，也可以直接接管它
- 模型调用之前：扩展可以修改模型将要看到的上下文和系统提示词
- 工具执行之前 / 之后：扩展可以修改参数、阻止调用，或者改写反给模型的结果
事件之外，Pi 还允许扩展直接注册新工具、新命令、新的模型服务和界面组件。因此扩展可介入输入接入、模型上下文、工具执行及结果回流至下一轮思考的完整链路。
Pi 像一栋已搭好合金结构的房子：主梁与楼层固定，但预留了大量插座、管线与改造接口——可加装智能家居、重新设计照明、调整房间用途。
这套设计划定了清晰的生命周期边界。当你退出 Pi 切换会话或重新加载扩展时，Pi 会发出关闭事件，让扩展有机会停止自己创建的定时器、连接和后台任务。再次启动时，Pi 可以重新建立扩展环境，同时保留当前会话和其他持久数据。
DSH：一切皆插件
DSH 将这一问题再推进一步：harness 的承重结构能否也由同一套插件机制组装？
DSH 最核心的架构原则是"一切皆插件"：
- 模型适配器是插件
- 工具是插件
- 会话系统是插件
- 默认的 Agent Loop 本身也是插件
承载这些插件的底座反而很薄，仅包含 Cordis 运行机制和一层负责启动装配的基座代码。官方再通过不同的插件组合形成标准模式、极简模式和创造模式等预设。
所以 DSH 更像一套模块化建筑系统，官方提供的不同预设就是用这些插件预先搭建好的几套成品方案——可以直接使用，也可以按照需要重新组合。
"一切皆插件"指的是这些组件拥有相同的架构身份，但重要性依然有区别：Agent Loop 和会话系统仍然承担着承重作用，只是通过统一的插件机制进入系统。这些常用插件可以更换，但替代品仍然需要遵守 DSH 内部的公共约定：
- 一项能 力叫什么
- 可以接收什么输入，会返回什么结果
- 一次 Agent 运行会产生哪些事件
- 会话中需要记录哪些事实
新组件可以改变内部实现，但必须继续沿用系统能识别的语言，依赖它的其他组件才能正常工作。
为什么需要 Cordis
架构允许更换承重插件只是第一步。实际运行中，这些插件可能已注册工具、监听事件，并被其他插件依赖。此时若要替换其中之一，系统必须同时解决两个问题：
- 旧插件留下的影响怎样清理
- 依赖它的其他插件怎样安全断开并重新连接
DSH 选择 Cordis 作为底层运行机制，原因正在于此。Cordis 在 DSH 出现之前已经长期用于一个聊天机器人插件生态，那里需要同时管理不同聊天平台、数据库和大量社区插件。插件持续安装、卸载和更新以后怎样清理残留、怎样处理不断变化的依赖，早就是一个真实的工程问题。这些经验后来被抽象为一个学术概念——时空可组合性。
时间可组合性：组件离开时留下的影响
卸载软件是常见操作：图标消失，后台仍可能残留定时任务、配置文件或开机启动项。用户眼中只是一次点击，卸载逻辑却必须由开发者预先实现——把安装过程中产生的副作用逐一还原，遗漏任何一步都可能留下残留。
Cordis 采用了一种更接近撤销记录的做法：插件通过 Cordis 注册接口注册事件监听、提供服务、注册一个工具或者挂载子插件时，这些接口本身就知道对应的反向操作：
- 事件监听加入了哪张表，卸载时就从同一张表里摘掉
- 服务登记在什么名字下面，卸载时就移除这项服务
- 父插件挂载了哪个子插件，父插件退出时，子插件也跟着退出
Cordis 能做到这些，是因为它只追踪通过注册接口提交的操作——它不解析任意代码，也不试图推断撤销方式。
如果插件直接创建了一个定时器，或者打开了一条网络连接，Cordis 无法凭空知道该如何关闭。开发者仍需在创建资源时一并登记对应的关闭方式。Cordis 不会清理未被告知的资源。
空间可组合性：依赖链跟随能力变化
正确卸载一个组件只解决了一半问题。软件由众多相互依赖的组件构成，某个能力下线时，仍在使用它的组件该如何处置？
在 Cordis 里，一个插件可以明确声明自己需要哪些能力。运行时由此维护一张依赖关系图：谁提供能力、谁依赖这项能力。
- 如果某项必须能力还没有出现，依赖它的插件不会启动——能力出现以后它才开始运行
- 如果提供这项能力的插件被卸载，依赖者也会退出；新的提供者出现以后，它们再重新启动连接新的实现
- 卸载顺序也很重要：一个能力准备离开时，系统会先停止向新的组件提供它，再沿依赖图通知现有的依赖者退出；等依赖者完成自己的清理，旧的能力提供者才真正关闭
这类依赖由运行时持续维护，而不会只在启动时检查一次。论文把这种根据能力变化重新组织组件的目标称为空间可组合性。
"时空可组合性"是论文《CORDIS: Spatiotemporal Composability for Dynamic Plugin Systems》提出的概念。Cordis 是这个框架里负责实现它的运行时机制。
同一功能对比：定时提醒 + 语音播报
上述讨论仍偏抽象，下面用同一功能对比两者的实现差异。
假设要让 Agent 定时提醒用户起身活动，并以语音播报提醒内容。该功能可拆为两部分：定时提醒与语音播报。
| 关注点 | Pi | DSH |
|---|---|---|
| 提醒 + 语音怎么写 | 写在同一个扩展里 | 拆成两个插件，语音插件提供"语音播报"服务，提醒插件声明依赖 |
| 定时器怎么跟踪 | session_start 创建，session_shutdown 关闭 | 创建时把关闭方式登记进 Cordis 撤销记录 |
| 修改语音实现 | /reload 整体重建扩展环境 | Cordis 根据依赖图自动通知提醒插件先退出 |
| 不受影响的部分 | 同样随扩展环境销毁 | 继续运行 |
具体地，在 Pi 里这两个能力可以写在一个扩展里。扩展可以在 session start 事件中创建定时器，时间到了以后向 Agent 注入一条提醒消息触发新一轮运行。语音能力通过 Pi 接口注册成模型能够调用的工具。现在要修改语音实现、让新版本生效，执行 /reload 会先触发 session shut down 事件让扩展关闭定时器和语音连接，然后整体重建扩展环境，所有通过 Pi 注册的工具和事件处理器都会随旧环境一起消失。
在 DSH 里，可以将提醒和语音作为两个插件：让语音插件提供一项叫"语音播报"的服务，再让提醒插件明确声明自己依赖这项服务。提醒插件创建定时器时同时把关闭定时器的方式加入自己的撤销记录。
现在把语音组件换成另一个实现，Cordis 会从依赖关系图中自动找到提醒插件，先让提醒插件退出、关闭它的定时器，接着让旧语音组件真正关闭。新语音组件安装、语音服务重新出现以后，提醒插件再次启动并连接新的语音实现。如果新语音组件插件安装失败，系统会清理这次未完成的安装并尝试恢复原来的语音组件。没有依赖语音服务的其他组件无需因此次变更重建。
两套方案最终都能实现定时提醒和语音播报。差异在于系统对此次变更的响应机制：
- Pi 维护的是一套稳定宿主加上一份可整体重建的扩展环境
- DSH 进一步记录每个组件产生了哪些可撤销影响，也记录组件之间的动态依赖；哪个组件发生变化，系统就重新组织它和受到影响的依赖链
各自的代价
| 维度 | Pi | DSH |
|---|---|---|
| 运行流程 | 相对固定（输入→模型→工具→结果） | 组件关系图随运行动态变化 |
| 排查方式 | 沿固定阶段向下找 | 需要梳理配置、命名、动态依赖关系 |
| 深层替换 | 受宿主已开放接缝限制 | 组件可细粒度更换和重组 |
| 插件作者心智模型 | 围绕生命周期事件编程 | 需要理解依赖图、动态卸载、热更 |
| 学习曲线 | 低 | 中等到高 |
Pi 的扩展开发者主要面对一条相对固定的运行流程：输入经过哪些阶段、模型在哪里调用工具、扩展环境何时关闭。扩展的边界更容易理解和排查，但更深层的替换受到宿主接缝限制。
DSH 把更多结构开放出来：组件可以进行更细粒度的替换和重组，这带来了更大的灵活性，也增加了理解成本。组件拆得越细，需要配置、命名和梳理的依赖关系就越多。插件开发者还需要理解一张会动态变化的组件关系图——自己提供什么、依赖什么、一个组件离开时会影响哪些下游组件。
自进化：DSH 的创造模式
插件不一定都由人编写，也可由 Agent 生成。沿此思路再进一步，便触及 DSH 另一备受关注的话题——自进化。
- 如果 Agent 只能给自己增加一个工具，它改变的是自己的能力
- 如果 Agent 连 Loop、会话和运行组件都可以重新组合，它就开始触及构成 Harness 的方式
DSH 提供了一个创造模式，让 Agent 检查当前运行结构、实验插件并创作新的 Agent 组合。Cordis 提供的可逆卸载、动态依赖与 失败恢复能力，为此类修改奠定了可反复试错的运行基础。
DSH 目前仍处于开发者预览阶段，它展示的是一种开放程度很高的架构方向以及一套已经可以研究和实验的组件机制。论文中也认为，未来的自进化 Agent Harness 可能需要在持续运行中生成、替换和重新组合自己的组件，但现有系统很难把旧组件清理干净，也很难处理随之变化的依赖关系。Cordis 的时空可组合性，正是为这类动态修改提供的基础。
怎么选
选择标准不在于"哪个更先进"，而在于所需的改造边界：
- 选 Pi：你希望扩展作者面对的是一条相对固定的运行流程，看重清晰的阶段边界和较低的理解成本；深层替换受限是可接受的代价
- 选 DSH：你希望组件能细粒度更换、依赖关系能被系统自动协调，并愿意为这种灵活性付出更高的理解成本和插件作者的额外心智负担
若涉及自进化场景——让 Agent 自行编写插件、重组 Harness——DSH 是当前公开架构中走得最远的方案。但这套机制本身仍在演进，把它当作"已经可生产使用的基础设施"还为时尚早。
References
- CORDIS: Spatiotemporal Composability for Dynamic Plugin Systems —— Yanting Chen et al., 2025-08-08
- 同样灵活、可扩展，Pi 和 DeepSeek Harness 的核心设计有什么不同？ —— YangAgent, 哔哩哔哩, 2026-08-20