# 通过现有 MCP 工具工作

调用前发现宿主的 Task Conductor 服务、说明及当前输入输出契约，使用实际命名空间；不直接修改数据库或文件替代 MCP 操作。

## 提交工作

- 明确用户目标、预期交付、执行时机和已有绝对工作目录。优先使用已有上下文和可核实的信息；仍缺少影响任务定义或授权的必要事实时询问。插件或缓存目录不是任务工作目录；除非已确认 stdio 启动目录正确，否则显式提供 workspace。
- 调用 `executor_list`，只选择已有、就绪且适用于用户授权工作的执行端。适配器就绪不证明原生登录或工具权限。
- 提供完整节点、依赖和执行端，写清各节点的工作要求与验收标准；一个节点足够时不增加节点。提交前澄清重要歧义及有后果的操作。后台协调者负责推进这些节点。
- 从 `task_create` 当前契约读取时间、资源与去重语义。响应不明时保留原提交身份和参数，不换 requestKey 重放。
- 只为已授权工作调用 `task_create`，保存并报告 Task ID 和 workspace。提交仅证明已持久接收，不证明成功。

Pi 和 dsh 的已连接持久会话可自动收到后台事件，无须持续轮询；模型省略 `notification`，由接入层绑定原会话。dsh 的默认 workspace 是当前原生会话的固定 cwd，可用 `/task-conductor status` 核对；子代理不能借用父连接，应由主会话提交。通知未出现时查询原任务，配置与补投方式见[通知设置](installation.md#pi-与-dsh-通知设置)。

## 查询进度与交付

用 `task_list` 查任务、`task_get` 查定义、`task_run_list` 查运行历史、`task_run_get` 查详情与已验收交付。分页保持过滤条件并使用返回游标，不进行快速无界轮询。

区分未来触发状态与具体 Run 结果。依据记录说明工作尚未触发、执行中、等待事实、失败或已交付；通过 `task_run_get` 读取已验收交付内容，不把原始输出或协议 turn 结束当作交付。

## 持续对话与补充执行

用 `task_message_send` 联系 Task 协调者，`task_message_list` 查看公开对话。节点不是独立聊天入口。已保存或提交的回执不证明事实已被考虑或工作已完成。

## 回答问题

读取最新未回答问题及期限，向用户展示实际问题和已完成工作。用 `task_question_answer` 提交用户原意，遵循 Task、问题身份和去重契约。该操作返回输入回执，执行结果仍需查询所属 Run。

## 控制未来触发或取消 Run

`task_schedule_control` 控制未来触发，`task_run_cancel` 停止具体 Run。先确认用户要控制的范围；更改未来触发不取消当前 Run，取消也不回滚外部副作用。

对于中断或外部结果不明，报告阻断并要求核查，不自动重试、重放已完成节点、切换执行端、改 DAG 或创建替代任务。

服务管理使用现有 `task-conductor` CLI。通过命令帮助查询配置、执行端和生命周期操作；沿用用户的管理请求，重启前核查活动及待回答 Run。