汽车三安一体Agent实践：用智能体生成功能安全、SOTIF与信息安全初稿

1. 从“人建模型”到“Agent建初稿”到底在说什么

汽车功能安全、预期功能安全（SOTIF）和信息安全，这三块内容在传统整车开发流程里一直是三条相对独立的线。功能安全看的是电子电气系统失效后会不会导致危害，SOTIF盯的是没有系统失效但功能本身能力不足或可预见误用带来的风险，信息安全则关注外部攻击面、数据完整性和访问控制。过去做这三个方向的安全分析，基本靠资深工程师手工建模型、画架构图、写危害分析和风险评估，一个项目下来光是安全概念阶段的文档就能堆满几个G的共享盘。

REANA这个项目做的事情，是把这三条线用一个智能体串起来，让Agent去生成初稿，工程师从“从零开始建模型”变成“审阅和修正模型”。这个转变听起来只是效率提升，实际上改变的是整个安全工程的工作流。以前一个功能安全工程师拿到系统描述，要先理解架构、识别相关项、定义边界、做HARA、推导安全目标、分配到子系统，再写技术安全需求。这套流程走下来，一个中等复杂度的域控制器项目，光概念阶段就要两到三周。现在Agent可以在几个小时内产出一份结构完整、条目齐全的初稿，工程师把精力集中在判断和决策上。

这篇文章适合几类人看。一是正在做汽车安全相关工作的工程师，包括功能安全、SOTIF和信息安全方向，想了解怎么把Agent引入日常工作流。二是做Agent开发和编排的工程师，想看看在汽车安全这个垂直领域里，Agent的架构应该怎么设计、工具怎么接、记忆怎么管。三是对三安一体这个概念还比较陌生、但需要快速建立认知的技术管理者。我会从整体设计思路讲到具体实现细节，包括Agent的编排方式、知识库的构建、工具链的对接、以及实际跑下来会遇到哪些坑。

需要提前说明的是，REANA这个项目本身是一个工程实践方向的探索，不是某个标准组织发布的规范。它做的事情是把现有的安全分析方法论和Agent技术做结合，所以文章里涉及的标准引用都是公开的行业标准，不涉及任何特定企业的内部流程。

2. 三安一体的核心设计思路拆解

2.1 为什么要把三个安全域放在一个Agent里

功能安全、SOTIF和信息安全在标准层面是分开的。ISO 26262管功能安全，ISO 21448管SOTIF，ISO/SAE 21434管信息安全。三个标准各有各的流程要求、分析方法和输出物。传统做法是三个团队各做各的，最后在系统层面做协调。这种模式的问题在于，同一个系统架构，三个团队可能画出三套不同的图，识别出的风险条目也有重叠和遗漏。

REANA的设计思路是，让一个Agent同时具备三个域的知识，在生成初稿的时候就从统一的系统模型出发。比如一个自动驾驶域控制器，功能安全关注的是刹车指令计算错误会不会导致非预期制动，SOTIF关注的是感知算法在特定场景下漏检会不会导致碰撞，信息安全关注的是CAN总线上的报文会不会被篡改。这三个问题指向的是同一个系统的不同侧面，如果Agent能同时理解这三个视角，生成的初稿就能在条目层面做交叉引用，而不是三份互不相关的文档。

具体实现上，Agent的知识库分成三层。底层是通用安全知识，包括三个标准的核心概念、分析方法和典型模式。中间层是领域知识，比如动力系统、底盘系统、座舱系统的常见失效模式和攻击面。上层是项目知识，包括当前项目的系统架构、接口定义、已有安全需求。Agent在生成初稿时，会从这三层知识里检索相关内容，然后按照标准要求的输出模板组织内容。

2.2 Agent建初稿的边界在哪里

这里要明确一个边界：Agent生成的是初稿，不是终稿。初稿的含义是，结构完整、条目齐全、逻辑自洽，但具体的技术判断需要工程师确认。比如Agent可以识别出“制动扭矩计算错误”是一个潜在的危害事件，并给出对应的安全目标“避免非预期制动扭矩输出”，但具体的安全目标ASIL等级需要工程师根据暴露率、可控性和严重度来最终确定。

