我的 Agent 给一个用户从没提过的订单退了款:大模型"幻觉"出来的工具参数,我居然让它直接执行了

这是一个让我惊出一身冷汗、也彻底改变了我做 Agent 方式的事故。我做了一个客服 Agent,它有一项能力——可以调用一个"退款工具"给用户处理退款。一切看起来很智能:用户说"我要退款",Agent 理解意图、提取订单号、调用退款工具,搞定。可上线后,出了一桩怪事:一个用户只是来咨询退款政策、压根没说要退哪个订单,我的 Agent,却真的给他的某一个订单,退了款——而那个订单号,用户从头到尾,一个字都没提过。

这是一笔真实的、错误的资金操作。我紧急排查,把那次对话的完整日志和 Agent 的每一步决策都拉了出来,看到大模型生成的那个"退款工具调用"时,我后背一凉:大模型在调用退款工具时,需要一个"订单号"参数;可用户根本没提供订单号,于是大模型……自己"编"了一个!它凭空"幻觉(hallucinate)"出了一个看起来像模像样、实际上是它瞎编的订单号,填进了工具的参数里。而我的 Agent 框架,对大模型给出的这个参数,没有做任何核实,就直接、忠实地拿着这个编造的订单号,去执行了真实的退款操作。问题的根子,是我犯了一个做 Agent 的大忌:我无条件地、百分百地,信任了大模型生成的"工具调用参数",把一个"概率模型可能编造的东西",当成了"可以直接拿去执行真实操作的、可靠的指令"。

故障现场:一个被"幻觉"出来的订单号

我把出问题的 Agent 逻辑,简化一下。问题就藏在"拿到大模型给的参数,不加核实就执行"上:

# 我的客服 Agent(有致命缺陷的版本)
def handle_message(user_message, conversation):
    # 让大模型决定: 要不要调工具、调哪个、传什么参数
    response = llm.chat(messages=conversation, tools=[refund_tool])

    if response.tool_calls:
        for call in response.tool_calls:
            if call.name == "refund":
                # ✗ 致命: 直接拿大模型给的 order_id 去执行退款, 不做任何核实!
                order_id = call.arguments["order_id"]
                do_refund(order_id)   # 真实的退款操作!
                return f"已为订单 {order_id} 退款"

# 出事的对话:
#   用户: "你们的退款政策是怎样的呀?"  (只是咨询! 没说要退款, 更没给订单号)
#   大模型: 决定调用 refund 工具, 参数 order_id = "ORD20240312001"
#           ← 这个订单号是大模型【凭空编造】的! 用户根本没提过!
#   我的 Agent: 拿着这个编造的订单号, 直接执行了退款! 😱
#   → 给一个用户没要求退、甚至不一定属于他的订单, 退了款! 资损 + 严重事故!

看清这个流程,我对自己的疏忽懊悔不已。问题的核心,是我对"大模型生成的工具参数",抱有一种致命的、不加批判的信任。在我的设计里,大模型说"调用退款工具,订单号是 X",我的 Agent 就毫不犹豫地,拿着这个 X,去执行了真实的退款。可大模型,本质上是一个概率性的文本生成模型——它擅长理解和生成语言,但它并不保证它生成的每一个内容,都是真实的、准确的。它有一个众所周知的特性,叫"幻觉(hallucination)":在缺乏信息、或为了"让回答看起来完整"时,它会一本正经地、自信地,编造出一些看似合理、实则虚假的内容——可能是一个不存在的事实、一个虚构的引用,或者……一个它凭空捏造的订单号。在我那次的对话里,用户只是咨询、并没有提供订单号,可大模型在决定调用退款工具时,这个工具需要一个订单号参数——于是,它没有"老实地说我没有订单号",而是幻觉出了一个 ORD20240312001 填了进去。而我的 Agent,把这个"被幻觉出来的、虚假的参数",当成了"真实可靠的指令",直接拿去执行了——一个本不该发生的退款,就这样发生了。我的错误,不是大模型会幻觉(那是它的固有特性),而是我毫无防备地、无条件地信任了它可能幻觉出来的东西,并让它直接驱动了真实世界的操作。

第一件事:搞懂大模型"会幻觉",其输出不可全信

