伊利诺伊大学厄巴纳-香槟分校出手：用数学证明的方式给AI工作流"体检"，效果提升近12%

这项由伊利诺伊大学厄巴纳-香槟分校与独立研究者联合开展的研究，于2026年6月以预印本形式发布，论文编号为arXiv:2606.06523，有兴趣深入了解的读者可通过该编号查询完整论文。

研究的起点，是一个困扰了整个AI行业很久的难题：大语言模型（就是ChatGPT这类能对话的AI）在帮我们做复杂任务的时候，怎么才能保证它按照我们期望的方式一步步走下去，而不是在某个环节悄悄出错，最后交给我们一个看似完整实则一塌糊涂的结果？

现有的AI系统大多依靠"感觉"来评估自己的工作——要么让另一个AI来打分，要么由人工检查。这两种方式都有明显的软肋。AI打分容易自我感觉良好，在长达数十步的复杂任务中尤其容易出现幻觉；人工检查则耗时费力，根本跟不上实际需求。

这个问题在数学界早就遇到过，而且有了成熟的解决方案。数学家在证明复杂定理时，也面临同样的困境：自然语言描述的证明过程，越长越容易出错，越难验证。于是他们发展出了"形式化语言"——一种严格到不能有任何歧义的数学语言，可以让计算机自动检查每一步逻辑是否正确。Lean4就是这样一种语言，被数学界广泛用于证明验证。

研究团队由此受到启发：能不能把这套方法搬到AI工作流的验证上来？由此诞生了这项研究的核心框架——**Lean4Agent**。简单来说，这是第一个用形式化数学语言来给AI工作流"做体检"的系统，能在AI执行任务之前，就帮你发现工作流设计中隐藏的逻辑漏洞；在执行过程中，还能精确定位哪一步出了问题。

一、AI工作流究竟是什么，为什么它需要被"体检"

要理解这项研究，先得弄清楚"工作流"是什么意思。把AI完成一个复杂任务的过程，比作一个工厂的生产流水线：流水线的每一道工序都有固定的输入原料和输出产品，工序之间有明确的先后顺序，有些工序可以并行，有些需要循环重复，还有些需要根据情况做分支判断。AI工作流就是这样一条"生产线"——它规定了AI应该先做什么、再做什么、用哪些信息、产出什么结果。

研究团队将工作流正式定义为一张"异构图"，图中的每个节点代表一个执行步骤，节点之间的连线代表步骤的先后关系或数据流向。每个节点有四个要素：它读取哪些变量、写入哪些变量、用自然语言写成的执行指令，以及它的执行类型。执行类型这个概念很关键——比如有的步骤是"step"类型，会带着整个对话历史来执行；有的是"task"类型，每次都是全新的独立执行，没有记忆。这个区别听起来小，但在实际运行中会导致截然不同的结果，也是工作流设计中非常容易出错的地方。

与此同时，AI的实际执行过程被定义为"执行轨迹"——就像工厂流水线运转时留下的生产日志，记录了每一道工序执行前后的状态、用了什么指令、产出了什么内容。研究的目标就是：既要在流水线运转之前检查设计图是否合理，也要在运转过程中盯住每一步是否按照设计图执行。

二、三层体检机制：从结构到语义，再到实际运行

Lean4Agent的核心组件叫做**FormalAgentLib**，这是一个用Lean4语言编写的形式化库，目前包含151个类型定义、611个函数，以及41个已经过严格验证的定理。整个体检过程分为三个层次，就像医院体检时先做基础检查、再做功能检查、最后做应激测试一样。

第一层检查的是工作流的"骨架"是否完整，称为结构验证。这一层不管AI的智能水平高低，只看流程图画得对不对。研究团队在Lean4中定义了一套基础类型系统，其中最重要的是变量类型（BaseType）和步骤类型（StepType）。BaseType涵盖了字符串、整数、浮点数、布尔值、JSON格式数据、列表、字典、集合等常见数据类型，还有一个特别的"TUnknown"类型用于处理类型不确定的情况，支持渐进式类型检查。StepType则区分了十几种不同的步骤类别，包括带历史记忆的step、不带记忆的task、结构化输出的discover、质量评分的evaluate、条件判断的validate、循环控制的forEachLoop和whileLoop等等。

