AI Agent 跑了一夜，第二天你该看什么？

每天早晨打开电脑，我都在反复问一个问题：我不在的时候，这里到底发生了什么？

在过去的开发工作中，这个问题并不存在。我知道发生了什么，因为代码是我敲的。我记得哪行写了一半，哪个单测被我跳过了，哪块逻辑打算周一再修。我的个人记忆就是系统日志。

直到我开始让 AI Agent 在夜间自主跑任务，这个问题变得非常具体。

掀开笔记本屏幕，后端工作节点旁边亮着一个绿点。它可能从凌晨两点开始就亮着了。

这个绿点可能有三种含义：进程还活着；任务执行完了；或者结果通过了某项检查。

屏幕上只有一个绿点，剩下的上下文全靠脑补。

我正在做一个名为 Luffy HQ 的实验性工作台，把各个 AI Agent 组织成一个像素风的虚拟办公室。调研、研发和运维分布在不同楼层，有专门的角色、两个主管、一个任务看板，以及启动和监控的机制。界面看着赏心悦目，但我却在这里撞上了同一堵墙——这堵墙和像素艺术毫无关系。

在《界面已离开大楼》（The interface has left the building）一文中，作者 Om Prakash 提出：屏幕正在失去它在设计体系中的中心地位。先是对话框，接着是语音，最后是彻底没有可视界面的自主 Agent。这个判断很准，但它只说了一半。

当界面离开时，用户也离开了。问题在于：用户终究是要回来的。

过去两年，整个行业都在精心设计「离开」的瞬间：输入框、规划预览、「我帮你预订晚上 7 点的餐厅」的确认弹窗。这个阶段的设计模式已经烂熟，各种组件库应有尽有。

但「返回」的瞬间，至今处于设计真空。一个睡了一觉、开完一整天会、或者度完假回来的用户，打开屏幕，必须在脑中重新构建那段他未曾目睹的工作过程。Agent 稳定运行的每一个小时，都是人类缺失的一段信息黑盒。

这是委托任务的另一面：不是你怎么吩咐 Agent，而是你回来时面对什么。我们来看一个看似微不足道的 Bug，它击溃了绝大多数 Agent 界面。

能通过所有测试的致命 Bug

昨晚我让 Agent 做一个团队活跃度仪表盘，包含日期筛选、分页、图表和自动化测试。

后端逻辑将日期范围的截止日处理为开区间（Exclusive）：如果选 9 月 30 日，接口会拉取截止到 9 月 30 日 0 点前的数据，不包含 30 日当天。这是后端很常见的处理方式。

前端组件却把同一个控件标记为闭区间（Inclusive）：选 9 月 30 日，界面文案和逻辑认为包含了 30 日当天。

前后端跑起来了，各自写的单元测试全部通过——因为每个 Agent 都是按自己对逻辑的理解去写单测。没有服务崩溃，没有报错报警，界面上所有状态全都是绿的。

然而，仪表盘静默吞掉了每个月最后一天的报表数据。直到运营人员发现月度数字对不上、彻底丧失对系统的信任之前，没有人会察觉。

这种失败最危险，也是现有界面处理得最差的。服务崩溃不可怕，崩溃会大声报警；这种 Bug 却伪装成了成功的模样。

一个「完成」标签，绑架了三种概念

那个绿点背后，实际上混淆了三种需要完全不同证据的断言：

1. 尝试已结束：底层进程退出。这是对执行过程的观察，也是大多数监控系统唯一真正能看到的东西。
2. 产物符合要求：生成的代码或产物经过了符合初始需求的校验。这是对交付物的验证，针对的是补丁本身，而不是执行过程。
3. 允许后续操作：获得了部署或发布的许可。这是一个权限边界，跟前两者毫无关系。

前面提到的日期 Bug，满足了第一条，通不过第二条，而第三条根本无人过问。

很多系统里的心跳检测器会把僵死的工作节点标记为「已完成」；或者直接读取控制台输出的 exit 0 来推导任务状态。这些做法都是把执行层面的状态强行提升为业务产物的完成。一旦提升，UI 就再也无法把它降级回去。

