在群里 @ 一位虚拟员工
@ 不是一个 HTTP 请求排队，而是往 ta 的虚拟邮箱投一封信。消息旁边那个徽标就是这封信的状态：排队 = 未读，开跑 = 处理中，跑完 = 已读，失败与取消单独标出。回帖边收 SSE 边吐字，同事中途插一句会当场掐断上游、按新消息重答。
- 同一个（员工, 群）同时只跑一封，群内严格 FIFO
- 员工回复里的 @ 交给下一位，接龙层数上限 3
- 思考链只在轨迹页看，永不进群
功能，一段一段看
每段录屏后面那条链接指的不是营销页，是这能力在仓库里的实现说明：调度、执行、上下文三层各写在哪一节、为什么那样设计。数字都是实测或代码里的常量，不是配置上限。
录屏跑在一个演示环境里：模型端点是内置的 demo://local，终端连的是本机 ttyd 夹具，所以画面里看不到逐字流式、思考链和 token 用量——演示端点一次给完一条回帖、既不吐增量也不回报用量，界面就按口径写「这条后端不回报用量」。接真上游以后这三条都换成实测值，正文里说的 SSE、思考链标签页与命中率是那时候的行为。
一张工作台，多个群同时推进
群就是 stream。首页用卡片网格或列表铺开，右上角切 2/4/9 分屏，每格都能直接 @ 派活；群边框跟着任务状态闪——排队是黄色，刚推进过是绿色。员工详情页的 Stream flow 把「哪一封信在哪一格被领走」画成时间线：横轴是进入时间片的时间，纵轴按群权重从高到低。
- 每位员工按各群权重（1–20，可单独覆盖）用最大余额法分这一格的预算
- 任务用比较并写领取，跑着的孤儿任务由过期回收兜住
- 常驻 worker 让队列在没有浏览器时也往前走
为什么 ta 是这么答的
每一轮模型看见了什么，都能重建出来。轨迹检视器列出这一步的提示词块与缓存断点在哪，思考链单独一个标签页读（它不进流式正文），用量与 KV 命中按群加权汇总——上游没回报用量的那些轮子直接写「不回报」，不拿 0% 冒充结果。
- 稳定块在前、每轮都变的块垫底，前缀缓存才吃得住
- 压缩在后台把水位线推上去，覆盖范围可枚举并对账
- 超限的那几份摘要如实记成「这一步没并进去」
人和虚拟员工 attach 同一个会话
登记了虚拟机、又填了控制台网关地址的群，顶栏会多出一个 SSH 控制台入口，「接入本群的机器」每一行也能直接点开。宽窗口是真分屏：左边聊天与输入框照常用，右边是终端。推荐用 ttyd -p 7681 tmux new-session -A -s work 起网关，这样你可以一边看 dmesg -wT，一边 watch 虚拟员工操作。
- 浏览器直连网关，WorkStream 只存地址、不代理会话
- VM 口令没有理由下发到前端：网关用它自己的认证
- 网关地址写入口只收 ws/wss/http/https，带
user:pass@、查询串或锚点当场拒绝