1. 功能安全咨询行业为什么开始卖AI Agent
功能安全咨询这个行当，过去十几年一直是典型的“人力密集、知识密集、交付周期长”的生意。一家做ISO 26262、IEC 61508合规咨询的公司，核心资产就是那几位懂HARA、懂FMEA、懂安全案例（Safety Case）撰写的资深工程师。客户拿着一个ECU项目过来，从概念阶段的安全目标定义，到系统阶段的ASIL等级分解，再到软硬件层面的诊断覆盖率论证，整套流程走下来少则三五个月，多则一年半载。咨询公司卖的是人天，工程师的时间就是产能天花板。
但这两年情况在变。主机厂和Tier1的项目节奏越来越快，平台化开发让同一套安全机制要在多个车型上复用，客户不再满足于“你给我一份报告”，而是希望“你把能力沉淀到我这边”。与此同时，大模型和AI Agent的能力边界在快速扩张，尤其是Agent在结构化任务编排、知识检索、文档生成上的表现，让不少功能安全从业者开始琢磨：那些高度依赖标准条款、模板化程度高、但又需要专业判断的环节，能不能交给AI Agent来打辅助？
这就是“功能安全咨询公司卖AI Agent”这个命题的由来。它不是把咨询顾问换成机器人，而是把咨询公司多年积累的方法论、检查清单、标准解读经验，封装成一个能持续运行、可交互、能调用工具的数字助手。客户买的不是一个聊天窗口，而是一个懂ISO 26262、懂FMEA逻辑、能帮你梳理安全需求的“虚拟安全工程师”。
我接触过几家做这块尝试的团队，他们的产品形态差异很大。有的做成了嵌入在需求管理工具里的插件，工程师写安全需求时它自动提示条款依据；有的做成了独立的Web应用，上传一份架构图就能生成初步的FMEA表格；还有的做成了本地部署的Agent，能读取项目里的DBC、ARXML文件，结合安全目标做一致性检查。这些产品的共同点是：底层都依赖大语言模型的理解能力，但真正的价值在于上层那套功能安全领域知识的编排和约束。
适合读这篇内容的人，我大致分三类。第一类是功能安全咨询公司的技术负责人，正在考虑怎么把团队经验产品化；第二类是主机厂或Tier1的功能安全工程师，想了解这类工具到底能帮自己省多少事、边界在哪里；第三类是做AI Agent开发的技术人员，想看看垂直领域Agent在功能安全这个高门槛场景下是怎么落地的。不管你是哪一类，接下来的内容会从设计思路、核心细节、实操过程到踩坑经验，一层层拆开讲。
2. 功能安全AI Agent的整体设计与思路拆解
2.1 为什么不是“微调一个模型”那么简单
很多人第一反应是：功能安全咨询公司有大量历史项目文档、标准解读、检查清单，拿这些数据去微调一个开源模型不就行了？我一开始也这么想过，但实际试下来发现这条路走不通，原因有三个。
第一，功能安全的知识不是静态的。ISO 26262在2018年出了第二版，IEC 61508的修订也在推进，不同主机厂还有自己的企业标准。你今天微调进去的知识，明天可能就因为标准更新或客户要求变化而失效。微调模型的更新成本太高，不适合这种需要频繁迭代知识的场景。
第二，功能安全任务对“可追溯性”要求极高。你让模型生成一条安全需求，工程师必须知道这条需求对应标准哪一条、依据是什么、为什么这么分解。微调模型给出的答案是一个黑盒，你没法追溯它的推理路径。而Agent架构可以把“检索标准条款”和“生成需求文本”拆成两个步骤，中间结果可查、可审。
第三，功能安全任务往往需要调用外部工具。比如读取需求管理系统的数据、解析架构文件、运行FMEA表格的校验脚本。这些操作不是纯文本生成能搞定的，必须让Agent具备工具调用能力。
所以，正确的思路不是“微调一个功能安全大模型”，而是“构建一个以通用大模型为推理引擎、以功能安全知识库为约束、以工具集为手脚的Agent系统”。大模型负责理解和生成，知识库负责提供依据，工具负责执行具体操作，三者缺一不可。
2.2 Agent的核心组成：从Prompt到Skill再到Memory
一个功能安全AI Agent的骨架，我习惯用四层来拆：Prompt层、Skill层、Memory层、Tool层。这四层对应热搜词里提到的“ai agent skill memory mcp”和“prompt和skill”的关系。
Prompt层是Agent的“角色设定”和“行为准则”。功能安全Agent的System Prompt不能只是“你是一个功能安全专家”，而要写清楚：你遵循ISO 26262和IEC 61508的术语体系；你在生成安全需求时必须标注ASIL等级；你在做FMEA分析时必须区分严重度、暴露率、可控性三个维度；你遇到不确定的条款时必须明确说“需要人工确认”而不是编造。这些约束看起来琐碎，但正是它们让Agent的输出从“看起来像”变成“真的能用”。
Skill层是Agent的“专业技能包”。一个功能安全咨询公司可能同时做HARA、FMEA、FMEDA、安全案例、网络安全（ISO 21434）等多个业务，每个业务都有独立的流程和模板。Skill层就是把这些流程封装成可复用的模块。比如“HARA Skill”负责接收整车功能描述，输出危害事件列表、严重度/暴露率/可控性评分、ASIL等级；“FMEA Skill”负责接收系统架构和失效模式清单，输出FMEA表格。每个Skill内部有自己的Prompt模板和输出格式约束。
Memory层是Agent的“项目记忆”。功能安全项目周期长，Agent需要记住这个项目的安全目标是什么、已经识别了哪些危害、当前处于哪个开发阶段。没有Memory的Agent每次对话都是“失忆”的，工程师得反复交代背景，体验很差。Memory的实现方式可以是向量数据库加结构化存储，把项目文档、历史对话、已确认的决策都存进去，Agent在需要时检索。
Tool层是Agent的“手脚”。功能安全场景下常用的工具包括：标准条款检索工具、需求管理系统API、架构文件解析器、FMEA表格校验脚本、文档导出工具。Tool层让Agent从“只会说”变成“能做事”。比如工程师说“帮我把这条安全需求同步到Polarion”，Agent调用需求管理系统的API就能完成，不需要人工复制粘贴。
2.3 为什么选择Agent架构而不是传统规则引擎
有人会问：功能安全咨询公司过去用Excel模板、检查清单、规则脚本也能干活，为什么非要上AI Agent？我的观察是，传统规则引擎擅长处理“如果A则B”的确定性逻辑，但功能安全工作中大量环节是“半结构化”的。比如从一段自然语言描述的系统功能中提取危害事件，规则引擎很难覆盖所有表达方式，而大模型的理解能力可以。再比如安全案例的论证逻辑，不同项目、不同客户的要求差异很大，规则引擎需要写大量分支，而Agent可以通过Prompt和知识库的组合灵活应对。
当然，Agent不是万能的。对于ASIL等级分解这种有严格数学逻辑的环节，规则引擎反而更可靠。所以实际产品设计里，往往是Agent和规则引擎混合使用：Agent负责理解、生成、编排，规则引擎负责校验、计算、一致性检查。这个混合架构是功能安全AI Agent落地的一个关键设计决策。
3. 核心细节解析与实操要点
3.1 System Prompt怎么写才能让Agent“懂规矩”
功能安全Agent的System Prompt是整个系统里最需要打磨的部分。我见过一些团队直接把“你是一个功能安全专家”扔给模型，结果Agent生成的回答里ASIL等级乱标、标准条款张冠李戴。下面是我总结的一个System Prompt骨架，你可以直接参考：
你是一个功能安全AI助手，服务于ISO 26262和IEC 61508合规项目。 行为准则： 1. 所有安全需求必须标注ASIL等级（A/B/C/D）或SIL等级（1/2/3/4）。 2. 引用标准条款时必须给出具体章节号，如“ISO 26262-3:2018 第6.4.2条”。 3. 当信息不足以做出判断时，明确输出“需要人工确认”，并列出缺失信息。 4. 禁止编造标准条款或ASIL等级，不确定时优先检索知识库。 5. 输出FMEA表格时，必须包含严重度(S)、暴露率(E)、可控性(C)三列。 6. 涉及安全目标分解时，必须说明分解依据（如“基于ASIL分解规则，D级可分解为C(D)+A(D)”）。 术语规范： - 使用“危害事件”而非“危险情况” - 使用“安全目标”而非“安全要求” - 使用“功能安全概念”而非“安全方案”这个Prompt的关键在于“可验证”。每一条准则都对应一个可检查的输出特征。比如第1条，工程师拿到输出后一眼就能看出ASIL等级有没有标；第3条，Agent说“需要人工确认”比它编一个答案要安全得多。实际使用中，我建议把System Prompt当成代码来管理，每次修改都记录版本和变更原因，因为Prompt的微小改动可能导致输出风格大幅变化。
3.2 知识库构建：标准条款怎么切、怎么存、怎么检索
功能安全知识库的核心是标准条款。ISO 26262有12个部分，IEC 61508有7个部分，加上各主机厂的企业标准，文档量很大。构建知识库的第一步是切分。我的经验是按“条款”切，而不是按“页”或“段落”切。每个条款是一个独立的检索单元，包含条款号、条款标题、条款正文、适用阶段、相关ASIL等级。
切分之后是存储。向量数据库适合语义检索，但功能安全场景下精确匹配同样重要。工程师可能直接搜“ISO 26262-5 第8.4.2条”，这种查询用向量检索反而不如关键词检索准。所以实际方案里，我建议用“向量检索+关键词检索”的混合模式，向量负责语义相似，关键词负责精确命中。
检索环节有一个容易忽略的点：条款的“上下文”。单独一条“诊断覆盖率应达到90%”没有意义，必须知道它适用于哪个ASIL等级、哪个硬件组件类型。所以知识库里每个条款要带上元数据标签，检索时根据当前项目上下文过滤。比如当前项目是ASIL D的电机控制器，检索时就优先返回ASIL D相关的条款。
3.3 Skill开发：以FMEA Skill为例拆解
FMEA是功能安全咨询里最标准化的交付物之一，也是最适合做成Skill的环节。一个FMEA Skill的输入通常包括：系统架构描述、组件清单、每个组件的功能描述、已知的失效模式。输出是一张FMEA表格，包含失效模式、失效影响、严重度、失效原因、预防措施、探测措施、建议措施等列。
Skill内部的Prompt模板大致长这样：
基于以下系统架构和组件信息，生成FMEA表格。 系统架构： {architecture_description} 组件清单： {component_list} 要求： 1. 每个组件至少识别3种失效模式。 2. 严重度评分参考ISO 26262-5附录C。 3. 失效影响需区分“对组件自身”和“对系统功能”。 4. 预防措施和探测措施需具体可执行，避免“加强设计”这类空话。 5. 输出格式为Markdown表格。这里的关键是“约束要具体”。“至少3种失效模式”比“尽可能多”可执行；“参考附录C”比“合理评分”可追溯；“避免空话”比“措施要有效”更容易检查。实际使用中，Agent生成的FMEA表格通常需要工程师做一轮审核和补充，但能省掉从零开始填表的时间，尤其是失效模式和失效原因的初稿生成。
3.4 Memory设计：让Agent记住项目上下文
功能安全项目的Memory需求和其他场景不太一样。它不是简单的“记住用户偏好”，而是“记住项目状态”。一个项目从概念阶段到产品发布，Agent需要记住：当前处于哪个阶段、安全目标是什么、已识别的危害事件有哪些、已分配的安全需求有哪些、哪些决策已经过评审确认。
我的做法是把Memory分成两层：短期Memory和长期Memory。短期Memory存当前会话的上下文，比如工程师刚才上传了一份架构图、刚才讨论的是哪个组件。长期Memory存项目级的结构化数据，用关系型数据库存安全目标、危害事件、安全需求这些实体，用向量库存项目文档和历史对话。
检索时，Agent先根据当前问题判断需要哪类Memory。如果工程师问“这个项目的安全目标是什么”，Agent直接查关系型数据库；如果工程师问“之前有没有讨论过这个失效模式”，Agent查向量库。这种分层设计比把所有东西都塞进向量库要高效得多。
4. 实操过程与核心环节实现
4.1 从零搭建一个功能安全Agent的最小可行方案
如果你现在就想动手试，我建议从一个最小可行方案开始，不要一上来就搞大而全。下面是我实际跑过的一个搭建流程，用到的工具都是常见且容易获取的。
第一步，选一个支持工具调用的大模型API。国内可用的有DeepSeek、通义千问等，国外有OpenAI、Anthropic。选哪个取决于你的部署要求和预算。如果项目数据敏感，建议选支持本地部署的开源模型，比如Qwen系列。
第二步，搭建知识库。把ISO 26262的PDF文档用解析工具转成文本，按条款切分，存入向量数据库。我常用的是Chroma或Milvus，轻量场景Chroma就够了。切分脚本可以用Python写，核心逻辑是识别“条款号”模式，比如“6.4.2”这样的编号。
第三步，写System Prompt和Skill Prompt。先从一个Skill开始，比如“安全需求生成Skill”。Prompt模板参考上一节的示例，根据实际输出效果迭代调整。
第四步，接入工具。最简单的工具是“标准条款检索”，输入条款号或关键词，返回条款正文。这个工具可以用Python函数实现，Agent通过Function Calling调用。
第五步，测试和迭代。找几个真实的历史项目案例，让Agent跑一遍，对比人工输出和Agent输出的差异。重点看：Agent有没有编造条款、ASIL等级有没有标错、输出格式是否可用。根据测试结果调整Prompt和知识库。
这个最小方案跑通后，再逐步增加Skill、完善Memory、接入更多工具。不要一开始就追求完美，功能安全Agent的价值是在迭代中逐渐体现的。
4.2 参数选择：温度、Top-p、最大Token怎么设
大模型的生成参数对功能安全场景的输出质量影响很大。我实测下来的经验值如下：
| 参数 | 推荐值 | 原因 |
|---|---|---|
| 温度 | 0.1-0.3 | 功能安全需要确定性输出，温度太高会导致同一问题每次答案不同 |
| Top-p | 0.9 | 保持一定的词汇多样性，但不要太高 |
| 最大Token | 4096 | 安全需求、FMEA表格通常较长，需要足够的输出空间 |
| 频率惩罚 | 0.3 | 避免重复表述，但不要太高以免影响术语一致性 |
| 存在惩罚 | 0.1 | 轻微鼓励引入新信息 |
温度这个参数特别关键。我试过温度设0.7，结果同一个安全目标，Agent两次生成的ASIL分解方案不一致，工程师没法用。后来降到0.2，输出稳定多了。当然，温度太低也有问题，Agent会变得“死板”，遇到稍微变化的问题就套用之前的答案。0.1到0.3之间是一个比较平衡的区间。
4.3 一个完整的HARA Skill实操记录
HARA（危害分析与风险评估）是功能安全概念阶段的核心活动。我用一个真实案例来展示Agent是怎么跑这个流程的。
输入是一段整车功能描述：“电子驻车制动系统（EPB）在车速低于5km/h时自动施加驻车制动，驾驶员可通过按钮手动释放。”
Agent的处理流程分四步：
第一步，功能分解。Agent把这段描述拆成“自动施加”“手动释放”“车速判断”三个子功能，并识别出每个子功能的输入输出。
第二步，危害事件识别。Agent针对每个子功能，结合知识库里的危害事件模板，生成候选危害事件。比如“自动施加”对应的危害事件是“非预期施加驻车制动导致车辆突然减速”。
第三步，ASIL评估。Agent根据严重度、暴露率、可控性三个维度打分。严重度参考ISO 26262-3附录B，暴露率参考附录B，可控性参考附录B。Agent给出评分和依据，比如“严重度S2（可能造成轻伤），暴露率E4（高概率暴露），可控性C2（一般可控），ASIL B”。
第四步，输出HARA表格。Agent生成Markdown表格，包含危害事件、严重度、暴露率、可控性、ASIL等级、安全目标。
整个流程跑下来，Agent用了大约40秒，生成了12条危害事件和对应的ASIL等级。人工审核发现，其中9条可以直接用，2条需要调整评分，1条是Agent误判（把“手动释放失效”的严重度评高了）。这个准确率对于初稿来说已经很有价值了，工程师的工作从“从零写”变成“审核和修正”。
4.4 工具调用：让Agent能读文件、查数据库、写文档
功能安全Agent如果只能聊天，价值有限。真正让它“能干活”的是工具调用。我列几个实际项目中常用的工具：
- 文件解析工具：输入DBC、ARXML、PDF、Excel文件，输出结构化文本。Agent可以用这个工具读取架构文件，提取组件清单和信号列表。
- 条款检索工具：输入条款号或关键词，返回标准条款正文和元数据。
- 需求管理工具：对接Polarion、DOORS等系统，支持创建、查询、更新安全需求。
- FMEA校验工具：输入FMEA表格，检查是否有遗漏的失效模式、评分是否合理、措施是否具体。
- 文档导出工具：把Agent生成的表格和文本导出为Word或PDF，套用公司模板。
工具调用的实现方式取决于你用的模型。OpenAI的Function Calling、Anthropic的Tool Use、开源模型的ReAct模式都可以。关键是把每个工具的参数定义清楚，让Agent知道什么时候该调用哪个工具。比如“帮我查一下ISO 26262-5关于诊断覆盖率的要求”，Agent应该调用条款检索工具；“把这个FMEA表格导出成Word”，Agent应该调用文档导出工具。
5. 常见问题与排查技巧实录
5.1 Agent编造标准条款怎么办
这是功能安全Agent最危险的问题。Agent为了“显得专业”，可能会编造一个不存在的条款号，或者把条款内容记混。我踩过这个坑，后来总结了几条应对措施。
第一，在System Prompt里明确禁止编造，并要求Agent在引用条款前先调用检索工具。第二，在输出后加一道校验：用正则表达式提取所有条款号，逐个在知识库里验证是否存在。第三，对于关键输出（如安全目标、ASIL等级），强制要求Agent给出条款依据，没有依据的输出标记为“待确认”。
实测下来，加了检索工具和校验环节后，条款编造率从最初的15%降到了2%以下。剩下的2%通常是条款号正确但内容表述有偏差，需要人工审核。
5.2 Prompt被标记违规或闪退怎么处理
热搜词里出现了“invalid prompt: your prompt was flagged as potentially violating our usage policy”和“+prompt闪退”，说明不少人在使用大模型API时遇到了Prompt被拦截或程序崩溃的问题。功能安全场景下，Prompt里可能包含“失效”“危害”“事故”等词汇，容易被安全策略误判。
我的处理经验是：第一，把敏感词汇做替换或脱敏，比如“事故”改成“非预期事件”，“危害”改成“风险源”。第二，把长Prompt拆成多个短Prompt，分步调用，降低单次请求的触发概率。第三，在代码里加异常捕获和重试机制，遇到API返回违规标记时，自动调整Prompt措辞后重试。第四，如果用的是本地部署模型，这些限制通常不存在，但要注意模型本身的安全对齐程度。
5.3 Agent输出格式不稳定怎么治
功能安全交付物对格式要求严格，FMEA表格的列顺序、安全需求的编号规则、ASIL等级的写法都有固定格式。Agent有时候会“自由发挥”，把表格列顺序打乱，或者把ASIL B写成ASIL-B。
治理格式问题，我的做法是“Prompt约束+后处理校验”双管齐下。Prompt里用明确的格式示例，比如“输出必须严格遵循以下Markdown表格格式：| 失效模式 | 严重度 | 暴露率 | 可控性 | ASIL |”。后处理环节用脚本检查输出是否符合格式，不符合的自动修正或重新生成。
另外，温度参数对格式稳定性影响很大。温度高于0.5时，Agent容易“创新”格式；温度低于0.3时，格式通常很稳定。所以如果格式问题严重，先把温度降下来。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决措施 |
|---|---|---|---|
| Agent编造条款号 | 知识库检索未触发 | 检查Function Calling日志 | 强化Prompt约束，加后处理校验 |
| 输出ASIL等级不一致 | 温度过高 | 对比多次调用结果 | 温度降至0.1-0.3 |
| Prompt被API拦截 | 敏感词汇触发策略 | 查看API返回信息 | 替换敏感词，拆分Prompt |
| Agent“失忆” | Memory未生效 | 检查Memory检索日志 | 完善Memory存储和检索逻辑 |
| 工具调用失败 | 参数格式错误 | 检查工具定义和调用日志 | 修正工具参数Schema |
| 输出格式混乱 | Prompt格式约束不足 | 对比输出和期望格式 | 增加格式示例，加后处理 |
| 响应速度慢 | 知识库检索耗时 | 分析各环节耗时 | 优化检索索引，加缓存 |
| 多轮对话后质量下降 | 上下文过长 | 检查Token用量 | 压缩历史对话，只保留关键信息 |
5.5 独家避坑技巧
第一个技巧：知识库的条款切分不要用固定长度，要用“语义完整性”。我试过按500字切分，结果一条完整的条款被切成两半，检索时只返回半条，Agent理解出错。后来改成按条款号切分，每个条款作为一个完整单元，检索准确率大幅提升。
第二个技巧：Agent的“不确定”输出要保留。有些团队为了让Agent“显得有用”，把“需要人工确认”的输出过滤掉了。这是危险的。功能安全场景下，Agent说“我不确定”比它编一个答案要安全一百倍。保留这些输出，让工程师知道哪些地方需要重点审核。
第三个技巧：用真实项目做回归测试。每次修改Prompt或知识库后，拿3-5个历史项目跑一遍，对比修改前后的输出差异。我见过一个团队改了一句Prompt，结果Agent把所有ASIL D的需求都标成了ASIL C，幸好回归测试发现了。
第四个技巧：Agent的输出要能“一键导出”到公司模板。工程师审核完Agent的输出后，如果还要手动复制粘贴到Word模板里，效率提升就大打折扣。做一个导出工具，把Agent的Markdown输出自动套用公司模板，生成可交付的文档。
6. 功能安全AI Agent的边界与人的角色
6.1 Agent能做什么、不能做什么
跑了这么多项目，我对功能安全AI Agent的能力边界有了比较清晰的认识。它能做的是：标准条款检索和解读、安全需求和FMEA的初稿生成、文档格式转换、一致性检查、历史项目知识复用。它不能做的是：最终的安全决策、ASIL等级的最终确认、安全案例的论证责任、与客户的合规谈判。
这个边界很重要。Agent是“副驾驶”，不是“自动驾驶”。工程师始终是责任主体。我见过一些宣传说“AI全自动完成功能安全认证”，这是不负责任的。功能安全认证的核心是“可追溯的论证过程”和“有资质的人员签字”，Agent可以加速这个过程，但不能替代人的判断和责任。
6.2 咨询公司的商业模式怎么变
功能安全咨询公司卖AI Agent，本质上是在卖“沉淀后的方法论”。过去卖人天，现在卖“人天+工具订阅”。客户买Agent，买的是咨询公司多年积累的检查清单、模板、标准解读经验。这对咨询公司来说，是一个从“项目制”向“产品制”转型的机会。
但这里有个矛盾：咨询公司的核心资产是知识，把知识封装成Agent后，客户会不会“学会”了就不需要咨询了？我的观察是，功能安全咨询的价值不只是知识，还有“判断”和“背书”。Agent能生成FMEA表格，但判断这个表格是否满足认证要求、能否通过审核，还是需要资深工程师。所以Agent更像是咨询公司的“获客工具”和“交付加速器”，而不是“替代品”。
6.3 后续可以扩展的方向
功能安全AI Agent目前主要覆盖ISO 26262和IEC 61508，后续可以往几个方向扩展。一是与网络安全（ISO 21434）的融合，因为功能安全和网络安全在汽车领域越来越密不可分。二是与ASPICE的集成，把安全需求和过程改进结合起来。三是多模态能力，比如直接读取架构图、时序图，从中提取安全相关信息。四是与仿真工具的联动，Agent生成安全需求后，自动生成测试用例并调用仿真环境验证。
我个人在实际操作中的体会是，功能安全AI Agent的落地难点不在技术，而在“信任”。工程师愿不愿意用Agent的输出、敢不敢在项目里用、认证机构认不认，这些问题的解决需要时间。我的建议是，先从“辅助”场景切入，比如条款检索、格式转换、初稿生成，让工程师逐步建立对Agent的信任，再往更核心的环节推进。最后分享一个小技巧：Agent的输出里加上“置信度”标记，高置信度的输出可以直接用，低置信度的标记为“需人工重点审核”，这样工程师的审核效率会高很多。
