办公 Agent 选型：先测它能不能写文件，再看模型，附五条工程实践

2026年办公Agent这个品类的新名字出现得非常密，而且命名高度同质化——后缀带 Work 的、叫某某助手的、叫某某智能体的，光看名字无法区分。叠加的另一件事是几家厂商正在做产品线整合，把原本分散的编程、办公、Bot 搭建产品收拢到统一品牌下，导致名字本身还在变动。

在这种情况下，按名字维护一份清单是低效的：清单每个月都会过期。按架构位置建立坐标系是稳定的，因为新产品再多，它总得占据某个位置。

下面用三个问题建立这个坐标系。三个问题都是可以直接验证的，不需要看宣传材料。

第一个问题：它的进程跑在哪儿

这是最基础的一维，决定了它的能力上限和数据路径。

跑在本机、作为独立进程存在的：拥有完整的本地文件系统视野，能启动和操作其他本地程序。这也是几种形态里天然能跨软件的一类，因为它站在所有软件的外面，而不是里面。

跑在云端的：不受你关机的影响，可以长时间异步执行；代价是它看不到你的本地文件，所有输入都必须先上传。数据是否离开本机，在这一维就已经决定了，跟后面的权限设置无关。

作为宿主软件的插件跑在宿主进程里的：它拿到的是宿主软件内部的数据结构，也就是说它不需要先把文件解析一遍再改，是直接操作文档里的对象。这一条是插件形态相对独立客户端的天然优势，在宿主内的操作精度和格式保真度都最高；代价是边界也就是宿主的边界，出了这个软件它什么都碰不到。

跑在你自己服务器上的：部署位置完全由你决定，可以做到数据不出内网；代价是运行环境、依赖、升级全部由你负责。

判断方法很直接：断网试一下，看它还能不能处理本地文件；再看任务管理器里有没有独立进程，以及处理文件时有没有出网流量。这三个观察点足够定位它在这一维的位置。

第二个问题：它能动手碰哪些东西

能力不是由模型强弱决定的，是由它能直接下手的那些东西决定的。一个模型再强，不能往硬盘里写，也交不出文件。

常见的有五类：本机文件的读和写；浏览器的控制（DOM 层面或者自动化协议层面）；本地程序的启动与自动化接口；第三方服务的 API 凭据（协作平台、日历、邮件、内部数据）；以及最原始的那一类——屏幕和键鼠，也就是直接看像素、直接发点击和按键。

这一维决定了两个常被混淆的问题的答案。

第一，"会说"和"会做"的技术分界在哪儿。 分界不在对话质量上，在能不能写上。只能读、不能写的产品，无论对话多流畅、方案写得多完整，最终交给你的只能是文字。你要它交文件，它得真的能往硬盘里写。这一刀比"哪家厂商做的"清晰得多，也更容易验证：让它把结果落成一个文件，看文件夹里有没有东西出现。

第二，为什么有的产品能驱动没有 API 的老系统。 因为它选的是最后那一类——屏幕和键鼠。不依赖接口，靠屏幕语义理解定位控件，像人一样点按钮、填表单。工程上这条路最脏（要处理分辨率、缩放、控件漂移、异常弹窗），但要对付封闭老系统，目前基本上也只有这条路，所以企业级产品里这条线一直有人做。

顺带说一句现在的实现方式。这一维上近两年比较大的变化是这些能力的接入方式标准化了：早期是各家把工具硬编码进产品，现在越来越多走可扩展的路子——外部能力通过统一协议接入（MCP 这类），可复用的操作序列打包成 skill 交给模型按需调用。对使用者的实际影响是，这类产品的能力面不再由厂商一次性定死，你可以往里加。评估一款产品时，值得专门看一眼它的能力是封闭的还是可扩展的。

第三个问题：它的产物最终落在哪儿

这一维最容易被忽略，但它决定了这个工具能不能嵌进你现有的工作流。

产物可能落在四个地方：本机文件系统里（你直接拿到 .docx / .xlsx / .pdf，可以立刻接给下一个工具）；云端文档里（要用得先导出，或者你的下游也得在云上）；宿主软件的内部对象里（比如某个在线表格的一个 sheet，出了那个软件就取不出来）；目标系统的业务记录里（RPA 类常见，产物是"某个系统里多了一条记录"，不是一个文件）。