定位到根源,我必须把"大模型幻觉"这件事,以及它对做 Agent 的意义,彻底想透:大模型是一个基于概率的生成模型,它的核心目标,是"生成看起来最合理、最连贯的文本",而不是"生成绝对真实、绝对准确的内容"。这两者,大多数时候是一致的,但并不总是一致——当它们不一致时,大模型会优先选择"看起来合理",哪怕那是编造的。这就是"幻觉"。

大模型"幻觉"的本质, 以及它对 Agent 的致命影响:

大模型的本质: 一个"预测下一个最可能的词"的概率模型。
  它的目标: 生成"看起来最合理、最连贯"的文本。
  它【不保证】: 生成的内容"真实、准确"。
  → 当"合理"和"真实"冲突时, 它可能选"看起来合理"的编造。

幻觉(hallucination)的典型表现:
  - 编造不存在的事实、数据、引用
  - 在缺信息时, "脑补"出一个看似合理的答案(而非说"我不知道")
  - 在 Agent 场景: 编造工具调用的参数!(本文的坑)

为什么这对 Agent 尤其危险?
  - 普通对话: 它幻觉了, 顶多是"回答错了", 用户看看就过去了。
  - Agent: 它的输出, 会【驱动真实世界的操作】(退款、下单、删数据、发邮件)!
    → 一个被幻觉出来的参数, 会变成一个【真实的、错误的、可能不可逆的】操作!
    → "说错话"和"做错事", 是天壤之别! Agent 让大模型从"说"走向了"做"。

核心认知: 大模型的输出, 是"建议", 不是"确凿的事实/指令";
  尤其是要用它去驱动【真实操作】时, 必须先【核实】, 再执行。

原理终于清晰了。大模型,本质是一个"预测下一个最可能的词"的概率模型,它的目标是生成"看起来最合理、最连贯"的文本,而不保证内容的"真实准确"。当"看起来合理"和"事实真实"发生冲突时,它可能会选择前者——编造出一个看似合理、实则虚假的内容,这就是"幻觉"。在普通对话里,幻觉的代价,顶多是"它回答错了",用户看看、纠正一下就过去了。可在 Agent 场景里,大模型的输出,不再只是"说出来给人看的话",而是会驱动真实世界的操作——退款、下单、删数据、发邮件……于是,一个被幻觉出来的参数,就会变成一个真实的、错误的、甚至可能不可逆的操作!这是 Agent 把大模型,从"说"(生成文本)推向了"做"(执行操作)的领域——而"说错一句话"和"做错一件事",其后果有着天壤之别。我这次的事故,正是这个区别的血淋淋的体现:大模型"说"它要退款订单 X(幻觉),这本身只是个错误的"建议";可我的 Agent,把这个建议,直接变成了一个真实的"操作"。我从这次踩坑里学到的最根本的一课是:大模型的任何输出——尤其是用来驱动真实操作的工具调用参数——都应该被当成"一个需要核实的建议",而不是"一条可以直接执行的确凿指令";在让它驱动任何有真实后果的操作之前,必须先核实。

第二件事:正解——参数先"接地(grounding)"核实,高危操作要确认

搞懂了根因——"盲目信任大模型可能幻觉的参数,直接驱动真实操作"——正解就清晰了:大模型给出的工具参数,在拿去执行之前,必须先做"接地(grounding)"——用真实、可信的数据源去核实它是真的、有效的;而对于退款、删除这类"高危、不可逆"的操作,还要加上"人工确认"这道关。绝不能让一个未经核实的参数,直接驱动真实操作。

# 正解: 参数先核实(grounding) + 高危操作要确认
def handle_message_safe(user_message, conversation, user):
    response = llm.chat(messages=conversation, tools=[refund_tool])
    for call in response.tool_calls or []:
        if call.name == "refund":
            order_id = call.arguments["order_id"]

            # 核实1: 这个订单号, 在真实数据库里【存在】吗?
            order = db.get_order(order_id)
            if order is None:
                return "抱歉,我没有找到这个订单,请提供有效的订单号。"  # 编造的号会被这里拦下

            # 核实2: 这个订单, 真的【属于当前用户】吗?(防越权)
            if order.user_id != user.id:
                return "抱歉,这个订单不属于您。"  # 防止退了别人的订单

            # 核实3: 订单状态允许退款吗?(业务规则校验)
            if not order.can_refund():
                return "抱歉,这个订单当前不支持退款。"

            # 核实4(高危操作): 退款前, 必须让用户【明确确认】!
            if not user_explicitly_confirmed(conversation):
                return f"您确定要为订单 {order_id}(金额 {order.amount} 元)退款吗?请回复'确认'。"

            # 全部核实 + 确认通过, 才真正执行:
            do_refund(order_id)
            return f"已为订单 {order_id} 退款"