结构验证能发现的典型错误，是论文中一个生动的案例：一个工作流使用了parallel步骤，让四个AI分支并行搜索，分别产生了results_q1、results_q2、results_q3、results_q4四个结果。然而设计者忘记了，parallel分支内部的变量有自己的"作用域"——就像工厂里几条并行的小生产线，线上产出的产品没有被汇集到主干线。结果后续的合并步骤想读取这四个变量时，系统发现根本找不到这些数据的来源，直接报错：allReadResolvable = false。这种问题在人工审查时极容易被忽视，但Lean4的native_decide机制（一种自动判定机制）可以立刻发现。

第二层检查的是工作流的"语义"是否自洽，称为静态语义验证。这一层要回答的问题是：每一步AI任务的执行，有没有足够的"前提条件"，能不能产出预期的"后置条件"？这里借鉴了计算机科学中一个经典的思想框架——霍尔逻辑（Hoare Logic），简单来说就是：在执行某个操作之前，某些条件必须成立；操作执行之后，另一些条件应当成立。

为了让这套逻辑能处理AI的模糊性，研究团队设计了一套谓词系统（Predicate System）。谓词就是关于变量的可验证性质描述，比如"这个变量是非空字符串"、"这个变量是合法的JSON格式"、"这个变量符合某个特定的JSON模式"、"这个文件路径是有效的"等等。这些谓词被实现为Lean4中的归纳类型PredicateType，每个谓词都有一个toProp函数，能把谓词转化为可验证的Lean命题。系统还支持用户自定义谓词（通过ext和custom类型），不需要修改核心代码就能扩展。

更精妙的地方在于"隐式变量"的处理。不是所有的语义要求都体现在明面上的变量里——比如"上下文流畅性"这个性质，描述的是某个步骤能不能看到之前执行的对话历史，这不是一个具体的变量，而是整个执行图上的结构性质。信息流谓词追踪每个步骤消耗了什么信息、产出了什么信息；上下文管理谓词则规定了哪些步骤可以看到哪些历史记录。这些图级别的谓词能够捕捉到那些即使是人工审查也容易错过的隐性设计缺陷。

整个语义验证的基石是一个叫做**LLMExec**的假设。这个假设说的是：如果一个AI步骤在满足前提条件的情况下被执行，那么它能够产出满足后置条件的结果。这听起来像是在说废话，但其实非常重要——它把对整个复杂工作流的验证，分解成了对每一个单独步骤的验证。每个步骤的语义规格由LLM自动标注，而标注的合理性建立在"LLM能够正确执行短期、局部的任务"这一经验性观察之上。多伦多大学等机构的研究也支持这一点：大语言模型在短小、明确的任务上表现可靠，问题通常出在跨步骤的信息传递和长链推理上。

有了LLMExec假设，验证过程就变成了一个谓词传播过程：从工作流的初始参数出发，把每个步骤已知的前置谓词收集起来，判断下一个步骤所需要的前置条件是否已经被满足，再把该步骤产出的后置谓词加入到谓词库中，如此传播下去。如果在某个步骤发现它所需要的某个谓词没有任何前驱节点建立过，那就说明这个工作流存在语义缺口。

论文中展示了一个非常典型的语义错误案例：一个用于回答学术论文问题的工作流，其中find_evidence步骤产出了evidence_pack变量，JSON格式包含"snippets"字段，每个snippet有"text"和"source"两个子字段。然而后续的compose_answer步骤却期望evidence_pack包含"passages"字段（每个passage有"quote"和"page"两个子字段）以及一个"summary"字段——这些字段压根没有任何前驱步骤建立过。这种JSON字段不匹配的问题，在运行时会悄无声息地导致答案生成失败，但Lean4验证在运行前就能精确指出：Node compose_answer (ID 3): missing predicate matchesJsonSchema(...) for variable 'evidence_pack'。

