做企业级 Agent 后我才发现：没有评估体系，Agent 永远只是 Demo

企业级工作流Agent的真相正在被颠覆——当所有产品都在标榜'一句话生成完美流程'时，我们却发现真正的难题在于如何判断这条自动生成的链路是否正确。从意图错配到参数偏差，从工具误用到合规风险，本文深度拆解工作流Agent最致命的6类错误，并提出8个关键验收指标，揭示Agent产品从Demo走向实用的核心分界线。

最近在做一个企业级工作流 Agent，目标很直接：用户说一句话，系统自动生成一条可执行的工作流。

听起来很像现在所有 Agent 产品都在讲的故事：

用户不需要懂流程、不需要懂配置、不需要懂工具，只要描述目标，Agent 自动拆解任务、选择工具、生成流程，最后帮你把事情做完。

但真正开始测试后，我发现问题并不是“能不能生成”。

更大的问题是：

生成出来之后，没人知道它到底算不算对。

用户说：帮我每天监控竞品舆情，并生成一份日报。

Agent 咔咔思考两下，迅速生成了一条丝滑的工作流：

抓取数据 → 情感分析 → 总结内容 → 发送通知

乍一看，它好像完成了任务。

但只要往下看，每一步都可能是错的。

• 可能数据源只用了网页搜索，没有覆盖小红书、微博、公众号（没有账号认证，没法绕过爬虫，直接自己编一段）
• 可能关键词配置过窄，真正的竞品内容根本没抓到（XX家等别名根本识别出来）
• 可能情感分析标准不清，把用户吐槽误判成中性内容（用户评价“产品真是个nc”，AI还认为是好评）
• 可能自动把报告发给其他人员，但没有任何人工确认（没和你确认权限，转手把日报发到有老板的大群）

一条工作流，四个步骤全烂了，每一步都在合格线以下，串起来把一坨包装精美的无效日报一键发给了老板。

这时我才意识到，Agent 产品最难的不是生成，而是验收。

一、传统 LLM 看答案，Agent 要看链路

以前做大模型应用，评估通常围绕回答质量展开：

但 Agent 不一样。

Agent 不只是回答问题，它会做一串动作：理解用户意图，拆解任务，选择工具，调用 API，读取数据，修改系统状态，生成结果，甚至触发后续动作。

也就是说任务链路正确，不是看它”跑没跑通”，而是看它”该不该这么跑”。具体拆开：意图拆没拆对、工具选没选对、参数配没配错、顺序合不合理、失败节点有没有人兜底。

这句话对企业级 Agent 很关键。

因为 Agent 一旦进入业务系统，它就不再是一个“会聊天的模型”，而是一个“会影响业务结果的执行系统”。

一条回答错了，用户骂一句。

一条链路错了，订单错了、权限错误开了、数据库改了、通知发出去了——而且可能没人发现。

所以，评估对象必须从：答案是否正确

升级为：任务链路是否正确。

二、工作流 Agent 最容易出现 6 种错

以“一句话生成工作流”为例，一个工作流看起来跑通了，但里面可能有很多隐藏错误。

1. 意图错

同样是“监控竞品舆情”，用户可能要的是：

• 每日固定时间简报；
• 实时监控并预警；
• 周期性的异常波动提醒；
• 一次性总结的老板汇报材料。

这些不是同一个工作流。

用户要的是每天九点躺进邮箱的日报，Agent 却当成了实时监控，风吹草动就推通知。数据源、分析颗粒度、输出格式、通知方式，全走岔了。意图识别这一步错了，后面所有节点都在为错误的理解打工。

2. 节点规划错

工作流里的节点可能多了，也可能少了。

少了关键节点，任务完成不了。

多了无关节点，流程变复杂，甚至引入风险。

用户要做舆情分析，合理流程应该包括：

数据采集 → 数据清洗 → 情感判断 → 主题聚类 → 风险分级 → 摘要生成 → 推送通知

但 Agent 可能只生成：

搜索网页 → 总结内容 → 发送邮件

