68 lines
4.9 KiB
Markdown
68 lines
4.9 KiB
Markdown
# 1
|
||
|
||
在`investigations`新建一个调研。
|
||
本次调研为通知唤醒机制，我讲一下思路：
|
||
1. 主会话（当前会话）启动一个子会话，要求子会话启动后直接Sleep 2分钟。主会话关闭本回合。
|
||
2. 子会话sleep 2分钟后，发送反馈到主会话。
|
||
3. 主会话被激活。调研就结束了。
|
||
|
||
我觉得难点，或者不清楚的在于如何取得当前会话id。若这个能取到，交给子会话，子会话应该能回调回来。
|
||
|
||
这个调研主要是解决：
|
||
现在docs/workflow是轮询机制，子会话跑几十分钟，主会话就一直用心跳来测试，浪费时间。
|
||
|
||
---
|
||
|
||
基于以上，有什么问题请提出。
|
||
先对齐思路。
|
||
|
||
我的理解：这个调研目标不是改 `docs/workflows`，而是先验证 Codex app 里是否存在真实“子会话完成后唤醒父会话”的路径。现有 [slide-task-orchestration.md](</C:/Users/wangq/Documents/Codex/video-workbench/docs/workflows/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](</C:/Users/wangq/Documents/Codex/video-workbench/investigations/2026-06-24-thread-notification-wakeup/test-1-report.md>)。子会话结果文件也存在：[test-1-child-result.md](</C:/Users/wangq/Documents/Codex/video-workbench/investigations/2026-06-24-thread-notification-wakeup/test-1-child-result.md>)。
|
||
|
||
我同时更新了调研 README 和索引。当前结论是：最小回调唤醒机制可用；但还不应直接推广到生产 slide workflow，下一步应做一次“真实 slide package 完成后再回调”的生产形态验证。
|
||
|