这个边界的设计是有意为之的。安全分析的核心价值在于工程判断，Agent的价值在于把工程师从重复性的文档工作中解放出来。如果Agent直接给出终稿，工程师反而要花更多时间去验证每一条判断的合理性，效率提升就不明显了。初稿模式下，工程师看到的是一个已经组织好的框架，只需要在关键节点做决策和修正，工作量和心理负担都小很多。

从实际跑下来的数据看，一个中等复杂度的项目，Agent生成的初稿可以覆盖大约70%到80%的条目。剩下的20%到30%主要是项目特有的边界情况、与供应商相关的接口细节、以及需要跨域协调的条目。工程师在这个基础上做补充和修正，整体时间可以压缩到原来的三分之一左右。

2.3 为什么选择Agent而不是传统的脚本或模板

传统做法里也有用脚本生成安全文档的尝试，基本思路是预定义模板加参数填充。这种做法的问题在于，安全分析不是简单的填空。同一个系统，不同的架构决策会导致完全不同的分析结果。脚本没法理解架构背后的设计意图，只能机械地套模板。

Agent的优势在于它能理解上下文。比如系统描述里提到“采用双核锁步架构”，Agent能推断出这是为了提高诊断覆盖率，进而在功能安全分析里把对应的诊断措施和安全机制关联起来。脚本做不到这一点，它只能看到字符串，看不到字符串背后的工程含义。

另一个关键点是Agent可以处理非结构化的输入。工程师给Agent的输入可能是一段文字描述、一张架构图、一份接口定义表，甚至是会议纪要。Agent可以从这些零散信息里提取出系统边界、功能列表、接口关系，然后组织成结构化的分析模型。这个能力是传统脚本不具备的。

3. 核心细节解析与实操要点

3.1 Agent的编排架构怎么搭

REANA的Agent编排采用的是一个主Agent加多个子Agent的结构。主Agent负责理解任务、拆解步骤、调度子Agent、汇总结果。子Agent按安全域划分，分别是功能安全Agent、SOTIF Agent和信息安全Agent。每个子Agent有自己的知识库和工具集，但共享同一个项目上下文。

主Agent的工作流程是这样的：首先接收输入，输入可以是一段自然语言描述、一份系统架构文档、或者一组接口定义。主Agent先做意图识别，判断当前任务属于哪个阶段，是概念阶段的HARA，还是系统阶段的安全需求分配，还是详细设计阶段的安全机制定义。然后根据任务类型，决定调用哪些子Agent，以及调用的顺序。

子Agent之间的协作通过共享内存实现。比如功能安全Agent在分析某个危害事件时，发现这个事件可能与信息安全攻击相关，它会把这条信息写入共享内存。信息安全Agent在后续分析中读取到这条信息，会从攻击路径的角度做补充分析。这种交叉引用是三个域放在一个Agent体系里的核心价值。

工具集方面，每个子Agent都挂载了一组工具。功能安全Agent有HARA工具、安全目标推导工具、ASIL等级计算工具。SOTIF Agent有场景库检索工具、触发条件分析工具、已知危害场景匹配工具。信息安全Agent有威胁建模工具、攻击树生成工具、安全控制措施检索工具。这些工具本质上是一组封装好的函数，Agent根据当前任务需要调用。

3.2 知识库的构建和维护

知识库是Agent能不能生成高质量初稿的关键。REANA的知识库构建分三步走。

第一步是标准知识的结构化。把ISO 26262、ISO 21448、ISO/SAE 21434三个标准的核心内容拆解成条目，每条包含概念定义、适用场景、分析方法、输出要求。这一步的难点在于标准文本本身是自然语言写的，需要人工做一轮结构化。我的经验是，不要试图把整个标准都塞进去，先聚焦在概念阶段和系统阶段最常用的那部分，大概覆盖标准内容的30%左右，就能支撑大部分初稿生成任务。

第二步是领域知识的积累。这部分主要来自历史项目的安全分析文档。把过往项目里的HARA表格、安全目标列表、威胁建模结果做脱敏处理后，作为案例库存入知识库。Agent在生成初稿时，会检索相似案例作为参考。这里要注意的是，案例库需要定期更新和清理，过时的案例反而会误导Agent。