第三层检查在实际运行之后进行，针对的是具体的执行轨迹，称为轨迹验证。这一层的目标是验证LLMExec假设在特定一次执行中是否真的成立，从而精确定位是哪一步的执行出了问题。对于有精确定义的谓词（比如JSON格式验证），直接用Lean命题来判断；对于需要网络连接才能验证的谓词（比如URL有效性检查），调用外部Python验证器；对于只有自然语言描述的模糊谓词，则调用LLM-as-judge模块进行判断。LLM法官还可以利用任务执行环境产生的反馈信息，比如软件工程任务中单元测试的错误信息，来辅助判断。

三、让工作流"自我进化"的LeanEvolve机制

发现了问题只是第一步，更有价值的是能够修复问题，甚至让工作流自动变得更好。建立在FormalAgentLib之上的**LeanEvolve**，就是这样一套工作流进化机制。

LeanEvolve的工作场景是这样的：一个工作流通过了第二层的语义验证，说明它的设计在逻辑上是自洽的；但在某次实际执行中，它没有产出正确的结果。这时候LeanEvolve登场，利用第三层轨迹验证的结果，找到那个让整个任务失败的关键步骤，以及它违反了哪些谓词条件，然后把这些诊断信息提供给一个LLM代理，让它有针对性地修改那个步骤的指令描述。修改完成后，用修改后的工作流重新执行同一个问题，看看能不能解决。

这种"有根据的修改"被称为formal-guided evolve（形式化引导进化）。与之对比的是pure-LLM evolve（纯LLM进化）——后者不用任何形式化分析，直接把执行轨迹和任何可用的环境反馈丢给LLM，让它凭感觉改工作流。实验结果清楚地显示了两者的差距，但这里先按下不表，留到实验部分一并讲述。

对于像软件工程这样有丰富测试反馈的任务，LeanEvolve还可以开启"纯LLM进化"附加模式，作为形式化引导进化的补充。这个模式不依赖形式化分析，而是做更大范围的探索性修改，适合处理一些"走偏路"才能解决的问题。两种模式结合，形成了一个更全面的进化机制。

四、在真实任务上的测试：数字背后的故事

研究团队在两类完全不同的任务上测试了Lean4Agent，这个选择本身就很有意思：软件工程任务（SWE）代表了"LLM密集型"任务——工作流设计相对简单，但需要AI大量自主探索、调试和修改代码；AI论文理解任务代表了"工作流密集型"任务——工作流的精细设计直接决定了效果好坏，AI的发挥空间相对受限。

软件工程任务使用的是SWE-Bench-Verified这个基准，它收集了真实的GitHub问题，每个问题都有单元测试可以客观判定是否解决。研究团队从中挑选了50个"硬题"——那些通常需要人类工程师超过一小时才能解决的问题。论文理解任务使用的是ELAIP-Bench，包含从最新AI论文中提取的403道多项选择题，研究团队随机选取了100道进行实验。

实验的设计方式是：让一个强大的AI（Claude-Opus-4.6）生成40个候选工作流，过滤掉格式不合规的，然后对通过格式检查的工作流进行第二层语义验证，随机选取3个通过验证的和3个未通过验证的，分别用于五个主流大模型（GPT-5.2、GLM-5、Kimi-K2.5、Gemma-4-31B、Qwen-3.5-27B）在两个基准上的测试。这样的设计可以分离工作流质量的影响，也能测试结论是否跨模型稳定。

结果令人信服。在软件工程任务上，通过验证的工作流平均正确率为58.27%，未通过验证的工作流平均正确率仅为43.47%，差距达到14.80%。更重要的是，这个差距在统计上显著，95%的自举置信区间为[10.00%, 19.60%]，完全不包含零。在论文理解任务上，通过验证的工作流平均得分36.60%，未通过的27.53%，差距9.07%，置信区间[5.66%, 13.07%]同样在零以上（除了Qwen-3.5-27B这一个模型在该任务上的结果置信区间跨越了零，可能因为这个模型在此任务上基线就较强）。

一个有趣的观察是：对于参数量较小的模型，验证带来的提升效果更大。比如Gemma-4-31B在软件工程任务上，通过验证的工作流比未通过的高出了27.33%。这说明工作流质量对能力相对较弱的AI更加重要——工作流设计得好，能在一定程度上弥补模型本身能力的不足。

