之前 Codex Pet 很火，我也想在 Qoder 里放一个类似的小东西。于是，周末 Vibe Coding 了一把。做着做着才发现，它要解决的好像不是“再多一个 Notification”。

过去讨论 Coding Agent，我们很容易把焦点放在“它能不能写代码”“能不能修 bug”“能不能生成文档”上。但当 Qoder、Codex、Claude Code 这一类工具开始支持长任务、后台执行、多线程会话、权限请求和结果审查时，问题开始换了：让 Agent 做事已经不是唯一难点，多个 Agent 同时做事时，人类怎么把它们看住，反而变得更难。

这时候，Agent 开始从聊天窗口里“长出来”。它不再只是一个输入框后面的模型，而开始像一个具体的工作对象：有状态、有任务、有提醒、有等待点， 也会在某些时刻主动找你。它可能在等一个 Permission Request，也可能通过 AskUserQuestion 请求方向选择；它可能告诉你任务已完成，也可能把你拉回一个需要 review 的结果。表面上看，这很像 IM 时代的多会话管理：谁在线，谁 @ 我，谁有未读，哪个 thread 需要处理。

但多 Agent 比 IM 更复杂。IM 管理的是消息，Agent 管理的是执行。一个 Agent 的提醒背后，可能是一条正在运行的命令、一个待批准的权限、一个缺失的证据、一次失败的验证，或者一个等待人类判断的分叉。于是，人的角色也悄悄变了： 我们不再只是和 Agent 聊天，而是在监督一支异步运行的工程队。

引子 0：从 Codex Pet 到 Office 桌面助手

我最开始的想法很简单：做一个桌面上的 Clippity，我把它叫作 Cliplet。右键它，选择 New Slides，输入一句需求，然后它把这个需求交给 Qoder 的新任务入口，让 Qoder 使用 /slide 这样的 Skill 去生成 PPT，最后再通过 Office Canvas / WebView 渲染成可以预览的网页。

表面上看，这只是一个“右键生成 PPT”的小功能。

但做着做着，我发现它和我之前设计 Routa 时遇到的问题有点像。卡住人的地方在后半段：Agent 在后台异步执行之后，人类如何知道它做到哪里、是否需要介入、结果能不能接回来。

Routa 更像一个工程化控制面，适合管理任务、证据、门禁和多 Agent 协作；而 Cliplet 更适合出现在日常工作流里，作为一个轻量的前台状态层。 它不一定负责执行，但它可以负责告诉我：任务正在跑、需要回答、等待授权、已经完成、失败了，或者可以预览了。

所以，Cliplet 自己不负责写 PPT，也不把自己做成 Office 编辑器。它只做三件事：接住人的意图，把意图转成一个可追踪任务，再把任务交给真正的 Agent 执行。

这个边界很重要。一旦桌面助手自己承担生成、渲染、修复、提交和状态判断，它很快就会变成另一个复杂 Agent。而我真正想验证的是：桌面上能不能存在一个更轻的层，只负责组织异步 Agent 的状态、入口和人类介入点。

我后面才意识到，Cliplet 不是生产力工具本身，而是生产力工具之间的前台调度面。

引子 1：Agent 正在像 IM 联系人一样出现

从用户体感上看，Agent 正在变得越来越“实体化”。它不再只是输入框里的模型，而是开始拥有头像、名字、状态、菜单、任务、 线程和提醒。它会在桌面上出现，会在侧边栏里排队，会在任务完成后冒泡，也会在需要权限时停下来等你。于是，多 Agent 管理很自然会被我们类比成 IM。

这个类比有用，因为 IM 时代解决的核心问题不是“聊天”，而是注意力分配：这么多会话里，哪一个现在值得我看？哪一个可以稍后处理？哪一个必须立刻回复？

多 Agent 时代也一样。一个 Agent 在写 PPT，一个 Agent 在跑测试，一个 Agent 在等权限，一个 Agent 已经生成了结果但还没有证据。用户并不想读完所有日志，也不想打开所有窗口。用户只想知道：现在到底是谁需要我？需要我做什么？这件事能不能等？

