对比DSH与Pi：Agent框架设计理念与架构差异

做一个下dsh和pi的对比 Pi 的目标是“最小核心 + 用户自己拼”，DSH 的目标是“几乎所有能力都插件化，官方先给你几套完整组合”。DSH 的骨架是Cordis。Cordis 不是普通插件加载器，它强调两件事： 1. 可逆副作用（temporal composability）：插件卸载时，注册的服务、事件、工具 schema、prompt section 全部自动撤销。

2. 依赖声明与空间组合（spatial composability）：插件通过 `inject` 声明需要什么服务，运行时按依赖挂载。所以在 DSH 里： - 模型适配器是插件 - 工具注册表是插件 - session log 是插件 - agent loop 本身也是插件 - 甚至 UI 也是插件 没有“神圣不可动的核心”。你想换 loop、换工具策略、换上下文压缩，挂一个新插件 + 改配置就行。

启动时是 Profile + Bundle叠出来的： 空根 → dsh-base（模型、工具、沙箱、凭证…） → dsh-web-app 或 dsh-headless → 用户自己的 cordis.patch.yml → 命令行 --patch `dsh --profile web --dump-config` 能直接把当前实际挂载的树打出来。Session 设计是硬核部分 Session 是 append-only 的事件流 模型最终看到的上下文，必须能从这条 log 完整重建出来。官方写得很死： > Model-visible means logged. 任何会进模型请求的内容，都要先变成 session event。

所以 fork、resume、回放、UI 渲染、telemetry，全部从同一条流投影。这点比大多数 coding agent 做得更彻底。Turn / Step 有claudecode的影子，流程如下： turn/start → claim input → agent/pre-step（可拦截、可改写） → step/start → llm/stream → tool/call → tools/pre-execute → execute → post-execute → step/end → 继续 or turn/end `agent/pre-step`、`tools/*` 这些是 waterfall，监听者必须显式 `next()` 才能往下传。

扩展点设计得很规整。Pi 的实际交集 DSH 仓库里有一个包： `@deepseek-ai/dsh-llm-pi-ai` 它就是把 pi-ai当成 LLM 适配器的后端。多 provider、协议兼容、reasoning effort 映射、catalog 覆盖，都走 pi-ai 的能力，再包一层 Cordis 插件契约。

所以： - LLM 调用层：吃了 Pi 的基础设施 - Agent 编排、工具、session、UI、沙箱：完全自己的 Cordis 体系 “LLM 适配层直接用了 pi-ai，上层重做了一套更重的可组合 Runtime”。模式上的对应 DSH 的 Minimal 模式才最接近 Pi 的默认体验：只留 shell + 文件编辑器，专门给 benchmark 用。官方之前在 V4 的 agent 评测里就用过这个模式。

Standard 模式和 Code（PTC）模式则是完整工具集 + 程序化工具编排，已经远超 Pi 默认的 4 工具。如果你喜欢 Pi 那种“核心极瘦、自己动手加东西”的感觉，DSH 会显得重，配置和概念也更多。如果你要的是可替换的 agent loop、完整事件回放、多模式预设、以及官方已经搭好的 Web 界面，DSH 的插件树和 seam 设计更系统。

一句话： Pi 是极简可扩展的 coding harness；DSH 是基于 Cordis 的完整 Agent Runtime，LLM 层复用了 pi-ai，但整体不是同一套代码。