一家功能安全咨询公司卖AI Agent听起来像什么像一群天天把“证据”“可追溯”“评审证据链”挂在嘴边的人突然开始兜售最不稳定的东西。我一开始也觉得这多半是蹭热度功能安全靠的是对标准条文的抠字眼、对失效场景的穷举、对证据链的死磕这些东西跟AI Agent能有什么关系但真的把一个Agent放到客户现场跑了一轮之后我的看法变了。这篇文章不聊大模型有多聪明聊的是我们怎么把功能安全这个“最保守”的咨询行当拆成可以让Agent干活的具体环节再把它作为产品卖出去。中间有五个已经落地的Agent场景有从人天计价转向订阅结果付费的定价纠偏也有一个上线前差点让我们翻车的权限问题。适合正在犹豫要不要做AI产品的咨询公司朋友也适合在功能安全圈子里被文档折磨的工程师。1. 咨询行业的老底子为什么容得下Agent——三个死结与一个转机1.1 按人天卖脑力的模式已经摸到天花板功能安全咨询公司表面上卖的是文档实际上卖的是风险判断能力。但风险判断能力的载体是几千个小时的专家经验而专家的经验没法像货架上的商品一样复制到下一个项目。这个行当常年处在“项目多了人不够人多了项目又没那么多”的周期循环里。人天报价的天花板算一算就清楚了一个资深顾问一年能交付的人天就那么多出差在路上占掉两成剩下的时间还要开会、评审、改文档。产能上限不是管理问题是数学问题。更要命的是知识封装。我们每个顾问脑子里都装着一堆“当年那个项目”的经验某个控制器在极端温度下做过什么处理、某个客户在HARA评分上会卡哪个条款、某个评审专家喜欢追问哪类安全目标。这些经验从来没有被结构化成公司资产。人走了经验就跟着走了。新人培养周期又长看懂标准容易看懂客户怎么在标准面前打折扣难。第三个死结是质量波动。同一个FMEA表格A顾问填得干净利落B顾问填得拖泥带水同一个差距分析今天用的判断标准和三个月前的版本就有出入。客户可能不会直接抱怨但评审会上被开不符合项的时候低质量文档的成本会加倍返还。这三个死结叠加在一起让我们不得不认真想一件事能不能把一部分“文档苦力”交给软件把人腾出来做真正需要判断力的工作1.2 功能安全偏偏是文档密集、规则透明的行业我见过太多咨询团队做AI产品最后都死在同一个地方拿不出来一条完整的证据链。功能安全客户不会因为你用了大模型就买账他只会问一句——你的结论依据的是标准哪一条但功能安全这个行业有个特点跟很多软件咨询不一样它的流程文档极度结构化。虽然产品千差万别但HARA、FMEA、安全需求、追溯矩阵每一类文档都有固定的模板和填写规则。这就像一个两层的游戏规则是固定的内容因项目而异。AI Agent最适合的就是这种场景——规则由标准定义好了剩下的工作就是根据项目上下文把内容填上去、把不一致挑出来、把证据链补全。举几个具体场景。法规差距分析要求把客户现有流程和标准条款逐条对比这是典型的“条款检索文本对照”。FMEA要把历史失效数据、部件失效模式、现场反馈组织成结构化表格这是典型的“信息检索模板生成”。安全案例要把安全目标、论据、证据串成没有断点的链条这是典型的“逻辑编排证据引用”。这些场景的共性是什么规则清楚、模板固定、重复度高、上下文因项目而异。正好是Agent比较擅长做的事。1.3 为什么是现在三个让我下决定的条件这项技术三年前也存在语音识别和搜索引擎也能做一部分但做不到让我们愿意把它包装成产品去卖。真正让我下定决心的是三个条件同时到位。第一个是语言模型的语义理解能力已经到了能处理“条款号变了但描述语义不变”这种问题的程度。以前做文本对照只能靠关键字匹配条款一旦换了表述方式就断掉现在可以按语义去找“项目开发流程中缺失了安全计划定义”和标准条款之间的对应关系。第二个是私有化检索的成本降到了项目预算能接受的范围。功能安全客户普遍要求数据不出域这意味着不能简单调一个云端接口就完事必须考虑私有化部署。现在一套检索增强方案跑在普通服务器上就能应付几百页文档成本不再是拦路虎。第三个是客户自己变了。越来越多客户内部已经在用数字化工具管需求、管测试、管问题追踪对“AI出草稿、人来复核”的工作模式并不排斥。当然还有一个被很多人忽略的原因功能安全标准很稳定。ISO 26262不会每个月变一次IEC 61508的维护周期更是以年为单位。稳定的标准意味着知识库存量寿命够长不用像做互联网产品那样天天跟着规则变动重写提示词这对踩坑容忍度极低的咨询行业来说非常友好。2. 我们实际在卖的五个Agent每一个都冲着“文档苦力”去2.1 法规差距分析助手结论必须能溯源到条款做法规差距分析的痛苦做过咨询的人都懂。客户拿来几十上百页流程文档说“你帮我们看看离合规还差多少”背后其实是几百条标准和上百份公司文件的交叉比对。传统做法是顾问手动翻阅一边看一边记开着Excel逐条打钩。一个中高复杂度的差距分析两个人做两周做完还要酝酿一份动辄几十页的差距报告。我们的Agent做的事情很直接用户上传现有开发流程文档Agent先按标准条款拆解成检查项再对文档做语义级检索输出差距清单每条差距都带上“现行做法摘要”“标准要求原文”“证据缺口”三部分。关键设计是结论后面必须能回溯到标准条款号和原文段落位置。没有溯源能力的差距分析客户根本不会认随便一个评审专家翻出原文就能把结论推翻。实际跑下来后发现检索不准的问题多半出在客户文档的命名上。某个客户把安全计划写成“SP_V2.1_Final_2023”另一个客户在文件夹深处放了一份“HARA_Final_审核版_终稿”这种命名不规则的文件切割和索引都容易乱。我们后来在知识库里加了目录结构引导让用户上传时先选文档类型再允许Agent解析正文准确率立刻上来了。2.2 FMEA初稿生成器把老师傅脑子里的事故库捞出来FMEA表是功能安全里最让人头大的输出物之一。跨部门的人填出来的表五花八门同一个失效模式设计部门描述角度和质量部门都不一样更浪费的是老工程师在过往项目里处理过的大量失效模式散落在旧Excel、邮件、问题追踪系统里从来没人整理复用。我们的做法不是让Agent凭空生成FMEA而是从脱敏后的历史FMEA库里检索相近部件、相近场景、相近失效模式给出初稿。工程师要做的不是从零填表而是对初稿做判断这条失效模式适用吗严重度S、发生度O、探测度D的评分符合当前项目吗需要补充哪些设计措施某工控设备项目试运行时的数据很有参考价值Agent生成的描述性文字部分工程师采纳率在七成左右但评分部分几乎没有人直接采纳。原因很简单严重度、发生度、探测度要结合具体运行场景和客户的历史失效数据来定不可能靠通用模型猜出来。这个观察让我们明确了产品的边界Agent负责把“从无到有”变成“从有到改”工程师负责所有带判断的决策和评分。客户接受度很高因为没人愿意从空表格开始敲字。2.3 安全案例草稿助手先把证据链骨架搭起来安全案例是所有功能安全交付物里最难组织的一份。它不是写作文而是要把安全目标、论据、证据组织成一条没有断点的链。很多项目经理写安全案例写着写着发现中间缺了一环某个安全需求没有对应的验证记录某个验证记录没有关联到系统设计。回头补文档的滋味体验过的人都懂。我们把安全案例拆成“论据骨架证据填充”两步。Agent按GSN目标结构符号的模式生成论据骨架从项目文档库里检索可用的设计说明、测试报告、评审记录一件件挂到对应位置上。工程师的任务是检查骨架逻辑通不通、证据关联得对不对、缺的证据要补做什么。这里有个非常实用的经验Agent生成的证据关联只能作为线索不能直接进入正式交付物。因为安全案例最终是要被评估机构看的证据链的完整性、一致性、可验证性都有人为责任。我们的产品里做了一个“暂存区”设计Agent找到的所有证据都先放到暂存区工程师逐条确认后才进入正式版。这个设计看着很土但恰恰是最让客户放心的地方。2.4 文档一致性检查员专治评审会上的不符合项在功能安全评审会上被开不符合项的重灾区之一就是文档不一致。同一个安全需求在需求规范里写的是“响应时间小于100ms”到了架构设计文档里变成了“响应时间小于150ms”到了测试报告里又变成了“平均响应时间100ms”。这种问题人工查很费劲因为要在几百页文档里来回翻不查又不行因为评估机构非常喜欢把这种不一致拎出来。我们的Agent做的是术语级和参数级比对。它会提取文档中的需求编号、功能名称、关键性能参数、时间约束跨文档比对同一实体的描述是否一致输出一张不一致清单。每一条都标出“A文档原文位置”和“B文档原文位置”工程师再审一遍确认。有个汽车电子试点项目的数据几百页的文档集人工抽检需要一周Agent半天给出初版报告人再花两天复核。虽然不能完全省掉人但周期的压缩非常明显。比较意外的是这个Agent在售前阶段成了最受欢迎的一个。因为它解决的是“立刻能感知到的检查需求”客户可以在谈判桌上看到一份自动生成的不一致清单比演示什么泛泛的智能问答管用得多。2.5 条款问答与新人陪练当AI客服不如当“搜索优先”的资料员最后一个Agent我们最初是想做成内部培训工具给新人用的后来发现客户那边也要就包装成了产品。功能其实不复杂新人问“ASIL分解到底能不能跨控制器”“HARA里的TTC和FTTI的区别”Agent回答并附上标准条款上下文导师在旁边负责纠正必要的时候补充公司内部的方法论。设计这个Agent时有个很容易踩的坑把它做成AI客服。AI客服的交互是“用户提问系统回答”大家会本能地问“标准第几部分说了什么”系统答对了还要追问“原文在哪一页”。所以我们把交互改成“搜索优先、答案其次、出处兜底”任何回答都以检索结果作为支撑宁可只返回相关段落也不硬生成一段看似正确但找不到依据的结论。这块工作不花哨但对功能安全行业的用户极其受用。3. 到底卖什么模型不是产品证据链才是——技术架构与产品边界3.1 不微调、不炼丹用RAG守住私有知识边界在第一版设计时有人提过要不要微调一个专用模型让它“记住”所有功能安全条款。我们算了一笔账就放弃了标准条文多、细节深微调需要大量高质量语料成本不低而且客户的项目数据是绝对不允许出域的微调模型要么无法用私有数据要么就得在客户环境里反复训练周期和合规风险都不可控。所以整体技术路线走的是RAG加工作流编排把标准条款、模板库、历史项目文档统一脱敏作为基础知识库客户上传自己的流程文档后Agent在检索阶段就只从当前客户的知识库切片里找上下文然后交给语言模型做归纳和生成。这样做的好处是把“知识记忆”的问题拆成了“检索质量”的问题。检索质量是可以被评估、被验证的而记忆是不好验证的。部署模式上我们也做了区分。汽车电子客户对数据出域非常敏感普遍要求私有化部署我们就把整个服务打包成一个镜像放到客户环境里工控设备客户相对能接受云端隔离实例但也会明确要求“训练隔离”和“访问控制”。这个差异不是技术问题而是客户所在行业的监管习惯问题做方案时要在商务阶段就问清楚。3.2 知识库分层比调参更花时间真正花时间的地方不是模型是知识库怎么组织。我们踩了一个多月才把知识库从“一堆PDF堆在一起”变成“分层的检索体系”。现在的结构大致是这样第一层标准条款库包括ISO 26262、IEC 61508等按条款编号和章节标题切块每一条都保留版本号和生效日期。第二层内部方法库包括我们公司自己做项目时的HARA模板、FMEA示例、安全计划框架、评审检查单这些是咨询公司的看家底子。第三层脱敏历史项目库去掉客户名、产品名、具体参数后保留的结构化失效信息和文档片段。第四层客户自有库每个客户的流程文档、阶段产物、评审意见单独隔离只对当前项目开放。切块策略也有讲究。我们最初学通用做法按固定token数量切结果把条款切得支离破碎检索经常断章取义。后来改成按标题层级和条款编号切一个条款就是一个块一个章节超过一定长度就按子标题继续切。检索效果立刻好了一大截。版本管理同样不能省标准如果出新版本旧版本必须在知识库里保留但标注“已废止”否则Agent会混乱。3.3 人必须留在环上Agent出草稿工程师签字功能安全是证据学科这个行业里没有人会允许AI Agent承担安全责任。如果产品话术里写着“AI自动生成安全案例”客户评估机构第一个不答应。所以我们从一开始就把人机分工写死在产品逻辑里Agent产出草稿工程师在系统里做评审评审意见和修改记录作为审计轨迹留档。这套设计在产品界面上的体现就是“草稿态”和“定稿态”两个状态。Agent输出的东西全部在草稿态带着明显的“AI生成未复核”标签工程师逐条确认之后才能转成定稿态此时系统记录确认人、确认时间、修改内容。这里还有个微妙的设计定稿态的文档里不出现“AI生成”标记因为功能安全交付物最终不能存在责任的第三方。这个“人必须留在环上”的原则我们还写进了销售材料的第一页。它既是卖点也是边界卖点是帮客户把重复劳动省掉边界是承担判断责任的一直都是人。同行做类似产品时建议先把这个边界理清楚再去谈合同不然后面扯皮的空间很大。3.4 客户第一次问的永远是数据安全第一次给客户讲Agent产品时对方技术负责人听完并没有追问模型效果而是问了一句“我们的FMEA里带着真实故障代码和测试数据传到你们平台会不会被拿去训练”这个问题基本每一次演示都会被问到。我们的回答分三层。第一层是合同约定训练隔离写进条款客户数据不用于任何模型训练项目结束后按客户要求删除或交付归档。第二层是技术手段私有化部署的客户数据只在客户环境里处理云端隔离实例的客户数据库单独开库、单独备份、访问凭据分项目隔离。第三层是证据展示我们专门准备了一份脱敏演示数据所有现场Demo都用这份数据跑不让客户的真实数据进入演示环境。这里特别提醒一点在功能安全行业做SaaS服务不能拿“别人家都用云”来糊弄客户。客户的合规要求是他们所处的行业决定的不因为你是软件服务商就放宽。4. 从“人天计价”到“订阅结果付费”我们调了三次价格表4.1 按人天卖Agent是自杀式定价咨询公司有个根深蒂固的习惯什么东西都按人天报。顾问一天多少钱乘以预估天数加上差旅费就是报价。这套逻辑放在纯人力交付上没问题但放在Agent产品上非常别扭。原因很简单Agent的边际成本几乎是零。同一个文档一致性检查Agent跑一个项目是这些算力跑一百个项目还是这些算力。如果按人天卖客户会非常困惑为什么你一个软件收得比两个顾问还贵反过来如果按人天折算得很便宜我们自己又会发现卖软件居然卖成了卖人头利润率上不去还要承担接口不稳定、算力波动这些不属于传统咨询的风险。更微妙的是客户的心理预期。按人天报价客户默认你在“出售时间”会盯着你实际投入了多少人、干了多少天按软件订阅报价客户默认你在“出售结果”会盯着你给我产出了什么价值。功能安全客户对结果的敏感度远高于过程与其被追问“这个Agent到底算几天人天”不如直接按结果来定价。计价模式客户视角供应商视角适用场景人天计价买的是顾问时间按小时抠成本产能有上限利润率取决于人头能否复用纯咨询交付不涉及产品化订阅计价买的是一个持续在线的工具按年付费收入稳定但上量慢需要持续投入迭代高频、低单价、人人可用的工具结果计价买的是特定业务产出按交付物付费单价高但验收成本高需要明确质量口径低频、高单价、价值可量化的项目型产品4.2 我们最后用的组合订阅打底、项目制走量、结果付费做尖刀调了三次价格表之后我们定下的结构是三层组合。第一层是基础订阅包含文档一致性检查员和条款问答。这类功能使用频次高、价值清晰按每个项目组或每个账号收年费。客户预算上容易批我们也能获得稳定的现金流来支撑后续迭代。第二层是项目制报价包含法规差距分析和FMEA初稿生成。这类功能跟特定项目绑定按项目发起、按项目收尾用户数不限但限制知识库的文档量和项目数。客户认可度高因为可以拿一个具体项目的预算来试水风险小。第三层是按结果计费主要针对安全案例草稿。这类交付物价值极高验收标准也相对明确按生成的“论据骨架证据关联初版”收费。客户相当于买了一个“加速器”用自己的工程师时间换回更短的项目周期。这个组合比单一订阅或单一项目制都好推进。原因在于它尊重了功能安全客户的采购习惯不是从零接受一个全新工具而是在已有的项目预算里挑一条最轻的路径先试。我们也遇到过客户要求“你干脆全包了给我把这个项目的安全案例做到评审通过”这种需求我们暂时不接因为责任边界太模糊一旦评审出现问题说不清是产品的问题还是咨询交付的问题。4.3 合同谈判中最容易扯皮的三个点第一个是质量定义。客户会要求Agent保证“不出错”这是一个无法承诺的东西。我们改成定量的口径FMEA初稿的描述性文本采纳率不低于百分之多少、文档一致性检查报告的检出项必须逐条可溯源、法规差距分析的每个结论都必须带条款编号。客户能接受这种口径因为功能安全本来就是一个讲究证据和量的领域。第二个是责任边界。合同里必须写清楚Agent输出为辅助材料正式交付物的最终责任由客户指定工程师承担。我们不是想甩锅而是功能安全的行业规矩本来就是“谁签字谁负责”。写进合同反而让客户的合规部门踏实因为这意味着我们没有试图用AI替代责任主体。第三个是数据条款。包括项目结束后多久删除数据、是否可以保留脱敏数据用于质量改进、私有化部署的客户是否有权在项目结束后继续使用系统。我们目前的规则是客户数据默认项目结束后三个月内删除脱敏数据可以用于内部检索质量测试但不得用于任何第三方展示。5. 踩坑实录上线前三天被一个“最简单”的权限问题困住5.1 客户一句话把我们拉回现实整套Agent产品做出来后我们安排了一家客户做上线试点。某资深安全负责人把我们拉进会议室打开系统点了几下问了一句至今让我印象很深的话“为什么我A项目组的账号能在搜索结果里看到B项目组的文件列表”当时我第一反应是权限模块的配置出了问题。因为在功能安全场景里项目间数据隔离是底线中的底线。客户那边两个产品线正好处于竞争关系A项目组和B项目组的FMEA数据互相可见哪怕只是文件名都足以让客户当场终止合作。我们找了一圈权限配置没发现明显错误。菜单显示正常角色设置正常敏感文件在界面列表里看不到但搜索接口确实把不该出现的结果返回出来了。这个现象很像是在某个环节把项目维度弄丢了。5.2 缩小范围界面没问题接口有问题按照排查惯例我们先在测试环境复现再用不同角色的账号做对比。结果发现系统菜单和文档列表权限是正确的A项目组的用户确实访问不了B项目组的文件夹但一旦在全局搜索框里搜一个关键词返回结果就混进了其他项目的文档。问题被锁定在搜索接口。我们换了另一个账号反复测试发现只要搜索关键词包含某些通用词比如“安全”“失效”“电机”返回结果里就会出现跨项目文档。更奇怪的是通过文档列表页访问这些文档接口会拒绝但通过搜索结果的跳转链接访问居然能打开。到这里局面已经很清楚不是权限模块整体失效而是搜索接口在检索时没有带项目隔离条件。5.3 根因项目ID在序列化环节悄悄丢了查代码最终定位到根因。搜索接口的请求体里设计了一个metadata_filter字段用来传递当前用户的项目ID服务端在向量检索时应该把这个字段作为强制过滤条件。前端日志里确实解析到了项目ID但在组装请求体的过程中某个内部工具类在序列化时把没赋值的extra字段覆盖了请求体项目ID在这个环节被悄悄丢掉。服务端拿到的请求里过滤条件为空默认执行全库检索于是跨项目结果就出现了。这是一个典型的“看起来简单但藏得很深”的问题。界面层完全没有报错权限模块的单元测试也通过了因为那些测试用例走的是另一个入口没有覆盖这个搜索入口的参数链路。真正定位时靠的是对比接口日志发送方日志里还有项目ID接收方日志里过滤条件为空中间肯定有一个序列化或者参数装配的环节出了问题。5.4 修复、验证、写进测试用例修复本身不复杂在检索API的服务端强制注入项目级隔离条件不允许调用方决定是否携带过滤参数。也就是说过滤条件不再信任前端传来的值而是由鉴权中间件从当前登录态中解析直接拼进检索语句。这样即使前端某次漏传服务端也会自动补上。改动完成以后我们做了一轮账号矩阵验证A项目组账号、B项目组账号、管理员账号、跨项目临时授权账号分别搜索热门关键词确认互相不可见。同时把这类用例写进了自动化回归测试每周跑一遍。这次之后我们规定所有涉及检索、列表、导出的核心接口必须在请求级别做数据隔离断言任何服务端接口都不能依赖前端的过滤参数。5.5 为什么这个坑在功能安全行业尤其致命在普通软件产品里跨项目搜到别的项目文档算是一个中等严重度的安全漏洞。但在功能安全行业这是可以直接让客户终止合作的信任危机。客户评估机构的审核员对数据隔离极其敏感一份跨项目泄露的FMEA会被解读为“这家供应商连基本的数据边界都管不好怎么能交付安全合规的系统”所以我的建议是做面向功能安全客户的Agent产品第一优先级不是模型效果而是数据边界。演示之前先在真实环境里做权限和隔离的专项测试账号矩阵要覆盖不同角色、不同项目、不同知识库之间的交叉访问。6. 踩过这些坑之后给同行的六条建议6.1 先卖检查类别把生成类当主力检查类Agent的验收标准好定不一致清单准不准、差异报告能不能溯源、检出项有没有漏报。客户可以在半小时内看到效果购买决策也快。生成类Agent的使用效果依赖很多上下文一旦生成结果不够好客户容易觉得“花了钱买了个半成品”。我们的经验是第一单下去用检查类建立信任再推生成类做增值。6.2 每个Agent必须配一个“人肉负责人”功能安全圈子认人不认系统。客户用你的Agent一定会在群里艾特某个人问“这个结果为什么这么出”“能不能调整一下检索口径”。我们必须为每个Agent指定一个外部可见的负责人这个人既懂功能安全业务流程又熟悉产品的工作原理。说到底客户买的不是一个黑盒而是一个“知根知底的服务单元”。6.3 标准条款库要用正版数据源自己转录OCR标准条文看起来省了钱实际上风险很大一是准确率没保证条款号一旦错了一位Agent给出的所有结论都不可信二是标准文本本身涉及著作权和授权问题功能安全客户对这类问题的敏感度不亚于代码合规。我们最后是通过正规授权渠道获得的条款数据源并且逐条校验过版本号。6.4 演示Demo永远用脱敏数据演示时用真实客户数据哪怕只是截图都可能构成泄密。我们的规矩是所有演示环境跑一套固定的虚构数据集数据脱敏到看不出任何真实产品信息。宣传材料里的案例也都改成行业说法例如“某汽车电子客户”“某工控设备客户”不出现可识别的项目特征。6.5 销售话术里禁止出现“替代顾问”这个行业里客户信任的是顾问的专业判断而不是一套软件系统。销售材料里要是写了“AI替代安全顾问”会同时得罪客户内部的安全团队和我们自己的交付团队。我们的话术是“把顾问从文档苦力里解放出来去做更有技术含量的评审和决策”。这不是包装而是Agent产品真实的价值定位。6.6 从单项目试点进不要一上来就推全公司订阅功能安全部门对工具的接受是渐进式的。客户安全负责人不可能在没有充分验证的情况下给全公司买一个Agent订阅。我们现在的推进路径是选一个正在做的项目限定在项目范围内试用跑完一个里程碑拿出量化收益再谈扩大范围。一旦试点项目里出了差池影响的是后面所有商务谈判。最后再分享一个个人体会如果让我重来一次会更早地把“AI负责初稿、人负责判断”这条分工线定在合同里而不是等客户追问的时候再去解释。这个行当不缺技术能力强的人缺的是把知识封装成产品、并让客户放心买走的能力。另外一个小技巧客户上线前先拿一份公开的脱敏文档跑通全流程让客户亲手点一遍“从结论溯源到原文”的按钮这比你讲十页PPT都管用。