解决办法不是在屏幕上堆砌更多图表，而是给出准确的定义：

• 「节点失去响应」是运行观察。
• 「截止日期校验未通过」是验证结果。
• 「未获得部署授权」是边界控制。

三句不同的话，指向三种后续行动，人类在一秒钟内就能看明白。区分它们还有一个好处：不确定性不再让人焦虑。心跳丢失不代表补丁作废；单测失败不代表整个工作毫无价值；未授权发布也不等于开发停滞。在当下糟糕的界面里，这三者都会变成同一种刺眼的红色报警，最后导致用户对所有警报彻底麻木。

任务必须比 Worker 活得更久

拟人化的虚拟办公室隐喻给 Agent 赋予了具体的「工位」，这确实符合直觉。但它也悄悄把虚拟员工变成了界面的核心：点击员工、查看员工、重启员工。

但用户要的从来不是员工，用户要的是那个仪表盘。

假设负责后端的 Agent 在凌晨 2 点崩溃了，死之前它刚好写出了修复日期边界的代码。2 点 05 分，替补 Agent 启动。在很多系统里，用户早晨看到的是工位上坐着一个健康的 Agent，任务显示「进行中」。

之前的修改丢了。就算代码没删，上下文也丢了。新上岗的 Agent 不知道前任已经找到了前后端冲突的原因，屏幕前的用户更不知道。替换节点变成了记忆失忆，却被系统包装成了「自我修复」。

正确的做法是：任务始终处于前景，每次执行尝试只是挂在任务下面的记录。第一次尝试产生了一半的代码并终止；第二次尝试基于上一版继续；评审员驳回了某一个特定版本。这是一段连贯的历史，哪怕中途换了三个不同的 Agent。

对于前面的日期 Bug，真正有价值的上下文资产包括：

• 界面端日期必须为闭区间的业务要求；
• 未完成的代码补丁；
• 失败的边界测试；
• 一条关键记录：「先前的尝试误改了图表渲染，但真正的冲突在日期解析」。

最后这条是最昂贵的认知资产。如果没有它，人类第二天上午 11 点又得肉眼翻上千行对话记录来重新发现一遍。

决策不是聊天气泡

设想一下，凌晨 3 点，带着那个日期 Bug，Agent 抛出一条消息：

「一切测试通过，是否立即部署到生产环境？」

一切看起来确实完美，所有单测都是绿的——因为单测本身就是各执一词的前后端自己写的。

你根本没法回答这个问题。因为这句话隐藏了所有决策所需的关键细节：部署哪个版本？推到哪个环境？到底验证了什么？回滚方案是什么？审核之后代码有没有被改动？

对话流（Chat）根本不适合承载高风险决策。 聊天适合模糊发散的需求沟通，但不适合承载重大决策，因为关键证据会被稀释在几十条信息流里，迫使用户像侦探一样自己拼凑事实。

必须把待办动作做成结构化的实体卡片。一个发布请求必须标明：产物哈希值、目标环境、通过的验证、尚存的不确定性，以及请求的权限范围。

大部分界面都在授权范围上失控：

• 批准部署测试环境，绝不能顺带授权生产环境；
• 批准特定版本的产物，在别人又改动了文件后必须立即失效；
• 「允许本次」和「今后始终允许此类行为」是完全不同的两件事。

按钮文案必须承担起法律合同般的精确性：

• 仅允许本次
• 允许此版本构建物
• 永久允许此类操作

只有第三种是修改了系统策略，但在很多产品设计里，它往往被冠以最省事、最友好的默认样式。

卡片存在的意义，是让批准或拒绝成为一次知情决策，而不是为了骗取用户的确认点击。如果系统拿不出回滚方案的验证记录，卡片就应该坦白写上「未验证回滚链路」，而不是生成一段充满 AI 幻觉的「回滚应该问题不大」来掩饰太平。

把阻力放在刀刃上

