SpreadJS Agent 是我们围绕电子表格智能交互做的一次完整探索。它最终获得了 “2025年度软件行业先进性科技成果” 奖项，但对我们来说，奖项只是结果。真正值得拿出来说的，是它把对话理解、产品知识、能力调用、代码执行和结果校正真正接到了一起，让 Agent 在 SpreadJS 这样的专业产品里，不只是“能聊”，而是“能做事”。
很多 AI 演示看起来很聪明，但一旦进入真实电子表格场景，问题就会很快暴露出来：理解不稳定、能力调用混乱、结果出错后缺少回路，最后给人的感觉往往是“会说，但不可靠”。SpreadJS Agent 想解决的，并不是让模型多说几句，而是让它真正能围绕 SpreadJS 干活，能理解任务、调用能力、检查结果，也能在必要的时候把错误收回来。
产品能力
MCP 接入
MCP 是 SpreadJS Agent 里非常重要的一层能力。很多同类产品在这一点上做得并不彻底，但对真实业务场景来说，尤其是财务、会计、数据处理这类场景，Agent 能不能接入外部知识和外部数据，往往会直接决定它到底是一个演示系统，还是一个能真正参与工作的系统。
SpreadJS Agent 在这方面做的是完整接入，而不是只留一个概念接口。系统内置了 SpreadJS 相关的 MCP 预置能力，同时支持用户自定义 MCP Server，支持动态工具发现，也支持授权接入和扩展式工作流。对用户来说，这意味着 Agent 不只会使用内置能力，也可以继续接入外部系统，把原本属于“系统外”的能力拉进任务链路里。
更重要的是，MCP 在这里不只是一个“插件入口”。它本身参与了 Agent 的工作方式。对于复杂任务，尤其是工具未完全覆盖、需要生成更强代码逻辑的场景，SpreadJS Agent 会优先利用 MCP 提供的产品知识和接口信息，再进入后续执行流程。这样做的结果，是模型在处理复杂代码任务时，能更接近真实产品能力边界，而不是只凭记忆和猜测生成代码。
工具系统
SpreadJS Agent 当前内置了 90+ 个能力点，覆盖数据读写、Sheet 管理、格式、条件格式、图表、透视表、表格、批注、数据验证、单元格状态、单元格类型、形状与图片、超链接、切片器、导入导出与外部检索等主要场景。对用户来说，这意味着它不是围绕几个演示动作搭起来的系统，而是一层相对完整的电子表格操作面。
但工具多本身并不等于好用。Agent 系统真正的难点，不是“有没有很多能力”，而是“这些能力能不能被稳定调用”。如果所有工具一次性全量暴露给模型，结果通常不是更强，而是更乱。工具越多，误调用、混用和工具幻觉就越容易出现。
为了解决这个问题，SpreadJS Agent 采用了 gateway 的方式来管理工具披露。系统把工具拆成基础能力、模块入口和模块内能力三层，默认只向模型暴露高频基础工具和模块入口，进入对应模块之后，再披露该模块的专属能力。这样做的结果，是模型在每一步真正看到的工具范围更小，注意力更集中，工具过载的情况会明显减轻。
这种设计的价值，不只是“减少出错”，还在于它让大工具集真正变得可用。对 Agent 来说，能力规模和调度稳定性必须同时成立，系统才会有真正的完成度。
代码执行
即便工具系统已经覆盖了大量场景，真实任务里仍然会不断出现“工具还没包到，但产品本身其实能做”的需求。SpreadJS Agent 在这里提供了另一层能力：受保护的 execute_code 工作流。
这不是简单开放一段代码执行入口，而是把代码生成放进了一个受控流程里。对于复杂批量操作、跨区域联动、循环分支逻辑，或者需要直接利用 SpreadJS 原生 API 的场景，Agent 可以进入代码执行模式，把单次 tool call 很难完成的事情拉回到可执行范围内。
更关键的是，这条链路不是裸奔的。系统会把产品知识、执行环境和结果保护一起接进来：前面有 MCP 提供的能力信息，中间有封装好的执行环境，后面有预执行验证、工作簿快照和异常回滚。这样一来，execute_code 的意义就不只是“能写代码”，而是“能在受控条件下生成更强的能力”。
从产品角度看，这一点很重要。因为这意味着 SpreadJS Agent 的能力边界，不会被“当前内置工具数量”卡死。工具覆盖的是高频显式能力，代码执行补足的是弹性能力，两者结合起来，系统的上限会更高。
上下文与会话
SpreadJS Agent 不是一个只看单轮消息的系统。它在上下文工程上做了比较完整的支持，包括工作簿状态注入、任务上下文维护、消息级快照、会话分支、会话恢复和上下文占用提示等能力。
对用户来说，最直观的体验是：系统不是“每轮重新开始理解”，而是在持续带着工作簿状态、任务进度和对话上下文往前走。对于电子表格这类强状态场景，这一点非常关键。因为真正的任务往往不是一句话完成，而是在一轮又一轮操作中逐步推进的。
我们也把不少工程化能力直接做成了产品特性。例如会话支持本地持久化与自动恢复，支持消息级工作簿快照和会话 Fork，支持会话导入导出，也支持导出诊断包用于问题定位。再加上上下文窗口用量显示，用户和开发者都能更清楚地知道当前系统处在什么状态，而不是把一切都变成黑盒。
模型与平台
SpreadJS Agent 在模型接入上也不是单一路径。系统支持多平台模型接入，包括 OpenAI 兼容路径以及多类主流模型能力。同时，图片输入和多模态能力也已经接入：当对话中出现图片时，系统可以自动切换到对应的多模态模型处理链路，而不需要用户手动切换工作模式。
这意味着 SpreadJS Agent 的底层不是被某一个模型或某一种平台绑定住的。对产品来说，这种多平台和多模式能力非常重要，因为它让 Agent 更容易适应不同环境，也更容易继续向外扩展。
系统设计
知识体系
在专业产品里，模型最大的风险，往往不是“完全不会”，而是“知道一点，但知道得不完整”。这种状态最危险，因为它会表现得很自信，但结果不一定对。SpreadJS Agent 围绕文档理解、知识检索、结果回查和能力确认建立了一整套支撑 Agent 的知识体系，它的目标不是简单增加背景信息，而是让模型在真正执行任务时，能够更可靠地理解产品，减少偏差，并在发现问题时有能力回到知识来源重新确认。
这也是为什么在 SpreadJS 这样的专业产品里，Agent 系统不能只靠模型本身。真正能拉开差距的，不是“第一次永远正确”，而是“出错以后能不能自己收回来”。
文档工程
在 AI 场景里，文档早就不只是给人看的资料。它同时也是知识来源、理解依据和结果校正的参照。如果底层文档质量不够，后面的知识体系再复杂，效果最后还是会塌。
相比之下，SpreadJS 的文档体系更完整，也更适合直接被 Agent 利用。它提供的不是零散信息，而是更稳定、更成体系的知识来源。接入之后，模型拿到的信息会更可靠，召回出来的内容也更像“能直接指导执行的知识”。从这个角度看，文档工程在 AI 时代已经不只是产品附属物，本身也是系统能力的一部分。
工程方法
除了知识体系和工具系统，我们在开发过程中也保持了比较明确的任务和过程控制。项目推进得越快，越需要有稳定的边界、有持续的记录，也有清楚的能力分工。这样做的价值很实际：系统不会轻易失控，后续复盘和迭代也不需要只靠个人记忆。
在正式推进之前，我们也长期研究过多类办公 AI 和 Agent 产品的能力边界、交互方式和实现思路。回头看，SpreadJS Agent 能做成现在这样，靠的不是某一个单点能力，而是这些前期积累在同一个项目里被系统地接了起来。
结果
从 demo 到产品雏形
SpreadJS Agent 最初的目标，是展示 SpreadJS 与 Agent 结合以后能做到什么。但真正推进时，我们没有把它当成一次简单演示。我们希望它交出来的，不只是“能展示”，而是一个真正可用、可继续演进的产品雏形。
回看
SpreadJS Agent 最终获得了 “2025年度软件行业先进性科技成果” 奖项。这个结果当然是认可，但如果只把注意力放在奖项本身，反而会忽略更重要的部分：它背后其实是一整套围绕专业产品做 Agent 的系统设计，包括 MCP 接入、工具披露、代码执行、上下文工程、文档工程和能力调度。
回头看，SpreadJS Agent 的价值，不只是把 AI 接到了电子表格里，而是证明了在专业软件场景里，Agent 要真正可用，靠的从来不是单一模型能力，而是围绕理解、执行、校正和演进搭起来的一整套系统。