表面上有流程，实际上缺了核心分析环节，最后生成的是一个看着正确但无法作用到生产的工作流。

多了无关节点呢？流程会变复杂，甚至引入风险。用户只是要查询知识库，Agent 却调用了外部搜索和爬虫。它不知道哪些动作该做，哪些动作不该做。

2. 参数错：流程跑通，结果跑偏

节点选对了，不代表事就做对了。

• 同一个“数据抓取”节点，抓哪些平台、用什么关键词、时间多长、怎么去重——参数不一样，抓回来的东西可能跟你要的完全无关。
• 同一个“情感分析”节点，判断标准偏一度、阈值调宽一档、人工复核关掉——负面的全判成中性，舆情监控等于白做。

参数错比节点错更可怕。节点选错一眼能看出来，参数配偏了，流程照跑，结果照出，一切看着正常——直到业务方拿着错误数据做了错误决策。

5. 工具错

用户要查企业内部数据，Agent 却调用了网页搜索。

• 用户要查 CRM，Agent 却调用了知识库。
• 用户要生成报表，Agent 却只做了文本总结。

AWS 文章里把 Tool 调用准确率列为 Agent 应用最基础的保障，并提到可以做细粒度检测，比如逐个工具调用对比、参数提取正确率对比；也可以做粗粒度检测，比如工具调用完成后，检查任务环境或数据状态是否一致。(Amazon Web Services, Inc.)

对工作流 Agent 来说，工具调用不是一个技术细节，而是产品质量的核心。

因为 Agent 最终能不能做事，取决于它有没有调用正确的工具，并且有没有用正确参数调用。

6. 合规错

这是重视数据安全的中国企业级场景里非常重要的一层。

工作流不只是“能不能跑”，还要看：

• 是否越权访问数据；
• 是否调用了高风险工具；
• 是否自动执行了本该人工确认的动作；
• 是否缺少日志和追溯；
• 是否对外发布内容但没有审核节点。

对工作流 Agent 来说，安全评估不能只看最后回答有没有敏感词，而要看整个流程里有没有高风险节点、越权工具、违规数据访问和缺失人工确认。

三、我现在会这样验收一个工作流 Agent

如果让我重新设计一个企业级工作流 Agent 的评估体系，我不会只看“任务成功率”。

我会往下面8 个指标的方向去拆解。

这套指标的意义是： 它把“Agent 好不好”拆成了可测试、可量化的问题。

当然，在具体的业务场景中，还要根据业务方自身需求、任务的特殊性，去定义哪些节点算“关键节点”、哪些错误算“致命错误”、什么程度算“可接受的偏差”。指标是框架，业务才是标尺。

四、Agent 产品经理的价值，不是写提示词，而是定义“什么叫做对”

以前我会觉得，Agent 做不好，是模型不够强。

现在我更倾向于认为：很多 Agent 做不好，是因为团队没有定义“什么叫做对”。

当一个 Agent 跑不通时，如果没有评估体系，团队讨论会变成这样：

• 产品说：体验不对，不像用户会用的东西，算法还需要再优化。
• 算法说：模型能力有限，不能保证完全正确，幻觉本身很难控制。
• 测试说：实际流程跑不通，很多地方都有问题。

每个人都对，但没有人能推进问题，因为大家没有共同的判断标准。

没有定义“什么叫做对”，就无法验收；

• 无法验收，就无法归因；
• 无法归因，就无法迭代；
• 无法迭代，Agent 就永远停留在 Demo。

真正的 Agent 产品经理，不只是把用户需求翻译成 Prompt，也不是只画一个工作流页面。

更重要的是建立这套判断系统：

意图怎么算错，拆解怎么算乱，节点怎么算多余，工具怎么算越界

什么时候必须拦，什么动作不准碰，什么失败能重来，什么失败立刻停。

这才是 Agent 从“会说”走向“会做”，从“Demo”走向“产品”的分界线。

只有能被评估的 Agent，才有可能被优化。

只有能被归因的失败，才有可能被产品化。

本文由 @朝闻道夕跑路 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议