第一章：从 Coding Agent 到办公 Agent，为什么焦点开始转向办公室？

我最近观察到一个变化：前一段时间，大家谈 AI Agent，最容易想到的是让它读代码、改代码、跑测试、提交补丁。到了 2026 年，模型公司的产品介绍里，邮件、文档、表格、客户系统和审批流程出现得越来越频繁。这个变化常被概括成：AI 从 Coding Agent 转向办公 Agent。

这里先约定一个词。Agent 不是只会聊天的机器人，而是能够读取信息、调用工具、连续推进任务的软件助手。它可能先查资料，再改一份草稿，等待人的决定后继续执行。本文使用「办公 Agent」这个说法，指这类进入邮件、文档、表格和企业流程的 Agent；它是为了讨论方便的统称，并不是一个已经统一的行业术语。

Coding Agent 是很好的入口，因为代码通常放在代码仓库里，也就是集中保存源代码、文档和版本记录的项目目录。Agent 可以调用终端、测试框架和 Git，把需求拆成修改、运行、检查几个步骤。结果也容易验证：能否编译、测试是否通过、Diff 是否合理。Diff 可以理解成「这次改动前后具体多了什么、少了什么」的差异清单，做错了还可以回滚。

办公室任务没有这么整齐。「整理本周销售情况」可能意味着从邮件找需求，从文档确认口径，在表格中计算数据，查询 CRM，写报告，最后发给负责人并发起审批。CRM 是客户关系管理系统，里面可能存着联系人、商机和跟进记录。任务跨越多个系统和权限，还夹杂组织约定与人的判断。

难点因此不只是生成一段文字，而是让 Agent 知道该读什么、能改什么，以及什么时候必须停下来问人。聊天机器人可以给出建议；一个可靠的办公 Agent 设计，还应进入任务现场，维护步骤之间的状态，并为发送、修改、提交等关键动作保留人工确认。对企业来说，价值也不只在「回答得像不像人」，还在于能否少一次复制粘贴，少一次系统切换，并且留下可检查的过程记录。

Anthropic 与 Material 在 2025 年底对美国 500 多名技术负责人进行了调查。《2026 State of AI Agents》报告称，57% 的受访组织当前部署了多阶段工作流，其中 16% 跨越团队；报告把接近 90% 概括为 AI 辅助编码的比例。这个接近 90% 的数字描述的是调查中的编码辅助情况，不能直接理解为编码 Agent 的生产部署率。报告还把数据分析与报告生成、内部流程自动化列为值得关注的场景，但这些数字仍然只代表该项调查的样本。

从这四家公开产品路线看，变化更准确的说法是：AI 正在从编码工作扩展到更广的办公和企业流程。Coding Agent 证明模型可以参与生产工作；办公 Agent 要面对的，是生产工作背后的整套组织流程。

第二章：四家公司正在把 Agent 做成什么样？

如果只看名称，四家公司都像是在推出「更强的助手」。但从官方页面和公告的描述看，它们都在补齐一条链：让 Agent 获取组织上下文，跨应用调用工具，运行较长流程，并在身份、权限、评估或审批上接受管理。下面的比较是产品页面所强调的能力，不代表每个版本、地区或组织配置都能获得完全相同的行为。

产品路线官方页面主要强调的方向运行与治理关键词
OpenAI Frontier / Workspace Agents共享企业上下文、工具执行、跨工具长流程身份权限、评估、团队共享、按需或按计划运行
Microsoft Copilot CoworkWork IQ 支撑的跨应用办公任务多模型、插件、敏感动作检查、审计、预算与按使用量计费
Anthropic Claude Cowork在指定文件和工具中完成多步骤知识工作浏览器、插件、计划任务、过程可见、权限控制
Google Gemini Spark / Enterprise个人持续任务与企业连接、构建和治理Google 应用、Microsoft 365、CRM、Jira、Tasks、Skills、Schedules

OpenAI：把 Agent 做成共享工作流

OpenAI 在 2026 年 2 月 5 日介绍 Frontier 时，重点描述了共享业务上下文、工具执行、评估、身份和权限。数据仓库、CRM、工单系统和内部应用可以成为 Agent 的工作环境，Agent 也被放进组织成员、授权和管理的框架里。

