.png)
最近几年都在做 Agent（AI 智能体）项目时，我有一个越来越深的感受：现在做一个 Agent，其实没那么难。真正难的是，让它在实际业务中稳定运行，真正帮企业解决问题。
为什么这么说？
现在有了 Dify、Coze 这些工具，就算不太懂代码，花半天时间，也能搭出一个看起来不错的 Agent。
接入大模型，上传一些知识库文档，配置几个工具，再把工作流程串起来，一个能回答问题、查询数据、执行任务的 AI 助手就做好了。
演示的时候，效果通常还不错。
但真正交给业务人员使用，问题就来了。
比如：
用户稍微换一种说法，Agent 就听不懂了。
明明应该去系统里查数据，它却自己编了一个答案。
调用工具失败后，它不停地重复调用，最后直接卡住。
用户已经修改了需求，它还按照之前的要求执行。
测试时表现很好，上线后却经常出错。
AI 调用费用越来越高，但实际节省的人工成本却很有限。
这些问题，真的是因为大模型不够聪明吗？
不完全是。
很多时候，问题出在一开始的产品设计上。
比如，没有明确 Agent 到底负责什么，也没有规定它能做什么、不能做什么，更没有考虑出错以后怎么办。
这就好比招聘一名员工。
你只告诉他：“以后公司的事情你都帮忙处理一下。”
却没有告诉他具体负责哪些工作、有什么权限、遇到问题找谁。
那这个员工再聪明，也很容易把事情搞砸。
Agent 也是一样。
一个真正能落地的 Agent，不仅要有聪明的大脑，还要有清晰的工作职责、办事流程和管理规则。
结合实际项目中容易遇到的问题，我总结了 AI 产品经理需要重点掌握的 6 个能力。
一、别一上来就做万能 Agent，先让它把一件事做好
很多团队刚开始做 Agent 时，都有一个共同的问题：
想做的事情太多。
比如，要做一个电商售后 Agent。
业务方可能希望它能：回答售后问题、查询订单、判断退款条件、自动退款、创建工单，最好还能主动联系客户。
听起来非常不错。
如果这些功能都实现了，确实能节省不少人工成本。
但问题是，功能越多，需要考虑的情况就越复杂。
比如，用户说想退款。
这时候 Agent 就得考虑：用户有没有提供订单号？如果用户买了好几件商品，到底要退哪一件？如果订单已经退款了怎么办？如果不符合退款条件怎么办？如果退款接口突然出问题了怎么办？
这些问题看起来不起眼，但每一个都可能影响实际业务。
如果第一版就把所有功能都做进去，很容易出现一种情况：看起来什么都会，实际用起来什么都不稳定。
更好的办法：先解决一个具体问题
假设还是做电商售后 Agent。
第一版先不要让它直接处理退款。
只让它完成一件事：
听懂用户的售后需求，然后帮用户创建售后工单。
比如，用户说：“我昨天买的耳机，今天收到发现左边没有声音，我想换一个。”
这时候 Agent 要做什么？
首先，它要听懂用户的问题。
用户买的是耳机，遇到的是商品质量问题，想要的解决方案是换货。
其次，它要检查创建工单需要的信息是否齐全。
发现没有订单号，就主动询问：“好的，我来帮您申请售后。麻烦提供一下订单号。”
用户提供订单号后，Agent 再去系统里查询订单信息。
确认信息没有问题，就创建一张售后工单，并告诉用户处理结果。
这样，一个完整的业务流程就跑通了。
虽然它暂时不能自动退款，也不能处理所有售后问题。
但至少，它能稳定完成一件有价值的事情。
等这个功能运行稳定，再逐步增加订单查询、退款条件判断、自动处理退款等能力。
这里有一个非常重要的产品思路：做 Agent，不要一开始就追求功能多，而要先保证一个核心功能真的能用。
就像开餐馆。
与其第一天就推出100道菜，不如先把10道招牌菜做好。
用户真正需要的，不是菜单上有多少道菜，而是点的菜好不好吃。
Agent 也是这个道理。
二、不要什么事情都让大模型做，要分清 AI 和业务系统的职责
做 Agent 时，还有一个很容易犯的错误：觉得大模型这么聪明，什么事情都可以交给它。
实际上，大模型虽然很强，但并不适合处理所有事情。
尤其是涉及金额、订单状态、用户权限等需要准确结果的业务。
举个例子。
用户问售后 Agent：
“我这个订单还能退款吗？”
如果直接让大模型回答，它可能根据知识库中的退款政策，给出这样的回复：
“根据平台规定，商品支持7天无理由退款，您的订单可以申请退款。”
听起来挺合理。
但问题是，Agent 可能根本没有查询用户的订单。
它不知道商品有没有超过退款期限，也不知道订单是否已经退款，更不知道商品是否属于特殊类目。
这就可能出现一个严重的问题：AI 说可以退款，但实际业务系统根本不允许退款。
用户听了 AI 的回答，认为自己一定能退款。
最后发现退不了，就容易产生投诉。
正确的做法是什么？
其实很简单。
让大模型负责理解用户，让业务系统负责处理业务。
还是刚才的退款场景。
整个流程应该是这样的：
第一步，用户说：“我想退掉昨天买的耳机。”
第二步，大模型识别出用户想申请退款，并提取相关信息。
第三步，Agent 调用订单查询工具，获取真实订单数据。
第四步，业务系统根据订单状态和退款规则，判断是否符合退款条件。
第五步，大模型把查询结果整理成用户容易理解的话。
比如：“查询到您的订单昨天已经签收，目前还在7天无理由退款期限内，可以申请退款。”
这样就合理多了。
因为退款资格不是 AI 猜出来的，而是业务系统判断出来的。
再举一个例子。
用户购买了一件999元的商品，使用了100元优惠券，其中部分商品已经退款。
现在用户想知道还能退多少钱。
这种时候，最好不要让大模型自己计算。
应该让业务系统按照实际退款规则算出金额，再由大模型告诉用户。
为什么？
因为大模型生成答案存在一定的不确定性。
它可以帮你解释退款规则，但涉及真实资金时，最终计算和校验应该交给确定性的业务程序。
所以，AI 产品经理需要建立一个意识：不是所有事情都交给 AI，才叫智能。
真正好的 Agent，应该知道什么时候让 AI 发挥作用，什么时候必须依靠业务系统。
简单来说：AI 负责听懂人话，业务系统负责把事情办对。
三、Agent 能调用工具，不代表它能安全地使用工具
现在做 Agent，有一个很常见的功能叫 Tool Calling，也就是工具调用。
简单理解，就是给 AI 配备一些可以使用的工具。
比如：
给它一个订单查询工具，它就能查询订单。
给它一个工单创建工具，它就能创建工单。
给它一个消息发送工具，它就能给用户发送通知。
这样，Agent 就不只是一个聊天机器人，而是真的可以帮用户做事情。
但这里有一个非常重要的问题：给 Agent 一个工具很简单，确保它不会乱用工具却很难。
举个例子。
我们给售后 Agent 配置了一个创建工单的工具。
用户说：“我的耳机坏了，帮我申请售后。”
Agent 调用工具，成功创建了一张工单。
看起来没有问题。
但如果出现下面这种情况呢？
Agent 调用创建工单接口时，网络突然卡住了。
虽然系统实际上已经创建成功，但 Agent 没有收到成功的回复。
于是，它认为刚才失败了，又调用一次。
结果系统创建了两张工单。
如果 Agent 继续重试，甚至可能创建三张、四张。
这显然不是我们想要的结果。
所以，工具调用必须提前设计好规则
我认为至少要考虑5个方面。
第一，明确每个工具到底能做什么。
比如，查询订单和修改订单，最好分成两个工具。
不要把所有功能混在一起。
这样更容易管理，也能减少误操作。
第二，调用工具之前，要检查信息是否完整。
比如创建售后工单，需要订单号、问题类型等信息。
如果用户没有提供订单号，就应该先询问。
不能让模型随便生成一个订单号去调用接口。
第三，明确什么情况下允许调用工具。
比如用户只是问：“如果我想退款，应该怎么操作？”
这只是咨询，不代表用户真的要申请退款。
Agent 不能直接发起退款。
第四，重要操作必须有确认机制。
比如退款、删除客户资料、修改订单、发送重要消息等。
这些操作可能造成实际影响。
所以需要根据风险程度，设置用户确认、权限校验或者人工审批。
第五，工具调用失败后，要有处理办法。
不能一失败就无限重试。
尤其是创建订单、退款、发送消息等操作。
如果接口超时，应该先检查之前的操作是否成功。
如果已经成功，就不要重复执行。
这里涉及一个技术概念，叫“幂等性”。
名字听起来有点复杂，其实很好理解。
同一个操作，即使重复请求，也不能产生不应该出现的重复结果。
比如同一笔退款申请，不能因为 Agent 调用了两次接口，就真的退两次钱。
这类问题，需要业务系统提供相应的防重复机制。
所以，Agent 产品经理不能只关心工具有没有接通。
更重要的是：工具在什么情况下可以使用、使用之前需要满足什么条件、使用失败后怎么办。
这些规则如果没有设计好，Agent 越能干，反而可能带来越大的风险。
四、Agent 的记忆，不是记住所有聊天记录，而是记住当前真正有用的信息
很多人在设计 Agent 记忆功能时，第一反应是：把用户之前说过的话全部保存下来。
下次对话时，再把这些聊天记录交给大模型。
这样，Agent 不就有记忆了吗？
这种方式确实能解决一些简单问题。
但如果聊天记录越来越多，就会出现麻烦。
首先，模型每次都要处理大量历史内容，Token 消耗会增加。
其次，聊天记录里可能有很多过时的信息。
模型有时会搞不清楚，到底应该以哪一次的信息为准。
举个旅游 Agent 的例子
假设用户正在让 Agent 帮忙制定旅游计划。
第一轮，用户说：“我想去日本玩7天，预算5000元。”
第二轮：“主要想去东京和大阪。”
第三轮：“预算还是改成8000元吧。”
第四轮：“算了，大阪不去了，就在东京玩。”
这时候，用户真正的需求已经变成：
去日本东京玩7天，预算8000元。
但是，如果 Agent 只是简单保存所有聊天记录，它看到的信息就会包括：
预算5000元、预算8000元、去东京和大阪、只去东京。
虽然大模型通常能够理解用户后面的修改，但对话越长，出现理解错误的可能性就越大。
更好的办法：给 Agent 准备一张任务信息表
比如：
{
"目的地": "东京",
"旅行天数": 7,
"预算": 8000,
"货币": "人民币",
"旅行方式": "自由行"
}
每当用户修改需求，系统就更新对应的信息。
比如用户说：“预算再增加2000元。”
系统就把预算从8000元更新成10000元。
用户说：“我想顺便去大阪玩两天。”
系统就更新目的地和行程安排。
这样，Agent 后续制定计划时，使用的是最新的任务信息。
而不是每次都重新翻看几十轮聊天记录。
Agent 的记忆可以分成三种
第一种：短期记忆。
就是记住用户最近聊了什么。
比如用户刚才问了退款政策，下一句说“那我这个订单呢？”
Agent 需要知道“这个订单”是在接着刚才的话题聊。
第二种：任务记忆。
就是记住当前任务进行到哪一步。
比如售后 Agent 已经获取了订单号，正在等待用户确认退款原因。
这时候，Agent 应该知道自己下一步要做什么。
第三种：长期记忆。
就是记住用户长期有效的偏好。
比如用户习惯使用中文，希望回答简洁一些，或者经常需要某种格式的报告。
当然，长期保存这些信息，需要考虑用户授权、隐私保护，以及用户修改和删除信息的需求。
这三种记忆的用途不一样，不能简单地全部混在一起。
Agent 的记忆能力，不是看它能保存多少聊天记录，而是看它能不能在需要的时候，准确找到当前有用的信息。
五、Agent 好不好用，不能靠感觉，必须拿数据说话
很多团队开发 Agent 时，测试方式比较简单。
产品经理自己问几个问题。
研发同学测试几个场景。
业务人员体验一下。
大家觉得回答挺自然、逻辑也不错，就认为可以上线了。
但这里有一个问题：Agent 回答得像那么回事，不代表它真的把事情做对了。
举个例子。
销售人员让 Agent：“帮我查询一下这个客户最近的3笔订单，再分析一下应该怎么跟进。”
Agent 很快生成了一段内容：“该客户近期采购比较活跃，建议重点推荐相关产品，并适当给予优惠。”
看起来很专业。
但如果仔细检查，就可能发现：它只查到了2笔订单。
其中一笔订单的金额还读取错了。
甚至有可能，订单查询接口根本没有成功，但 Agent 还是生成了一段看起来合理的分析。
如果只看最终回答，很容易认为 Agent 表现不错。
但从业务角度看，这个任务其实没有完成。
所以，评估 Agent，不能只看它会不会说
我认为至少要从两个方面判断。
第一个方面：事情有没有做对。
比如，用户让 Agent 创建售后工单，它到底有没有创建成功？
用户让它查询3笔订单，它有没有查全？
用户要求退款，它有没有按照实际业务规则处理？
生成的内容有没有编造数据？
这些都属于结果是否正确。
第二个方面：办事过程靠不靠谱。
比如，Agent 有没有调用正确的工具？
有没有重复调用接口？
工具失败后有没有正确处理？
有没有使用不该使用的权限？
执行一次任务花了多长时间？
消耗了多少 Token？
这些都属于执行过程是否可靠。
两个方面都要看。
因为 Agent 和普通聊天机器人不一样。
普通聊天机器人主要负责回答问题。
而 Agent 往往还要执行任务。
对于一个负责干活的 AI 来说，事情有没有办成，比话说得漂不漂亮更重要。
那应该怎么测试？
我的建议是，先准备一套测试题。
不用一开始就准备几千条。
可以先整理几十到上百个常见业务场景。
比如针对售后 Agent，除了正常情况，还要测试用户表达模糊、缺少订单号、接口调用失败、用户中途修改需求、用户要求越权操作等情况。
这样才能知道 Agent 遇到不同问题时，到底会怎么处理。
上线以后，还要持续观察实际使用情况。
例如：
任务完成率： 100个用户提出需求，最终有多少个成功完成？
问题识别准确率： 用户说的是退款问题，Agent 有没有正确识别？
工具调用成功率： Agent 调用系统接口时，有多少次成功？
人工接管率： 有多少问题 Agent 处理不了，需要人工介入？
平均处理时间： 完成一个任务需要多久？
任务处理成本： 每完成一个任务，需要花多少钱？
这里我尤其建议关注一个指标：成功完成一个任务，到底需要花多少钱。
为什么？
假设有两个 Agent。
Agent A，每处理一次任务花0.1元，但成功率只有50%。
Agent B，每处理一次任务花0.15元，但成功率有90%。
如果暂时只考虑模型调用成本，那么：
Agent A 平均成功完成一个任务，需要花费约0.2元。
Agent B 平均成功完成一个任务，需要花费约0.167元。
虽然 Agent B 单次调用更贵，但它完成一个有效任务的平均成本反而更低。
当然，实际业务中还需要考虑人工接管、系统资源和错误处理等成本。
这说明：不能只看 Agent 花了多少钱，还要看这些钱到底解决了多少问题。
没有数据指标，团队就只能不断修改 Prompt，然后凭感觉判断效果有没有变好。
这种优化方式，很难长期持续。
六、设计 Agent 时，不能只考虑成功，还要提前想好失败了怎么办
做过产品的人都知道，设计正常流程通常不难。
真正麻烦的是各种异常情况。
比如用户信息不完整、系统接口出错、网络超时、数据不准确等。
Agent 还会更加复杂。
因为大模型的输出并不是每次都完全一样。
即使用户提出相同的问题，在不同上下文或工具返回结果下，Agent 也可能采取不同的处理方式。
所以，设计 Agent 时，不能只考虑：用户提出需求 → Agent 理解需求 → 调用工具 → 返回结果。
还要考虑：如果其中任何一步出错，应该怎么办？
举个销售 Agent 的例子
假设我们开发了一个销售 Agent。
它每天自动查询客户信息，分析客户情况，然后通过企业微信提醒销售人员跟进客户。
正常流程很简单：查询客户资料 → 分析客户情况 → 生成跟进建议 → 发送消息。
但实际运行时，可能遇到很多问题。
情况一：客户资料查询失败。
这时候 Agent 应该怎么办？
正确做法是告诉用户当前无法获取完整数据，或者稍后重试。
而不是根据之前的聊天内容，编造一个客户分析结果。
情况二：生成的客户分析有错误。
比如 Agent 说：“该客户上个月购买了10万元产品。”
但实际系统里根本没有这笔交易。
这时候就需要通过数据核对、内容检查等方式降低错误风险。
对于重要内容，必要时还需要人工审核。
情况三：消息发送失败。
比如企业微信接口超时。
Agent 不能直接无限重试。
否则销售人员可能收到好几条相同的提醒。
应该先查询消息有没有发送成功，再决定是否重新发送。
情况四：Agent 一直重复调用工具。
比如它查询客户数据失败后，不停地重复查询。
如果没有限制，就可能一直运行下去。
不仅浪费 Token，还可能给业务系统带来额外压力。
所以需要设置最大调用次数和执行时间。
超过限制，就停止当前任务，并记录失败原因。
情况五：对话内容太多。
Agent 执行复杂任务时，可能需要经过很多轮推理和工具调用。
如果把所有过程都保留下来，Token 成本会不断增加。
这时候就需要压缩历史信息，只保留当前任务真正需要的内容。
产品经理应该怎么做？
我的建议是：在设计正常业务流程的同时，就把可能出现的异常情况整理出来。
比如每个关键环节，都要想清楚：
如果失败了，系统怎么发现？
能不能自动重试？
最多重试几次？
重复执行会不会产生问题？
失败后需要恢复之前的状态吗？
什么时候应该交给人工处理？
最后应该怎么告诉用户？
这些问题，最好在产品设计阶段就明确。
而不是等上线出了问题，再让研发临时想办法解决。
因为很多异常问题，不是简单修改几句 Prompt 就能解决的。
它们往往涉及系统设计、业务规则和权限控制。
一个成熟的 Agent，不是永远不会出错，而是即使出错，也知道应该怎么处理，不会让问题失去控制。
这也是 Agent Demo 和真正能上线的 Agent 之间，一个非常明显的区别。
七、做了 Agent 项目后，我对 AI 产品经理有了新的理解
以前提到 AI 产品经理，很多人首先想到的是：
会不会写 Prompt？
熟不熟悉 Dify、Coze？
会不会搭知识库？
懂不懂工作流？
会不会选择大模型？
这些能力当然重要。
但做的 Agent 项目越多，我越觉得：这些只是基础能力，真正重要的是能不能利用 AI 解决实际业务问题。
具体来说，我认为有5件事特别重要。
1. 判断一个业务场景，到底需不需要 Agent
不是所有业务都适合使用 Agent。
比如一个简单的计算器功能，本来几行代码就能解决。
如果非要让大模型参与，不仅增加成本，还可能引入错误。
所以，产品经理首先要判断：
这个场景是不是足够复杂？
是不是需要理解用户的自然语言？
是不是存在一些无法通过固定规则完全处理的情况？
使用 Agent 以后，能不能明显提高效率？
不要为了做 AI 而做 AI。
技术只是手段，解决问题才是目的。
2. 能不能把复杂需求拆成具体任务
业务方提出的需求，通常比较笼统。
比如：“我们想用 AI 提高售后效率。”
这句话其实没办法直接开发。
产品经理需要继续往下拆。
到底要提高哪个环节的效率？
是自动识别售后问题？
还是自动查询订单？
或者自动创建工单？
又或者自动处理退款？
每个任务需要什么信息？
执行哪些操作？
满足什么条件才能继续？
什么情况下需要人工处理？
只有把这些问题拆清楚，研发团队才能真正开始开发。
Agent 产品设计的核心能力之一，就是把模糊的业务需求，变成清楚、具体、能够执行的任务。
3. 能不能设计好 AI 和业务系统的分工
Agent 不应该是一个什么事情都自己决定的系统。
产品经理需要提前明确：
哪些事情交给大模型？
哪些事情由传统程序完成？
哪些数据需要实时查询？
哪些业务规则不能随意改变？
哪些操作需要人工确认？
就像管理一个团队。
每个人都有自己的职责。
合理分工，整个团队才能高效运转。
Agent 也是一样。
好的 Agent 产品，不是让 AI 包办一切，而是让 AI 和现有系统配合起来，把事情做好。
4. 能不能通过数据持续优化 Agent
Agent 上线以后，不代表项目就结束了。
相反，真正的优化才刚刚开始。
因为真实用户提出的问题，往往比测试阶段复杂得多。
这时候，产品经理需要通过日志和实际数据，找到问题出在哪里。
比如 Agent 经常回答错误。
到底是因为没有理解用户的问题？
还是知识库没有找到正确内容？
或者工具调用失败？
又或者业务流程本身就设计得不合理？
不同的问题，需要采用不同的解决方式。
不能一发现 Agent 出错，就想着修改 Prompt。
有时候，问题根本不在 Prompt 上。
5. 能不能算清楚 Agent 的业务价值
这一点非常重要。
因为企业最终关心的，不是 Agent 使用了多先进的模型，而是它到底带来了什么价值。
比如，一个售后团队每天要处理1000张工单。
原来每张工单平均需要人工处理5分钟。
现在上线了售后 Agent。
那么就需要观察：
有多少工单可以由 Agent 自动完成？
人工处理时间有没有下降？
错误处理的情况有没有增加？
客户满意度有没有受到影响？
Agent 每天的运行成本是多少？
如果算下来，Agent 确实能节省大量人工时间，同时保持较好的服务质量，那这个项目就是有价值的。
但如果上线以后，Agent 经常出错，人工还需要花大量时间检查和修改结果，那就不一定真的提高了效率。
所以：一个 Agent 项目有没有价值，不能只看它有多智能，还要看它到底帮业务省了多少时间、降低了多少成本、解决了多少实际问题。
最后：未来真正稀缺的，不是会搭 Agent 的人，而是能让 Agent 稳定干活的人
现在 AI 工具发展得很快。
以前开发一个 AI 应用，可能需要好几个研发人员忙上几周。
现在使用 Dify、Coze 等平台，可能几个小时就能做出一个原型。
这当然是一件好事。
因为做 AI 产品的门槛正在降低。
但这也意味着：以后，单纯会搭 Agent，可能不再是什么特别稀缺的能力。
真正有竞争力的，是那些既懂 AI，又懂业务，还知道怎么把 AI 真正用起来的人。
为什么？
因为工具虽然越来越简单，但真实业务并没有变简单。
订单规则还是很复杂。
不同系统之间还是有权限限制。
用户提出的需求还是可能模糊不清。
模型还是可能理解错误。
系统接口还是可能调用失败。
企业还是需要考虑成本、效率和实际收益。
这些问题，不会因为大模型越来越强，就自动消失。
所以，做了这些 Agent 项目以后，我越来越觉得：AI 产品经理真正重要的能力，不是让 Agent 看起来有多聪明，而是让它在实际业务中做事靠谱。
如果现在让我重新规划一个 Agent 项目，我不会一开始就急着研究多 Agent 架构，也不会马上设计一套特别复杂的工作流。
我会先想清楚几个问题：
第一，这个业务真的需要 Agent 吗？有没有更简单的解决方案？
第二，我们到底希望 Agent 帮用户完成什么任务？
第三，怎样才算任务成功？怎样算失败？
第四，哪些事情可以让 Agent 自动完成，哪些必须经过人工确认？
第五，如果 Agent 出错了，系统能不能及时发现并妥善处理？
第六，上线以后，我们怎么证明它比原来的工作方式更好？
这些问题想清楚以后，再去考虑模型选择、工具调用和工作流设计。
我认为，这才是比较合理的顺序。
先把一个具体场景做深、做稳，真正跑出效果，再考虑增加功能和设计更复杂的 Agent。
就像培养一个新员工。
先让他熟悉一项工作，能够独立、稳定地完成任务。
等他把这项工作做好了，再逐步交给他更多职责。
而不是第一天就要求他什么都会。
说到底，企业真正需要的，不是一个演示时看起来无所不能的 AI 助手。
而是一个能够融入日常工作、稳定完成任务、真正提高效率的 AI 系统。
会搭 Agent，只能说明你掌握了工具。
能让 Agent 稳定运行，说明你具备了产品设计和工程落地的能力。
能让 Agent 持续创造业务价值，才真正体现了 AI 产品经理的核心竞争力。
最后，我想用一句话总结：
Agent 做得好不好，不是看 Demo 演示时有多惊艳，而是看上线以后，有没有人愿意天天用、能不能稳定把事情办成，以及到底给业务带来了多少实实在在的价值。
评论区