企业官网建设流程全解析

1. 项目缘起：为什么汽车安全领域需要“三安一体”的智能体

汽车行业做功能安全、预期功能安全和信息安全的同行都有一个共同感受：标准越读越厚，文档越写越多，但真正落到项目里的效率提升却非常有限。ISO 26262 要求危害分析与风险评估、安全目标、功能安全概念、技术安全需求一路推导下来，每一层都要有追溯关系；ISO 21448 针对预期功能安全又要求考虑性能局限和可预见误用；ISO/SAE 21434 则把信息安全从威胁分析、风险评估到安全概念、安全需求全部串起来。三套标准各自独立，但落到同一个 ECU 或同一个域控制器上时，它们共享同一套系统架构、同一份需求库、同一批验证证据。

问题就出在这里。过去我们做安全分析，基本是“人建模型”——工程师打开 Medini、Ansys medini analyze 或者 Excel 模板，手动建结构树、画 HARA 表、填 S 值 E 值 C 值、推导 ASIL 等级，然后再把结果复制到另一份文档里做 SOTIF 的触发条件分析，再复制到第三份文档里做 TARA 分析。一个中等复杂度的域控制器项目，光安全分析文档就能堆到上千页，而且三套分析之间的追溯关系全靠人工维护。一旦架构变更，比如换了一颗 SoC 或者调整了通信矩阵，三份文档都要同步改，漏改一处就是审核不符合项。

REANA 这个项目要解决的就是这个断层。它的核心思路是把功能安全、SOTIF 和信息安全三套方法论做成一个统一的智能体框架，让 Agent 基于系统架构描述和需求输入，自动生成三份安全分析的初稿，并且保证三者之间的追溯关系是内建在模型里的，而不是靠人工维护的。换句话说，从“人建模型”转向“Agent 建初稿”，工程师的角色从“从零画表”变成“审阅和修正 Agent 的输出”。

这个转变的意义在于：安全分析中最耗时的部分不是判断风险等级，而是把系统架构、需求、失效模式、触发条件、威胁场景这些信息按照标准要求的格式组织成可追溯的模型。这部分工作有很强的模式性，适合 Agent 来做初稿。而真正的工程判断——比如某个失效模式的 ASIL 等级是否合理、某个触发条件的可控性评估是否准确——仍然需要资深工程师把关。

适合读这篇内容的人包括：做汽车功能安全或信息安全的工程师、安全经理、想了解 Agent 在工程领域落地的开发者，以及正在考虑把 AI 引入安全流程的团队负责人。不需要你精通 Agent 开发，但需要对汽车安全标准有基本认知，至少知道 HARA、TARA、ASIL 这些概念是什么意思。

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

2.1 为什么不是三个独立的 Agent 而是“一体”

一个自然的想法是：功能安全做一个 Agent，SOTIF 做一个 Agent，信息安全再做一个 Agent，三个 Agent 各干各的，最后人工合并。这个方案听起来模块化，但实际落地会踩一个大坑——三套分析共享的底层信息不一致。

举个具体例子。功能安全做 HARA 时，会识别出“制动扭矩输出异常”这个危害，推导出安全目标“防止制动扭矩非预期输出”。SOTIF 分析时，会识别出“由于传感器性能局限导致制动扭矩误判”这个触发条件。信息安全做 TARA 时，会识别出“攻击者篡改制动控制报文导致扭矩异常”这个威胁场景。这三个分析其实指向同一个系统行为，但如果在三个独立 Agent 里分别生成，它们对“制动扭矩输出异常”这个失效的描述、对相关组件的命名、对追溯关系的表达很可能不一致。合并的时候就要人工对齐，工作量不比从头做小。

