于是一个很自然的想法出现了能不能给 AI 接上表格 API 文档再给它一个代码执行器让它自己完成所有表格操作答案是能而且 Demo 往往做得很快。但如果表格里放的是预算、报价、库存或经营数据问题就从“模型会不会”变成了“我们敢不敢”。MCP 解决的是能力发现不是执行安全复杂表格组件的 API 数量很多。模型不可能把每个接口、参数和版本差异都准确记住。让它先通过 MCP 查询可靠文档再生成调用方案是一条合理路径。例如用户说在当前工作表里找出使用区域给最后一列加上合计公式再把结果导出。模型可以先查如何获取当前活动工作表如何获取已使用区域如何设置公式当前版本的导出方式。这里 MCP 的价值很明确把“凭记忆写代码”改成“查证后再行动”。但文档只会告诉模型某个 API 怎么调用不会替业务系统判断当前用户有没有导出权限是否允许覆盖最后一列公式应该写入数据区还是汇总区导出的文件能不能包含敏感字段失败后是否需要恢复工作簿。所以知识查询和执行授权必须是两层。一个更稳妥的三段式链路我更倾向于把复杂操作拆成三段第一段查知识 MCP 检索官方文档确认 API 和约束 第二段做计划 生成待执行步骤、影响范围和风险说明 第三段受控执行 参数校验 - 预执行 - 必要时确认 - 正式执行这里的“预执行”不一定要做完整沙箱。对于表格任务先计算影响范围就很有价值。比如模型计划清空某个区域执行器可以先返回{ operation: clear, sheetName: 报价单, range: A2:H800, nonEmptyCells: 4217, containsFormula: true, riskLevel: high }看到这个结果系统就不该静默执行而应该让用户确认。固定工具和代码执行不是二选一还有一个常见争论到底应该给 Agent 提供固定工具还是开放代码执行实际项目里这两种能力适合不同场景。高频、稳定、风险明确的操作应该做成固定工具写入单元格设置样式排序筛选插入公式新建工作表低频但组合复杂的需求可以进入受控代码执行按多层业务规则生成报表动态组合图表、公式和条件格式处理固定工具尚未覆盖的新 API问题不在于代码执行本身而在于是否有边界。一个可接受的执行器至少应做到只暴露允许使用的对象和方法禁止网络、文件系统等无关能力设置执行超时和最大步骤数执行前保存快照捕获异常并恢复记录代码、参数和结果。如果只提供一个 eval那不是 Agent 架构只是把风险藏进了聊天框。文档正确也不代表业务意图正确这是接入 MCP 后最容易产生的错觉。模型查到的 setFormula 用法可能完全正确但它仍然可能找错目标列忽略表头占一行把本地化公式名当成通用公式名在筛选后的表格中改到隐藏行覆盖原有计算逻辑。知识层解决“怎么调用”上下文层解决“现在是什么状态”业务规则解决“允许做什么”。三者缺一不可。把执行日志当成一等公民复杂 Agent 出问题时聊天记录通常不够用。真正有用的日志至少包括用户原始请求 工作簿上下文摘要 模型选择的工具 工具参数 确认记录 执行前快照 ID 执行结果 异常信息 执行后状态摘要这样才能回答“为什么它改了这 300 个单元格”而不是在一长串模型输出里猜。调试台最好还支持绕过模型直接输入参数执行单个工具。因为很多问题压根不是模型问题而是工具对合并单元格、保护区域或空选区处理得不完整。MCP 把门打开了门禁还得自己装MCP 让模型获得外部知识和工具能力这是 Agent 落地非常重要的一步。但企业应用真正关心的是调用是否可审计、执行是否可控制、失败是否可恢复。对于表格这种高密度业务数据载体尤其如此。可以让模型查得更多、计划得更灵活但最后按下执行键的那一层必须比模型更保守。在 SpreadJS AI Agent 的实战里我会专门拆解“先查知识、再受控执行”这条链路包括 MCP、预执行、快照和失败回滚。不是展示一个万能提示词而是把每一层的责任讲清楚。对应源码https://gitee.com/GrapeCity/spreadjs-ai-agent。项目基于 TypeScript/TSX 和 SpreadJSREADME 已整理工具体系、MCP 配置、受控代码执行、快照与恢复等入口适合边读代码边验证。本文相关看点MCP 查询、受保护的 execute_code、预执行与异常回滚。