HUMAN ↔ AGENT
当 Agent 真正工作，人需要看到的不只是聊天记录。
一个长运行可能包含多次模型请求、工具调用、材料读取、Artifact、暂停和审批。只显示最终回答，会把最重要的工程事实藏起来。
ZUAEF Workbench 的方向，是让人可以观察、理解、纠正 Agent，而不是用更多控制字段替 Agent 做决定。
一个围绕权威 Run Projection 构建的操作面。
当前 Web Console 提供四个核心工作区：
已实现Run List
选择近期 Run，在不同执行历史之间切换，不需要直接打开底层状态文件。
Trajectory
以操作员可读的 Timeline 查看 Model / Tool Lifecycle Events。
Inspector
选中一个 Event 查看细节。当人在阅读历史时，不会被 Live Stream 不断把视图拖回最新位置。
Artifact Bar
让最终产物与 Pause / Approval 状态始终和 Run 本身放在一起。
Console 是 Runtime Truth 的 Projection，而不是另一个 Runtime。
LIVE REQUEST OVERVIEW
Stream 只负责通知变化，Server Projection 继续作为权威。
当选中的 Run 处于 Live 状态，Console 会建立一条很薄的 SSE Stream，监听 `run_changed` invalidation。
Stream 不携带另一份 Timeline 数据。它只告诉 Client：“权威 Projection 发生变化了。”Client 随后重新请求同一个 HTTP Run Projection。
SSE invalidation → refetch authoritative projection → render当操作员点击历史 Event，live-follow 自动暂停。恢复意味着“jump to now”，而不是“把我正在看的历史视图不断刷新掉”。
Observability 应该减少歧义，而不是再增加一个 Truth Source。
NEXT LAYER
Raw Telemetry 已经能看见，下一步是解释。
Timeline 对工程师有用，但它仍然要求人手工推断问题。Run Analysis 应该直接回答：
- Run 的 Wall-clock Time 主要花在哪里？
- 哪些 Request 携带了最大的 Context？
- 哪些 Tool Call 触发了额外 Model Turn？
- Agent 是否反复执行同一种 Verification？
- 有没有 Capability 被 Loaded 但从未 Invoked？
- 模型是不是已经有足够 Evidence，却仍继续 Research？
- 哪一步开始偏离原始 Business Outcome？
- 最值得人先检查的 Artifact / Decision 是哪个？
目标不是再做一个 Counter Dashboard，而是给人或 Engineering Agent 一个真正可以行动的解释。
Run → Analysis → Workspace → Patch → Fresh Run
更有价值的开发闭环应该是：
真实 Run → Execution Evidence → Run Analysis → Engineering Workspace → Capability / Code Patch → Snapshot Freeze → Fresh Run → Human RewardWorkbench 可以成为 Runtime Evidence 与 Engineering Workspace 之间的接口。
重要边界
Patch 不应该在同一次业务 Run 中间偷偷修改 Capability。版本归因很重要。代码变更发生在两次 Run 之间，下一轮重新 Freeze Snapshot，再用 Fresh Run 验证行为是否真的改善。
产品方向
真正的工作单元不是“聊天”，而是人和 Agent 围绕同一个 Case 与 Artifact 协同。
更完整的 Workbench 最终可以把这些 Surface 放在一起：
- 当前 Conversation
- Bound Business Case
- Source Material
- Draft / Document / Analysis Artifact
- 字句、段落与全文批注
- Run Trajectory
- Run Analysis
- Approval
- Operator Correction
- 当问题属于 Capability 本身时，进入 Engineering Handoff
这也是 Agent Console 与 Stillwrite 这类协同写作/批注空间最终能够连接起来的方向。
方向 · 在代码证明深度集成之前，不得写成已完成Correction 不是事后备注，它应该成为下一轮工作的一部分。
如果操作员说：
- “开头还是太像 AI。”
- “价格暂时不要写。”
- “这个客户在意的是速度，不是功能数量。”
- “停止继续搜资料，先把现在的 Draft 给我看。”
……下一轮 Agent 应该能够把这些纠正作为相关 Task / Business Context 使用。系统不应该要求人每次重述整个 Case，也不应该把每个瞬时模型动作污染成 Durable State。
Workbench 从“日志查看器”升级为真正协同工作面，关键就在这里。
Workbench 原则
Outcome First
主界面先展示 Artifact、Decision、Effect 或 Blocker，而不是 Receipt Field。
Evidence on Demand
Raw Evidence 随时可查，但只有在它有助于当前判断时才进入主工作面。
Stable Inspection
Live Run 不应该让人无法稳定查看历史。
Human Correction First-class
人从“这里错了”到“下一轮改变决策”之间必须有直接路径。
不做假 Orchestration UI
不存在真实行为所有权的组件，不要为了画面热闹画成一个盒子。简单但忠实于真实执行的 UI 更有价值。