[🛠] AI Orchestration #3: 只在 Telegram 里给出目标，实测 AI Orchestrator

✨ GPT-5.6 Sol 的总结

不指定项目路径或 Agent，只通过 Telegram 提出结果要求，逐一解决问题，直到 PDF 和 XLSX 返回为止。

Telegram 自然语言目标指令与项目自动发现

我想在 Telegram 里说一句“把这个结果做出来”，然后由 AI Orchestrator 找到项目、拆分任务、修正有问题的成果，再把文件发回来。如果只是调用一次 Codex 并返回回答，就没有必要专门做一个 Orchestrator。

第一个障碍是权限。即使在每位员工的 Cell 中，系统级 Codex 限制也让它很难发现启动时打开的 Workspace 之外的项目。我取消了对同一 macOS 用户所拥有项目的这项限制，但仍保留对 push、部署、外部发送等会影响外部环境的操作在执行前进行审批。

Telethon CLI 按 Topic 回收响应与附件

我制作了基于 Telethon 的 CLI，用它向 AI Orchestrator Bot 发送命令，并接收回复和附件。认证信息与用户 Session 放在仓库之外，每个项目的 Topic 则作为一个工作单元。

但第一版 CLI 只要发出消息就可能以成功状态退出。即使 Bot 的最终回复或文件根本没有到达，命令也会被视为成功。

我把完成条件从本地命令结束改成实际收到 Telegram 回复和附件。即使同时向不同 Topic 提交任务，每个 OpenClaw Session 也能分别保留上下文，并把结果送回原来的 Topic。

OpenClaw Session 与 Codex 并行执行的职责划分

OpenClaw 直接创建的短任务会丢失完成事件，而 Codex native sub-agent 能稳定收集并行任务的结果。工作已经完成却无法回收完成状态的结构，不能作为 Orchestrator 的执行基准。

只靠 OpenClaw 的 Task Flow，很难把子任务的执行状态与完成状态绑定到一份统一的基准记录。因此我不再把 Task Flow 当作唯一标准：OpenClaw 负责 Telegram、Topic、Session 和 Memory，Codex 负责项目发现、任务拆分、并行执行、整合与复验。

Telegram 进度状态流式更新

长任务期间没有任何消息，就无法判断流程是否已经停止；直接输出内部命令，又会让 Telegram 看起来像终端转储。执行期间，我最多更新四行韩语状态，最终结果到达后再删除这条进度消息。

现在只看 Telegram，也能分辨系统是在收集资料，还是在制作成果物。

Agent、Skill、Tool 自动选择与成果物复验

各项功能连接起来后，我故意采用最麻烦的方式进行测试。我担任最高决策者，让 Codex 代理 CEO，只把结果要求交给 AI Orchestrator。项目路径、模型、Agent、Skill、Tool 和执行顺序一个都没有指定。

AI Orchestrator 找到相关项目，选择所需的 Skill 与 Tool，并行运行分别承担规划、技术和验证工作的 Codex native sub-agent。即使我没有告诉它路径和方法，它也能自行安排谁负责什么。

返回的 PDF 与 XLSX 也不是第一次就完全正常。PDF 因 TTC 字体导致韩文损坏，我改用 TTF 重新渲染；XLSX 则修正错位的日期显示和列结构，再重新检查所有工作表的公式与显示。

请求发出22分6秒后，CEO Pilot 决策简报 PDF 和两周执行管理 XLSX 返回到原来的 Telegram Topic。从 Telegram 再次下载的文件，其 SHA-256 与生成原件一致。这不只是消息里声称完成，而是实际文件确实完成了往返。

单用户端到端验证与多用户隔离缺口

单用户端到端流程已经完整跑通，但22分钟对日常小任务来说仍然太长。最终成果还是由创建它的 Agent 自己复验，因此不能称为独立验证。我也尚未直接测试把所有子任务状态放进同一个 Task Graph、只确认一次最终完成的 controller，以及不同员工之间的 Session 隔离。

下一轮实测首先要确认两名员工的 Session 是否真的不会混在一起。之后还要找出22分钟流程中耗时最长的瓶颈。只有两项都通过，系统才能从个人实测走向员工共同使用。