企业微信开放CLI、飞书产品团队并入豆包：办公正在从“操作”走向“委托”

企业微信开放办公能力，字节整合飞书与豆包，看似方向相反，实则共同指向办公模式的深层变革。本文从产品与战略视角，解析Agent如何从工具变为办公核心，推动办公从“人操作软件”转向“人委托任务”的新范式。

近期，企业微信在“AI开放能力”页面列出了WorkBuddy、DeepSeek Harness、MiniMax Code、Kimi Work、Codex和企业自研智能体。页面展示了消息、邮件、文档、表格、待办、日程、会议、微盘和通讯录等办公模块的开放能力。

几周前，字节跳动也调整了AI业务组织：飞书产品团队与豆包产品团队整合，飞书的市场、销售与客户服务团队则进入火山引擎的ToB体系。字节给出的解释是，加强豆包、飞书和火山引擎在企业生产力场景中的产品与服务协同。

两件事看起来方向相反。企业微信是在向外开放，让不同Agent调用自己的办公能力；字节是在向内整合，把飞书的企业知识和协作工具放进豆包的产品体系。

如果只看单个动作，企业微信像是增加了一种开发者接入方式，飞书像是经历了一次组织架构调整。但把两件事放在一起，会看到一个更完整的变化：Agent正在移动到办公软件上层，办公软件则开始成为Agent获取信息、调用工具和交付结果的工作环境。

这可能意味着，办公正在从“人操作软件”转向“人委托任务”。用户不再负责完成每一个操作步骤，而是提出目标、设定边界和验收结果；Agent负责在企业权限范围内查找信息、调用工具和推进流程；人则在关键决策、风险操作和异常环节介入。

这个变化还没有完成。企业微信开放接口，不等于企业已经愿意把真实工作权限交给Agent；飞书产品团队进入豆包体系，也不等于豆包已经能够稳定完成复杂的企业任务。但两家公司正在补齐同一种办公模式需要的不同部分。

一、两家公司分别补上了Agent办公的哪一层

这里所说的Agent，是能够理解目标、拆解任务、调用外部工具，并根据执行结果继续行动的AI系统，其职责已经超出回答问题。

一个Agent可以写出会议邀请，并不代表它能真正安排会议。它还需要知道邀请哪些人、读取成员的空闲时间、访问相关材料、创建日程、发送通知，并在时间冲突或权限不足时请求用户处理。模型负责理解和规划，办公系统负责提供数据、工具和业务状态，两者缺少任何一边，任务都只能停留在建议层面。

企业微信CLI补上的，是办公系统的执行层。

CLI是命令行工具。对普通员工来说，命令行不一定比图形界面更方便；但对Agent而言，结构化的命令、参数和返回结果，比识别界面位置、模拟鼠标点击更稳定，也更容易组合成多步骤任务。

企业微信官方开源项目目前明确列出了消息、文档、智能表格、通讯录、待办、会议和日程等能力。例如，Agent可以查询会话、读取文档、搜索成员、查看多人闲忙、创建会议并更新待办。

这并不意味着所有企业、所有接入模式都已经获得完整权限。官方项目对个人、小团队和较大企业的开放范围作了区分，具体能力还受到机器人身份、组织规模和管理员授权的影响。企业微信新页面展示的能力范围也比当前公开仓库中的说明更广，实际接入时仍需要逐项核对。

即便存在这些限制，产品方向已经比较明确：消息、会议和文档不再只是员工在界面中使用的功能，也被包装成Agent可以理解和调用的工具。企业微信不必把所有Agent入口掌握在自己手中，也可以通过开放能力，成为不同Agent共同依赖的办公执行环境。

字节正在补齐另一部分：让Agent进入企业工作场景，并获得组织上下文。

2026年7月30日，飞书产品团队与豆包产品团队整合，成立新的豆包产品团队；飞书的市场、销售和客户服务团队与火山引擎整合，统一承接MaaS、SaaS等企业服务的商业化工作。飞书原有产品和服务继续保留，并没有因为组织调整而被取消。

这次调整更值得关注的是办公产品的未来路线由谁主导。飞书品牌目前仍然保留，飞书产品团队进入豆包体系，则意味着办公场景的产品优先级更可能围绕Agent重新组织，而不是继续把AI作为文档、会议和表格中的附加功能。

飞书官网对豆包企业版的描述已经呈现出这种关系。“飞书里的豆包”是豆包企业版在飞书中的工作入口。豆包可以在授权范围内使用企业文档、知识和组织工具，也可以调用云端电脑、浏览器以及飞书文档、表格和日历，交付可以继续编辑和分享的成果。

在这套关系中，豆包负责理解目标、规划任务和组织模型能力；飞书提供企业知识、人员关系、身份权限、协作工具和任务结果的承载位置；Seed模型提供推理与多模态生成能力；火山引擎提供模型服务、运行环境和企业商业交付。

企业微信是从办公系统一侧向上开放，让系统能够被不同Agent调用。字节是从Agent入口一侧向下整合，让豆包能够进入企业知识和协作环境。两条路径正在相向而行。

企业微信从办公系统向上开放，字节从Agent入口向下整合，两条路径最终汇入同一条任务链。

