开头我先说一个真实场景。去年我在评审一份TARA（威胁分析与风险评估）报告时，发现整份文档已经是第4版，但危害清单里仍有两条与SOTIF（预期功能安全）场景重复，还有一处信息安全资产的分类与功能安全里的"安全相关项"直接冲突。这种事在传统交付流程里太常见了——三个标准域由三拨人分别维护，文档间靠人工对齐，而初稿阶段的体力活几乎吞掉了工程师的全部精力。这就是这篇文章想聊的核心：REANA，一个把汽车功能安全、SOTIF与信息安全揉成"三安一体"的智能体平台，它的核心思路不是让AI把报告写完，而是把"人建模型"变成"Agent建初稿"，让人把精力留给真正需要判断的地方。我会从三安一体的难点、REANA的架构落地方案、实测产出质量、生产化避坑四个角度讲透这个项目，适合正在做功能安全/信息安全交付团队、做安全工具链开发、以及所有关心Agent怎么在合规领域落地的朋友阅读。
1. 为什么"人建模型"撑不住了：三安交付里的打字疲劳
先讲一个更普遍的痛点。做过功能安全交付的朋友都知道，ISO 26262（道路车辆功能安全）、ISO 21448（预期功能安全，SOTIF）、ISO 21434（道路车辆网络安全）这三份标准，每一份都要求一整套生命周期文档。Item Definition、HARA（危害分析与风险评估）、功能安全概念、TARA、安全目标、安全概念、验证报告……一个中等复杂度的域控制器项目，这些文档加起来轻松超过一千页。
而这些文档里有大量的"建模"工作：把系统拆成功能模块、把运行场景枚举出来、把危害事件和风险等级对应起来、把威胁路径与攻击树画出来。过去我们真的是一个人坐在电脑前，一行一行地把这些模型"建"出来。
1.1 一次HARA评审会暴露的时间黑洞
我印象很深的一次会议，是给一个L2+级智驾域控制器做HARA。我们团队花了两周时间，梳理出37个运行场景、28条危害事件，然后逐条开会讨论ASIL等级（汽车安全完整性等级）和可接受风险。会开到一半，功能安全经理突然发现：场景清单里漏了一条"雨夜对向远光灯眩目"的情况——这个问题其实应该归属SOTIF分析域而不是传统功能安全域。
于是，SOTIF工程师重新拉了一轮分析，又花了一周。而信息安全同事也提了个意见：有一条威胁路径依赖"云端OTA升级包被篡改"，这条路径在HARA里是用"不可用"来描述的，但在TARA里需要被识别为"机密性/完整性破坏"事件，两个域对同一个事件的描述和等级划分完全对不上。
这个会议让我意识到一个结构性问题：初稿阶段的纯体力劳动，已经变成了交付瓶颈。枚举场景、整理清单、做初步的风险分级、把术语对齐——这些事情并不需要深度判断，但极其耗时，而且极易因为人的疲劳而遗漏。
1.2 初稿工作占掉了工程师八成精力
我粗略统计过自己团队在某个域控制器项目上的工时分布：从拿到系统需求描述到产出第一版可评审的安全/信息安全文档，大约需要六个工程师×三周时间。如果把"整理场景清单、起草安全目标、初步分级、跨域术语映射、格式排版、追溯性矩阵维护"这些工作称为"初稿构建"，真正花在"风险是否可接受""某个安全目标定得是否合理""这条威胁路径的可行性"这类判断上的时间，其实只占两成左右。
这个比例很不健康。判断是安全工程师的核心价值，但初稿构建却把我们的时间全吃掉了。更麻烦的是，初稿的质量直接决定了后续评审的效率——初稿如果漏了场景、分错了等级，评审会就会变成一场低效的"补漏"大会，而不是"决策"大会。
所以当我开始思考能不能用Agent来干活时，我的第一反应不是"AI能不能写文档"，而是"AI能不能先把初稿建出来，把这些体力劳动接过去"。
2. "三安一体"真正的难点不在标准多，而在域冲突
很多不了解行业的人会觉得，把功能安全、SOTIF、信息安全放在一个Agent里，无非是把三份标准的内容灌进大模型里让它生成文档。真做过的人才知道，问题远不是"知识量"够不够，而是这三个域之间存在大量术语、方法论、边界上的冲突。
2.1 三个标准的三套语言体系
先列一个最基础的对照表，你就能直观感受到这种割裂：
| 维度 | ISO 26262（功能安全） | ISO 21448（SOTIF） | ISO 21434（信息安全） |
|---|---|---|---|
| 关注对象 | 系统性故障、硬件随机失效 | 预期功能不足、性能局限、误触发 | 恶意攻击、威胁、漏洞 |
| 核心分析入口 | 危害（Hazard） | 触发条件/场景（Triggering Conditions） | 威胁（Threat） |
| 风险表达式 | 严重度×暴露率×可控性 | 场景概率×触发条件严重度 | 攻击可行性×影响 |
| 输出物类型 | HARA、FS、TSR | SOTIF分析报告、安全论证 | TARA、安全概念 |
| 关键词汇 | ASIL、安全目标、故障 | 功能不足、性能局限、可接受风险 | STRIDE、攻击树、安全事件 |
如果你把这三份标准的术语表直接合并，会立刻发现一大堆撞车：功能安全和信息安全都谈"风险"，但计算方法完全不同，一个基于严重度/暴露率/可控性，一个基于威胁可行性与影响；功能安全里的"危害"和信息安全里的"威胁"经常描述同一个物理事件，但分析路径和要求的产品属性完全不一样。
2.2 边界交叉地带最难：一个场景，三个人抢着分析
真正的难点在交叉地带。比如一辆带有ACC（自适应巡航）功能的车辆，在雨夜传感器性能下降时前车急刹车，系统未能及时制动——这个场景里：
- 功能安全工程师会问：传感器故障导致信号丢失，这是A/D转换失效还是供电故障？ASIL等级是多少？
- SOTIF工程师会问：传感器没有故障，但算法在雨天场景下性能降级，这就是预期功能不足，需要评估触发条件和可接受风险；
- 信息安全工程师会问：有没有可能攻击者通过注入虚假传感器数据来"制造"这种制动失效？攻击路径是什么？
同一个物理事件，三个域的分析逻辑完全不同。传统做法是"各自分析、线下对齐"，但这带来两个问题：一是分析重复（三个人都要枚举同一套场景），二是输出不一致（同一个事件在HARA里叫危害H1，在TARA里叫威胁T3，两个编号之间没有自动追溯关系）。
2.3 为什么"一体"要求先建设备场景本体
要让Agent真正把"三安一体"做起来，第一步不是写Prompt，而是建设一个"设备场景本体"（Ontology）。简单说，就是让三个域共享同一棵"场景树"：一个场景节点在根上只有一次定义，但它可以同时被注册为功能安全分析对象、SOTIF触发条件和信息安全威胁入口。
我用生活化的方式解释一下：就像一栋楼的消防系统，同一个"厨房火灾"事件，消防工程师关心火源和灭火器位置，结构工程师关心楼板耐火等级，安防工程师关心是否有人纵火。三个人如果各画各的图，一定对不上；但如果先有一个"房间-火源-损失路径"的公共模型，每个人只需要标注自己关心的属性。
REANA在设计上就把"场景本体"作为三安一体的地基。系统先解析车型和功能描述，自动生成功能清单、运行场景、环境因素序列、人机交互事件，然后不同的Agent基于这棵公共本体分头分析，最后再自动合并出跨域追溯矩阵。这一步是整个工程里最关键、也最容易被忽略的——没有本体，多Agent做得再精致，产出也还是散的。
3. REANA的落地方案：多Agent协作、知识库与Skill封装
理解了域冲突之后，再来说REANA的架构选择。这里有一个核心判断：为什么要用"多Agent"而不是把三个标准塞进一个大模型的单次Prompt？
答案和"harness和agent区别"这类问题其实同源。单个大模型在同一段上下文里既要当功能安全专家、又要当SOTIF专家、还要当信息安全专家，结果往往是谁都当不好——因为三个域的术语和推理逻辑会互相干扰。在Agent工程里，这叫"上下文角色污染"。而多Agent的本质是让每个专家Agent只干自己那一摊事，通过明确的输入输出接口协作，而不是在同一个上下文里混战。
3.1 框架选型：为什么选择多Agent编排，而不是单Agent硬扛
我们调研过的路线有三条：
- 单Agent + 大上下文窗口：把三份标准、系统描述、历史项目案例全塞给一个大模型。这条路的优点是简单，缺点是上下文一长，模型会"遗忘"前面关键约束；而且三个域的分析相互干扰，输出经常出现"用信息安全逻辑做SOTIF分级"这种张冠李戴。
- 单Agent + 外部工具调用：让Agent自己决定调用哪个域的检索接口。这比纯单Agent好，但问题在于分析流程是线性的，一个Agent很难同时在一份文档里维护三个域的并行视角。
- 多Agent编排：每个域一个"领域Agent"，中间有一个"协调Agent"负责拆任务、合并结果、统一术语。这是我们最终选择的路线。
REANA采用第三种方案，具体结构类似这样：
- 项目解析Agent：读取系统需求描述（SysML/自然语言），生成本体化的功能/场景清单。
- 功能安全Agent：基于场景本体做HARA，输出危害事件清单、ASIL分级初判、安全目标草案。
- SOTIF Agent：基于同一场景树识别预期功能不足和触发条件，输出SOTIF分析报告初稿。
- 信息安全Agent：基于STRIDE方法做TARA，输出威胁清单和安全概念草案。
- 三安协调Agent：负责把三份初稿合并为一份跨域报告，同时自动生成追溯矩阵，把"同一场景在三域中的编号"对齐。
这几个Agent之间不是简单的"各写各的"，而是通过一份共享的中间产物——场景本体JSON——协作。功能安全Agent发现的新场景会回写本体，SOTIF Agent和信安Agent能自动感知并补充自己在同一场景上的分析。
3.2 领域知识库与检索：安全标准不能靠模型记忆
大模型天然会"自信地胡说"，而安全标准恰恰是最不能容忍幻觉的领域。我见过最离谱的一次测试：让一个大模型直接引用ISO 26262第6部分的条款号，它编了一个根本不存在的"第8.4.2条关于A/D转换的ASIL C要求"，看起来煞有介事，实际是幻觉。
所以在REANA里，所有涉及标准条款的内容都不允许模型凭记忆生成。我们为三份标准分别构建了RAG知识库，拆粒度到"条"级别，并把每一条的上下游关联关系也存进去。当功能安全Agent需要判定某个危害的ASIL建议时，它会先检索知识库里相关条款和典型示例，再基于检索结果生成。生成时，输出里会强制带引用来源标记（标准编号+条款号），没有来源标记的断言会被后处理关卡直接拦截。
这个设计是从一个很痛的教训里来的：早期版本有一版HARA初稿，把"ASIL B的严重度"定性搞错了，导致下游的硬件开发计划全都基于错误的指标展开，返工成本非常高。标准检索+强制引用，是为了让Agent"说每句话都有据可查"。
3.3 把HARA、TARA、SOTIF分析流程封装成Agent Skill
另一个让我们少走弯路的决策，是把分析方法论封装成Skill，而不是让Agent"自由发挥"。
比如HARA这个Skill，内部流程是固定的几个步骤：
- 从场景本体读取"运行场景+人员行为+环境条件"的组合；
- 针对每个组合故障模式，推导可能的危害事件；
- 按严重度S、暴露率E、可控性C三维逐项评估；
- 查ASIL分级表，给出初判等级；
- 从安全知识库检索可参考的安全目标模板，生成初稿。
把流程"硬化"成Skill，带来两个好处：一是Agent不会跳过步骤漏分析，二是结果格式统一，后面评审和追溯都好做。相比之下，如果只是给Agent一个"你是功能安全专家，请做HARA"的Prompt，它输出的内容经常结构混乱，甚至漏掉ASIL里最关键的三个维度之一。
TARA Skill走的则是另一套流程，基于STRIDE模型（欺骗、篡改、否认、信息泄露、拒绝服务、权限提升），逐条分析资产、威胁场景、攻击路径、可行性与影响等级。SOTIF Skill重点在触发条件识别和"已知/未知场景"的分类框架。每个Skill都包含输入schema、分析步骤、输出schema，这样三个Agent各自的输出可以被协调Agent稳定地合并。
3.4 多Agent的上下文管理与中间产物落盘
Agent落地时另一个必须处理的问题是上下文长度。一个真实项目的系统描述、历史文档、标准条款检索结果加起来，轻松超过几十万token。如果每个Agent都硬塞全部上下文，不管模型窗口多大都扛不住，成本也会失控。
REANA的做法是"分阶段落盘"：每个Agent处理完一个阶段后，把结构化产物写到共享存储（我们用的是带版本控制的目录，相当于一个中间产物仓库），下一个Agent只需要读取自己需要的那部分数据结构，而不是重新加载全部上下文。
举个例子，功能安全Agent做完HARA后，产出的是一份结构化JSON（危害ID、场景引用、S、E、C、ASIL jichu判级、依据条款）。SOTIF Agent并不需要读取整份HARA，它只需要从场景本体中拿到"属于SOTIF分析域的场景子集"再独立分析。这样既保证了分析视角独立，又避免了上下文互相污染。这个设计思路，其实和"AI Agent怎么扛并发"是同一类问题——解耦每个Agent的工作上下文，才能让多个Agent真正并行跑起来。
4. 实测REANA的产出质量：初稿能力到底到什么程度
理论说了那么多，关键还是看产出。我拿一个真实的测试场景说明：给REANA输入一个"A级SUV的L2+智驾域控制器需求描述"，里面包含感知融合、决策规划、执行控制三大功能模块，以及目标市场（中国、欧洲）的工况假设。
4.1 一个好的初稿应该长什么样：示例拆解
REANA在三十分钟内产出了一套初稿，核心内容包括：
- 基于场景本体自动识别出42个运行场景组合（白天/黑夜/雨/雾/隧道/高速/城区/行人/前车切入等）；
- 功能安全Agent标出23条危害事件，其中一条是这样写的："危害H14：前方车辆静止时，系统未在预期距离内触发AEB制动，导致碰撞风险。S=3，E=4（高速场景），C=3（可控性低），建议ASIL B；引用条款：ISO 26262-3:2018 第7.2.3条相关示例。"
- SOTIF Agent额外识别出6条"非失效类"问题，例如：传感器感知性能在强逆光下下降到不足以稳定检测摩托车，但系统仍处于激活状态——这属于预期功能不足，建议通过功能限制或性能监控缓解；
- 信息安全Agent输出17条威胁，其中与H14同源的一条威胁是"攻击者通过伪造前方目标雷达回波，抑制AEB触发"，威胁ID为T-09，在下游安全概念里建议做"传感器输入可信度校验"；
- 三安协调Agent生成了一张追溯矩阵，H14与T-09指向同一个场景节点SC-09，并且自动标注了"功能安全措施与信息安全措施需联合设计"的交叉提示。
这个输出质量，我诚实地说，拿来直接交客户不行，但拿来当评审底稿绰绰有余。它把过去三拨人三周才能完成的初稿压缩到了半小时，而且跨域对齐这件最琐碎的事情完全自动化了。
4.2 必须由人来兜底的判断点清单
那哪些地方Agent做不了？我们也梳理了一份"人工兜底判断点"，这是整个项目里最有价值的一份清单：
| 判断类型 | 示例 | 理由 |
|---|---|---|
| 商业风险接受度 | "中国市场是否接受ASIL B还是必须ASIL C" | 这取决于OEM的安全战略，不是技术推导 |
| 场景完备性判断 | "是否遗漏了某个特定地区独有的交通场景" | Agent只能基于知识库和输入描述，无法替代本土经验 |
| 多域措施冲突仲裁 | 功能安全说要加冗余传感器，信息安全说冗余传感器增加攻击面 | 这是工程权衡，需要架构师综合决策 |
| 异常Value标定 | S=3还是S=4，不同公司有不同的判据细则 | Agent给的是建议值，最终定级需要内部评审 |
用一句话概括：Agent负责"把该分析的全部分析出来、把依据找齐"，人负责"在这些选项里做最终决策"。这个定位非常清晰，也让团队里的安全工程师更容易接受Agent，而不是把它当成威胁。
4.3 验收方式建议：Agent先出、人来改、机器再查差异
在实际项目里，我们建立了一套"初稿-人审-差异回检"的流程：
- REANA输出初稿，每个结论都带引用来源；
- 责任工程师在Review时直接修改等级、增删条目，修改都会留痕；
- 初稿被改完后，系统会重新跑一次"差异分析"，把Agent初判与工程师最终结论之间的所有差异整理成清单；
- 工程师在看差异清单时，只需回答两个问题：Agent判错了，还是Agent判对了但不符合本项目的默认策略？
- 所有"判错了"的案例会被回传到Agent的知识库/规则库，作为下一轮的修正输入。
这套闭环跑起来之后，项目的知识积累就从"存在人脑子里"变成了"沉淀到Agent系统里"。新项目开始时，REANA等于带着过去所有项目的判断经验来建初稿，初稿质量会一代比一代高。
5. 落地踩坑与生产化经验
最后这部分，我想把真正踩过的坑和已经验证过的经验讲透。任何Agent系统在演示环境里都"看起来很好"，但一上生产就有各种意想不到的问题。REANA也不例外。
5.1 幻觉问题：条款引用错误是最大的合规风险
前面已经提到过强制引用的设计，但这还不够。有一次，知识库更新的时候，我们把ISO 26262-8的某个条款全文错误地映射到了ISO 26262-6的编号下，结果Agent大量引用了一个"错位"的条款。若不是人工评审时抽查发现，这个错误会直接进入交付物。
这件事让我们固化了一个规矩：知识库每一个条款条目都必须有"双人复核"（一个领域专家、一个文档管理）才能上线，而且定期做一致性抽查。大模型的幻觉可以通过RAG缓解，但知识库本身的维护错误，往往是更隐蔽的风险源。
5.2 术语污染：三域共用同一个词汇表会互相带偏
第二个大坑是三域术语的互相污染。REANA最早的设计里，三个Agent共用一个项目内术语表，结果在准备生成跨域报告阶段，SOTIF Agent把"触发条件"误标成了"威胁入口"，因为它在术语表里找到了同一个词的网络安全定义。
后来我们把术语表升级成了"分域、可映射"的结构：每个域有自己的权威术语定义，跨域映射关系单独维护。协调Agent在做合并时，只用映射关系，不允许自由改造术语。这个改动的结果立竿见影——跨域报告里的术语一致性从78%提升到了97%以上，人工修正量大幅下降。
5.3 并发与多人协作：生产环境要注意的事
团队里多个项目同时用REANA时，并发策略很重要。我们的早期版本是一个项目一个Agent实例，资源占用很大，几个项目同时启动就会把推理服务拖垮。后来参考任务隔离的思路改成"流程级调度"：把单个法律域分析拆成独立任务队列，不同项目可以共享同一个推理服务，互不阻塞。另外，中间产物存储必须做文件级锁定，否则两个项目经理同时改同一份场景本体会互相覆盖。
这部分的经验总结成一句话：Agent系统上线生产，真正的瓶颈往往不在模型能力，而在任务调度、存储隔离和并发控制这些"工具链工程"层面。
5.4 从试点到推广的路径
如果你也想在自己团队里落地类似的"Agent建初稿"模式，我建议按三步走：
- 先选一个单一域试点（比如只做功能安全HARA初稿），让团队熟悉输出格式和Review流程，跑通"初稿-人审-差异回检"闭环；
- 再打通三安共享的场景本体，让两个域（比如功能安全和SOTIF）开始用同一棵场景树，验证跨域对齐效果；
- 最后把信息安全域也接入，并逐步积累跨域历史案例，让三安协调Agent的合并质量越来越稳定。
不要一上来就追求"全自动三安一体"，那会让团队既不知道怎么审、也不敢审。Agent的可靠性和团队对它的信任度，是需要通过一个个真实项目滚出来的。
在我实际使用REANA的过程中，最深的体会是：这套系统的价值不在于"写文档比人快"，而在于它把安全工程师从"建模打字员"变回了"安全决策者"。初稿由Agent来建，人负责判断和决策，机器的产出质量反而会在一次次评审反馈中持续变好。如果你正被"三安交付"的初稿工作量压得喘不过气，不妨先在小范围内试试"Agent建初稿+人做决断"这个模式——不必一步到位，先跑通一个最小的闭环，你就会看到复利在哪儿。
