计划赶不上变化

前面五篇文章讨论的问题都有相对明确的对策——幻觉可以加 RAG，工具错误可以强 Schema，崩溃可以做检查点，协调可以共享状态，治理可以定规则。但有一个问题是本质性的：未来不可预测，而智能体必须做决策。

这就是规划失效问题：智能体基于当前信息制定了完美的执行计划，但执行过程中环境变了、信息更新了、前提不成立了——计划从"最优解"变成了"最蠢路径"。

这不是 AI 的特殊问题，是人类也在天天面对的。区别在于人类有丰富的经验来应对不确定性，而智能体的"经验"只有训练数据和当前上下文。

不确定性的三个来源

来源一：环境动态性

外部环境在 Agent 执行任务期间发生了变化。

典型场景

Agent 计划：查库存 → 下单 → 发货
现实发生：查库存时有货 → 下单时库存已变（另一位客户买了）→ 发货失败

动态环境中的"信息时效性"问题：

• 查询时信息准确 ≠ 行动时信息准确
• 信息和行动之间的时间差越大，规划越可能失效
• 有些环境变化不可预测（突发需求、系统故障、外部政策调整）

特殊难点：Agent 自身改变了环境

Agent 的行动可能改变了它所处环境的条件，导致后续计划的前提不再成立：

Agent 分析了市场数据 → 基于分析推荐了 A 股票
→ 1000 个用户跟随买入 → A 股价被推高
→ Agent 原有的"低估"判断不再成立

这就是反身性（Reflexivity）——观察行为本身改变了被观察对象。 Soros 讲了几十年的金融哲学，在 Agent 时代以新形态重现。

来源二：信息不完备性

Agent 做决策时所依据的信息不完整。

已知的不确定 vs 不确定的不确定

• 已知的不确定：Agent 知道自己不知道什么。比如"我不知道今天的库存量，需要先查询"
• 不确定的不确定：Agent 不知道自己不知道什么。比如 Agent 以为自己了解退货政策，但政策上周刚改了，它不知道

后者更危险——Agent 在错误的前提下做出自信的决策，和幻觉类似但根源不同：幻觉是模型编造事实，信息不完备是真实事实缺失但 Agent 假装拥有。

隐性约束

很多约束没有写在文档里，是行业惯例或组织内部的不成文规则：

智能体的"半途而废"之痛

写代码的人都知道——程序崩溃不可怕，可怕的是崩溃后状态全丢，只能从头再来。

智能体面临的就是这个问题。一个 20 步的自动化任务，执行到第 15 步时 LLM API 超时了，所有中间状态消失。下次运行从第 1 步重新开始，前面的 14 步白做了。如果有副作用（已经发了一封邮件、已经创建了一条数据库记录），那就更麻烦——重做会导致重复操作。

Temporal 的技术博客 2026 年 4 月发表了一篇引起广泛共鸣的文章，核心观点是：AI 可靠性是一个十年前就该解决、现在仍然只解决了一半的问题。我们应该用基础设施手段而非更好模型来解决它。

为什么智能体会中途崩溃？

原因一：LLM 推理本身就是不稳定的

传统软件的执行路径是确定性的——给定相同输入，永远走同一条路。LLM 不是。每一次推理都是一次概率采样，天生带有不确定性：

• API 超时：模型推理慢时，HTTP 请求可能超时中断
• Token 限制：上下文窗口满了，前面的轮次被截断
• Rate Limit：API 调用频率受限，被 429 返回
• 服务降级：高峰期模型响应质量下降
• 随机中断：GPU 集群节点切换、负载均衡导致连接中断

这些问题不是偶尔发生的，在大规模生产环境中是常态。

原因二：智能体状态是"内存态"的

大多数 Agent 框架把执行状态存在内存中：

# 典型的 Agent 循环
state = initial_state
for step in plan:
    state = llm_call(step, state)  # state 在内存
    state = tool_call(step, state)  # 一旦进程挂了，state 全丢

传统软件有数据库保驾护航——应用挂了重启后数据还在。Agent 框架呢？进程一死，所有中间推理、工具返回、上下文积累全部消失。

原因三：长链路任务的脆弱性

智能体任务越复杂，包含的步骤越多，执行成功率呈指数下降：

单步成功率 95%
10 步任务成功率: 0.95^10 = 59.9%
20 步任务成功率: 0.95^20 = 35.8%
50 步任务成功率: 0.95^50 = 7.7%

即使每步有 95% 的成功率（这已经是优秀的表现），一个 20 步任务就有近 2/3 的概率在某步失败。而大多数真实业务场景不止 20 步。

一个人干不了所有活