它们共同指向一条新的办公链路：用户提出目标，Agent理解并拆解任务，企业系统提供数据和工具，权限体系约束可执行范围，人负责确认关键动作并验收结果。聊天框只是这条链路中的意图入口。

当这条链路能够稳定运行时，办公的基本单位就会发生变化。用户面对的不再只是“创建文档”“更新表格”或“安排会议”等单个功能，而是一个可以被整体委托、持续执行和最终验收的工作任务。

二、从操作式办公到委托式办公，改变的不是聊天框

企业微信开放办公能力，豆包进入飞书的企业环境，这些变化很容易被概括成一句话：未来用户不需要点击按钮，只要对AI说一句话就能完成工作。

这种描述抓住了交互形式的变化，却没有解释办公模式真正改变了什么。自然语言只是新的输入方式。如果用户仍然需要逐步告诉AI打开哪个文档、复制哪段内容、填写哪个表格、邀请哪些人，那么用户只是把鼠标操作换成了语音或文字指令，任务规划和过程控制仍然由人承担。

判断一种新办公模式是否出现，需要看任务的理解、规划、执行和责任如何在人与系统之间重新分配。

操作式办公：人理解任务，也负责完成步骤

在传统桌面办公中，用户既是任务决策者，也是软件操作员。

假设产品经理需要组织一次季度复盘，他需要自己确定资料范围，打开群聊、文档和数据表，搜索用户反馈，核对指标口径，整理分析材料，再进入日历查询时间、创建会议和发送邀请。

软件提供的是搜索、编辑、计算、发送和创建等功能。软件可以提高单个步骤的效率，但不会主动理解这些操作共同服务于什么目标。用户需要记住任务进行到哪里，也需要在不同软件之间搬运信息和维持上下文。

操作式办公的基本单位是功能。用户想完成一项工作，需要把它拆成一系列软件能够执行的操作。

协同办公：信息进入共享系统，协调责任仍然属于人

飞书、企业微信和钉钉等协同办公产品改变了信息的存放方式。文档、会议、消息、日程和项目状态进入共享空间，成员可以围绕同一份内容持续协作。

协同办公减少了文件反复传递和版本不一致的问题，也让组织中的信息更容易被搜索和复用。但在大多数情况下，仍然需要人判断应该查找什么、联系谁、使用哪个工具，以及下一步怎样推进。

产品经理可以在群聊中找到反馈，在共享表格中查看数据，在日历中协调参会人，但这些功能不会自动组成一次完整的产品复盘。信息已经连接起来，任务规划仍然分散在人的头脑中。

协同办公的基本单位逐渐从个人文件变成共享对象，例如一份多人编辑的文档、一个项目或一张业务表格。人的角色从个人操作员变成协作组织者，但人仍然负责连接不同工具和推动流程。

流程自动化：系统按照预先定义的路径执行

企业已经使用工作流、RPA和自动化规则处理大量重复任务。表单提交后自动通知审批人，会议结束后自动保存录制文件，客户状态变化后自动创建跟进任务，都属于流程自动化。

流程自动化的特点是执行路径事先已经确定。产品或业务人员需要提前配置触发条件、操作节点、数据字段和异常规则。只要输入符合预期，系统就能稳定重复执行；如果任务目标、数据格式或业务条件发生变化，通常需要人工修改流程。

它适合边界明确、规则稳定、重复频率较高的任务。它的限制也来自同一个地方：系统擅长执行已经定义好的流程，却不能轻易处理路径未知、材料不完整或需要临时判断的工作。

流程自动化解决的是“怎样更稳定地重复一个已知过程”，还没有把任务规划交给系统。

委托式办公：人描述结果，Agent动态组织过程

委托式办公改变的是人向系统提供的信息。

用户不再完整描述每一个操作步骤，而是提供任务目标、必要约束和验收标准。例如：

整理上季度的用户反馈和核心指标，找出当前版本的主要问题，生成一份产品复盘材料，并安排本周的复盘会。数据口径不确定的地方先问我，会议邀请发送前让我确认。

这段要求没有指定Agent必须打开哪些文档、使用哪张表格或按照什么顺序执行。Agent需要结合用户权限和企业上下文，自主判断需要查找哪些信息、选择哪些工具、记录哪些任务状态，并在口径冲突时把控制权交还给用户。

这里的“委托”不是让Agent无限自主运行。它表示用户把任务规划和部分执行权交给Agent，同时保留目标设定、高风险授权、结果验收和责任承担。

委托程度需要根据任务确定性和操作风险调整。资料整理、格式转换和内部信息汇总可以给予较高的自动执行权限；涉及外部发送、数据删除、合同审批、人员评价和资金操作时，Agent需要展示依据、请求确认，必要时转交人工。

这也是委托式办公与流程自动化的关键区别。流程自动化由人预先定义固定路径，系统负责重复执行；委托式办公由人定义目标和边界，Agent根据实际上下文动态选择路径。两者不会互相替代。Agent可以调用已有工作流，也可以在任务条件稳定后，把部分执行过程沉淀成新的自动化流程。

自然语言在这个过程中只是意图入口。委托式办公能否成立，取决于Agent能否理解组织上下文、调用正确工具、维持长任务状态，并在权限不足、信息冲突或执行失败时做出合适处理。

