如果你用过 AI 聊天工具，大概有过这样的体验：你描述一个需求，它返回一段文字、一份总结或一段代码。这些能力确实有用，但仔细想想，它做的大部分事情，还停留在"告诉你该怎么做"。
真正的麻烦往往不在于"怎么做"，而在于"做完它"。
一份原始销售数据，老板要的不是"如何制作月度报表"的方法论，而是有人替他把每个区域的销售额算出来、把低于目标的行标红、把表头样式统一好，再生成一张能直接拿去汇报的图表。财务真正头疼的，不是"同比怎么算"的解释，而是公式要逐格检查、缺项要补齐、结果要落到表格里。这些活儿，知道方法只完成了百分之十，剩下百分之九十是重复、枯燥、容易出错的动手环节。
AI 正在跨过的下一道门槛，正是从"生成内容"走向"完成任务"。而表格，是这道门槛上最典型、也最贴近每个人工作的场景。
什么是"智能体"，它和聊天机器人有什么不同
AI Agent，中文常叫"智能体"。这个词听起来抽象，但它和普通聊天机器人的区别，可以用一句话讲清：聊天机器人主要输出内容，智能体还会感知环境、调用工具、并真正改变环境。
一个能干活的智能体，至少要跑通这样一个闭环：
Plaintext
理解用户目标
-> 感知当前环境
-> 规划下一步行动
-> 调用工具执行
-> 读取执行结果
-> 继续行动，或把结果交还用户大模型只是这个闭环里负责理解和决策的"大脑"。光有大脑还不够------它得知道自己面对什么（环境上下文），知道自己能做什么（工具），有人替它把决定变成确定性动作（执行器），还得有人替它兜底，处理不确定性和失败（安全与恢复机制）。
判断一个产品是不是真有 Agent 能力，可以问几个朴素的问题：它知不知道用户当前在处理哪个对象？它能不能调用业务系统已有的能力？执行结果会不会影响下一步决策？高风险操作有没有人在管？做错了能不能反悔？如果这些都没答案，那再漂亮的聊天界面，本质上只是给老软件加了个问答入口。
表格，为什么是智能体最理想的练兵场
电子表格可能是办公软件里最普遍、也最容易被低估的一类工具。它既能是一张简单清单，也能承载预算、报价、排产、项目排期、经营分析甚至复杂财务模型。
表格工作有三个特点，让它特别适合交给智能体。
第一，目标好描述，过程很繁琐。"整理成月度经营报表"这一句话背后，可能藏着清洗数据、补公式、设数字格式、加汇总行、画图、查异常值十几步操作。人知道自己要什么，却未必愿意在菜单和函数里一个个翻找。
第二，既要理解，又要精确。哪些列参与计算、哪一行是表头，需要语义判断------这是大模型擅长的；公式写到哪个区域、图表引用什么范围，必须分毫不差------这是表格引擎擅长的。两者天然互补。
第三，表格一直在变。用户可能一边让 AI 整理数据，一边自己手动改数值、换选区、调格式。智能体不能把表格当成"上传一次就不再变"的静态文件，而要把它看成一个持续互动的工作空间。
SpreadJS 在这里扮演什么角色
要让 AI 真正操作表格，光有大模型不够，还得有一个"能被程序精确控制"的表格引擎。这就是 SpreadJS 的位置。
SpreadJS 是一个运行在浏览器里的 JavaScript 电子表格组件。对最终用户来说，它提供接近 Excel 的工作表体验------单元格、公式、样式、图表、透视表、条件格式、冻结、筛选，用户照样能选区域、改内容、看结果。对开发者来说，它提供一套可编程的对象模型，能用代码精确地控制数据、公式、样式、图表和导入导出。
这种"用户可见、程序可控"的双重属性，正是构建表格智能体的关键。用户不必离开熟悉的表格环境；AI 也不必靠模拟鼠标点击去戳界面，而是直接调用明确的接口完成写入、排序、筛选、建图。界面上看到的结果，是 SpreadJS 真实算出来、画出来的，而不是模型在回复里嘴上说一句"已完成"。
换句话说，SpreadJS 不是 AI 回答的展示容器，而是把自然语言落地成真实业务动作的那只"手"。
"做表格"和"看表格"，是完全不同的两件事
很多 AI 表格演示，会把单元格导出成一段文本或 CSV，丢给模型分析，再把分析结果展示出来。这解决的是"看懂表格"。
但真实工作簿远比一段文本复杂。它里面有工作表、活动单元格、多个选区、公式、样式、条件格式、图表、图片、冻结区、各种对象。一个单元格显示"25%"，底层值可能是 0.25；一列看起来普通的数字，也许由公式算出来；删一行，可能让别的公式引用全乱套。如果 AI 只面对一张被拍扁的二维文本，它根本无从理解这些关系。
所以，让 AI 操作表格，难点不在"接一个大模型 API"，而在于：怎么让模型这种概率性的决策，和表格系统这种确定性、有结构、会相互联动的执行，可靠地接在一起。这正是这一整套课程要拆解的核心工程问题。
七节课，一条完整的工程链路
这套课程围绕一个真实开源项目------SpreadJS AI Agent 展开，用七节课把"表格智能体"从里到外讲了一遍。七节课是一条连续的链路，每一节都接着上一节的尾巴。
第一课，完整链路总览。 用户说一句"在 A1 写入 Hello"，这句话怎么穿过页面、服务端、工具层，最后落到真实的表格里？这节课建立全项目的地图，定下一条核心原则：服务端做决策，浏览器执行真实操作。
第二课，表格上下文。 服务端的模型够不到浏览器里的工作簿，它凭什么知道当前有哪些表、用户选中了哪里、表格刚发生了什么变化？答案是上下文摘要和变更追踪------给 AI 配一张会持续更新的"工作簿地图"。
第三课，工具链。 为什么不能直接让模型写表格代码？因为 API 容易写错、参数容易乱、风险不可控。这节课讲怎么把高频操作封装成结构化工具，用 Schema 给参数加边界，让调用变得稳定可验证。
第四课，渐进式工具暴露。 当工具接近 90 个，全塞给模型反而会让它选错。这节课讲基础工具、网关工具、模块子工具的分层，以及一个状态机怎么在合适的时机只给模型合适的工具。
第五课，MCP 与代码执行。 固定工具表达不了复杂循环和跨表批处理时怎么办？项目引入了能直接执行代码的工具，但更难的是怎么保证代码不出错、出错能回滚。这里会讲到用 MCP 查 API、沙箱预执行和临时快照。
第六课，安全与人工确认。 AI 要覆盖已有数据、删除工作表、运行代码时，能不能直接动手？这节课讲破坏性操作检测、人工确认、主动提问和步数上限，把控制权留在用户手里。
第七课，快照、会话与调试台。 AI 做错了怎么反悔，复杂任务怎么追踪，不同方案怎么从历史节点继续尝试？这节课讲消息级快照、终止还原、会话分支、任务计划和调试台，让整套系统可恢复、可追踪、可维护。
不同的人，能从这里看到不同的东西
这套课不是写给某一个单一角色的，不同背景的人都能找到对自己有用的那一层。
普通用户可以借此理解，AI 为什么开始从"给答案"走向"做任务"，以及未来我们使用软件的方式，为什么会越来越多地变成"描述目标"。你不必懂代码，也能看懂这套系统在替你解决什么真实的麻烦。
产品经理可以看到，一个 Agent 产品不能只规划一个聊天入口，还要设计上下文、能力范围、确认时机、过程反馈和失败恢复。用户信不信任 AI，往往取决于这些细节，而不是模型跑分。
开发者则能看到一套具体而扎实的工程分层：模型负责决策，工具负责约束能力，业务代码负责确定性执行，上下文负责把真实状态带给模型，安全与快照负责兜底。这套分层可以迁移到文档编辑器、低代码平台、BI 系统、报表工具等几乎任何"浏览器里的业务对象"。
把 AI 从"能演示"推进到"能干活"
有意思的是，这套系统从头到尾都没有假设模型永远正确。恰恰相反，它承认模型会误解、会误选、会失败，于是用上下文让它看清楚、用工具给它画好边界、用确认机制把关键决定交还给人、用快照让一切都能反悔。
这或许才是表格智能体最值得借鉴的思路：真正可靠的 AI，不是那个从不出错的 AI，而是出了错也有办法兜住的 AI。
接下来七篇文章，我们就沿着这条链路，一节一节把它拆开。先从最基础也最关键的一条线开始------用户说的一句话，到底是怎么变成一次真实的表格操作的。