本文核心判断：2026 年企业 Agent 的主矛盾，已经从「能不能干活」变成「代办权落在谁手里、出事谁负责」；产品经理必须把读、写、执行拆开划线，而不是继续堆能力。
同一周里，两扇门朝相反方向转动。
一扇门开着：员工用企业微信账号登录 WorkBuddy，Agent 可以连上消息、文档、会议，把任务拆开往下做，直到交出一版可用的成果。管理后台里还能配权限、控用量、查日志——听起来像「终于能在公司里正经干活了」。
另一扇门关着：摩根大通的 Jamie Dimon 公开说，不会让外部 AI agent 进到客户账户里代操作，因为「你不想要 rogue agents」；嘉信理财的 Rick Wurster 也在拦未授权 Agent（包括 Meta Muse）试图代客户动手，理由更直白——密码交给别人代操作，出事了责任说不清。
一边是办公协作里 Agent 正在拿到「读写上下文」的钥匙，一边是金融账户门口贴着「凭证代登，禁止通行」。产品经理如果还在用「Agent 能帮你自动完成」这句话讲故事，就会在这两扇门之间撞墙：客户要的是代办，组织怕的是越权，监管和法务要的是追责链。
真正该问的不是「要不要上 Agent」，而是——代办权开到哪一层，责任边界画在哪里。
01 发生了什么：企微里进门干活，银行门口被拦住
先把能核对的事实摆清楚。这一节不讲愿景，只讲公开材料里已经写明的事。
1.1 腾讯 WorkBuddy × 企业微信：Agent 开始连办公上下文
企业微信帮助中心写得很明确：企业微信与 WorkBuddy 联合打造面向企业员工的 AI 办公工作台；可用企业微信账号登录 WorkBuddy，连接办公中产生的消息、文档、会议等数据，自动拆解用户任务并逐步执行，直到交付完整成果。成员可在企微桌面端侧边栏「智能机器人」领取试用，也可向管理员申请；管理员购买并分配席位后使用。
管理侧入口同样公开：企业微信管理后台 → 智能专区 → 智能机器人 → 机器人管理 → WorkBuddy。管理员可购买与分配席位、配置可使用应用权限、查看使用情况与用量上限，并前往 WorkBuddy 管理后台配置智能体、模型与技能、安全风控，以及检索操作日志、对话日志。
计费方面，帮助中心刊例价写的是 198 元/人/月（起购 1 人；时长可选 1–11 月或 1–3 年等）。另有加量包 Credits 档位说明。腾讯云产品页对 WorkBuddy Enterprise 旗舰版亦标出同样刊例价，并强调统一身份、企业级安全治理与审计等能力。
来源：企业微信帮助中心 · 购买&计费说明；腾讯云 · WorkBuddy Enterprise 产品页
对产品经理来说，这里的信号不是「又多了一个聊天机器人」，而是：Agent 正在被装进企业已有的身份体系和工作台，消息、文档、会议不再只是人看的材料，而可能成为 Agent 可连接的上下文。权限、用量、日志被放进管理后台，说明厂商也默认——这东西必须能被管。
1.2 OpenAI ChatGPT：多智能体并行，进度可跟、结果可点开
OpenAI 官方 ChatGPT release notes 写明：GPT-6 Pro 在 Chat 页支持 多个 agent 并行处理同一任务的不同部分；用户可在对话中跟踪进度，并打开已完成任务查看各 agent 做了什么。该更新面向符合条件的 Pro 用户推出；托管工作区是否可用取决于工作区设置与放量资格。
来源：OpenAI Help Center · ChatGPT release notes
这意味着消费级与专业用户侧的交互预期正在变：不再是「问一句、答一段」，而是「派一组子任务、盯进度、验收分件结果」。当这种交互习惯渗进企业采购与员工自用时，IT 和产品会同时面对一个问题——并行代办之后，谁批准了哪一步？
1.3 银行关闸：JPMorgan 与 Charles Schwab 的公开立场
据 CNBC 报道（2026 年 10 月 13 日），摩根大通 CEO Jamie Dimon 在三季报电话会上表示，不会允许任意外部 agent 进入公司体系代客户操作，因为对客户和银行都太冒险；并提到「你不想要 rogue agents，而且可能有成千上万个」。发言人向 CNBC 确认：银行目前阻止外部 AI agent 代表零售客户操作；检测到第三方用客户银行凭证登录代操作会拦截；同时支持通过 open banking 等安全、客户授权的数据共享，并称致力于以安全方式启用 agentic connections。报道进一步解释：这意味着 Agent 或可通过 Plaid 等连接器以只读方式获取部分数据（如余额），但不能转账或付账单——而后者恰恰是「代办」最有用的部分。Dimon 还提醒：若用户使用外部 Agent，应理解风险与「责任转移」（liability transfer）。
来源：CNBC · JPMorgan blocks outside AI agents；Fortune · Jamie Dimon bars outside AI agents
据 Moneycontrol 转述 Bloomberg（2026 年 10 月 16 日），嘉信理财 CEO Rick Wurster 表示，公司正在拦截未授权 AI agent（含 Meta Muse）试图代客户操作；不愿客户把密码交给 Muse 代操作——「我们控制不了，客户也控制不了，出了问题谁负责？」他希望客户使用自家助手 Charley；并将通过 MCP server 等可控通道，让外部大模型做余额查看与研究，但不允许挪动资金。Wurster 还提到，每周拦截次数以「几十次」计，说明用户爱 AI，但还不愿意把金融账户轻易交给外部 Agent。
来源：Moneycontrol · Charles Schwab blocks unauthorised AI agents
把三条线并在一起看：办公侧在开「连接上下文」；对话侧在推「多智能体并行」；金融侧在关「凭证代登 + 资金动作」。冲突不是媒体标题制造出来的，而是产品能力走到了责任边界上。
1.4 对照：微软叙事里的「控制平面」提醒
有用的不是品牌名，而是同一判断：Agent 一旦能跨系统行动，就必须被当成可编目、可授权、可观测、可追责的数字角色，而不是聊天窗口里的彩蛋。
02 真正的矛盾：不是「要不要 Agent」，而是「代办权」与「责任边界」
很多团队还在争论要不要上 Agent。银行和办公厂商已经用产品动作回答了另一半问题：上可以，但代谁办、办到哪一步、出事谁背，必须先写清楚。
2.1 「代办」三个字，拆开看是三种完全不同的风险
把 Agent 能做的事粗分为三档，产品讨论会立刻冷静下来。
读（Read） ：查消息摘要、拉文档目录、看会议纪要、看账户余额、检索知识库。风险主要在隐私与越权可见；但通常不改变业务状态。银行公开立场里，通过 open banking / MCP 一类可控通道做只读共享，仍被讨论为可接受路径。
写（Write） ：改文档草稿、填工单字段、生成并保存会议纪要、给群里发一条建议回复。会改变信息状态，但多数还可回滚、可覆盖；责任往往落在「谁点了发送 / 谁点了保存」。
执行（Execute） ：转账、付账单、改权限、发正式对外通知、触发采购下单、用客户银行凭证代登操作。状态改变且难逆，或直接涉及资金与合规。JPMorgan / Schwab 的关闸，卡的正是这一档——尤其是「拿用户密码代登」这一条。
产品经理最常见的错误，是把三档揉成一句「Agent 自动帮你搞定」。演示很好看，上线后第一周就会卡在法务、风控或一线主管那句：「错了谁签字？」
2.2 责任边界为什么比模型能力更先爆
Wurster 的原意很朴素：客户把密码交给 Muse，银行控制不了，客户也控制不了，出事责任不清。Dimon 则点出 liability transfer——用户若坚持用外部 Agent，要明白责任可能发生转移。
翻译成产品语言：
- 身份是谁的？ Agent 是用员工个人授权、企业应用授权，还是偷偷复用用户密码？
- 动作是否可逆？ 读余额和挪资金，不是同一级产品决策。
- 日志能否还原「谁授意、谁执行」？ 没有日志，就没有复盘，也没有保险与合规口径。
- 人工确认卡在哪一步？ 没有人机交接，就没有「最后一公里责任人」。
所以矛盾不是「银行守旧、科技公司激进」。矛盾是：代办越接近资金与不可逆动作，组织就越要求可控通道；代办越停留在读与草稿，组织就越愿意为效率松口。
2.3 企业里会出现一种新的 Shadow IT：自带密码的 Agent
参考文提醒过：没有治理的 Agent，就是 AI 时代的 Shadow IT。2026 年的变体更危险一点——员工可能不只是私接一个聊天插件，而是把邮箱、网盘、甚至银行凭证交给外部 Agent「代我登录」。
办公侧（如企微 × WorkBuddy）走的是企业账号登录、后台配权限、查日志的路径，本质上是在把 Agent 收编进组织身份。银行侧拦的是「第三方拿凭证代登」，本质上是拒绝把账户操作权交给不可控主体。
产品经理若只盯「功能清单」，会漏掉真正的战场：身份与授权模型。谁登录、代表谁、能做什么、日志落在哪——这四件事没定，后面所有「多智能体并行」都只是把风险并行放大。
03 产品该怎么重新划线：读 / 写 / 执行三级，外加权限矩阵与人机交接
这一节给可落地的划线方法。目标不是做出更会说话的 Agent，而是让业务、安全、法务能在同一张表上签字。
3.1 先定任务类型，再谈模型与编排
沿用「查询 / 判断 / 执行 / 协同」的任务拆法（见参考文对客服工单 Agent 的拆解），把它映射到读 / 写 / 执行：
| 任务类型 | 典型动作 | 默认级别 | 建议策略 |
|---|---|---|---|
| 查询型 | 查制度、查文档、查余额、搜历史会议 | 读 | 可自动；需数据范围与脱敏 |
| 判断型 | 根据账号状态判断登录失败原因；根据会议纪要标风险项 | 读 + 有限写（草稿） | 可自动出结论；结论进正式系统前需人确认 |
| 执行型 | 改权限、发对外邮件、转账、创建正式合同 | 执行 | 默认禁止自动；强确认 / 双人复核 / 审批流 |
| 协同型 | 跨部门分派、汇总多方意见 | 写为主 | Agent 整理与建议；分派与承诺由人点头 |
划线原则只有一句：先假设 Agent 会错，再决定它能不能动手。
3.2 权限矩阵：按「数据域 × 动作级 × 角色」三维裁
不要只问「开不开 WorkBuddy」。要问开给谁、开到哪一类应用权限、用量与日志谁看。企微帮助中心已写明管理员可配置应用权限、成员用量、操作与对话日志——产品设计应把这些能力用满，而不是默认全开。
一张可用的权限矩阵示例（可按公司改名，但列不能少）：
| 数据域 | 读 | 写（草稿） | 写（正式） | 执行（资金/权限/对外承诺） | 适用角色示例 |
|---|---|---|---|---|---|
| 个人待办 / 自己的日程 | 开 | 开 | 人确认后开 | 关 | 普通员工 |
| 团队群消息摘要 | 开（本群） | 草稿回复 | 本人点发送 | 关 | 项目成员 |
| 部门知识库 | 开 | 开（个人空间） | 知识管理员确认 | 关 | 部门员工 |
| 客户合同 / 报价 | 白名单 | 草稿 | 销售负责人确认 | 关 | 销售 + 法务白名单 |
| 财务付款 / 银行类账户 | 经官方连接的只读（若有） | 关 | 关 | 仅官方渠道 + 人工审批 | 财务；禁止凭证代登 |
| 账号权限变更 | 开（审计视图） | 关 | 关 | 审批流 | IT / 安全 |
三条硬规矩建议写进产品需求，而不是写进培训 PPT：
- 最小权限默认：新 Agent、新连接器上线时，默认只有「读」；「写」和「执行」单独申请。
- 正式写 ≠ 草稿写：生成纪要可以自动；同步进正式 Wiki / 对外发出，必须人点一下。
- 禁止密码代登作为产品路径：任何「请用户把账号密码交给 Agent 去登录第三方」的设计，都应视为高危，优先改为 OAuth / 企业应用授权 / 官方 MCP 或 open banking 类通道。
3.3 人机交接：把「确认点」设计成产品，而不是事后补丁
生产可用的 Agent，不是去掉人，而是让人只出现在该负责的地方。建议每个高价值流程至少标出三个交接桩：
- 意图确认：Agent 复述「我将读取 A、生成 B，不会执行 C」，用户点「按此执行」。
- 高风险确认：涉及对外发送、权限变更、资金相关时，二次确认并展示将要调用的工具与目标对象。
- 异常接管：工具失败、置信度低、命中敏感策略时，强制转人工，并带上已收集的上下文，而不是让用户从头再讲一遍。
OpenAI 在 release notes 里强调多智能体并行时可跟踪进度、打开已完成任务查看——对企业产品是个好暗示：并行可以，但每个子任务的验收入口要在界面上可见。 否则「五个 Agent 一起干」会变成「五个黑箱一起错」。
3.4 日志与追责：没有还原链，就没有规模化
至少落这六类字段（名称可变，语义不能少）：
- 触发人与触发入口（企微机器人 / 独立客户端 / API）
- 授权范围快照（当时开了哪些应用权限）
- 检索与工具调用列表（读了哪些文档/消息，调用了哪些连接器）
- 模型输出与是否被人工修改
- 确认人、确认时间、确认动作
- 最终业务结果（是否真正写入系统 / 是否发送 / 是否被回滚）
WorkBuddy 管理侧已提供操作日志、对话日志检索入口——产品经理要做的是：定义「出事后 30 分钟内能回答的问题清单」，倒逼日志字段齐套。例如：
- 这条对外邮件是谁授意、哪个 Agent 起草、谁点的发送？
- 客户余额是通过哪条官方连接读到的，还是异常登录？
- 并行子 Agent 里，是哪一个改写了数字？
答不上来，就不要把该场景从试点扩到全员。
3.5 和「控制平面」对齐的四层治理（给内部评审用）
可直接借用参考文的四层结构，改成你下周评审会上的检查表：
- 目录层：每个 Agent / 每个技能有 owner、场景、数据源、开放范围、试点或正式状态。
- 权限层：读 / 写 / 执行分级；高风险必须人确认；可暂停、可回收。
- 观测层：不只看 DAU，看任务完成率、人工接管率、平均节省时长、错误与回滚次数。
- 风险层：敏感策略、异常告警、审计日志、事故演练。
筛选标准也可以写死在需求里：没有 owner 的不上线；没有边界的不放权；没有指标的不扩容；没有审计的不接核心流程。
04 国内落地对照：企微工作台里该先开什么、先停什么
国内大量团队的真实入口是企业微信工作台，而不是再装一个「未来办公操作系统」。结合已核实的 WorkBuddy × 企微能力，给出一版「先开 / 后开 / 先停」建议。这是产品策略，不是厂商承诺。
4.1 建议先开：高频、可逆、边界清楚
优先放行这些场景（默认停在「读 + 草稿写」）：
- 会前会后：根据会议主题拉相关文档与历史纪要；会后生成待办草稿，由主持人确认后写入待办。
- 周报与材料初稿：从本人有权访问的消息 / 文档中归纳进展，输出可编辑草稿，不自动群发。
- 制度与知识问答：连企业内部已授权知识源，回答「怎么走流程」，并附来源链接；不自动替人提交审批。
- 研发 / 方案辅助：技术方案、研究报告、海报网页等「产出物」类任务——帮助中心亦将其列为专业任务方向——适合作为效率试点，但仍需人工把关后对外。
这些场景的共同特点：错了可以改，责任人清晰（起草人 / 主持人），不碰资金与正式权限变更。
4.2 建议后开：看起来省事、实际跨系统
下列场景等权限矩阵和日志跑稳再开：
- 自动回复客户群 / 对外邮件：一旦发出，就是公司态度。
- 跨部门资料汇总后直接写入正式知识库：涉及信息权威性与泄密面。
- 批量改文档权限、拉人进群、改日程组织者：属于执行级协作动作。
- 连接财务、人事核心系统做变更：即使模型很稳，审批流也不能省。
4.3 建议明确停用或禁止作为产品路径
- 任何要求员工把个人银行 / 券商密码交给 Agent 代登的用法——对照 JPMorgan / Schwab 的公开立场，这不是「国外特例」，而是责任结构问题；国内产品同样经不起「出事谁负责」。
- 未登记的外部 Agent 私接企业数据：Shadow IT；应用商店 / 机器人管理里看不到的，就当它不存在于合规体系。
- 全员默认开齐所有应用权限：刊例价再便宜，也不该用「先全开再收」的方式赌运气；应先小范围席位 + 窄权限。
- 无用量上限、无日志查阅习惯的「先飞起来」：管理后台已提供用量与日志，不用等于裸奔。
4.4 试点路径：三周看信号，而不是一季看愿景
可复用参考文「先辅助、再低风险工具、再带确认的执行」三段式，缩成国内企微场景：
第 1 周：只读 + 草稿。 10–30 个席位；只开消息 / 文档 / 会议中的只读类权限；产出全部进个人草稿。指标：周活跃、草稿采纳率、人工修改比例。
第 2 周：低风险写入。 允许写入个人待办、个人文档；群消息回复保持「生成但不发送」。指标：接管率、错误报告数、平均节省分钟数（用一线问卷，别只看点击）。
第 3 周：带确认的窄域执行。 选一个流程，例如「会议待办写入项目群待办」或「周报发送前确认」。必须有确认 UI、日志字段、回滚说明。指标：确认通过率、误发 / 误写事故（目标为 0）、复盘是否能在 30 分钟内还原链路。
过不了第 3 周的，不要用「再换个更强模型」逃避——问题多半在边界，不在智商。
05 给产品经理的 30 天行动清单
以下清单按周拆，尽量做到「下周就能开干」。角色按产品经理牵头，安全 / IT / 业务负责人会签。
第 1–7 天：盘点与划线
- 列出公司里正在用的所有 Agent / 机器人 / 插件（含员工自采），填 owner、场景、数据源、是否进生产。
- 画一张读 / 写 / 执行对照表，把现有场景逐条贴进去；标红所有「执行」且无人确认的点。
- 明确一条公司级禁令草案：禁止以产品路径支持「把银行或其他高敏感账户密码交给第三方 Agent 代登」；只读类接入必须走官方或已审批连接器。
- 若已采购或试用企微 × WorkBuddy：在管理后台核对席位分配、已授权应用权限、用量上限，截图归档；确认谁能查操作日志与对话日志。
- 找法务 / 安全要一句书面口径：Agent 辅助产出的对外内容，签字责任人是谁。
第 8–14 天：矩阵与试点设计
- 完成权限矩阵 v1（数据域 × 动作 × 角色），评审会上只讨论「哪里必须人点头」。
- 选定 1 个试点场景（建议会务纪要 → 待办草稿，或制度问答），写清触发入口、交付物、失败兜底。
- 为试点写「确认点」交互：意图确认 + 高风险确认 + 异常接管。
- 定义日志最小字段集，并让技术确认现网能否查出这六类信息。
- 定 3 个北极星以外的过程指标：草稿采纳率、人工接管率、可还原事故数（应为 0）。
第 15–21 天：小范围上线
- 开通有限席位（宁少勿滥）；默认权限仅读 + 草稿写。
- 做一次桌面推演：假设 Agent 把错误数字写进周报并群发，复盘链路能否定位到人与步骤。
- 同步业务负责人：并行子任务（若产品支持）必须在界面可点开验收，禁止「黑箱并行」。
- 收集一线原话，改提示词与权限，不急着加连接器。
- 输出一页纸《Agent 代办边界说明》给全员，避免「听说能自动转账」类谣言。
第 22–30 天：决策扩容还是收缩
- 召开扩容评审：没有 owner、没有边界、没有指标、没有审计的，一律不扩。
- 对标银行公开逻辑做一次红队提问：若员工用外部 Agent 带公司凭证登录关键系统，我们能否检测、拦截、告警？
- 把「官方只读通道 vs 凭证代登」写进供应商评估表；采购外部 Agent 时列为否决项。
- 若参考微软 control plane 思路做内部路线图，只取治理能力清单（台账、权限、观测、安全），不抄无法核对的发布细节。
- 形成 90 天路线：哪些场景保持辅助，哪些场景进入「确认后执行」，哪些场景明确永不自动。
06 结语：下一阶段拉开差距的，不是谁先会代办，而是谁先敢把代办停在该停的地方
企微侧把门推开，是因为办公上下文里的「读」和「草稿写」能明显省时间，而且可用企业身份、权限和日志把 Agent 收编进组织。银行侧把门关上，是因为账户上的「执行」一旦失控，客户与机构都担不起「rogue agents」和说不清的责任链。
两边并不矛盾。它们在提醒同一件事：
Agent 的产品竞争力，正在从「多会做一件事」转向「多敢拒绝一件不该自动做的事，并且拒绝得有产品依据」。
对产品经理，2026 年最值钱的交付，未必是又一个炫技 Demo，而是三样很「土」的东西：一张读 / 写 / 执行权限矩阵、一套人机确认交互、一条出事能还原的日志链。微软叙事里的控制平面、企微后台里的权限与日志、OpenAI 对话里可点开的并行任务、银行门口对凭证代登的拦截——指向的都是治理，而不是口号。
一句话收束：先把代办权划清楚，再谈 Agent 进企业；先把责任边界写进产品，再谈规模化。
