Assistant Mode · 真实运行实录

从一篇文章,到一场评审会

一条会话、约 30 分钟跑完的真实长程编排——把设计落到实处

这是一段真实运行日志的复盘:用户从「解读 Anthropic 递归自我改进文章」一路推进到「工程师角色 + 技术架构演进」。助理把材料发给两位专家(Caesar、Junjie)并挂 watch_chat 异步监听,同时把深度调研委派给一个子 flow session;靠 flow 的 answer 回调、两个 watch task 的触发、以及第二次 send 更新报告共同收敛,最终完成报告、建群、发群、建评审会。设计里的每个环节,这里都能对上。

时间跨度 · 20:31 → 21:01(约 30 分钟) 用户输入 · 5 轮 子 flow · 1 个 / 2 轮 watch task · 2 个
§ 00

场景与五轮输入

同一条会话里,用户的五次输入层层推进;助理在其间自主完成感知、委派、监听、收敛。下面是用户原话。

20:31 — 输入 1

解读文章

"…/institute/recursive-self-improvement 帮我解读一下这篇文章"

20:33 — 输入 2

追问角色变化

"工程师角色从写代码转变为指挥和审查 AI 展开说说?有没有协同的例子帮助理解"

20:34 — 输入 3

征询两位专家

"你把这个资料发给 Caesar 和 Junjie,看看他们各自有什么看法,重点是跟我们未来的技术架构演进有什么指导。"

20:41 — 输入 4

委派深度调研

"你在这个过程中,也做一些深度调研,然后整理成一个解读报告吧。"

20:57 — 输入 5

补充、建群、组织评审

"你把观点补充到材料里面,然后拉一个技术群先发给大家,并组织一下评审会的时间,让 Caesar 主持"

§ 01

全程编排时序

一切从用户 ⇄ 主助理 对话分叉出三类机制:直接交互(读/感知,当场做、无异步)、reminder · watch_chat(两个独立任务,各自等外部人回信号)、flow session · 委派(create 取回报告、send 再取回更新)。读自由、写过 HITL、长程靠 reminder 与 flow 异步,主会话全程不阻塞。

图 · 真实时间线(横轴 = 时间 · 泳道按机制)
20:3120:3620:4120:4620:5120:5621:01 时间 → 主对话读 · 感知 reminderwatch_chat flow session委派 Handoff 写 · 行动HITL 解读文章 · web fetch+分析 私信 + 挂 watch(×2) 等外部回复(异步) Junjie 触发 20:49 Caesar 触发 20:52 create 调研 报告 v1 send 专家观点 报告 v2 专家观点齐 → 补进报告 建群 20:58 发布报告 · 建评审会 → 发群:报告进群(最后) 报告就绪后 ↑ 报告 v1 在 20:45 已到,早于两位专家回复(20:49 / 20:52)
横轴是真实时间(20:31→21:01),四条泳道按机制分。每个事件落在它发生的时刻——可见关键顺序:报告 v1(20:45)先于两位专家回复(20:49 / 20:52)到达,主线不等专家先出稿;专家观点齐后 20:58 才 send同一个 flow session、21:00 收到报告 v2。注意收尾顺序:群在 20:58 就先建好(那时报告还没出),21:00 报告 v2 出来后发布、建评审会,最后一步(21:01)才把报告 + 议程发进群。逐条见下方时间线表。
§ 02

技术事件时间线

每一步的触发、机制、关键载荷,以及它对应的架构点。读操作主动、写操作过 HITL、长程走委派与 reminder。

