DeepSeek Harness 和 Pi 是否正趋向于相同的理念? 人们给出的答案大同小异：“是的——核心精简，其余一切皆为插件。”

这固然没错，但这却是这两个项目中相对最不重要的一点。

这两个框架确实都精简了核心，也都致力于将功能向外扩展。但在“由谁来编写插件”这一问题上，它们存在深刻的分歧——一旦深入到运行时（runtime）层面去探究这种分歧，它就不再仅仅是一个理念上的注脚，而是解释了为何其中一个项目需要一篇长达 80 页关于“效应系统”（effect systems）的论文，而另一个项目仅需一个能让人轻松背诵的钩子（hook）列表。

---

两句话

Pi 的主页写道：“提供原语（Primitives），而非功能（features）。” 并且更明确地指出：“市面上有许多智能体（agent）框架——但这一个是属于你的。”

DeepSeek Harness 的主页则写道：“一切皆为插件。” 其 README 文件对此进行了毫不含糊的阐述：模型适配器、工具注册表、会话日志，甚至是智能体循环（agent loop）本身，全都是插件，因此“每一个部分都可以通过配置进行替换”。

将两者并列阅读，它们听起来像是同一份宣言，只是音量大小不同罢了。但事实并非如此。Pi 描述的是一种边界——这是我们掌控的精简核心，而这条线之外的一切都由你掌控。DeepSeek Harness 描述的则是边界的缺失。其 docs/architecture.md 文件直截了当地指出：“不存在需要打补丁的特权核心。”

“精简核心”与“无核心”之间的差异，正是整个对比的核心所在。

图 1 —— 同样的口号，两种不同的形态。Pi 保留了一个宿主（host），并在其边缘挂载扩展点。 DSH 将宿主环境（host）解构为服务图（service graph）。

---

Pi 的具体形态

七个工具与极简的系统提示词

Pi 为模型提供了一份刻意精简的工具列表——包括 read、write、edit、bash，以及 grep、find 和 ls。这些工具运行在一个系统提示词（system prompt）之下，据开发者 Ronacher 称，这是他所知的所有此类工具框架中最短的一个。在报道 DSH 发布时，《The Register》曾对比过两者的系统提示词长度：Claude Code 的提示词长达数万 token（尽管近期已缩减约 80%），而 Pi 仅需几百 token。虽然具体数值会随版本和统计方式而波动，但数量级上的巨大差异才是关键所在。

扩展接口：二十个易于记忆的钩子（hooks）

扩展接口本质上是一组宿主 API。扩展程序是一个 TypeScript 模块，通过 jiti 加载，无需构建步骤即可运行，并与 pi 对象进行交互：

• 注册类： pi.registerTool、pi.registerCommand、pi.registerShortcut、pi.registerFlag、pi.registerProvider / unregisterProvider、pi.sendUserMessage、pi.appendEntry
• 生命周期钩子（通过 pi.on(...) 调用）：session_start、session_shutdown、session_before_switch、session_before_fork、session_before_compact、session_compact、session_tree、resources_discover、turn_start、turn_end、before_agent_start、before_provider_request、message_start / message_update / message_end、context、tool_call、tool_result、user_bash、input

总共大约只有二十个事件名称和八个注册调用。你可以将整个 API 牢记于心——这绝非易事，而这显然正是其设计初衷。

拒绝即设计

“拒绝”构成了设计的另一半。Pi 的 README 文件以一种直截了当的方式阐明了这些限制——我希望更多项目能有这种坦诚的态度：不支持 MCP，不支持子智能体（sub-agents），也不支持“计划模式”（plan mode）。没有内置的待办事项功能——“这会干扰模型。请使用 TODO.md 文件。” 没有权限弹窗——“在容器中运行，或者利用扩展构建自定义的确认流程。” 没有后台 Bash 进程——“使用 tmux。这样既具备完整的可观测性，又能直接交互。”

每一次拒绝都附带一句简短的理由。绝不是那种“我们会考虑加入”的敷衍之词。

会话即树状结构，且扩展可向其写入数据

使其不仅仅停留在“极简主义美学”层面的关键在于：扩展可以通过 appendEntry 将状态持久化到会话的 JSONL 日志中，且会话本身呈树状结构（支持 /tree、/fork、/clone 等操作）——这意味着扩展可以将任务分支到侧向对话中，处理完毕后再切回主流程，而无需破坏主上下文。Ronacher 曾盛赞扩展状态持久化功能“极其强大”；亲身体验开发后，我也深表赞同：正是这一特性，让原本简单的钩子（hook）系统摇身一变，成为了能够支撑复杂工作流的强大平台。

