做了几个 Agent 项目后，我发现：真正拉开 AI 产品经理差距的，不是技术

最近在做 Agent 项目的过程中，我越来越明显地感受到一个问题：现在搭一个 Agent Demo 真的不难，难的是让它真正进入业务流程，并且稳定运行。

用 Dify、Coze 这类平台，可能半天就能搭出一个看起来不错的 Agent。

接入大模型、配置知识库、添加几个工具，再设计一套工作流，一个能回答问题、查询数据、执行任务的 Agent 就出来了。

演示的时候，效果往往还不错。

但一旦真正放到业务环境里，各种问题就开始出现：

• 用户稍微换一种问法，Agent 就理解错了。
• 明明应该查询系统数据，Agent 却自己编了一个答案。
• 工具调用失败后，Agent 反复重试，最后卡死。
• 用户修改了需求，Agent 还按照之前的信息执行。
• 测试的时候效果很好，上线后准确率却明显下降。
• Token 消耗越来越高，但实际业务价值却没有明显提升。

这些问题，很多时候并不是模型能力不够，而是产品设计阶段就没有考虑清楚。

做 Agent 项目越多，越会发现：

Agent 能不能真正上线，关键不只是模型有多强，而是产品经理能不能把任务边界、业务流程、工具权限、异常处理和效果评估设计清楚。

下面结合实际项目中比较常见的问题，聊聊我认为 AI 产品经理必须掌握的 6 个核心能力。

一、不要一上来就做「万能 Agent」，先把一个场景跑通

这是我觉得很多团队最容易踩的第一个坑。

刚开始做 Agent 时，大家往往都比较兴奋。

业务方希望它能回答问题、查询数据、分析报表、生成内容，最好还能自动发消息、创建工单。

产品经理也希望第一版就做得足够智能，能够体现 Agent 的价值。

于是，一个原本简单的需求，慢慢变成了一个所谓的「全能 AI 助手」。

结果呢？

功能看起来很多，但真正能稳定使用的没几个。

举个售后 Agent 的例子。

假设我们要给一家电商企业做一个售后 Agent。

最开始，业务方可能提出这样的需求：希望 Agent 能够自动识别用户问题、查询订单、判断退款条件、处理退款、生成工单，甚至主动联系用户。

听起来是一条完整的业务链路。

但如果第一版就把这些能力全部做进去，复杂度会非常高。

因为每增加一个能力，就意味着增加一批需要处理的异常情况。

比如：

• 用户没有提供订单号怎么办？
• 一个用户有多个订单怎么办？
• 订单已经退款了怎么办？
• 用户要求退款，但订单不符合退款规则怎么办？
• 如果退款接口调用失败，又应该怎么办？

如果这些问题没有提前考虑，Agent 很容易在真实业务中出现各种不可控的行为。

我的经验：先做最小业务闭环

遇到这种场景，我更倾向于先把目标缩小。

第一阶段，不让 Agent 直接处理退款，而是先解决一个具体问题：

自动识别售后问题类型，并创建对应的售后工单。

整个流程可以设计成：

用户描述问题 → Agent 识别意图 → 提取关键信息 → 判断问题类型 → 创建工单 → 返回处理结果。

这里最重要的是提前明确四件事：

1. 用户输入什么？
2. Agent 需要完成哪些动作？
3. 最终应该输出什么？
4. 什么情况下算任务成功？

比如，用户说：「我昨天买的耳机，今天收到发现左边没声音，想换一个。」

Agent 需要识别：

• 问题类型：商品质量问题。
• 用户诉求：换货。
• 商品信息：耳机。
• 缺失信息：订单号。

接下来，Agent 应该引导用户补充订单号，而不是直接承诺换货成功。

等到订单信息补齐，再调用业务系统创建工单。

这样，一个完整且可验证的业务闭环就形成了。

后续再逐步增加自动查询订单、判断售后政策、推荐解决方案等能力。

我的一个体会是：Agent 第一版最重要的不是功能丰富，而是让一个高频任务真正跑通。

