为什么DeepSeek-Harness的代码不适合大部分项目？
内容提要
DeepSeek-Harness虽以“一切皆插件”理念引发关注，但对普通用户不友好，且对开发者缺乏灵活性，难以直接集成到现有项目。其基于Cordis的结构性障碍限制了应用，相比之下Pi框架更易整合。作者认为dsh更适合产品级定制，而非编程领域，最终选择放弃dsh改用Pi，并指出dsh作为国产探索，倒逼生态开放，但前景待观察。
延伸解读
“一切皆插件”的双刃剑
文章指出，“一切皆插件”虽然让能写代码的用户感到灵活，但对没有代码经验的普通用户并不友好，他们需要承受调试的心理压力。同时，对于开发者而言，这种设计也缺乏灵活性，难以直接集成到现有项目中。因此，这种理念更适合有强烈个性化定制需求的用户，而非普通用户或一般开发者。
集成方式的差异：微服务 vs 组件化
作者认为，Claude Code、Codex和DeepSeek Harness都适合作为微服务部署，但难以作为代码模块直接嵌入现有系统。而Pi框架则可以直接与TypeScript项目整合，作为系统的一个组件使用。这种差异源于设计理念的不同：前者做加法，接口固定，适合独立部署；后者做减法，底层固定，上层自由，更适合集成。
编程领域的竞争与生态隐忧
作者不看好dsh在编程领域的前景，认为编程工具需要先规范流程，再提升灵活实现覆盖率，而dsh依赖社区插件，难以持续维护。他以MCP为例，指出社区插件容易涌现后大量停止维护，形成“僵尸插件”，增加用户筛选成本。相比之下，Claude Code和Codex在编程领域更具优势。
国产探索的积极意义与局限
文章肯定DeepSeek Harness作为国产Agent Harness的探索价值，认为它冲击了AI领域，并倒逼Codex等开源生态。但作者也指出，dsh仍处于早期阶段，其“一切皆插件”路线能否走通尚待观察。这种探索体现了国产Agent不再完全跟随国外设计，而是争取自己的话语权。
Q&A
DeepSeek-Harness 为什么对普通用户不友好？
DeepSeek-Harness 没有类似 WorkBuddy、Codex 那样的桌面端入口，且其“一切皆插件”的设计需要用户自己摸索工具用法并搭建任务流程，对没有代码经验的普通用户来说调试心理压力大，心智负担高。
DeepSeek-Harness 的“一切皆插件”理念为什么对开发者不够灵活？
虽然“一切皆插件”让能写代码的用户可以灵活更换插件，但开发者想将 DeepSeek-Harness 集成到自己的项目中时，它基于 Cordis 的结构性障碍（如 ctx.agentLoop @deepseek-ai/cordis）使其难以直接嵌入现有系统，必须部署为独立实例，无法作为组件插入已有项目。
DeepSeek-Harness 与 Codex、Claude Code 在用户心智负担上有何不同？
Codex 和 Claude Code 提供标准，用户按标准操作即可，降低了心智负担；而 DeepSeek-Harness 不提供标准，只给工具说明书，用户需要先学会工具用法，再自己找到实现目标的“拼积木”方式，抬高了心智负担。
为什么作者认为 DeepSeek-Harness 更适合产品级定制而非编程领域？
作者认为编程领域需要先规范流程，再逐步提升灵活实现覆盖率，而 DeepSeek-Harness 依赖社区插件，难以在热度过后持续维护，且其“一切皆插件”的灵活性更适合有强烈个性化定制需求的产品级场景，而非编程工具。
作者最终为什么放弃 DeepSeek-Harness 改用 Pi？
因为 DeepSeek-Harness 基于 Cordis 的结构性障碍使其无法直接集成到现有项目中，而 Pi 框架可以直接与 TypeScript 项目整合，作为系统的一个组件使用，更适合已在运行的项目。
DeepSeek-Harness 对 AI 生态产生了什么影响？
DeepSeek-Harness 作为国产 Agent Harness 的探索，倒逼原本闭源的生态开放，例如在它发布 0.2.0 版本时，Codex 也完全开源了 3 套内核组件。它不再完全跟随国外设计，而是规划自己的路线，争取话语权。