4 月 22 日介绍 Workspace Agents 时，OpenAI 进一步强调了 Codex 驱动、团队共享、跨文件和连接应用的长流程，以及在 ChatGPT 或 Slack 中使用、按需运行或按计划运行的方式。官方页面把批准机制作为工作流控制的一部分，具体何时暂停仍要结合产品和配置理解。

Microsoft：把办公上下文和运行控制放在一起

Copilot Cowork 的介绍里，Work IQ 是用于理解邮件、会议、文件和业务数据等组织工作上下文的能力。Cowork 还被描述为可以跨 Microsoft 365、业务系统和插件执行较长任务，并提供模型选择、管理员控制、审计和预算管理。

Microsoft 的产品页面同时强调敏感动作检查。发送邮件、发布消息或修改共享文件等行为，可能触发审批或其他控制，通常应由用户确认，具体取决于产品和配置。Cowork 按使用量和 Copilot Credits 计费，是 Microsoft 的一个具体商业案例，不能直接外推为行业标准。

Anthropic：把 Claude Code 的执行方式带到知识工作

Anthropic 明确区分 Claude Cowork 与 Claude Code：前者面向研究、分析和文档制作等知识工作，后者仍面向软件工程。Claude Cowork 官方页面强调，用户可以指定文件夹和工具，让它执行多步骤任务，使用浏览器和插件，并处理后台或计划中的工作。

页面还强调了行动计划、打开的文件和调用的工具等过程可见信息。删除文件等敏感行为是否需要额外确认，应以具体产品流程和配置为准，不能概括成所有场景下都必然如此。

Google：把持续任务和企业连接分开推进

Google Gemini Spark 的官方页面强调后台任务，以及与 Gmail、Docs、Slides 等应用的连接。Tasks、Skills 和 Schedules 分别可以理解为任务、可复用的能力组件和定时运行安排，用来组织持续或重复的工作。发送邮件、消费等重大动作前的确认，是页面强调的控制方式，具体动作范围仍以实际产品为准。

Gemini Enterprise 的官方介绍则把重点放在企业连接、无代码 Agent、权限和治理上，连接范围包括 Google Workspace、Microsoft 365、CRM 和 Jira。这样看来，四家路线的共同点是把 Agent 从单次问答推向持续工作；差异在于切入点不同，有的从共享平台出发，有的依托办公套件，有的从编码执行能力扩展，有的同时覆盖个人任务和企业连接。

第三章：办公 Agent 比 Coding Agent 难在哪里？

如果把 Coding Agent 看成熟悉代码仓库的程序员助手，办公 Agent 就是要在组织里办事的工作助手。比如让它完成一份周报：读取数据、计算指标、查找历史结论、生成草稿、等待负责人确认，再发送给相关人员。任务看似简单，技术复杂度却明显上升。

1. 上下文从仓库扩大到组织

Coding Agent 主要围绕代码、Issue、终端和项目文档工作。办公 Agent 还要理解人员、团队、会议决定、历史文件、客户记录和流程状态。「上下文」就是完成任务所需的背景信息。它要把资料找出来，还要判断谁负责、哪份是最新版、哪些内容可以使用。拿错一张表，报告写得再漂亮也无效。

2. 工具调用变成跨系统编排

代码任务常围绕一个仓库使用终端和测试工具；办公任务可能依次调用数据平台、浏览器、邮件、表格、CRM、Jira 和内部 API。Agent 要选对工具、填对参数，把上一步结果交给下一步，并处理系统不可用、格式不一致或返回错误的情况。插件只是连接工具的方式之一，不能自动等同于安全隔离；真正的难点在于管理一条跨系统的执行链。

而且这些系统往往各有自己的「说话方式」：同一个客户可能使用不同编号，同一个日期也可能有不同格式。Agent 必须在调用工具前后完成转换和核对，否则一个小错误就会沿着整条链路继续传播。

3. 从一次生成变成长流程执行

办公任务可能要等待数据同步或人工审批，甚至后台运行几小时。系统因此需要「持久状态」，也就是进程暂停后仍记得做到哪一步；还需要重试、超时和幂等。幂等的意思是同一动作重复执行，也不会把邮件发两遍、把数据改两次。用户要能看到进度，任务卡住时可以接管，并从中断处继续。