但是，IM 类比到这里就应该停下来。因为 IM 管理的是消息，而 Agent 管理的是执行。IM 里的“未读”通常意味着有人说了话；Agent 里的“未读”可能意味着任务卡住、权限待批、测试失败、证据缺失，或者只是一次低风险进展。

• 一个 Agent 没有发消息，不代表它没有在工作。
• 一个 Agent 发了很多消息，也不代表任务真的有进展。
• 一个 Agent 说 completed，也不代表这件事已经可以交付。
• 一个 Permission Request，也不是普通的“请回复一下”，而是系统边界正在等待人类确认。

所以，IM 化 Agent 不是终点，而是一个危险的中间态。它让 Agent 更容易被理解，也让 Agent 更容易获得打断人的权力。如果只把多 Agent 做成会话系统，我们就会漏掉更关键的东西：任务、阶段、证据、权限和失败路径。

问题来了：合理中断，才是最危险的中断

当我们同时使用 Qoder、Codex、Claude Code、Routa 这类工具时，让人疲惫的不是“Agent 太吵”，而是它们的每一次打断看起来都很合理。

• Permission Request 很合理，因为 Agent 不应该静默运行危险命令。
• AskUserQuestion 很合理，因为 Agent 不应该在需求不明确时瞎猜。
• Review Required 很合理，因为 Agent 的结果不能直接进入交付。
• Task Completed 也很合理，因为任务结束后，人需要知道有结果了。

问题在于：合理，不等于应该立即打断我。

我可能正在网页里使用 Deep Research 梳理另一篇文章，也可能正在 review 一份文档，或者刚刚把注意力切回一个复杂的架构判断。然后，一个 approval、一个 question、一个 completed、一个 reminder，把我重新拉回另一个上下文。在 IM 时代，我们还能凭经验忽略一些消息。

但在 Agent 时代，每一条消息背后都可能有一个正在运行的任务、一个待批准的命令、一个缺失的证据，或者一个失败的验证门禁。 于是，人类的角色悄悄变了。我不再只是和 Agent 协作的人，而变成了多个 Agent 的中断处理器。

这就是多 Agent 时代的注意力问题：低价值消息当然麻烦，更麻烦的是高理由密度的中断太多。每个 Agent 都有理由找我，每个任务都觉得自己值得被看见，每个提醒也好像不应该被错过。当这些“合理”叠在一起之后，人就很难再靠经验判断哪一个可以等、哪一个必须现在处理。如果没有一层系统帮我判断“这件事是否真的需要现在打断人”，人的注意力就会被这些合理中断一点点切碎。

什么是 Attention Harness？

所谓 Attention Harness，就是给 Agent 打断人这件事加一层约束。通知先不要急着弹出来，事件也不要直接丢给用户，而是先判断一个更底层的问题：

这个 Agent 此刻有没有资格占用人的注意力？

在多 Agent 同时运行时，事件不能直接变成 notification。因为从 Agent 执行的角度看，“完成”“提问”“权限请求”“验证失败”“等待验收”并不是同一类东西。一个 completed 可能只是低风险进展，一个 permission request 可能涉及系统边界，一个 question 可能是关键决策点，一个 review required 可能意味着结果还不能交付。

所以，Agent 事件需要先经过 Attention Harness，被压缩、分流、延后，或者升级成一次人类接手：

Agent Event
   ↓
Attention Harness
   ├─ ambient：只改变状态，不打断
   ├─ digest：进入摘要，稍后再看
   ├─ inbox：需要人处理，但不必现在
   ├─ interrupt：必须立即打断
   └─ task handoff surface：把任务现场整理给人

它至少要判断几件事：任务是否被阻塞，是否涉及高风险或不可逆操作，是否必须由人类做判断，是否处在关键路径上，以及人被叫回来后能不能快速恢复上下文。只有当这些因素共同指向“必须现在处理”时，Agent 才有资格打断人。

