做一个下dsh和pi的对比 Pi 的目标是“最小核心 + 用户自己拼”，DSH 的目标是“几乎所有能力都插件化，官方先给你几套完整组合”。 DSH 的骨架是Cordis。 Cordis 不是普通插件加载器，它强调两件事：
- 可逆副作用（temporal composability）：插件卸载时，注册的服务、事件、工具 schema、prompt section 全部自动撤销。
- 依赖声明与空间组合（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 仓库里有一个包： -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，但整体不是同一套代码。