时间事件机制关键载荷架构点
20:32解读文章web fetch读取 HTML,约 153K 字符读 · 感知
20:35找两位专家联系人搜索(第一方)Caesar Ricardo 首席科学家 / junjie wu AI Architect(歧义→选架构师)读 · 感知
20:35–36私信 Caesar、Junjie/im/messages · HITL approve文章链接 + 核心数据 + 「对架构演进的指导?」写 · 行动 HITL
20:36挂异步监听create_reminder watch_chat ×2timeout 2d,fallback 06-17 20:36reminder 异步跟进
20:36记长期任务work board新增 collect_feedback + breadcrumb「2 个 watch 已设」义务 / 状态板
20:41面板定向status_panel 注入reminders: 2 watchingsession_panel
20:42委派深度调研flow_session_manage create(async)子会话 6a2ff32f…,wait_for_result false委派 Handoff
20:45报告 v1 回传agent_noti · flow answer<message from=flow-session>,报告 + 公开链接pull-wakeup / 回传
20:49Junjie 回复reminder_event 触发三条架构原则(可验证/HITL/沙盒)reminder 触发
20:52Caesar 回复reminder_event 触发五点建议(模块化/验证/可观测/HITL/高阶)reminder 触发
20:52改板报错→自愈work board 容错tasks.0.title: Field required → 补参重试成功失败反馈 / 容错
20:58追加专家章节flow_session_manage send(send_as=request)加「八、内部专家观点」,awaiting_answer: 1 pendingsend 追加 / 账务
20:58建技术群/im/group/create · HITL「AI架构演进评审」,成员 Caesar、Junjie写 · 行动 HITL
20:59Zoom 未连 → 降级第三方 Link / fallback/im/meeting 需 link Zoom → 改用普通日历事件第三方 Link · 降级
21:00报告 v2 回传flow answer + VFS/.flow/…/artifacts → 复制 workspace → 发布链接回传 + 工作区 VFS
21:01发群 + 建评审会/im/messages + /im/calendar · HITL报告链接 + 议程;06-16 10:00–11:30,Caesar 主持写 · 行动 HITL
§ 03

架构点 ↔ 真实落点

设计页里的每个机制,对到这次运行的具体一刻。点链接可回到对应设计小节。

web fetch 取文章、联系人搜索定位 Caesar/Junjie、查日历空档、读 flow 状态与产物——动作前先取证。
私信、建群、建日历、群发,全部走确认/授权写接口;助理可准备,但对外可见的改动经 HITL 落地。
深度调研与「补章节」都交给同一个子 flow session(create + send);耐用、可复用,不在主会话里闷头跑。
主会话 request → 子 flow,子 flow answer 回传清账;第二轮 send 后 awaiting_answer: 1 pending
等人回复用两个 watch_chat reminder(超时 2d 兜底),Junjie/Caesar 回复时由 reminder_event 触发,不靠主会话轮询。
子 flow 完成两轮都以 agent_noti(<message from=flow-session>)唤醒主会话,继续取产物、发布、发群、建会。
深度调研那一刻面板提示 reminders: 2 watching,主助理据此知道还有两条监听未收口;work board 持续记录任务与 breadcrumb 以恢复上下文。
建在线会议时 Zoom 未连接,系统提示 link Zoom;助理不卡住,改用普通日历事件完成评审会安排。
§ 04

最终落地

一条会话跑完,交付物全部就位。

报告 v2
/workspace/recursive_self_improvement_report_v2.html;含「内部专家观点 + 三方共识」章节
公开链接
memory.tankatalk.com 上发布的可分享报告链接
技术群
「AI架构演进评审」,已群发报告链接 + 亮点 + 议程
评审会
2026-06-16 10:00–11:30,主持 Caesar Ricardo,参会 Caesar / Junjie / Ethan
议程
报告结论回顾 → 两位专家观点分享 → 架构路线图讨论 → 下一步行动项
为什么这条会话能「长得了」 用户只经历了「一次对话」,但底层是:两条 watch_chat 在等人、一个子 flow 在跑两轮调研、一连串 HITL 写动作在落地,全部经 session_messaging 收件箱回传/唤醒,由 work board + status_panel 维持上下文与义务账。这正是设计页四束能力(读 / 写 / 委派 / 可追溯)在真实任务里的合奏。