假设现在是周一上午十点。

客服系统进来一张工单，用户只写了一句话：

昨天买的套餐用不了，给我退了。

如果只是做 Demo，这个场景很好处理。

让 Agent 判断情绪、查询退款政策，再生成一段客气的回复。屏幕上很快出现一套完整答案，看起来效率挺高。

可真要上线，第一步就卡住了。

用户买的是哪个套餐？名下有没有多笔订单？“用不了”是配置问题、账号问题，还是产品本身异常？最关键的是，他到底符不符合退款条件？

这些信息没有确认之前，Agent 写得越快，我反而越不放心。

能生成回复，不代表能处理工单

很多人第一次看 Agent，会把注意力放在最终答案上。

回复是否自然，语气是否像真人，有没有准确引用规则。

这些确实重要，但只是最后一层。

一张退款工单真正的处理过程，应该是先识别用户，再找到对应订单，判断故障原因，查询当前有效的退款规则，最后决定是排查问题、生成回复，还是提交退款申请。

Agent 的价值，就在于它可以根据中间结果调整下一步。

发现用户有三笔订单，就先确认具体订单；发现套餐其实没有故障，就转入使用排查；发现符合退款条件，才继续申请退款。

它不是按照固定话术一路念下去，而是在任务中不断做判断。

麻烦也出在这里：判断越多，出错的机会就越多。

第一个坑：用户没说清楚，Agent 却替他补全了

人有一种很自然的习惯，会根据上下文补全缺失信息。

模型更擅长这件事。

在写文章时，这种能力很好用；放到业务操作里，就得小心了。

如果用户没有说明订单，Agent 不能因为最近一笔订单“看起来最像”就直接操作。它可以查询候选订单，也可以追问，但不能把概率最高的那个当成已经确认的事实。

我后来给这类任务定了一条很朴素的规则：

能补全表达，不要补全事实。

比如，Agent 可以把用户零散的描述整理成一段清楚的故障说明。但订单号、退款金额、客户身份和执行对象，只要没有可靠来源，就必须停下来确认。

这一点看起来保守，实际能挡住不少事故。

第二个坑：查询失败，被它理解成什么都没有

假设 Agent 已经拿到用户身份，开始查询订单。

接口等了十秒，没有返回。

Demo 程序为了简单，可能直接给模型一个空列表。Agent 很容易继续往下走，告诉用户：“系统中没有查询到相关订单。”

听着没毛病，对吧？

可“没有订单”和“这次没查到订单”，根本不是一回事。

工具返回结果时，至少应该讲清楚：

• 请求成功，有订单；

• 请求成功，确实没有订单；

• 请求超时；

• 用户没有查询权限；

• 参数缺失；

• 服务暂时不可用。

如果这些状态全挤在一个空值里，Agent 就只能猜。

生产环境里，最危险的往往不是明显的胡说八道，而是这种建立在错误前提上的正常表达。它逻辑完整，语气也稳，用户很难第一时间意识到系统其实出了故障。

第三个坑：搜到了规定，不等于找到了当前规定

订单查到了，接下来要判断能不能退。

Agent 去知识库搜索“退款政策”，很快拿回来一段内容。问题是，这段内容可能来自半年前的培训材料，也可能只适用于某类套餐。

知识检索最容易制造一种错觉：只要搜到了文字，就像有了依据。

其实还差得远。

至少要确认文档什么时候生效、适用于哪种产品、有没有更新版本，以及这名员工是否有权查看。两份规定互相冲突时，也不能让模型凭语气判断哪份更可靠。

我见过有人把知识库检索做得很花哨，相似度、重排、摘要都有，可最终结果里没有生效时间。

那就像在一抽屉合同里准确找出关键词，却不知道哪份已经作废。找得再准，也不敢直接用。

真退款这一步，我不会让模型自己拍板

假设所有信息都核验完成，用户也确实符合退款条件。

Agent 可以生成一份回复草稿，也可以准备退款申请。至于最终提交，我会让它停一下。

不是不相信模型，而是不同动作的风险差得太多。

生成一份草稿，错了还可以改；给工单加一个标签，通常也容易撤销；真正发起退款，涉及金额和账户变化，就不能只看模型判断。

我一般会把能力一点点开放：

