“OpenAI just proved AI has no idea what it's doing (July) [video]”这段带有挑衅意味的视频标题在技术社区流传时，真正值得关注的不是“OpenAI 又要炒作什么”，而是一个反复出现的工程现象：AI 能生成非常自信、流畅、结构完整的回答，却并不真正掌握自己行为的正确性。把这句话翻译成技术语言，就是大模型缺少可靠的自验证能力。它不知道自己答错了，因为生成机制里没有独立的“事后检查”模块。
这里以 OpenAI 和各类 LLM Agent 的工程实践为背景，先解释大模型为什么会表现出“像知道、其实不确定”的行为，再从 Agent 工程视角给出评估、约束、排查和落地方法。不要把“AI 不知道自己在做什么”当作哲学判词，它是一组可以被验证和缓解的工程缺陷。搞清楚这一点，你在业务里用 AI 的方式会发生明显变化：从“让模型自由发挥”变成“让模型在约束内执行，再用外部机制验证”。
1. 先把“AI 不知道自己在做什么”变成可验证的技术判断
1.1 大模型的生成机制里本来就缺少“行为监控”
先说结论：目前主流大模型的自回归生成过程，本质上是一个“每次只预测下一个 token”的概率循环。模型拿到用户消息和已经生成的内容，计算下一个 token 的概率分布，按分布采样，把新 token 拼回上下文，再继续预测。这个循环没有全局规划器，也没有独立的“行为监控模块”来检查已经生成的步骤是否真的正确。
因此，当你说“AI 不知道自己在做什么”时，严格的技术表述是：它没有一个机制来判断“我当前生成的内容与真实目标之间是否一致”。它产生“接下来应该写什么”的能力，来自训练阶段从海量语料中学到的统计结构。写代码时，它见过太多“先引入库、再写主函数、最后调用入口”的文本模式，所以它擅长生成看起来像代码的 token 序列，但没有任何内部状态知道这段代码能否编译、能否通过测试。
这一点在 Agent 场景中更明显。Agent 的常见交互方式是“模型决策 -> 调用工具 -> 观察返回值 -> 再次决策”。每一步模型都在预测“这种情况下通常应该调用哪个工具”，但它并不拥有工具执行后的真实世界状态，只能依赖返回文本。如果返回值里有错误，模型可能继续沿着错误方向执行下一个动作，因为“继续执行”这个模式在训练数据里非常常见。
相关讨论里有一个常见误解：模型能详细解释自己的推理过程，就代表它理解任务。实际上 CoT（思维链）只是让模型显式生成中间步骤，让推理过程可阅读、可追踪，却不保证中间步骤真实可靠。尤其在长推理中，模型完全可能编造一个推导过程，而推导过程和最终答案都是错的，只是语言上看不出破绽。
1.2 “流畅解释”与“真正理解”不是一回事
人类判断一个人是否“知道自己在做什么”，通常看三点：是否理解目标、是否能意识到错误、是否有办法纠正。LLM 在这三点上都很弱。它生成的答案可能语法完美、逻辑严密、引用知识精准，但那是语言模型的强项——模仿高质量的语言形式；不是世界模型的强项——对真实状态进行可靠建模。
幻觉概念能帮助理解这一点。所谓幻觉，是指模型生成的内容与输入上下文或事实不一致，但表达方式极度自然。比如让一个 AI 编程助手修改 config.yaml，它可能把文件中本来不存在的 key 当作存在来处理；让一个客服 Agent 查询订单，它可能编造一个看起来合理的订单状态，因为它从上下文判断“这里应该有一个状态字段”。它不是在撒谎，而是从 token 概率里采样出了一个符合语境的文本。
这个行为从根本上解释了“OpenAI just proved AI has no idea what it's doing”这类标题为什么会引发共鸣：模型输出端有极强的“正确感”，内部却没有对应的正确性保障。真正有价值的工程反应不是骂模型不行，而是接受这个特性，在模型之外建立正确性护栏。
1.3 模型“信心”和采样概率不能当可信度使用
有些系统把模型输出的概率或 logits 当作置信度，用于判断“AI 是否确定”。这个做法只能作为参考，不能当作可靠性依据。因为语言模型被训练成预测“下一个 token 在语料里出现的概率”，而不是“这句话是否正确”的概率。一个 token 序列概率很高，只说明它符合模型学过的语言模式；高概率的错误答案依然可能是错误答案。
温度（temperature）和 top-p 采样让问题更复杂。低温输出更稳定、更少发散，高温输出更多样、更有创造性。同一个问题在不同温度下可能得到不同答案，而模型每次都不会告诉你“我对这个答案的把握有限”。工程上更好的做法是：不依赖模型自带的“信心感”，而是为每个任务建立外部验证点。模型答完之后，用编译、测试、schema 校验、规则匹配、检索比对等方式做独立确认。
下面用一个表格对比人类意义上的“知道”和模型意义上的“生成”：
| 维度 | 人类“知道自己在做什么” | LLM 的“生成行为” |
|---|---|---|
| 目标感知 | 清楚任务目标和对错标准 | 没有独立的全局目标状态 |
| 局限感知 | 能评估自身能力边界 | 通常无法可靠判断自己不会回答 |
| 过程监控 | 能发现中途跑偏并拉回 | 缺少独立的行为检查模块 |
| 错误纠正 | 可以针对失败调整策略 | 倾向于继续按语境模式生成 |
| 结果负责 | 能说明理由并承担后果 | 只输出文本，不拥有现实责任 |
工程含义很明确：要验证 AI 是否真的“会做某件事”，不能靠它自己解释，也不能靠演示观感，必须引入外部验证设施。这就是后面要重点展开的内容。
2. 演示视频里的“无所不能”，和生产 Agent 之间隔着工程落差
2.1 演示是全流程筛过的能力抽样
网络上流传的 AI 演示视频，通常是团队从大量运行结果中挑选出来的成功样本，配上剪辑和旁白。它并不代表模型在任意输入下的平均表现，更不代表生产环境条件下的表现。它更像“能力抽样”而非“能力测试”。一个视频能证明 100 次运行里有 1 次成功，但不能证明 99 次失败不会发生在你的业务里。
实际项目里最常见的误区，是把演示当作验收标准：看到视频里 AI 能用自然语言操作文件、回答问题、写测试，就觉得自己的业务也能直接套用。真正上线后，输入数据分布不同、上下文长度更大、外部系统更复杂，成功率会显著下降。判断一个 AI 方案是否可用，应该看它在你的数据、你的任务、你的验证标准下的失败率和失败模式，而不是看它在营销视频里的高光时刻。
注意：不要用演示视频代替评估集验证。单次成功只能证明模型具备某种能力潜质，不能证明它在生产输入分布下的稳定性。
2.2 Agent 多步任务常见失败模式
Agent 不是单个问答，而是多个动作的组合。多
