当 Agent 被强行变成入口，会带来哪些改变

先看几条信息：

• • 上周，易观发布桌面办公 Agent 报告，WorkBuddy 月活以 2097 万绝对领先，这疯狂的增长来自于铺满北上广深地铁的“我帮你”

• • 上周，阿里把 Qoder Work、MuleRun 和悟空整合成“千问办公”，划到钉钉团队；

• • 本周，字节把飞书整合进了豆包，飞书负责人向豆包负责人汇报；

WorkBuddy 疯狂的增长验证了这事儿可行，然后字节和阿里立刻调整状态跟进。

不出意外的话，接下来几个月，这场“办公 Agent 三国杀”大概率会打得很热闹。

“新建”入口意味着什么？

不管最后谁占上风，三家在一件事上的方向肯定是一致的：把 Agent 做成新的办公入口。

产品经理们可能要遭罪了。

不要小看这个入口的改变，Agent 是一个非常恐怖奇葩的存在。

“用 Agent 赋能”和“用 AI 赋能”是完全不同的两回事。

过去讲 AI 赋能，赋能的主体是产品，然后间接去赋能用户。

产品经理负责把 AI 能力塞进原来的产品流程里，让搜索更智能、写作更方便、数据分析更快……

AI 是产品拥有的一件新工具，最后还是用户来使用这个产品。

• • 产品是主体。

• • AI 是产品的工具。

• • 产品经理考虑的是怎么把 AI 塞进产品，让产品对用户更友好。

Agent 赋能则完全不是一回事。

Agent 自己有自主决策能力，也会调用工具、拆解任务和连续执行。用户把目标交给 Agent，Agent 再决定该使用哪些产品。

赋能的主体是用户，Agent 作为用户的“代理”，产品反倒成了 Agent 完成任务时调用的工具。

• • 用户是主体。

• • Agent 代表用户理解目标、组织任务。

• • 产品成为 Agent 可以调用和操作的工具。

• • 产品经理要做的，是给 Agent 开绿灯，让自己的产品更容易被它理解和使用。

说白了，那些做 Agent 的产品经理，抢了普通产品经理的主导权，让大家“沦为二等公民”没机会直接用自己的作品去“赋能用户”了。

Anyway，这才是办公 Agent 成为入口之后产品经理们应该关注的：过去是把 AI 接入产品，将来则要让产品接入 Agent。

至少在办公场景里，产品都得开始考虑怎么对 Agent 更友好：

• • 能不能被 Agent 找到和理解？

• • 有没有稳定的 API、CLI、MCP Server 或 Skill？

• • Agent 能不能读取产品里的信息？

• • 能不能代替用户执行大部分操作？

• • 权限、确认、日志和出错恢复怎么处理？

如果三大厂真的把 Agent 做成了办公入口，其他产品也不得不跟着改。

因为新入口之后用户可能不再频繁打开你的产品，而是让 Agent 代替自己使用它。

从这个角度看，飞书被整合进豆包也许就是一个挺有意思的信号：产品正在成为 Agent 能力的一部分。

既然统一入口已经交给了 Agent，各个产品再分别折腾一套自己的“AI 赋能”，多少会显得重复，甚至可能互相打架。

“Agent 吞噬一切”听起来有点夸张，不过产品逐渐从“给人操作”变成“也给 Agent 操作”，甚至主要被 Agent 操作，这件事已经挺具体了。

基于这套论述，我整理了 10 个可能在 2027 年之前就会到来的变化，请各位产品经理品鉴。

1.新的要伺候的对象

过去产品经理主要研究人：用户有什么目标、怎么理解页面、愿意点几步、在哪里会放弃。

Agent 成为入口后，产品可能同时服务两类用户：

• • 人类用户：提出目标，确认关键决策，处理例外。

• • Agent 用户：理解产品能力，选择工具，传递参数，执行操作，读取结果。

这会产生一些以前不太重要的问题：

• • Agent 能不能理解这个产品是干什么的？

• • 它怎么判断什么时候该调用这个产品？

• • 相似工具很多时，为什么选你？

• • 调用失败后，能不能知道错在哪里、下一步怎么办？

• • 执行结果能否以结构化方式返回，而不是丢给它一张页面截图？

“用户体验”可能要分成两部分：给人看的交互体验，以及给 Agent 用的调用体验。

two-users

2.产品界面不再是唯一产品主体

很多产品经理做产品/功能习惯从页面出发：信息架构、功能入口、操作路径、交互细节。

如果大量操作由 Agent 完成，页面的重要性不会消失，但它承担的任务可能会变化：

• • 高频、标准化操作交给 Agent。

• • 页面更多用于查看状态、处理异常和确认高风险操作。

• • 复杂配置可能由 Agent 通过对话收集，再转换成结构化参数。

• • 用户未必需要知道某个功能藏在哪一级菜单里。