当然，走极端也是错的。如果 Agent 每调用一个工具就弹窗确认一次，人类又被拴死在了打字机前，委托也就失去了意义。

另一个极端同样糟糕：提供一个一揽子的「完全信任该 Agent」开关，把无数后果迥异的动作抹平成单一口味的选择题。

分界线不应该按某种模糊的「风险评分」来切，而应该看这个操作是在约定边界内执行，还是在改变边界本身。

读取项目文件、运行白名单内的测试集，Agent 可以在既定规则下跑一整夜；但发布上线、给外部人员发送通知、修改数据库权限，就必须跨越阻力门槛。研究表明，在决策辅助系统中，强制要求用户深思的界面设计能显著降低过度依赖（Overreliance），尽管这类设计在用户满意度打分时往往不如「一键搞定」讨喜。阻力的价值在于改善决策质量，而不是讨好用户。

就算是「终止任务（Stop）」按钮，也需要严谨的状态契约：

• 已发起取消请求
• 本地进程已终止
• 外部接口已调用，该操作不可逆

一个秒回但实际上没把外部副作用停掉的假「已停止」，比一个响应慢但实话实说的系统要危险得多。

设计「重返工作」的首页

早晨 9 点，人类重回工位。

一份活跃 Agent 列表只能说明谁在线，一屏聊天流只能说明谁说了什么。这两样都回答不了最核心的问题：这个项目现在的状态，比昨晚我离开时是变好了还是变差了？

重返视图的第一屏，必须按顺序回答四个问题：

1. 改动了什么？
2. 验证了什么？
3. 还有哪些不确定？
4. 哪些事情需要我做决定？

面对那个日期 Bug，理想的总结应该只有四句话，且每一句都能向下穿透：

「前后端接口已调通。截止日期的边界测试依然未通过。候选修复补丁已保留。未向任何环境部署。」

对比一下很多人机系统随手生成的套话：

「进展顺利！团队很快就要完成了。」

这种毫无信息增量的废话，把所有的排查成本全推回给了人类。

渐进式信息暴露（Progressive Disclosure）应该围绕「任务」组织，而不是围绕「组织架构」展开。先展示业务后果，次级展示支撑证据，完整的底层日志折叠在一跳之外，而不是把它当成早间必读书目。

此外，视图必须诚实说明数据的新鲜度：这份总结是基于 2 分钟前的状态，还是半小时前的快照？某个 Agent 的状态是不是已经断联无法获取？在卡片角标上标注一句*「摘要生成于 4 分钟前，1 个工作节点离线」*，对建立信任的帮助远胜过再画一张花哨的图表。

透明度不是倾倒日志。一万行没有上下文的执行事件不是解释。设计的任务是把系统的主张与证据连起来，再把证据对准人类有权做出的决策。

检验标准：用户能否重建记忆？

评价一个 Agent 系统的界面好坏，不要去问用户「觉不觉得好用」或者「信不信任 AI」，这类主观问卷测不出任何实质问题。

真正的压力测试应该是：把系统置于一个半死不活的非正常状态——一个心跳断掉的节点、一份挂在旧版本上的评审意见、一个未决的上线申请、以及一个悄悄吞掉一天数据的边界 Bug。然后把屏幕交给一个刚进房间的人，问他：

「下一步做什么才是安全的？」

看他能不能分清进程结束和产物验收；看他能不能找到结论背后的证据链；看他明不明白一旦点下同意，系统到底会去执行什么。

交互的速度固然重要，但绝不是首要指标。一个三秒内自信点下错误审批的用户，获得的不是好体验，而是一场事故。我们要统计的是错误的批准次数、被忽略的未知风险、以及系统偏航后人类理清头绪所需的耗时。

最高境界的协作从来不是「无条件的盲目信任」，而是在证据确凿的地方果断前行，在证据缺失的地方保持克制，并拥有随时干预的清晰路径。

屏幕和界面也许正在离开舞台中央，但人类每天早晨都要走回这个房间。人机协作的成败，不在于你昨晚怎么把它打发走，而在于今天天亮你回来时，能不能看懂它究竟干了什么。