聊天窗口很适合告诉 Agent“我要什么”，但真的不适合看它“干到哪了”

昨天 GitHub 发了一篇挺有意思的文章，题目直接点出了一个越来越明显的问题：

Chat is great for intent, but agent work gets lost in the scroll.

我很认同。

过去两年，我们几乎默认了一个 UI 逻辑：

AI = Chat

用户输入一句话，AI 回复一大段。

可 Agent 一旦从“回答问题”变成“执行任务”，这个界面开始变得别扭。

比如一个 Coding Agent 正在做：

理解需求
→读 18 个文件
→拆 7 个任务
→修改 5 个文件
→跑测试
→修 3 个失败
→再跑测试
→等待人工确认

最后这一切都被塞进一条越来越长的聊天记录。

问题就来了。

我真正想看的不是它说了什么，而是它现在是什么状态

用户问：“现在做到哪了？”

聊天记录可能已经有 80 屏。

真正应该回答的是：

任务：登录模块重构

总步骤：7
完成：4
进行中：1
阻塞：1
待人工：1

已修改：
- AuthService.java
- JwtFilter.java
- LoginController.java

测试：
32 passed
2 failed

预算：
$1.82 / $3.00

这不是 Chat UI。

这是任务控制面。

GitHub 那篇文章里提到的一个现实问题很关键

Agent 生成代码的速度，已经开始超过人类 Review 的速度。

以前瓶颈是写代码，现在慢慢变成看 Agent 到底改了什么。

所以产品界面如果仍然只展示模型消息，人会越来越累。

因为 Review 需要的不是完整过程日志，而是：

变更
证据
状态
差异
决策点

一个 Agent Run，我希望至少有四个视图

Goal

最上面固定显示用户真正要完成什么。

例如：

修复登录偶发401，
不能改变现有Token格式，
必须通过全部Auth测试。

Agent 跑了半小时以后，人不用重新翻第一条消息。

Plan

[✓] 复现401
[✓] 定位Token刷新逻辑
[✓] 增加并发测试
[→] 修改Refresh流程
[ ] 全量测试
[!] Security Review

Plan 能改，但修改要显示 Diff。

Artifact

Agent 产生的代码Diff、测试报告、截图、查询结果和分析文档应该单独展示，不是埋在消息里。

Decisions

只列需要人的节点：

是否允许修改数据库Schema？
是否接受删除兼容逻辑？
是否发布到10% Canary？

这才是人真正需要参与的地方。

为什么“完整过程都可见”反而不等于可观测

很多 Agent 产品喜欢显示：

Thinking...
Reading...
Searching...
Calling tool...
Analyzing...

很热闹。

但如果出了问题，还是答不上：

哪一步失败？
失败以后重试几次？
用了哪个版本？
哪个Tool产生了副作用？
最终结果基于哪些Artifact？

真正的可观测需要结构化事件。

{
  "event": "STEP_COMPLETED",
  "step_id": "run-tests",
  "status": "FAILED",
  "duration_ms": 18342,
  "artifact": "test-report-92",
  "error_code": "TEST_FAILURE",
  "retryable": true
}

UI 只是把这些事件画出来。

我会把 Agent UI 做成“事件投影”

后端事实：

RunCreated
PlanCreated
StepStarted
ToolCalled
ArtifactCreated
StepCompleted
ApprovalRequested
RunFinished

前端不是自己猜状态，而是：

消费事件
→生成Projection
→画界面

这样刷新页面、断线重连、多人同时看，都不会丢状态。

聊天仍然重要，只是不应该承担全部职责

Chat 最适合：

  • 设定目标；
  • 补充信息；
  • 修改要求；
  • 提问；
  • 给反馈。

Canvas/Run View 最适合：

  • 看进度；
  • 看Artifact；
  • 看Diff；
  • 看风险；
  • 看预算；
  • 做审批。

两者应该并存。

一个具体的交互例子

用户：

把这个Spring Boot项目升级到Java 25。

聊天区：

Agent：
我会先检查JDK、Spring Boot、插件、
CI和Docker镜像兼容性。

任务区立即出现：

Java 25 Upgrade

1. Inspect build files
2. Check Spring Boot compatibility
3. Update Maven compiler
4. Update CI
5. Update Docker
6. Run tests
7. Review breaking changes

执行 5 分钟后：

4 / 7 completed
Changed files: 6
Tests: 128 passed, 3 failed
Blocked: Mockito agent warning
Needs decision: Upgrade Mockito?

用户不需要再问“现在进展怎么样？”。

Agent 越自治，越需要视觉化控制面

这是个看起来矛盾的结论。

很多人觉得 Agent 越自动，人越不需要看。

我反而觉得：

Agent越自动
人越不能只看最后一句话

因为中间发生的事情更多。

例如：

修改20个文件
调用8个工具
花掉5美元
读了3个系统
等待1次审批
重试4次

如果界面只给最终结果“任务已完成”，这不是自动化，是黑箱。

我最希望看到的几个组件

Timeline

09:12 Run started
09:13 Plan approved
09:14 Repo scanned
09:18 6 files changed
09:20 Tests failed
09:23 Fix applied
09:25 Approval requested

Artifact Diff

只显示真正变化：

pom.xml
Dockerfile
ci.yml

Budget

Model calls: 14
Tool calls: 28
Tokens: 184K
Cost: $2.31

Risk

LOW: Read repo
MEDIUM: Modify source
HIGH: Deploy

Human Queue

只把必须由人决定的事情推出来。

不要把“Canvas”理解成另一种白板

我这里说的 Canvas，不一定是某个产品功能名称。

更准确地说，是：

Agent Run 的结构化工作界面

它可以是 DAG、看板、时间线、文件树、流程图或状态面板。

关键不是画得漂亮，而是从 Message-oriented 变成 State-oriented。

最后一个判断

聊天框不会消失。

但我觉得纯 Chat Agent 的黄金期正在过去。

未来真正复杂的 Agent 产品，很可能都会长成：

Chat
＋Run
＋Plan
＋Artifact
＋Approval
＋Observability

因为人和 Agent 的关系已经不是“我问，你答”，而越来越像“我交代一个目标，你去执行，我在关键节点介入”。

当交互模型变了，UI 迟早也要跟着变。

接下来谁能把“Agent 到底干了什么”做得比“Agent 会说什么”更清楚，可能才是更重要的产品差异。

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/