AI 会写代码、会做事之后，谁来证明它选对了？

这两年，企业 AI 落地最热闹的话题是什么？是写代码、是干活、是让 Agent 把一件事从头做到尾。理解、执行、记忆 —— 这三层能力，软件工程的方法论已经给出了越来越成熟的答案。

但有一个问题，正在变得越来越尖锐，却很少被真正回答：

AI 会写代码、会做事之后，谁来证明它选对了？

01 从「可交付」到「可决策」，中间还差一步

一个 AI 系统要在企业里真正做事，必须先回答四个问题：

第一问：它读懂了吗？（理解） 需求、上下文、合同条款、业务语言 —— 这是大模型最擅长的一层，基本过关。

第二问：它做得到吗？（执行） 调用工具、权限控制、测试与审计、失败后能恢复 —— 这是 Harness 工程在解决的事，正在快速成熟。

第三问：它记得住吗？（记忆） 已下的单、已发的车、当前库存 —— 系统不能忘记的 "已发生的现实"。记忆层开始有共识了：以 ERP 和事件日志为准，不由大模型自己 "记得"。

第四问：它选对了吗？（决策） 当目标冲突、资源有限、承诺不可撤销时，谁来证明 "这个动作值得执行"？

前三问，工程界已经交了卷。第四问，在大多数 Harness 里目前是空的。

为什么是空的？因为回答 "选对了吗"，需要的不是更漂亮的回答，而是能落地、能复算、能追溯的选择。而这类 "证明"，大模型天然给不了 —— 它擅长预测，不擅长证明。

02 一门每天都在用、却很少被提起的学科

补上这第四问的，是一门存在了几十年的老学科：运筹学（Operations Research，OR）。

一句话定义它：在一堆不能违反的规则下，从所有可行的方案里，找出最好的那一个 —— 并证明它是最好的。

四个要素，缺一不可：

• 决策变量：能动的开关（哪个服务放哪台机器、补多少货、几点付款）
• 约束：不能破的规则（资源上限、合同条款、交期、法规）
• 目标函数：要优化的那一个（成本最低、机器最少、利润最高）
• 求解器：算出来 + 证明（把前三样喂给它，它回传方案和证据）

你可能没听过这门学科，但每天都在用它：pip/apt 的依赖解析、数据库的查询优化器、导航 App 的路径规划、Excel 里的 "规划求解"、航班与机组排班、Kubernetes 调度 —— 全是 OR。

一句话说透它与机器学习的分工： 机器学习回答 "接下来可能发生什么"；OR 回答 "所以现在该怎么做"。两者加起来，再加上 Harness 执行，才是一个完整的决策系统。

03 让大模型摔一跤：同一道题，三个 LLM，三种答案

口说无凭。分享现场用同一道真实的多期补货决策题 —— 整数、卡车容量、库容、最坏情况风险、不能偷看未来 —— 直接问三个主流大模型，不给任何工具：

DeepSeek：没算完。 它很诚实地承认：找到候选可行解，但无法证明全局最优，也交不出可执行的计划。诚实，但没有可提交的方案。

Gemini：判错了。 它输出了一份最像求解器报告的回答，声称模型不可行（INFEASIBLE）。但题目里 "什么都不补货" 本身就是一个可行解 ——语言模型可以生成 "INFEASIBLE" 这个词，只有求解过程能让它成为证明。

Grok：知道边界。 它正确识别了工具边界，建议用商业求解器，但同样没有给出完整决策方案。

三个模型，三种 "看起来合理" 的失败。这说明什么？

"多生成几个再挑" 是有天花板的。 用一道 "12 个服务放几台机器" 的题就能看清：12 个服务 ×5 台机器，一共有 2.4 亿种摆法；其中符合全部规则的只有 1.07%；用到最少机器的只有 0.057%。随机抽 1,000 个方案，有 57% 的机会一个最优方案都抽不到。

你挑出来的，只是 "看过的 N 个里最好的"。没看过的那 2.4 亿个里有没有更好的？它答不了 ——"最优" 是关于没看过的方案的结论。

