航空安全规范如何破解AI幻觉：从DO-178C到LLM Agent容错实践

Karpathy最近聊到一个让很多人愣住的观点他说软件本身正在被AI改写但真正让他感兴趣的是三十多年前航空业给软件写下的那套安全手册——一套原计划用来约束机载软件的规范居然意外成了眼下治理AI废话幻觉最靠谱的思路之一。这话初听有点绕一个AI大模型跟飞机上的电传飞控系统能有什么关系可你要是见识过AI Agent自作主张改代码、编文档、信誓旦旦给你一个错误结论的场面大概就能明白他为什么非要把四十年前的航空规范翻出来不可。这篇文章想跟你聊清楚三件事第一为什么大模型一出口就自带自信的废话;第二航空软件那套可靠性规范到底写了什么凭什么能拿来约束AI第三落到你自己的Agent或LLM应用里哪些做法可以直接照搬哪些只能借鉴思路。我自己在LLM智能体项目里也踩过不少坑文末会把一些踩坑记录一并放出来供你参考。1. Karpathy提航空规范到底戳中了AI的哪个痛处1.1 大模型的废话体质幻觉不是bug是默认行为几乎所有接触过大模型的人都遇到过这种情况你问它一个自己专业领域内的问题它答得头头是道引用的数据、论文标题、API参数看起来都无比真实结果一核对出处是编的参数是混的。更麻烦的是它自己并不知道自己在编。很多人把这种现象叫幻觉听起来像是一个可以修的bug。但你要明白一点LLM的底层目标函数是预测下一个词的概率分布它从头到尾就没打算保证字面内容与现实一致。语言流畅性和事实正确性是两套逻辑而大模型优化的是前者。换句话说一本正经胡说八道不是模型的异常状态而是它的默认状态。我经常用一个类比跟团队解释这件事普通人说话大脑里有一套事实检查器说错了会感到违和但大模型没有这个违和感机制它只有语义连贯性检查器。对一个句子是否为真的判断在它那儿本质上是这个句子跟前面内容搭不搭、像不像人类会写的句子的概率计算。Karpathy长期强调的一直是大模型也是软件这一层认知。既然是软件就得按软件的规矩来对待。航空业就是被听话的机器在有明确目标的情况下照样可能出错这个问题折磨了几十年最终磨出了一整套对付不确定性的方法论。1.2 航空安全代码为什么能让AI脸红航空软件的可靠性要求和普通软件完全不是一个量级。一架飞机的飞控系统如果出bug不是弹个崩溃窗口的问题是人命。所以航空业很早就意识到你没法证明代码绝对正确你只能在工程过程上堆积证据让出错概率被压缩到可以接受的水平。这套思路在四十年前被固化成了DO-178标准后来又演化成DO-178C。它的核心逻辑不是我们的代码没bug而是我们有一套流程能保证每个bug都会在特定阶段被拦截而且这个过程可审计、可回溯。你把这个标准往AI上一套就会发现一个尴尬的对照我们验收一个LLM应用时常常只看它能完成多少任务几乎不关心它有多少次在悄悄编造论据它在什么边界条件下会执行危险操作出错了有没有完整的日志链条可以回放。这些东西在航空软件里全是硬性要求在AI工程里却经常被当作可选项。1.3 为什么偏偏是现在才把这个话题重新翻出来其实四十年前的规范放在五年前的AI圈没人会觉得有参考价值。那时候大模型主要是聊天玩具胡说八道的代价很低——最多就是被用户嘲笑两句。但今天不一样了。AI Agent开始被赋予执行权让它调用API、让它写代码、让它操作数据库、让它自动回复邮件。错误不再只是文本层面不好看而是实实在在的系统事故。一个Agent若是在缺少约束的情况下生成了一段看似合理的SQL并直接执行后果跟飞机上一个传感器数据被错误放大没有本质区别。Karpathy表达的核心意思就是AI正在从生成内容走向执行动作。内容错了可以重生成动作错了可能没法重来。责任越大对工程纪律的要求越高。这时候回头看航空规范会发现它早替你回答了一个问题当系统不可避免地会出错时你怎么设计组织流程让每个错误都处于可控范围。2. 40年前的航空规范到底写了啥以DO-178C为核心拆一遍既然要借鉴就得先搞清楚航空规范里到底有什么可借鉴的。这里以DO-178C作为主线因为它不只是文档要求更是一套完整的软件开发治理框架。2.1 DO-178C在航空软件里管的那些事DO-178C的全称是《机载系统和设备合格审定中的软件考虑》由RTCA航空无线电技术委员会发布最早可以追溯到1982年的DO-178版本。它本质上是给机载软件的开发方和适航审定方之间搭了一套对话框架。它要求软件生命周期必须明确定义并且做到每个阶段都有输入、输出和客观证据。开发一个机载软件你需要证明的事情包括每个高层需求都被追踪到了低层需求和代码实现每个代码实现都被测试覆盖到了每个测试用例都跟具体需求有对应关系所有缺陷都有分类、有记录、有关闭证据变更会重新触发完整的回归验证而不是只测改动那几行。听起来很朴素但执行起来非常重。它真正逼迫软件开发团队改变的不是写更多文档而是每一步都留下了可以被别人复核的证据。2.2 五个等级和目标-证据模式的精髓DO-178C最出名的概念是五个软件等级用开发保证等级DAL表示从A到E递减软件等级失效可能的影响典型系统DAL A灾难性影响可能造成人员伤亡飞控主系统、发动机控制DAL B危险影响严重伤害或任务失败起落架控制、导航系统DAL C主要影响系统功能显著下降客舱环境控制DAL D轻微影响功能有所降低机内娱乐系统DAL E无安全性影响非安全相关工具软件等级越高对过程目标的要求越严。DAL A级的每一行代码都要有需求追溯要有结构覆盖分析要用独立于开发团队的验证团队去做确认。DAL E则几乎不需要专门的过程保证。这套体系最值得AI从业者学习的不是分五级的形式而是它背后的一个原则安全投入要与失效后果成正比。你做一个内部知识库问答机器人和做一个自动给客户回信、自动申请退款甚至自动执行网络交易的Agent承担的失效后果完全不同所以工程保证的强度也应该拉开差距。而不是一刀切地所有AI应用都跑一次基准测试就行。2.3 航空规范本身也在与时俱进很多人以为DO-178C是几十年前的死规矩其实它在2011年才发布C版而且专门增加了三个配套文件来应对新技术的挑战DO-330是工具鉴定要求DO-331是基于模型的开发补充DO-333是形式化方法的补充。这些补充文件说明航空业自己也在思考一件事当代码开始由更抽象的工具生成当系统复杂到人没法逐行审查时你怎么保证可靠性形式化方法就是其中一条路。它要求用数学语言描述系统行为然后用定理证明或模型检验来证明某些错误不可能发生。放到AI语境下你可以把它翻译成一个更实际的请求如果某个LLM Agent的输出结果违反了预定义的不变量比如金额不能为负文件路径不允许越界系统必须有一道不依赖模型自觉的硬闸门把它拦下来。航空规范强调的正是这种不信任单一组件只信任系统级约束的思路。3. 把航空精神移植到LLM从说废话到不敢说废话理念听再多也没用关键还是怎么落到工程里。我按照航空软件的核心实践逐一映射到LLM应用的日常开发流程里你完全可以抄作业。3.1 先治需求病给LLM写正式的软件需求规格说明我见过太多LLM项目几万字的产品需求写得头头是道但你问工程师这个Agent在用户输入模糊时应该怎么办API调用失败时回退策略是什么答案通常是看提示词怎么写。提示词不是需求规格说明书。航空软件对需求的要求是无歧义、可验证、有唯一标识。你现在去翻自己的prompt里面大概率充满了更好地适当地合理地这类航空标准里会被打回重写的词。我的建议是给每种关键Agent行为建立一张需求表每条需求至少包含前置条件、触发动作、期望输出、失效处理。举个例子需求IDR-QUERY-001前置条件用户查询里包含数据库表名触发动作生成SQL查询语句期望输出SQL可被解析且只含SELECT操作失效处理如果生成结果无法通过解析器校验拒绝执行并返回无法生成有效查询的固定文案把这样的需求表固化下来之后提示词只是实现方式之一而不是全部。它真正的价值是当模型行为偏离预期时你能定位到是哪一条需求在执行中失效了而不是玄学式地微调提示词。3.2 形式化验证与不该说的话约束航空里的形式化验证是拿数学工具证明程序状态不会进入危险集合。放到LLM上我们暂时做不了完整的数学证明但可以做两类很实在的约束。第一类是输出结构约束。不要依赖模型自觉遵守格式要用程序保证格式。比如要求Agent返回JSON时直接上JSON Schema校验要求它选择工具时直接把可选工具列表限定死而不是让它自由发挥函数名。这类约束的本质是把模型的自由文本输出降维成受控的结构数据让模型在内容层面可以有想象空间在动作层面没有想象空间。第二类是动作白名单约束。金融类Agent不允许输出涉及转账金额超过X的操作代码类Agent不允许执行rm -rf或drop table语句。这些约束不写在提示词里乞求模型遵守而是写在执行层的拦截器里硬编码生效。航空规范从来不会说飞行员请自己注意安全它会把危险操作从设备层面就锁死。3.3 运行时监控与独立冗余让AI学会自我怀疑航空系统里最经典的设计是冗余多套独立通道同时工作如果输出不一致系统会判定故障并走安全路径。LLM Agent完全可以借这套思路。我实践下来比较有效的一个模式是双模型验证主模型负责生成动作另一个更小、更保守的判别式模型负责校验动作是否符合预期。比如生成一段代码后用代码AST解析器或静态分析工具做独立校验生成一个SQL后用SQL解析器做语法和语义检查。关键是验证器不能和生成器共用同一套参数和思维模式否则它的判断和生成器一样会犯同样的错。这里的成本肯定会上升但你可以分级控制。低风险操作只做结构校验高风险操作比如执行写操作、发邮件、调用支付接口强制启用第二意见一致性不达标的直接终止任务并把完整上下文存档。3.4 严格的回归测试与数据覆盖面回归测试在LLM应用里是个经常被低估的环节。模型端的升级、提示词的改动、底座的切换都可能让一个原本正常的行为突然变异。如果不做回归很多问题会延迟到线上才爆发。我建议团队建立三类回归集黄金输出集整理一批典型输入与期望输出的对照数据每次改动都跑一遍用自动化方法评估输出漂移边界偏移集专门覆盖模型容易越界的输入场景比如诱导攻击、超长上下文、矛盾指令、跨语言提问故障注入集模拟API超时、上游返回垃圾数据、并发冲突等异常环境验证Agent的降级逻辑是否正常。航空软件最狠的地方在于它要求每次变更都重跑全部验证不管你的改动是改了一个变量名还是换了一个算法。LLM应用也应该保持这个不信任增量的态度——你以为只改了一个标点模型的行为可能已经漂移了不少这不是夸大其词。4. 从规范到落地一个LLM智能体自主容错控制框架的粗实践光说不练不行。我的团队在一个内部业务Agent项目里按照上面的思路搭了一个简化版的容错控制框架用了一段时间效果确实比裸奔状态稳定得多。这里分享一下框架结构和实测中遇到的问题。4.1 三层容错架构计划-执行-验证我们借鉴的核心理念可以概括成LLM智能体自主容错控制给Agent装一道独立于大脑的神经系统在感知到异常时触发自身的容错机制而不是依赖模型自己意识到错误。架构上看三层规划层负责把用户目标拆解成子任务输出结构化计划同时将每条计划映射到需求表里的相关条目执行层根据计划调用API、工具或代码片段所有执行动作都必须经过白名单和参数校验验证层独立于前两层校验执行结果是否符合预期并决定继续、重试、回滚还是终止。伪代码逻辑大概是这样def agent_run(goal): plan planner.generate(goal, constraintsREQUIREMENT_TABLE) if not validate_plan(plan): return SAFE_ABORT(plan violates constraints) for step in plan: action executor.prepare(step) if not gate_check(action): # 白名单、参数范围、权限校验 rollback(step) continue result executor.execute(action) verdict verifier.check(result, expectedstep.expectation) if verdict.confidence EXECUTE_THRESHOLD: # 降级路径先回滚再尝试弱化版本的操作 rollback(step) degraded_result executor.execute(degrade(step)) if verifier.check(degraded_result, SAFE_FALLBACK): record_failure_mode(step, verdict.reason) continue else: report_abort(goal, step, verdict) return SAFE_ABORT(verifier rejected step)这套结构最大的好处是每个环节都有明确的责任边界。生成、校验、执行、回滚是四个独立的组件谁出错都有对应的处理路径。这比大型提示词里反复强调请谨慎行事要靠谱得多。4.2 落地细节契约定义、验证器选型、告警策略具体操作上有几个细节值得展开说。契约定义方面我们把每个工具调用的输入输出都做成JSON Schema并且把invariant单独抽出来。比如一个发邮件的Agentinvariant之一是收件人字段必须来自通讯录名单不能来自模型自由生成的文本。这些invariant不放在提示词里而是放到执行层的schema checks里。验证器选型上我们尝试过三种方案让大模型自查、让同模型复述判断、用小模型独立判断。结论是大模型自查基本无效它倾向于维护自己的原结论同模型复述判断会多消耗一次推理也没有本质提升独立小模型在格式校验参数合法性行为分类这类任务上表现稳定且推理成本低很多。说白了验证任务尽量交给判别式模型生成任务才交给生成式模型各干各擅长的活。告警策略上我们参考了航空系统的报险caution不报错warning分级。轻微偏离只记录日志不打断流程中等偏离会降低该步骤的信心权重要求更多步骤的交叉确认严重偏离直接终止任务并触发人工复核流程。所有告警都进入一个失效模式库持续积累作为后续测试集的种子。4.3 实测中踩到的坑这个框架落地过程中我们踩了三个比较有代表性的坑写出来供你绕开。第一个坑是双模型冗余的成本被低估了。你以为只是多调一次模型实际上验证器模型需要单独部署、单独调优、单独监控初始化阶段的工作量并不小。建议先只在最高风险的几个操作上启用验证器不要一开始就全量铺开。第二个坑是回归集膨胀导致的死锁。回归集越来越多每次底层模型升级都要全量跑跑完发现一批老用例行为漂移又要逐个判断是模型退化还是测试预期过时。这个治理成本非常高我们最后给回归集加了时间戳和分级标记只有跟当前业务强相关的用例才强制全量跑。第三个坑是最隐蔽的我们一度试图让主模型自己产出验证规则它产出的规则和它的行为模式天然同构等于让运动员自己当裁判。后来我们把验证规则全部改成团队人工编写、维护在独立代码库里效果立刻就不一样了。5. 航空规范不是银弹哪些能抄哪些不能硬搬最后必须泼一盆冷水。航空规范给了AI很好的治理思路但它不是灵丹妙药有些东西能抄有些东西强行照搬只会把团队拖垮。5.1 不能照搬的部分第一认证成本。DO-178C的DAL A级项目文档和证据链的耗费往往远超编码本身人力成本以人年计算。LLM应用迭代速度是周级的如果每个改动用同样重量级的流程来管你的Agent永远别想上线。第二穷尽性测试思路。航空软件可以通过需求表推导测试用例因为需求是确定的系统规模也是有限的。LLM的输入空间是开放的你根本不可能列完所有可能的用户输入。所以不能用覆盖率100%的目标来要求AI测试一个务实的替代是关键风险路径覆盖加边界事故注入。第三人工介入流程。航空审定里大量依赖人工评审和签章这在一个需要秒级响应的Agent系统里不现实。AI场景更适合自动拦截事后人工抽审的组合把人的精力用在异常样本复盘上而不是逐单审批。5.2 值得借鉴的三个习惯FMEA失效模式与影响分析思路很值得引入。每次Agent在线上胡说八道导致问题后不是骂完模型就完事而是把这次失效完整记录成一条失效模式档案包括触发场景、模型输出、校验层为什么放行、最后如何发现。积少成多这张表就是你治理Agent靠谱程度最值钱的资产。报险文化值得借鉴。如果团队成员在代码评审里说这个Agent突然从一个没人问过的角度回答了问题不要当成小概率事件忽略。要营造一种氛围任何异常的Agent行为都是值得记录的险情哪怕没有造成实际损失。小步变更也要学。航空业对任何软件变更都极其谨慎是因为他们知道变更本身是风险源。LLM应用也一样提示词的每次修改、每次模型底座切换都走一次变更记录、回归测试、上线监控的固定流程。宁可慢一点不要悄无声息地改完就上。5.3 最重要的态度转变AI工程师不是驯兽师我在这个项目里最大的体会是心态层面的转变。很多人把调优LLM当驯兽——多说点好话它就听话换一种话术它就不闹。但驯兽师没有责任保证野兽永远不失控而工程师有。Karpathy反复强调的software is changing这句话我现在的理解是AI确实让软件系统的构建方式发生了巨变——从明确指令变成自然语言对话从确定性逻辑变成概率生成。但工程的核心命题没有变你构造的系统必须在真实世界里稳定完成它承诺的职责哪怕内部组件并不完美。航空规范给AI最大的礼物不是那些具体的文档模板或流程表格而是那一句刻在骨子里的信条可靠性不是靠某个组件永不犯错来实现的而是靠整个系统即使在一个组件犯错时也能安全运行来实现的。这句话我希望每个正在构建AI Agent的人都能抄在自己的需求文档第一页。最后分享一个我个人实操中的小技巧。如果你暂时没条件搭完整的验证框架可以先从上一季度事故清单入手把团队记录的AI翻车案例整理成一块禁忌知识库在Agent每次决策前先注入这块知识再配合几条硬编码的拦截规则。这算是最轻量级的失效模式库起步方案。做完这一步你再看Agent的行为会发现它至少开始知道什么不该说了。这比盲目追求更强的模型来得实在。