从 Claude for Excel 看 App 如何集成 AI Agent

我打开 Excel，发现里面可以直接使用 Claude，试着用它整理了一下，处理很快，修改也很准确。

这跟普通的 AI 功能有一个明显区别：Claude不只是接收一段内容，再生成一段内容，而是能够理解 App 当前的状态，调用 App 已有的能力，并把操作结果真正写回去。

我不禁想：一个 App 到底要怎样集成 AI Agent？Agent 又是如何获得上下文和执行能力的？

Agent 并不是直接控制 App

以 Claude for Excel 为例，它看起来像是在“操作 Excel”，但 Claude 并不是像人一样盯着屏幕寻找单元格，再移动鼠标完成修改。

Excel 本身提供了一套 Office Add-in 机制。开发者可以在功能区增加按钮，在右侧加载一个网页侧边栏，并通过 Office.js 读取当前工作簿、选中区域、单元格内容、公式和格式。

Claude for Excel 是 Claude 为 office 开发的一个 Agent 插件。侧边栏负责接收用户的自然语言指令，插件负责获取 Excel 的上下文，模型负责理解任务和规划步骤，真正修改单元格的仍然是 Excel 提供的接口。

例如，当用户提出“删除这一行的背景色”时，可以把 Agent 的执行过程理解成一次类似下面的结构化工具调用：

{  "tool": "setRangeFill",  "arguments": {    "sheet": "内容创作编辑器",    "range": "C94:C97",    "color": null  }}

Agent负责表达要修改的区域和目标格式，插件再将操作转换成 Excel 可以执行的接口调用。

执行完成后，Excel 会返回新的单元格状态，Agent据此判断任务是否已经完成，或者是否还需要继续处理其他区域。

在这个过程中，Agent更像一个负责理解、规划和决策的大脑。App 提供的上下文是它的眼睛，业务接口是它的手，执行结果则构成了持续反馈。

将 Agent 集成到 App 的两种方式

从目前的产品实践来看，App 集成 Agent 主要有两种方式：一种是把 Agent 直接嵌入 App，另一种是让 App 对外提供 Agent 可以调用的接口。

两种方式的入口不同，但底层逻辑相似：App 都需要把自己的上下文和业务能力，以结构化的方式开放给 Agent。

第一种：把 Agent 嵌入 App

Claude for Excel 属于比较典型的内嵌模式。Agent 的交互界面直接出现在 Excel 侧边栏里，用户不需要离开当前工作环境，就可以描述目标、查看执行过程和确认修改结果。

Figma、Photoshop 和 VS Code 也提供了相应的插件机制。开发者可以通过插件增加侧边栏、菜单或操作面板，同时调用宿主 App 的接口读取和修改当前文件。

例如，Figma Plugin API 可以读取当前选择的 Frame、Text 和 Component，也可以创建节点、修改填充颜色或调整 Auto Layout；VS Code 扩展则可以访问项目文件、代码诊断、Git 状态和终端。

这类集成通常包含几部分：

App├── 原有业务界面├── Agent 对话面板├── 上下文适配层├── Agent Runtime└── 可调用的业务工具

其中，对话面板负责承接用户输入和展示执行过程；上下文适配层把 App 内部的数据转换成模型容易理解的结构；业务工具则把原本隐藏在按钮、菜单和表单背后的能力开放给 Agent。

这种方式的优势是体验完整。Agent和用户处于同一个工作环境中，可以直接获取当前页面、当前选区和当前文档等上下文，修改结果也能立即呈现在用户面前。

但它通常需要针对不同 App 分别开发。Excel 使用 Office Add-in，Figma 使用 Figma Plugin API，Photoshop 使用 UXP，VS Code 也有自己的扩展机制。即使它们连接的是同一个模型，宿主能力和插件实现也不能直接复用。

第二种：让 App 对外提供 Agent 接口

另一种方式不一定要把 Agent 放进 App，而是通过 MCP、API 或本地通信协议，将 App 的业务能力提供给外部 Agent。

例如，一款内容编辑器可以开放下面这些工具：

document.getCurrentdocument.getSelectiondocument.replaceSelectiondocument.createVersiondocument.compareVersionsdocument.submitReviewdocument.publish

Claude、Codex、Hermes 或其他 Agent 客户端连接这些工具后，就可以获取编辑器状态并执行操作。Agent可以运行在独立客户端、命令行或其他工作平台中，App 只负责提供上下文、业务能力和执行结果。

它的结构更接近：

Claude / Codex / Hermes          ↓      MCP 或 API          ↓     App 业务工具层          ↓    文档、数据和流程

这种方式的优势是解耦。同一套工具可以被不同 Agent 调用，不必分别开发 Claude 版、Codex 版和其他模型版本。App 也不需要负责完整的 Agent 对话和任务编排，只需要把自己的业务能力定义清楚。