REANA 的做法是建一个统一的安全知识图谱作为共享底座。这个图谱里包含系统架构模型（组件、接口、数据流）、需求模型（安全需求、信息安全需求、SOTIF 需求）、危害与威胁模型（危害事件、威胁场景、触发条件）、以及追溯关系模型。三个安全领域的 Agent 都读写同一个图谱，只是各自关注的节点类型和关系类型不同。功能安全 Agent 主要操作危害事件和安全目标节点，SOTIF Agent 主要操作触发条件和性能局限节点，信息安全 Agent 主要操作威胁场景和攻击路径节点。但它们共享同一套系统架构和需求节点，所以追溯关系天然一致。

这个设计的关键决策是：图谱的 schema 必须足够通用，能同时表达三套标准的概念，又不能太抽象导致 Agent 无法理解。REANA 选择了一个折中方案——用属性图模型，节点类型包括 Component、Interface、Function、Requirement、Hazard、Threat、TriggerCondition、SafetyGoal、SecurityGoal 等，边类型包括 realizes、mitigates、triggers、tracesTo、violates 等。这个 schema 不是标准里直接定义的，而是从三套标准的概念映射中提炼出来的。

2.2 Agent 编排：谁先谁后，谁依赖谁

三安一体不是三个 Agent 并行跑就完事。它们之间有明确的依赖关系。功能安全的 HARA 输出——危害事件和安全目标——是 SOTIF 分析的输入之一，因为 SOTIF 要分析的是“在功能安全已经识别出的危害基础上，哪些是由性能局限或可预见误用导致的”。信息安全的 TARA 又需要参考功能安全的安全目标，因为很多安全目标本身就是信息安全要保护的对象。

REANA 的编排策略是分阶段串行加局部并行。第一阶段，功能安全 Agent 先跑，基于系统架构和功能描述生成 HARA 初稿，输出危害事件列表、S E C 评估、ASIL 等级、安全目标。第二阶段，SOTIF Agent 和信息安全 Agent 并行跑。SOTIF Agent 读取功能安全的危害事件，结合系统性能局限和场景描述，生成触发条件和 SOTIF 相关需求。信息安全 Agent 读取功能安全的安全目标和系统架构，结合威胁库和攻击路径分析，生成威胁场景和信息安全需求。第三阶段，一个一致性检查 Agent 跑一遍，检查三份输出之间是否有矛盾，比如某个安全目标在信息安全分析里没有被覆盖，或者某个触发条件在功能安全里没有对应的危害事件。

这个编排逻辑不是拍脑袋定的，而是基于三套标准在实际项目中的依赖关系。功能安全是基础，因为它的 HARA 定义了系统的安全边界。SOTIF 和信息安全是在这个边界内做更细化的分析。如果反过来先做信息安全，可能会识别出一堆威胁场景，但不知道哪些威胁会导致功能安全危害，优先级排不出来。

2.3 为什么用 Agent 而不是传统规则引擎

有人会问：这种模式化的分析工作，用规则引擎或者模板引擎不就行了吗，为什么要用 Agent？这个问题我在项目初期也纠结过。规则引擎的优势是确定性，输入一样输出永远一样，适合审核追溯。但安全分析的难点在于，很多判断不是纯规则能覆盖的。

比如 HARA 里的 S 值评估，标准里给了参考表，但具体到某个危害事件，S 值是 S2 还是 S3，取决于危害发生时驾驶员和乘客的受伤程度。这个判断需要结合系统功能、车辆类型、使用场景来综合推理。规则引擎只能处理“如果车速大于 X 且碰撞方向为 Y 则 S 值为 Z”这种硬编码规则，但实际项目中车速和碰撞方向的组合千变万化，硬编码规则库会膨胀到无法维护。

Agent 的优势在于它能基于上下文做推理。你给它一个危害事件描述和系统上下文，它能结合标准里的评估原则，给出一个有理有据的 S 值建议，并且能解释为什么这么选。工程师审阅时如果不同意，可以直接改，Agent 会记录这个修正并在后续类似场景中参考。这种“可解释的推理加可修正的输出”是规则引擎做不到的。