4. 从代码审查扩展到组织责任

读取客户资料、修改业务记录、发送邮件和提交审批，都涉及权限与责任。系统需要限制 Agent 能读什么、能改什么；敏感动作可能触发审批检查，通常应由用户确认，具体取决于产品和配置，并留下审计记录。审计就是记录谁在何时以什么身份读取或修改了什么。安全仍取决于身份、授权、审批和系统限制。

5. 从编译测试扩展到真实后果

代码 Agent 可以用编译、测试和代码审查验收。办公 Agent 还要检查周报数字是否准确、资料是否过期、流程是否合规、权限是否越界、是否按时完成，以及错误会不会造成不可逆的副作用。更稳妥的周报流程是：Agent 收集资料并写草稿，系统校验关键数字，负责人确认，Agent 最后发送。

办公 Agent 的难点在于进入真实组织后，必须理解背景、调度系统、保存状态，并在责任边界内行动。Coding Agent 证明模型能操作代码；办公 Agent 还要让组织有办法验证它是否能够被可靠使用。

第四章：真正的竞争，是谁能成为企业的工作入口？

第二章列的是厂商如何描述产品，第三章拆的是系统为什么难做。把两章放回企业现场，我更关心另一个问题：员工会从哪里发起任务，Agent 又能否在任务发生的地方接住它？

如果 Agent 只待在聊天框里，它要等人想起它、打开它、写清楚指令。连接日历、邮件、文档、表格和 CRM 后，任务可能在新邮件、会议结束、数据更新、工单变化或固定报告时间出现。谁占住这些入口，谁就更接近企业每天真实发生的工作。

入口价值：少一次转交，少一次上下文丢失

抽象地想象一位销售负责人：每周一上午，他收到一条周报提醒，里面需要汇总销售表、核对上周异常、补充 CRM 中的跟进情况，再把报告交给区域经理。若 Agent 能在授权范围内读取这些来源，先生成带数据出处的草稿，负责人只需检查判断和措辞，工作就少了一轮复制粘贴。

这个例子是抽象示例，不对应某个真实客户。它想说明的是，办公 Agent 的价值不只在于回答「本周卖了多少」，还在于把检索、整理、计算、起草和交接放进一条可以检查的流程。流程越靠近工作入口，员工越不必在多个系统之间手动搬运上下文。

组织上下文：真正难搬走的资产

企业里的客户记录、内部术语、审批习惯、历史决策和权限关系，构成了 Agent 工作时需要的组织上下文。模型可以替换，调用接口也可以重新封装；但谁能在授权范围内持续理解这些信息，并留下可追溯的行动记录，谁就更接近流程核心。

这也解释了分发和生态的价值。办公套件、聊天工具、项目系统和业务平台都可能成为入口，连接器、插件和内部 API 则决定 Agent 能走多远。工具数量多不等于流程可靠，关键要看身份能否细分、数据边界能否解释、动作能否审计。

商业化：从买席位到买运行能力

长流程会消耗推理、上下文检索、工具调用和后台运行时间。至少从 Microsoft Copilot Cowork 的用量计费可以看到，企业可能同时面对基础席位费用和随任务消耗变化的使用费用。Cowork 按使用量和 Copilot Credits 计费，是一个具体案例，不能被外推成全行业统一的收费标准。

对供应商来说，Agent 可能从一个功能变成持续嵌入企业流程的基础服务。对企业来说，连接越深，迁移成本、权限管理、数据边界和供应商依赖也越重。选择时要问：数据能否迁移，权限能否细分，行动能否审计，必要时能否切回人工。长期留下的理由，应当是它能在权限范围内完成可验证、可追责、可复用的工作。

第五章：办公 Agent 什么时候真的有用？