• • 一部分过去必须设计成页面的能力，可能只需要成为 API、MCP Tool、CLI 或 Skill。

新的影响：以后定义一个功能，除了画页面，还要考虑它能不能被抽象成 Agent 可调用的能力。

interface-becomes-console

3.PRD 要加 Agent 故事？

以前写功能需求，通常会描述用户故事、业务流程、页面状态、数据和异常情况。Agent 参与后，可能还得补充：

• • 这个能力的调用条件是什么？

• • 输入参数怎样定义，哪些必填，哪些可以推断？

• • 输出结果怎样表达，Agent 才能继续完成后续任务？

• • 哪些信息需要放进上下文？

• • 哪一步允许自动执行，哪一步必须询问用户？

• • Agent 调错工具、填错参数、重复执行时怎么办？

• • 操作能不能撤销、回滚和追溯？

• • 同一个任务执行到一半中断，之后能不能恢复？

过去很多隐藏在人脑里的业务常识，也得被整理出来。因为 Agent 不一定知道“公司里一般都是这么处理的”。

agent-story-prd

4.产品功能得拆一拆

给人使用的产品，常常按照页面和业务模块组织功能；给 Agent 使用时，能力可能要拆得更原子化。

比如“帮我完成一次报销”背后可能包含：

• • 识别票据

• • 查询费用标准

• • 匹配费用类型

• • 填写报销单

• • 找到对应项目

• • 检查字段

• • 提交审批

• • 查询审批状态

产品经理需要判断哪些能力做成 Tool，哪些组合成 Skill，哪些仍由 Workflow 固定编排。

拆得太粗，Agent 很难灵活使用；拆得太细，调用链会很长，出错概率和 Token 成本也会上升。这里可能会逐渐形成一套新的“功能颗粒度”方法。

atomic-capabilities

5.“AEO”

过去的分发入口是应用商店、搜索、广告、销售和渠道。Agent 如果占据入口，可能再多一层：Agent 在执行任务时愿不愿意选择你的产品。

影响选择的因素可能包括：

• • 能力描述是否清楚

• • 接口是否稳定

• • 调用成本是否合理

• • 返回结果是否结构化

• • 成功率和执行速度

• • 权限申请是否顺畅

• • 有没有适合常见任务的 Skill

• • 出错后能不能自我修复

• • Agent 是否能验证任务真的完成了

这有点像过去做 SEO、应用商店优化，只是优化对象变成了模型和 Agent 的工具选择机制。以后可能会出现某种“Agent 渠道运营”，但具体会长什么样，现在还不好说。但肯定是产品经理的活。

aeo-tool-selection

6.考核 KPI 要变

只看 DAU、页面访问量、点击率，可能会越来越奇怪。

如果 Agent 替用户完成了大量操作，一个成功任务可能只产生一次调用，甚至没有传统意义上的页面访问。

产品团队可能更应该关心：

• • Agent 调用次数

• • 任务完成率

• • 首次执行成功率

• • 平均调用轮数

• • 人工接管率

• • 用户确认次数

• • 错误恢复率

• • 单次任务成本

• • 被不同 Agent 选择的比例

• • 从调用到最终业务结果的转化率

这里还有一个挺麻烦的问题：Agent 调用了工具，不代表用户的目标真的完成了。比如“邮件发送成功”和“客户接受报价”之间还隔着很远。PM 需要区分工具执行成功、任务完成和业务结果达成。

agent-kpi

7.权限和风控得更严格了

“不怕流氓有文化，就怕文化人耍流氓。”

Agent 能力越强，误操作(故意搞破坏)的危害和可能性越高。

一个只能生成文字的 AI，出错后最多是内容不靠谱；一个可以操作电脑、删除文件、提交审批、发送消息的 Agent，错误会直接进入真实业务。

过去我们几乎不用考虑产品被逆向的问题，但是当 Agent 来使用我们产品的时候，它会并且有能力为了完成任务干出任何事。

所以产品经理可能得更频繁地处理这些设计：

• • 哪些操作默认允许？

• • 哪些操作需要二次确认？

• • 确认时要向用户展示多少信息？

• • 能否限定 Agent 的可操作范围和有效时间？

• • 如何防止重复提交？

• • 如何记录每一步操作？

• • 出错后由谁负责？

• • 用户能否一键停止、撤销或接管？

• • 敏感操作如何设置提示词拦截？

8.隐形规则需要显化

很多业务产品能运行，依赖的是员工经验。

例如：

• • 某类客户要优先处理

• • 超过某个金额要先找领导沟通

• • 某些字段虽然非必填，但实际必须填

• • 特殊日期不能执行某种操作

• • 系统提示成功后还要去另一个页面检查

人用了几年，自然知道这些细节；Agent 不知道。它只会根据获得的上下文和工具反馈行动。

因此，PM 可能需要把业务经验整理成：