一个稳定解决具体问题的 Agent，往往比一个什么都能做、但什么都不稳定的 Agent 更有业务价值。

二、不要什么都交给大模型，先分清「模型做什么，系统做什么」

这是 Agent 产品设计里特别重要，但又很容易被忽略的一点。

很多人刚开始做 AI 产品时，会有一个误区：

既然大模型这么强，是不是所有事情都可以交给模型处理？

实际上并不是。

大模型擅长理解和推理，但不应该成为所有业务事实和规则的最终裁决者。

举个例子。

用户问：「我这个订单现在能退款吗？」

如果只是把问题交给模型，让模型根据知识库里的退款政策回答，就可能出现问题。

因为能不能退款，通常不只是理解退款政策这么简单。

还需要知道：

• 订单当前是什么状态？
• 是否已经发货？
• 是否超过退款期限？
• 商品是否属于特殊类目？
• 是否已经存在退款申请？

这些都是实时业务数据。

如果模型没有查询业务系统，而是直接根据经验回答，就存在很大的风险。

更合理的方案是什么？

我一般会把 Agent 的能力拆成两部分。

第一部分：模型负责理解和决策辅助。

比如：

• 识别用户是不是想退款。
• 判断用户描述的是质量问题还是物流问题。
• 从自然语言中提取订单号。
• 判断当前缺少哪些必要信息。

第二部分：业务系统负责事实查询和确定性执行。

比如：查询订单状态、计算退款金额、验证退款资格、检查用户权限、执行退款操作。

完整流程应该是：用户提出退款需求 → 模型识别退款意图 → 调用订单接口 → 系统返回订单状态 → 规则引擎判断退款条件 → Agent 组织回复。

这样设计的好处是：模型负责处理不确定的自然语言，业务系统负责处理确定的业务逻辑。

两者各自发挥优势。

还有一个特别典型的例子：金额计算。

假设订单金额是 999 元，优惠券抵扣 100 元，部分商品已经退款。

这时候需要计算实际可退金额。

我的建议是：不要让模型直接计算最终退款金额，而是交给业务系统计算，再由模型解释计算结果。

因为金额这种东西，不应该依赖模型的概率性输出。

AI 产品经理一定要明白：不是 AI 参与得越多，产品就越智能。真正成熟的 Agent 设计，是知道哪些地方应该使用 AI，哪些地方坚决不能只依赖 AI。

三、工具调用不是接上 API 就完事，真正难的是设计边界

很多 Agent 项目做到工具调用这一步，就觉得已经实现了智能体。

比如通过 Function Calling，让 Agent 可以查询订单、发送消息、创建工单。

但在实际项目里，我发现：工具能调用，和工具能安全、稳定地调用，完全是两回事。

举个例子。

我们给 Agent 配置了一个创建工单的工具：create_ticket

它可以根据用户问题自动生成售后工单。

看起来很简单。

但产品经理必须提前考虑几个问题：

• 什么情况下允许创建工单？
• 必须提供哪些参数？
• 如果用户信息不完整怎么办？
• 如果用户连续说了三次同样的问题，会不会创建三个重复工单？
• 如果接口超时，但实际上工单已经创建成功了怎么办？

这些问题如果没有设计清楚，上线后很容易出问题。

我一般会重点关注 5 件事

1. 工具用途必须明确

一个工具最好只负责一类清晰的业务动作。

比如查询订单和修改订单，尽量不要混在一个工具里。

2. 参数必须校验

订单号、用户 ID、工单类型等关键参数，不能完全依赖模型生成。

尤其是用户身份和权限信息，应该由系统侧提供或验证。

3. 调用条件必须明确

不能因为模型判断用户可能想退款，就直接执行退款。

应该先完成信息确认和规则校验。

4. 高风险操作必须有确认机制

退款、删除数据、发送对外消息、修改客户资料等操作，必须结合风险等级设计权限控制、二次确认或人工审批。

