LLM 与确定性程序的分工

一句话理解：让 LLM 做“理解、判断、生成”，让程序做“查询、计算、规则、状态与校验”；一个可靠的 Agent，是把两者放在各自擅长位置上的系统。

学完前面几课，你应该已经形成了一个判断：模型很强，但它是一台概率性的续写机器。这一课把这个判断落到设计上——每一个步骤，到底该交给模型，还是交给程序？

这是 Agent 产品设计中最高频、也最容易出错的决策。交给模型太多，系统不稳定、成本高、难以审计；交给程序太多，系统僵化，处理不了真实世界里的模糊情况，也就失去了做 Agent 的意义。

LLM 不是这四样东西

LLM 不是	为什么	应该用什么
数据库	知识压缩在参数里，记不住精确条目，也不知道你的实时数据	数据库查询、业务 API
搜索引擎	没有实时索引，不知道训练截止之后的事，可能编造来源	搜索工具、检索系统（RAG）
规则引擎	同样的输入可能给出不同判断，无法保证 100% 执行规则	代码里的条件判断、规则引擎、权限系统
计算器	数字被切成 Token 处理，大数运算、日期推算、汇总统计会出错	代码执行、SQL 聚合、计算函数

反过来，程序也有做不到的事：读懂一条语气含混的客户留言、从杂乱的客服备注里判断是不是“客户主动取消”、把一堆指标变化组织成一段让老板看懂的解释。这些正是 LLM 的价值所在。

更适合 LLM	更适合程序
理解自然语言意图与情绪	精确查询与数据读取
在模糊、不完整的信息中做判断	数值计算、汇总、日期推算
从非结构化文本、图片中提取信息	执行明确的业务规则与阈值
规划多步骤任务、决定下一步查什么	权限检查与审批流转
生成解释、报告、话术、代码草稿	状态管理、幂等、重试、事务
归纳、分类没有明确边界的内容	格式与业务校验、审计日志

一个补偿规则的拆分示例

假设一家电商平台的补偿规则是：

订单支付超过 72 小时仍未发货，且延迟原因不属于客户自身因素（如地址填写有误、客户主动要求延后发货），
按实付金额的 20% 补偿，单笔上限 50 元；VIP 客户比例提高到 30%，上限 100 元。
补偿金额超过 50 元需要主管审批。

错误的做法：把这段规则写进提示词，让模型读完订单数据后直接输出“应补偿 xx 元”。它大多数时候能算对，但会偶尔算错比例、忘记上限、把“客户主动要求延后发货”误判为平台责任，而且你无法审计它为什么这么算。

正确的做法：把规则拆开，只把“真正需要判断”的那一步交给模型：

图 1 · 补偿规则拆分：模型只在 ④ 和 ⑦ 两步出场

在这个设计里，模型只在第 4 步和第 7 步发挥作用：一个是“读懂模糊的文字并归类”，一个是“把确定的结果说成人话”。金额永远由程序计算，审批永远由流程决定。即使模型在第 4 步判断错了，也有置信度字段和抽检机制兜底，而且错误可以被定位和统计。

四个贯穿场景的分工

场景	交给程序	交给 LLM
销售分析	SQL 聚合同比环比、按区域和 SKU 下钻、显著性判断	决定下钻方向、结合库存和活动信息给出解释、写分析报告
SEO 诊断	抓取页面、检查标题长度、状态码、Canonical、结构化数据是否合法	判断内容与搜索意图是否匹配、给问题排优先级、写修复建议
订单售后	查询订单与发货记录、计算时长、执行补偿规则与审批	解读备注与客户留言、判断问题原因、生成沟通话术
Coding Agent	编译、运行测试、代码检查、版本控制	理解需求、定位问题、编写和修改代码

Coding Agent 之所以进展最快，一个关键原因就是它天然拥有强大的“确定性程序”：编译器和测试会毫不留情地告诉模型哪里错了（参见办公 Agent 与 Coding Agent）。其他领域的 Agent 要做强，就要主动为模型搭建类似的程序化反馈。

桥梁：让模型写程序、调程序

模型不擅长算，但擅长 写出计算的代码 和 决定调用哪个工具。这就是工具调用和代码执行的意义：

图 2 · 桥梁：模型决定做什么，程序把它做对，结果再回到模型

对应的设计原则是：模型负责“决定做什么”，程序负责“把它做对”，然后程序的结果再回到模型那里。 工具如何设计见工具调用，代码执行环境见沙箱。

判断一个步骤归属时，可以用这组问题快速过一遍：

图 3 · 步骤归属决策树：先问规则能否写清，再问出错代价

高风险动作的“LLM 决策 → 程序校验 → 权限检查 → 人工审批 → 执行”链路，在程序校验优先一课会系统展开。

常见误区

“模型越来越强，以后规则都可以写在提示词里。” 模型再强也是概率性的。涉及金额、权限、合规的规则，需要的是可审计、可复现的执行，这是程序的职责。
“能用程序做的就全用程序，模型只做聊天。” 这样做出来的往往是一个套了对话框的旧系统。真实业务中大量环节依赖对模糊信息的判断，这恰恰是 Agent 的价值。
“让模型调用一个万能的 SQL 工具，它自己查自己算。” 这把查询的正确性和安全性都交给了模型。应该提供粒度合适的专用工具，见安全的工具设计。

设计要点

把业务流程拆成步骤，逐步标注：程序、LLM、LLM + 程序校验、人工。
能写成明确规则的，写成代码；模型只处理规则无法覆盖的判断。
模型输出的判断要结构化，方便程序接着处理和统计。
数字、金额、ID、时间只由程序产生或校验，模型只负责解释。
为模型的判断步骤设计置信度与兜底路径，而不是假设它总是正确。

练习

用本课方法拆解一个真实流程（约 45 分钟）：

选一个你熟悉的业务流程，例如“处理一张客户投诉商品破损的工单”或“每周一生成销售周报”。
把它拆成 8–12 个步骤，每一步标注由程序、LLM、LLM + 程序校验，还是人工负责。
对每个标注为 LLM 的步骤，写出它的输入、输出格式，以及出错时的兜底方式。
检查一遍：有没有任何金额、权限或不可逆动作是由模型单独决定的？如果有，重新设计。

下一步

模型的边界清楚了，接下来要学会如何把业务规则和流程“告诉”模型。下一个模块从「指令的四层结构」开始，讲清楚一个 Agent 的指令由哪几层组成、冲突时谁说了算。

LLM 与确定性程序的分工