单个智能体再强，也有能力边界。它不可能同时是代码专家、财务分析师、法律顾问和设计师。于是多 Agent 协作成为自然选择——让不同专长的 Agent 各司其职，协同完成复杂任务。

听起来很美好，实战中却是一地鸡毛。

Medium 上有一篇被广泛引用的文章，标题就很直白：《Multi-Agent AI 的黑暗心理学：30 种能摧毁你整个系统的失败模式》。30 种可能是夸张了，但核心观点不虚——多 Agent 系统的复杂度不是线性增长，而是指数增长。2 个 Agent 的协调问题比 1 个 Agent 多不止一倍。

三种协作架构

先理清多 Agent 协作有哪几种模式，再分析各自的问题。

模式一：Orchestrator-Worker（中心调度）

一个"主管" Agent 负责理解任务、分解子任务、分派给专业 Worker Agent，最后汇总结果。

[Orchestrator] → 分派 → [代码 Agent]
              → 分派 → [财务 Agent]
              → 分派 → [设计 Agent]
              ← 汇总 ← 各 Agent 结果

优点：逻辑清晰、责任划分明确 缺点：Orchestrator 成为单点瓶颈——它既要理解全局，又要管理分发，还要处理冲突

模式二：Pipeline（流水线）

Agent 按照固定顺序串联执行，前一个的输出是后一个的输入。

[需求分析 Agent] → [设计 Agent] → [编码 Agent] → [测试 Agent] → [部署 Agent]

优点：简单、可预测 缺点：无反馈回路——如果测试 Agent 发现问题需要返回设计阶段，流水线很难回溯

当智能体的"手"不听使唤

如果说幻觉是智能体"脑子"的问题，那工具调用失败就是"手脚"的问题。智能体不仅要思考，还要行动——调用 API、查询数据库、操作文件系统。而但凡涉及外部系统交互，失败的维度比纯文本幻觉要多得多。

Arize AI 2026 年对生产环境智能体的故障分析指出：工具相关失败占 Agent 异常的 40% 以上，其中最危险的不是"调用失败"本身，而是失败后的错误处理——智能体对错误的理解和处理能力，往往比工具调用本身更不可靠。

三大失败模式

模式一：静默错误——最危险的失败

工具返回了错误信息，但智能体没有正确解读，把错误响应当做正常结果继续推理。

典型场景

// 智能体调用天气 API
{"tool": "get_weather", "arguments": {"city": "北京", "date": "2026-07-01"}}

// API 返回错误
{"error": "city_not_found", "message": "City name must be in English: Beijing"}

// 智能体把 json 当成了天气数据继续推理
"根据返回的数据，北京7月1日的湿度和 error 字段显示..."

这比调用直接报错更危险——至少报错时智能体知道出错了，还能重试。静默错误时，智能体浑然不知，把垃圾数据当成金子继续加工。

为什么会发生？

1. 错误格式不统一：不同 API 的错误响应结构不同（HTTP 状态码、JSON error 字段、HTML 错误页……），智能体难以用统一逻辑识别
2. Prompt 缺少错误处理指令：很多人在 system prompt 里只写了"使用 XX 工具查询"，没写"如果工具返回错误，你应该……"
3. 模型倾向"继续完成任务"：遇到异常数据时，模型的训练倾向是给用户一个答案，而不是停下来讨论 API 报错

模式二：参数构造错误——最常见的失败

智能体理解了要调什么工具，但构造参数时出错。

常见错误类型

• 格式错误：日期传 2026/07/01 而 API 要 2026-07-01
• 类型错误：传字符串 "5" 而 API 要整数 5
• 枚举错误：传 "medium" 而有效值只有 ["low", "mid", "high"]
• 遗漏必填参数：忘了传 currency 字段
• 语义错误：传了合法格式但语义不对，比如把 page_size=100 传给了限制最大 50 的分页接口

根因分析

模型对 API 的理解来自 prompt 中的工具描述（Function Schema）。如果描述不够精确——比如某个参数的合法值只写了 string 没有枚举——模型就只能"猜"。

幻觉：智能体最顽固的问题

如果只能用一个词概括当前 AI 智能体最致命的问题，行业里多数人会选"幻觉"（Hallucination）。通用大模型写诗写周报文采斐然，但让它分析"上季度 A 产品线毛利率下降的原因"，它可能编造一串子虚乌有的数据，还附上看起来很专业的百分比。更糟糕的是——语气越自信，越难被非专业用户识破。

Fiddler AI 2026 年的报告给出了一个残酷的数字：生产环境智能体失败率 70%-95%，幻觉是头号杀手。BetterYeah 的调研发现，68% 的企业在 AI 落地中遭遇幻觉问题，其中 32% 因错误累积导致系统性风险。