# 关键: 大模型只负责"提议"(我觉得该退订单X), 真正"是否执行", 由确定性的、
#   基于真实数据的代码 + 必要的人工确认 来把关。AI 提议, 代码核实, 人工确认。

这个正解的核心,是在"大模型提议"和"真实执行"之间,插入一道由确定性代码把守的"核实与确认"关卡。大模型说"退款订单 X",这只是它的提议;在这个提议变成真实操作之前,我的代码,会用真实可信的数据,去逐一核实它:核实1(存在性)——这个订单号,在数据库里真的存在吗?(一个被幻觉编造的订单号,大概率根本不存在,在这一步就会被拦下。)核实2(归属/权限)——这个订单,真的属于当前这个用户吗?(防止退了别人的订单,这是关键的越权防护。)核实3(业务规则)——这个订单的状态,允许退款吗?核实4(高危确认)——退款这种"涉及资金、且不可逆"的高危操作,在真正执行前,必须让用户明确地确认一次("您确定要退款订单 X 吗?")。这套机制,精髓在于一句话:"AI 提议,代码核实,人工确认"——大模型只负责'提议该做什么'(它擅长理解意图),而'是否真的执行、用什么参数执行',则由确定性的、基于真实数据的代码来把关,高危操作再加一道人工确认。这样,即使大模型幻觉出一个虚假的参数,它也会在'核实'这一关被拦下,绝不会直接酿成真实的错误操作。

下面这张图,对比了"盲目执行"和"核实后执行"两条路径:

这张图的对比很清楚:左边红色那条,盲目信任、直接拿大模型给的参数执行,一旦参数是幻觉编造的,就酿成真实资损;右边那条,先用真实数据核实参数(存在性、归属、状态)、再对高危操作做人工确认,把幻觉编造的参数稳稳拦在执行之前。两条路的根本分野,在于你有没有在"AI 提议"和"真实执行"之间,插入那道"核实与确认"的关卡。

第三件事:大模型幻觉,在 Agent 里还有别的"作案方式"

填平了"参数幻觉"这个坑,我警觉起来,系统排查了大模型的"不可靠",在 Agent 里还会以哪些方式造成问题。我发现,"幻觉"和"输出不可靠",绝不只是编造参数这一种:

大模型的"不可靠", 在 Agent 里的多种"作案方式":

# 作案1: 幻觉工具参数(本文) → 用真实数据 grounding 核实

# 作案2: 调用一个"不存在"的工具 / 用错工具
#   → 校验工具名; 工具描述写清楚, 减少误用

# 作案3: 输出的"JSON"格式不对(裹了```、多了解释、单引号)
#   → 容错解析 + 用模型的"JSON模式"/函数调用 + 解析失败让它重试

# 作案4: 幻觉出"工具的执行结果"
#   → 模型可能"假装"调用了工具并编造结果, 而非真的等工具返回
#   → 框架要确保: 工具结果来自"真实执行", 而非模型自己说的

# 作案5: 在 RAG 里, 检索到的内容不相关, 但模型"硬答", 编造
#   → 让模型"基于检索内容回答, 检索不到就说不知道", 并标注来源

# 作案6: 多步任务中, 中间某步幻觉, 错误"传染"到后续步骤
#   → 关键步骤做校验, 别让错误在 Agent 的长链条里累积放大

核心: 大模型是个"能力强、但不可靠"的组件;
  做 Agent, 本质是给这个"不可靠的智能", 套上一层
  "确定性的、可核实的"的约束与防护, 让它的能力可控、可靠地发挥。

