在汽车行业把功能安全、SOTIF 和信息安全放进同一个 Agent 里跑通我一开始也以为是概念玩得花。直到团队把内部代号 REANARequirements Engineering and Analysis Agent的三安一体智能体推上预研项目我才意识到真正有价值的变化不是某个工具多了一个 AI 按钮而是“人建模型”长期被工程师手工作业吃掉的产能终于有机会让位给“Agent 建初稿”。这篇文章适合三类人一是被安全文档和模型反复折磨的功能安全/SOTIF 工程师二是正在做 ISO/SAE 21434 落地的信息安全工程师三是对 Agent 开发感兴趣、想了解它怎样在严肃工程场景里落地的 AI 从业者。我会把背景痛点、架构设计、技术拆解、实操流程、踩坑记录这几块按我实际推进项目的顺序讲透能直接照着做。1. 为什么汽车安全需要“三安一体”1.1 三条安全线各自为战的现状过去几年我在多个量产项目中看到同一个问题功能安全、SOTIF、信息安全三拨人各自堆文档各自建模型甚至对同一个系统可以给出三套完全不同的“危险事件”描述。功能安全工程师关注功能失效导致的危害SOTIF 工程师关注功能不足和触发场景带来的风险信息安全工程师则盯着攻击路径和漏洞利用。三者理论上都围绕“风险”做事但在组织流程和工具链里却彼此隔离。这种隔离最直接的后果有三个。第一重复建模。同一个系统边界、同一个功能清单在三份安全分析里被维护三遍改一个需求就要同步四处漏掉一处就是一致性缺陷。第二术语冲突。SOTIF 里的“触发条件”、功能安全里的“运行模式”、信息安全里的“资产”在语义上高度重叠但互不相同评审会上经常要花半小时统一语言。第三安全活动之间缺少传递。SOTIF 分析中发现的危险场景本应该成为功能安全里安全机制的验证场景也可以作为信息安全威胁分析中的攻击前提条件但现实中这些信息靠人肉搬运丢失率极高。如果只是文档多、会议多问题还不算严重。真正的痛点在于“建模”这一步。不管是危害分析与风险评估HARA、SOTIF 的场景风险分析还是信息安全的威胁分析与风险评估TARA都需要安全工程师把系统描述、功能定义、外部环境、用户操作、威胁模式这些东西手工转换成结构化模型。一个人做一个中型项目的 HARA从读懂功能描述到完成危险事件分级往往要一周以上而项目前期的频繁变更会让这些模型被推倒重来多次。1.2 从“人建模型”到“Agent 建初稿”的范式变化“Agent 建初稿”这个提法容易让人误解为 AI 要把安全工程师替换掉。我自己的实践结论是短期里它替换不了人但它能把工程师从“从零建模”里解放出来让工程师变成“模型评审者”。传统工作流里安全工程师面对空白模型文件需要先想结构、再补内容、再查一致性。比如做 HARA 时先列出车辆级危害再关联到功能、场景和运行模式最后打分定 ASIL。这里面真正需要专家判断的部分是对功能失效后的“可控性”和“严重度”的把握而前 70% 的机械工作——收集功能信息、枚举场景、映射故障类型、整理标准条款——完全适合交给 Agent 完成初稿。REANA 的设计出发点就在这。它不是一个简单的问答机器人也不是把安全文档丢进向量库做一个检索增强生成就完事。它要能调用工具、读取系统模型、执行多步推理在标准框架下自动生成初始的安全分析产物并且让每一步都留下可追溯的证据供工程师评审和修改。人从“画第一版模型的人”变成“审模型、改模型、拍板的人”。这个转变听起来只是分工变化实际上已经在改变整个安全交付的产能模型。2. REANA一个三安一体的智能体架构2.1 REANA 的定位与整体架构我记得搭建时最纠结的不是选哪个大模型而是要把系统定位成“分析引擎”而不是“聊天助手”。REANA 在逻辑上分四层基础模型层、Agent 编排层、知识层、业务集成层。基础模型层是大语言模型负责理解、推理、生成文本Agent 编排层用任务图和状态机管理安全分析流程决定什么时候该做 HARA、什么时候该做 TARA、什么时候该调用工具知识层把 ISO 26262、ISO 21448、ISO/SAE 21434 的标准文本、内部模板、历史案例、安全模式库、攻击模式库整理成可供模型检索的统一知识底座业务集成层接上企业常用的需求管理工具如 DOORS、Polarion、系统建模工具如 SysML 模型库和流程审批平台让 Agent 输出的初稿能直接写回数据源。这四层听起来常规但真正让它变成“三安一体”的是知识层的统一本体设计。我们把三条安全线共同关心的对象抽象成一张联合风险模型系统/组件、功能/行为、场景包含环境、驾驶员状态、操作序列、威胁/故障事件、风险等级、缓解措施。功能安全关心“故障事件”和“安全目标”SOTIF 关心“功能不足/触发场景”和“预期功能风险”信息安全关心“威胁事件/攻击路径”和“资产影响”。这些在底层都可以归结为“从某场景出发某种异常事件导致某个危害需要某类缓解策略”。统一本体之后三条线第一次可以在同一张风险登记表上对话。2.2 为什么选择 Agent而不是 RAG 或硬编码模板这是我在宣讲时被问最多的一个问题。既然安全文档有固定章节为什么不用模板加规则再辅以 RAG 抽取内容答案在于安全分析的三个特性。第一分析路径是动态的。每个项目的功能不同、架构不同哪些危害需要展开哪些场景需要深挖依赖前面步骤的输出。用一个固定模板只能生成静态填充无法根据上一步结果调整下一步分析深度。Agent 的规划能力正好能处理这种动态路径。第二安全工件之间有相互引用和一致性约束。HARA 输出的安全目标要在安全需求里体现TARA 里的缓解措施要能追溯回威胁事件SOTIF 的场景分析结果要反馈到功能安全验证确认计划。Agent 可以维护一个工作记忆跨任务保持上下文并在生成过程中执行一致性校验。RAG 只是检索答案没有任务状态做不到这层联动。第三需要工具调用才能拿到真实工程数据。安全分析要引用真实的系统模型、架构图、需求条目这些数据不会老老实实躺在知识库里而是分散在 ALM、PLM、SysML 模型里。Agent 通过函数调用去查询、筛选、拼接这些数据才能保证初稿紧贴当前项目基线。单纯 RAG 只会返回偏离基线的相似文本生成再漂亮也是空中楼阁。我承认 Agent 架构的稳定性远不如模板脚本它会有幻觉、会有工具失败也会有自己“想当然”的脾气。但换来的是一旦跑通它可以在几十分钟内完成传统需要一周的初稿工作而且可以把三份安全分析钉在同一套数据模型上。这个取舍我认为对安全工程是对的。3. 核心技术与知识工程拆解3.1 多标准知识库与跨标准本体映射REANA 的知识库不是简单的文档切片向量库。我们把知识拆成四类分别用不同的存储和检索方式处理。第一类是标准条文库包括 ISO 26262 的各个部分、ISO 21448、ISO/SAE 21434以及像 UNECE R155/R156 等法规要求。这类知识适合整段切片后做语义检索因为模型提问时往往带着具体场景需要找到相关条款原文做支撑。第二类是模板库按安全计划、HARA 表、TARA 表、SOTIF 分析表等工件类型整理每个模板有字段定义、填写说明、示例。这部分用结构化 Schema 管理Agent 生成时直接按 Schema 约束输出。第三类是案例库包括历史项目的危险事件、典型攻击路径、已发布的事故分析这部分做去标识化处理后按风险模式聚类。第四类是安全模式库包括安全机制如故障诊断、冗余设计、SOTIF 缓解措施如系统能力强化、驾驶员监控介入、信息安全控制措施如安全启动、SecOC、入侵检测。这四类知识要在“联合风险模型”下打通靠的是一个本体映射层。我举个具体例子“自动紧急制动AEB在雨夜对静止障碍物未触发”这个场景。功能安全视角把它拆成传感器故障、控制策略误判、执行器失效SOTIF 视角关注传感器性能边界雨水遮挡、低照度、算法对特殊车形的识别能力不足、非预期触发导致的驾驶员误操作风险信息安全视角则考虑传感器信号被伪造、CAN 总线报文注入、诊断接口被非法访问。三种视角的起点是同一个物理场景终点是不同的风险矩阵和缓解策略。本体层要保证Agent 在生成其中任意一份分析时都能看到其他两条线的相关条目并且能在同一个“场景 ID”下做交叉链接。这一步做扎实三安一体才是真的一体而不是三个 AI 小助手并排站着。3.2 Agent 任务编排从输入到安全工件初稿REANA 的 Agent 编排采用“主 Agent 子任务 Agent”的结构。主 Agent 负责理解项目输入功能描述、系统架构、运行环境、操作场景拆解出当前项目需要哪些安全工件排定生成顺序维护全局任务状态。子任务 Agent 分别负责 HARA、SOTIF 分析、TARA、安全需求生成、安全案例初稿等具体环节每个子任务有独立的目标和输出格式。子任务之间不是简单串联而是有依赖和回环。比如 HARA 子任务生成安全目标后TARA 子任务要读取安全目标来判断“这个功能在失效时会造成什么影响”SOTIF 子任务要读取 HARA 里的运行模式列表来约束场景枚举。主 Agent 在编排时会先建立一张依赖图能并行的环节并行有依赖的环节串行并在每个环节结束后把输出摘要写回共享记忆池。从输入到输出的完整链路大致是主 Agent 接收系统描述 → 提取系统边界与功能清单 → 启动 HARA 子任务枚举危险事件并评级 → 启动 SOTIF 子任务识别预期功能不足与触发场景 → 启动 TARA 子任务确定资产、威胁、攻击路径与风险等级 → 汇总三线风险清单交叉查重和链接 → 生成安全计划初稿与追溯矩阵。我在试点项目里实测这个流程在一个中等复杂度域控制器功能上跑一遍从输入 SysML 模型和需求条目到输出三份安全分析表加一份追溯矩阵耗时 40 分钟左右中间会调用 20 多次外部工具查询生成约 1.5 万字的初稿。3.3 工具集成与数据回写Agent 如果只读不写价值会打一半折扣。REANA 通过工具层接入了三类系统。第一类需求与项目管理工具主要是 DOORS 系列和 Polarion。Agent 用只读接口查询需求树、提取需求条目编号和版本生成初稿后按标准模板在工具里创建新的“分析工作项”。回写时只创建草稿状态不会直接发布到正式基线必须等人工评审通过。这一点非常重要我们的原则是 Agent 可以建初稿但永远不能替人发布基线。第二类系统建模工具。工程团队用 SysML 做系统架构REANA 通过建模工具 API 读取结构树、状态图、活动图元素把系统名称、接口、流、状态机转成 Agent 可理解的文本描述。实践里我建议读取时做一轮“模型精简”把几百个元素缩减成与当前安全分析相关的子集否则大模型上下文会迅速爆炸生成质量断崖式下降。第三类流程与合规系统包括问题追踪平台和文档审批流。Agent 生成初稿后会在追踪平台上创建评审任务、关联责任人、附上证据链接并记录生成时用的模型版本和提示词版本。这为审计提供了基础。后续扩展还会接入漏洞管理平台把信息安全的持续监测结果自动触发新一轮风险评估。这一类系统往往权限复杂我的经验是先做只读连通再逐步放开写权限每类系统都单独配置白名单和字段映射表避免 Agent 拿到不该看的数据或写进不该写的字段。4. 实操指南搭一个能跑通的最小闭环4.1 数据准备与知识库搭建如果你也想走到“Agent 建初稿”这一步建议从最小闭环开始别一步到位追求完整的三安一体。第一阶段只选一条业务线比如 SOTIF一个已知功能比如自动泊车用现有标准文本加内部模板搭建知识库。我常用的做法是先用向量数据库如 Milvus、Qdrant 或 pgvector存放标准条文和案例再对模板部分做结构化 Schema 定义把 HARA/SOTIF/TARA 等表格的字段名、枚举值、示例全部预先写清楚。这里有个细节不要一上来就往库里塞几百份文档。初版知识库控制在 30~50 个核心文档精修切片方式和索引规则比塞得多更重要。切片时我建议按章节保留标题层级并给切片打上“标准名称、章节、主题、适用阶段”的元标签这样检索时能按业务场景过滤不至于把 ISO 21448 的内容混进 TARA 分析里。搭建完成后先用 5~10 个历史项目的问题做检索测试看看召回结果是否准确。这个阶段不值得优化大模型先把知识库的召回调准后面所有环节都会更顺。4.2 定义 Agent 的任务序列与输出格式最小闭环里我用 LangGraph 这类框架定义四个节点输入解析、危害枚举、场景映射、初稿生成。输入解析节点负责把功能描述拆成“功能名称、工作模式、外部环境、用户操作、可能失效类别”。危害枚举节点根据输入解析结果结合知识库中的标准条款和案例库生成危险事件的候选列表并给出每个事件的场景描述和风险初步评级。场景映射节点把 SOTIF 的目标功能不足场景如传感器性能限制、算法能力边界映射到功能安全里的运行模式和安全机制上。初稿生成节点把前几个节点的结果组装成标准表格或文档初稿。在实现中我给每个节点写了两段 Prompt第一段是“角色和背景”告诉模型它现在在做哪个安全分析环节、依据什么标准、知识库来源是什么第二段是“输出格式”要求模型严格按 JSON 或 Markdown 表格输出字段名必须匹配模板 Schema。不要让模型自由发挥必须输出结构化内容否则后续环节没法解析。这里有一个我认为很关键的技巧让每一步都输出“置信来源”也就是引用它用了哪条标准、哪个案例、哪条需求。比如某条危险事件旁边标注 “[参考 ISO 26262-3:2018 表 B.1][案例库#1024]”。这样评审时工程师能直接点开来源核对Agent 的幻觉也会大幅减少因为模型被强制要求“说人话且有出处”。下面是一个简化版的输出 Schema 示例实际项目里字段会更多{ hazard_event_id: HAZ-001, scenario: 雨夜低速行驶前方出现静止障碍物AEB 未触发, hazard: 车辆与障碍物发生碰撞导致乘员受伤, operating_mode: 雨夜、低速、自动驾驶模式, risk_level: ASIL B, sotif_trigger: 雨水遮挡传感器算法对低反射率物体识别能力不足, security_threat: 传感器信号被伪造导致目标物信息错误, reference_sources: [ [ISO 26262-3:2018 表 B.1], [案例库#1024] ] }4.3 效果评估与质量守门怎么判断 Agent 生成的初稿能不能用我建了一套五维评分标准完整性、标准合规性、可追溯性、一致性、可读性。完整性看危险事件/威胁场景是否覆盖系统的主要功能和各运行模式标准合规性看是否出现与标准定义冲突的术语、分类、风险等级可追溯性看每条分析结论是否都有来源引用一致性看三安之间是否有重复条目漏删除、跨线条目是否链接正确可读性看工程师能否不查额外资料就理解初稿内容。运行方式是在每个子任务完成后由另一个“评审 Agent”做初筛并设两道闸门。第一道是机器检查包括必填字段检查、枚举值合法检查、追溯链接有效检查。第二道是人工评审由安全工程师对初稿提出修改意见系统记录下每次修改形成反馈数据。这些反馈数据非常宝贵。我们每两周会把评审中的修改增量做一次“增量调整提示词”或“知识库补充”把典型的错误模式写进负面清单里。比如某段时间 Agent 老把 SOTIF 的“触发条件”写进功能安全的“运行模式”我们就在知识库里加入一条冲突消解规则当上下文包含 SOTIF 触发条件时禁止归类为功能安全运行模式。这种机制成本低但对质量提升立竿见影。5. 真实踩坑记录与排查经验5.1 模型幻觉与标准冲突踩得最多的坑第一个就是幻觉。大模型生成安全分析时非常容易把标准条款“背错”。比如把 ISO 21448 里的“功能不足”解释成“功能失效”把 ASIL 的四个等级与信息安全的风险等级混在一起。解决思路分三层一是在 Prompt 里加硬约束要求风险等级只能从枚举值里选不允许自创等级二是要求模型引用标准原文并做严格校验所有引用必须在知识库中真实存在三是在评审环节引入自动比对脚本将生成内容中的标准编号与知识库条目做映射检查。第二个坑是“标准冲突”。功能安全要求“在故障发生时应降低危害风险”信息安全要求“在不信任的网络里保护命令真实性”两者在具体设计上可能打架。比如为满足网络安全系统要求在异常时主动降级并限制部分功能但功能安全流程可能认为降级策略本身引入新的危害。Agent 在生成缓解措施时如果不具备“跨线冲突检测”会给出一个自相矛盾的方案。我们的对策是在统一本体中建立“冲突消解规则”每条安全机制都标注它影响的其他安全线一旦生成的设计措施落到了多个安全线的约束区域就自动弹出人工复核提醒。5.2 多轮任务中的上下文污染第二个大坑是上下文污染。子任务串联时HARA 的输出会作为 TARA 的输入但如果 HARA 输出里有过时或错误的信息会一路传染到 SOTIF 和安全需求。尤其在长会话里模型有时会记混“这个项目是乘用车还是商用车”“有没有某个安全机制”。我亲测有效的做法有两个一是共享记忆池只保存结构化摘要不存原始聊天记录每个环节开始时只注入当前任务需要的摘要二是给关键实体设置“全局变量”比如项目名称、系统名称、运行场景列表、版本号在每轮 Prompt 中都重新注入彻底消除记忆漂移。另外要控制上下文窗口。把整个 SysML 模型全塞进去基本等于自杀。我一般会把模型抽取出来的文本限制在 3000~5000 字以内超出部分按子系统分批处理。长文本生成采用“分章节生成再汇总”而不是一次性输出全文避免后半段开始丢三落四。5.3 工具链路与上游数据质量第三个坑集中在工具链Agent 查询 ALM、SysML 模型时经常遇到字段读不到、权限不允许、接口返回超时等问题。更麻烦的是上游数据本身是脏的。需求条目不具备严格编码、系统模型元素命名混乱、版本基线不一致这些都会让 Agent 输出偏离预期。我的经验是先弄一个“数据探针”模块在每个子任务跑之前先自动检查上游数据的关键字段是否存在若缺失则直接提示人工补数据而不是让 Agent 瞎猜。同时在工具集成层做好接口降级如果 SysML 模型读取失败就回退到文本化架构描述如果 DOORS 查询不到需求条目就回退到手工上传的需求清单。Agent 每次使用工具都会把调用参数、返回数据摘要、是否降级写入日志。这样既能保证生成不因上游问题而中断也能在评审时还原整个过程。5.4 常见问题速查表现象可能原因解决方案生成的风险等级不在合法范围内Prompt 未做枚举值硬约束在输出 Schema 中加入枚举校验非法值重试标准条款引用错误知识库切片粒度不合理或模型幻觉强制引用校验只允许检索到的原文三安分析中同一场景描述不一致缺乏统一场景 ID 和共享记忆池在联合风险模型中按场景 ID 做交叉链接长文档后段质量下降上下文窗口过大、生成过长分章节生成控制单段输出长度工具超时导致流程中断外部接口不稳定做接口降级和重试机制设计措施在三安之间互相矛盾缺少跨线冲突检测机制建立跨线冲突消解规则和人工复核提醒6. 个人体会与后续扩展6.1 复盘Agent 在安全领域落地的三条经验首先模型能力不是门槛工作流设计才是。在汽车安全这种高监管领域Agent 落地最重要的不是模型有多强而是你愿不愿意把原本完整的交付流程拆成“机器做初稿、人做终稿”两段。只要这个拆分成立很多焦灼的环节会突然变轻。其次初稿的价值不在于能直接交付而在于让专家把精力集中到高风险判断上。工程师不用再趴在空白表格前憋第一版他们可以把时间花在那些真正需要经验、需要跨线权衡的地方。我发现团队里资深工程师对新流程的接受度反而比年轻人更高因为他们最烦重复劳动。最后数据反馈闭环决定了整个系统的天花板。每次人工评审的修正意见都是最宝贵的提示词优化素材和知识库补充来源。如果你做了 Agent 但没有记录评审中的每次修改那你只是用了半套方案。6.2 我打算继续做的三件事后续我想在这个方向做三件事一是把 Agent 的初稿能力扩展到时序逻辑安全分析和预期功能安全验证场景生成覆盖更多 SOTIF 落地环节二是把信息安全的漏洞情报和事件响应闭环接入 REANA让风险评估能根据实时威胁情报自动触发更新三是建立跨项目的安全知识飞轮让每次人工评审后的修正数据都能持续改善后续初稿质量。6.3 给后来者的最小启动建议如果你也在做类似的方向我的建议很简单选一个最痛的安全环节搭一个 40 分钟闭环的最小 Agent 原型用自己的历史项目数据做测试。先别急着追求完整的三安一体跑通一个环节你就知道下一步该怎么走了。这比读一百篇架构文章都有用。