这不是"模型还不够聪明"的问题。这是智能体的结构性挑战。

从单步错误到幻觉累加

单步幻觉：模型不确定时仍"自信输出"

LLM 的核心训练目标是"合理续写"，而不是"如实回答"。当训练数据中缺少相关信息时，模型不会说"我不知道"——它会生成一段看起来连贯但实际上没有事实支撑的文字。

这是因为：

1. 训练数据偏差：互联网文本中，自信断言远多于谦虚声明"我不确定"
2. 采样机制：模型采样概率最高的 token 序列，不受事实约束
3. 缺乏不确定性建模：模型内部没有显式的"置信度"信号传递给输出层

结果：模型在信息不足时的行为是"编造"，而非"沉默"。

多步累加：小偏差滚雪球

当智能体执行多步任务时，单步幻觉的破坏力被指数放大。看一个典型场景：

步骤 1：检索客户信息 → 幻觉：编造了不存在的客户 ID
步骤 2：用该 ID 查询订单 → 返回空结果
步骤 3：智能体"推断"该客户是新客户 → 编造注册时间
步骤 4：基于虚假注册时间做客户画像分析 → 输出错误结论
步骤 5：基于错误结论撰写运营建议 → 决策偏离

每一步都"合乎逻辑"，但起点就是一个虚构的事实。这就是幻觉累加效应——错误在推理链中不断传播和放大，最终输出和现实南辕北辙。

2025 年 Q1 某金融机构的案例就是典型：智能体在财报分析中第一次幻觉了一个营收数字，后续所有财务比率、趋势判断、投资建议全部基于这个错误数字展开。表面看报告专业完整，实际结论完全失真。

为什么传统 NLP 时代的幻觉没那么致命？

传统 QA 系统也幻觉，但影响范围有限——一次问答的错误不影响下一次。智能体截然不同：它是一个持续运行的闭环系统，前一步的输出是后一步的输入。一个幻觉 token 就像生物学中的基因突变，在后续"转录"过程中被不断放大。

三类幻觉的根源

1. 事实性幻觉

模型编造不存在的事实。典型表现：

当智能体有了"自主权"，谁为它的行为负责？

前几篇文章讨论的问题——幻觉、工具调用失败、崩溃、协调混乱——都是技术可解的。但有一类问题超越了技术范畴：当智能体越来越多地代替人做决策和行动时，谁来为后果负责？

McKinsey 2026 年 AI 信任成熟度调研覆盖了数千家企业，核心发现是：企业对 AI 的信任没有跟上 AI 能力的增长。随着 Agent 从"辅助工具"走向"自主行动者"，治理和问责缺位成了最紧迫的系统性风险。

这不是"以后再考虑"的问题。2025 年已经有多起因 AI Agent 自主行动导致的业务事故：

• 客服 Agent 自作主张给用户全额退款
• 营销 Agent 向错误人群发送敏感促销
• 数据处理 Agent 把内部数据写入了外部系统

每一件事的直接原因都是技术层面的（幻觉、工具错误），但根本原因是治理框架缺失——没有人为 Agent 的行动设定边界。

四大治理挑战

挑战一：权限边界模糊

核心问题

智能体能干什么？哪些决策它可以自己做？哪些必须请示？

大多数 Agent 系统根本没有清晰定义权限边界。系统 prompt 里写了"帮用户处理订单"，但没有写：

• 你可以取消订单吗？
• 你可以修改价格吗？
• 你可以给超过 100 元的订单退款吗？
• 你可以查看其他用户的数据吗？

为什么重要

权限不清时，Agent 的两种倾向都会出问题：

• 过度谨慎：什么都问用户，失去自动化的意义
• 过度激进：什么都自己做，出了事不可控

现实中的 Agent 往往走向后者——因为"帮用户解决问题"的指令天然偏向行动，而非克制。

类别

权限至少需要从三个维度定义：

1. 数据维度：能访问什么数据？能读哪些？能写哪些？
2. 操作维度：能执行哪些操作？取消订单 vs 修改地址 vs 查看物流？
3. 金额维度：操作有财务影响时，上限在哪里？

挑战二：审计追踪缺失

核心问题

Agent 做了一个决策，事后能否完整回溯"它为什么这样做"？

目前多数 Agent 系统的回答是：不能。

• 推理过程只存在于 LLM 的上下文中，运行结束后消失
• 工具调用的参数和返回值可能记录了，但"为什么选择调这个工具"没有记录
• 多步推理中，前面步骤的中间结论影响了后面决策，但这些因果链没有被显式记录

后果

没有审计追踪 = 没有问责基础。