章节主旨
用五个 Cloud Code 实例的实测演示证明「原始 LLM 输出可变性太大,无法直接用于业务」,拆解可变性的底层来源(概率分布 + 复合错误率),指出根因是「让概率系统去做确定性工作」,并引出解法框架 DOE 框架:把确定性任务交给代码、把判断路由交给 LLM。
核心论点
- 原始 LLM 对同一问题会给出 30-50% 差异的答案,这种可变性对严肃业务不可接受。(→ 详解1)
- LLM 是概率系统而非确定性系统:它预测的是下一个 token 的统计分布,再叠加 temperature/top-P 的随机采样。(→ 详解2)
- 随机性不是缺陷而是特性——没有它模型就无法灵活推理。问题只在于业务场景不容忍这种随机。(→ 详解3)
- 多步流程的错误率按复合概率灾难性放大:每步 90% 成功、五步只剩 59%,十步只剩 35%。(→ 详解4)
- 根因是拿概率系统做确定性工作;解法不是等模型变聪明,而是在模型外面包一层框架收窄输出区间。(→ 详解5)
- DOE 框架 靠「关注点分离」落地:确定性活(API 调用、数据转换、数学)交给代码,判断与路由交给 LLM。(→ 详解6)
知识点详解
1. 五实例实测:同一问题,五种答案 0:52:53
作者同时开五个 Cloud Code 实例(Opus 4.5,均设为 plan mode 只出计划不执行),向五个都问同一个简单问题「有哪些自动发送 proposal 的方式」。
五个回答彼此完全不同:一个反问「哪种 proposal」,一个直接列长清单,一个混合(先问再给触发场景),一个给四个选项,一个给一张表。结论虽大致殊途同归,但过程毫无「程序化、可复现的分步结果」可言。
作者用这点铺垫:业务里当有人填表、要开发票、要发邮件时,这种 30-40-50% 的答案方差远远过大。发票、收据、onboarding 邮件、线索资格审核——每一次都必须基本一致。任何规模化的严肃公司若流程带这种方差,撑不了多久。
2. LLM 为什么是概率系统而非确定性系统 0:55:20
作者提到自己照 Andrej Karpathy 的教程从零训过一个 mini-GPT,借此讲底层原理。LLM 本质是「按结果分布运作的统计模式匹配机器」。
常见误解是 LLM 预测「单个最可能的下一个词」;实际上它预测的是一整张候选词的统计分布。比如输入 “hi how are ___“,你以为只会得到 “you”,但模型内部得到的是 you / things / your 等一整张概率图。0:56:16
即便 “you” 有 98% 置信度是最可能 token,系统也不总是选它。通过 temperature 和 top-P 两个参数,在一个截断范围内带着随机性(stochasticity)去采样下一个 token,因此你无法预测 LLM 每次会怎么做。0:56:57
3. 随机性是特性,不是缺陷 0:57:37
作者强调这种不可预测「不是坏事,反而是好事」。如果模型永远对同一输入吐出完全相同的输出,那它就只是一长串多米诺骨牌,一块推倒下一块,根本谈不上灵活推理,也就没必要用 LLM 了。
随机性与 stochasticity 正是模型能替我们解决问题、进行推理的很大一部分能力来源。换句话说,流程的每一步都被注入了一定随机性——这既是能力的源泉,也是可变性的源头。
矛盾点在于:模型这种「灵活」在开放推理时是优点,但业务要的是「每次一样」。特性本身没错,错的是把它硬塞进不容忍随机的确定性场景。
4. 复合概率:多步流程错误率灾难性放大 0:58:56
随机性在流程的每一步累积。数学上这叫复合概率(compound probabilities):各步成功率相乘,而非取平均或最小。
举例:一个五步流程(读收件箱挑最佳邮件 → 摘要 → 喂给另一模型 → 合并其他摘要 → 生成当日 digest),每步都有 90% 成功率。直觉以为整体还是 90%,但 0.9 的五次方 ≈ 59%。步数越多塌得越狠:十步约 35%,二十步只剩 12%,哪怕单步做到 95% 也救不回来。1:00:08
作者用一个业务类比钉死这点:一家月入 10 万美元的公司,若 5% 的时间发错发票,冲击绝不是 5% 而是接近毁灭性——客户被发错一次(哪怕二十分之一),大概率不会有第二十一次合作。业务对方差的容忍度极低。
5. 根因与解法方向:别让概率系统做确定性工作 1:01:40
作者把根因一句话点破:我们在要求概率系统去做确定性工作。概率系统是那团不可解释的思考过程;确定性则是业务在用的「一步接一步、可预期」的流水线。最好的公司把一切产品化、标准化,而这恰恰是纯概率系统给不了的。
解法不是「傻等模型变聪明」。虽然模型越聪明方差通常越小,但那个时间表不可控。真正的办法是在模型外面包一层框架——给它定义好的节点(nodes)与步骤,缩短每一步的「总缺口」,让本来摇摇欲坠的输出变成仍然可用的东西。
一句话概括:把这团「银河大脑智能」包进一个框架里,用它来为可控的业务目的服务。这就是 Agentic 工作流 的本质。
6. DOE 框架:关注点分离,确定性交给代码 1:03:02
框架落地为 DOE 框架(Directive / Orchestration / Execution,指令-编排-执行):
- **Directives(指令)**在最顶层,提供清晰无歧义的说明文档(即知识阶梯的第一级)。
- **Orchestration(编排)**是 LLM 施展 PTMRO 循环 的地方——它决定做什么、以什么顺序做。
- **Execution(执行)**脚本干重活,但不用模型本身跑,而是用模型写好、反复测试过的小段代码(作者常用 Python,语言不限)。
核心是关注点分离:凡是确定性的活(API 调用、数据转换、文件操作)全进代码——代码给定输入 A 永远输出 B,零方差、可解释、可复现;而灵活的判断、路由决策留给 LLM。代码可靠、快、精确,LLM 灵活、善处理模糊,二者组合取长补短。1:04:02
一个具体理由:LLM 极不擅长基础运算。让它数单词字母数、给长列表排序,好比「雇个博士去点库存」——花大钱办小事。1:05:33一个 Python 脚本排序能比 LLM 快 1 万到 10 万倍且近乎免费。所以把确定性任务推给脚本,把 LLM 的 token 省下来做真正的思考;需要算数就给它建个 calculator 工具去调。
术语
- probabilistic / deterministic(概率的 / 确定性的:LLM 输出带随机分布 vs 业务流水线输入定则输出定)
- temperature / top-P(采样参数:控制从候选 token 分布中带随机性挑选的范围)
- stochasticity(随机性:每步 token 选择注入的不确定,是推理能力来源也是方差来源)
- compound probabilities(复合概率:多步流程成功率相乘,错误率随步数灾难性放大)
- separation of concerns(关注点分离:确定性活交代码、判断路由交 LLM 的设计原则)
- DOE(Directive / Orchestration / Execution,指令-编排-执行框架)
自检问题
- 为什么原始 LLM 对同一个业务问题会给出彼此差异很大的答案? 答案:因为 LLM 是概率系统,预测的是下一个 token 的统计分布而非单个最优词,再叠加 temperature/top-P 的随机采样(stochasticity),每步都注入随机性,所以不可预测、方差大。0:55:20
- 五步流程每步 90% 成功,整体成功率是多少?这说明什么? 答案:0.9 的五次方 ≈ 59%,不是 90%。复合概率让多步流程错误率灾难性放大(十步约 35%,二十步约 12%),所以多步业务流程不能靠裸 LLM 硬跑。1:00:08
- 既然随机性带来这么多麻烦,为什么作者说它不是缺陷? 答案:因为随机性正是模型能灵活推理、解决问题的能力来源;若永远同输入同输出,模型就只是一串多米诺骨牌,失去推理价值。问题不在随机性本身,而在于把它用进了不容忍随机的确定性业务场景。0:57:37
- DOE 框架靠什么原则解决可变性,具体怎么分工? 答案:靠「关注点分离」。确定性任务(API 调用、数据转换、文件操作、数学)交给代码——同输入永远同输出、快且可复现;灵活的判断与路由交给 LLM。取代码的可靠精确 + LLM 的灵活善处理模糊。1:03:02