当然，Agent 也有它的风险——幻觉。它可能生成一个看起来合理但实际不符合标准的输出。REANA 的应对策略是双保险：一是所有 Agent 输出都必须附带推理依据，引用标准条款或项目上下文；二是一致性检查 Agent 会交叉验证，比如检查 ASIL 等级和 S 值 E 值 C 值的组合是否匹配标准里的 ASIL 判定表。如果发现不一致，标记出来让工程师复核。

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

3.1 安全知识图谱的构建与维护

图谱是整个系统的地基，建得不好后面全白搭。REANA 的图谱构建分三步走。

第一步是系统架构导入。支持从常见的架构描述格式导入，比如 SysML 模型、Excel 架构表、或者简单的 JSON 描述。导入后自动解析出 Component、Interface、DataFlow 三类节点和它们之间的关系。这一步的难点在于不同项目的架构描述粒度不一致。有的项目把 ECU 作为一个组件，有的项目把 ECU 里的每个软件模块都作为组件。REANA 的做法是让用户指定一个“分析粒度”参数，Agent 根据这个参数决定是否对导入的架构做聚合或展开。

第二步是需求关联。把功能安全需求、信息安全需求、SOTIF 需求挂到对应的组件或功能节点上。这一步通常需要人工介入，因为需求文档的格式千差万别。REANA 提供了一个半自动的需求抽取 Agent，能从自然语言需求描述里识别出“这个需求是关于制动的”“这个需求涉及 CAN 通信”，然后建议挂载位置。工程师确认后正式建立关联。

第三步是安全分析结果的回写。每次 Agent 生成 HARA、TARA 或 SOTIF 分析结果后，都会把新产生的节点和边写回图谱。比如功能安全 Agent 生成了一个危害事件节点，它会自动建立这个危害事件到相关组件和功能的 tracesTo 边。这样图谱会随着分析迭代越来越丰富，后续 Agent 跑的时候能利用的历史信息也越来越多。

注意：图谱的 schema 一旦确定，不要轻易改。改 schema 意味着所有已有节点和边的类型都要迁移，成本很高。建议在项目初期花时间把 schema 设计到位，至少覆盖三套标准的核心概念。

实操心得：图谱的节点命名规范要统一。我见过一个项目，同一个组件在功能安全分析里叫“Brake_ECU”，在信息安全分析里叫“制动控制器”，在 SOTIF 分析里叫“ brake ecu ”，结果追溯关系全断了。REANA 的做法是强制使用架构导入时的原始命名，Agent 生成新节点时也必须引用已有节点的 ID 而不是名称。

3.2 功能安全 Agent 的 HARA 生成逻辑

HARA 是功能安全分析的起点，也是三安一体里最复杂的部分。REANA 的功能安全 Agent 按以下流程工作。

首先，Agent 读取系统架构和功能描述，识别出需要做 HARA 的功能。不是所有功能都需要做 HARA，只有那些失效后可能导致危害的功能才需要。Agent 会根据功能的安全相关性标注来判断，这个标注可以来自需求文档，也可以由工程师预先指定。

然后，对每个安全相关功能，Agent 枚举可能的失效模式。这里用到了一个失效模式库，包含常见的失效类型：功能丧失、功能异常输出、功能输出卡滞、非预期激活等。Agent 会根据功能的具体描述，从库里选择适用的失效模式，并生成具体的失效描述。比如对于“制动扭矩输出”功能，Agent 会生成“制动扭矩非预期增大”“制动扭矩非预期减小”“制动扭矩输出延迟”等失效模式。

接下来是 S E C 评估。S 值评估危害的严重程度，E 值评估暴露概率，C 值评估可控性。Agent 对每个失效模式，结合车辆使用场景和驾驶员控制能力，给出 S E C 的建议值。这里 Agent 会引用标准里的评估原则，比如 S3 对应“危及生命”的伤害，S2 对应“严重但非致命”的伤害。E 值根据暴露场景的出现频率来定，比如“每次驾驶都会出现”对应 E4，“极少出现”对应 E1。C 值根据驾驶员能否及时控制来定，比如“无法控制”对应 C3，“容易控制”对应 C1。

