[🛠] AI Orchestration #4: 把 Telegram 后续任务从22分钟缩短到9分钟

✨ GPT-5.6 Sol 的总结

在真实工作 canary 中找出同一 Session 内的自锁、重复探索和一次性验证实现，并通过复用现有生成器、验证器与局部返工，将 Telegram 文件返回时间缩短了57.6%。

同一 Session 的 canary 引发的自锁

在前一天的实测中，我只通过 Telegram 给出目标，最终收到了 PDF 和 XLSX。项目发现、角色拆分、并行执行、返工和文件返回都跑通了，但耗时22分6秒。如果每个小型后续任务都需要这么久，实际使用起来还是会让人着急。

我没有另外搭建 benchmark，而是在同一个 Telegram Topic 里再次只给出目标：“保持质量不变，把22分钟的流程缩短。”我想直接观察 AI Orchestrator 能否自己找到真实瓶颈、修改共享 Workflow，并完成后续文件任务。

结果第一次验证就发生了自锁。AI Orchestrator 在处理当前请求时，把 canary 发进同一个 Session，随后又等待它的回复。新请求必须等当前 turn 结束后才能执行，而父任务又在等待这个新请求完成，于是双方都无法结束。

我只终止了正在等待的 CLI，并把产品修改 Topic 与 canary Topic 分开。这不是模型不会完成任务，而是执行边界出了问题：Orchestrator 不能在自己正占用的 Session 内等待下一项任务。

复用现有生成器与验证器进行局部返工

独立 Topic 中的第一个 canary 用17分35秒返回了文件。速度确实更快，但结果错误地把已经批准的 Pilot 再次标成等待批准。仅仅缩短时间还不能算通过。

沿着实际执行过程检查后，我发现系统反复查找同一份证据、轮询子任务，并且在开始生成产物后才补做 dependency 检查。明明已有通过验证的 PDF、XLSX 生成器和 verifier，却又临时搭建相似验证路径，也带来了明显成本。

我只在共享 Workflow 中保留了以下规则：

• 用一次有边界的 snapshot 固定所需证据。
• 通过完成 event 回收子任务结果，不重复 polling。
• 已有生成器或 verifier 时直接复用，不再新建一套实现。
• 只应用最新决策和数值的差异，只返工出现缺陷的范围。
• 最后只对完整产物执行一次验证，并对齐 Source provenance。

我只修正了第一版结果中错误的批准状态和文字，然后重新执行完整渲染与独立打开、重存验证。新的流程不再从头重做所有内容，而是只修改语义已经过时的部分，再检查整个结果的完整性。

9分23秒返回 Telegram 文件并保留质量门槛

返工 canary 在没有用户介入的情况下，用9分23秒把 PDF 和 XLSX 返回到 Telegram。相比最初的22分6秒缩短了57.6%，Orchestration tool call 也从56次降到21次。

这并不是靠跳过检查换来的速度。我重新检查了2页 PDF 和4个工作表 XLSX的渲染、结构、内容、公式以及独立 open/re-save。重新从 Telegram 下载的文件 hash 也与生成的原始文件一致。最后，系统还发现文件内的 Workflow provenance 仍指向旧 hash，并在不改动内容与结构的前提下只修正了这个值。

这里最重要的决定，是没有把第一个17分钟级的结果算作成功。如果最新决策本身是错的，缩短处理时间只会更快地产生错误结果。这次改进之所以通过，是因为质量 Gate 保持不变，而真实返回时间确实下降了。

单用户 v0.1 与多用户 Pilot 的边界

目前的单用户 v0.1 已经可以接收自然语言目标、寻找项目、拆分工作、验证结果，并通过 Telegram 返回文件。不过，现在还不能称为完全无人值守。这次仍然需要我以 CEO 的角色终止同一 Session 的自锁，指出第一版结果中的语义错误，并要求补上遗漏的本地 commit。

下一步不是再做一个 benchmark，而是在相同质量边界下继续交付真实、非敏感任务，积累处理时间并观察其分布与回归。等另一个用户的连接获得批准后，还要验证两个 Cell 同时运行时 Session、Memory 和文件不会混在一起。完整的 Task Flow controller 目前并不是这条用户路径上的关键瓶颈，因此继续作为独立的长期方向保留。