• • 规则

• • SOP

• • 权限条件

• • Tool 描述

• • Skill

• • 校验逻辑

• • 异常处理策略

这部分工作过去常散落在培训材料、客服话术和老员工脑子里。Agent 真要干活，就得把它们重新翻出来显化放在每一个 Agent 需要决策的节点。

make-hidden-rules-visible

9.用研也得更新了

以后研究 Agent 产品，光访谈用户可能不够，还需要观察 Agent 的执行过程。

比如：

• • 它为什么选择了这个工具？

• • 哪条描述让它误解了功能？

• • 上下文在哪一步丢失了？

• • 为什么连续重复同一个错误？

• • 用户在哪些节点倾向于接管？

• • 哪些确认弹窗让用户觉得比自己操作还麻烦？

可能需要把模型的调用记录、工具参数、上下文和用户接管行为放在一起分析。

某种程度上，PM 除了研究用户行为，还得研究一种概率化、会波动、偶尔不讲道理的“新用户行为”。

research-agent-behavior

10.产研协作边界移动

Agent 产品里，一些原本偏技术的概念会进入日常产品讨论：

• • Tool Use

• • Function Calling

• • MCP

• • Skills

• • 上下文窗口

• • KV Cash

• • 模态、tokens/s

• • 沙箱、容器、Harness、HOOKS

• • 调用日志

• • Eval 与成功率测试

PM 未必需要亲自实现底层，但如果不了解这些东西，很难判断一个方案为什么能做、为什么不稳定，以及应该在哪个环节增加约束。

同时，Vibe-Coding 和 Agent 开发工具也会让 PM 更容易自己做原型。原型可能不再只是一套页面，而是一个能调用真实工具、跑完整任务链的小 Agent。

product-tech-boundary

其他可能的奇怪的变化

再往远一点猜：

• • 一些产品的页面访问量可能下降，但实际使用量增加。

• • 一些功能对人来说体验普通，对 Agent 来说非常好用，反而获得更多调用。

• • 大量相似的轻工具可能被 Agent 层屏蔽，用户不再关心背后用了哪一个。

• • 产品品牌可能弱化，能力、数据和服务质量变得更重要。

• • Agent 平台可能掌握分发权，应用重新经历一轮“被入口抽成”。

• • 企业购买软件时，会开始问“能不能接入我们的 Agent”，类似过去询问有没有 API、能不能单点登录。

• • 产品经理的一部分工作，会从设计固定流程转向设计 Agent 可以活动的边界。

一句还不太成熟的概括：过去 PM 设计的是用户完成任务的路径；以后还要设计 Agent 代替用户完成任务的条件、工具和边界。

补课吧，产品经理！

对产品经理来说，充分且透彻的理解 Tool Use、MCP、Skills 这些基本范式已经没啥可讨论得了。

如果你不知道 Agent 如何调用工具，你几乎不可能设计出能被 Agent 调用的工具。

初次之外，还有一部分更重要、但更容易被忽略的：要像过去研究用户心理和用户行为一样，研究 LLM 的基本特性。

比如：

• • AI 拥有大量知识，但反倒更不可靠

• • 它为什么会把“听起来合理”当成“正确”

• • 哪些任务适合完整交给它，哪些环节用程序更合适？

• • 需要提供什么上下文，它才能把事情做对？

• • 怎么拆任务、加约束、设检查点，减少它一路错下去？

• • 产品要提供哪些工具、权限和反馈，Agent 才能稳定工作？

• • 一百万超长上下文，注意力机制为什么反倒更重要了？

• • ……

将来做产品，可能不只是研究“用户想怎么操作”，还得研究“Agent 要怎样才能完成操作”(这两个对象的特性差异其实挺大，应该会冒出不少新的产品方法)。

这些 Agent 时代产品经理需要掌握的基本功，我都压缩到《AI 产品经理转型实战营》线下课了。

两天课程，包括：

• • 大模型的基本原理、缺陷和使用边界（顺便学会用 AI 做市场调研、写 PRD、画高保真原型）

• • Workflow、RAG 和上下文工程（掌握 AI 赋能&Agent 赋能的关键能力原子化拆解）

• • API 调用、Tool Use 和 Agent 循环（上手开发一个真能干活的 Agent 程序）

• • MCP、Skill、CLI，以及怎样让产品对 Agent 更友好

• • Vibe-Coding 实战，从想法到可运行应用（三个 AI 赋能场景，交付完整作品）

第一期已经在过去的 1 个月完成交付，广受好评：

第二期开始招募，安排如下：

城市

时间

状态

北京-2期

8月01-02日

已满

深圳-2期

8月15-16日

招募中

上海-2期

8月22-23日

招募中

课程原价 3999 元，限时早鸟价 2999 元将在二期开营前结束。

扫码可以查看课程详细内容、上课方式与详细安排。