章节主旨
用「给列表排序」这个最简单的任务,现场对比 LLM 原生智能 vs Python 脚本两种做法,得出一条贯穿全课的原则:LLM 只留给判断,确定性执行交给代码。
核心论点
- 同一件确定性小事,脚本比 LLM 快几百倍、便宜几百倍且更准——排序 demo 里脚本 53 毫秒完成,LLM 逐 token 输出要十几到三十秒。(→ 详解1)
- 该原则=把确定性工作推进工具:LLM 负责决策,脚本负责执行,二者分工。(→ 详解2)
- 这正是 DOE 框架的落点,后续所有工作流都按「LLM 判断 + 代码执行」搭建。(→ 详解3)
知识点详解
1. 排序 demo:原生 LLM vs 脚本 1:07:42
Nick 让 agent 先只用 LLM 原生智能排序,禁用任何工具,并自行计时。展开 reasoning 面板能看到模型在逐个 token 手动输出整份排好序的列表,从头到尾约花了半分钟。模型自称「没有内部时钟」,但肉眼可见其慢。
再让它「改成跑脚本」——agent 转而调用一个现成的 Python 排序脚本,右侧几乎瞬间给出结果,且准确度显著更高。
脚本实测 53 毫秒完成 1:08:48;而 LLM 那侧即便不算调用它的往返延迟,也在十几到三十秒量级。
差距不只是速度。Nick 强调脚本还「几百倍地更省钱」1:08:56:在自己或云端 CPU 上跑一段排序脚本几乎零成本,而 LLM 每次调用都在烧 token。
2. 原则:确定性工作推进工具 1:09:24
Demo 里连模型自己都总结出了这条:这是「把确定性工作推进工具」的核心论据——LLM 处理决策,脚本处理执行。
一句话概括:把大模型调用留给需要判断的环节,其余交给代码 1:09:36。这样做同时换来更快、更可靠、更便宜三重收益。
这条分工是概率系统 vs 确定性工作的具体操作化:排序这种有唯一正确答案的确定性任务,没必要交给一个概率性生成器去猜。
3. 接入 DOE 框架 1:09:49
这条「判断归 LLM、执行归代码」的分工,正是 DOE 框架(Directive Orchestration Execution,指令-编排-执行)的落脚点。
Nick 说本课后续所有工作流都会按这个框架搭建,本章的排序对比就是它最小的代表性例子。
术语
- native LLM intelligence(LLM 原生智能,不借助任何外部工具、纯靠模型本身推理生成的能力)
- deterministic(确定性,同输入必得同输出、有唯一正确答案的计算)
- DOE / Directive Orchestration Execution(指令-编排-执行框架,本课搭建工作流的主线方法)
自检问题
- 同样给列表排序,为什么优先用 Python 脚本而不是让 LLM 直接排? 答案:脚本快几百倍(53 毫秒 vs 十几到三十秒)、便宜几百倍(几乎零成本 vs 烧 token)、且准确度更高。排序是有唯一正确答案的确定性任务,不需要概率性生成器去猜。1:08:48
- 「LLM 负责什么、代码负责什么」这条分工怎么说? 答案:把大模型调用留给需要判断/决策的环节,其余确定性执行交给代码。换来更快、更可靠、更便宜。1:09:36
- 本章的排序对比对应课程里哪个框架? 答案:DOE(Directive Orchestration Execution,指令-编排-执行)框架,本课后续工作流都按此搭建。1:09:49