5. 工具失败必须有处理方案

比如接口超时，可以先查询操作状态，而不是直接重复执行。

这里还有一个特别容易被忽略的问题：幂等性。

假设 Agent 调用创建工单接口时超时了。

模型可能会认为调用失败，于是再次发起请求。

但实际上，第一次请求可能已经成功，只是响应没有及时返回。

如果没有幂等机制，就可能创建两张相同的工单。

所以在工具设计时，最好由业务系统通过业务唯一标识、幂等键等机制避免重复执行。

这类问题，单纯靠优化 Prompt 很难彻底解决。

真正可上线的 Agent，一定是模型能力和工程约束共同作用的结果。

四、Agent 的记忆不是保存聊天记录，而是管理任务状态

很多人在做 Agent 记忆功能时，最直接的方式就是：

把用户之前的聊天记录全部放进 Prompt。

这样模型就能知道用户之前说过什么。

这种方式在简单场景下确实能用。

但随着对话越来越长，问题也会越来越明显。

首先是 Token 成本不断上涨。

其次是历史信息可能相互冲突。

更麻烦的是，模型不一定知道哪些信息已经失效。

举一个很常见的场景

用户正在使用一个旅游规划 Agent。

第一轮：「我想去日本玩 7 天，预算 5000 元。」

第二轮：「主要想去东京和大阪。」

第三轮：「预算还是调整到 8000 元吧。」

第四轮：「算了，不去大阪了，只玩东京。」

如果只是简单保存历史对话，模型可能同时看到：

预算 5000 元。

预算 8000 元。

目的地东京和大阪。

目的地只有东京。

虽然模型有时能理解最新信息，但随着对话变长、任务变复杂，这种方式并不稳定。

更合理的做法：管理结构化任务状态

在这个场景里，我会考虑维护一份当前任务状态。

例如：

{
  "destination": ["东京"],
  "duration": 7,
  "budget": 8000,
  "currency": "CNY",
  "travel_type": "自由行"
}

每次用户提出修改，系统就更新对应字段。

这样 Agent 后续规划行程时，读取的是当前有效信息，而不是重新从几十轮聊天记录中寻找答案。

这里其实涉及 Agent 记忆的三个层次。

第一层：短期对话记忆。

主要用于理解当前几轮对话的上下文。

第二层：任务状态记忆。

记录当前任务已经完成到哪一步、收集了哪些信息、还有什么信息缺失。

第三层：长期用户记忆。

记录经过用户授权、确实有必要长期保留的偏好信息，例如常用语言、内容风格等。

这三种信息不应该混在一起处理。

尤其是长期记忆，还要考虑隐私、保存期限和用户修改或删除信息的能力。

我觉得 Agent 记忆设计最关键的一点是：不是让 Agent 记住所有事情，而是让它在正确的时候使用正确的信息。

五、没有评测体系，Agent 优化基本就是靠感觉

这个问题在实际项目中非常普遍。

很多团队评估 Agent 效果的方式是：

产品经理自己问几个问题。

研发同学测试几个 Case。

业务方体验一下。

大家觉得回答还不错，就准备上线。

但问题在于：

Agent 的效果不能只靠主观体验判断。

特别是涉及复杂工作流和工具调用时，回答看起来正确，不代表任务真的完成了。

举个例子。

用户让 Agent 查询一个客户的最近三笔订单，并生成销售跟进建议。

Agent 最后输出了一段非常流畅的分析。

看起来很专业。

但如果仔细检查，可能发现：

它只查询了两笔订单。

某笔订单金额读取错误。

客户最近一次购买时间不准确。

甚至工具调用失败后，它直接根据上下文编造了分析结果。

如果只评价最终回答是否自然、流畅，很容易把这类问题漏掉。

我通常会把评测分成两个层次

第一层：结果是否正确。

比如：

任务有没有完成？

意图识别是否准确？

关键信息有没有提取正确？

最终结果是否符合业务规则？

有没有编造不存在的数据？