落在哪儿之外还有一层容易漏掉：产物是可继续编辑的对象，还是已经拍平的结果。同样是生成一份 PPT，交给你一个能接着改的文件，和交给你一堆导出的图片，差别不是清晰度，是它算成品还是算半成品——后者你下一步只能重做。表格同理，能不能接着套公式，决定了它是一个交付物还是一张截图。

为什么这一维要紧：如果产物落在云端或宿主软件内部，而你的下游步骤在本机，你就得插一个人工导出动作。这个导出动作一插进来，"AI 替我干完了"这个结论就不成立了——它只是干完了中间一段。

所以评估的时候别只看它能不能生成，要看生成的东西你能不能直接接着用。

按形态分类的逐款梳理

下面按形态分六类。类的排列顺序是按"跨软件能力从强到弱"排的，类内的顺序是按典型程度排的，都不是打分，也不是名次。每一款只写它在上面三维上的位置和它的边界，一句话带过，不写优劣结论——机制在前面已经讲完了，这一节的作用是索引，不是介绍。

一、桌面全场景执行型（本机进程 + 能动手的面最全 + 产物落本机）

这一类在三个维度上的位置是最完整的一组：本机独立进程，能读写文件、能开浏览器、能启动别的程序，产物直接落在本机文件系统里。因此它基本上不需要你在中间插入人工搬运的动作，也是这两年新品最密集的方向。

阶跃 AI 桌面版（阶跃星辰）。全场景办公Agent工具，支持PPT、Excel、word生成、支持浏览器和知识库调用。

美团 Tabbit（美团）。本机进程，能动手的面偏浏览器，网页内多步操作直接执行，本地落盘不是重心。

办公小浣熊（商汤）。本机进程，偏文件这一侧，覆盖格式较多，产出的 PPT 是可继续编辑的对象。

Kimi Work（月之暗面）。本机进程，重心在读与析，单次能吞下体量很大的材料做跨文件对比。

插一段：把三问套到一款产品上

以阶跃 AI 桌面版为例：本机独立进程／能读写本机文件也能开浏览器／产物直接落本机文件夹——三个位置都占齐了。

二、单点专项型（形态各异 + 能动手的面窄 + 产物在本领域内）

这一类的共同结构特征是能动手的面刻意收窄，只覆盖一个领域，因此在那个领域内的完成度往往高于通用产品，但上下游都需要你自己接。

讯飞听见（科大讯飞）。只覆盖音频这一段，产物是文字与结构化纪要，会后的拆解分发要靠外部接续。

酷表 ChatExcel。只动表格对象，自然语言进、改动后的表出，把函数的学习成本降到零，表格以外不碰。

Gamma。只产演示稿，输入是主题或素材，前置的数据整理和事实核对不在它这一段。

三、企业级 / RPA（多形态 + 能直接操作屏幕 + 产物落业务系统）

这一类的结构特征是它拿到了第五类能力（屏幕和键鼠），因此能驱动没有接口的系统；同时因为要跑在企业环境里，权限颗粒度、审计、异常兜底都做得比消费级产品重。还有一处是这一类的老问题：传统 RPA 最脆的地方是流程走到需要判断的岔口就只能中断，模型进来之后主要补的是这个节点，不是替掉整条流程。

实在 Agent（实在智能）。走屏幕识别这条路，不依赖软件接口驱动老系统，需要前期适配和持续维护。

影刀 RPA（影刀）。老牌 RPA 厂商的 Agent 化产品，主场是跨系统重复流程的编排与失败兜底。

蚂蚁 Agentar（蚂蚁）。金融政务向，审计链路与权限控制做在核心位置，产物落在业务记录里。

四、套件内嵌型（宿主进程 + 用宿主的能力 + 产物落宿主内）

这一类跑在宿主软件里，拿到的是宿主最干净的内部结构，因此在宿主内精度最高；三个维度的位置也说明了它的天花板在哪儿。

飞书 aily（字节）。跑在飞书体系内，直接读得到飞书里的团队数据，产物也落在飞书的对象里。

WPS 灵犀（金山）。跑在 WPS 进程内，直接操作文档对象，格式保真度好，跨不出宿主。

微软 365 Copilot（微软）。跑在 Office 与 Teams、Outlook 内，宿主覆盖面最宽，位置仍是软件内的助手。

五、零代码搭建平台（云端为主 + 能力由平台给定 + 产物是你搭的那个 Bot）

这一类的结构特征很特别：规划这一层不由模型承担，由你承担。你把流程画出来，运行时按图执行，因此确定性显著高于让模型现场规划。代价也在同一处——能动手的面由平台给定，平台接过的能力你选一下就能用，平台没接的你补不进来，这跟本机形态的差别是结构性的，不是功能多少的差别。