最后，根据 S E C 的组合查 ASIL 判定表，得出 ASIL 等级，并生成安全目标。安全目标的描述要包含“防止什么”和“在什么条件下”，比如“防止制动扭矩非预期增大导致车辆非预期减速，在车速高于 20km/h 时”。

提示：Agent 生成的 S E C 值一定要人工复核。我见过 Agent 把“安全气囊非预期展开”的 S 值定为 S2，理由是“气囊展开本身不致命”，但它忽略了气囊非预期展开可能导致驾驶员惊慌失控，进而引发碰撞。这种间接危害的评估是 Agent 容易漏掉的地方。

3.3 SOTIF Agent 的触发条件分析

SOTIF 分析和功能安全分析的最大区别在于：功能安全关注的是系统失效导致的危害，SOTIF 关注的是系统在没有失效的情况下，由于性能局限或可预见误用导致的危害。所以 SOTIF Agent 的工作重点是识别触发条件。

REANA 的 SOTIF Agent 从三个维度识别触发条件。第一个维度是传感器性能局限。Agent 读取系统里所有传感器的规格参数，比如摄像头的分辨率、毫米波雷达的探测距离和角度、激光雷达的点云密度，然后结合使用场景分析在什么条件下这些传感器的性能会不足。比如“强光直射导致摄像头过曝，无法识别前方车辆”就是一个典型的触发条件。

第二个维度是算法性能局限。Agent 分析感知算法、规划算法、控制算法的已知局限。比如“目标分类算法在雨天将卡车误判为背景”或者“路径规划算法在施工区域无法生成合理轨迹”。这些局限通常来自算法开发团队的输入，Agent 把它们和具体的场景关联起来。

第三个维度是可预见误用。Agent 基于功能的使用说明和驾驶员行为模型，分析驾驶员可能怎么误用这个功能。比如“驾驶员在系统提示接管后未及时接管”或者“驾驶员在非设计运行域内激活功能”。

每个触发条件生成后，Agent 会把它和功能安全 Agent 生成的危害事件做关联。如果某个触发条件可能导致某个危害事件，就建立一条 triggers 边。这样 SOTIF 分析和功能安全分析就串起来了。

注意：SOTIF 的触发条件分析很容易和功能安全的失效模式分析混淆。区分方法是：如果这个原因涉及硬件或软件的失效，归功能安全；如果涉及的是性能不足或人为误用，归 SOTIF。但实际项目中有些场景是交叉的，比如“传感器在特定天气下性能下降”既是性能局限也是潜在的失效诱因。REANA 的处理方式是允许一个场景同时关联到危害事件和触发条件，但在追溯关系上分别标注。

3.4 信息安全 Agent 的 TARA 生成逻辑

TARA 的核心是威胁场景识别和风险评估。REANA 的信息安全 Agent 按以下步骤工作。

第一步是资产识别。Agent 从系统架构里识别出需要保护的信息安全资产，包括软件组件、通信数据、存储数据、诊断接口等。资产识别不是把所有东西都列上，而是根据资产的安全属性来筛选。比如一个只读的传感器数据，如果被篡改会影响功能安全，那它就是资产；如果被篡改只影响舒适性功能，那它的优先级就低。

第二步是威胁场景生成。Agent 使用一个威胁库，包含 STRIDE 分类下的常见威胁类型：欺骗、篡改、否认、信息泄露、拒绝服务、权限提升。对每个资产，Agent 枚举适用的威胁类型，并生成具体的威胁场景描述。比如对于“制动控制报文”这个资产，Agent 会生成“攻击者篡改制动控制报文导致制动扭矩异常”这个威胁场景。

