没有人会盯着一个跑四十分钟的智能体——要为"回来"而设计，不是为"等待"。
你做的每一处流式输出、实时思考轨迹与进度条，前提都是有个用户正盯着屏幕；而过了大约九十秒，这个用户已经走了。真正贵的问题不是等待，而是重新进入——他们回来后要花两分钟把"我不在的时候发生了什么"重新拼出来，而且每一次运行都要付这笔钱。这份手册讲的是"人不在场"的情形：什么该推送通知、什么该写进交付物而不是你的界面、怎样把回归成本压到几秒，以及为什么一道背后没人的审批闸门是死锁而不是安全控制。
当一次运行的时长超过注意力的时长，容器就变了。
聊天记录之所以适合对话，是因为双方都在场，而且最后一条消息就是状态。智能体独自跑起来之后，这两条都不成立了。用户回来时面对的是四十条他没看到抵达的消息，而他真正需要的状态——什么变了、什么卡住了、哪里要他拍板——散落在这四十条里，而不是安安稳稳待在最底下。界面于是不再是一场对话，而变成一个以任务为单位的收件箱：一份运行清单，每一条都带着状态、"下一步归谁"以及一件交付物。
- 给每次运行一个稳定的身份、一个 URL，以及一个一眼能读懂的状态：运行中 / 需要你 / 完成 / 失败。这里面只有"需要你"有资格主动来找人。
- 先设计列表，再设计详情页。用异步智能体的用户活在列表里；详情页是某次运行赢得注意力之后他才会去的地方。
- 流式输出并没有白做，但它现在是给少数"被盯着看"的运行准备的调试手段，而不是主界面。设计力气按这个比例分配。
用一个数字判断你有没有这个问题：有多少比例的运行，用户的最后一次交互早于智能体的最后一次动作。如果超过三分之一左右，你就是在用一个同步界面交付一个异步产品，而你收到的每一条"我看不出它到底干了什么"的抱怨，都是这处错配。
通知是一份预算，而且花掉就不再回来。
注意力是这套设计里唯一不会自动补充的资源。一个因为不必看的事被打扰的用户，不会只是把下一条通知打个折——他会把整个频道静音，于是等你真正需要它的那一刻，你的上报通道已经没了。把通知额度当成固定且很小的一份来用，只花在用户必须行动的状态上。
- 只在需要决策和到达终态时通知。卡在审批、触到不可逆边界、失败、完成。就这四种；其余都是进度，而进度是被拉取的东西，不是被推送的东西。
- 永远不要按百分比通知。"第 7 步，共 12 步"回答的是一个离开工位的人根本没在问的问题，而它花掉的额度和一条真警报一样多。
- 按运行合并，而不是按事件。十二个子智能体扇出、每个都想说句话，那是关于一次运行的一条通知，不是十二条。按时间窗合批；只有当这次运行超出窗口仍然卡着，才升级。
- 让通知本身可以就地处理。如果唯一的动作是批准/拒绝，那就把批准/拒绝放进通知里。一条只能靠打开笔记本才能了结的提醒，等于一条要拖到晚上的提醒。
交付物就是状态界面。
用户回来时不是为了打开你的运行视图看发生了什么；他们回来是为了那件智能体在做的东西。如果交付物是一个 pull request、一份文档、一张工单、一块看板，那么状态就该待在这个对象自己的界面上——因为用户本来就在那儿，也因为它比你的产品活得久。把状态推进交付物，交付物就对那些从没碰过你界面的人自我说明了。
- 随着进展把进度写进交付物：一个会自己更新描述的草稿 PR，一份顶部带着实时"状态与待决问题"区块的文档。
- 让交付物带上来源信息——由哪次运行、哪个版本产出，并能链接回去。一个冷不丁看到它的评审者，需要在信任它之前就知道这是智能体写的，而不是之后。
- 让交付物在每个检查点上都是有效的，而不是只有最后一刻才有效。一次被打断的异步运行，应该留下可评审的东西，而不是一个写了一半的文件——这正是持久状态在体验层的那张脸。
重新进入靠的是 diff，不是回放。
异步智能体产品里杠杆率最高的那一屏，是回答"我上次看过之后有什么变化，以及哪里需要我？"——按这个顺序，在十秒左右答完。聊天记录做不到这件事：它按时间排序、不区分轻重，还把归纳的活儿丢回给用户。要把这份 diff 显式地做出来。
- 以"上次看到哪"为锚。按运行记录用户的已读位置，并据此渲染。"自你上次来之后"永远胜过"到目前为止"，这也是同一次运行可以对两个不同评审者显示两份不同摘要的原因。
- 先决策，再变更，最后叙事。待决问题与待批审批排最前，然后是创建或修改了什么，最后才是推理过程——这就是把渐进式披露的折叠规则，从单个步骤之上挪到流逝的时间之上。
- 保留深链。摘要里的每一行都应该能展开到产出它的那一步、那次工具调用与那条观察结果。用户无法核验的摘要，会被信任一个星期，然后被放弃。
- 说清楚它没做什么。跳过的步骤、推迟的问题、悄悄失败的工具，恰恰是回来的用户从交付物里推不出来的东西，而信任的损伤就发生在这处遗漏上。
用智能体自己的结构化运行状态——决策、产物、阻塞项——来生成重新进入摘要，而不是拿模型去把聊天记录总结一遍。从日志生成的摘要会继承日志里的幻觉，还会悄悄漏掉那个失败的步骤；而从状态渲染出来的摘要漏不掉阻塞项，因为阻塞项是一个字段。
一道背后没人的审批闸门就是死锁。
人在环控制的设计前提，是环里真有个人。把运行改成异步，同一道闸门就变成一次停摆：智能体在第三分钟停下，用户晚上九点才看见，本该一小时的任务拖成一天——之后团队会做那件可以预料的事，把闸门整个拆掉。正确的修法是把人的决策提前，而不是删掉它。
- 在派发时预先授权。趁用户还没走开，把计划和其中有后果的步骤摆出来，当场把审批收齐。一次前置决策胜过之后四次打断，而这与审批体验里那套按后果分级是同一件事，只是挪到了前面。
- 给每个阻塞点配一个期限和一个默认动作。闸门必须声明"窗口内没人回应会怎样"——而对一切不可逆的事，这个默认必须是停下并保持，绝不能是继续。没有超时的闸门，是一次永远漏着的运行。
- 让智能体把可逆的活儿先存起来。卡在一个审批上不等于处处卡住：把互不依赖的分支继续做完，把被闸住的那条留成待决，回来时一并呈上。
- 用战绩而不是不耐烦来放宽自主权。对闸门疲劳的正确回应，是按渐进式自主用一份记录把某个具体动作提升为无人值守——而不是一句笼统的"以后别问我了"。
什么时候不该做成异步。
异步是一项关于"爆炸半径有界"的承诺，因为那个负责纠偏的人不在场。如果智能体的动作不可逆、如果你没法把一次运行干净地中途叫停、或者任务确实每一步都需要判断，那么诚实的产品是一个三分钟就跑完的同步产品——而不是一个在第三十分钟才发现自己在第四分钟就需要一个决定的异步产品。只有当一次完全无人照看的运行能安全地失败、并留下可评审的痕迹时，才把它做成异步；前提条件是一个真能用的急停开关和一组有界的无人值守动作，两者缺一，你在造的那条队列就是一堆惊吓的积压。