这一排查,让我对"在 Agent 里如何对待大模型"有了全局的、清醒的认识。大模型的"不可靠",在 Agent 里会以多种方式"作案",远不止幻觉参数一种。作案2(用错/瞎编工具):要校验工具名、把工具描述写清楚。作案3(JSON 格式不对):大模型的"结构化输出"常常不规范(裹 markdown、加解释、用单引号),要容错解析、用模型的 JSON 模式、解析失败让它重试。作案4(幻觉工具结果)尤其阴险——模型可能"假装"调了工具、自己编了个结果,而非真的等工具返回;框架必须确保工具结果来自真实执行。作案5(RAG 硬编造):检索内容不相关时,要让模型"基于检索回答、检索不到就说不知道"。作案6(错误传染):多步任务中,中间一步的幻觉会"传染"到后续,关键步骤要校验。这些"作案方式"共同指向一个核心心法:大模型,是一个'能力强、但不可靠'的组件;而做 Agent,本质上,就是给这个'不可靠的强大智能',套上一层'确定性的、可核实的'约束与防护——用真实数据核实它的提议、用确定性代码把关它的执行、用人工确认守住它的高危操作——从而,让它强大的能力,得以'可控、可靠'地发挥,而不会因为它的'不可靠',酿成真实世界的事故。

第四件事:给 Agent 的工具,按"危险等级"分级设防

这次事故让我意识到,不是所有工具都该被同等对待。一个"查询天气"的工具,和一个"退款"的工具,危险等级天差地别。我据此设计了一套"按危险等级,分级设防"的工具治理策略:

给 Agent 的工具, 按"危险等级"分级设防:

# 等级1: 只读、无副作用 (查询类)
#   例: 查天气、查订单状态、搜索知识库
#   防护: 基本不用额外防护(查错了也没真实损害), grounding 可选
#   → 可以放心地让 Agent 自主调用

# 等级2: 有副作用、但可逆/低风险
#   例: 发一条提示消息、创建一个草稿、加入购物车
#   防护: 参数 grounding 核实; 出错能撤销/影响小
#   → 核实后可自动执行

# 等级3: 高风险、涉及资金/不可逆 (危险类)
#   例: 退款、下单付款、删除数据、发正式邮件、转账
#   防护: 参数严格 grounding + 权限校验 + 【必须人工确认】+ 操作日志/审计
#   → 绝不让 Agent "自主"执行, 必须有人(或强校验)在回路里

# 等级4: 极高风险 / 批量操作
#   例: 批量退款、批量删除、修改核心配置
#   防护: 在等级3基础上, 加"二次确认""金额/数量上限""灰度"等
#   → 甚至考虑: 这种操作, 到底该不该交给 Agent?

设计原则:
  - "权限最小化": 只给 Agent 它"完成任务必需"的工具, 别给多余的危险工具。
  - "危险操作, 人在回路(human-in-the-loop)": 越危险, 越要有人确认。
  - "一切可审计": 所有 Agent 触发的操作, 都要有日志, 能追溯、能复盘。

这套分级策略,让我对"给 Agent 配什么工具、怎么管"有了清晰的章法。它的核心思想,是"按危险等级,差异化设防"——不搞一刀切,而是让防护的强度,匹配操作的危险程度。等级1(只读查询):查错了也没真实损害,可以放心让 Agent 自主调用。等级2(可逆副作用):核实参数后可自动执行。等级3(高危/不可逆):退款、付款、删除这类,必须"参数严格核实 + 权限校验 + 人工确认 + 审计日志",绝不让 Agent "自主"执行——我这次的退款工具,正是等级3,却被我当等级1来用了。等级4(极高风险/批量):还要加二次确认、金额上限,甚至要反思"这种操作到底该不该交给 Agent"。而贯穿这套分级的三条设计原则尤其重要:"权限最小化"(只给 Agent 完成任务必需的工具,别给多余的危险工具)、"危险操作人在回路(human-in-the-loop)"(越危险越要有人确认)、"一切可审计"(所有 Agent 触发的操作都有日志可追溯)。这套'分级设防 + 人在回路 + 可审计'的治理,是让一个'能执行真实操作'的 Agent,变得安全可控的关键。把工具的危险分级和对应防护整理成一张表:

第五件事:理解 AI 的"能力"与"可靠性"是两回事