研究团队还额外测试了Claude 4.5 Opus，结果显示通过验证的工作流准确率67.33%，未通过的56.67%，绝对提升10.67%，证明结论能够跨不同来源的模型推广。

在LeanEvolve的效果上，五个模型在软件工程任务上平均额外解决了7.47%的问题，将综合准确率从56.93%提升到64.40%。其中Qwen-3.5-27B提升最大（10.67%），GPT-5.2次之（8.00%），GLM-5提升相对最小（4.67%）。在论文理解任务上，对比形式化引导进化和纯LLM进化的直接效果：五个模型平均而言，形式化引导的方式比纯LLM方式多解决了7.00%的初始失败案例，充分说明有了精确的错误定位，修改才更有的放矢。

五、细节揭秘：那些容易被人忽视的隐性错误

论文花了相当篇幅介绍两个具体的错误案例，这两个案例很好地说明了为什么形式化验证能捕捉到人工审查容易遗漏的问题。

第一个案例来自软件工程任务。有一个工作流由五个步骤组成：setup_and_explore（探索代码库）、reproduce_issue（复现问题）、implement_fix（实现修复）、verify_fix（验证修复）、submit_patch（提交补丁）。这五个步骤全都是task类型，也就是说每个步骤执行时都没有对话历史的记忆。然而verify_fix步骤的指令里写道，要根据之前实现的修复来验证效果——但task类型根本看不到"之前"，每次都是全新开始。FormalAgentLib通过隐式变量的信息流谓词系统发现了这个问题：verify_fix步骤需要fix_implementation_evidence这个谓词，但因为没有对话历史，这个证据实际上并不在当前的执行上下文中。解决方法很简单：把task类型改成step类型，让步骤能看到历史记录。改完之后，GPT-5.2在50道硬题上的准确率从52%提升到62%。

第二个案例来自论文理解任务。有一个工作流设计了evaluate_A、evaluate_B、evaluate_C、evaluate_D四个步骤，分别独立评判四个答案选项，听起来非常合理——独立评判能避免先入为主。然而这四个步骤使用的是step类型，也就是说每个步骤都能看到之前步骤的对话历史！这意味着evaluate_B执行时，已经看到了evaluate_A的评判过程，独立性根本无法保证。FormalAgentLib的evaluateChoicesIndependent谓词捕捉到了这个矛盾：工作流设计的意图是独立评判，但step类型的上下文共享机制破坏了这一意图。

第三个案例是LeanEvolve在软件工程任务django_15098上的表现。原始工作流在执行中，AI只看到了错误的表面症状，没有追溯到import链中的根本原因，修复方案错误，单元测试失败。第三层轨迹验证精确定位到verify_fix步骤：Lean验证确认fix_verification_evidence变量存在（非空字符串），但外部工具验证发现两个单元测试最终失败，LLM法官也确认了测试失败这一事实。诊断信息进一步指出：工作流错误地把修复当成已验证的，尽管失败的测试仍然存在。基于这个诊断，LeanEvolve修改了verify_fix步骤的指令，要求AI追踪完整的错误调用链，使用精确的FAIL_TO_PASS测试路径来验证，而不是遇到表面上的"修复成功"就停止。修改后的工作流在下一次执行中通过了测试。

六、消融实验：拆解各个组件的贡献

为了弄清楚是哪些部分真正起了作用，研究团队还做了消融实验。第一个消融实验是去掉第二层验证中的图级别谓词，只保留针对单个变量的谓词。在论文理解任务的40个工作流中，原本有21个未通过完整的第二层验证；去掉图级别谓词后，只有8个仍然失败，说明有13个工作流的错误完全依靠图级别谓词才能被检测到。最常见的违反谓词是makeUnifiedJudgement和unifiedLoopBack，这些都是只有从整个工作流图的视角才能看到的一致性要求，单看某个节点是发现不了的。这个实验有力地证明了图级别谓词的不可替代性。

第二个消融实验是在软件工程任务上去掉LeanEvolve中的纯LLM进化附加模式，只保留形式化引导进化。结果显示，去掉纯LLM进化后，平均提升从7.47%降到5.07%，减少了2.40%。说明纯LLM进化确实贡献了一部分价值，主要是在需要探索性修改或非常规解法时；但形式化引导进化才是主要驱动力，贡献了绝大部分提升。

