有幸一个月前就被 @tianyi 拉进了仓库。当时 DSH 还是一个只实现了 core framework 的毛坯房。过去一个月，基本上每次 pull 代码，都是上千个 commits 的速度在涨。 说一下我对 DSH 的一些理解，不一定对： 1. 首先是怎么理解 DeepSeek Harness 这个东西。我觉得 DSH 既是一个可以直接运行的 Coding Agent，目前官方提供了 Web 和 headless 两种形式；同时它也是一套 Agent 开发框架。TUI 之类的其他交互方式，也可以通过外部 profile 和插件接进来。 2. 如果拿 Coding Agent 的标准来说，当前 DSH 的体验确实不如 Claude Code / Codex 那么完善。整个项目还很早期，接口一直在变化，插件生态也才刚刚开始，质量肯定是层次不齐的。 3. 但如果从开发框架的角度来看，可以把 DSH 想象成一个乐高汽车玩具。DeepSeek 官方提供的这个 Coding Agent，只是他们自己拼出来的一套官方预置。你完全可以把里面的零件换成自己喜欢的：换引擎、换轮胎、换挡风玻璃，或者加装其他模组。甚至最后拼出来的东西，也不一定还是一辆汽车。 4. DSH 的核心是「一切皆插件」。模型、工具、文件系统、Shell、沙箱、会话存储、Subagent、UI，甚至 Agent Loop 本身，都是插件。正因为这样，你可以把 DSH DIY 成任何自己想要的样子，这也给后面的社区生态留下了很大的空间。 5. 再往前想一步，这其实有一点「自进化软件」的雏形了。DSH 现在已经可以让 Agent 检查自己的 runtime，现场写一个插件并挂载上去，然后在后续的任务里直接使用这个刚刚获得的能力。 当然，现在这部分还比较实验性：动态生成的插件只存在于内存里，重启就没了，也还不能自动沉淀成一个永久插件。 但可以想象一下：假设某个功能现在没有，你和 Agent 随便聊两句，这个功能就被做好了，而且可以直接开始使用。甚至 Agent 在执行任务的时候，可以自己发现缺少某种能力，然后自己完成开发、安装和调用。 6. 接下来就需要等待一批真正优秀的插件了。DSH 现在还很早，但我相信它的潜力非常大。 --- 另外从代码上来看，DSH 有非常多函数式编程的影子，不熟悉 Ocaml/Haskell 可能一上来会比较难理解，可以多让 Agent ELI5 一下。

有幸一个月前就被 @tianyi 拉进了仓库。当时 DSH 还是一个只实现了 core framework 的毛坯房。过去一个月，基本上每次 pull 代码，都是上千个 commits 的速度在涨。 说一下我对 DSH 的一些理解，不一定对： 1. 首先是怎么理解 DeepSeek Harness 这个东西。我觉得 DSH 既是一个可以直接运行的 Coding Agent，目前官方提供了 Web 和 headless 两种形式；同时它也是一套 Agent 开发框架。TUI 之类的其他交互方式，也可以通过外部 profile 和插件接进来。 2. 如果拿 Coding Agent 的标准来说，当前 DSH 的体验确实不如 Claude Code / Codex 那么完善。整个项目还很早期，接口一直在变化，插件生态也才刚刚开始，质量肯定是层次不齐的。 3. 但如果从开发框架的角度来看，可以把 DSH 想象成一个乐高汽车玩具。DeepSeek 官方提供的这个 Coding Agent，只是他们自己拼出来的一套官方预置。你完全可以把里面的零件换成自己喜欢的：换引擎、换轮胎、换挡风玻璃，或者加装其他模组。甚至最后拼出来的东西，也不一定还是一辆汽车。 4. DSH 的核心是「一切皆插件」。模型、工具、文件系统、Shell、沙箱、会话存储、Subagent、UI，甚至 Agent Loop 本身，都是插件。正因为这样，你可以把 DSH DIY 成任何自己想要的样子，这也给后面的社区生态留下了很大的空间。 5. 再往前想一步，这其实有一点「自进化软件」的雏形了。DSH 现在已经可以让 Agent 检查自己的 runtime，现场写一个插件并挂载上去，然后在后续的任务里直接使用这个刚刚获得的能力。 当然，现在这部分还比较实验性：动态生成的插件只存在于内存里，重启就没了，也还不能自动沉淀成一个永久插件。 但可以想象一下：假设某个功能现在没有，你和 Agent 随便聊两句，这个功能就被做好了，而且可以直接开始使用。甚至 Agent 在执行任务的时候，可以自己发现缺少某种能力，然后自己完成开发、安装和调用。 6. 接下来就需要等待一批真正优秀的插件了。DSH 现在还很早，但我相信它的潜力非常大。 --- 另外从代码上来看，DSH 有非常多函数式编程的影子，不熟悉 Ocaml/Haskell 可能一上来会比较难理解，可以多让 Agent ELI5 一下。

大家一定要体验一下最新版本的 @MulticaAI，对 UIUX 做了大量的优化，整套 UI 都是 5.6 Sol + Fabel 5 写的，但是几乎没有什么 AI Slop（除了一些个别页面还没有优化完）。 过段时间可以分享一下如何结合这两个模型来做 UI 设计。

使用 Multica 你甚至可以一次性做 100 件事，主要的瓶颈还是在人的 attention，例如我们的队列里面还有 170+ 任务等待人做一个最终的 review。

Codex 实践下来一个最节省 usage 的配置： - 模型 5.6 Sol - Effort 选择 Extra High 或者 Max - Speed 选择 Standard Ultra 很难用（只是会 spawn 多个 sub agent），Fast 很好用但是太耗 token 了，Ultra + Fast 一个任务就可以把 5h limits 跑完。 按照这个配置可以多消耗 2x-3x 的 token。

几个客观性说明： 1）这一条和 MiniMax 没有任何关系（我从来不接商单） 2）「体感」不等于真实水平，不是量化数据 用了更多的一些体验，整体上 coding 能力对比 m2.7 是质的提升，目前发现的缺点是 1-shot 的结果相比较 Opus 4.6/4.7/gpt5.5 没有那么全面，会出现考虑不是特别全的情况。 但是加另外一个 Agent 作为 gate 和 mentor（例如 Opus 4.7），可以获得一个非常好的结果，M3 写代码，Opus 4.7 做 code review 并给出具体的修改意见，可以做到一个很好的「效果 + token 使用」的平衡。 为了保证客观性，正在做一个更加量化的数据评测：用 Multica 这个项目中真实的 Issue 来做 benchmark。 整个流程均基于 Multica 的 Squads 功能，会同步加上其他主流 OSS 模型作为评测的对象。

已经测试一个早上了，目前体感上接近 Opus 4.7（还需要进一步测试）。 用 M3 来写代码，Opus 4.8 + GPT5.5 来做对抗式的 code review，效果还不错。 已经完成了 1 个 PR

Multica 已经发布了一个多月了，距离一个多月前，我们完成了数百项更新（基本上每天更新一个版本），已经补齐了大部分基本的功能。 GitHub star 也接近 30K，有数百位社区成员给 Multica 贡献了代码，每个月在 Multica 上的 token 消耗超过了 3000 亿，Multica 帮助用户完成了几十万个 Task。 感谢大家支持！