DeepSeek Harness Job Panel 子代理分工

症状：面板里能集中看到多个任务，但文件冲突、权限越界和失败接管仍然没人负责。
最快解法：不要按 Codex 或 Claude Code 的品牌固定分工，先为每个子代理任务写清目标、输入、工作区、权限、验收产物和失败负责人。

截至 2026 年 8 月 18 日，本文按 rc.7 Release 已确认的接入范围整理方法；任务权限、跨重启恢复和并发行为，仍应以写作当日的官方 Release、架构文档、代码变更和隔离测试为准。DeepSeek 官方公开资料可从其 GitHub 组织与相关 Agent 文档 继续核对；DeepSeek 也提供了 Claude Code 接入说明，但“能接入”不等于自动获得隔离或恢复能力。 (github.com)

这篇文章适合三类人：

• 想把大任务拆给多个子代理的独立开发者；
• 需要管理并行代码任务和仓库写入边界的小型研发团队；
• 负责远程执行环境、权限控制和任务恢复的平台工程师。

集中观察不等于自动隔离

DeepSeek Harness Job Panel 的价值是把多个任务的创建、状态和结果集中到一个观察面板里。但集中观察只解决“你在哪里看”的问题，没有自动解决以下至少 4 类工程责任：

1. 任务所有权不清。 主 Agent 可能已经修改认证模块，子代理又收到同一目标，最终出现重复执行、互相覆盖或两个结果都没人合并。
2. 工作区边界不清。 多个任务若直接写入同一个目录，文件修改、生成物、分支和锁文件都可能互相影响。
3. 权限继承不透明。 Job Panel 显示的是任务关系，不代表操作系统已经隔离文件、命令、网络和凭据。
4. 状态可见但不一定可恢复。 面板仍显示一个任务，不代表主进程退出、连接中断或机器重启后，任务一定继续运行。

因此，你应把 Job Panel 当作调度与观察层，把工作区、权限、日志和恢复机制当作执行环境层。OpenAI 对 Codex 的公开说明也把独立环境、代码修改、命令执行和可核验日志分别列为任务能力；这说明“任务能运行”和“结果能被接管”本来就是两件事。 (openai.com)

Codex 和 Claude Code 不按品牌分工，按任务契约分工

不要简单规定“Codex 负责写代码，Claude Code 负责审查”。这类规则会随版本、模型配置、工具安装状态和权限设置变化。更稳妥的方式，是先定义任务类型，再在当前环境中用最小任务验证某个子代理是否真的具备所需能力。

只读调研：共享输入，禁止写入

只读任务适合代码结构梳理、依赖调查、故障定位、测试计划和风险清单。输入应是固定路径、提交版本或任务附件，输出应是报告、文件清单、假设和证据，而不是直接改代码。

你可以让 Codex 或 Claude Code 读取同一份代码，但要明确：

• 不允许创建或修改源文件；
• 不允许执行部署、删除、迁移数据库等高风险命令；
• 输出必须标明读取的提交、文件路径和不确定项；
• 报告不能直接视为实现方案，必须由主 Agent 或人工负责人确认。

受控修改：一个目标，一个写入责任人

代码修改任务必须只有一个最终写入负责人。例如，一个子代理负责 src/auth/，另一个只负责测试夹具；不要让两个代理同时修改同一配置文件、同一接口定义或同一锁文件。

Codex 的官方任务说明提到，任务可以在独立环境中读取和编辑文件，并运行测试、代码检查和类型检查。你可以借鉴这种“任务环境 + 证据输出”思路，但不能据此推断 DeepSeek Harness Job Panel 在你的部署中自动提供同等隔离。 (openai.com)

构建测试：把执行环境写进输入

构建和测试任务的关键不是“谁更会写代码”，而是它是否能访问正确的依赖、脚本、环境变量和缓存。任务契约中至少写明：

• 使用哪个提交或工作区；
• 允许运行哪些构建、测试和静态检查命令；
• 测试失败时只报告，还是允许修复；
• 生成物放在哪里；
• 谁负责判断失败是代码问题、环境问题还是依赖问题。

外部工具任务：默认低权限，人工接管

涉及网络、云资源、发布、凭据、数据库或供应链的任务，应与普通代码修改分开。即使面板能显示审批或任务状态，也要在操作系统和执行账户层面限制权限。

Claude Code 的官方更新记录持续涉及权限提示、脚本执行和环境控制等能力变化，说明权限行为会随版本演进，不能只记住一次安装时的结果。每次升级后，都应重新核对允许路径、命令、网络和凭据范围。 (code.claude.com)

同一仓库适合并行写入吗

可以同时运行，但不建议同时写入同一个工作区。并发的价值来自任务彼此独立，而不是面板里同时出现更多任务。

你可以采用三种策略：

• 只读共享： 所有代理读取同一版本，只有一个代理负责修改。适合调研、审查、测试设计。
• 独立工作区： 每个修改任务使用独立目录、分支或 worktree，最后由明确的合并负责人处理差异。适合两个以上互不重叠的功能。
• 顺序合并： 先完成一个任务并验收，再把结果交给下一个代理。适合共享接口、数据库迁移、配置文件和大型重构。