办公软件的图形界面也不会因此消失。它需要承担新的控制职责：展示Agent的执行计划和当前状态，解释信息来源，确认高风险动作，允许用户修改中间成果，并为错误操作提供暂停、撤销和恢复入口。

当任务规划和部分执行权开始转移，办公产品的基本单位也会从单个功能和共享对象，继续走向可委托、可跟踪、可验收的任务结果。产品设计面对的不再只是一组页面和按钮，而是一条由用户、Agent、企业数据、工具和人工确认共同完成的任务链路。

真正发生变化的不是输入方式，而是任务规划与执行责任逐步从人转移给系统。

三、一项工作怎样从“人操作软件”变成“Agent推进任务”

委托式办公不能只停留在“用户说一句话，AI自动完成工作”的描述中。产品是否成立，要看这句话进入系统以后，模型、企业知识、办公工具、业务规则和人工分别做什么，以及任务在哪些地方可能中断。

下面仍以“季度产品复盘”为假设场景，拆解一条相对完整的Agent办公链路。这个场景属于基于当前公开的知识检索、文档处理、表格分析、日程和会议调用等能力构建的目标形态，并非对企业微信、豆包或飞书现有功能的实测。

产品经理向Agent提出要求：

整理上季度的用户反馈和核心指标，分析当前版本的主要问题，生成产品复盘文档和汇报材料，并在本周安排一次复盘会。数据口径不确定的地方先问我，会议邀请发送前让我确认。

这项任务同时涉及信息检索、数据分析、内容生成、日程协调和对外发送。任何一个单独的AI功能都无法完整覆盖它，Agent需要维持一项持续运行的任务。

理解目标，而不是立即执行

Agent接到任务后，需要把自然语言转换成可执行的任务定义。

“上季度”对应哪个具体日期范围，“用户反馈”包含群聊、客服记录还是调研文档，“核心指标”采用哪个业务看板，“主要问题”按照用户影响、商业影响还是技术严重度排序，这些信息不能完全依靠模型猜测。

系统可以根据企业上下文补充一部分信息。例如，读取当前产品所属项目、默认数据空间和过去的复盘模板。但当不同解释可能显著改变结果时，Agent需要向用户确认，而不是选择一个看起来合理的答案继续执行。

一个可用的任务定义至少要包含：目标、时间范围、材料范围、交付结果、权限约束、需要人工介入的确认点和最终验收标准。模型负责解释用户意图，业务规则负责约束任务边界，用户负责确认会改变结果的重要条件。

建立执行计划，并检查身份与权限

任务范围明确后，Agent需要形成执行计划。计划可以包括查找资料、整理反馈、读取数据、分析问题、生成材料、协调会议和沉淀待办，但系统不能因为计划合理，就默认拥有执行权限。

企业办公中的权限与普通网页搜索不同。同一份文档可能只对特定项目成员开放，同一个Agent也可能以用户身份、机器人身份或企业应用身份运行。三种身份能够访问的数据和执行的动作并不相同。

Agent需要知道当前代表谁访问企业资料，可以读取哪些消息、文档和表格，是否具备创建文档和会议的权限，哪些结果只能生成草稿，以及哪些动作会影响其他成员。

权限不足不应该被当成普通任务失败。Agent可以缩小材料范围、请求补充授权，或者把无法执行的步骤转交用户。产品需要明确告诉用户哪些资料已经读取，哪些资料因权限限制没有进入分析。否则，一份看似完整的报告可能只是基于局部信息得出的结论。

收集材料，并保留信息来源

进入资料收集阶段后，企业知识系统负责提供消息、文档、会议记录、版本说明和用户反馈，办公工具负责查询和读取，模型则负责识别材料与当前任务的相关性。

Agent不能把搜索到的所有内容直接放进上下文。重复反馈、过期文档、无关讨论和不同版本的数据会干扰判断。系统需要完成去重、时间筛选、版本识别和来源记录。

例如，同一个功能问题可能出现在客服记录、用户群和复盘文档中。三处信息可以互相印证，但不能简单计为三个独立用户反馈。某份指标表可能在季度中途修改过统计口径，旧版本与新版本也不能直接合并。

这一阶段的产品关键在于Agent能否说明材料来自哪里、对应什么时间、是否属于当前有效版本，也要记录被排除的内容、仍然缺失的信息和支持结论的证据。资料数量本身不能证明分析完整。

保留来源不仅方便用户检查，也是后续纠错的基础。如果用户发现某份文档已经失效，Agent需要能够移除这份材料，并更新受它影响的分析结果。

分析信息，在冲突处暂停

材料准备完成后，模型可以对用户反馈进行聚类，结合版本变化分析问题原因，并读取表格数据寻找指标异常。

模型擅长从大量非结构化信息中发现主题，却不能替代业务口径。假设用户反馈显示“搜索结果不准确”是高频问题，而数据表中的搜索成功率却在提升，Agent不能自动选择其中一方作为结论。

这种冲突可能来自不同原因：数据指标只统计是否返回结果，没有衡量结果质量；用户反馈集中在某类特殊查询；统计口径在季度中途变化；反馈样本来自新版本，指标仍包含旧版本；高价值用户的问题被总体数据稀释。

