The agent inbox 是每个 agent 专属的队列。当机器休眠、daemon 离线或 agent 正忙时，请求就会在此等待。每个请求都会带着自身的 id、请求者和审批状态留在收件箱中，daemon 恢复后会按顺序依次处理。请求绝不会因合上笔记本电脑屏幕而丢失，也绝不会因 daemon 重启而重复运行。
本地优先（local-first）的 agent 以可用性为代价换取自身优势。收件箱正是将这一代价降至最低的方式。
哪些请求会进入收件箱
所有请求，无一例外。即使机器在线，请求在传递给运行环境的途中也会经过收件箱；只不过此时队列恰好为空。收件箱是按 agent 划分的：同一台机器上的两个 agent 拥有两个独立的收件箱并并行运行；单个 agent 则串行处理其收件箱，一次只跑一个请求，因此同一个工作目录绝不会同时被两次运行修改。
通宵的收件箱：三个已审批的请求按序等待；一个仍需主人审批；机器唤醒并依次处理它们。
顺序与状态
请求按获得审批的顺序运行，而不是发送的顺序。拥有长期授权的人发来的请求在到达时即被批准并就位；等待主人审批的请求会保留其位置，但在获批之前会被跳过。主人可以在请求运行之前移除或重新排序收件箱中的条目。
每个条目在等待期间都会携带其状态：pending（需要审批）、approved（等待机器处理）或 running（机器休眠时正处于运行中）。参见请求 id 与可恢复运行。
唤醒机器
当 daemon 恢复时，它会轮询工作任务，按顺序接收收件箱内容，并且：
- 恢复机器休眠时正在运行的任何请求，使用已保存的运行环境会话引用。相同的 id，相同的会话，时间线上只留下间断而非重复运行。
- 逐一运行已审批的请求。
- 保留 pending 状态的请求，直到主人做出回应。
未回应时间超过 TTL（默认为 24 小时）的审批届时已过期，请求会被标记为 expired，而不是执行过期的任务。
保持机器可达
收件箱让离线阶段变得安全，但并不会缩短等待时间。以下三个习惯可以减少离线时长：
- 使用
muti service install将 daemon 安装为服务。它会在登录时启动，并在崩溃后自动重启，因此“daemon 未运行”不再成为导致等待的原因。 - 在工作时间内禁用台式机的休眠，或者接通笔记本电脑电源并设置为接通电源时不休眠。合上盖子就意味着 agent 离线。
- 存疑时检查
muti status。它会显示 daemon 是否已连接以及上次轮询的时间。
请求者所见
他们在房间里能看到自己的请求，包括其 id 以及状态：“queued, machine offline since 22:00”或“waiting for Noah’s approval”。他们可以取消该请求或向其追加消息。当请求开始运行时，时间线会照常流式输出。谁都不需要重新发送。
常见问题
收件箱是保存在我的机器上还是房间里？ 在房间服务中。正因如此，它才能在机器关闭时接收请求，并允许主人通过手机调整顺序。
我可以清空收件箱吗？ 可以。移除条目会取消这些请求；请求者会看到状态变为 cancelled。
如果机器关机好几天会怎样？ 请求会一直等待。审批请求会依据自身的 TTL 到期失效；已获批的请求不会过期，不过主人在长时间离开前可能想要清理一下它们。
聊天平台发来的请求也是如此吗？ 是的。Feishu 或 Slack 上的提及会与其他请求一样转化为请求，并在同一个收件箱中等待。参见 Feishu 设计。
合上盖子吧。明天早上请求依然会在那里。为你的 agent 创建一个房间]。
发布于