AI Agent 工作台：把不确定性设计成可操作的界面

Agent 承接的是持续任务：它会计划、调用工具、等待、失败、重试，也可能需要人接管。把这些都压在消息流里，用户只能猜系统此刻在做什么。

一个更稳的结构是三层：任务目标放在顶部，正在发生的执行过程放在主区，证据、工具结果和可恢复操作放在侧区。用户不需要理解模型实现，但必须能判断下一步是否该介入。

生成中回答“它在做什么”；等待授权回答“为什么需要我”；失败回答“哪里出错、是否可重试”；完成回答“结果来自哪里、能否继续编辑”。状态不是一颗彩色圆点，而是一份行动说明。

对长任务，不要只显示转圈。把计划拆成可折叠步骤，允许用户查看已完成证据，并在关键节点提供暂停、修改目标和人工确认。

聊天适合承接意图澄清和结果解释；工作台适合承接并行信息与可复用操作。两者并置时，聊天负责说清楚，结构化面板负责做清楚。

最终检查标准很简单：如果用户刷新页面后无法快速重建任务上下文，说明任务状态仍然藏得太深。

工作台最常见的数据错误，是把一次 Agent run 等同于一条 assistant message。Message 适合承载人类可读的叙事，run 承载一次从目标到结果的执行，step 则记录计划、工具、等待和恢复点。三者共用稳定 ID，但生命周期不能混在一起。

一个 run 可以产生多条消息、多个 tool step 和多个 artifact；同一条消息也可能随着流式输出持续追加 part。刷新页面时，前端先恢复 run 与 step，再恢复消息投影，才能知道任务究竟完成了、暂停了，还是只显示到一半。

建议把 threadId、runId、stepId、messageId、toolCallId 和 artifactId 写进事件契约。只要这些 ID 缺失，后续的重试、分支、审批和审计都会退化为字符串匹配。

可观察不等于把模型内部发生的一切暴露出来。用户首先需要目标、当前阶段、阻塞原因和下一步；工具参数、原始日志、token 消耗与内部 reasoning 属于按需展开的证据层。

可以把事件分成三档：必须打断用户的 approval、failure 与 missing input；应该持续可见的阶段和产物；默认折叠的低风险 tool 与 telemetry。每档对应固定的视觉重量，避免十次搜索调用制造十张同样醒目的卡片。

对 reasoning 尤其要克制。展示简短的行动说明和证据来源，而不是把内部推理文本当作产品解释。可解释性来自可核验的输入、工具、结果与决策，不来自更长的思维直播。

普通 Happy Path 很难检验 Agent 工作台是否可靠。真正有效的验收是主动制造中断：执行到一半刷新页面、撤销授权、让工具超时、让用户修改目标、让审批人换设备继续处理。

每次中断后，界面必须能回答已完成什么、哪些结果仍有效、为什么停住、谁负责下一步以及可以从哪里恢复。重试按钮必须绑定具体 step 和输入快照，而不是重新发送最后一条自然语言消息。

上线前至少保存一组可重放的事件 fixture，覆盖成功、等待输入、拒绝审批、工具失败、用户取消和部分完成。UI 用同一组 fixture 做视觉回归，后端用它验证事件兼容性。