而求解器不枚举，它算 "界"：证明 "这一片不可能少于 4 台"，整片跳过。就像搬家装箱：东西一共 116 升，一个箱子装 32 升，116÷32=3.6—— 不用试遍所有装法，一行除法就知道至少需要 4 个箱子。

测试只能证明有 bug，不能证明没有 bug。多生成几个是 "测试"；求解器给的是 "证明"——这是两种不同的操作，不是算力多少的问题。

04 Beyond Memory：记忆的终点，是让事实变成下一次决策的约束

很多人以为记忆 = 聊天记录。这场分享最有分量的一页，是把记忆拆开：

语义记忆（知识、规章、合同解释）、情景记忆（历史事件、复盘）、程序记忆（工具用法、审批流程）—— 这些常被讨论。但真正决定企业级连续决策的，是第四类：运营状态—— 当前库存、已下单、已付款、已在跑的服务、承诺与约束、模型版本。

记住错误的事实，比忘记更危险：过期（库存按 500 算，实际已出货 430）、冲突（合同已修订，记忆里仍是旧折扣）、重复执行（审批后重试，产生两张采购单）。

所以核心原则只有一句话：已发生的锁定，未来的重算。 一台机器挂了，过去的最优方案不能重算 —— 那是已经发生的现实；只重算还没做的部分，把 "已发生" 变成约束写进模型。全站从头算一遍也能得到同样的最优解，但要搬动 9 个服务，等于一次全站重启。有没有记忆，代价天差地别。

这正是 "Beyond Memory" 的意思：记忆的终点不是回忆得更多，而是让已经发生的事实，变成下一次决策的约束。

05 Decision Harness：六个环节，一个持续重算的闭环

基于此，分享提出了一个叫法（注意：是本次分享提出的概念，不是行业标准）——Decision Harness，与 Agent Harness 的差别只在第 3、4 步：

观察 → 读状态 → 建模 → 求解 → 闸门 → 执行，然后回到观察，形成一个持续重算的闭环。

• 超时了？用上一版可行解 / 保守解；
• 不可行了？看冲突集、放松规则、上报人工；
• 间隙大于约定？继续算、降级、等待。

Harness 的工作不是让模型永不犯错，而是让每一种失败都有结构性的下一步。

配套的架构主张，同样值得带走：把不确定的放在边缘，让核心保持确定。

• 边缘层：LLM / 机器学习，处理不确定的语义 —— 预测需求、从合同制度文本里抽候选规则、把求解结果翻译成业务语言，允许出错（前提是有人或求解器在看）；
• 核心层：求解器，处理可证明的决策 —— 整数规划、硬规则强制成立、回传状态 / 间隙 / 冲突集，算完那一刻结论就成立；
• 执行层：Harness，处理工程化与可审计 —— 状态 / 记忆 / 版本、审批、超时降级、版本追溯与全量留痕。

可靠性不是靠约束一个不可靠的核心得来的，而是让每个元件只负责它真正能保证的事情。Harness 的职责也变了：不是驯服一个不可靠的推理器，而是守住混乱世界与确定性核心之间的那道边界。

06 与公司本体接上了：本体是名词和关系，求解器模型是动词和取舍

这里和我们之前反复推演的公司本体，终于接上了。

本体建模（业务语义）和求解器模型（OR）是两个都叫 "建模"、却回答不同问题的东西：

• 本体回答：这是什么？和谁有关？合不合规？（类别、属性、关系、规则 —— 布尔的一致 / 不一致）
• 求解器模型回答：该选哪个？为什么？离最好差多少？（变量、目标、约束、参数 —— 可量化、可权衡）

本体是名词和关系，求解器模型是动词和取舍。本体定义 "世界长什么样"，求解器模型定义 "在这个世界里怎么选"。两者是同一条管线的上游与下游。