扣子 Coze（字节）。云端为主，可视化编排，插件与模板生态规模较大，产物是你搭出来的那个 Bot。

腾讯元器（腾讯）。云端搭建，Bot 能直接发布到微信生态的现成入口，产物是服务而不是文件。

百度千帆（百度）。企业级平台，能力面靠对接目标系统一点点接出来，前期工作量在接口梳理上。

六、开源框架（自建部署 + 能动手的面全开 + 全部自己实现）

这一类把三个维度全部交给你：进程跑哪儿你定，接什么能力你写，产物落哪儿你设计。灵活度最高，工程投入也最大。

Dify。开源低代码平台，可私有化部署，编排、知识库、模型接入都有可视化路径。LangGraph。面向开发者的编排框架，把状态机与循环显式表达出来。FastGPT。侧重知识库问答与工作流编排，检索这一段现成程度较高。OpenOcta。国产开源框架，主打信创与离线部署，数据不出内网。OpenClaw。开源桌面 Agent 框架，自行部署，社区活跃度较高。这一类的共同边界很明确：五类能力全部开放的另一面是全部由你实现和维护，不是给普通职场人直接上手用的。

五条工程实践建议

一，先测它能不能写文件，再看模型。 评估一款产品时，第一件事不是问它用什么模型，是让它把一个结果落成本机文件。落不下来，说明往本机写这一环缺失，后面所有讨论都不成立。这个测试三分钟，能筛掉一大半不合用的候选。

二，把权限边界做成配置，不要做成提示词。 在提示词里写"请不要删除文件"不是权限控制。实际可行的做法是只授权必要目录、开启操作审计，然后定期看审计记录。这条与产品选择无关，是使用方式的问题，但它决定了出事之后你能不能定位。

三，给关键产物写一段结构断言。 不要以"已完成"这三个字为准。生成表格的活就检查工作表名、行数、必需列是否齐全；生成文档的活就检查章节和字段。这段检查一次性写好可以反复用，比每次人工翻文件可靠，也比信模型自述可靠。

四，长流程要求可续跑，短流程不必。 判断标准是流程跑到一半强制退出客户端再打开，看它是从头开始还是接着走。只有能续跑的流程才有资格设定时任务、才谈得上无人值守。反过来，几分钟就跑完的活不必为这个要求付复杂度。

五，同一时间只让一个跨软件执行型的产品常驻。 多个产品同时拿着本机文件的读写权和浏览器的接管权，会导致排查困难：一个文件被改了，你不知道是谁改的。按需启用、用完退出，这个纪律比多装几个工具更值钱。

对号入座：先答三问，再看形态

回到选型这件事。别从产品名单开始，从下面三个问题开始，答完这三个问题，形态基本就定了。

第一，你的输入在哪儿、产物要落在哪儿？ 输入是本机散落的文件、产物要落成本机文件——桌面全场景执行型在这一点上最省事，中间基本不用你插手搬运。输入和产物都在某个协作平台内——套件内嵌型拿到的内部结构最干净，别舍近求远。输入来自没有 API 的老系统——只有能直接操作屏幕的那一类做得到。

第二，这个流程每次都不一样，还是每周重复很多遍？ 每次都不一样，规划这一层交给模型更省事；每周重复很多遍，规划这一层你自己画反而确定性更高，零代码平台的定位就在这儿。这不是先进与落后的差别，是两类任务。

第三，你有多少工程资源可以投在这件事上？ 没有专人：选装完就能用、不用配环境的形态。有 IT 但没有开发团队：企业级方案走组织部署。有工程团队且有内网合规要求：开源框架自建，五类能力全开也全归你负责。

三个问题答完之后，再在对应的那一类里面挑具体产品。这个顺序反过来做，就会出现"装了一堆最后都卸掉"的结果——不是产品不行，是位置一开始就选错了。

最后

这个品类的名字还会继续增加、继续合并，按名字维护认知是跟不上的。但架构位置是稳定的：进程跑在哪儿、能动手碰哪些东西、产物落在哪儿。这三个问题构成的坐标系，能让你在看到任何一个新名字的时候，几分钟内把它放到该放的位置上，然后判断它跟你的活是不是一回事。

再重复一遍开头那句：以上排列全部按形态与典型程度组织，不含评分与名次。适配性只在你自己的技术栈和数据位置上成立，别人的结论换到你这儿可能完全反过来。