也因此，打断人本身应该是一种权限。过去我们讨论 Agent 权限，更多是在讨论文件、命令、网络和浏览器；但在多 Agent 同时工作的情况下，注意力也会变成一种被消耗、被争抢、被错误占用的资源。Attention Harness 的任务，就是重新排队：谁留在后台，谁进入摘要，谁进待办，谁可以越过当前工作，直接来到人面前。

交互发生了变化：从消息提醒到任务接手

Attention Harness 先解决“该不该打断”。但系统真的把人叫回来之后，还有另一个问题：这次交互应该长什么样？

在传统软件里，通知通常只是一个入口。它告诉你有新消息、新状态、新结果。点进去以后要看什么、怎么判断、接下来做什么，很多时候都交给用户自己处理。

Agent 场景不太一样。Agent 找你，往往不是因为“有一条新消息”，而是因为一段执行过程走到了某个需要人类承担责任的位置：权限边界、判断分叉、失败纠偏、结果验收，或者关键路径上的阻塞点。

所以，人的动作也发生了变化。过去我们是“看一条通知”，现在更像是在“接手一个任务现场”。

一个简单的提醒可能是：

Slides 已生成，可打开预览。

到了 Agent 这里，提醒最好多给一点现场：

任务：生成 Pet Agent Skill 演示文稿
状态：可预览
为什么找你：需要确认是否继续修改
最近动作：已生成 PPT，并启动 Office WebView
证据入口：Canvas artifact / WebView URL / 生成日志
可选动作：打开预览 / 继续修改 / 稍后处理 / 归档

重点不在于它是不是一张卡片。它可以出现在通知里、任务列表里、宠物气泡里、侧边栏里，甚至是完整的任务控制面里。关键在于：当 Agent 把人请回来时，它不能只丢出一个状态，而要把这个状态整理成一个人可以立刻处理的现场。

Attention Harness 的可能演化：从通知路由到前台调度面

继续往前看，Attention Harness 不会只是一个通知过滤器。它最初看起来是在管理提醒：哪些不提醒，哪些稍后提醒，哪些立刻提醒。但随着 Agent 数量、任务长度和执行风险上升，它会逐渐变成一个更完整的前台调度面。

第一步会从 notification routing 变成 task routing：系统不再只判断“这条消息发到哪里”，而是判断“这个任务状态应该流向哪里”。低风险进展留在 ambient，多个小进展合并成 digest，需要人处理但不紧急的事项进入 inbox，高风险、阻塞关键路径的事项才进入 interrupt。

再往前，它会从单点弹窗变成待处理队列。多个 Agent 同时工作时，人需要的不是一个个通知，而是一个按风险、阻塞程度、关键路径和上下文恢复成本排好序的队列。

再往后，它会变成任务恢复界面和权限闸门。人被叫回来时，系统需要提供目标、阶段、最近动作、证据、风险和可选动作；权限请求也不应该只是“允许 / 拒绝”，而应该解释这个操作为什么需要执行、风险是什么、是否可回滚、有没有更安全的替代方案。

放到这个方向上看，Attention Harness 的未来形态不会是一个单独组件，而是一组能力的组合：中断路由器、状态压缩器、任务恢复面、权限闸门、证据入口和人工判断队列。 它表面上是在管理提醒，实际上是在管理多 Agent 系统里最稀缺的资源：人的注意力、判断力和责任边界。

结语：IM 时代管理消息，Agent 时代管理执行

回到最开始的问题：Codex Pet 也好，Cliplet 也好，它们看起来像是一个可爱的桌面入口，但值得讨论的并不是 Agent 要不要有一个头像、一个气泡，或者一个更拟人的提醒方式。

麻烦在后面：当 Agent 开始后台执行、长时间执行、多线程执行时，人和 Agent 的关系变了。

多 Agent 的未来，最好少一点热闹的聊天窗口，多一点安静、可恢复、可审计的前台调度面。Attention Harness 的价值，不在于让 Agent 更会提醒人。 它更像一条边界：只有需要判断、授权、验收和纠偏时，才把人请回任务现场。