做功能安全这些年，我越来越觉得这行最大的痛点不是方法论不懂，而是模型写不完。ISO 26262、ISO 21448、ISO/SAE 21434三条标准压下来，一个L2+的ADAS项目光HARA、SOTIF、TARA三轮分析，建模和文档工作量就能拖垮整个安全团队。我去年牵头做了一个内部Agent平台，代号REANA，全称是Reliability & Engineering Analysis with Natural-language Agents，核心目标就是把功能安全、SOTIF、信息安全这三种分析从"人建模型"推进到"Agent建初稿"。这篇文章把我踩过的坑、最终定型的架构、以及实测效果完整记录下来，希望能给正在往这个方向走的安全工程师和AI应用开发同学一些参考。
1. 三安一体的背景与REANA的核心定位
1.1 为什么一定要把三条标准"压到一个平台"
功能安全管的是系统因随机硬件故障和系统性失效导致的风险，SOTIF管的是预期功能本身能力不足、规范不完备和可合理预见误用带来的风险，信息安全管的是攻击者利用漏洞威胁车辆安全的风险。过去这三条线在大多数OEM里是三个团队各做各的，从流程、文档模板到评审体系都是三套。
但到了自动驾驶和软件定义汽车阶段，这三条线实际是"长在一起"的。一台L3级自动驾驶车在高速上突然急刹，原因可能是感知算法在逆光下漏检前方静止车辆，这是SOTIF；也可能是域控制器内存被非预期数据破坏导致计算降级，这是功能安全；还可能是攻击者通过诊断接口注入伪造制动报文，这是信息安全。同一个危险场景，三条标准都会对它提要求，如果各自为政，就会出现三个典型问题：重复建模但描述不一致、跨领域的需求链路断裂、评审会议上三拨人互相争吵。
REANA想解决的不是"把三份文档放进同一个文件夹"，而是让一个分析任务同时考虑三类失效来源，联合输出一份带交叉引用的安全初稿。说白了，安全分析的对象是同一台车，那分析本身就不该分裂成三个孤岛。
1.2 REANA到底是一个什么形态的产品
REANA不是提示词套壳，也不是一个大家随手调戏的聊天机器人。它是一个面向安全分析场景的工作台级智能体：工程师输入相关项定义、系统架构、功能清单、场景库，REANA内部的主控Agent会解析任务、拆解流程，调用场景分析、危害识别、评级计算、交叉比对等不同职能的子Agent和工具，最后产出一份结构化、可追溯的安全分析初稿。初稿里的每一项声明尽量挂接依据，比如场景编号、标准条款号、功能名来源，方便人工评审时快速核实。
这个定位避开了两个极端。第一个极端是让Agent完全替代工程师做安全分析，这在当前模型能力下不现实，出了事责任归属也完全不可接受。第二个极端是只把Agent用成能问会答的文档助手，那它和普通代码助手没有本质区别，解决不了团队流程级的低效。REANA取的是中间态：Agent负责建初稿、做交叉检查、自动评级、生成需求草稿，工程师负责定义输入、审核中间结果、拍板最终结论。这个分工贯穿后续所有设计。
1.3 从"人建模型"到"Agent建初稿"到底改变了什么
传统安全建模，很多人以为核心是"分析"，我做下来感觉真正消耗时间的是"抄写和编排"。在Excel里拉场景矩阵、在Word里逐条写危害事件、按S/E/C三个维度打分、把安全目标从一个文档复制到另一个文档，这些活占了工程师至少七成时间。真正需要人的判断力的部分，比如某个事故的严重程度到底定S2还是S3、某个场景的暴露概率权重怎么给，占的时间反而不多。
但因为那三成判断力的存在，前面七成的体力活也必须由懂行的工程师来做，不敢轻易外包给普通工具。Agent建初稿先把这七成拿掉：REANA把安全工程师的经验拆成可复用的规则和提示模板，让Agent批量生成场景清单、危害事件描述、评级理由、安全目标草案，工程师只负责审，不负责写。
这个转变最大的收益还不是速度快，而是一致性。模型不会因为下午精神不好就漏写一个暴露度评级，同一份场景库按同一套配置跑十次，输出结构是稳定的。这个特性在安全审计场景下价值非常大。
2. 关键技术选型与Agent架构设计
2.1 分层的Agent架构：不是一个Agent，而是一组带协作关系的Agent
从第一版用一个超长Prompt硬刚，到最后定型的架构，中间大概推翻了三四版。最初的想法很简单：把标准条款、场景库、功能描述全塞进一个上下文，让大模型一口气输出HARA和TARA。结果惨不忍睹，上下文一长，后面的分析质量断崖式下跌，而且中间任何一个环节出错都要整个重跑。
最终REANA采用的是"调度器+领域子Agent+工具"的分层架构：
- 调度层：负责任务解析、工作流编排、上下文汇总、结果校验，维护整个分析任务的进度和依赖关系。
- 领域层：按安全领域拆分，包括场景分析Agent、HARA Agent、SOTIF Agent、TARA Agent、交叉检查Agent、报告生成Agent。
- 工具层：标准知识库查询、评级计算器、需求编号生成器、文档渲染器、DOORS导出器。
- 记忆层：短期记忆保存当前分析任务的中间状态，长期记忆保存历史案例、评审意见、常见错误。
拆分的根本原因在于，三安一体化分析不是一次问答能完成的，它天然是多阶段流程：场景先要被理解，然后分别从三条标准的视角去分析，最后合并交叉点。所有这些在一个chat上下文里全做完，模型窗口根本不够用，输出质量也无法保证。拆成子Agent各自负责一段，每一段都有明确的输入输出模式，中间上下文可以压缩成结构化数据传递，稳定性和可调试性都会好很多。
2.2 为什么核心引擎用Rust而不是Python或Node
REANA的编排核心最终落在Rust上，这个选择在AI项目里有点反直觉，因为绝大多数团队会用Python。主要考虑有三个点。
第一是可靠性。Agent编排是典型的并发密集型场景，多个子Agent并行输出、工具异步调用、状态频繁切换，用Python写这种系统，稍微一乱就出现野指针和状态污染问题。Rust的所有权系统和类型系统能在编译期拦住一大批并发错误，内存安全问题几乎不可能出现。
第二是资源占用。模型推理已经占了大量CPU和显存，调度层再背一个Python运行时，很多开发机和内网的虚拟机上根本跑不动。Rust编译出来是单个轻量二进制，部署简单，跑起来占资源也少得多。
第三是高频本地工具的性能。评级计算、文档格式校验、白名单核对这些逻辑在分析过程中会被反复调用，用Rust直接内联，比Python和Node之间来回IPC效率高得多，出错面也小。
当然，不是全项目都用Rust。模型API客户端、数据处理、向量数据库连接这些AI生态工具链最成熟的部分，我们仍然保留Python。Rust核心服务通过gRPC和Python侧通信。核心编排在Rust，生态胶水在Python，边界清晰，两边各用各的强项，这是最终稳定下来的分工。
2.3 模型选择与三安提示词工程
模型选型我们最开始只试了一个超大尺寸闭源模型，效果不算差，但有三个问题：成本高、数据合规风险大、关键环节黑盒程度太高。安全分析数据通常是企业内部敏感数据，直接全量丢给云端模型，法务和安全部门不会同意。后面改成混合推理方案：本地部署开源底座模型，负责日常场景分析和草稿生成；风险等级复核、交叉检查这类需要强推理的环节，走云端更强的模型API。所有模型调用前面都做敏感信息脱敏，VIN、精确GPS轨迹、个人身份信息在进入模型前替换成占位符。
提示词方面，我们基本不用自由对话式提示。所有子Agent的System Prompt统一为"角色定义-任务说明-输入模式-输出模式-约束说明-示例"六段结构。我拿HARA Agent举例，最终Prompt模板大概长这样：
角色定义：你是一名资深HARA分析师，熟悉ISO 26262第3部分和第4部分，具备ASIL评级经验。 任务说明：给定相关项定义、功能清单、场景属性表，识别危害事件并输出危害事件表。 输入模式： - item_definition: {item_name: ..., item_description: ...} - functions: [{function_id, function_description}] - scenarios: [{scenario_id, road_type, weather, traffic, speed_range, lighting}] 输出模式：JSON，必须符合如下Schema： { "hazard_events": [{ "hazard_event_id": "HE-001", "function_id": "FUN-ACC-01", "scenario_id": "SCE-HW-R01", "hazard_description": "...", "harm_description": "...", "severity_criteria": "枚举值：S0/S1/S2/S3", "exposure_criteria": "枚举值：E0-E4", "controllability_criteria": "枚举值：C0-C3", "source_refs": ["条目标识"] }] } 约束说明： - 不得编造功能清单和场景库中不存在的功能或场景。 - 所有枚举值必须从给定词表选择，不得自由发挥。 - 评级理由必须说明依据，无法挂接依据时写"模型推理"。 示例：……最重要的细节是输出模式强制JSON Schema，让Agent输出结构化数据而不是自然语言。自然语言段落只允许出现在理由字段里。这样下游的评级计算器、交叉比对器、报告渲染器才能稳定处理，不会被模型自由发挥带偏。
2.4 标准知识库与RAG：让Agent"按条款说话"
纯靠模型的训练知识做安全分析，很容易编出"看起来像标准条款、实际上根本不存在"的条目。REANA启动前我们花了大功夫做标准知识库：把零散的ISO 26262、ISO 21448、ISO 21434标准文本、企业内部安全流程模板、历史项目安全案例，统一解析成结构化知识条目。每条知识都带来源标准、条款号、类别、关键词、关联条款这些元数据，然后用向量索引加关键词索引双路检索。
RAG这里我们踩过一次大坑。刚开始只做向量相似度检索，结果条款引用经常张冠李戴，因为安全标准里"10.4.2 Clause 1"这种编号形式非常相似，语义也接近，向量距离拉不开。后来改成混合检索：先按条款号精确匹配和关键词命中，再做向量召回去重融合，最后按标准的章节结构做重排。这样Agent引用条款时，准确率从不到70%提升到了95%以上。工程师审核产出时点一下引用编号就能调出原文，这一步是取得安全评审组信任的关键。
3. 实操：把三种安全分析变成Agent工作流
3.1 功能安全：HARA自动化建模的完整流程
先拿功能安全的HARA来说一条完整工作流。输入侧三个前置条件：相关项定义、功能清单、运行场景库。场景库我们用OpenSCENARIO和内部表格两种格式维护，Agent优先读表格化后的场景属性，包括道路类型、天气、交通参与者、车速区间、光照，这样每个场景就是一个结构化字典，模型不容易丢失细节。
执行链是这样的：
- 调度器解析相关项定义和功能清单，把待分析功能（比如自适应巡航控制ACC）作为主任务分发给场景分析Agent。
- 场景分析Agent从场景库中过滤出与ACC相关的场景：高速、城市、雨天、隧道、行人横穿等，并补充变体。
- HARA Agent基于"功能×场景"组合识别危害事件。例如雨天场景下，ACC该减速不减速，危害事件描述为"车辆未按预期减速导致与前方车辆碰撞"。
- 评级Agent把危害事件映射到S/E/C等级的判据描述，再由评级计算器用规则引擎算出最终ASIL。这步的设计很关键，后面细说。
- 输出安全目标草稿，比如"车辆应确保在检测到前方静止或低速目标时，在标定减速度范围内可靠减速，避免碰撞"。
- 报告生成Agent把危害事件表、评级结果、安全目标、依据引用渲染成标准格式初稿。
实际上我们把工作流配置写成了YAML，方便调整：
workflow: hara agent_chain: - scenario_agent - hara_agent - rating_agent - safety_goal_agent - cross_check_agent input_artifacts: - item_definition - function_list - scenario_library rules: rating_engine: local_rule_table output_schema: hara_initial_draft_v2这里有个核心认知：ASIL不是一个让模型"感觉"出来的值，它是一个查表函数，S/E/C三档输入映射到QM、A、B、C、D五个等级是刚性规则。模型偶尔一次算错，在安全评审里就是一次事故。所以REANA里模型只做"把情况描述翻译成等级判据"，等级判据到ASIL的映射统统交给确定性规则引擎。规则引擎永不出错，模型负责的是它擅长的事。
3.2 SOTIF：从触发条件到风险可接受性
ISO 21448的分析逻辑和功能安全不同，它聚焦预期功能能力的局限性。REANA的SOTIF Agent输入除了系统功能描述和场景库，还要加上性能边界描述，比如感知系统的探测距离、算法在雨雾天气的退化程度、定位在高架下的精度漂移。
工作流分四步。第一步识别功能不足和性能局限，Agent列出ACC在特定场景下的薄弱环节，比如"摄像头在逆光条件下对前方车辆识别置信度下降"。第二步识别触发条件：雨强、逆光角度、前方车辆类型、路面标线缺失等，Agent把这些触发条件映射到场景属性。第三步生成SOTIF危害事件：把功能不足与场景组合，比如"逆光且前车车身反射较强时，ACC未识别前车，导致低速追尾"。第四步做风险可接受性判定，REANA没有让Agent自己算"可接受不可接受"，而是让Agent给出危害严重度等级和发生概率的估计依据，再由企业定义的风险矩阵去判定。
SOTIF Agent还有一个特别重要的职责：把分析结果反向映射到功能安全领域。如果某个SOTIF触发条件无法通过功能增强消除，就必须设计功能安全机制，比如"感知置信度低于阈值时触发降级请求，要求驾驶员接管"。这个映射关系就是"三安一体"最体现价值的部分：标准层面是两条线，工程层面是一条链。
3.3 信息安全：用STRIDE和攻击路径生成TARA
TARA和功能安全分析在工作流上有天然相似性：识别资产、识别威胁、评级、生成需求。REANA的TARA Agent复用了共享框架，但也有自己的特殊性。
第一步资产识别。TARA Agent从系统架构描述里抽取通信资产比如CAN总线、以太网交换机、诊断通道，数据资产比如车辆密钥、位置数据、OTA包，功能资产比如ACC启动、制动控制接口。每个资产标注完整性、机密性、可用性三类属性，特别标注是否影响Safety。
第二步威胁场景识别。用STRIDE六个维度做思维脚手架：Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilege。比如针对"制动控制CAN报文"资产，Spoofing威胁场景是攻击者伪造报文注入假制动请求，Tampering威胁场景是篡改ECU制动标定参数。
第三步攻击路径分析。模型这里容易编造过于理想的攻击路径，我们做了硬限制：TARA Agent只能基于架构图里的已连接组件和通信链路生成路径，目标组件之间没有连接关系时，路径不允许被发明。
第四步风险评级。采用影响等级和攻击可行性的二维矩阵，同样用规则引擎计算，模型生成影响描述和可行性论证。最后输出网络安全目标和网络安全需求草稿，需求属性里打上关联的资产ID和威胁ID，方便追溯。
3.4 交叉检查与三安联合输出：REANA最"值钱"的部分
如果REANA只是把三种分析用三个Agent分别做，那它最多算三套工具的加速器，谈不上三安一体。真正把它连成一体的是交叉检查Agent和背后的联合分析规则。
交叉检查要做三件事。第一类是重复项合并：同一危害事件在HARA和SOTIF里都可能出现，比如逆光漏检在功能安全模型里被写成"感知失效"，在SOTIF里被写成"性能局限"。交叉检查Agent把描述规范化后按场景和后果自动聚类，标记为共享危害事件，生成合并后的综合需求。
第二类是机制冲突检查。信息安全Agent可能建议通过OTA更新修复漏洞，功能安全流程要求固件更新必须经过完整验证，两者存在潜在冲突，交叉检查Agent检测到后在报告里标记"需人工协调"。
第三类是缺口识别。比如TARA发现某个对外接口存在攻击面，但HARA没有把该接口失效列为危害事件，Agent会提醒补充分析。
输出端我们设计了三安联合分析报告，前半部分按标准要求的章节组织，便于审计，后半部分是交叉分析附表：共享危害事件清单、机制依赖关系表、待协调问题列表。这份报告既能直接进评审，又可以拆开灌回各自的合规文档。
4. 实测中的常见问题与避坑手册
4.1 幻觉问题：Agent编造标准条款和功能行为
安全分析场景里幻觉不可接受。实测遇到最多的是两类幻觉：编造标准条款，比如引用"ISO 26262-3:2018 8.4.2"但实际条款内容完全对不上；编造系统功能，架构里根本没有"雷达前融合模块"，Agent却写"该模块在雨雾天气下性能下降"。
处理方案是双管齐下。一方面Prompt强制要求所有硬性声明必须挂接依据，JSON Schema里技术声明字段都带source字段，无法挂接就写"模型推理"。另一方面报告生成阶段做事实核对：用系统架构清单、功能清单、知识库条款索引做白名单，对Agent输出中的功能名、组件名、条款号自动比对，不在白名单里的直接标记"疑似虚构"，严重时阻断生成。这个白名单校验看起来笨，但实测极其有效，把幻觉暴露率降到了接近零。
4.2 评级不一致：同一危害不同批次跑出不同结果
模型有随机性，同样的输入换一个温度参数，输出可能从ASIL C飘到ASIL B，这在安全评审里是硬伤。解决评级漂移的思路前面说过：模型不直接输出等级，只输出等级判据枚举值，规则引擎查表。但判据描述本身也可能漂移，比如一次把事故后果写成"轻微受伤"，另一次写成"骨折"，S等级自然不同。
这个问题靠建模规范约束：场景库和危害事件模板里预置事故后果枚举词表，Agent只能在"重伤、轻伤、财产损失"这类固定选项里选，不允许自由发挥。等级判据在一个项目内保持一致，规则引擎算出的等级自然稳定。
4.3 安全工程师如何审查Agent产出：人机协作的评审流程
Agent建初稿后，评审的质检点变了。工程师要看的不是"有没有写全"，而是"有没有写对"。我们建立了四层评审机制：第一层Agent自检，交叉检查Agent先跑一致性检查；第二层三条线的领域专家分别审自己领域章节，重点看场景覆盖率和评级依据；第三层系统安全评审会看交叉部分，尤其是待协调问题列表；第四层配置管理和发布流程，定稿后进正式基线管理。
还有一个非常重要的经验：Agent处理过程必须留痕。REANA给每个分析任务生成运行日志，包含每个Agent的输入摘要、调用的工具、命中的条款、关键输出快照。审计时能讲清楚"这份报告是Agent生成、人工已审核修改"的完整链路。这个小设计在质量体系审核时比说一百句"我们有人工把关"都管用。
4.4 与传统工具链对接：DOORS、Medini以及文档格式之痛
现实环境里，没有哪家OEM会为Agent平台把已有安全工具生态全推翻。REANA从第一天就考虑跟DOORS、PTC Integrity、Medini Analyze这些存量工具共存。做法是以导出导入为桥：报告生成Agent除了输出Word和Markdown，还生成ReqIF文件和Excel模板，DOORS可以通过ReqIF导入需求条目；评级结果输出为符合Medini导入格式的分析表。需求编号规则沿用企业现有编码规范，追溯链不断。
这里有个教训：别等到对接阶段才考虑格式。我们第一版报告样式是按自己喜好定的，后来导出到DOORS时字段映射一团乱，又花两周改模板。正确顺序是：先拿到目标工具的字段定义和导入模板要求，再反过来设计Agent输出的JSON Schema和Excel列结构。格式问题看起来技术含量不高，但往往决定平台能否真正落地。
5. 落地效果与团队工作方式的改变
5.1 一个实际项目的效率对比
以内部一个L2+级ADAS项目试点为例，行车和泊车两大类功能，初始功能清单约40个功能、场景库约120个场景。传统方式走一轮HARA，熟练工程师大概需要两到三周，加上文档润色和评审准备要一个月；SOTIF分析再加两三周；TARA因为信息安全团队人力更紧张，排期更久。
用REANA跑，四种分析的初稿生成在半天内完成，之后领域专家评审、修正和定稿大约花了一周。整体从项目启动到可提交评审的分析初稿，时间从八周压到十天左右。这个数字不是AI替代人的功劳，主要原因是Agent把大量格式化、抄写、重复建模工作干掉了，工程师的时间全花在真正需要判断力的地方。
5.2 团队角色的变化：从"写模板的人"到"审结论的人"
落地半年后，团队的工作方式发生了一个有意思的变化：安全工程师的角色从文档生产者慢慢变成了分析评审者。新人不再花半年学怎么写HARA表、怎么算ASIL，而是直接上手用REANA生成初稿，在审核过程中理解"为什么这个评级合理""为什么这个场景要覆盖"。经验丰富的老工程师可以同时review多个子系统的初稿，把精力集中在最难的交叉分析和决策上。这个变化对组织来说比省几周工期更有价值。
当然，新角色需要补齐新技能：怎么正确地质疑Agent产出。工程师要学会快速判断"这条场景是不是实际会发生的场景""这个评级理由和标准条款是否真的对应"。安全培训内容里已经增加了相应模块，否则平台用得越熟练，纸面上的错误可能越隐蔽。
5.3 后续扩展：从建初稿到持续监控
REANA目前最值得投入的方向不是继续优化建初稿，而是把Agent的安全分析能力做进全生命周期的持续反馈闭环。开发阶段Agent生成的危害事件和触发条件，在实车测试阶段可以直接转成测试用例候选集合；试运行阶段采集到的场景数据，比如某地区雨天事故数据、用户误用行为数据，再回流给Agent，让SOTIF危害库持续演进；信息安全方面，新漏洞情报也可以作为TARA的输入，让威胁模型不再是半年一年更新一次，而是随着威胁环境持续刷新。
最后分享一点个人体会。做REANA这一路我最大的认知变化是：不要让Agent替你决策，而是让Agent替你完成"构建草稿"这种高重复劳动。安全分析最终的责任仍然在人身上，Agent的作用是把工程师从抄写和重复建模的深坑里解放出来，让他们把精力放到真正需要人类判断力的地方。后续谁能在"人机协同的安全分析"这个模式上走得最稳，谁就能在三安融合的大趋势里拿到真正的效率红利。
