夜雨聆风护城河、复杂度税与采用决策
看完一个大型开源 Agent 项目后，最容易给出两种极端评价。
一种被功能清单吸引：包多、工具多、支持 Web/SDK/多 Agent，于是认为它已经是一套成熟平台。另一种被复杂度吓退：219 个 package、插件框架、事件溯源、合同生成，于是认为这是过度设计。
这两种判断都绕开了真正的问题：这些复杂度是否对应长期变化，工程治理是否足以控制它，项目当前成熟度是否匹配你的风险预算。
第一层：dsh 的护城河不是某一个功能，而是边界之间的对齐
模型 Adapter 可替换，并不稀有；工具注册也不稀有；Session、Web UI、SDK、多 Agent 各自都有人实现。
dsh 更有价值的部分，是这些能力在同一套不变量下对齐：
插件注册与 fiber 生命周期对齐，卸载回收 effect； 模型可见信息与 Session durable facts 对齐； 工具参数、实际执行与审计记录对齐； 并发 dispatch 与模型顺序 commit 对齐； Host business method 与生成 Client contract 对齐； local/remote Provider 与共同 capability interface 对齐； 子 Agent durable Session 与 process-local Activation 对齐； Web live state 与 Session replay projection 对齐。
单个功能容易复制，跨边界一致性需要长期工程积累。这更接近基础设施的护城河。
第二层：仓库用自动化门禁对冲模块化复杂度
根 package.json 不只有 build/test/lint。它还包含：
Host 与 Client 分阶段 build； strict typecheck、Oxlint、duplication、knip、publint； unit、coverage、E2E、snapshot、Web perf/stress、GUI； Windows/Wine 与 Node compatibility； 文档 typecheck、链接、fragment、Markdown wrap； Mermaid、Cordis catalog、tool/config/persistence catalog； module graph、scoped events、translation pairing； package licenses、runtime closure、Cordis config； 发布 pack 与安装验证。
根级 AGENTS.md 还规定 packages/*/*/src 使用 per-file 100% coverage gate，package README 必须记录 Model Experience、Token effect、KV Cache effect 与 Known Limitations；产品可见变化要有 REAL composition test。
这些约束说明团队知道自己的主要风险：大量细粒度包、动态组合、Host/Client face、生成文档和模型可见行为很容易漂移，所以把一致性变成可执行 gate。
但“有 gate”不能直接推出“生产稳定”。本研究没有重新跑完全仓 CI，也不据 test 文件数量推断覆盖率结果。更重要的是，项目明确处于 Developer Preview，版本为 0.1.0-rc.5，未来允许破坏性变化；Session format v0 只做窄范围旧记录转换。
第三层：复杂度税应该由谁支付
dsh 的主要复杂度税有六类。
第一是学习税。开发者需要理解 Cordis Context、service、fiber、effect、scope、isolate 和 waterfall，才能正确扩展。
第二是组合税。实际行为取决于 bundle、patch、插件顺序、Provider 和 Agent scope。排查问题不能只看一个 package，必须重建最终 dump-config。
第三是兼容税。细粒度 package、生成合同、Client/Host 双面、Python bundled runtime 与原生依赖扩大了发布矩阵。
第四是安全税。Sandbox、approval、FS guard、subprocess Provider 和 OS capability 必须组合验证；“某个沙箱包存在”不能成为合规结论。
第五是数据税。Append-only Session 需要存储、压缩、spill、隐私和迁移治理。
第六是团队边界税。Seam 很多意味着需要明确 owner：谁维护 LLM Provider，谁维护执行环境，谁批准 profile，谁处理 schema 演进。
什么时候值得支付？
如果团队要维护多个 Agent 产品形态，需要多模型、多执行环境、Web/SDK/IDE 多入口，并且合规要求模型历史和工具事实可审计，那么这些复杂度对应真实需求，平台化可能产生复利。
如果团队只需要一个固定工作流或 FAQ Bot，模型和工具集合长期稳定，单一 Web 入口足够，那么 dsh 的大部分边界不会产生复用，反而增加交付时间。
一套务实的试点路线
第一阶段，不写插件。启动一个固定 commit 的 Web profile，导出 dump-config，观察 followup → Turn/Step → Session event → Tool result → UI projection。团队必须能解释模型每条消息从哪条 event 来。
第二阶段，只替换一个 seam。比如新增一个只读工具、切换 LLM adapter，或给单个 Agent 加 tool restriction。测试加载、卸载、权限、取消、错误、回放与真实 composition。
第三阶段，再做产品 profile。锁定 Node/pnpm/runtime 与 bundle，建立 Session 恢复、跨 Provider、权限、安全和升级演练，把 dump-config 作为发布工件。
第四阶段，才考虑关键业务。此时应明确 Session 数据保留、v0 migration 策略、Workflow 无 resume 的弥补方案、Code Mode 中间值边界和多 Agent token 预算。
我的结论是：dsh 现在更适合作为高质量的 Agent 基础设施研究对象和受控平台试点，而不是“拿来即承诺长期稳定 API”的黑盒产品。
它真正的长期价值，在于把 Agent 系统最难的变化——模型、工具、执行环境、策略、宿主和协作方式——压进一组可定位边界。它真正的风险，也来自同一个地方：边界越多，治理必须越专业。
源码核验索引
工程脚本： package.jsonWorkspace 与供应链策略： pnpm-workspace.yaml根级不变量： AGENTS.md架构与限制： docs/architecture.md、各 package README Known Limitations项目成熟度： README.zh.md
事实边界：测试数量、工程 gate 和详细文档是质量信号，不是性能领先或生产稳定的充分证据。采用结论属于基于当前 rc 状态的分析判断。