knowledge-vault/discussions/creative/在路上/在路上-video-调研唤醒机制.md

1

在investigations新建一个调研。 本次调研为通知唤醒机制，我讲一下思路：

1. 主会话（当前会话）启动一个子会话，要求子会话启动后直接Sleep 2分钟。主会话关闭本回合。
2. 子会话sleep 2分钟后，发送反馈到主会话。
3. 主会话被激活。调研就结束了。

我觉得难点，或者不清楚的在于如何取得当前会话id。若这个能取到，交给子会话，子会话应该能回调回来。

这个调研主要是解决： 现在docs/workflow是轮询机制，子会话跑几十分钟，主会话就一直用心跳来测试，浪费时间。

---

基于以上，有什么问题请提出。 先对齐思路。

我的理解：这个调研目标不是改 docs/workflows，而是先验证 Codex app 里是否存在真实“子会话完成后唤醒父会话”的路径。现有 slide-task-orchestration.md 是父会话等待+轮询；这次应在 investigations/2026-06-24-thread-notification-wakeup/ 里做一个最小实验，验证后再决定是否提升为工作流规则。

我认为你的思路基本成立，关键点有三个：

1. 当前父会话 id 可以取得，但目前证据是“可观测取得”，不是专门 API。刚才 list_threads 返回的第一项就是本会话，id 是 019ef999-07d2-7333-99b4-d5d2da040406，标题/预览都匹配当前请求。
2. 子会话理论上可以用 send_message_to_thread(parentThreadId, prompt) 回写父会话。真正要测的是：父会话结束本回合后，这个回写是否会让主会话自动激活，而不是只是在后台队列里多了一条消息。
3. 不应先用 automation_update heartbeat，因为那会变成定时唤醒/轮询替代品，容易污染结论。第一轮应只测“子会话 sleep -> 回写父 thread”。

我建议调研的成功标准写得很窄：父会话创建子会话并结束；子会话 Start-Sleep 120 后发送一条带时间戳、child id、parent id 的消息回父会话；如果当前会话自动出现后续回合并能读取该消息，就判定“直接回写唤醒可用”。同时让子会话写一个 result.md，这样即使唤醒失败，也有文件证据可查。

唯一需要你确认的问题：第一轮测试是否就用当前会话 id 019ef999-07d2-7333-99b4-d5d2da040406 作为父会话目标，允许子会话在 2 分钟后直接向本会话发送回写消息？

2

第一轮测试是否就用当前会话 id 019ef999-07d2-7333-99b4-d5d2da040406 作为父会话目标，允许子会话在 2 分钟后直接向本会话发送回写消息？

刚刚交流时，实际有两个会话在同时进行。 现在另外一个已经关闭了。 我觉得，这个当前会话 id 应该是一个现取的观测值。 我可以保证的是，不论是正式调研测试，还是将来正式的流程运行，只有一个主会话在进行。

我刚刚尝试了下，从我这里，没法取得这个id，没有相关的命令。 所以，你可以现在在取一下这个会话id。现在只有一个活动会话了。

现取结果：当前主会话 id 仍是

019ef999-07d2-7333-99b4-d5d2da040406

当前列表里还有旧会话，但它们是 idle 或 notLoaded；唯一 active 且标题/预览匹配本次“调研会话唤醒机制”的就是这个线程。

我建议调研里把“当前会话 id 获取方式”记录为：由父会话在运行时通过 Codex app 线程列表观测，选择 status=active、cwd=video-workbench、标题/预览匹配当前任务的线程；这是可行但仍需验证的机制，不是稳定的命令行 API。

3

在用户的授权下，由父会话在运行时通过 Codex app 线程列表观测，选择 status=active、cwd=video-workbench、标题/预览匹配当前任务的线程

增加了触发条件，用户需要保证只有一个活动会话。这样基本不会错了。

已经对齐思路，现在可以设计这个调研。完了后，直接进行测试。

若主会话收到了子会话的通知，我觉得可以进一步进行调研结果/报告的输出。 若没有收到，我可以看见子会话是否关闭，这时我会介入。

测试通过：子会话 sleep 120 秒后用 send_message_to_thread 回写，父会话在没有主动轮询的情况下收到了回调并进入本回合。

已写入结果报告：test-1-report.md。子会话结果文件也存在：test-1-child-result.md。

我同时更新了调研 README 和索引。当前结论是：最小回调唤醒机制可用；但还不应直接推广到生产 slide workflow，下一步应做一次“真实 slide package 完成后再回调”的生产形态验证。