先让它查资料，再让它生成建议；稳定一段时间后，可以开放低风险操作；碰到退款、付款、删除、发信和权限修改，还是要保留程序校验或人工确认。

模型可以说“建议退款”，但执行层还要检查订单、金额、退款次数和审批条件。

这不是重复劳动，而是把责任放回确定性的系统里。

如果它做到一半断了，第二次会不会再退一遍

这也是 Demo 里很少出现、生产环境里迟早会遇到的问题。

Agent 已经提交退款申请，准备更新工单时网络断开。用户刷新页面，又说了一遍“帮我处理”。

它会从头开始吗？

如果系统只保存聊天记录，Agent可能知道双方聊过退款，却不一定知道退款申请有没有真正提交成功。于是它可能再调一次接口。

所以，长任务一定要有独立状态。

系统要记得当前走到哪一步，哪些工具调用成功了，哪些动作还在等待确认。写操作还要带唯一请求标识，哪怕同一个请求被发了两遍，业务系统也只处理一次。

聊天记录是给模型看的，任务状态是给系统用的。两者混在一起，早晚会出问题。

做企业 Agent，我最关心的不是它有多聪明

一套工单 Agent 上线前，我会故意折腾它。

不给订单号，看它会不会瞎选；把接口弄超时，看它会不会下结论；放两条新旧政策，看它会不会偷懒只用第一条；任务执行到一半强制中断，再看它恢复后会不会重复操作。

我还会模拟越权请求。比如普通客服要求查询不属于自己的客户，看看 Agent 是听用户的，还是服从真实权限。

最后才是那些常规指标：任务完成率、人工通过率、平均耗时、调用成本。

因为答案写错了，我们还能修改。权限失控、重复写入和错误退款，处理起来就不是改一句话了。

第一个 Agent 场景，不妨选得小一点

企业第一次做 Agent，很容易定一个大目标：做一名覆盖客服、销售、运营和财务的智能员工。

听起来很完整，真正拆需求时，每个部门的权限、数据和验收方法都不一样，很快就会搅在一起。

我更愿意从一张工单开始。

先把用户识别、订单查询、规则检索、回复草拟和人工确认这几个节点做稳。之后再复用已经验证过的工具和权限机制，扩展到其他任务。

会议纪要、线索整理、制度问答、合同信息抽取，也都适合当起点。它们高频、结果能检查，而且可以先停在“给建议”这一步。

至于一个连团队自己都讲不清的流程，先别急着塞进 Agent。人都没有统一标准，模型只会把原来的混乱执行得更快。

Agent 到底什么时候才算能上线

不是它成功跑完十个测试用例的时候。

我觉得至少要等它证明三件事：

第一，正常情况下能把事情办完；第二，异常情况下不会装作一切正常；第三，涉及高风险动作时知道停下来确认。

它还得留下足够清楚的执行记录。出了问题，我们能看到它查了什么、依据了什么、哪个接口失败，以及最终是谁确认执行的。

做到这一步，Agent 才不只是一个演示效果不错的模型外壳。

它开始像一名刚加入团队的同事：可以处理明确任务，也接受权限限制；遇到拿不准的事情，会回来问一句，而不是自己把空白补上。

Demo 证明的是，它偶尔能把任务做完。

生产环境需要证明的是，哪怕事情没有按剧本发展，它也不会把一个小误判变成真正的业务事故。

常见问题

AI Agent 和普通工作流有什么区别？

工作流通常按预设路径执行，Agent 会根据当前信息选择下一步。实际落地时，两者经常一起使用：Agent 负责判断，工作流负责控制关键节点。

Agent 一定要有长期记忆吗？

不一定。很多业务任务只需要保存当前会话和执行状态。长期记忆只适合存经过确认的稳定偏好，不能默认把所有对话都记下来。

Agent 能直接连接数据库吗？

技术上可以，生产环境却不建议开放任意查询。更稳妥的方式是把查询封装成具体业务工具，再由程序检查权限和参数。

哪些动作应该人工确认？

退款、付款、删除数据、对外发送以及修改权限等高风险动作，通常都要经过人工审批或确定性规则校验。

怎么判断 Agent 不是 Demo 了？

看它能不能处理信息缺失、接口失败、权限不足和任务中断。正常路径能完成，异常路径能停住，关键动作能追溯，才算具备基本的生产条件。