---

深入了解 DeepSeek Harness

Cordis 的五大核心理念

DSH 构建于 Cordis 之上——这是一个插件元框架，DeepSeek 将其源码直接纳入了 vendor/ 目录，而非将其作为外部依赖引入。根据 docs/cordis-primer.md 的描述，整个框架由以下五大理念支撑：

1. 插件即实现 Service 接口的对象。
2. 上下文（Context）即服务的集合——某个插件声明一个稳定的键（如 ctx.tools、ctx.llm、ctx.sessions），其他插件通过该键查找它，而不是直接导入具体的实现。
3. 依赖项通过 inject 声明，因此加载顺序由依赖关系决定，而非固定的启动序列。
4. 通信基于类型化事件，分发方式包括 emit、waterfall、parallel 或 serial —— 且分发模式属于事件公共契约的一部分。
5. 注册操作是可撤销的副作用（effect）。 所有操作都通过 ctx.effect() 或 ctx.on() 进行，并在插件卸载时自动回滚。

第 5 点至关重要，我们稍后会再谈。

配置方案（Profiles）、包（Bundles）与补丁层（Patch Layers）

在 Cordis 之上，DSH 通过有序的层级组合来构建运行中的 Agent：bundle（包） 是一种分发格式，包含配置项及其挂载的代码；profile（配置方案） 则是多个 bundle 的堆叠，并附加了用户自定义的 cordis.patch.yml。运行 dsh --profile web --dump-config 会输出当前机器启动时的实际配置树，树中打印的任何配置项都可以通过补丁（patch）进行替换。这就是“无需修改源码”这一承诺背后的机制，而且它确实行之有效——我曾替换过 LLM 适配器，却完全没有改动 packages/ 目录下的任何文件。

Agent 循环（Agent Loop）仅仅是配置树中的一个配置项

关键细节在于哪些组件构成了配置树中的配置项。架构文档将 core/agent-loop 描述为“实现该接口的默认驱动程序”——这里的接口指的是注册在 ctx.agents 上的 Agent 接口。这个循环本身就是一个插件。如果未来的模型生成方式导致 ReAct 风格的步骤执行逻辑不再适用，你无需 fork DSH 代码库；只需注册一个不同的驱动程序，并修改（patch）对应的配置项即可。

“一切皆插件”带来的代码量影响

以下是我本地代码库中的一些数据（官方宣传资料中并未提供这些信息）：

