做普通聊天产品这个划分没问题。可一旦 AI 要操作浏览器里的复杂表格前端就不再是一个薄薄的显示层。工作簿对象在浏览器里活动表、选区、公式、样式和撤销栈也在浏览器里。服务端模型能理解用户想做什么却不能隔着网络直接拿到这些状态。真正落地时前端更像 Agent 的“手”和“现场观察员”。一条指令至少往返两次用户说“把当前选区中的负数标红再给这一列加合计。”完整链路通常是浏览器采集当前选区 - 服务端模型判断意图 - 返回结构化工具调用 - 浏览器校验并执行 - 浏览器回传实际结果 - 模型决定是否继续服务端第一次收到的不能只有一句中文还要有最小表格上下文。模型返回的也不能是一段随意代码而应该是受约束的工具参数。例如{ tool: applyNegativeNumberStyle, arguments: { sheetName: 月度经营, range: F2:F128, color: #C62828 } }浏览器执行后再返回{ ok: true, affectedRange: F2:F128, matchedCells: 9 }模型只有拿到这个结果才知道第一步已经完成下一步可以写合计公式。为什么不把工作簿搬到服务端最省脑子的方案是把整个工作簿上传到服务端处理再把结果传回来。但浏览器端表格有很多“现场状态”很难用一个文件表达用户此刻选中了哪里光标停在哪个单元格哪张工作表处于活动状态哪些内容刚刚修改但还没保存当前撤销栈里有哪些操作页面业务权限允许用户做什么。把执行留在浏览器还有一个直接好处很多格式修改根本不必上传业务数据。用户说“给选区加粗”服务端只需要知道选区坐标和意图不需要看到单元格里的客户信息。前后端之间需要一份稳定协议Agent 项目容易把协议写成“模型返回什么前端就临时适配什么”。工具少时还能维持工具一多就会出现参数命名混乱、错误结构不一致和版本难以兼容。每个工具至少应约定type ToolResult { ok: boolean; toolCallId: string; summary: string; affectedRanges?: string[]; data?: unknown; error?: { code: string; message: string; retryable: boolean; }; };这里 toolCallId 很重要。一次模型回复可能包含多个动作异步返回时要知道结果属于哪次调用。retryable 也比只返回错误文本更有用权限不足不该重试临时状态冲突则可以重新采集上下文后再试。客户端工具也要做权限判断“服务端已经鉴权前端不用管”在 Agent 场景里并不够。服务端可以判断用户有没有编辑某份文档的权限但某个单元格是否锁定、当前区域是否允许覆盖往往只有浏览器里的工作簿知道。执行工具需要在落笔前再次检查现场状态。所以权限至少分两层服务端判断身份、角色和业务范围客户端判断工作表、区域和当前状态是否允许执行。两边的判断目标不同不是重复劳动。断线和重复请求怎么处理网络一抖前端没收到结果重新请求一次。如果工具没有幂等设计刚才新增的工作表可能又被新增一次。解决方式是给任务和工具调用都分配稳定 ID并记录执行状态pending - running - succeeded - failed - cancelled浏览器收到相同 toolCallId 时先查询是否已经执行。已成功就返回原结果而不是再做一遍。对“设置 A1 的值”这类天然幂等操作问题不大对“插入一行”“新增工作表”“追加记录”则必须认真处理。前端工程师会成为 Agent 落地的关键角色AI 表格并不是在现有产品旁边加一个聊天框。它需要前端理解工作簿状态、封装可验证工具、维护任务状态还要处理确认、取消、重复调用和恢复。模型负责推理服务端负责调度浏览器负责感知与执行。三者之间没有谁只是“展示层”。在 SpreadJS 这类浏览器端表格中越早把前端当作 Agent Runtime 的一部分后续工具扩展越不容易失控。SpreadJS AI Agent 实战会从一条自然语言指令开始把浏览器、服务端模型和工具结果回传完整走一遍。理解这条链路后再看上下文、安全和回滚就会清晰很多。想把这套方案真正跑起来如果你想看浏览器中的 SpreadJS、服务端 Agent 和大模型如何真正配合课程第一部分会从完整请求链路开始说明上下文在哪里采集、工具在哪里执行、结果如何回传以及前后端各自应该承担什么责任。课程《从0到1掌握企业级表格 Agent 搭建》基于公开的 SpreadJS AI Agent 项目共 7 节每节约 20 分钟从整体架构一路讲到安全确认、快照回滚和调试体系。