第三步是项目知识的注入。每个新项目启动时，把项目的系统描述、架构图、接口定义整理成Agent能理解的格式，注入到项目知识库。这部分内容是动态的，随着项目推进不断更新。我的做法是每周做一次项目知识库的同步，把最新的设计变更和会议结论更新进去。

知识库的检索策略用的是混合检索，既有关键词匹配，也有向量相似度匹配。关键词匹配保证精确性，向量匹配保证召回率。实际跑下来，混合检索的效果比单一策略好很多，尤其是在处理同义词和近义表达的时候。

3.3 输入输出的格式约定

Agent的输入格式需要做一定的约定，不能完全依赖自然语言。我的做法是定义一个轻量的输入模板，包含几个必填字段：系统名称、系统功能描述、系统边界、主要接口、已知的安全相关特性。其他字段可以选填，比如已有的安全需求、供应商信息、法规要求。

输出格式则严格遵循标准要求的文档结构。功能安全部分输出HARA表格、安全目标列表、功能安全概念。SOTIF部分输出场景分析表、触发条件列表、SOTIF相关危害。信息安全部分输出威胁模型、攻击树、安全控制措施列表。三个部分的输出在条目层面做交叉引用，比如某个安全目标如果同时与信息安全相关，会在两个部分都出现，并标注关联关系。

这里有一个实操心得：输出格式不要追求一步到位。第一版可以先输出纯文本的结构化内容，工程师确认后再生成正式的表格和图表。这样做的好处是，工程师在早期就能介入修正，避免Agent在错误的方向上生成大量内容。

3.4 注意事项与常见坑

第一个坑是知识库的污染。如果案例库里混入了质量不高的历史文档，Agent生成的初稿也会带上这些问题。我的做法是，案例入库前做一轮人工审核，只保留经过验证的、结构清晰的文档。入库后定期做质量抽检，发现问题的案例及时清理。

第二个坑是过度依赖Agent的判断。前面说过，Agent生成的是初稿，但实际使用中工程师很容易把初稿当成终稿，直接提交评审。这个习惯很危险。我的建议是，在流程上强制要求工程师对每一条Agent生成的内容做确认，确认的方式可以是打标签，比如“确认无误”、“需要修改”、“需要补充”。这样既能保证质量，也能积累反馈数据用于后续优化。

第三个坑是上下文窗口的限制。汽车安全分析涉及的系统描述往往很长，加上知识库检索的内容，很容易超出Agent的上下文窗口。我的做法是做分层处理，先让Agent处理系统级描述，生成高层级的分析框架，然后再分模块做详细分析。每个模块的分析独立进行，最后汇总。这样既能控制单次处理的上下文长度，也能保证分析的深度。

4. 实操过程与核心环节实现

4.1 环境准备与基础配置

REANA的运行环境基于容器化部署，核心组件包括Agent运行时、知识库服务、工具服务三部分。Agent运行时负责任务调度和对话管理，知识库服务负责知识的存储和检索，工具服务封装了各种安全分析工具。

基础配置方面，需要准备的东西包括：一个支持函数调用的模型接口、一个向量数据库用于知识检索、一个关系型数据库用于存储项目数据和Agent的运行日志。模型接口的选择上，我的经验是不要追求最大的模型，中等规模的模型在垂直领域经过知识库增强后，效果往往更好，而且推理成本更低。

配置过程中有几个关键参数需要调整。检索的top-k值建议设在5到10之间，太小会导致召回不足，太大会引入噪声。温度参数建议设在0.1到0.3之间，安全分析需要的是稳定和一致，不需要创造性。最大输出长度根据任务类型动态调整，HARA分析可能需要较长的输出，而简单的条目检索可以短一些。

4.2 从系统描述到安全分析初稿的完整流程

整个流程分五个阶段。

第一阶段是输入解析。Agent接收系统描述后，先做实体识别和关系抽取，识别出系统的组成部分、功能、接口、以及它们之间的关系。这一步的输出是一个结构化的系统模型，包含组件列表、功能列表、接口列表、以及组件之间的连接关系。

