\n\nMistral推出Leanstral，利用形式验证实现代码自动化审计，旨在消除人工复核瓶颈。专家指出，尽管其具备数学级准确性，但在缺乏业务上下文的情况下，人工干预在把控风险方面依然不可或缺。
译自：Mistral’s Leanstral wants to kill off human-in-the-loop code checks, but is it blowing in the wind?
作者：Adrian Bridgwater
就在技术行业将“人在回路（Human-In-The-Loop）”这一术语正式化之际，全球自动化游说团体正寻求在尽可能多的 AI 领域将该术语推向过时。
今年 3 月，法国生成式开发专家 Mistral AI 推出了 Leanstral，这是一个开源代码智能体，旨在打破软件工程中的“人工评审瓶颈”。在我们探究该工具的有效性、质疑其潜在的未知数和未来发展轨迹之前，让我们先回顾一下它的工作原理。
形式验证，数学证明
Leanstral 使用形式验证过程，通过数学方式证明任何给定的代码段都能完全按规范运行，且行间不隐藏任何细微（或无关紧要）的漏洞。该智能体使用 Lean 4 编程语言和交互式定理证明器，作为其构建机器可检查证明能力背后的逻辑引擎。
Mistral AI 团队表示：“我们预见到了更实用的新一代编程智能体，它们既能执行任务，又能针对严格的规范对其实现进行形式化证明。人类不再需要调试机器生成的逻辑，而是直接下达他们想要的需求。”
Leanstral 内部运行的 Lean 4 采用了高度稀疏的架构，并利用并行推理（即多个计算同时发生），这使其适用于航空航天、密码学和前沿数学等高风险的任务关键型部署。其输出不仅具有合理性，而且在数学上是有保证的，并且经过训练可以在现实的形式化仓库中运行。
在架构上，Leanstral 采用了混合专家（MoE）模型，总参数量为 1190 亿，但为了提高效率，只有 65 亿个激活参数。该技术以 Apache 2.0 许可证发布，开发者可以通过免费 API 和 Mistral AI 自身平台访问。该团队声称 Leanstral 的表现优于包括 Qwen、Kimi 和 GLM 在内的开源模型，并进一步表示其表现超越了 Claude 4.6，且成本更低。
随风飘逝？
尽管 Mistral AI 的 Leanstral 据称在数学上极其严谨，但在实际部署中，这项技术能有多完美呢？正如该技术以吹过普罗旺斯的著名法国风命名一样，当应用于实际生产环境时，Mistral 能保证其根基稳固吗？
也许我们需要记住，这不是一个创造完美代码的承诺；这是一个“如果人类开发者（还记得人类吗？）首先设定了完美的应用规范，就能创造完美代码”的承诺。应用规范可以是严谨正式的，但也同样可能是不可靠的。
“形式验证可以证明代码符合规范，但 AI 风险很少只存在于数学中；它存在于规范是否完整、是否具备上下文以及是否符合现实。”—— Judah Taub。
X 射线（应用）规范
更脆弱的规范可能会产生，原因可能是用户未能详细传达应用或数据服务需求，或者是开发需求团队未能与足够的利益相关者沟通，以确保产品构建符合用途。规范也可能因为缺乏版本控制和范围蔓延而失效，即：开发者应该根据当前且正确的指令进行构建，而不是根据未能考虑边界情况处理（可能发生罕见错误状态的情况）的过时概念性指令。
即使将数学上最完美的编程智能体放在错误的航道、错误的船上，你最终也只会到达一个“完美错误”的地点。
Mistral AI 告诉我们，Lean 4 证明助手能够表达复杂的数学对象，如完备空间（perfectoid spaces，连接不同领域的复杂算术几何空间），但这些完备空间需要对准正确的北极星。
Hetz Ventures 的创始人兼管理合伙人 Judah Taub 曾是一名以色列情报官员，也是政府在 AI、网络安全和国防战略方面的顾问。Judah Taub 告诉 The New Stack，Leanstral 是向更快、更自动化的软件开发迈出的切实一步，但它并未消除对人类判断的需求。
“形式验证可以证明代码符合规范，但 AI 风险很少只存在于数学中；它存在于规范是否完整、是否具备上下文以及是否符合现实。在生产环境中，边界情况、不断变化的需求和意外后果依然至关重要。这并非‘人在回路’的终结，而是向更高层次监督的转变，由人类来定义‘正确’究竟意味着什么，” Judah Taub 说道。
切换语言，注意差距
Charles Jasthyn De La Cueva 在其今年 3 月创建的 Open-TechStack 网站上撰文，解释并澄清了一个关键考虑因素。重要的是，De La Cueva 提醒我们，就 Leanstral 的基因而言，其领域是 Lean 4……因此，如果开发团队的代码库是用 Rust、Python 或 TypeScript 编写的，Leanstral 并不能直接验证这些代码。
“你用 Lean 编写规范和实现，获得经验证的版本，然后翻译成你的目标语言。证明过程给了你信心，但在‘在 Lean 中证明正确’和‘在你的生产语言中保持正确’之间仍然存在差距，”他写道。
“随着我们增加代码量，我们也增加了风险的表面积。我怀疑开发者和商务人士在短期内都需要大量的人类判断，才能搞清楚如何在任何复杂系统中思考这些风险。”—— Alation 首席执行官 Satyen Sangani。
现实情况是，鉴于目前机器生成的代码量庞大，公司已经在利用智能体进行代码评审。数据智能平台公司 Alation 的首席执行官兼联合创始人 Satyen Sangani 告诉 The New Stack，这些智能体的可靠性完全取决于它们所拥有的上下文。
“这种核心上下文需求意味着智能体需要知道必须遵循哪些特定于业务的规则（这包括那些不在原始产品需求文档中的规则），” Satyen Sangani 说道。“智能体还需要知道这段新代码会引入哪些可能的风险，以及还存在哪些其他智能体。随着我们增加代码量，我们也增加了风险的表面积。我怀疑开发者和商务人士在短期内都需要大量的人类判断，才能搞清楚如何在任何复杂系统中思考这些风险。工程师可能不需要做那么多细致的代码评审，但他们绝对必须不断思考风险，并为系统提供越来越多的上下文。”
重新定义“人在回路”
也许我们需要回归的问题是，“人在回路”是否适用于所有场景？Sumo Logic 的基础设施和数据全球主管 Eric Avery 告诉 The New Stack，今天应该将“人在回路”视为一个“固定变量”。这意味着问题必须变成“人在回路的哪个环节”，而不是是否有“人在回路”？
“虽然有一天我们可能会实现真正镜像人类大脑的神经网络，但我们现在还没到那一步，” Eric Avery 说道。“在那一天到来之前，总会有人参与其中，无论是设定智能体的功能、监控和维护智能体，还是在流程中的设定间隔内为功能或合规性要求对其进行引导。”
他进一步沉思道，AI 的消耗是由使用驱动的，即使我们想想象自己运行在一个 AI 采用成熟的世界里。Eric Avery 强调，许多用户仍处于技能重塑、技能提升的过程中，并在各自的 AI 旅程中犯错，这导致了消耗膨胀，无论使用何种工具、数据架构或基础设施。
未来的因素与弱点
Mistral AI 最初对其免费层级保持开放，但随着风向（抱歉，这是最后一个关于风的俏皮话）在 Leanstral 用户群中刮起，该公司对于将如何改变其定价结构可能一直保持得比较保守。
更谨慎的观察者可能还会建议，由于我们目前正处于这套工具集的早期阶段，在数学验证与跨复杂、现实世界分布式计算环境的大规模安全合规部署之间，逻辑上仍会存在差距。
Mistral AI 声称，手动验证代码所需的时间和专业知识已成为当今“工程速度的主要阻抗”。但对许多人来说，在 AI 驱动的代码生成世界里，人在回路将被视为核心支柱（lynchpin），而非瓶颈。
