以交互为中心：Personal Agent 的关键不是 async subagent

TL;DR：Grok Bot、Muse 这类个人助理（PA）的关键能力，不是 delegate（async subagent）带来的并行吞吐，而是以交互为中心的组织方式：消息的优先级与抢占、steer 时把工具移交后台再异步通知、打断生成到一半的模型、事件触发时保持静默。agent 之间的内部通信尽可以原生高效，面向人的边界则必须消息化、可打断、可静默。Converge AI 开源的 a13n 提供了一个机制样本：steer/next_run 双投递、可重排收件箱、5 秒前台等待后工具转后台、exec-* 回执与异步结果通知——async subagent 只是六类输入源之一。

讨论 PA 怎么建时，delegate 常被当作胜负手：能不能把任务派给异步子代理，能不能并行推进，能不能在人离开后继续干活。这个判断直觉上成立，但它回答的是「agent 怎么多干活」，没有回答「人怎么跟它相处」。另一种构建取向把交互当作组织原则：系统围绕对话而非执行体展开，每条输入都要回答三个问题——何时进入模型上下文，是否打断当前工作，要不要出声。两种取向的差异，在 a13n 这类开源 harness 的架构契约里落成了具体条文。

以 agent 为中心的惯性

以 agent 为中心构建，注意力自然落在吞吐上：拆任务、派子代理、并行跑、异步回收结果，人是不定时来验收的外部角色。这种思路在 coding agent 上成立——任务边界清晰，验收可以延迟，吞吐就是效率。但 PA 面对的是另一种工作：订机票、回邮件、盯账单、安排日程，任务碎、上下文切换频繁，人随时可能插进来改主意。此时瓶颈不是并行度，而是接待能力：人插话时系统能不能立刻听见，听见之后能不能优雅地让出前台。

一场相关的争论把这个分歧推到了通信层。X 用户 Yuu（@QuantumTransf）质疑 agent 之间为什么要用 message 通信，「我们明明有更好的办法」；TikTok 工程师 Todd Zheng 进一步断言：「agent通信需要通过message只是因为人类自己觉得自己需要in the loop」，重点是原生 IPC，不必绕远路走人类的 message。Kowyo（@_kowyo_）则反对任何觉得人类不重要、人类影响 agent 效率的观点：「任何所谓的 Agent Experience 都是为了服务 Human Experience」。两派看似对立，实则分层：agent 之间的内部通信尽可以原生、高效，不必模仿人类消息；但面向人的边界必须消息化、可打断、可静默。以交互为中心不是拒绝异步，而是把异步安放在不干扰人的位置。

「何时打扰人」才是卖点

产品文案佐证了这个转向。Grok Bot（2026 年 8 月 11 日发布）的官方介绍强调「像同事一样给它发消息」「只有需要批准时才回来找你」，以及用久之后「知道何时该 ping 你、何时继续干活」。Muse（9 月 8 日发布）同样「围绕人们已有的沟通方式设计」，关掉应用后继续工作，「有变化或需要批准时再回来」，还能不经提示主动建议。两家都没有把 delegate 或并行吞吐当卖点，「何时打扰人」才是被反复书写的能力。

讨论者 Ham.DeepQueue 的比喻更直接：PA 应该像一个前台。异步委托是前台的基操，但前台的价值在于接待：知道哪件事该立刻通报，哪件事该做完再说，哪件事根本不必出声。消息的优先级和抢占、模型输出到一半时的打断、heartbeat 或 connector 事件触发时的静默，这些才是 PA 区别于「一群并行干活的 agent」的地方。

a13n：把交互写成协议

「以交互为中心」这个提法，出自 a13n 作者 Wh1isper 与 a13n 核心开发者 Henry（GitHub: zhm9484）的讨论。a13n 是 Converge AI 开源的 harness，所以这一节看的是提出者自己的项目，不是独立的第三方佐证。选它当样本的理由是材料可查：前一节引的只是 Grok Bot 和 Muse 的产品文案，本文没有这两款产品的实现材料；a13n 的 spec 与文档是公开的，优先级与抢占、打断生成中的模型、工具移交后台，都有条文可以逐条对照。以下机制出自这些 spec 与文档，描述的是契约规定的行为。

第一，输入被显式分类。Stream Protocol 把输入源分为 user、steering、context、recovery、async_subagent、background_process 六类。async subagent 的结果只是其中一类，与用户消息、后台进程结果平级，都进入同一个 Thread 收件箱。

第二，优先级和抢占由投递语义表达。每条消息带一个投递方式：steer（默认）并入当前运行，next_run 排队等下一次运行；还在 pending 的消息可以编辑、撤回、重排（PUT …/inbox/order）。steering: immediate 允许在模型生成或工具等待期间插入输入。文档写道，立即 steering 会「打断并恢复一个主模型请求」；如果当时在等工具，则保留工具执行、释放前台等待。

第三，工具移交后台有默认参数。Service 默认 tools.mode: auto，前台等待 5 秒。工具 5 秒内没完成，模型先拿到一张 exec-* 回执继续对话，工具在后台继续跑；完成后经 outbox/mailbox 异步通知，结果 steer 进当前运行或排队。停止运行会请求取消这些后台调用，并抑制迟到的结果唤醒。

「事件触发时保持静默」这一项对应得最弱。定时消息（schedules）一律按 next_run 投递：排队等下一次运行，不抢占当前运行。这是 a13n 里与静默最接近的规定，但排队只是延后处理，不等于不出声。

最容易混淆的是 steer 与工具等待的交互分支。inline 模式下模型只能干等工具完成；auto 模式下，立即 steering 可以提前结束前台等待、拿到回执先回应人，工具结果稍后异步送达。

边界与判断

几条边界需要划清。「可能是目前唯一支持 PA 的 Harness 和 Agent Platform」是 Wh1isper 的宣称，本文未做独立横评；「以交互为中心」的提法如前所述来自他与 Henry 的讨论，Henry 本人没有公开文本。heartbeat 在 PA 语境里指周期唤醒，a13n 仓库中的 heartbeat 实为 worker 租约续约，同名不同义；「事件触发时保持静默」在 a13n 里更多体现为 next_run 排队与产品层策略，而非一个名为 silence 的开关。

交互中心也不否定 delegate。a13n 仍有完整的 async subagent 生命周期（spawn、steer、cancel、continue、child_result 通知），只是结果被定义为「那次运行的通知，而不是委托工具调用的第二次完成」。PA 的瓶颈正在从「能不能并行干活」转向「能不能像前台一样接待人」：并行能力是基操，接待能力才是分野。