第二阶段是相关项定义。Agent根据系统模型，结合项目边界，定义出功能安全的相关项。相关项的定义需要明确边界、功能、接口、以及与其他系统的交互。这一步的输出是相关项描述文档。

第三阶段是危害分析和风险评估。Agent基于相关项定义，识别潜在危害事件，分析危害事件的暴露率、可控性和严重度，推导出ASIL等级，然后定义安全目标。这一步是功能安全分析的核心，也是Agent生成内容最多的部分。

第四阶段是SOTIF分析。Agent从场景库中检索相关场景，分析系统在各类场景下的表现，识别触发条件，评估SOTIF相关危害。这一步与功能安全分析有交叉，Agent会在两个部分之间做关联。

第五阶段是信息安全分析。Agent基于系统架构和接口定义，做威胁建模，识别攻击面，生成攻击树，定义安全控制措施。这一步的输出与功能安全的安全目标做交叉引用。

整个流程跑下来，一个中等复杂度的项目，Agent生成初稿的时间大约在2到4小时。工程师审阅和修正的时间大约在1到2天。相比传统方式，整体时间压缩了60%以上。

4.3 关键参数的计算与选择过程

ASIL等级的计算是功能安全分析里的核心环节。Agent需要根据严重度、暴露率和可控性三个维度来确定ASIL等级。严重度分S0到S3四级，暴露率分E0到E4五级，可控性分C0到C3四级。三个维度的组合决定ASIL等级，从QM到ASIL D。

Agent在做这个计算时，会先给出每个维度的初步判断，然后根据标准里的对应关系表推导出ASIL等级。比如严重度S3、暴露率E4、可控性C3的组合对应ASIL D。Agent会在输出里标注每个维度的判断依据，方便工程师复核。

这里有一个实操细节：Agent对暴露率和可控性的判断往往偏保守，容易给出偏高的等级。我的做法是在Agent的输出里增加一个置信度标注，对于置信度较低的判断，工程师重点复核。这样既能利用Agent的效率，又能保证最终结果的准确性。

4.4 实操现场记录与经验总结

实际跑REANA的过程中，有几个场景让我印象比较深。

一个是处理一个域控制器的安全分析。系统描述只有两页纸，但涉及的接口有三十多个。Agent在解析输入时，自动把接口按类型做了分组，然后针对每组接口分析潜在的安全风险。这个分组能力是传统脚本做不到的，脚本只能按预定义的规则做简单分类。

另一个是处理一个涉及多个供应商的项目。系统描述里提到了几个供应商提供的组件，但没有详细的接口定义。Agent在生成初稿时，对供应商相关的部分做了标注，提示需要补充信息。这个标注机制很实用，避免了Agent在信息不足的情况下强行生成内容。

还有一个是SOTIF分析里的场景检索。Agent从场景库里检索到了几个相似场景，但其中一个场景的适用性存疑。Agent在输出里标注了这个场景的匹配度，并给出了不匹配的理由。工程师复核后确认这个场景确实不适用，直接删除了。这个匹配度标注机制减少了工程师的复核工作量。

5. 常见问题与排查技巧实录

5.1 Agent生成内容不完整怎么办

最常见的问题是Agent生成的初稿条目不全。原因通常有几个：输入信息不足、知识库检索没命中、或者任务拆解不够细。

排查思路是这样的：先看输入信息是否完整，系统描述里有没有遗漏关键组件或接口。如果输入没问题，再看知识库检索的日志，看Agent检索了哪些内容，有没有命中相关的案例或标准条目。如果检索也没问题，那就是任务拆解的问题，需要把大任务拆成更小的子任务，让Agent分步处理。

我的经验是，大部分不完整的问题都出在输入信息不足。Agent不是万能的，它只能基于已有的信息做推理。如果系统描述里没提到某个接口，Agent不可能凭空生成相关的分析。所以输入信息的完整性是第一步要保证的。

5.2 三个安全域的分析结果冲突怎么处理