基于提交 47f9438 的统计数据	数量
packages/ 目录下的 package.json 文件数量	226
packages/*/src 中的 TypeScript 代码行数（不含 *.test.ts / *.spec.ts）	~198,000
引入的 Cordis 代码库（vendor/ 目录下，共九个包）中的 TypeScript 行数	8,725

请仔细体会最后这一行数据。那个让“一切皆插件”理念成为现实的核心引擎，代码量还不到九千行。而其余部分——分布在 226 个包中的 19.8 万行代码——全都是基于该引擎编写的插件。无论你如何评价 DeepSeek 的工程能力，至少在践行其核心理念方面，他们是货真价实的，绝无弄虚作假。

---

关键差异：卸载（uninstall）是一项“一等公民”操作

这是大多数相关报道都忽略了的一点。

DeepSeek 不仅仅是开源了一个框架，他们还发表了一篇论文——《一种支持时空可组合性的编程范式》（A Programming Paradigm for Spatiotemporal Composability）。这篇长达约八十页的论文包含元理论探讨及汇合性（confluence）证明，旨在论证动态组合缺乏充分的形式化基础，并着手构建了这一基础。

时间与空间可组合性

论文提出了两个维度：

• 时间可组合性 (Temporal composability) —— 当移除某个组件时，该组件对共享环境所做的任何修改都必须被完全且安全地撤销。
• 空间可组合性 (Spatial composability) —— 组件之间必须能够以结构化且可验证的方式声明、发现并解析彼此的依赖关系，即便这些依赖关系在运行时动态出现或消失。

可撤销效应（Revertible effects）即运行进程的“撤销日志”

其核心形式化机制包括“可撤销效应”（即每次上下文转换都附带一个明确的逆操作，由运行时进行追踪与组合）以及“响应式共效应”（即组件将其需求声明为规范，而上下文的任何变更都会通知组件其状态是激活、停用还是中性）。如果不想深究范畴论，直观理解就是：这就像一个撤销日志（undo log）。上下文的每一次变更都会记录其逆操作；卸载时，系统会反向回放这些逆操作。Cordis 的原子操作自带逆操作，因此基于这些原子操作构建的插件可以自动获得“拆解/清理”功能；一旦跳出这些原语，提供逆操作就成了开发者的责任。这正是 ctx.effect() 返回一个清理函数（disposer）在实际应用中的含义。 ### 关于 VS Code 的证据

该论文明确指出了其针对的对象，这一点令人耳目一新。它直接点名 VS Code，并引用了 2026 年 6 月 9 日从插件市场（Marketplace）获取的数据：在安装量排名前 100 的插件中，有 87 个包含可执行代码，因此若要移除它们，必须完全重启插件宿主进程（extension-host）；同时，仅有 7 个插件声明了对非内置插件的依赖（即 extensionDependencies）。论文指出，VS Code 的 deactivate 钩子“仅作为宿主进程终止时的优雅关闭回调，因此无法实现插件的实时移除”。

那么，一个显而易见的问题随之而来：既然以往的插件系统从未需要过这种机制，为什么这个测试框架（harness）却需要长达八十页的篇幅来阐述它？

---

因为扩展机制变了

论文在第 1.2.2 节直接回答了这个问题，而这段论述也重构了整个比较的视角：

“由于这些修改是持续进行的，且伴随着有限的（或完全没有）……”
在需要人工监管的场景下，动态可组合性变得不可或缺。若缺乏时间维度的可组合性，每一次自我修改都将迫使系统进行全量重启，从而导致进程本地积累的所有状态丢失；这种频繁重启会造成显著的累计不可用时长，并反复中断正在进行的任务。更糟糕的是，一次错误的自我修改可能会导致用于恢复的那个关键进程失效。

人类操作频率与模型操作频率

请仔细研读关于“频率”的论点，因为这是整个方案的核心依据。

当人类安装扩展程序时，频率通常是每周一次。重启只需几秒钟，而且人本来就在键盘前操作。这种粗粒度的变通方案——即终止进程并重新启动——完全可行。正因如此，VS Code 长期以来（十年来）即便有 87 个热门扩展（前 100 名中）需要重启才能生效，也未受诟病；这也解释了为什么 Pi 不需要复杂的“效应演算”（effect calculus）机制。

当**智能体（agent）**在任务执行中途因遇到问题而决定加载新工具以获取某项能力时，重启意味着丢失构成当前任务的会话状态。而且，如果刚加载的那个组件本身有问题，你反而会使那个本应负责修复问题的进程失效。

这就是核心考量所在。DSH 的架构并非针对人类插件开发者进行了过度设计；它是针对“作为模型、以模型频率运行且无人值守”的插件开发者进行的恰当设计。

dsh-tool-cordis：核心理念的实证实现

他们还拿出了切实的成果。packages/extensions/tool-cordis 为模型提供了五个工具，直接作用于当前进程中的实时运行时环境：

• cordis_inspect —— 只读报告，涵盖服务、实时插件纤程（fibers）、已注册工具以及 API/事件目录
• cordis_undefine —— 记录一个包（包含宿主端和/或浏览器端），并对两者进行语法检查
• cordis_run —— 在沙箱中执行宿主端代码，并将浏览器端代码分发给已打开的页面
• cordis_stop —— 停止宿主端并使其进入静默状态，但保留其定义
• cordis_undefine —— 停止并移除该定义（彻底遗忘）

智能体可以编写、加载、使用并卸载插件，而无需重启进程。这就是该核心理念的可执行实现，也是整个代码库中最引人注目的部分。

该包的 README 文档也非常坦诚地说明了它的局限性：“沙箱隔离了全局变量，但并不构成安全边界……请将此工具集视为……” ……bash 访问权限。”_ 动态包仅存在于进程内存中——它们不写入文件，不修改 cordis.yml，也不会在重启后保留。这种做法固然正确，但也意味着目前的“自我修改循环”仅相当于一个临时草稿区，而非正式的插件发布途径。将一项实验转化为持久化插件，仍需依赖人工流程。

图 3 —— 同一插件系统在两种不同扩展主体下的表现。对于人类操作频率而言，卸载即重启仅属于微不足道的“舍入误差”；但对于模型操作频率而言，这却是一个关乎正确性的严重缺陷。

Pi 已经认同了其中的一部分观点

之所以说“它们是否正在趋同？”是一个真正有价值的问题，而非敷衍了事，原因在于：Pi 已经认同了其中的部分观点。 Ronacher 在一月份曾写道，其预想的流程根本不是下载扩展程序——“如果你想让智能体执行某项它目前尚不支持的操作，你不需要去下载什么扩展程序、技能包之类的东西。” “你要求智能体（agent）自行扩展。”

两者的目标相同。Pi 实现这一点的途径是极度缩小扩展接口（extension surface），从而让模型能够一次性正确地针对该接口进行写入操作；而 DSH 则是通过确保运行时（runtime）在执行过程中能够安全地进行修改来实现这一点。这两者并非同一个工程难题，其失效模式也截然不同。

Ronacher 本人在 DSH 发布后接受 The Register 采访时曾表示：“我不认为 DeepSeek Harness 已经完美无缺，但这确实是我第一次在这个领域看到新事物时，深受启发并想要重新审视我们自己的一些选择。”

这番话并非出自一个谈论竞争对手的人，而是一个在谈论某种他早已构思许久、如今终于看到概念验证（PoC）成果的人。

---

是“循环”还是“日志”？

整场讨论中最敏锐的见解来自一位名为 ciceroyang 的评论者，他完全跳过了关于插件的细枝末节，直指核心：Pi 将智能体循环（agent loop）作为产品的核心，而 DSH 则将会话（session）视为只可追加的事件日志——在 DSH 中，不可被替换的组件是日志，而非循环。

“模型可见即意味着已记录”

这话说得非常准确，并且可以在源代码中得到验证。docs/architecture.md 文件中用粗体明确了这一不变性原则：“模型可见即意味着已记录（Model-visible means logged）。” 任何进入模型请求的数据都必须能够从日志中还原，且这一原则由运行时的一个不变性约束强制执行。由此产生了一条规则，该规则在贡献者指南中对人类和智能体一视同仁：若要添加新的“模型可见”输入，必须扩展 Session 类。

使用新的会话事件创建 EventMap。您无法将上下文偷偷塞进请求中。

deriveMessages() 从日志中投影模型历史记录，并保留原始的 assistant/chunk 事件，以确保重放和 UI 的完整性。分支、恢复、转录、遥测和持久化都是基于同一流的派生视图。

方向，而非存在

Pi 也支持会话——JSONL 格式，树状结构，可分支，具有保留完整历史记录的压缩功能，以及用于扩展状态的 appendEntry。区别不在于是否存在，而在于方向。在 Pi 中，循环拥有上下文并写入其记录。在 DSH 中，日志本身就是上下文，循环是对其的投影，您可以自由替换它。

The Register 的报道指出，一个实际的好处是：由于所有模型可见的内容都会被记录，因此 DSH 可以让您完全访问推理过程，而此时主流厂商却在总结或隐藏思路链。如果你从事的是代理研究而非代理产品开发，那么仅此一点就足以决定最终选择。

---

它们真正的分歧点

并排比较

	Pi	DeepSeek Harness
口号	“基础，而非功能”	“一切皆插件”
扩展模型	主机 API — 约 20 个生命周期钩子 + 约 8 个 register* 调用	Cordis 服务图 — 声明一个 ctx.<key>，inject 依赖项，类型化事件
代理循环是否可替换？	否 — 它是核心	是 — 它是 ctx.agents 上的一个插件
卸载语义	重新加载扩展集；重启主机以进行更深层次的更改	形式化：每次注册都是一个可逆的效果，并跟踪其逆操作
模型上下文来源	循环	仅追加会话日志 (deriveMessages())
MCP	已拒绝。 “构建一个添加 MCP 支持的扩展。”	以插件形式发布 (dsh-mcp-client)，每个服务器在 cordis.yml 中配置一个实例
子代理 / 计划模式 / 待办事项	已拒绝，每个都有已记录的解决方法	以插件形式发布 (packages/subagent, packages/plan, packages/todo)
权限和沙箱	无内置功能。 “在容器中运行。”	操作系统级别：Landlock、Seatbelt、Windows ACL，以及一个审批/权限插件组
提供程序	开箱即用，支持 15 个以上，可在会话中切换 /model	ctx.llm 上的适配器接口；DeepSeek 第一方提供程序，Anthropic/OpenAI/Bedrock/Azure/Gemini 也可用
发现	成熟的软件包生态系统，数千个第三方软件包	GitHub 主题 (dsh-plugin)。目前尚无注册表。
成熟度	生产环境；作者每日使用	开发者预览版，明确存在缺陷
许可证	MIT	MIT

MCP 的反转

在整个对比中，我最喜欢的反转是 MCP 这一行。以“极简主义”为核心理念的框架拒绝发布 MCP。而以“一切皆插件”为核心理念的框架却以插件的形式发布了 MCP。两者都完全符合各自宣称的理念，却得出了截然相反的结论。这正说明了这些理念确实有效。

---

DSH 的代价

我对架构一直持积极态度，所以也让我同样具体地谈谈代价，因为它是实实在在的，而且没有人会提及这一点。

概念层面非常庞大

在编写一个有用的 DSH 插件之前，你需要了解以下内容：配置文件、捆绑包、补丁层、功能连接（服务定义/服务提供者/消费者——文档强调，单个角色本身并不构成连接）、四种分发模式以及哪些是瀑布式分发模式（其监听器必须调用 next()）、注册即效果、每个代理服务行的隔离域、品牌化的跨边界 ID，以及源平面/工件平面的划分。仓库中的 AGENTS.md 文件包含 15 KB 的规则，并链接到十几个其他文档。Pi 的等效项对应的 API 是 pi.on(event, handler)。

实际情况是：开发第一个实用的 Pi 扩展只需一个下午；开发第一个实用的 DSH 插件则需要一个周末——这还是建立在你已经熟悉依赖注入框架的前提下。

“开发者预览版”绝非虚言

README 文件用大写字母明确警告了可能导致不兼容的变更。AGENTS.md 进一步说明了这一点：后端会拒绝旧的磁盘存储格式，且 SESSION_FORMAT_VERSION（会话格式版本）目前设为 0，并声明“不保证兼容性”。千万不要基于本月的会话格式来构建产品。

生态系统尚未形成

DSH 的发现机制依赖于开发者为仓库添加 dsh-plugin 这一 GitHub 话题（topic）标签，该标签即作为索引。相比之下，Pi 拥有多年的包积累；无论如何统计 Star 数量（根据统计源和时间的不同，数据通常在 45,000 以上），它都拥有与之匹配的庞大用户群。

Pi 的代价：任意代码执行与缺乏权限系统

Pi 的模式也有其代价，官方文档对此也有说明。扩展程序会执行任意代码，且包可以注册允许模型运行的工具——这意味着供应链安全风险敞口极大；而有意不设计权限系统，意味着安全隔离的责任完全由用户承担。“在容器中运行”是一种合理的架构选择，但这并不等同于安全性，且其安全性明显弱于 DSH 原生集成的 Landlock 和 Seatbelt 机制。

图 4 —— 粗略的选型建议。大多数提出这个问题的人现阶段更适合使用 Pi，但无论如何都应该阅读 DSH 的论文。

---

那么——它们在趋同吗？

确实存在趋同之处

在大家都关注的那个维度上，确实如此，但这并不令人意外：两者都精简了核心功能，并将能力下放至插件中。Claude Code、Codex 以及同类产品也都在向这个方向发展。 ### 差异所在

在关键维度上，两者并不相同。它们对“扩展机制（extender）”的实现方式做出了不同的押注，这种差异贯穿了整个架构设计：

• Pi 押注于人类和模型针对一个足够小的接口层（surface）进行编写，从而在构建时就能保证正确性。其安全逻辑基于“可理解性”：由于整个 API 都可以被完整阅读，因此不太可能发生意外误用；移除操作采用粗粒度（coarse-grained）设计也是可接受的，因为移除操作并不频繁。
• DSH 押注于智能体（agent）在运行时动态重写运行时环境。其安全逻辑基于“效应演算（effect calculus）”：由于无法完整掌握整个 API（没人能记住 226 个包），正确性必须由框架来保证——即任何挂载（mounted）的组件都能被干净地卸载（unmounted）；移除操作必须是细粒度（fine-grained）的，因为移除操作会持续发生。

两者并非互斥或相互反驳的关系。它们针对同一个“近未来”的不同问题给出了各自的答案：客观来看，Pi 的方案在当下更优，而如果“自修改智能体”这一前提成立，DSH 的方案则更具优势。尽管这一前提尚未得到最终证实，DeepSeek 已经在其上投入了大量的工程资源，并发布了相关的论证。

我的建议

如果你本周就需要一个智能体框架（harness），请使用 Pi。如果你正在构建一款以该框架为核心差异化优势的产品，请认真评估 DSH，并做好应对破坏性变更（breaking changes）的准备。如果你想了解智能体基础设施的未来走向，无论最终选择哪个框架，都请务必阅读 Cordis 论文——它是该领域内最严谨的出版物，其核心论点的影响力将超越任何特定框架的成败。

---

常见问题解答 (FAQ)

什么是智能体框架（Agent Harness）？

它是围绕模型构建、使其成为智能体的一切要素：包括决定何时再次调用模型的循环机制、工具注册表、会话持久化、沙箱环境、权限管理以及交互接口。DeepSeek 将其定义为 Agent = Model + Harness（智能体 = 模型 + 框架）。模型提供智能，而框架提供行动能力。

DeepSeek Harness 是 Claude Code 的克隆版吗？

不是。Claude Code 是一款拥有特定工作流理念（opinionated）的集成化产品。 DSH 是一个运行时环境，其既定目标是让系统的每一个组件（包括 Agent 循环）都能通过配置进行替换。媒体将其描述为“Claude Code 的竞争对手”，这更多是出于市场定位的考量，而非架构层面的对比。

为什么 Pi 不支持 MCP？

因为大多数 MCP 实现要求在会话启动时将工具加载到系统上下文中；Ronacher 认为，这种机制使得在不破坏 Prompt 缓存（提示词缓存）的前提下，重新加载或修改工具功能变得困难甚至不可能。Pi 建议的做法是：将带有 README 文件的 CLI 工具构建为“技能”（Skills），或者在确有需要时编写扩展来添加 MCP 支持。

DeepSeek Harness 真的能在运行时自我修改吗？

可以，但有一定限制。dsh-tool-cordis 包针对正在运行的进程提供了 cordis_inspect、cordis_define、cordis_run、cordis_stop 和 cordis_undefine 等接口。以这种方式定义的包仅存在于内存中——它们不会写入文件或配置文件，也不会在重启后保留——且沙箱环境是……
它显然不构成安全边界，应将其视为拥有 bash 访问权限同等对待。

什么是 Cordis？

它是 DSH 底层的插件元框架，以 vendoring（本地集成）方式包含在仓库中，代码量约为 8700 行。它提供了“上下文即服务仓库”（context-as-service-repository）、基于 inject 的依赖解析、类型化事件以及“注册即为可回滚效应”（registrations-as-revertible-effects）的机制。其形式化模型在《时空可组合性编程范式》（A Programming Paradigm for Spatiotemporal Composability）一文中有所描述。

目前在生产环境中应该选择哪一个？

建议选择 Pi，除非你需要可替换的 Agent 循环或形式上可回滚的插件生命周期。Pi 已经成熟，拥有完善的包生态系统，且作者们在日常工作中也在使用它。DSH 目前处于开发者预览阶段，其文档明确提示磁盘存储格式可能会发生破坏性变更。

它们会合并或实现互操作吗？

不会合并。互操作性工作已由社区发起——pi2dsh 工具能将可执行的 Pi 包映射到 DSH 中，涵盖工具、命令、提示词（prompts）、技能（skills）、提供者注册表（provider registry）及生命周期钩子（lifecycle hooks），且无需重写或转换。 —

资料来源

• DeepSeek Harness插件目录 及其博客
• DeepSeek Harness — 开发者预览版 及 源码仓库 (MIT 协议)
• 《一种时空可组合性的编程范式》(A Programming Paradigm for Spatiotemporal Composability) — Yifan Shi, Wei Zhang, Tianyi Cui (cordiverse/paper)
• Cordis
• Pi 及 源码仓库 (MIT 协议)
• Armin Ronacher, 《Pi：OpenClaw 中的极简智能体》(Pi: The Minimal Agent Within OpenClaw) 与 《用 Pi 构建 Pi》(Building Pi With Pi)
• The Register, 《DeepSeek 创新的 Harness 将一切视为插件》(DeepSeek’s innovative harness treats everything as a plug-in) (2026-08-14)
• The New Stack, 《DeepSeek 开源了一款将一切视为插件的智能体 Harness》(DeepSeek open sources an agent harness where everything is a plugin) (2026-08-13)
• VentureBeat, 《DeepSeek Harness 发布，作为 Claude Code 的开源竞争对手》(DeepSeek Harness launches as open source rival to Claude Code)
• [GitHub 讨论 #1023 — “DeepSeek Harness 与 Pi Agent：它们是否正趋向于同一方向…”]哲学？"](https://github.com/deepseek-ai/deepseek-harness/discussions/1023)
• implicator.ai, Pi 编程智能体将极简主义转化为对 Harness 的反叛