第三步是攻击路径分析。Agent 分析攻击者可能通过什么路径到达目标资产。这需要结合系统的通信拓扑和接口暴露情况。比如如果制动控制报文通过 CAN 总线传输，而 OBD 接口可以访问 CAN 总线，那攻击路径就是“通过 OBD 接口接入 CAN 总线，发送伪造的制动控制报文”。

第四步是风险评估。Agent 根据攻击可行性、影响程度、攻击复杂度等因素，给出风险等级。这里 Agent 会参考功能安全的安全目标，因为很多安全目标本身就是信息安全要保护的对象。如果某个威胁场景会导致安全目标被违反，那它的风险等级会自动提升。

提示：信息安全 Agent 的威胁库需要定期更新。新的攻击手法和漏洞类型层出不穷，如果威胁库不更新，Agent 生成的威胁场景会越来越脱离实际。REANA 的做法是支持威胁库的插件式扩展，团队可以把自己积累的威胁场景导入库中，Agent 在生成时会优先匹配库里的已知威胁。

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

4.1 环境准备与项目初始化

REANA 的部署方式比较灵活，支持本地部署和容器化部署。本地部署适合小团队快速验证，容器化部署适合集成到 CI/CD 流程里。我建议先用本地部署跑通一个简单项目，熟悉了再上容器化。

本地部署的依赖包括 Python 3.10 以上、Neo4j 图数据库、以及一个 LLM 的 API 接入。Neo4j 用来存安全知识图谱，LLM 用来驱动 Agent 的推理。LLM 的选择上，REANA 不绑定特定厂商，只要支持 function calling 的模型都可以接入。实测下来，对于安全分析这种需要严谨推理的场景，模型的选择很关键。太小的模型容易在 S E C 评估上出错，太大的模型推理成本高。我的经验是选一个中等规模但经过领域微调的模型，效果比通用大模型好。

项目初始化时，需要准备三样东西：系统架构描述文件、功能列表、以及安全相关性标注。架构描述文件支持 JSON 和 Excel 两种格式。JSON 格式更灵活，适合复杂系统；Excel 格式更直观，适合快速上手。功能列表就是系统提供的所有功能，每个功能标注是否安全相关。安全相关性标注可以来自需求文档，也可以由工程师手动标注。

初始化命令很简单：

reana init --project-name my_project --arch-file arch.json --func-file functions.xlsx

执行后 REANA 会创建项目目录，导入架构和功能数据，初始化图谱数据库，并生成一个项目配置文件。配置文件里可以调整 Agent 的推理参数，比如温度、最大推理步数、是否启用一致性检查等。

注意：初始化时如果架构文件里的组件命名有重复，REANA 会报错并列出重复项。这是故意的，因为组件命名重复会导致后续追溯关系混乱。遇到这种情况，先在架构文件里把命名改唯一，再重新初始化。

4.2 功能安全 Agent 的运行与调优

功能安全 Agent 的运行命令是：

reana run --agent fusa --project my_project --output hara_draft.json

运行过程中，Agent 会依次处理每个安全相关功能，生成 HARA 初稿。处理时间取决于功能数量和模型推理速度。一个中等复杂度的域控制器项目，大概有 20 到 30 个安全相关功能，每个功能生成 HARA 初稿需要 30 秒到 1 分钟，总体下来 15 到 30 分钟能跑完。

跑完后，输出文件里包含每个功能的危害事件列表、S E C 评估、ASIL 等级、安全目标。工程师需要逐条审阅。审阅时重点关注三类问题：一是 S E C 评估是否合理，特别是 S 值的间接危害评估；二是安全目标的描述是否完整，有没有遗漏条件；三是 ASIL 等级是否和 S E C 组合匹配。

如果发现 Agent 的输出有问题，可以直接在输出文件里修改，然后执行回写命令：

reana apply --project my_project --input hara_reviewed.json

