功能安全、SOTIF、信息安全，这三个词放在一起已经是汽车电子圈的日常，但真正要求它们“三安一体”地放进同一个建模流程，难度完全不一样。过去大半年，我们团队一直在推这个事，核心抓手是REANA这个智能体平台：让Agent替安全工程师先写初稿，把人从“逐条敲模型”里解放出来，退到审稿位。说实话，一开始我心里打鼓——安全建模这种严谨活，让大模型来干，会不会把HARA做成事故报告？好几个迭代跑下来，我的结论是：真正的问题不在“Agent能不能干”，而在“流程边界怎么定、人工确认门放哪里、标准条款怎么让它引用而不是瞎编”。
这篇文章就把我们的方案、踩过的坑、以及测得的数据一次性写透，给正在做三安融合或者准备引入Agent辅助安全分析的团队一份参考。
1. 功能安全、SOTIF、信息安全为什么必须放进同一个建模流程
1.1 一个AEB场景，三种标准在抢同一辆车
先看一个典型的自动紧急制动（AEB）场景。车辆在城市道路行驶，毫米波雷达和摄像头融合识别前方行人，系统决定是否触发制动。按照传统做法，这里会拆成三份完全独立的分析工作：
- 功能安全团队问：雷达内部故障、摄像头图像信号异常、制动执行器卡滞，这些失效会不会导致危害？他们用HARA做危害分析与风险评估，输出安全目标，定ASIL等级。
- SOTIF团队问：雷达在雨天对行人反射截面变小、摄像头在逆光下识别置信度下降、系统在从未训练过的交通场景里出现功能不足，这些“不是故障但能力不够”的情况怎么办？他们用触发条件分析和场景评估来定预期功能安全的可接受准则。
- 信息安全团队问：攻击者能不能通过OTA升级包篡改AEB标定参数、通过车载蓝牙入口注入虚假制动指令、通过伪造传感器数据让AEB误触发？他们用TARA做威胁分析与风险评估，输出网络安全目标。
这三份分析从前到后讲的是同一辆车、同一个AEB系统，却是三拨人、三套流程、三种文档格式。功能安全工程师不知道SOTIF那边已经识别出逆光场景需要升级摄像头需求；信息安全团队把“篡改传感器数据”写成网络安全目标，而功能安全团队的另一版需求里压根没有对传感器通信做完整性校验的表述。更麻烦的是，评审会上三份文档放在一起，连“危害”“威胁”“触发条件”这几个词指什么都要先争论半小时。
三安一体的必要性从来不是某个标准要求的，而是现实逼出来的：平台化车型、软件定义汽车、SOA架构，让功能、预期功能和网络安全三个维度在同一个中央计算单元上深度耦合。AEB制动请求的传输链路，既是功能安全的失效路径，也是信息安全的攻击面，还是SOTIF算法能力不足时的补偿需求。这三个维度必须在同一个风险视图里对齐，否则任何一辆量产车都可能存在“三拨人都没看出来”的安全盲区。
1.2 人工建模的三处断点：文档孤岛、追溯断裂、精力错配
“三安一体”的理想很清晰，但落到“人建模型”的现实中，会撞上三堵墙。
第一堵墙是文档孤岛。HARA表、SOTIF触发条件清单、TARA报告，分别在不同团队手里，用不同工具维护。同一个“前向感知系统”，在功能安全文档里叫“FWD_PERCEPTION”，在SOTIF场景库里叫“front_camera_module”，在TARA资产清单里又叫“CAM_01”。Agent想把它们联起来做一致性分析，光是实体对齐就够喝一壶。
第二堵墙是追溯链断裂。功能安全要求从安全目标追溯安全需求，SOTIF要求从可接受准则追溯到验证场景，信息安全要求从网络安全目标追溯到攻击路径。三条追溯链各自闭合，但互相之间没有映射。当供应商更新了一个传感器方案，功能安全团队改了ASIL等级，SOTIF团队却不知道识别能力边界要跟着改，信息安全团队也不知道新传感器引入的新攻击面。变更影响分析全靠会议找人，漏是必然的。
第三堵墙是精力错配。HARA要枚举运行场景、TARA要清点攻击入口、SOTIF要梳理触发条件，这些动作里有大量“铺开枚举、逐条筛选”的低价值重复劳动。真正的安全专家稀缺且昂贵，他们的时间应该花在判断“风险可不可接受”“需求是否完整”上，而不是把同样格式的表格填写第二十遍。我们把这类劳动统称为“打字员工作”——模型越复杂，打字员工作量越爆炸。
这三堵墙叠加之后，再回头看“Agent建初稿”这件事，就有很明确的动因：不是赶AI时髦，而是让人从枚举性劳动里抽身，把精力放到真正需要经验判断的位置。
2. REANA的智能体底座：Harness、Skill与知识库如何分工
2.1 REANA不是文档系统，而是安全分析工作流引擎
REANA在我们项目里不是一个被动的知识问答工具，也不是又一个文档管理平台。它被定义成一个“安全分析工作流引擎”：输入是项目上下文、系统架构描述、场景描述和安全标准范围；输出是带证据链的HARA初稿、SOTIF分析初稿、TARA初稿，以及三安合一的追溯矩阵。它要做的是把“安全分析这件事”工程化、半自动化，而不是把标准条款变成聊天记录。
在这个定位下，REANA的架构可以拆成四层。最底层是安全知识库，存标准条文、公司模板、历史项目审查意见和供应商失效数据；第二层是Agent技能层，每一类安全分析动作对应一个独立Skill；第三层是编排层，由一个协调者Agent负责任务拆解、上下文传递和结果汇总；最上层是人工审校台，安全工程师在这里看初稿、打回、改判、批注。四层之间通过明确定义的接口通信，所有步骤都有trace日志，方便后续审计和认证支持。
为什么强调“工作流引擎”而非“AI工具”？因为安全分析的结果最终要进到ISO 26262 / ISO 21448 / ISO 21434的评审流程里，评审方要看到的是“这个过程是否受控、是否有证据”。一个纯聊天框式的AI工具再聪明也无法满足这一点。REANA把每一个Agent动作都变成工作流节点，每个节点绑定标准条件和产出物，这样生成初稿的整个过程就是可复现、可审查的。这是它跟市面上大多数“AI助手”的本质区别。
2.2 Skill是“经验包”，Harness是“运行壳”
做Agent开发的人应该对热搜里的“Skill”“Harness”这些概念不陌生。REANA把安全分析能力按Skill划分，而Harness负责把Skill安全地跑起来。
我举个具体例子。HARA分析这个Skill内部包含：场景要素抽取、危害事件枚举、S/E/C参数估计、ASIL等级建议、安全目标生成。这些步骤串成一个流水线，每个步骤都会调用知识库里面的标准条款。比如“S”的严重度分级参考ISO 26262-3附录B提供的伤害类型表格，“E”的暴露度参考中国交通事故深入调查报告数据，这些数据不在大模型脑子里，而是存在知识库里由Skill按需检索。
Harness则是运行环境，负责管理Agent调用的生命周期：LLM输出超时怎么办、工具调用失败怎么重试、多个Agent并行时资源怎么调度、输出内容需要经过哪些校验规则才能放行。这里有一个特别重要的点：Harness里可以预设“禁止无引用输出”之类的硬规则。大模型生成的每一条危害事件，都必须携带支持其判断的标准条款编号或项目数据出处，没有引用，这条结论就不会被写到初稿里。这个机制是我们后来发现所有质量问题的关键解药。
Skill和Harness分离带来一个直接好处：安全专家的经验可以沉淀成可复用的能力包，而不会跟某个具体Prompt绑定。新项目进来，不需要针对每个车型重新调Prompt，只需要更新知识库里的传感器失效数据、架构描述和场景库，让原有Skill在新上下文里跑一遍。对我们这种同时并行多个车型项目的团队来说，可复用性比单次效果重要得多。
2.3 为什么用多Agent而不是一个大模型全程代劳
设计REANA时，我们内部讨论过一个问题：直接用一个大模型，把HARA/SOTIF/TARA都塞进一次长对话里，行不行？实验做下来，答案是不行。
原因是三套分析的思维模式差异很大。HARA基于“失效—危害”的因果链，沿着系统功能找故障模式；SOTIF基于“功能不足—触发条件—风险场景”的能力边界分析，关注的是在ODD之外的“不知道不知道”的领域；TARA则基于“资产—威胁—攻击路径—损害场景”的对抗式思维，要模拟攻击者视角。三者共享一部分系统描述，但推理路径和输出粒度和规范完全不同。让一个大模型同时处理三种任务，结果往往是术语漂移、输出格式互相掺杂，HARA的安全目标里混进TARA的攻击树描述。
REANA的解法是三个专职Agent各干一摊，由协调者Agent做任务拆解和结果汇总。协调者拿到一个场景描述后，把它拆成三份带明确上下文的子任务，分发给HARA Agent、SOTIF Agent和TARA Agent。三个Agent各自独立输出后，协调者再做实体对齐和冲突标记。这样每一条分析路径都清晰可控，出了问题可以直接定位到某个Agent的某次推理，而不是在一锅粥里捞证据。
多Agent的代价是更长的运行时间和更复杂的调试，但换来的是结构化、可审计、可单点改进。安全工程最怕“黑盒”，多Agent架构恰好给了我们一个相对白盒的过程控制单元。
| 维度 | HARA Agent | SOTIF Agent | TARA Agent |
|---|---|---|---|
| 对应标准 | ISO 26262 | ISO 21448 | ISO/SAE 21434 |
| 输入重点 | 系统功能清单、失效模式、运行场景 | 功能定义、能力边界、ODD、用户行为 | 资产清单、通信接口、威胁入口 |
| 分析活动 | 危害事件枚举、S/E/C评估、ASIL分级 | 功能不足识别、触发条件分析、风险场景评估 | 损害场景/威胁场景枚举、攻击路径分析、风险评估 |
| 核心产出 | 安全目标、功能安全需求初稿 | SOTIF相关项、可接受准则、验证场景建议 | 网络安全目标、网络安全需求初稿 |
表格里的划分看起来简单，实际做起来最大的挑战是让三个Agent共享同一套系统边界描述，同时各自用不同的分析视角去拆解。这部分我们经历了三轮迭代才收敛，细节在下一章展开。
3. Agent建初稿的工作流拆解：从一段场景描述到三安需求包
3.1 先把“人话场景”转成可枚举的“场景要素表”
REANA处理的第一步不是直接让Agent分析雷达失效还是攻击者入侵，而是先把项目组给的一段“人话场景”转成结构化场景要素表。我们项目里习惯用一段自然语言描述新功能，比如：“车辆在雨天城市快速路行驶，自适应巡航开启，目标车辆从左侧车道切入本车前方，系统应平稳制动保持安全距离。”
这段描述直接扔给大模型，它的确能生成看起来合理的分析，但质量不稳定。后来我们设计了一个“场景要素模板”，要求Agent在进入HARA/SOTIF/TARA之前，先抽取以下要素：
- 运行场景：城市快速路、雨天、夜间、交通密度中高
- 系统功能：自适应巡航、自动纵向控制
- 外部参与者：目标车辆、行人、交通标志
- 系统状态：巡航激活、目标切入、本车车速
- ODD条件：车道标线可见、雨量中等、传感器视野受限
- 潜在失效/能力边界：雷达对切入车辆感知延迟、摄像头在雨夜性能下降
- 信息交互接口：V2X、OTA、诊断接口（供TARA清点资产）
这个结构化过程很重要，因为它决定了后续三个Agent的枚举边界。场景要素表如果漏了“雨天”，SOTIF Agent就不会去分析摄像头在雨天的感知衰减；如果漏了“OTA接口”，TARA Agent就会漏掉远程刷写攻击面。场景要素抽取的完整度，直接决定初稿覆盖度。因此我们把这个步骤设计成“Agent生成初稿 + 人工补充确认”的混合模式：Agent先抽要素，工程师在界面上一项一项核对，确认后再放行后续分析。
这里有一个非常实用的经验：不要让Agent直接分析原始需求文档全文。先让它做结构化抽取，哪怕抽出来的表不够全，人工补起来也远比在长文档里找遗漏场景快。我们后来所有项目的入口都统一收敛到这张场景要素表上，三安分析的质量一下子就稳了。
3.2 HARA/SOTIF/TARA三线并行：同一份输入，三种初稿
场景要素表确认后，协调者Agent会把它分发给三个专业Agent，三线并行开始建初稿。
HARA Agent做的是：枚举每个系统功能在失效情况下可能导致的整车级危害事件，估算Severity、Exposure、Controllability，给出ASIL等级建议，再导出安全目标初稿。它的推理链路是“失效模式—危害事件—安全目标”。比如对“目标切入”场景，它枚举出“雷达感知失效导致AEB不触发，车辆与切入车辆发生追尾”，对照ISO 26262-3的伤害类型，S=3（生命危险）、E=4（高暴露）、C=3（难以控制），建议ASIL C，生成安全目标“系统应确保在目标切入场景下AEB能在规定距离内触发”。每个“失效模式”和“安全目标”都带引用来源。
SOTIF Agent做的则是：从场景要素表里找出传感器能力和算法局限，枚举触发条件，再评估这些触发条件在真实使用场景中的风险是否可接受。针对同一段输入，它会写道：“雨天环境中，前向摄像头检测距离下降，可能导致对切入车辆的识别延迟；该触发条件下若AEB触发距离不足，则可能造成碰撞风险；建议补充验证场景：雨天夜间城市快速路目标切入测试矩阵。”它的输出不是“功能失效”，而是“设计能力不足带来的预期功能风险”。
TARA Agent做的是：从系统架构和场景要素里提取资产，枚举损害场景和威胁场景，分析攻击路径可行性，输出网络安全目标。它会关注到该车具备OTA能力，攻击者可能通过远程方式篡改AEB标定参数；也会关注到传感器通信总线可以被物理接入，存在伪造雷达数据的可能性。它输出的网络安全目标初稿是“应确保AEB相关控制参数在存储和传输过程中的完整性，并具备防回滚机制”。
三份初稿同时生成，看的不是单一视角，而是三套标准如何在同一个场景里交叉验证。尤其重要的是，每份初稿都被标记为“draft”状态，等待人工确认，而不是直接作为正式安全基线进入追溯矩阵。
3.3 冲突消解与需求追溯：Agent合并三安视图的关键一环
三个Agent单独写初稿只是第一步，真正体现“三安一体”价值的是合并环节。协调者Agent会把三份初稿放到同一个“安全需求工作区”里，做实体对齐和冲突标记。
最常见的冲突是需求完整性问题。HARA Agent只考虑雷达硬件失效，SOTIF Agent识别出摄像头逆光能力不足，TARA Agent发现传感器通信链路可被篡改。单独看每一份初稿都合理，但合并后会发现：安全目标要求“AEB应检测到前方行人”，这里的“检测到”在功能安全语境里默认是传感器正常工作的前提下，而SOTIF要求在逆光下也能检测，TARA要求检测结果不可被伪造。三个约束合并后，才真正形成一条完整的需求：“系统应在包括逆光、雨天的目标ODD内，对行人实现可靠检测，且传感器输入应具备防篡改机制，检测结果的置信度计算应抵抗恶意数据注入。”
这种合并动作如果靠人工做，需要同时熟悉三套标准，且要逐条对比，非常费神。协调者Agent先把三份初稿按“功能标签”对齐，然后把矛盾和不完整项标记出来，最后生成一张“三安需求追溯矩阵”。矩阵的行是危害事件/触发条件/威胁场景，列是安全需求、对应标准、验证建议。ISO 26262的HARA结论、ISO 21448的SOTIF相关项、ISO 21434的TARA结论，在矩阵里每一位都有对应关系。
这一张矩阵就是三安一体的核心交付物，也是REANA相对“三个独立AI助手”的最大差异：它不只是三份文档的并集，而是通过实体对齐和冲突消解，生成一个统一的、可追溯的安全需求集。评审会上不再需要三拨人各带一张Excel表争论，直接看矩阵就能定位每一个需求的前因后果。
4. 落地REANA最容易翻车的四个地方，以及我们的补救办法
4.1 坑一：Agent在“背诵”标准，而不是“引用”标准
第一次跑通REANA时，我们发现一个严重问题：HARA Agent输出的安全目标看起来非常专业，但追问来源时，它给的标准条款编号是错的。比如把ISO 21448的功能不足概念写进了ISO 26262的危害事件枚举里，引用条款看起来有模有样，实际对应关系是错的。这就是典型的大模型“背诵式输出”——它记住了条款的大致内容，但不知道边界在哪里。
补救办法有两个。第一，强制“引用即证据”规则：在Harness层写死校验逻辑，Agent输出结论时，每个条目必须携带知识库中检索到的条款ID和数据来源，否则该条目不进初稿。第二，知识库里的标准条文要做“段落级切分+索引”，不能只塞整篇PDF。我们把ISO 26262、ISO 21448、ISO 21434都切成了条款级别的文本块，并保留标准里的示例、注释和附录信息。这样Agent检索到的不是整章内容，而是精准到某一条。
改完之后，Agent的输出风格发生了明显变化：每条结论后面都挂了一串引用ID，人工核对时直接点开就能看到标准原文。这不仅减少了瞎编，还大大加速了评审——相当于Agent帮我们把“对齐标准要求”这件事提前做完了。
4.2 坑二：人工确认门放错位置，审核变成体力活
早期我们设计了“一个提交按钮审批所有Agent输出”的流程，结果工程师每天要花两小时批量点确认，基本没有仔细看内容。我们发现这个设计是彻底的失败：确认门的价值不在于“让工程师给Agent放行”，而在于让工程师在关键判断点上贡献专业知识。
后来我们把确认门细化到三个位置。第一是场景要素表确认，工程师确保系统边界和场景描述无遗漏；第二是风险等级判断确认，ASIL等级、SOTIF可接受准则、TARA风险等级这三类关键分级值必须由工程师确认，Agent只能给出建议；第三是安全需求集成的最终复核，工程师检查追溯矩阵是否覆盖已知的历史问题清单，是否与架构约束冲突。
这样调整后，工程师不再需要逐条审核几百个枚举项，只需要聚焦在“这个等级定得合不合理”“这条需求放到当前架构里是否可实现”这种真正需要专业判断的问题上。一次迭代下来，人工审校时间从原来的每人每天四小时降到一个小时，而且质量更高。
4.3 坑三：三套术语体系在模型里互相污染
术语污染是最隐蔽的坑。HARA里的“危害(Hazard)”、SOTIF里的“触发条件(Trigger Condition)”、TARA里的“威胁场景(Threat Scenario)”，在自然语言里都指向“出事的可能”，但它们在标准里的定义和边界完全不同。Agent在生成长文本时，经常会把“触发条件”误写成“威胁场景”，或者把“危害事件”和“损害场景”混用。这种问题在单次生成里不明显，但在追溯矩阵里会引发灾难性的歧义。
我们做了三件事来根治。一是在知识库里维护一套“术语本体映射表”，明确三套标准之间哪些概念是近义、哪些是包含关系、哪些是完全不同层级。二是给每个Agent的Skill都加了一段前置指令，在输出前先对待用术语做定义声明，比如HARA Agent在枚举时必须用ISO 26262中“harm event”的定义，禁用“threat scenario”。三是在协调者Agent的合并环节增加“术语一致性校验”工具，自动检查初稿中出现的术语是否归位到正确标准域。
这三板斧砸下去之后，追溯矩阵里的交叉引用才真正整齐。我们后来把这个术语映射表当作知识库的一部分在多个项目中复用，效果非常稳定。
4.4 坑四：把原始安全文档直接喂给公共大模型
这一点我不太想批判，因为实在太基础，但确实是团队里真实发生过的事。有同事为了快速跑通Demo，把整份HARA分析报告直接粘贴到公共大模型网页里，问模型“有没有遗漏的危害”。这在我们汽车电子行业是绝对的红线——未发布车型的电子电气架构、供应商失效模式数据、内部审查意见，这些都属于公司核心机密。
我们的补救方案是把REANA做成了纯私有化部署的链路：LLM推理走企业内部网关，可选用开源模型或企业私有化模型服务；知识库用内网向量检索服务；所有Agent的调用日志都保存在项目内部存储里。考虑到安全项目对性能和稳定性的敏感度，我们当时还专门测了不同规模的模型。结论是：初稿生成这类任务，7B~14B的中小模型在本地跑已经能给出不错的结构化输出；但对于需要综合三份初稿做冲突消解的协调者任务，模型参数量还是大一点更稳。
如果团队资源受限，我建议至少做到“敏感文档不出内网”，宁可在企业内部部署一个小模型跑初稿，再安排人工复核，也不能为了一点生成质量把核心资产暴露在外部API里。安全合规团队在这个问题上拥有一票否决权，项目启动前最好就让他们介入。
5. 试点效果复盘：Agent初稿的可用度、漏项与仍然必须人建的环节
5.1 试点选型：一个中等复杂度的智驾域控制器
为了验证这套方案到底行不行，我们选了一个中等复杂度的智驾域控制器项目做试点。这个项目负责高速NOA领航辅助，包含感知、决策、执行三个层面的功能，三套标准都要过，而且团队里已经有历史项目的安全文档可作参考，大概积累了四十多份HARA、SOTIF和TARA模板。这个复杂度既不像简单控制器那样看不出差距，也不会像全栈自动驾驶那样把整个方案拖垮，很适合做第一次测量。
试点评估的方法是对比实验：两位资深安全工程师按传统人工方式建立一版安全基线和追溯矩阵，同一时间另一位工程师用REANA生成一版初稿，再组织项目组专家对两版结果做盲审。盲审重点看三类指标：场景覆盖度、安全需求完整度、追溯链完整度。
5.2 我们看到的效率变化和质量分布
先看时间账。人工建初版HARA表和SOTIF触发条件清单，并跟TARA团队对齐，按我们的历史速度大概要两到三周。REANA第一条初稿当天就能跑出来，但那份初稿只能算“毛坯房”，经过三轮人工反馈迭代之后，才收敛到可进入评审的状态，整体花掉大约四天时间。也就是说，绝对时间从“两周”压到“四天”，而且这四天里工程师干的是审稿、改判、补遗，不是从头填表。
再看质量分布。盲审结果显示，Agent初稿在常规场景上的召回率相当不错。常见的传感器失效、告警误报、远程攻击入口，基本都能枚举到，覆盖率达到八成五左右。漏掉的绝大多数是“跨域组合场景”，比如“雨天+攻击者干扰+驾驶员疲劳后接管能力下降”，这类场景要求同时理解环境条件、网络安全事件和人的行为，单靠一个域的知识很难枚举齐全。这恰好印证了一个观点：Agent擅长单域知识的铺开，但跨域组合推演仍然需要人来补位。
在需求完整度上，Agent初稿的可用度比我们预想得高，但存在另一个问题：它的初稿往往“合理但不完整”。它能写出AEB在逆光下应保持行人检测能力的SOTIF相关项，但不会主动判断这条需求跟摄像头硬件选型之间的成本约束是否矛盾。这类架构层面的trade-off判断，Agent目前给不出有深度的见解，需要架构师参与整合。
5.3 仍然必须“人建”的清单：风险接受准则、架构约束与供应商审计
跑完试点，我给团队列了一份“哪些环节绝不交给Agent”的清单。
首先是风险接受准则。某个风险到底“能不能接受”，不是一个技术判断，而是一个企业级决策。ASIL等级、SOTIF可接受准则、网络安全风险等级，这些数字Agent可以建议，但“我们公司愿意承担多大残余风险”必须由管理层、功能安全经理和项目经理共同拍板。这部分一旦交给Agent，后果就是会把风险偏好交给统计概率，完全丧失工程判断。
其次是架构强约束。安全需求在设计上往往要依赖特定的架构冗余方案。比如“ASIL D的安全相关功能不能与非安全相关功能共享同一内存空间”这类约束，依赖对MCU架构、Hypervisor分区、软件部署的经验，Agent只能从标准里检索到原则性条款，但无法理解你当前这块芯片在特定配置下是否能满足。这类建模现在仍然人建，且是专家建。
第三是供应商审计。Agent可以生成“供应商应提供ISO 26262相关文档”这类批量需求，但对具体供应商的技术能力、历史交付质量、审核中发现的偏差，没有判断基础。每次审计意见、每个关注项，都要由有经验的供应商质量工程师撰写复核，这活没法靠大模型自动化。
这份清单不是给Agent“祛魅”，恰恰是帮助团队重新定义了人机协作边界：Agent负责铺开，人负责收敛；Agent负责枚举，人负责决策。边界清晰了，ROI才能算得清楚。
最后分享一个我们内部复盘时反复强调的观点：如果重新做一次这个项目，我会从第一天就把三套标准的术语本体映射表和场景要素模板定义好，而不是先急着让Agent跑起来。数据底座和流程边界清晰后，Agent的每一次生成都会回到同一个稳定的语义坐标系里，后面所有迭代都能踩在前一步的经验上。REANA这个平台落地到此，我的体会是：它没有取代安全工程师，只是让我们从打字员重新变回了专家。而“从人建模型到Agent建初稿”，本质上是把人的时间还给人，把模型的枚举能力压榨到极致，再用规则和流程把每一份初稿牢牢锁进安全工程的框架里。
