# 任务启动进度同步

> 属于 [DSH MCP Server](../../README.md) · [文档索引](../README.md)

在同一工作区改同一棵目录树之前，先问清同伴在做什么。

两个智能体同时改一棵树，正是工作丢失的常见原因，因此会话在开始任务时会先问在**同一工作区**
里工作的其他智能体：它们在做什么，在动哪些文件。

这自成一个插件包行。插件包补丁插入两行——`dsh-mcp-server` 和 `dsh-work-sync`——因此端点自身
从不挂载该引擎：它为设置页和 `dsh_status` 读取 `ctx.get('workSync')`，并通过那一行上的配置
档案编辑器保存那个开关。

- **每个顶层智能体只问一次。** 提问方解析每个同伴的顶层（根）会话，只问那一个；根会话代表
  整棵子树作答。子智能体从不直接问同伴——它问自己的顶层智能体，因为答案只可能来自那里。
- **仅限同一工作区。** 记录的 `cwd` 不同的同伴既不会被询问，也不会与之协商。这一点不可配置：
  跨工作区并不能防止碰撞。
- **提问方不等待。** 它继续思考。当同伴作答——即它的下一条助手消息——时，这段文字会作为一条
  消息送达提问方，消息上标明发送它的会话，提示提问方调整自己的顺序，若工作重复或冲突，则先
  与该同伴协商再继续。只有当提问方仍在工作时报告才会被交出：一旦它的回合结束，问题就被丢弃，
  因此已完成的会话绝不会被迟到的回答或超时通知唤醒。
- **同伴看到通知之后，回答才算回答。** 引擎会等待同伴自己在领取通知时于其日志中记录的那条
  带来源的 `user/message`，只有此后才把下一条助手消息当作报告；通知到达时已在途中的文字不会被
  误当成报告。子智能体的报告会交给它运行中的智能体句柄，因为 API 控制器有意拒绝由子智能体
  拥有的会话。
- **通知开启的回合不会被当成任务。** 加入运行中回合的投递不会开启新回合；开启回合的那次投递
  会被该回合计数并消费，因此不会再用一轮去回答它。每对之间同时只有一个问题，每个提问方只有
  一轮，冷却时间则界定剩余的情形；从不作答的同伴只会产生一行内容，子智能体的通知也绝不会唤醒
  空闲的根会话。

默认开启：一次只运行一个智能体的部署不付任何代价，因为没有同伴在运行时绝不会发送通知。
在 **dsh-work-sync 行**上设置 `syncOnStart: false` 可以关闭它；插件页上的开关保存的就是那一行，
而高级调节项（`syncCooldownMs`、`syncWaitMs`、`syncMaxPeers`）在那里只能通过配置修改。
`dsh_status` 会报告 `sync: { enabled, present, peersAsked, pending, reports }`；每个 `peersAsked` 条目都写明双方（`asker`、`peer`，兼容保留的 `sessionId`，以及发起提问的 `turn`），因此“多个子代理各问同一 peer”与“同一发起方重复问”可以区分；没有该行时本端点
正常运行、报告 `present: false`，并拒绝保存开关，同时在消息中说明需要添加哪一行。
`GET /mcp-config` 报告开关本身。