这个布局方便开发，也符合大家对 AI 助手的想象。

但当模型要修改表格时，纯聊天交互很快会暴露问题。用户看见“正在处理”，却不知道 AI 准备改哪张表、已经执行到哪一步、能不能中途停止。

一个会执行的 Agent，需要比聊天机器人更多的界面状态。

先展示计划，还是直接动手

不同任务应该有不同交互。

“把选区字体加粗”可以直接执行，因为范围明确、风险低、容易撤销。

“重构这份预算表并生成季度汇总”则应该先给计划：

计划执行 4 步
1. 读取「预算明细」A1:H860
2. 新建「季度汇总」
3. 按部门和季度汇总金额
4. 生成柱状图
​
预计新增 1 张工作表，不修改原始明细。

计划不是模型思维过程的全文展示，而是经过整理、用户可以判断的执行摘要。内部推理再长，也不应该原样倒给用户。

选区就是最自然的上下文入口

表格用户已经习惯“先选中，再操作”。

与其要求用户在聊天框里描述“销售明细表 D2 到 D500”，不如直接读取当前选区，在输入框上方显示：

当前作用范围：销售明细!D2:D500

用户发出指令前就能发现选错范围。模型返回工具后，界面还可以在表格中高亮即将修改的区域，形成二次确认。

SpreadJS 可以监听选择变化和活动工作表切换。前端不必每秒轮询，而是在用户切换现场时更新上下文提示。

任务状态不要只剩一个转圈

一个多步骤任务至少会经历：

理解请求
读取表格
等待确认
执行工具
验证结果
已完成

把这些状态都显示成“AI 思考中”，用户会不知道该等、该点，还是已经卡住。

更好的任务面板可以显示：

已完成 2/4
✓ 读取销售明细
✓ 创建季度汇总
● 正在写入汇总公式
○ 生成图表

同时保留“停止”操作。停止后要明确询问是保留当前结果，还是恢复到任务开始前，而不是悄悄结束动画。

确认应该发生在表格旁边

如果 Agent 要覆盖 F2:F500，只在聊天区弹一句“是否确认”并不直观。

界面可以同时做三件事：

• 表格中高亮目标区域；
• 侧栏显示影响 499 个单元格；
• 标明其中多少个非空、多少个含公式。

用户的视线不用在聊天文字和表格坐标之间来回翻译。

对于删除工作表这类动作，确认内容则应该显示工作表名称、使用范围和是否存在公式引用。

完成反馈要具体

“操作成功”几乎没有信息量。

更有用的反馈是：

已完成
在「销售明细」H2:H500 填充 499 个毛利率公式
跳过 2 个锁定单元格
抽样验证 5/5 通过
​
[定位结果] [撤销本次任务]

“定位结果”会把活动工作表切换到目标表并选中影响范围。用户不用自己在十几张表里找 AI 到底改了什么。

聊天记录和任务记录要分开

聊天消息适合保存用户意图和解释，任务记录则要保存：

• 工具调用；
• 参数；
• 确认；
• 影响范围；
• 快照；
• 执行结果。

两者混在一个消息流里，内容会迅速膨胀。普通用户只想看结果，开发者排错却需要完整细节。

可以默认显示简洁任务卡片，再提供“查看执行详情”。这样既不把界面做成日志控制台，也没有牺牲可追溯性。

好的 Agent UI，会把不确定性暴露在正确的位置

模型不确定目标列，就在执行前追问；系统检测到覆盖，就展示影响范围；执行时间长，就显示真实进度；任务失败，就提供恢复和重试。

用户并不需要看见模型的每一个思考片段。他需要看见的是：

AI 理解了什么
准备做什么
正在做什么
实际做了什么
做错后怎么退

这五件事做清楚，聊天框才从一个装饰性的入口，变成真正能承载表格任务的工作界面。

SpreadJS AI Agent 实战会把聊天交互、选区上下文、工具状态、确认和回滚放在同一套页面流程里。界面并不追求炫，而是让每一次执行都能被用户理解和控制。

想把这套方案真正跑起来

一个可用的表格 Agent 不只是聊天框，还需要任务计划、暂停追问、确认、进度、终止和恢复。课程会沿着真实项目页面与执行链路，把这些交互状态背后的工具调用和状态管理讲清楚。

课程《从 0 到 1 掌握企业级表格 Agent 搭建》基于公开的 SpreadJS AI Agent 项目，共 7 节，每节约 20 分钟，从整体架构一路讲到安全确认、快照回滚和调试体系。

课程地址

对应源码：https://gitee.com/GrapeCity/spreadjs-ai-agent。项目基于 TypeScript/TSX 和 SpreadJS，README 已整理工具体系、MCP 配置、受控代码执行、快照与恢复等入口，适合边读代码边验证。本文相关看点：任务计划、ask_user 暂停提问、进度状态和终止还原。