Agent可以提出解释假设，并继续查找支持材料，但不能把未经验证的解释写成确定结论。信息冲突会显著影响产品判断时，系统需要展示差异、说明可能原因，并请求产品经理选择分析口径或补充资料。

人在这里承担业务判断。Agent负责扩大可见范围、整理证据和暴露矛盾，产品经理负责决定什么信息足以支持结论，数据搬运则可以更多地交给系统完成。

生成成果，并允许用户修改中间结果

分析得到确认后，Agent可以生成复盘文档、数据图表和汇报材料。成果不应只是几份相互独立的文件，而要共享同一组事实、指标口径和问题判断。

如果用户修改了复盘文档中的核心结论，汇报材料和会议议程也需要同步更新。Agent需要维护任务状态，知道哪些成果已经确认，哪些仍是草稿，哪些内容会受到上游修改影响。

用户在这一阶段还要看到指标口径与企业材料来源。界面需要把模型推断和未验证问题单独标记，并说明修改某项结论会影响哪些后续成果。

只有当中间结果可以检查和修改，用户才可能逐步建立对Agent的信任。一次性生成一份看似完整的报告，无法替代可追踪的任务过程。

执行外部动作，把决定权留在正确位置

复盘材料完成后，Agent可以查询相关成员的空闲时间，提出会议时间、参会人和议程建议。创建会议和发送邀请会影响其他成员，属于需要用户确认的动作。

系统应当展示准备执行的内容，包括会议时间、参会人、邀请范围、会议议程和附带材料。用户确认后，Agent再调用日历和消息工具完成创建与发送。

如果某位关键成员没有共同空闲时间，Agent可以提供替代方案，而不是自行降低参会范围。因为谁必须参加复盘会属于组织判断，不是日程优化问题。

会议结束后，Agent还可以读取会议纪要，提取行动项、建议负责人和截止时间。待办在写入任务系统并分配给成员之前，同样需要确认。Agent可以准备执行，人仍然决定哪些讨论形成正式承诺。

区分完成、部分完成与失败

复杂任务很少只有成功和失败两种结果。

复盘文档已经生成，但数据口径尚未确认，属于部分完成；会议时间已经找到，但用户还没有批准发送邀请，属于等待确认；关键资料无法访问，导致分析缺少必要证据，则属于受权限阻塞。

产品需要展示完整的任务状态：已完成交付、执行中的步骤、待确认操作、因权限或资料不足产生的阻塞、失败动作和可用的恢复方式。

Agent不能用一段“任务已完成”的自然语言回复掩盖中间失败。真正的任务完成，需要同时满足结果已经交付、关键约束没有被违反、外部动作获得授权、执行过程可以追溯。

委托式办公让一个任务在用户、模型、企业知识、办公工具和业务规则之间持续流转，而不止于让模型一次生成更多内容。Agent的价值取决于它能否在正确的步骤继续执行，并在信息不足或风险上升时把控制权交还给人。

一项真实任务需要保留依据、设置确认点、保存中间状态，并在失败后继续恢复。

四、两条平台路线：开放执行层与一体化Agent平台

企业微信和字节都在为委托式办公补齐基础能力，但两者选择的路径不同。

企业微信正在把消息、文档、会议、日程和待办等能力开放给多种Agent。字节则试图把豆包、飞书、Seed模型和火山引擎组织成一套相对完整的企业AI体系。

一条路线强调让更多Agent接入，另一条路线强调从模型到办公场景的纵向整合。竞争范围覆盖办公软件用户、用户意图、任务安排、关键动作的执行权，以及任务数据最终留在哪里。

开放路线争取成为多种Agent共同调用的执行层；整合路线尝试掌握从用户意图到任务交付的完整链路。

企业微信：让自己成为不同Agent都能调用的执行层

企业微信开放CLI以后，用户不一定要在企业微信内部使用固定的AI助手。Codex、Kimi Work、DeepSeek Harness、MiniMax Code以及企业自研Agent，都有机会在获得授权后调用企业微信能力。

这条路线的战略价值在于，企业微信不需要准确押中哪一个Agent会成为最终入口。

Agent产品仍在快速变化，模型能力、交互方式和用户偏好都没有稳定。如果企业微信只支持自有Agent，它需要同时承担模型、Agent产品和办公平台三层竞争。向外部Agent开放以后，无论用户选择哪个任务入口，会议、消息、文档和待办仍可能通过企业微信完成。

这种位置与传统办公入口不同。用户可能减少直接打开企业微信页面的次数，但Agent对企业微信工具的调用可能增加。平台的价值不再完全由页面访问和功能点击体现，而是由它承载了多少组织数据、任务状态和执行结果决定。

企业微信拥有的人员关系、组织身份、消息记录和办公数据，不会因为接口开放而自动变成公共资源。外部Agent只能在企业授权范围内访问这些内容，任务结果也需要写回企业微信的文档、会议和待办系统。开放接口降低的是调用门槛，没有消除平台对身份、权限和业务状态的控制。