回写后，修改后的结果会更新到图谱里，同时 Agent 会记录这次修正，在后续类似场景中参考。这个反馈机制是 REANA 比较有意思的地方，用得越多，Agent 的输出越贴合团队的工程习惯。

调优方面，有几个参数值得关注。temperature控制推理的随机性，安全分析场景建议设低一点，0.1 到 0.3 之间，保证输出稳定。max_reasoning_steps控制 Agent 的最大推理步数，设太小可能导致推理不充分，设太大浪费推理成本，一般 10 到 15 步够用。enable_cross_check控制是否启用一致性检查，建议开启，虽然会增加运行时间，但能提前发现很多低级错误。

4.3 SOTIF 与信息安全 Agent 的并行运行

功能安全 Agent 跑完并审阅通过后，就可以启动 SOTIF 和信息安全 Agent 了。这两个可以并行跑：

reana run --agent sotif --project my_project --output sotif_draft.json & reana run --agent security --project my_project --output tara_draft.json & wait

SOTIF Agent 的运行时间通常比功能安全 Agent 短，因为它不需要做 S E C 评估，主要是识别触发条件和关联危害事件。信息安全 Agent 的运行时间取决于威胁库的大小和攻击路径的复杂度，一般和功能安全 Agent 差不多。

并行跑的时候要注意资源竞争。如果两个 Agent 同时读写图谱数据库，可能会出现锁等待。REANA 的做法是给每个 Agent 分配独立的读写事务，通过乐观锁来处理冲突。如果冲突频繁，可以加一个--serial参数改成串行跑，牺牲一点速度换稳定性。

审阅 SOTIF 输出时，重点关注触发条件是否覆盖了所有已知的性能局限和可预见误用。审阅信息安全输出时，重点关注威胁场景是否覆盖了所有高风险资产，以及攻击路径分析是否合理。

4.4 一致性检查与最终报告生成

三个 Agent 都跑完并审阅通过后，执行一致性检查：

reana check --project my_project --output consistency_report.json

一致性检查 Agent 会做以下几类检查。第一类是追溯完整性检查，检查每个安全目标是否至少有一个功能安全需求来支撑，每个危害事件是否至少关联到一个触发条件或威胁场景。第二类是等级一致性检查，检查 ASIL 等级和 S E C 组合是否匹配标准判定表，检查信息安全风险等级和功能安全 ASIL 等级之间是否有矛盾。第三类是命名一致性检查，检查同一个组件在三份分析里的命名是否一致。

检查报告会列出所有发现的问题，按严重程度分级。严重问题必须修复，比如追溯断裂或等级矛盾。轻微问题可以记录但不一定修复，比如命名风格不一致。

最后生成最终报告：

reana report --project my_project --format docx --output final_safety_report.docx

报告包含三份分析的完整内容，以及它们之间的追溯关系矩阵。追溯矩阵是审核时最常被检查的部分，REANA 生成的矩阵是自动从图谱里导出的，保证了和实际分析结果的一致性。

提示：最终报告生成后，建议人工再过一遍追溯矩阵。虽然 REANA 的一致性检查已经覆盖了大部分问题，但有些追溯关系是隐含的，比如某个安全目标通过一系列中间节点间接关联到某个威胁场景，这种间接追溯在矩阵里可能不直观。人工过一遍能发现这类问题。

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

5.1 Agent 输出不符合标准要求怎么办

这是最常见的问题。Agent 生成的 HARA 或 TARA 初稿，有时候会在格式或内容上偏离标准要求。比如安全目标的描述没有包含“防止什么”和“在什么条件下”，或者威胁场景的描述缺少攻击路径。

排查思路：先看 Agent 的推理日志，确认它是基于什么信息生成的这个输出。如果是因为输入信息不足，比如功能描述太简略，那就补充输入信息后重新跑。如果是因为模型对标准的理解有偏差，那就调整提示词或者换一个经过领域微调的模型。