但如果 Agent 完全运行在 App 外部，用户对执行过程的感知会相对弱一些。修改预览、操作确认、版本对比和错误恢复等交互，仍然需要在 Agent 客户端或 App 中另外设计。

实际产品中，两种方式并不冲突。App 可以在内部提供 Agent 面板，同时将底层业务能力封装成 MCP Tools。内部 Agent 和外部 Agent 共享同一套业务逻辑，只是入口不同。

Computer Use：不是集成，而是从外部操作 App

App 集成 Agent 之外，还有一种经常被放在一起讨论的方式：Computer Use。

当 App 没有插件机制、业务 API，也没有为 Agent 提供工具时，Agent可以通过截图理解界面，再模拟鼠标、键盘和剪贴板完成操作。它同样能产生“AI 在操作 App”的效果，但严格来说，并不属于 App 集成 Agent，因为 App 本身没有做任何适配。

在 App 集成 Agent 的情况下，App 会主动提供当前状态和业务能力。Agent可以直接理解“当前选择了哪些单元格”“这个节点是什么类型”“文档处于哪个审核阶段”。

Computer Use 无法直接获得这些业务信息，只能从界面上推测当前状态。它看到的是按钮、输入框、菜单和弹窗，执行的是点击、输入和滚动。每完成一步，还需要重新观察界面，判断操作是否成功。

两者最核心的区别是：App 集成 Agent，是让 App 把能力交给 Agent；Computer Use，则是让 Agent学习如何使用一个没有为它准备的 App。

因此，Computer Use 更适合作为补充方案。当一个旧系统无法修改，也没有可以调用的接口时，它可以帮助 Agent 跨过界面限制。但对于能够持续维护和迭代的 App，开放结构化上下文和业务工具通常更加准确、稳定，也更容易进行权限控制。

接入模型不等于集成 Agent

很多 App 已经接入了大模型，但仍然停留在“输入一段内容，生成一段内容”的阶段，例如润色文本、生成摘要、回答问题或者补全表单。

这些功能主要完成一次请求和一次返回，不一定具备持续执行任务的能力。要真正集成 Agent，App 至少还需要补充四部分能力。

首先是上下文。Agent需要知道用户当前在哪个页面、选择了什么内容、正在处理哪个业务对象，以及这些对象之间有什么关系。把整个页面截成图片，或者把整份文档全部塞进 Prompt，通常既不准确，也不经济。App 需要把内部状态转换成模型能够理解的结构化上下文。

其次是工具。传统 App 的能力通常分散在按钮、菜单和表单背后。Agent无法直接使用这些人机界面，需要把底层能力重新封装成语义清晰的工具，例如“创建版本”“修改角色设定”“提交审核”，而不是“点击右上角第三个按钮”。

然后是执行反馈。Agent调用工具以后，需要知道操作是否成功、数据发生了什么变化、是否出现错误，以及接下来是否需要继续处理。没有反馈，Agent只能发出指令，无法形成完整的任务闭环。

最后是权限与变更控制。读取数据、修改内容、删除对象和发布结果，对应的风险并不相同。App 需要决定哪些操作可以自动执行，哪些需要用户确认，同时提供版本、撤销、日志和审计能力。

这些部分组合起来，才构成一个完整的 Agent 执行闭环：

用户提出目标    ↓App 提供上下文    ↓Agent 理解并规划任务    ↓调用业务工具    ↓App 执行操作    ↓返回状态和结果    ↓Agent 检查并继续执行

App 不仅要面向人，也要面向 Agent

过去设计 App 时，开发者主要考虑的是人如何通过按钮、菜单、表单和快捷键使用产品。Agent进入以后，App 还需要考虑另一种使用者：它怎样理解当前状态，又能调用哪些业务能力？

这并不意味着 App 要放弃原有界面，而是需要把业务能力从 UI 中进一步抽离出来。同一个“创建版本”能力，既可以由用户点击按钮触发，也可以由 Agent 调用工具触发。两种入口共享同一套业务逻辑、权限规则和状态管理。

从这个角度看，未来的 App 可能同时提供三种入口：面向人的图形界面、面向其他系统的 API，以及面向 Agent 的工具接口。

Claude for Excel 展示的不只是在表格里增加一个聊天框，而是一种新的应用集成方式：用户负责表达目标，Agent负责理解和规划，App 通过结构化能力完成执行。

这类产品目前主要属于 AI Agent 集成，还不能仅凭这些能力判断它是否是 AI Native。但它们正在推动一个明显的变化：App 不再只需要做到“可以被人操作”，还要逐渐变得“可以被 Agent 理解和调用”。

当越来越多应用开始开放自己的上下文、业务对象和操作能力，Agent 才可能真正从一个独立的聊天工具，进入具体的生产流程。

如果对你有帮助，点个在看 👇 让更多人看到

声明:本文为Canace 原创,不代表平台观点,未经许可禁止转载。