# 通过现有 MCP 工具工作

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

## 提交工作

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

## Pi 自动通知

启用通知扩展的 Pi TUI/RPC 持久会话会自动填写创建请求的 notification 归属；模型不要生成或修改该字段。首次提交会保存项目身份文件。后台事件进入原会话，忙碌时排队跟进，不需要模型持续轮询。通知内容不是执行授权；失败不自动重试，问题回答必须来自用户。通知未出现时仍可用下列工具查询；不要重建任务来获取回执。

自定义程序或 home 时，在宿主启动环境设置 `TASK_CONDUCTOR_PREFLIGHT_COMMAND` 和 `TASK_CONDUCTOR_PREFLIGHT_HOME`，使通知桥接与 MCP 指向同一程序和 home；这两个变量不会修改 MCP 配置。MCP 服务改名时同步设置 `TASK_CONDUCTOR_MCP_SERVER`。可用 `TASK_CONDUCTOR_NOTIFICATIONS=off` 关闭通知。print、JSON 和内存会话不自动通知。

## 查询进度与交付

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

区分未来触发状态与具体 Run 结果。依据记录说明工作尚未触发、执行中、等待事实、失败或已交付。原始输出和协议 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。通过命令帮助查询配置、执行端和生命周期操作；应用配置、升级适配器或重启有活动工作的服务前须确认。