落到实际系统，是五层设计：本体层（唯一真相，对象属性关系规则版本化）→ 决策模板层（本体之上的决策视图，OR 工程师写、LLM 辅助）→ 实例化层（确定性程序，不用 LLM，同样的输入永远产生同样的模型）→ 求解与回映射（把 x [search][n5]=1 翻译成 "search 放到 n5"，冲突集直接翻成三条本体规则在打架）→ 政策闸门（形式化不了的规则留在这里）。

关键细节：每一次决策记录要带三个版本号 —— 本体版本 + 模型版本 + 状态版本。事后才能回答 "这条约束当初是怎么来的"" 这个方案是基于哪一刻的世界算的 "。

这也解释了为什么求解器的返回值可以被程序信任：status、mip_gap、binding/conflict_set、state_version、execution_mode—— 每一个字段都有明确语义，Agent 可以据此分支、写 SLA、拒绝过期状态、决定自动执行还是审批。LLM 的返回值里，没有任何一个字段可以被程序信任 —— 这就是全部的差别。

07 但求解器通过 ≠ 业务可接受：这正是 LLM 该回来的地方

不过，这场分享的可贵之处，是它同时划清了边界：求解器不是万能的。

真实案例：储能电力交易。当电价差小于电池损耗成本，数学最优解是 "今天完全不交易"—— 规则全部满足、目标全局最优、可复现、可审计，技术角度无可挑剔。但业务上不能接受：计划链断了（今天的电量是明天重算的起点）、市场资格与履约记录需要持续交易维持、运营团队没法向管理层解释 "今天什么都不做"。

处理方式：识别这类边界，启动 "强制交易模式"，在容忍一定损耗的前提下二次求解。这是纯技术检查器永远处理不了的一层，它需要业务语义的介入 —— 而这恰恰是 LLM 该回来的地方：解释、翻译、提出候选，但不作为任何规则的权威来源。

一句话总结三者分工：Harness 负责 "能不能执行"，求解器负责 "该不该执行"，大模型负责 "翻译"。

08 实务六步：顺序很重要

最后，如果今晚就想试一试，分享给了六步，顺序很重要：

1. 选一个决策：只选一个 —— 重复发生、有硬规则、代价明确（补货、排产、调度），不从战略问题开始；
2. 先写开关和规则：你能动什么、什么不能破，从 SOP、合同、SLA 里抄出来，标好来源；
3. 最后才定目标：先用一个简单的数（成本、机器数、缺货件数），先求可行，再求最好；
4. 用现有数据跑一遍：不需要预测，也不需要大模型，离线复盘过去三个月，和历史对比；
5. 只在需要处加预测：求解器会告诉你哪些参数敏感，只对 "敏感且不确定" 的参数做机器学习 —— 先 OR，后 ML；
6. 接进 Harness 上线：离线对比→影子运行→人工审批→有边界的自动执行。

为什么目标最后、预测最后？规则是事实，目标是立场，预测是成本。 先把事实写清楚，一个可行解就已经比今天的经验排法多了一份证明。

三个可以带走的判断

01 检查器的性质，决定可靠性的上限。 用 LLM 检查 LLM，是拿同一个不可靠来源做两次。要得到可证明的结论，检查器本身必须是可证明的 —— 运筹求解器就是这样一类检查器。

02 把不确定的放在边缘，而不是驯服核心。 可靠性来自正确分工，不是把一个模型 "训练得更乖"。

03 记忆让一次推理变成持续运行的系统。 记住已经发生的现实，锁定不可逆的决定，只对未来重新计算。结构性的失败需要结构性的兜底，而不是重试逻辑。

结语

机器学习预测 → 求解器决定并证明 → Harness 执行并记住。

过去几十年，运筹学一直在解 "怎么保证解可行且最优"——这里有现成的答案，只是还没有被接上。 求解器证明的是模型内的最优，模型对不对是人的责任。

AI 会写代码、会做事，已经不再是问题。下一个让企业真正敢把决策交给系统的问题，是谁来证明它选对了。而答案，可能不在更新的模型里，而在那门已经存在了几十年、你每天都在用、却很少叫出名字的学科里。