这条路线的风险也比较明确。Agent如果成为用户主要的办公入口，企业微信可能逐渐失去部分交互控制权。用户为什么发起任务、怎样描述需求、在不同方案之间如何选择，这些意图数据会更多地留在上层Agent中。上层Agent还能决定优先调用哪个办公平台，企业微信可能从用户直接感知的产品，退到不容易被看见的基础设施位置。

腾讯并没有只押注开放执行层。企业微信的新页面也把WorkBuddy列为支持的Agent工具，微信还在测试原生AI助手“小微”。更准确的理解是，腾讯在同时布局自有Agent和外部Agent生态：自有产品争夺用户入口，企业微信开放能力则保证腾讯的办公系统能够进入更多Agent的任务链路。关于“小微”的测试信息

字节：尝试掌握从用户意图到任务交付的完整链路

字节的路径更接近纵向整合。

飞书产品团队与豆包产品团队整合后，豆包获得了更直接的企业办公场景。飞书的市场、销售和客户服务团队进入火山引擎体系，则让模型服务、云基础设施、SaaS产品和企业交付进一步靠近。

在这套架构中，豆包负责接收用户意图、规划任务和组织模型能力；飞书提供企业知识、协作工具、人员关系与权限环境；Seed模型提供语言、推理、编程和多模态生成能力；火山引擎提供模型服务、Agent运行环境和企业商业交付。

纵向整合的优势是，字节可以围绕一条完整任务优化产品。豆包知道用户要完成什么，飞书知道用户所在的组织、能够访问的资料和可调用的工具，Seed模型负责理解与生成，火山引擎负责稳定运行和企业服务。产品团队可以减少跨公司接口适配，在任务状态、权限和成果交付之间建立更紧密的连接。

这条路线也有对应的成本。企业客户往往同时使用多种模型、办公软件和业务系统。如果豆包只能在飞书内部获得完整体验，或者飞书能力主要服务豆包，企业可能担心产品绑定和迁移成本。豆包企业版、飞书AI和飞书Aily之间也存在一定的能力重叠，组织整合能否转化为清晰的产品分工，目前仍需要观察。

字节同样不会采取完全封闭的策略。飞书已经提供API、集成平台、Aily和部分MCP能力，企业也需要接入自己的模型与业务系统。纵向整合更可能意味着豆包成为默认入口，并不等于排除所有外部Agent。

开放与整合背后，是办公平台的同一个矛盾

Agent成为上层入口后，办公平台会面对一个两难选择。

如果平台不开放，外部Agent难以调用它的功能和数据。用户可能转向接口更完整、执行更方便的替代系统，平台也可能被排除在新的任务链路之外。

如果平台全面开放，上层Agent就有机会接管用户交互和任务调度。办公平台仍然保存数据、提供工具，却可能失去用户为什么工作、如何决策以及下一步准备做什么的信息。

未来更可能出现混合路线：平台发展自己的默认Agent，争夺用户意图入口；平台也通过CLI、API或MCP等方式向外部Agent开放能力；核心数据、身份和权限继续由办公平台管理；企业按照任务和安全要求选择不同模型与Agent；高价值或高风险场景保留更严格的平台控制。

企业微信和字节目前的动作已经呈现出这种倾向。区别在于，企业微信现阶段更突出多Agent接入，字节更突出豆包与飞书的一体化体验。

平台争夺的四种控制权

模型能力仍然重要，但办公平台的竞争已经扩展到四个位置。

意图入口决定谁最早知道用户想完成什么。用户把任务交给豆包、WorkBuddy还是其他Agent，会影响后续工具选择和产品关系。

任务调度决定谁把目标拆成步骤、选择工具并安排执行顺序。Agent在响应请求的过程中，也会影响哪些平台获得调用机会。

执行系统决定谁保存消息、文档、人员关系、日程和业务状态。任务入口可以更换，但企业长期积累的组织数据与工作记录迁移成本更高。

治理体系决定谁提供身份认证、权限控制、操作审计、失败恢复和责任边界。企业愿不愿意把真实任务交给Agent，很大程度上取决于这一层，而不是模型能够生成多流畅的回答。

CLI和MCP等协议可能让工具连接逐渐标准化，但标准化不会自动消除平台壁垒。一个Agent即使能够调用大量工具，如果无法正确继承用户权限、记录操作过程、处理执行失败和恢复业务状态，仍然不能承担重要的企业任务。

企业微信的目标更接近：无论用户选择哪个Agent，真实工作仍然通过企业微信发生。字节更希望实现：用户把目标交给豆包，豆包利用飞书和火山引擎完成从理解、执行到交付的完整过程。

两条路线尚未证明哪一种更有效，但它们已经表明，未来办公平台争夺的不只是一个聊天入口，而是用户意图、任务调度、组织数据和可信执行能否被连接成同一条工作链路。

五、办公产品需要重新设计什么

传统办公产品围绕页面、功能和操作路径设计。产品经理会关注信息架构是否清楚、用户能否找到入口、表单是否容易填写，以及从一个页面进入另一个页面需要多少步骤。

当Agent开始承担任务规划和部分执行，设计对象会发生变化。用户可能不再依次进入文档、表格和日历页面，而是把一项跨越多个工具的工作交给Agent。产品需要同时管理页面流转、任务目标、执行计划、权限状态、中间成果、确认节点和失败恢复。