我的经验是，在项目初期花时间把提示词调好，比后期逐条修改输出要高效得多。REANA 的提示词模板是开放的，可以根据团队的标准理解做定制。比如有的团队习惯把安全目标写成“SG-001: 防止...”，有的团队习惯写成“安全目标 1: 防止...”，这些都可以在提示词里指定。

5.2 图谱数据不一致导致追溯断裂

追溯断裂是审核时最致命的问题。常见原因有三个：一是架构变更后没有同步更新图谱，二是 Agent 生成新节点时用了不同的命名，三是人工修改输出后没有回写到图谱。

排查方法：用 REANA 的图谱查询功能，检查每个安全目标是否有 tracesTo 边指向对应的需求节点，每个危害事件是否有 tracesTo 边指向对应的组件节点。如果发现断裂，用reana fix-trace命令尝试自动修复，修复不了的手动补边。

预防措施：架构变更后立即执行reana sync-arch命令同步图谱。Agent 生成新节点时强制使用已有节点的 ID 而不是名称。人工修改输出后必须执行回写命令。

5.3 并行运行时图谱锁冲突

前面提到过，SOTIF 和信息安全 Agent 并行跑时可能出现锁冲突。表现是 Agent 报错“database lock timeout”或者“transaction conflict”。

解决方法：一是加--serial参数改成串行跑，二是调整 Neo4j 的事务隔离级别，三是给每个 Agent 分配独立的图谱副本，跑完后再合并。第三种方法最彻底但最复杂，适合大规模项目。小项目直接用串行跑就行，牺牲一点时间换稳定性。

5.4 模型推理成本过高

安全分析需要大量推理，如果用的模型太大或者推理步数太多，成本会很高。一个中等项目跑完三个 Agent，如果用的通用大模型，API 调用费用可能上百元。

优化方法：一是换用经过领域微调的中等规模模型，效果差不多但成本低很多。二是调整max_reasoning_steps，很多场景不需要 15 步推理，8 到 10 步就够了。三是启用缓存，REANA 支持对相同输入的推理结果做缓存，重复跑的时候直接读缓存不调模型。

5.5 常见问题速查表

6. 从“人建模型”到“Agent 建初稿”的工程体会

这个项目做下来，我最大的体会是：Agent 在安全分析领域的价值不在于替代工程师，而在于把工程师从重复性的建模工作中解放出来。过去做一个项目的 HARA，光是建结构树、填表、维护追溯关系就要花掉整个安全分析工作量的六成以上。现在这部分工作 Agent 能在半小时内生成初稿，工程师只需要花两三个小时审阅和修正。省下来的时间可以用在真正需要工程判断的地方，比如 ASIL 降级的论证、安全机制的选型、以及和供应商的安全需求谈判。

另一个体会是，三安一体的价值在架构变更时体现得最明显。以前架构一改，三份安全分析文档都要手动同步，漏改一处就是审核风险。现在架构变更后，重新跑一遍 Agent，三份分析初稿自动更新，追溯关系自动重建，工程师只需要审阅变更影响的部分。这个效率提升是数量级的。

当然，Agent 建初稿不是万能的。它生成的初稿质量高度依赖输入信息的质量。如果系统架构描述不完整、功能描述太简略、安全相关性标注不准确，Agent 的输出也会打折扣。所以我在项目里一直强调：先把输入信息整理好，再让 Agent 跑。输入信息整理花的时间，会在审阅 Agent 输出时省回来。

最后分享一个小技巧：REANA 的 Agent 支持“示例学习”。你可以在项目里放几个已经人工审核通过的安全分析案例，Agent 在生成新分析时会参考这些案例的风格和判断逻辑。这个功能在团队有历史项目积累的情况下特别有用，能让 Agent 的输出更快贴合团队的工程习惯。我试过在一个有五个历史项目的团队里启用这个功能，Agent 生成的 HARA 初稿一次性通过率从六成提升到了八成以上。