办公 Agent 什么时候才是真的有用？关键不在于它像不像人，而在于这项工作是否适合交给一个「可以行动的助手」。我通常会先看下面六点：

  • 目标是否明确：Agent 要知道什么叫完成。「整理销售数据」太模糊；「按地区汇总本周销售额，标出比上周下降超过 20% 的地区并生成草稿」就清楚。
  • 资料和工具是否可访问：它需要在授权范围内看到文件、数据库或企业系统，不能凭聊天文字猜测。
  • 步骤能不能拆开：大任务要能分成可观察的小动作，每一步都有输入、输出和失败处理方式。
  • 结果能不能验证：数字、格式、来源或业务规则至少要有一项可以检查。
  • 失败后能不能回滚：误改文档、表格或记录后，应能撤销，或至少保留版本和恢复路径。
  • 关键动作能不能交给人审批：发送邮件、修改财务数据、发布公告、删除文件等动作，通常应由用户确认，具体取决于产品和配置。

权限和审计也不能省略。Agent 的权限应尽量小，操作过程要留日志。它是权限受限、可追踪、随时能被接管的程序，不能被当成「拥有全部账号密码的同事」。

拿「每周销售数据汇总」举例，可以这样安排：

  1. 读取资料，Agent 可自主执行：读取本周和上周销售表，记录数据范围和来源。
  2. 检查数据，Agent 可自主执行：核对列名、日期、金额和重复订单，把异常单独列出。
  3. 计算指标，Agent 可自主执行：按地区和产品线计算指标，标出明显变化，并保留计算依据。
  4. 生成草稿，Agent 可自主执行：把结果排版成报告草稿，不修改原始销售表。
  5. 发送报告，需要确认：负责人检查数字、措辞和收件人后，Agent 才能发送；系统同时保留报告版本、数据范围和审批记录。

出现问题时，操作者应能暂停任务、接管流程，必要时恢复旧版本。涉及开放式目标、不可验证的判断、不可逆操作，或者资料没有授权访问时，就不适合完全托管。例如处理所有客户投诉、决定员工去留、读完邮件后代表我回复，都牵涉隐私、责任和关系判断。Agent 可以分类、提取和起草，最终决定仍应由人承担。

因此，优先落地的方向通常是数据分析与报告、研究资料整理、内部流程自动化：重复性高，输入输出较稳定，过程易拆分，结果也容易复核。可靠的 Agent 不需要替人接管所有步骤，它先把机械工作做好，把判断、审批和接管权留给人。

第六章：结语——Agent 时代更重要的是设计工作，而不是堆模型

回头看，Coding Agent 解决的是「怎样让模型操作代码」：它可以读仓库、改文件、跑测试，再继续行动。办公 Agent 把问题往前推了一步：模型要进入真实组织，理解人员、流程和权限，在邮件、文档、表格、项目系统之间完成工作。这里比的不只是会不会生成答案，而是工作能不能被设计、验证和负责。

对开发者来说，下一步不该只是追模型排行榜。更值得补的是工具接口、状态管理、权限边界、日志和评估：失败后能否重试，重复执行会不会产生副作用，什么时候必须暂停等人确认。这些细节往往比换模型更决定系统能否上线。

对产品和组织，我建议从输入输出清楚、错误代价较低、过程可审计的流程开始。先让 Agent 读取资料、生成草稿、整理数据，把发送邮件、修改客户记录、提交审批留在人工确认之后。权限逐步开放，效果用节省时间、错误率和接管次数衡量，不要只看演示效果。

对普通使用者，Agent 更像需要授权和验收的工作伙伴，而不是可以无限放权的自动按钮。你可以让它先做检索、归纳和草拟，但要清楚它读了什么、改了什么、哪些动作已经发生。能执行，不等于该放任执行。

我自己的判断是，Agent 时代首先要设计的是工作，而不是先挑最强模型。下次设计 Agent，先画清楚它要读什么、调用什么、能改什么、何时等人确认，以及出错后由谁接管。上下文、工具、权限、审批、评估和人工接管，才是把模型能力变成组织能力的关键。

我参考了哪些资料

我查到的材料主要是 OpenAI、Microsoft、Anthropic 和 Google 在 2026 年公开的产品页面、公告，以及 Anthropic 与 Material 合作的《2026 State of AI Agents》调查。产品页面可以帮助我确认厂商如何描述和强调自己的产品，但不等于独立机构已经验证了所有宣传效果。

报告中的比例只属于它所调查的样本和口径，不是全行业普查结果。本文也只把这四家公司的公开材料作为观察样本，所以文中说的「产品路线变化」是基于这个样本的判断，不代表所有模型公司或所有企业的现状。