DeepSeek Harness一夜把 Codex 和 Claude Code 都"收编"了，网友：这波是降维打击

DeepSeek Harness（dsh）刚刚更新到 rc.8，最炸的变化是：Claude Code 和 Codex 现在都能被 dsh 直接调起来，当成"子代理"使唤。也就是说，一个开源框架，正在把两大编程 Agent 变成自己流水线上的打工人。有网友实测后直呼：这操作有点狠。

从"能对接"到"能指挥"

其实 Claude Code 和 Codex 进入 dsh 的视野并不是第一次。8 月 17 日的 rc.7 里，这两个 Agent 的子代理任务就已经被接进了 dsh 的 Job Panel，用户可以在任务面板里看它们跑。

但那时候更多是"接进来看着"，rc.8 这一步是把关系彻底捋顺了：dsh 变成了主代理，负责拆目标、分任务、汇总结果；Codex、Claude Code 变成外部编码子代理，专心干体力活。配合社区插件 dsh-agent-teams，甚至可以按依赖关系把多个子代理拉起来组队干活。

换句话说，dsh 这个框架，现在不止是能"调用"Codex 和 Claude Code 的接口，而是能拿它们"带团队"——而且是跨模型、跨厂商、跨工具地带。

有位群友实测后说得挺形象：DeepSeek 这波直接把 Codex 和 Claude Code 都"降级"成了 subagent，哈哈哈。这话糙理不糙——两个原本各自独立、被广泛认可的编程 Agent，如今在 dsh 的调度视角里，成了可以按需装卸、按角色分配任务的"零件"。

多 Agent 不是免费的午餐

当然，dsh 官方和不少实测者也都提了同一句话：多代理协作不会自动带来质量提升。

子代理越多，权限管理、Token 消耗、重复修改、结果冲突的风险也越大。想真正拿去生产环境用，还得老老实实地给每个实例限定工作目录、可用工具、并发上限和交付格式，最后由父任务做一遍终验证——不是甩手扔进去就能躺赢。

这也是这次更新被讨论的另一面：跨 Agent 编排听起来很酷，但工程上的"脏活"——权限隔离、状态管理、结果校验——一样都少不了。

多模态也一起补齐了

除了子代理这条主线，rc.8 还顺手把多模态短板补上了：DeepSeek 模型适配器开放了原生图片请求配置，/goal、/plan 等核心命令首次支持图文混合输入，截图可以直接丢进任务里跑。对于本身不支持视觉的模型，dsh 会自动降级成 OCR + 像素扫描，硬给纯文本模型拼出一套"看图"能力。

14 项更新集中砸在同一个版本里，多模态、子代理管理、Windows 兼容性三线齐进——不难看出 dsh 团队想把这个框架往"能落地"的方向推得更快。

写在最后

一个刚开源半个月出头的框架，已经能把 Claude Code 和 Codex 这样体量的产品变成自己调度体系里的一环，这个速度和野心都不算小。至于跨模型、跨工具的"带队"能力最终能不能扛住真实生产环境的复杂度，还得看后续版本怎么处理权限和状态管理这些"脏活"。

但至少从这一波网友的实测反馈看，dsh 这出"以子之矛攻子之盾"的戏码，已经足够让人多看两眼了。

JOTO 企业落地观察

• 企业若引入 dsh 类框架构建智能体编排系统，需同步建立子代理权限白名单机制，尤其对 Codex 在 CI/CD 中的非交互式文件读写行为，必须绑定最小作用域路径与沙箱执行环境。
• 多子代理并行场景下，父任务的终验证逻辑不能简化为结果拼接；企业需预置结构化交付 Schema，并将校验规则嵌入 dsh 的 post-hook 流程，否则易因模型输出格式漂移导致下游中断。
• dsh 对图文混合输入的 OCR+像素扫描降级方案，暴露了纯文本模型在多模态任务中的固有瓶颈；企业若依赖该能力做代码截图分析，应将其视为临时过渡方案，而非长期架构设计。
• Windows PTY 终端持久会话的补全，意味着 dsh 开始覆盖企业内网常见开发终端环境；但 PowerShell 模块加载状态的跨调用保持，仍需验证其在高并发子代理场景下的内存泄漏风险。