这意味着，办公产品的核心界面会从操作面板逐渐转向Agent控制台。

未来办公界面的核心职责，是让长任务可监督、关键动作可确认、执行失败可恢复。

任务入口需要把模糊要求变成可执行约定

自然语言降低了表达门槛，也带来了更大的不确定性。

用户说“整理一下最近的客户反馈”，其中可能缺少时间范围、客户类型、反馈渠道、分析维度和交付格式。Agent可以利用上下文推断部分信息，但不能把所有模糊之处都交给模型自行决定。

任务入口需要帮助用户补齐会改变结果的关键条件。产品可以展示Agent当前理解的目标、材料范围、交付结果和操作边界，让用户快速确认，而不是要求用户编写一份完整提示词。

一个有效的任务入口可以包含目标、范围、交付、约束、确认点与验收标准。这些信息不一定都通过表单收集。Agent可以先根据用户要求生成任务定义，再把真正存在歧义的部分交给用户确认。产品设计的重点是控制必要确认的数量，既不能让Agent带着错误理解持续执行，也不能把每个细节都变成新的填写负担。

长任务需要可见的计划、状态和中间成果

聊天产品通常把一轮回答作为基本交付。办公任务可能持续数分钟、数小时甚至更长，中间还会等待权限、资料或其他成员的反馈。

如果产品只显示“正在处理中”，用户无法判断Agent是在正常执行、等待外部系统，还是已经陷入无法恢复的循环。长任务需要清晰的状态模型。

用户至少要能查看执行计划、当前调用的工具、已获取资料、仍在生成的结果、待确认步骤、失败操作和剩余成本。

执行计划不必展示模型的完整推理过程。企业用户更需要的是与任务相关的行为解释，例如“正在读取经过授权的三份季度数据表”“发现两个指标口径不一致，等待确认”“会议邀请已生成但尚未发送”。

中间成果也需要独立保存。资料已经整理完成、分析仍在进行时，用户应该能够查看和使用已完成的部分。任务不能因为后续日程创建失败，就把前面已经完成的文档和图表一并判定为无效。

权限设计需要从“能不能访问”走向“可以代表谁做什么”

传统权限系统通常围绕页面、文件和角色设置。Agent会跨越多个工具连续执行，权限问题也变得更加复杂。

一个Agent可能能够读取文档，却没有创建会议的权限；能够代表用户生成邮件草稿，却不能直接发送；能够读取团队表格，却不能把数据传递到外部模型。

产品需要明确区分读取权限、生成权限、写入权限、发送权限、委托权限和数据流转权限。员工能够查看资料，不代表他可以把资料交给任何模型处理；员工能够执行某项操作，也不代表他有权把操作长期委托给Agent。

授权不应该只有“全部允许”和“全部拒绝”。企业可以按照任务、时间、数据范围和操作类型提供临时授权。例如，允许Agent在本次复盘任务中读取指定项目空间，但不允许访问其他项目；允许创建会议草稿，但发送邀请前必须确认。

确认机制需要根据风险分级

要求用户确认所有动作，会让委托式办公重新退化为逐步操作。完全不确认，又可能造成消息误发、数据覆盖和责任不清。

产品需要根据动作的影响范围、可逆性和外部性决定确认方式。低风险且容易撤销的动作可以自动执行，例如创建个人草稿、整理授权资料或生成内部分析。会影响其他成员但可以恢复的动作，可以先展示批量确认。对外发送、删除数据、提交审批和形成正式承诺等高风险动作，需要在执行前明确确认。

确认界面不能只显示“是否继续”。用户需要知道Agent准备做什么、依据是什么、会影响哪些对象，以及操作能否撤销。

如果用户频繁面对无法判断的确认请求，他可能为了推进任务而机械点击同意。确认次数很多并不代表产品安全，真正有效的确认需要让用户在承担责任的节点获得足够信息。

Agent生成的结论需要能够回到依据

传统办公产品通常把最终文件作为结果。Agent办公还需要保存结果与来源之间的关系。

一份分析报告中的数据来自哪张表，某个用户问题来自哪些反馈，某项建议是材料直接支持的结论还是模型推断，用户都应该能够检查。

来源追踪需要说明结论使用了哪些资料、材料是否属于有效版本、数据采用什么统计口径、模型对材料做了什么解释、用户修改过哪些内容，以及上游资料变化后哪些结果需要重新生成。

这项能力会影响Agent的纠错成本。如果用户发现某份资料已经过期，系统应该能够定位受影响的段落和图表，而不是要求用户重新执行整项任务。

这里所需的可解释性，是让用户能够核查业务依据、识别推断边界，并修正影响结果的输入，无需展示模型内部推理。

失败恢复比一次成功更接近真实办公

跨工具任务很难保证每一步都成功。网络中断、接口超时、权限变化、文档锁定、数据格式异常和外部成员未响应，都可能让任务停在中间。

如果Agent只能从头重试，已经完成的操作可能被重复执行。会议可能被创建两次，消息可能被重复发送，表格中的数据也可能被多次写入。

