AI Agent产品经理的新思维：从功能设计到AI原生产品的方法论转型

AI Agent产品经理的新思维从功能设计到AI原生产品的方法论转型各位产品同行、AI从业者大家好我是连续3年深耕AI工具Agent产品、从C端信息流今日头条/抖音生态PM成功转型AI原生垂直工具PM的张小白——过去两年我主导的「企业数据决策Agent」从0到1积累了1200付费企业客户MRR从最初的2万涨到现在的180万踩过的坑、总结的方法论今天毫无保留地分享给大家。我知道此刻打开这篇文章的你大概率正处于一种“焦虑与兴奋交织的十字路口”兴奋的是AI Agent的浪潮已经拍岸——OpenAI的GPT-4o Agents、Anthropic的Claude Projects、国内的智谱智谱、通义千问APP内置的“分身”、字节跳动的豆包APP的“豆包企业Agent”、飞书多维表格新增的“Agent助手”、钉钉斜杠的“定制化Agent”几乎所有头部科技公司都在砸钱、砸人、砸资源生怕错过这个比移动互联网更具颠覆性的技术周期焦虑的是你发现自己以前做产品的那套“竞品分析-需求调研-功能列表-原型图-UI评审-灰度上线-数据迭代”的方法论在AI Agent产品面前完全失灵了——你去调研用户用户说“我想要一个能帮我‘搞定所有报销相关的事’的工具”你以前会拆解成“发票拍照识别-智能分类-自动填写报销单-生成审批流程-对接财务系统-打款通知提醒”这一系列功能但AI Agent的用户要的不是“报销功能集合”是“报销这件事‘不需要我动手动脑’的服务闭环”你去抄竞品OpenAI的GPT-4o Agents卖得火但你抄过来之后要么是Agent“太傻太天真”——连发票抬头和税号识别都会错哪怕用了OCRLLM双重校验要么是Agent“太聪明太跳脱”——用户只是让它整理出差的住宿发票它却自作主张帮用户订了下一次出差的机票酒店还对接了公司的差旅审批系统你去画原型图发现以前用Axure/Sketch画的“输入框按钮列表页详情页”的标准组件根本装不下AI Agent的“不确定性交互”——用户可能用语音说可能用图片发可能用Excel表格传可能只给一句模糊的指令Agent的回复也可能是文字、语音、图片、视频、链接、甚至是一段可执行的代码/API调用而且整个交互过程是“多轮对话、分支无限、没有固定流程”的画到最后你发现Axure/Sketch都快崩了原型图却还是一团乱麻你去看数据发现以前关注的“日活、月活、留存率、转化率、客单价、复购率”这些标准指标在AI Agent产品面前只能反映“皮毛”——你日活100万但可能90%的用户都是好奇尝鲜的“一次性用户”问完一句“今天天气怎么样”就再也不来了你转化率10%但可能只有2%的用户真正“用对了”Agent剩下的8%要么是因为Agent帮不了自己的忙退订的要么是因为担心隐私问题卸载的你去灰度上线发现以前的“A/B测试控制变量法”根本没法用——因为变量太多了LLM模型的类型GPT-4o、Claude 3.5 Sonnet、通义千问3.0 Max、智谱清言4.0 Ultra、温度参数、top-p参数、最大token数、Prompt的版本、Agent的工具库、用户的输入方式、用户的使用场景……控制一个变量其他所有变量都会变灰度测试的数据根本没有参考价值最后你去做产品迭代发现以前的“根据数据反馈快速迭代”也不灵了——因为数据反馈往往是滞后的、模糊的比如你今天更新了一个版本的Prompt用户可能明天才会用而且用户不会明确告诉你“这个版本的Prompt比上一个版本好/差在哪里”只会用脚投票——要么继续用要么直接卸载。是不是戳中了你的痛点没关系今天这篇文章就是专门为你准备的。我会用12000字的篇幅从“问题背景旧思维为什么会失灵”“核心概念AI Agent到底是什么和传统的软件产品、传统的AI工具、大模型API有什么本质区别”“问题解决从功能设计到AI原生产品的5步方法论转型从‘拆解功能’到‘定义意图’、从‘设计流程’到‘构建思维链’、从‘开发功能’到‘组装工具链’、从‘固定交互’到‘设计弹性交互’、从‘数据驱动’到‘用户意图驱动的反馈闭环’”“边界与外延AI Agent产品经理的能力边界、AI Agent产品的边界与适用场景”“最佳实践tips我踩过的10个大坑以及对应的避坑指南”“行业发展与未来趋势AI Agent的发展历史、当前阶段、未来1-3年的发展趋势、产品经理的职业发展路径”“本章小结”这7个部分系统地讲解AI Agent产品经理的新思维。为了让你更好地理解这篇文章我会在文中穿插大量的案例分析包括我自己主导的「企业数据决策Agent」、OpenAI的GPT-4o Agents、字节跳动的豆包APP内置的“豆包企业Agent”、飞书多维表格新增的“Agent助手”、以及我调研过的100个AI Agent产品、概念对比表格AI Agent vs 传统软件产品 vs 传统AI工具 vs 大模型API、ER实体关系图AI Agent的核心组成要素及其关系、mermaid架构图AI原生产品的系统架构、mermaid交互关系图AI Agent的弹性交互流程、mermaid算法流程图从用户意图到Agent行为的转换流程、python伪代码思维链Prompt的设计、工具链的调用逻辑、数学模型用户意图的识别准确率公式、工具链的调用效率公式、Agent的整体满意度公式——所有的内容都是“干货满满”没有一句废话。好了话不多说让我们正式开始吧一、问题背景从功能设计到AI原生产品旧思维为什么会彻底失灵在正式讲解新思维之前我们必须先搞清楚一个问题我们以前做产品的那套“功能设计方法论”到底是什么它在移动互联网时代为什么会成功它在AI Agent产品面前为什么会彻底失灵只有搞清楚了这个问题我们才能真正理解“转型”的必要性才能从根本上改变自己的思维方式。1.1 旧思维是什么——移动互联网时代的“功能设计方法论”移动互联网时代的“功能设计方法论”本质上是一套**“以功能为中心、以流程为导向、以控制变量法为核心迭代方法”** 的产品方法论这套方法论是由苹果、谷歌、腾讯、阿里、字节跳动这些头部科技公司在过去15年的时间里通过无数次的成功和失败总结出来的它的核心逻辑可以用以下几个关键词来概括1.1.1 关键词一“需求拆解”——从“模糊的用户需求”到“清晰的功能列表”移动互联网时代的PM最核心的能力之一就是“需求拆解能力”——用户说“我想要一个能帮我打车的工具”PM会拆解成“定位当前位置-查看附近的车辆-选择车型快车、专车、豪华车、顺风车-输入/选择目的地-预估价格/时间-发起订单-司机接单-实时跟踪司机位置-到达目的地-在线支付-评价司机/车辆”这一系列“原子级的、可执行的、可量化的”功能用户说“我想要一个能帮我点外卖的工具”PM会拆解成“定位当前位置-查看附近的商家-选择商家-选择菜品/饮料-加入购物车-提交订单-选择支付方式-在线支付-查看订单状态商家接单、商家出餐、骑手取餐、骑手送餐、送达-评价商家/骑手/菜品”这一系列功能。为什么要做“需求拆解”因为在移动互联网时代软件产品的本质是“功能的集合体”每一个功能都是“解决用户某个具体痛点的工具”把所有的功能整合在一起就是一个“解决用户某个场景下所有痛点的产品”。而且“需求拆解”的越细“原子级的功能”越明确开发团队的开发效率就越高测试团队的测试难度就越低PM的项目管理难度就越小——这简直就是一套“完美的工业化产品方法论”和“汽车制造”“手机制造”的逻辑是一模一样的汽车制造商会把“一辆汽车”拆解成“发动机、变速箱、底盘、车身、轮胎、方向盘、座椅、空调、音响”等“原子级的零部件”然后把这些零部件交给不同的供应商去生产最后在总装车间组装成一辆完整的汽车手机制造商会把“一部手机”拆解成“芯片、屏幕、电池、摄像头、扬声器、麦克风、按键、外壳”等“原子级的零部件”然后交给不同的供应商去生产最后在总装车间组装成一部完整的手机。1.1.2 关键词二“流程设计”——从“功能列表”到“固定的用户操作流程”移动互联网时代的PM另一个核心能力就是“流程设计能力”——当PM把“模糊的用户需求”拆解成“清晰的功能列表”之后接下来要做的就是把这些功能“串联起来”设计成一条“固定的、最短的、最符合用户习惯的”用户操作流程。比如“滴滴打车”的核心用户操作流程是“打开APP→自动定位→选择车型→输入/选择目的地→发起订单→在线支付→评价”——这条流程是“单向的、没有分支的或者分支很少、且都是PM预先设计好的、用户必须严格按照PM设计的顺序来操作否则就无法完成打车的任务”比如“美团外卖”的核心用户操作流程是“打开APP→自动定位→选择商家→选择菜品→加入购物车→提交订单→在线支付→评价”——这条流程也是“单向的、没有分支的或者分支很少、用户必须严格按照PM设计的顺序来操作否则就无法完成点外卖的任务”。为什么要做“流程设计”因为在移动互联网时代用户操作软件产品的本质是“在PM预先设计好的流程里做选择题”——PM会把所有可能的用户操作路径都预先设计好用户只需要在这些路径里“做选择题”比如“选择快车还是专车”“选择支付宝还是微信支付”不需要“做填空题”比如“自己设计一条打车的路径”更不需要“做问答题”比如“自己思考怎么完成打车的任务”。而且“固定的用户操作流程”越短、越符合用户习惯用户的学习成本就越低用户的使用体验就越好产品的留存率和转化率就越高——这也是为什么“移动互联网时代的PM都在追求‘极简设计’‘一键操作’‘傻瓜式操作’”的原因。1.1.3 关键词三“控制变量法的A/B测试”——从“原型图”到“上线后的快速迭代”移动互联网时代的PM第三个核心能力就是“控制变量法的A/B测试能力”——当PM把“固定的用户操作流程”设计成“原型图”“UI稿”“高保真原型”之后接下来要做的就是“灰度上线”“A/B测试”“数据迭代”。比如PM不确定“滴滴打车”的“订单发起按钮”应该放在“屏幕底部的中间”还是“屏幕底部的右侧”PM就会做一个A/B测试把100万的用户分成两组A组50万用户看到的是“订单发起按钮放在屏幕底部的中间”的版本B组50万用户看到的是“订单发起按钮放在屏幕底部的右侧”的版本然后控制其他所有变量比如用户的使用场景、用户的使用设备、用户的网络环境、当时的天气情况、当时的交通状况都保持不变最后看哪一组的“订单发起率”更高——如果A组的“订单发起率”是12%B组的“订单发起率”是15%那么PM就会把“订单发起按钮放在屏幕底部的右侧”的版本全量上线如果后续数据显示“订单发起按钮放在屏幕底部的右侧”的版本的“订单取消率”比之前的版本高PM就会再做一个A/B测试看看能不能优化一下这个版本的其他功能降低“订单取消率”。为什么要用“控制变量法的A/B测试”因为在移动互联网时代产品迭代的本质是“用数据验证PM的假设”——PM的所有决策比如“按钮放在哪里”“颜色用什么”“文案写什么”本质上都是“假设”这些假设是否正确只有通过“数据验证”才能知道。而且“控制变量法的A/B测试”是“最科学、最准确、成本最低”的数据验证方法——通过控制其他所有变量都保持不变PM可以准确地知道“某个具体的变化比如按钮的位置、颜色、文案对某个具体的指标比如订单发起率、订单取消率、留存率、转化率的影响”从而做出“最正确”的决策。1.1.4 关键词四“标准的量化指标体系”——从“上线”到“产品的全生命周期管理”移动互联网时代的PM第四个核心能力就是“标准的量化指标体系的设计和分析能力”——当PM把产品“全量上线”之后接下来要做的就是“产品的全生命周期管理”而“产品的全生命周期管理”的核心就是“标准的量化指标体系的设计和分析”。移动互联网时代的“标准的量化指标体系”主要包括以下几个部分用户规模指标日活DAU、月活MAU、周活WAU、新增用户数、激活用户数、留存用户数次日留存、7日留存、30日留存、90日留存、流失用户数用户行为指标页面浏览量PV、独立访客数UV、平均页面停留时间、平均会话时长、跳出率、转化率注册转化率、登录转化率、订单发起转化率、订单支付转化率、复购转化率商业变现指标客单价、复购率、GMV商品交易总额、MRR月度经常性收入、ARR年度经常性收入、LTV用户终身价值、CAC用户获取成本、LTV/CAC用户终身价值与用户获取成本的比值这个比值至少要大于3产品才是盈利的产品质量指标崩溃率、ANR应用无响应率、错误率、加载时间、延迟时间。为什么要用“标准的量化指标体系”因为在移动互联网时代产品的成功与否本质上是“用数据说话”的——没有“标准的量化指标体系”PM就无法知道“产品的表现怎么样”“产品哪里做得好”“产品哪里做得不好”“产品应该怎么迭代”就像“没有仪表盘的汽车司机”根本不知道“自己开了多少公里”“自己的速度是多少”“自己的油量还剩多少”“自己的轮胎有没有问题”随时都有可能“翻车”。1.2 旧思维在移动互联网时代为什么会成功好了我们已经搞清楚了“旧思维是什么”接下来我们要搞清楚的问题是旧思维在移动互联网时代为什么会成功只有搞清楚了这个问题我们才能真正理解“旧思维的适用场景是什么”才能知道“什么时候应该用旧思维什么时候应该用新思维”。我认为旧思维在移动互联网时代之所以会成功主要有以下几个原因1.2.1 原因一移动互联网时代的用户需求是“相对明确、相对稳定、相对可预测的”移动互联网时代的用户需求本质上是“对传统线下需求的线上化改造”——比如“打车”是传统线下需求“滴滴打车”是对这个需求的线上化改造“点外卖”是传统线下需求“美团外卖”是对这个需求的线上化改造“买东西”是传统线下需求“淘宝/天猫/京东/拼多多”是对这个需求的线上化改造“社交”是传统线下需求“微信/QQ/微博”是对这个需求的线上化改造“看新闻”是传统线下需求“今日头条/腾讯新闻/网易新闻”是对这个需求的线上化改造“看视频”是传统线下需求“抖音/快手/爱奇艺/腾讯视频/优酷视频”是对这个需求的线上化改造。既然是“对传统线下需求的线上化改造”那么移动互联网时代的用户需求就是“相对明确、相对稳定、相对可预测的”——比如“打车”的需求就是“从A点到B点越快越好越便宜越好越安全越好”这个需求“从出租车诞生的那一天起就没有变过”未来10-20年也“大概率不会变”比如“点外卖”的需求就是“不用自己做饭不用自己出去买在家就能吃到自己想吃的东西越快越好越便宜越好越好吃越好越卫生越好”这个需求“从外卖诞生的那一天起就没有变过”未来10-20年也“大概率不会变”。既然用户需求是“相对明确、相对稳定、相对可预测的”那么PM就可以“很容易地把用户需求拆解成清晰的功能列表”就可以“很容易地设计出固定的用户操作流程”就可以“很容易地用控制变量法的A/B测试验证自己的假设”就可以“很容易地用标准的量化指标体系管理产品的全生命周期”——这就是旧思维在移动互联网时代成功的“最核心的原因”。1.2.2 原因二移动互联网时代的软件产品是“相对确定、相对可控、相对可量化的”移动互联网时代的软件产品本质上是“一套由代码组成的、相对确定的、相对可控的、相对可量化的逻辑系统”——比如“滴滴打车”的“订单发起功能”本质上是“一套由代码组成的逻辑当用户点击‘订单发起按钮’时APP会自动收集用户的当前位置、选择的车型、输入/选择的目的地等信息然后把这些信息发送给滴滴的服务器滴滴的服务器会根据这些信息在附近寻找符合条件的司机然后把订单推送给这些司机同时APP会显示‘正在寻找司机’的界面”——这套逻辑是“相对确定的”只要用户点击“订单发起按钮”APP就一定会执行这套逻辑这套逻辑是“相对可控的”PM和开发团队可以随时修改这套逻辑比如“修改寻找司机的范围”“修改推送给司机的优先级”“修改‘正在寻找司机’的界面的文案和UI”这套逻辑是“相对可量化的”PM可以随时查看这套逻辑的“执行数据”比如“订单发起率”“寻找司机的平均时间”“司机的接单率”“用户的取消率”。既然软件产品是“相对确定、相对可控、相对可量化的”那么PM就可以“很容易地开发出产品”就可以“很容易地测试产品”就可以“很容易地上线产品”就可以“很容易地迭代产品”——这也是旧思维在移动互联网时代成功的“重要原因”。1.2.3 原因三移动互联网时代的用户交互是“相对固定、相对单向、相对可预测的”移动互联网时代的用户交互本质上是“用户在PM预先设计好的固定流程里通过点击、滑动、输入等相对固定的操作方式与软件产品进行的相对单向、相对可预测的交互”——比如“滴滴打车”的用户交互是“用户打开APP→APP自动定位这是PM预先设计好的用户不需要做任何操作→用户点击‘快车’‘专车’‘豪华车’‘顺风车’中的一个这是PM预先设计好的选项用户只能做选择题→用户点击‘目的地输入框’输入/选择目的地这是PM预先设计好的操作方式用户只能通过点击输入框、输入文字、或者点击历史目的地/推荐目的地的方式来选择目的地→用户点击‘订单发起按钮’这是PM预先设计好的操作方式用户只能通过点击按钮的方式来发起订单→用户点击‘支付宝’‘微信支付’‘银行卡支付’中的一个这是PM预先设计好的选项用户只能做选择题→用户点击‘确认支付’按钮这是PM预先设计好的操作方式用户只能通过点击按钮的方式来确认支付→用户点击‘星星’来评价司机/车辆这是PM预先设计好的操作方式用户只能通过点击星星的方式来评价星星的数量也是PM预先设计好的最多5颗最少1颗”——整个交互过程是“相对固定的”用户必须严格按照PM设计的顺序来操作否则就无法完成打车的任务整个交互过程是“相对单向的”软件产品只会“被动地响应用户的操作”不会“主动地发起交互”除非是PM预先设计好的推送通知比如“司机接单了”“司机到达起点了”“订单送达了”“支付成功了”“快来评价司机/车辆吧”整个交互过程是“相对可预测的”PM可以准确地预测“用户在什么时候会做什么操作”比如“用户在选择完目的地之后大概率会点击‘订单发起按钮’”“用户在点击‘订单发起按钮’之后大概率会等待司机接单”“用户在订单送达之后大概率会在线支付”——这也是旧思维在移动互联网时代成功的“重要原因”。1.3 旧思维在AI Agent产品面前为什么会彻底失灵好了我们已经搞清楚了“旧思维是什么”“旧思维在移动互联网时代为什么会成功”接下来我们要搞清楚的问题是旧思维在AI Agent产品面前为什么会彻底失灵这是我们今天这篇文章的“核心问题之一”只有搞清楚了这个问题我们才能真正理解“转型的必要性”才能从根本上改变自己的思维方式。我认为旧思维在AI Agent产品面前之所以会彻底失灵主要有以下几个原因1.3.1 原因一AI Agent时代的用户需求是“模糊的、动态的、不可预测的”和移动互联网时代的用户需求不同AI Agent时代的用户需求不是“对传统线下需求的线上化改造”而是“对传统的‘人-机’交互模式的彻底颠覆”——用户不再需要“自己动手动脑去完成某个任务”而是需要“一个能帮自己‘搞定所有事情’的智能助手”或者说“一个能代替自己去完成某个任务的‘数字员工’”。比如用户不再说“我想要一个能帮我拍照识别发票的工具”而是说“我想要一个能帮我‘搞定所有报销相关的事’的工具”用户不再说“我想要一个能帮我整理数据的工具”而是说“我想要一个能帮我‘分析上个月的销售数据找出销量下降的原因并且给出具体的解决方案’的工具”用户不再说“我想要一个能帮我写邮件的工具”而是说“我想要一个能帮我‘给客户写一封邮件回复客户关于产品价格的疑问并且说服客户尽快下单’的工具”用户不再说“我想要一个能帮我订机票酒店的工具”而是说“我想要一个能帮我‘安排下个月去北京出差的行程包括订机票、订酒店、预约客户、预约会议室、准备会议资料’的工具”——这些需求都是“模糊的、动态的、不可预测的”需求是模糊的用户不会明确告诉你“我需要哪些功能”“我需要什么样的流程”“我需要什么样的结果”只会给你一句“模糊的指令”比如“搞定所有报销相关的事”“分析上个月的销售数据”“给客户写一封邮件”“安排下个月去北京出差的行程”需求是动态的用户的需求会“随时变化”——比如用户一开始让Agent“安排下个月去北京出差的行程”当Agent已经订好了机票、酒店、预约了客户、预约了会议室、准备了会议资料之后用户可能会突然说“我下个月不去北京了改成去上海”或者说“我下个月去北京的时间提前了3天”或者说“我下个月去北京除了见客户A还要见客户B和客户C”需求是不可预测的PM根本无法“预测用户会提出什么样的需求”——比如你做的是“企业数据决策Agent”你以为用户只会用它来“分析销售数据”“分析财务数据”“分析用户数据”但实际上用户可能会用它来“分析竞争对手的新闻稿”“分析行业报告”“分析员工的绩效考核数据”“分析公司的采购数据”“分析公司的库存数据”——只有你想不到的没有用户提不出来的。既然用户需求是“模糊的、动态的、不可预测的”那么PM就“无法像以前那样把用户需求拆解成清晰的功能列表”就“无法像以前那样设计出固定的用户操作流程”——这就是旧思维在AI Agent产品面前失灵的“最核心的原因”。1.3.2 原因二AI Agent产品是“不确定的、不可控的、不可完全量化的”和移动互联网时代的软件产品不同AI Agent产品的本质不是“一套由代码组成的、相对确定的、相对可控的、相对可量化的逻辑系统”而是“一套由大模型LLM/LMM、思维链Chain of Thought, CoT、工具链Tool Chain、记忆系统Memory System、反馈系统Feedback System组成的、不确定的、不可控的、不可完全量化的‘智能系统’”——这套系统的“核心”是大模型而大模型的“本质”是“一个基于概率的、黑盒的、不可完全解释的语言模型/多模态模型”大模型是基于概率的大模型的每一次输出本质上都是“根据输入的内容和自己的训练数据预测下一个最可能出现的token词/字/图片片段/视频片段”——也就是说大模型的输出是“不确定的”即使你给大模型输入的是“完全相同的内容”只要你调整一下大模型的温度参数、top-p参数、最大token数或者只要大模型的训练数据发生了变化大模型的输出就“可能会不一样”甚至有时候你给大模型输入的是“完全相同的内容”而且大模型的温度参数、top-p参数、最大token数、训练数据都没有发生变化大模型的输出也“可能会不一样”——因为大模型内部有一些“随机种子”这些随机种子会影响大模型的输出大模型是黑盒的、不可完全解释的目前为止人类还“无法完全解释大模型的内部工作原理”——我们不知道“大模型为什么会输出这样的内容”“大模型为什么会犯这样的错误”“大模型为什么会有这样的能力”我们只能“通过输入和输出的对比来猜测大模型的内部工作原理”——这就意味着AI Agent产品是“不可控的”PM和开发团队无法“像以前控制移动互联网时代的软件产品那样完全控制AI Agent产品的行为”——Agent可能会“太傻太天真”连简单的问题都解决不了Agent也可能会“太聪明太跳脱”自作主张地做一些用户没有让它做的事情Agent甚至可能会“撒谎”“编造事实”“输出有害的内容”AI Agent产品是不可完全量化的移动互联网时代的软件产品的“所有行为”都是“可量化的”——比如“滴滴打车”的“订单发起率”“寻找司机的平均时间”“司机的接单率”“用户的取消率”都是“可量化的”但AI Agent产品的“很多行为”都是“不可完全量化的”——比如Agent“分析上个月的销售数据的质量”“给客户写的邮件的质量”“安排出差行程的合理性”“和用户的交互体验的好坏”都是“不可完全量化的”——这些指标“只能通过用户的主观评价来衡量”而“用户的主观评价”是“模糊的、动态的、不可预测的”。既然AI Agent产品是“不确定的、不可控的、不可完全量化的”那么PM就“无法像以前那样用控制变量法的A/B测试验证自己的假设”就“无法像以前那样用标准的量化指标体系管理产品的全生命周期”——这也是旧思维在AI Agent产品面前失灵的“重要原因”。1.3.3 原因三AI Agent时代的用户交互是“弹性的、双向的、不可预测的”和移动互联网时代的用户交互不同AI Agent时代的用户交互不是“用户在PM预先设计好的固定流程里通过点击、滑动、输入等相对固定的操作方式与软件产品进行的相对单向、相对可预测的交互”而是“用户和Agent之间通过文字、语音、图片、视频、链接、甚至是一段可执行的代码/API调用等任意的操作方式进行的弹性的、双向的、不可预测的交互”交互是弹性的整个交互过程是“多轮对话、分支无限、没有固定流程”的——用户可以“随时打断Agent的话”“随时改变自己的需求”“随时提问Agent任何问题”“随时让Agent修改它之前的输出”Agent也可以“随时向用户提问”——当Agent发现用户的指令是“模糊的”“不完整的”“有歧义的”的时候Agent会“主动地向用户提问获取更多的信息以便更好地理解用户的意图完成用户的任务”比如用户说“帮我安排下个月去北京出差的行程”Agent会主动地向用户提问“请问您下个月去北京的具体日期是哪几天”“请问您的出发城市是哪里”“请问您对机票的舱位有什么要求吗经济舱、商务舱、头等舱”“请问您对酒店的星级有什么要求吗三星级、四星级、五星级”“请问您对酒店的位置有什么要求吗靠近客户公司、靠近机场、靠近市中心”“请问您要见哪些客户每个客户的具体见面时间和地点是什么”“请问您需要预约会议室吗如果需要的话会议室的具体要求是什么容纳人数、设备要求、时间要求”“请问您需要准备会议资料吗如果需要的话会议资料的具体内容是什么”——这些问题都是“Agent根据用户的模糊指令主动发起的”PM根本无法“预先设计好所有的问题”交互是双向的Agent不再是“被动地响应用户的操作”而是“主动地发起交互”——除了“当用户的指令是模糊的、不完整的、有歧义的时候主动地向用户提问”之外Agent还可以“根据用户的历史行为和记忆主动地为用户提供服务”——比如你做的是“企业数据决策Agent”Agent可以“根据用户的历史行为知道用户每个月的1号都会查看上个月的销售数据”那么到了每个月的1号Agent就会“主动地向用户发起交互‘张总这是您上个月的销售数据我已经帮您分析过了销量下降的主要原因是华东地区的竞争对手推出了一款新产品价格比我们的产品低20%我已经帮您准备了一份具体的解决方案您要不要看一下’”比如你做的是“个人生活助理Agent”Agent可以“根据用户的历史行为和记忆知道用户每个周末都会去爬山”那么到了每个周末的前一天Agent就会“主动地向用户发起交互‘小白明天的天气很好适合爬山我已经帮您查了附近的几座山的情况包括人流量、路线难度、停车情况您要不要看一下另外我已经帮您准备好了爬山需要的物品清单您要不要检查一下’”交互是不可预测的PM根本无法“预测用户会用什么样的操作方式和Agent交互”——用户可能用文字说可能用语音说可能用图片发比如发一张发票的照片让Agent帮忙报销可能用Excel表格传比如传一张上个月的销售数据表格让Agent帮忙分析可能用视频发比如发一段会议的视频让Agent帮忙整理会议纪要可能只给一句模糊的指令可能给一段详细的指令可能给一个链接可能给一段可执行的代码/API调用——只有你想不到的没有用户做不到的PM也根本无法“预测Agent会用什么样的操作方式和用户交互”——Agent可能用文字回复可能用语音回复可能用图片回复比如生成一张上个月的销售数据的图表可能用视频回复可能给一个链接可能给一段可执行的代码/API调用可能给一份文档可能给一份PPT——只有你想不到的没有Agent做不到的。既然用户交互是“弹性的、双向的、不可预测的”那么PM就“无法像以前那样用Axure/Sketch画原型图”——因为Axure/Sketch的标准组件根本装不下“弹性的、双向的、不可预测的交互”——这也是旧思维在AI Agent产品面前失灵的“重要原因”。二、核心概念AI Agent到底是什么——和传统软件产品、传统AI工具、大模型API的本质区别好了我们已经搞清楚了“问题背景”——旧思维在移动互联网时代为什么会成功在AI Agent产品面前为什么会彻底失灵。接下来我们要搞清楚的问题是AI Agent到底是什么它和传统的软件产品、传统的AI工具、大模型API有什么本质区别它的核心组成要素是什么这些核心组成要素之间的关系是什么只有搞清楚了这些问题我们才能真正理解“AI Agent产品的本质”才能知道“怎么做AI Agent产品”。2.1 AI Agent的定义到底什么是AI Agent“AI Agent”这个概念其实早在“大模型时代”到来之前就已经存在了——比如在“游戏AI”领域我们早就有了“NPC Agent”非玩家角色智能体在“机器人领域”我们早就有了“机器人Agent”在“推荐系统领域”我们也可以把“推荐系统”看作是一个“简单的AI Agent”——但“大模型时代的AI Agent”和“大模型时代之前的AI Agent”有“本质的区别”大模型时代之前的AI Agent本质上是“一套由代码组成的、相对确定的、相对可控的、只能完成某个特定任务的逻辑系统”而大模型时代的AI Agent本质上是“一个由大模型LLM/LMM作为‘大脑’由思维链Chain of Thought, CoT作为‘思考方式’由工具链Tool Chain作为‘手脚’由记忆系统Memory System作为‘记忆’由反馈系统Feedback System作为‘学习机制’的、通用的、自主的、能完成任意复杂任务的‘数字员工’”。为了让你更好地理解这个定义我给你举一个我自己主导的「企业数据决策Agent」的例子用户的模糊指令“张小白帮我分析一下上个月的销售数据找出销量下降的原因并且给出具体的解决方案。”「企业数据决策Agent」的执行流程大脑大模型通义千问3.0 Max首先理解用户的意图“用户让我分析上个月的销售数据找出销量下降的原因并且给出具体的解决方案。”大脑大模型然后调用记忆系统Memory System“让我看看用户的历史行为和记忆——用户是‘XX公司’的‘销售总监张总’他每个月的1号都会查看上个月的销售数据他之前让我分析过‘华东地区的销售数据’‘华北地区的销售数据’‘华南地区的销售数据’他最关注的指标是‘总销售额’‘总销量’‘各地区的销售额/销量’‘各产品的销售额/销量’‘各渠道的销售额/销量’‘新客户的销售额/销量’‘老客户的销售额/销量’‘客户的复购率’‘客户的流失率’。”大脑大模型接着调用思维链Chain of Thought, CoT进行思考“我应该怎么完成这个任务呢首先我需要从公司的‘数据仓库’里获取上个月的销售数据——上个月是‘202X年X月’对吧哦不对我应该先向用户确认一下上个月的具体日期不用户说的‘上个月’应该就是‘当前时间的上一个自然月’我可以先假设是‘202X年X月’如果获取的数据不对我再向用户确认。然后我需要对获取到的销售数据进行清洗和整理——去除重复数据、去除无效数据、补全缺失数据。接着我需要对清洗和整理后的销售数据进行分析——首先看一下‘总销售额’和‘总销量’的同比和环比数据确认销量是不是真的下降了如果销量真的下降了我再从‘各地区’‘各产品’‘各渠道’‘新客户/老客户’‘客户复购率/流失率’这几个维度进行拆解找出销量下降的具体原因找出具体原因之后我再给出具体的解决方案。最后我需要把分析结果和解决方案整理成一份‘可视化的报告’包括‘文字说明’和‘图表’然后发送给用户。”大脑大模型然后根据思维链的思考结果调用工具链Tool Chain里的工具执行任务a.调用「数据仓库查询工具」输入SQL查询语句“SELECT * FROM sales_data WHERE date BETWEEN ‘202X-0X-01’ AND ‘202X-0X-31’”从公司的“数据仓库”里获取上个月的销售数据b.调用「数据清洗和整理工具」对获取到的销售数据进行清洗和整理——去除重复数据、去除无效数据、补全缺失数据c.调用「数据分析工具」对清洗和整理后的销售数据进行分析——首先计算“总销售额”和“总销量”的同比和环比数据确认销量是不是真的下降了如果销量真的下降了再从“各地区”“各产品”“各渠道”“新客户/老客户”“客户复购率/流失率”这几个维度进行拆解找出销量下降的具体原因d.调用「可视化图表生成工具」根据分析结果生成“总销售额/总销量的同比环比图”“各地区的销售额/销量占比图”“各产品的销售额/销量占比图”“各渠道的销售额/销量占比图”“新客户/老客户的销售额/销量占比图”“客户复购率/流失率的趋势图”等可视化图表e.调用「报告生成工具」把分析结果、解决方案和可视化图表整理成一份“PDF格式的可视化报告”f.调用「企业微信/钉钉消息发送工具」把这份“PDF格式的可视化报告”发送给用户销售总监张总。大脑大模型最后调用反馈系统Feedback System记录这次任务的执行结果并且等待用户的反馈“我已经完成了用户的任务把分析结果和解决方案整理成了一份PDF格式的可视化报告并且发送给了用户。现在我需要记录这次任务的执行结果——包括‘用户的指令’‘我的思考过程’‘我调用的工具’‘工具的执行结果’‘我生成的报告’‘报告的发送时间’。然后我需要等待用户的反馈——如果用户对报告满意我就可以从这次任务中‘学习’到‘以后应该怎么更好地完成类似的任务’如果用户对报告不满意我就可以根据用户的反馈‘修改我的思考过程’‘修改我调用的工具’‘修改我生成的报告’直到用户满意为止。”你看这个「企业数据决策Agent」是不是就像一个“真正的数字员工”——它有“大脑”大模型能“思考”思维链有“手脚”工具链有“记忆”记忆系统能“学习”反馈系统能“自主地完成任意复杂的任务”——这就是“大模型时代的AI Agent”和“大模型时代之前的AI Agent”的“本质区别”。2.2 AI Agent的本质区别AI Agent vs 传统软件产品 vs 传统AI工具 vs 大模型API为了让你更好地理解“AI Agent的本质”我专门做了一个“概念对比表格”从“核心组成要素”“能力范围”“自主性”“交互方式”“输出结果”“适用场景”“产品经理的核心能力”这7个维度对比了“AI Agent”“传统软件产品”“传统AI工具”“大模型API”这4个概念维度大模型时代的AI Agent传统软件产品传统AI工具大模型API核心组成要素大模型LLM/LMM 思维链CoT 工具链Tool Chain 记忆系统Memory 反馈系统Feedback代码逻辑 UI界面 数据库 API接口特定的AI模型比如OCR模型、语音识别模型、语音合成模型、推荐系统模型 代码逻辑 UI界面 数据库 API接口大模型LLM/LMM API接口比如文本生成接口、多模态理解接口、代码生成接口能力范围通用的——能完成任意复杂的任务只要给它足够的工具和记忆特定的——只能完成PM预先设计好的特定任务特定的——只能完成某个特定的AI任务比如OCR识别、语音识别、语音合成、推荐通用的——能完成任意的文本/多模态任务比如文本生成、多模态理解、代码生成、翻译、摘要但不能直接调用外部工具不能直接访问外部数据不能直接执行代码自主性高——能自主地理解用户的意图自主地进行思考自主地调用工具自主地完成任务自主地向用户提问获取更多的信息自主地根据用户的反馈进行学习低——只能被动地响应用户的操作不能自主地进行思考不能自主地调用工具不能自主地完成任务不能自主地向用户提问不能自主地进行学习中——能被动地响应用户的操作能自主地完成某个特定的AI任务但不能自主地进行思考不能自主地调用其他工具不能自主地向用户提问不能自主地进行学习低——只能被动地响应用户的API调用不能自主地进行思考不能自主地调用外部工具不能自主地访问外部数据不能自主地执行代码不能自主地向用户提问不能自主地进行学习交互方式弹性的、双向的、不可预测的——可以通过文字、语音、图片、视频、链接、代码/API调用等任意方式交互用户可以随时打断Agent的话随时改变自己的需求随时提问任何问题随时修改之前的输出Agent可以主动地向用户提问获取更多的信息可以主动地根据用户的历史行为和记忆提供服务固定的、单向的、可预测的——只能通过点击、滑动、输入等相对固定的方式交互用户必须严格按照PM预先设计好的流程操作软件产品只能被动地响应用户的操作除非是PM预先设计好的推送通知相对固定的、单向的、可预测的——只能通过点击、滑动、输入等