研究团队还对比了Lean形式化验证与"LLM-as-judge"（用另一个AI来评判工作流质量）的效果。在工作流质量相对容易判断的论文理解任务上，LLM法官的评分与Lean验证结果大体吻合；但在判断标准更模糊、依赖实际执行的软件工程任务上，LLM法官的评分与Lean验证结果几乎毫不相干，而且与实际执行效果的关联也很弱。检查发现，LLM法官通常只能看到工作流的显式行为，对隐式信息流、上下文可见性、图级别谓词等深层次问题视而不见——恰恰是这些深层次问题，才是形式化验证真正能发挥作用的地方。

七、研究的局限性与未来的路

研究团队坦诚地列出了几个局限性，这让整项研究显得更为可信。大语言模型的内部行为是黑箱，无法被完全检视；Lean4Agent的方式是把它分解成可验证的步骤，并对每个步骤的语义做出假设，但这些假设本身也可能不完全准确。其次，工作流的谓词标注是由另一个LLM（Claude-Opus-4.6）自动完成的，LLM有时会标注出错误的谓词，尽管标注完成后的Lean验证是严格的，但错误标注会导致验证基础出现偏差。此外，现代大语言模型生成的工作流很少出现明显的结构性错误，这使得第一层结构验证的效果难以通过大规模定量实验来评估，目前主要靠案例研究来展示。

从更宏观的视角看，这项研究开辟了一个新方向：用具有表达能力的依赖类型形式化语言来建模和验证AI代理系统。时序逻辑等传统形式化方法无法处理数据依赖的属性；SMT（可满足性模理论）方法难以表达高阶推理；而Lean4作为一种依赖类型语言，能够同时表达数据类型依赖的性质、高阶逻辑和复杂推理链，是目前已知表达能力最强的形式化验证工具之一。将这种工具引入AI代理验证领域，是这项研究最具开创性的贡献。

说到底，这项研究告诉我们一件颇为反直觉的事：给AI"打草稿"的工作流，比AI本身更值得仔细雕琢。一个逻辑自洽、信息流清晰的工作流，能让即使能力相对一般的AI也发挥出远超预期的水平；而一个充满隐性矛盾的工作流，则会让再强大的AI也频繁犯错。研究团队用数学证明的严格性，给这个朴素的观察找到了一个可量化、可操作的实现路径。下一次当你设计一个多步骤的AI应用，也许真正值得思考的问题不只是"用哪个模型"，而是"这个工作流的逻辑真的通顺吗"。

---

Q&A

Q1：Lean4Agent验证的是什么，和普通测试有什么区别？

A：Lean4Agent使用形式化数学语言Lean4对AI工作流进行三层验证：结构层检查变量读写是否一致、流程图是否合法；语义层检查每个步骤的前置条件是否能被满足、后置条件是否会被建立；轨迹层在实际执行后检查LLM是否真的按照规格执行了。普通测试只能发现已经发生的错误，而这套方法能在运行前就发现逻辑缺陷，并能精确定位问题所在的步骤。

Q2：FormalAgentLib检测到的错误，人工审查能发现吗？

A：论文展示的案例说明，很多错误人工审查很难发现。比如把task步骤误用在需要历史上下文的场景中，或者评判选项的步骤因为使用了step类型而失去了独立性——这些错误不看执行类型的底层语义就很难察觉。实验中LLM法官（用GPT-5.5来评判工作流质量）在软件工程任务上和实际执行效果几乎没有关联，说明这类深层次的隐性矛盾确实超出了一般评审的感知范围。

Q3：LeanEvolve是如何自动修复工作流的，它每次都有效吗？

A：LeanEvolve利用第三层轨迹验证的结果，找到具体失败的步骤和违反的谓词，把这些诊断信息交给LLM来修改那个步骤的指令，然后重新执行。它不是每次都有效，实验显示平均额外解决了7.47%的问题，对于需要追踪完整错误链或跨文件修改的情况效果最好。对于那些需要非常规探索才能解决的问题，LeanEvolve中附加的纯LLM进化模式会补充更广泛的修改尝试，两者结合比任何一种单独使用效果都更好。