产品需要为长任务设置检查点，记录每一步的输入、输出和业务状态。执行失败后，系统应该判断哪些步骤可以重试，哪些步骤需要撤销，哪些步骤已经生效而不能重复。

失败恢复可以包含自动重试、更换经过授权的执行路径、回滚操作、保留部分成果、转交人工和终止任务。能够停止也是Agent能力的一部分。产品不能只追求Agent自主完成更多步骤，还要保证它在无法可靠继续时，不会扩大错误。

多人协作需要明确谁提出、谁确认、谁负责

企业任务很少只属于一个人。发起任务的员工不一定有权批准预算，生成材料的Agent也不能替负责人承诺交付时间。

Agent需要识别不同成员在任务中的角色：发起人定义任务目标，资料所有者决定是否开放数据，业务负责人确认关键判断，执行负责人接收待办，审批人批准高风险动作，管理员配置Agent可以使用的系统能力。

产品需要把这些角色放进任务状态中。当任务转交给其他成员确认时，对方应该看到必要上下文，而不是只收到一个孤立的“同意”按钮。确认完成后，Agent还需要知道新的决定改变了哪些后续步骤。

委托式办公需要让Agent进入现有组织关系，帮助多人围绕同一任务协作，不能停留在一个人与一个Agent的封闭对话中。

评估指标需要从使用次数转向任务结果

传统软件常用日活跃用户、页面访问、功能点击和使用时长衡量产品表现。这些指标在Agent办公中仍有价值，但可能产生误导。

如果Agent帮助用户减少页面切换和重复操作，点击量与使用时长下降可能是产品有效的结果。产品更需要关注任务是否完成、完成质量如何，以及用户为此付出了多少监督成本。

端到端任务完成率衡量Agent是否在遵守约束的情况下交付了全部结果。不能以Agent回复“已完成”作为判断依据，需要检查文档是否生成、数据是否正确写入、会议是否成功创建，以及需要确认的动作是否获得授权。

首次成功率衡量任务是否无需用户修改计划或重复执行就能达到要求。人工介入次数需要区分必要介入和无效介入。数据口径冲突时请求产品经理判断，属于合理介入；Agent反复询问已经提供的信息，属于产品问题。

接管率衡量用户是否中途放弃委托，转为自己操作。接管发生在哪一步，比一个总体比例更有诊断价值。失败恢复率衡量任务中断后能否保留成果、重试正确步骤或顺利转交人工。结果采用率则衡量Agent交付的文档、数据和待办是否被用户继续使用。

效率指标需要同时考虑人工耗时、任务总时长和模型工具成本。风险指标则需要记录越权请求、错误写入、错误发送、撤销操作和严重业务后果。平均完成率很高，也不能掩盖少量不可接受的高风险错误。

这些指标共同指向一个变化：AI产品经理设计的不再只是一个功能是否好用，而是一项工作能否在明确权限、可控成本和可恢复风险下完成。界面、权限、评测和异常处理需要围绕同一个任务结果建立起来，委托式办公才可能从演示能力进入稳定使用。

六、新办公模式已经出现，但还没有完成

企业微信开放CLI，说明办公系统开始为Agent提供结构化调用能力；飞书产品团队进入豆包体系，说明字节正在提高Agent在企业办公产品中的优先级。

这些变化可以支持“委托式办公正在形成”的判断，却不能证明这种模式已经成熟。

最有力量的反方观点是：企业软件开放API并不是新鲜事，企业也已经使用工作流、RPA和自动化平台多年。CLI和MCP只是降低了Agent调用工具的成本，组织合并也可能只是减少内部重复建设。只要Agent无法稳定理解任务、获得真实权限并对执行结果负责，大多数员工仍然需要回到原来的办公界面完成工作。

这个反方提醒我们区分三件事：平台已经开放什么能力，Agent技术上能够做什么，以及企业是否真的愿意把工作交出去。

能调用工具只是基础设施，可治理的执行过程建立信任，真实任务被持续委托才证明新模式成立。

能调用工具，不等于能够完成任务

Agent接入文档、表格、日程和会议工具，只证明它获得了执行某些动作的通道。

一次真实办公任务往往包含多个相互依赖的步骤。资料范围理解错误，会让后续分析失去基础；数据口径判断错误，会让报告结论偏离业务；参会人识别错误，会让会议安排失去意义。单个步骤看起来成功，组合起来的任务仍然可能失败。

长任务还会放大小错误。Agent在早期选择了一份过期文档，后续生成的分析、图表和汇报材料都可能受到影响。用户如果只在任务结束时看到结果，很难发现错误从哪里开始，也无法判断哪些内容需要重做。

新办公模式不能以“接入了多少工具”作为主要判断标准。更关键的问题是，Agent能否维护完整的任务状态，识别步骤之间的依赖，并在上游材料变化时更新受影响的结果。

企业工作不只是信息处理

许多办公任务可以拆成搜索、分析、生成和写入，但企业工作还包含判断、协商与责任。

产品经理决定某个用户问题是否进入版本计划，需要同时考虑反馈数量、公司战略、研发资源、客户关系和团队承诺。管理者决定预算、招聘和绩效，也不能只依靠文档与数据推导。

这些任务的难点不一定来自信息不足，而是不同目标之间存在冲突。Agent可以帮助整理材料、列出方案和暴露分歧，却不能自动获得组织授予的决策责任。