这次踩坑,让我在认知层面有了一次重要的升级——我开始清醒地区分 AI 的"能力"和"可靠性"这两个不同的维度。我把这个认知,沉淀成了做 AI 应用的几条根本原则:

做 AI 应用的根本认知: "能力强" ≠ "可靠"

  大模型: 能力(理解、生成、推理)非常强, 但可靠性(每次都对)不保证。
  这是两个【独立】的维度:
    - 能力: 它"能不能做到"(它确实很能)
    - 可靠: 它"是不是每次都对"(它不保证)

做 AI 应用, 要同时尊重这两点:
  1. 善用它的"能力": 把"理解意图、生成内容、灵活决策"这些它擅长的, 交给它。
  2. 不信它的"可靠": 凡是它的输出会导致"真实后果"的, 都要核实、要兜底。

具体落地:
  - AI 负责"软"的部分(理解、提议、生成); 确定性代码负责"硬"的部分(校验、执行、规则)
  - "AI 提议, 代码把关": 让 AI 的不可靠, 被代码的确定性接住。
  - 关键/危险环节, 保留"人在回路"。
  - 一切 AI 驱动的真实操作, 可审计、可回滚、有上限。

核心: 拥抱 AI 强大的能力, 同时, 清醒地为它的不可靠, 设计好防护;
  这, 才是当下做 AI 应用, 既能用上 AI、又不被 AI 坑的, 务实之道。

这层认知,是这次踩坑给我最宝贵的财富。它的核心,是清醒地区分 AI 的两个独立的维度:"能力"(它能不能做到)和"可靠性"(它是不是每次都对)。大模型的"能力"——理解、生成、推理——确实非常强;但它的"可靠性"——每一次输出都准确无误——是不保证的。把"能力强"误当成"可靠",正是我这次踩坑的认知根源。而做 AI 应用,要同时尊重这两点:一方面,要善用它强大的"能力"——把"理解意图、生成内容、灵活决策"这些它擅长的"软"工作,放心地交给它;另一方面,要不轻信它的"可靠性"——凡是它的输出会导致"真实后果"的地方,都要用确定性代码去核实、去兜底。落地的核心模式,就是"AI 提议,代码把关":让 AI 负责'软'的部分(理解、提议、生成),让确定性的代码负责'硬'的部分(校验、执行、规则),用代码的'确定性',去接住 AI 的'不可靠';再在关键、危险的环节,保留'人在回路';并让一切 AI 驱动的真实操作,可审计、可回滚、有上限。把"能力"和"可靠性"这两个维度,以及对应的态度,整理成一张表:

一张"Agent 该不该执行这个工具调用"的决策图

把这次踩坑沉淀成一张图。每当 Agent 要执行一个大模型提议的工具调用时,照着它走:

这张图的核心:只读查询可直接执行;有副作用的,先用真实数据核实参数(拦住幻觉);高危/不可逆的,核实后还必须人工确认,并记审计日志。把"AI 提议的工具调用,执行前先按危险等级核实与确认"变成 Agent 框架的铁律,那个"给没提过的订单退款"的坑就再也不会发生。

我立下的几条 Agent 安全规矩

这次"给用户没提过的订单退款"的事故后,我给自己立了几条规矩:

1. 大模型输出是建议不是指令:把大模型给的工具参数当成"待核实的建议",绝不直接拿去驱动真实操作。
2. 参数必做 grounding:工具参数执行前,用真实数据核实它(存在性、归属、状态、权限),拦住幻觉编造的值。
3. 高危操作人在回路:退款、删除、付款等高危/不可逆操作,必须有明确的人工确认,绝不让 Agent 自主执行。
4. 工具按危险分级设防:只读放心调、可逆核实后调、高危必确认,防护强度匹配危险等级。
5. 权限最小化:只给 Agent 完成任务必需的工具,别给多余的危险工具。
6. 一切可审计可回滚:Agent 触发的所有真实操作都记日志、可追溯,关键操作可回滚、有上限。
7. 分清能力与可靠:善用大模型的能力,但不轻信它的可靠性,用确定性代码接住它的不可靠。