第二层：执行过程是否可靠。

比如：

工具有没有调用成功？

工具调用顺序是否合理？

有没有重复调用？

失败后有没有正确处理？

有没有触发越权操作？

整个任务消耗了多少 Token？

响应时间是否符合要求？

这两层都很重要。

因为 Agent 和传统聊天机器人最大的区别之一，就是它不仅要回答，还要执行。

评测集应该怎么建？

我的建议是，不要一开始就追求几千条测试数据。

可以先从一个具体场景入手，整理几十到上百条具有代表性的测试用例，再持续扩充。

重点覆盖几类情况：

1. 正常问题：用户信息完整，业务流程正常。
2. 模糊问题：用户表达不清楚，需要补充信息。
3. 信息缺失：缺少订单号、客户 ID 等必要参数。
4. 工具异常：接口超时、返回空数据、服务不可用。
5. 高风险操作：退款、删除、越权查询等。
6. 多轮对话：用户中途修改需求，或前后信息冲突。

上线后，还需要持续关注真实业务数据。

比如售后 Agent，可以重点看：

任务完成率： 用户提出的问题，有多少最终完成了目标任务？

分类准确率： Agent 对售后问题的分类是否正确？

工具成功率： 工具调用有没有成功执行？

人工接管率： 有多少任务最终需要转人工？

平均响应时间： 用户完成一次任务需要等待多久？

单任务成本： 每完成一次有效任务，需要消耗多少模型和系统资源？

这里我特别建议关注一个指标：

单次成功任务成本。

因为有些 Agent 虽然 Token 成本很低，但任务完成率也很低。

还有些 Agent 虽然模型调用成本略高，但能够明显减少人工处理时间。

只看 Token 消耗，很容易做出错误判断。

更合理的方式，是把成本和任务完成效果结合起来分析。

没有评测体系，Agent 优化就是不断改 Prompt、不断试效果，最后很难证明到底有没有变好。

六、上线前一定要设计失败路径，而不是等出问题再补

做过真实业务系统的人应该都有体会：

正常流程通常不是最难设计的。

真正麻烦的是各种异常情况。

Agent 更是如此。

因为它本身就存在一定的不确定性。

同样的用户输入，在不同上下文、模型版本或工具返回结果下，可能产生不同的执行路径。

所以设计 Agent 时，不能只画一条理想流程：

用户输入 → 模型理解 → 调用工具 → 返回结果。

还必须考虑每个环节出错以后怎么办。

举个实际业务中很容易遇到的问题

假设我们做了一个销售 Agent。

它可以根据客户信息自动生成跟进建议，并通过企业微信给销售人员发送提醒。

正常流程很简单：

查询客户数据 → 分析客户情况 → 生成跟进建议 → 发送提醒。

但实际运行时，可能出现很多情况。

情况一：客户数据查询失败。

这时 Agent 应该明确提示数据获取失败，而不是根据不完整的信息生成看似准确的分析。

情况二：模型生成内容异常。

比如建议里出现了不存在的客户信息。

这种情况需要通过数据校验、内容约束等方式降低风险，必要时进入人工审核。

情况三：消息发送接口超时。

不能直接无限重试，否则可能给销售人员发送多条重复提醒。

应该先查询发送状态，再决定是否重试。

情况四：Agent 进入循环。

比如模型反复调用同一个查询工具，却始终无法得到需要的信息。

这时必须有最大调用次数、执行超时等限制。

情况五：上下文过长。

多轮执行后，历史信息越来越多，可能导致成本上涨甚至超出上下文窗口。

这时需要进行上下文压缩、历史信息裁剪，或者从结构化任务状态中恢复必要信息。

所以我现在设计 Agent，会特别关注一张表

也就是「异常场景处理表」。

至少要明确：

异常发生在哪个环节？

系统如何识别异常？

是否允许自动重试？

最多重试几次？

失败后是否需要回滚或补偿？

什么时候需要人工介入？

最终应该如何告知用户？