三个域的分析结果冲突是正常现象，因为三个标准关注的角度不同。比如功能安全可能认为某个危害事件的ASIL等级是B，而信息安全分析认为这个事件相关的攻击路径需要更高级别的防护。这种冲突不是错误，而是需要协调的点。

处理方式是在Agent的输出里增加一个冲突检测机制。当三个域的分析结果出现不一致时，Agent会标注出来，并给出冲突的原因分析。工程师在复核时重点关注这些冲突点，做跨域的协调决策。

从实际跑下来的情况看，冲突主要集中在安全目标的等级分配和安全控制措施的优先级上。功能安全倾向于用ASIL等级来驱动，信息安全倾向于用攻击可行性和影响来驱动。两个视角都有道理，最终决策需要结合项目的实际情况。

5.3 Agent运行超时或中断怎么恢复

Agent运行超时通常是因为单次处理的任务量太大。汽车安全分析涉及的内容多，如果一次性把所有任务都交给Agent，很容易超出模型的上下文窗口或运行时间限制。

我的做法是把整个分析流程拆成多个阶段，每个阶段独立运行，阶段之间通过共享内存传递中间结果。如果某个阶段运行失败，只需要重新运行这个阶段，不需要从头开始。这样既提高了容错性，也方便调试。

另外，Agent的运行日志要详细记录，包括每次调用的输入、输出、耗时、以及中间状态。出问题的时候，日志是排查的第一手资料。我的习惯是每天收工前看一眼当天的运行日志，发现异常及时处理，不要等到问题积累多了再排查。

5.4 常见问题速查表

5.5 独家避坑技巧

第一个技巧是关于知识库的冷启动。新项目启动时知识库往往是空的，Agent生成的内容质量会打折扣。我的做法是先用几个历史项目的数据做一轮预训练式的知识注入，让Agent先建立基本的领域认知，然后再处理新项目。这样冷启动阶段的质量会好很多。

第二个技巧是关于工程师的反馈闭环。Agent生成的初稿，工程师的修正意见要收集起来，定期做一轮分析，看哪些类型的错误出现频率高，然后针对性地优化知识库或调整Agent的提示词。这个闭环跑起来后，Agent的生成质量会持续提升。

第三个技巧是关于多轮对话的管理。安全分析往往需要多轮交互，Agent需要记住之前的对话内容。我的做法是把对话历史做摘要压缩，只保留关键决策和结论，避免上下文窗口被无关内容占满。摘要的粒度可以按阶段来，每个阶段结束后做一次摘要。

第四个技巧是关于输出的一致性检查。Agent在不同时间生成的内容可能会有不一致的地方，比如同一个安全目标在不同章节里的描述有差异。我的做法是在输出前加一道一致性检查，用规则匹配的方式检查关键术语和条目的一致性，发现不一致的地方自动标注出来。

6. 这套方案还能怎么扩展

REANA目前的实现聚焦在概念阶段和系统阶段的初稿生成。往后再走，有几个方向可以扩展。

一个是往详细设计阶段延伸。目前Agent生成的是安全目标和功能安全概念，下一步可以生成技术安全需求和安全机制的具体设计。这部分需要更细粒度的系统信息，也需要Agent对硬件和软件设计有更深入的理解。

另一个是往验证和确认阶段延伸。Agent可以根据安全需求生成测试用例，覆盖功能安全、SOTIF和信息安全的验证需求。这部分的关键是测试用例的覆盖度分析，需要Agent理解需求之间的依赖关系。

还有一个方向是与其他工程工具的集成。目前REANA的输出是文档形式的，下一步可以做成与需求管理工具、架构设计工具、测试管理工具的直接对接，让Agent生成的内容直接进入工程工具链，减少人工搬运的环节。

我个人在实际操作中的体会是，Agent在安全分析领域的价值不在于替代工程师，而在于把工程师从重复性的文档工作中解放出来，让工程师有更多时间做真正的工程判断。这个定位想清楚了，Agent的设计和实现就有了明确的方向。最后再分享一个小技巧：Agent的提示词不要写得太复杂，把任务拆解清楚、把输出格式定义清楚，比堆砌大量的指令更有效。