这几条里,第一条和第二条是直接根治这次 bug 的核心。而贯穿所有规矩的那条主线,是对"信任"的审慎。我这次酿成事故,根子上是我"过度信任"了大模型——我把一个'能力强、但不可靠'的概率模型,当成了一个'值得无条件信任、可以直接驱动真实操作'的可靠组件。而'信任',尤其是'要不要把'真实操作的执行权'交给一个东西'这种信任,是需要极其审慎的。我们对一个组件的信任程度,应该匹配它的'可靠程度'以及'出错的后果':对一个可靠的、出错后果小的东西,可以多一些信任、少一些核实;而对一个不那么可靠的(如大模型)、或出错后果严重的(如退款),则必须少一些盲目信任、多一些核实与防护。我这次的错误,正是给了一个'不够可靠、且驱动着高后果操作'的组件,以'与它实际可靠性不匹配的、过度的信任'。把信任的程度,和被信任者的可靠性、以及后果的严重性,审慎地匹配起来——这是和一切'不完全可靠'的组件(尤其是 AI)打交道时,一条根本的安全准则。

写在最后:越强大、越不可全信的力量,越需要约束

这次被大模型幻觉教育的经历,给我一个在 AI 时代尤其重要的启示:我们正在拥抱一种前所未有地强大、却又并非完全可靠的力量——大模型;而拥抱它的正确姿势,绝不是'无条件地信任它、放手让它去做一切',而是'一边充分地借用它的强大能力,一边清醒地为它的不可靠,设计好严密的约束与防护'。能力越强、且越不可全信的力量,就越需要被恰当地约束——因为它的强大,意味着它一旦出错,造成的破坏也越大;而它的不可全信,意味着它出错的可能,是真实存在的。大模型,正是这样一种力量:它强大到能理解我们的意图、能自主地决策和行动;可它又不可全信,会一本正经地幻觉、会犯我们意想不到的错。我这次的事故,正是因为我只看到了它的'强大'(能自动处理退款)、却忽视了它的'不可全信'(会编造订单号),给了它一份与它可靠性不匹配的、不受约束的信任和权力。

想通这一点,我对"如何驾驭强大而不可全信的力量"这件事,有了更深的敬畏。这其实是一个古老的智慧,在 AI 时代的新演绎:任何强大的力量——无论是一项强大的技术、一个强大的工具、还是一份强大的权力——都需要被'约束'与'制衡',才能安全地、为善地发挥作用;而越是强大、越是可能出错的力量,这种约束就越不可或缺。我们给 Agent 的危险工具设人工确认、设权限、设审计,本质上,和人类社会给强大的权力设制衡、设监督、设问责,是同一种智慧——都是认识到'强大 + 不完全可靠/可信 = 潜在的巨大风险',从而主动地,用一套'确定性的、可核查的'机制,去约束它、去接住它可能的'出错'。对一种强大力量的恰当约束,不是对它的'不信任'或'限制其发挥',恰恰相反,是让它得以'被安心地、放心地使用'的前提——正因为有了核实、确认、审计这些约束,我们才敢把'处理退款'这样的真实任务,交给一个会幻觉的大模型。

所以,如果你也在这个 AI 时代,构建着各种由 AI 驱动的应用,我想把这次踩坑最想说的话送给你:请用一种'既充分借用、又清醒约束'的姿态,去拥抱大模型这种强大而不可全信的力量。充分地、大胆地,去借用它在理解、生成、决策上的强大能力;但同时,清醒地、严密地,为它的不可靠,设计好那一道道'核实、确认、审计、回滚、人在回路'的约束与防护。因为大模型,是一种我们前所未有的、强大的'智能',但它还远不是一种我们可以'无条件信任'的智能;而在它的强大与它的不可靠之间,找到那个'既用足其能、又约束其险'的平衡点,正是当下我们构建可靠 AI 应用,最核心、也最考验智慧的功课。那个给陌生订单退了款的 Agent,最终教给我的,正是这份对'强大而不可全信之力'的敬畏与驾驭之道——它让我懂得,真正用好 AI,不是天真地把一切都交给它、信任它,而是在尽情借用它强大能力的同时,始终为它的不可靠,保留一份清醒的警惕、和一套严密的约束;唯有如此,我们才能既乘上 AI 这股强大的东风,又不被它可能的'失控',掀翻了船。

—— 别看了 · 2026