委托式办公不应以“Agent替代多少员工决策”为目标。更合理的方向是把可重复的信息处理和工具操作交给Agent，让人把时间放在需要业务判断、关系协调和责任承担的部分。

企业权限会限制Agent的执行范围

办公Agent需要访问比聊天助手更敏感的数据。企业消息、客户资料、财务表格、会议记录和人员信息，都可能受到严格权限约束。

员工有权查看一份文档，不一定意味着他可以把文档交给外部模型处理；员工能够创建会议，也不一定有权代表部门向外部人员发出邀请。Agent继承用户身份后，能否把读取权限自动转换成模型处理和工具执行权限，目前仍需要更细的规则。

企业还需要处理跨系统授权。一个任务可能同时调用协同办公平台、客户管理系统、数据平台和外部浏览器。不同系统的身份、权限和审计规则并不一致，Agent不能因为获得某个工具的连接，就默认获得完整业务权限。

权限问题如果没有解决，Agent只能停留在读取资料和生成草稿的辅助层。权限开放过快，又可能把一次模型误判放大成真实业务操作。

成本并不只有模型调用费用

Agent办公的成本包含模型推理、工具调用、任务运行时间、人工确认、错误纠正和安全治理。

一项原本需要员工十分钟完成的任务，如果Agent运行半小时，还需要用户多次确认并重新检查结果，节省的人工操作不一定能够抵消监督成本。

高质量模型可能提高成功率，也会带来更高的推理费用。企业需要判断哪些任务值得使用复杂模型，哪些步骤可以交给轻量模型、固定规则或传统工作流。Agent并不是每一步都需要自主推理。

产品不能只展示“节省了多少操作步骤”，还要计算任务总时间、人工介入时间、模型与工具成本、错误恢复成本，以及结果是否真正被采用。

委托式办公会从边界清楚的任务开始

适合较早交给Agent的工作通常具备几个条件：输入范围相对明确，结果可以检查，错误可以撤销，所需权限有限，对外部对象的影响可控。

这类任务包括在指定资料范围内搜索和整理信息，对格式明确的数据进行清洗、汇总和可视化，根据经过确认的材料生成文档、表格和汇报草稿，查询成员空闲时间并提出会议建议，从会议纪要中提取待办草稿，跟踪已经明确的任务状态，以及在人工确认后完成内部低风险写入。

这些任务不一定简单，但它们的成功标准可以被定义。Agent做错以后，用户也有机会发现并修正。

需要谨慎委托的任务具有另一组特征：结果难以验证、动作不可撤销、影响范围较大，或者责任无法交给系统承担。

招聘与绩效决定、预算审批、合同承诺、法律和财务判断、对外公开沟通、数据删除及关键生产系统变更，都不适合仅凭模型输出自动执行。Agent可以准备材料和提出建议，正式决定仍需要由具备相应职责的人完成。

任务边界也会随产品成熟度变化。某项能力在测试阶段只能生成建议，经过长期验证并建立权限与恢复机制后，才可能进入有限自动执行。产品需要按照真实风险逐步提高自主程度，而不是用统一的“自动模式”覆盖所有任务。

判断新模式是否成立，需要观察几类信号

平台开放接口和发布Agent功能，只能证明厂商正在建设基础设施。委托式办公能否进入稳定使用，还需要更多结果信号。

产品能力方面，需要观察Agent是否从读取和生成，继续进入真实写入和多步骤执行。它能否跨文档、表格、会议、日程和业务系统完成一项任务，能否保留中间状态，以及失败后能否继续、撤销或转交人工，会比工具数量更有解释力。

用户行为方面，需要观察员工是否重复委托真实工作，而不是只体验一次演示。用户是否逐渐减少逐步指导，是否愿意让Agent持续运行长任务，以及交付成果是否被继续使用，能够说明信任是否真正形成。

企业治理方面，需要观察平台是否提供细粒度授权、临时权限、操作记录、成本控制、暂停机制和风险分级。企业愿意开放读取权限，不代表愿意开放写入和对外发送权限。权限从试用环境进入生产环境，才是Agent开始承担真实工作的信号。

结果与经济性方面，需要比较Agent任务与原有人工流程的完成率、总耗时、人工介入、结果采用和综合成本。如果效率提升依赖员工重新检查所有内容，委托的价值仍然有限。

商业层面可以观察企业是否开始为任务执行能力持续付费，而不只是购买AI功能或模型额度。Agent是否进入企业正式采购、管理制度和业务流程，能够反映它是否从个人工具变成组织能力。

企业微信CLI与飞书进入豆包体系，更像是委托式办公基础设施开始成形的信号。它们让Agent逐渐获得企业上下文和工具调用能力。新模式是否成立，需要以员工是否愿意把真实工作交出去作为验证，而不能只看用户能否用一句话触发任务。

当Agent能够说明自己读取了什么、执行了什么、哪里失败以及怎样恢复；当企业能够限制它的权限、审计它的操作并为错误设置人工接管；当用户不必重新完成一遍任务就能采用结果，委托式办公才真正从产品设想进入日常工作。

本文由 @Jaimo. 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议