这些问题，应该在产品设计阶段就考虑，而不是等到上线后再交给研发临时处理。

一个成熟的 Agent，不是永远不出错，而是出现问题时，系统仍然能够保持可控。

这一点，也是 Demo 和生产级 Agent 之间非常明显的区别。

七、做 Agent 项目后，我对 AI 产品经理有了一个新的认识

以前做 AI 产品，大家可能更关注：

• Prompt 怎么写？
• 模型怎么选？
• 知识库怎么搭？
• 工作流怎么编排？
• Dify、Coze 怎么使用？

这些能力当然重要。

但随着 Agent 真正开始进入企业业务，我越来越觉得，这些更多是基础能力。

真正决定 Agent 能不能产生业务价值的，是另外一些问题。

比如：

第一，能不能找到真正值得做的场景。

不是所有业务都需要 Agent。

如果一个简单的规则引擎就能解决问题，就没必要为了使用 AI 而引入 AI。

第二，能不能把复杂业务拆成可执行的任务。

用户需求往往是模糊的。

产品经理需要把它拆成明确的输入、动作、条件、输出和异常分支。

第三，能不能设计好模型与业务系统的协作关系。

哪些步骤依赖模型？

哪些步骤依赖规则？

哪些数据必须实时查询？

哪些操作必须由人确认？

这些都需要提前设计。

第四，能不能建立持续优化的机制。

Agent 上线不是结束，而是开始。

需要通过日志、评测数据和真实用户反馈，不断定位问题。

到底是意图识别不准确？

知识库召回不好？

工具调用有问题？

还是业务流程本身设计得不合理？

不同问题，对应完全不同的优化方式。

不能遇到所有问题都只想着改 Prompt。

第五，能不能算清楚业务价值。

比如一个售后 Agent：

原来人工处理一张工单需要 5 分钟。

引入 Agent 后，有多少工单可以自动完成？

人工平均处理时间减少了多少？

错误处理率有没有上升？

系统运行成本是多少？

用户满意度有没有受到影响？

只有把这些数据算清楚，才能证明 Agent 对业务真正有价值。

否则，技术上再先进，也可能只是一个成本不低的演示项目。

最后：会搭 Agent 的人越来越多，但能让 Agent 稳定上线的人依然稀缺

现在 AI 开发工具越来越成熟。

以前需要开发几周的能力，现在通过低代码平台，可能几小时就能搭出一个原型。

这意味着，单纯会使用工具，未来很难成为 AI 产品经理的核心竞争力。

因为工具的门槛会越来越低。

但企业的真实业务不会因此变简单。

业务规则依然复杂。

系统之间依然存在数据和权限边界。

用户需求依然充满不确定性。

模型依然可能出错。

成本、效率和效果之间依然需要权衡。

真正有价值的 AI 产品经理，是能够把大模型的不确定性，装进一个相对确定、可控、可评估的业务流程里。

所以，如果现在让我重新规划一个 Agent 项目，我不会一上来就考虑多 Agent 架构，也不会急着设计复杂的工作流。

我会先问自己几个问题：

这个场景真的需要 Agent 吗？

它到底要替用户完成什么任务？

成功和失败的标准是什么？

哪些操作可以自动执行，哪些必须人工确认？

出现异常时，系统能不能安全退出？

上线后，怎么证明它比原来的流程更好？

只有这些问题都想清楚了，我才会开始考虑具体的技术方案。

先把一个场景做深、做稳、做出数据，再考虑复杂工作流和多 Agent。

这是我认为现阶段做企业级 Agent 产品，比较靠谱的一条路径。

毕竟，Agent 产品经理的核心竞争力，从来不是会不会搭 Agent，而是能不能让 Agent 真正解决业务问题。

而衡量一个 Agent 项目是否成功，也不应该只看 Demo 演示得有多惊艳。

真正的成功，是业务人员愿意每天使用它，系统能够稳定运行，并且最终能在效率、成本或业务结果上看到实实在在的改善。