选择依据应是修改范围与合并责任，而不是单纯追求并发数。Git 官方文档对 worktree 的独立工作目录机制有明确说明；但 worktree 只能降低文件覆盖风险，不能替你解决两个任务对同一业务决策的冲突。

Job Panel 如何管理子代理任务

建议你给每个任务分配一个不可复用的任务标识，例如 auth-read-01、auth-edit-01 和 auth-test-01。任务记录至少包含：

• 任务目标：一句话说明最终要改变什么；
• 输入来源：提交、文件路径、Issue 或上一个任务的交付物；
• 写入范围：允许修改的目录和禁止触碰的路径；
• 运行环境：命令、依赖、环境变量和网络要求；
• 验收产物：差异文件、测试结果、日志摘要和未完成项；
• 失败责任：谁判断失败、谁决定重试、谁有权回退。

这样处理后，主 Agent 不再依赖面板上的颜色或状态名称判断所有权，而是通过任务标识、状态记录和最终产物核验来决定下一步。

失败后由谁恢复

失败责任不能写成“由主 Agent 自动处理”，因为失败可能来自三种完全不同的原因：

• 输入失败： 路径错误、上下文不足、任务目标冲突；
• 执行失败： 权限不足、依赖缺失、命令失败或连接中断；
• 结果失败： 代码能运行，但没有满足验收条件。

建议采用以下规则：

1. 输入失败，由任务创建者修正契约后重发；
2. 执行失败，由平台负责人检查环境、权限和连接；
3. 结果失败，由原写入负责人返工；
4. 连续失败或涉及高风险操作时，暂停自动重试，交给人工接管。

不要因为面板仍显示任务，就推断任务已经在后台继续运行。取消、超时、主进程退出和远程连接中断后的行为，必须在隔离仓库中逐项测试，并保留实际日志。当前公开资料能够证明某些 Agent 支持任务执行或会话能力，但不能替你的 Job Panel 部署证明跨重启恢复一定存在。 (api-docs.deepseek.com)

用 5 步把分工落地

第 1 步：先冻结基线

为任务指定提交哈希、分支或只读快照。不要让子代理自行决定“当前最新代码”，否则主 Agent 在任务运行期间继续提交，会让结果难以复现。

第 2 步：拆出最小任务

每个子任务只保留一个主要目标。例如“分析登录流程并列出风险”是只读任务；“修改令牌刷新逻辑并补测试”是受控修改任务。不要把调研、实现、部署和回滚塞进同一个提示词。

第 3 步：设置写入与权限边界

为每个任务列出允许路径、禁止路径、命令白名单和网络要求。涉及密钥、生产环境或外部服务时，默认关闭自动执行，留下人工审批点。

第 4 步：先跑最小能力验证

在正式任务前，用一个小文件完成读取、修改、测试和失败取消验证。确认当前版本的 Codex 或 Claude Code 是否真的能完成目标，不要从品牌名称推断工具能力。

第 5 步：按证据验收并登记责任

验收时要求子代理提交差异文件、测试命令与结果、日志摘要、未完成项和已知风险。主 Agent 应能在不重跑全部步骤的情况下判断接受、返工或回退。

三种方案的条件式选择

如果你只需要一个明确结论，可以按下面的分支执行：

• 若任务只读、输出是报告，且没有文件写入： 选单子代理，或让多个代理只读并行。
• 若任务之间存在接口、配置或数据库依赖： 选串行多子代理，前一个任务验收后再启动下一个。
• 若任务修改范围完全不重叠，且每个任务有独立工作区与合并负责人： 选隔离并行。
• 若两个任务会写同一文件、同一锁文件或同一迁移脚本： 回退到串行合并。
• 若任务需要生产凭据、外部网络或删除性命令： 回退到人工审批，不使用无人值守并行。
• 若无法确认取消、超时或重启后的真实状态： 回退到可重建任务，不把面板状态当作持久化保证。

下面的任务契约表可以直接复制到团队的 Issue、Job Panel 备注或任务登记文件中：

为了避免把“并发”误认为“效率”，你还可以给方案打分。分数不是产品性能测试，而是团队在当前环境中的管理可控度：

评分只反映责任与风险，不代表 Codex 或 Claude Code 的模型能力排名。两个工具都可以承担只读、修改或测试任务，但最终选型仍应由当前版本的真实能力、权限配置和验收证据决定。

最后，把三类执行方式放进你的运行规划中：

如果你现在的方案是把多个 CLI 直接放在同一台机器、同一目录和同一套凭据下，真实缺点通常不是启动慢，而是文件互相覆盖、权限难以审计、失败后无法判断是否需要重跑。长期并行运行还会叠加磁盘、内存、远程连接和人工复核压力。此时，使用 MacDate 的远程 Mac 环境，把不同任务放进可区分的工作区，再按容量规划分配执行节点，通常比继续堆叠本地终端更容易控制；你可以先查看 MacDate 的 Mac 计算节点，再结合 DeepSeek Harness 后台任务验收 与 M4 计算节点数量规划 评估是否适合你的任务规模。

建议你先用两个低风险、互不修改同一文件的任务验证 Job Panel：一个只读分析，一个独立测试。只有当任务标识、工作区、权限、取消行为和交付证据都能被复核后，再扩大到串行多代理或隔离并行。