一人成军_从零搭建基于 OpenClaw 的功能安全 Agent(5)TSC实战-夜雨聆风

一人成军_从零搭建基于 OpenClaw 的功能安全 Agent(5)TSC实战

本篇聚焦五个核心机制：输入采集链、活动卡 × Lessons 联动、Spawn 调度流程、Excel 框架、问题→解决方案→Lessons 闭环。

前面四篇把基础设施搭好了——部署、多 Agent 架构、审查机制、知识库。这一篇终于能跑起来了。

说”跑起来”三个字很简单，但真正从一份 IC 安全手册推到 19 个 sheet 的 Excel 交付物，中间发生的事比我预想的多得多。下面两条实战项目，把整个过程掰开给你看。

先交代背景：为一个车载仪表生成TSC，仪表安全等级为ASIL B。

这次实战中，我假设了两个项目（两个项目的输入完全一致）

项目1：XXX XX Cluster，一条龙流水线，最后出了 148 条 TSR

项目2：xxxx cluster，对生成环节进行了优化，出了 161 条 TSR（本文重点介绍的内容）

两个项目跑下来，该踩的坑基本都踩了。现在回头整理，分五个核心机制来和大家分享。

──────────────────────────────────────

一、完整流程概览

先看全局，下面是经过两次实战打磨后的最终流水线：

每条线 AI 自己跑大概半小时，你的时间只花在判定上——哪些通过、哪些要改。下面逐个机制展开说。

──────────────────────────────────────

二、机制一：TSC 前置输入采集与确认链

2.1 为什么输入采集要单独拎出来

第一个最容易被忽视的系统性错误，就是拿到 FSC 直接写 TSR。

听起来很合理对吧？功能安全需求来了，我开始推导技术安全需求，有什么问题？

问题是 Engineer 少问了三个问题：

1.平台上各 IC 到底能提供什么安全机制？

2.架构里哪些接口承载了安全功能？它们坏了会怎样？

3.我对架构的理解跟你想的一样吗？

先说结论：

第一个问题靠 S17（IC 安全数据提取）回答。第二个靠 Stage 1 （安全链路与接口审计）。第三个靠你——用户确认。

后来我把整个生成过程拆分成了3前置，1产出。

缺一环就不能往下走。

之所以有这样的流程——第一遍实战的时候，跳过了 Stage 1 审计，VR 第一轮直接炸出 14 个 Warn 加 1 个 Fail。仔细一看，全是「接口覆盖不全」「链路分析缺失」「架构假设没验证」——这些本该在审计阶段就解决掉。

2.2 S17 — 第一道前置：IC 安全数据提取

S17 的目标很朴素：把各 IC 安全手册里零零散散的信息，整理成一张结构化清单，后面 TSC 写需求的时候直接查，不用每次都翻几百页的手册。

用户提供的输入：

材料	来源	提取内容
主MCU 安全手册	MCU 厂商	ECC, Lockstep, WDT, ADC 诊断, 时钟监控, 电源监控, MPU
核心IC安全手册	PMIC/OSD IC 厂商	过压/欠压/过温检测, SPI 通信超时, CRC 校验, 电压比较器

这里有一个我觉得特别能说明问题的错误：安全手册中 SPI Timeout 计算公式，Engineer 把 15 帧超时抄成了 255 帧。手册原文清清楚楚写的 15 帧，但 AI 把常量抄错了。

这不是 AI 不懂——它读手册大方向从来没偏过。但这恰恰是 VR 必须存在的理由：你不需要让 VR 理解整套安全逻辑，你只需要它帮你核对关键数字。

2.3 Stage 1 — 第二道前置：安全接口与链路审计

S17 告诉你「各 IC 能做什么」。Stage 1 审计告诉你「这些机制是不是可以覆盖整个安全链路」。

审计干了四件事：

步骤	内容
解析输入	S17 + FSR 表 + 架构图
识别安全接口	每个接口标清楚：谁到谁、什么信号、承载什么 ASIL、有没有保护机制
映射安全链路	每条 FSR 从头画到尾：传感器→处理→决策→执行
标记缺口	哪里有歧义、哪里缺覆盖、哪里靠假设撑着

xxxx cluster 的审计产出：

类别	数量	说明
安全接口	28	MCU↔OSD IC (SPI), MCU↔PMIC (I2C), MCU↔Deserializer (I2C), 显示链路等
MCU 内部机制	12	ECC, Lockstep, WDT, ADC 诊断, 时钟监控, 电源监控
FSR 安全链路	11	每条 FSR 的完整路径 + 故障模式 + 保护覆盖

审计阶段就直接暴露了三个问题——如果没做这一步，这些问题得等到 VR 阶段才发现：

1.VSYNC 看门狗 500ms，FTTI 才 300ms：显示链路要求故障后 300ms 内响应，但看门狗 500ms 才触发。中间有 200ms 的盲区，故障发生了没人知道。

2.SPI 超时设了 200ms，占了整个通信预算的 67%：FTTI 总共 300ms，光故障检测就吃掉 200ms，降级响应只剩 100ms，时间非常紧。

3.OSD IC 三个安全机制出厂默认是关的：CRC 校验、帧超时检测、电压比较器，上电必须通过 SPI 显式使能。如果不使能，这三个保护形同虚设。

说实话，这三个问题如果拖到 Stage 2 才发现，整条链路都得推翻重来。Stage 1 审计干的事就一个：把架构理解的偏差，挡在写需求之前。

2.4 用户确认 — 第三道前置：纠偏循环

审计报告出来了，不急着往下走。中间必须夹一个确认环节——给你看，你说对了再往下。

xxxx cluster 这个阶段来回改了 4 版：

版本	改了什么	为什么改
v1.0	初始审计（28 接口 + 12 机制 + 11 链路）	—
v1.1	IF-01 降 QM(B)、IF-02 升 ASIL B、IF-09 升 ASIL(B)、移除背光分析	纠正了 ASIL 分配
v1.2	Signal/Data 列补全	v1.1 改 ASIL 的时候漏了同步更新数据字段
v1.3	E2E 保护补充	审计发现通信链路缺端到端保护

v1.1 改完 ASIL 漏了 Signal/Data 这件事，直接催生了一条新规则：「四列一致性检查」——改 ASIL 必须同步检查 Signal / Mechanism / Notes 三个关联列。后来这条规则纳入了所有 Manager 的 VR 规范。

确认通过，才进入 Stage 2（TSC产出）。（这是强制要求）

──────────────────────────────────────

三、机制二：活动卡 × Lessons Learned 联动

3.1 把规则放到正确的地方

相信很多用户会自然地觉得：规则嘛，放 AGENTS.md 就行了。「每条 TSR 只能有一个 shall」「禁用弱词」「条件前置」——全写进去。

结果 Engineer 根本不执行。

不是 AI 不听话。是它读 AGENTS.md 的方式跟我们想的不一样——通用行为指令写到后面，AI 会选择性略过。不是”忽略”，是”概率性忽略”。有时候遵守了，有时候跳过了，完全不可靠。

后来我们把规则换了个地方放。

3.2 活动卡管流程，Lessons 管教训

现在是这样分层的：

逻辑很简单：

活动卡是稳定不变的——定义流程

Lessons 是随项目累积的——记录教训

Engineer 每次执行，活动卡先指路：”去读 Lessons 文件”

Lessons 文件里全是具体的、踩过坑的问题和正确答案

Manager 或 Head 在 VR/CR 中发现了新问题，评估一下值不值得推广，值得就追加到 Lessons 文件

──────────────────────────────────────

四、机制三：Spawn 调度流程

4.1 你说的「开搞」，底下发生了什么

你说完「开搞」之后：

4.2 四个踩出来的设计决策

决策一：Manager 绝不动内容

Manager 的 AGENTS.md 开头就写了：你是审核者，不修改。整条修改链路是单向的——你说改 → Head 转发 → Manager 转发 → Engineer 动手。Manager 在中间只是传话筒加审查者。

一旦 Manager 开始改内容，审查和被审查就是同一个人，VR 就失去意义了。

决策二：每次修改必须重新 spawn Manager

我犯过两次这个错误，两次都导致 completion 事件丢失。

决策三：Engineer 进度要直报给你，不能只报 Manager

Manager spawn 完 Engineer 就进 yield 态了——它在休眠，没法主动去问 Engineer “你跑完了没”。所以 Engineer 内部设了检查点（5% / 15% / 40% / 80% / 100%），每到一个点就推一条消息给你。

这不是多此一举。这是 yield 态架构下唯一能监控进度的办法。

决策四：task 写模糊了 AI 会”善意曲解”

最早 task 里写的是「提交 Manager VR」。Manager 读成”这是给 Engineer 的指令，它提交了我转交就行”——直接跳过 VR。改成「你必须自己打开文件审查，对照 checklist 逐项检查」之后，才开始干活。

把 task 当成 API 调用看。参数不精确，返回值就是错的。

──────────────────────────────────────

五、机制四：Excel 生成框架

5.1 Excel 为什么归 Head 干

CR 过了之后，MD 规格书已经是完整交付物了。但项目上通常要 Excel。

这个转换我放在了 Head，没给 Engineer。原因是：

·Engineer 的上下文窗口在 TSC 产出时已经用掉一大半

·Excel 是纯格式转换，不需要理解安全逻辑

·每个人干自己最擅长的事

──────────────────────────────────────

六、机制五：问题→解决方案→Lessons 闭环

6.1 跳过接口审计的代价

第一次实战没做 Stage 1，直接写 TSR。VR 第一轮 14 Warn + 1 Fail，根因全指向同一个方向：不了解架构里的接口和链路。

把安全分析和需求编写掺在一起做，就是会漏东西。后来拆成 Stage 1（审计）+ Stage 2（写需求），中间加确认点，问题彻底解决。第二次实战的 Stage 1 审计在动笔写需求之前就揪出了三个关键问题：看门狗超时、SPI 预算吃紧、安全机制默认关闭。

6.2 一句话改了 Manager 的行为

Manager 跳过 VR，连续两次。

就因为我 task 里写了「提交 Manager VR」。Manager 觉得这是给 Engineer 的指令——Engineer 提交，我转发，完事。

改成「你必须自己打开文件审查，对照 checklist 逐项检查」之后，再也没跳过。

AI 会善意曲解模糊的指令，它会选那条最省事的路径走。你让它”提交”，它就只提交。你让它”审查”，它才审查。

6.3 VR 结果丢了半截

80 多项的 VR 结果，放在一条 session 消息里发。后半截直接没了。

不是代码 bug，是消息通道承载不了那么长的内容。后来强制 VR 结果写入 `VR_Result_vX.X.md` 文件，session 消息只放摘要，没再出过这个事。

6.5 Lesson Learn怎么沉淀到系统里

每次跑完，新lessonlearn走这条路：

──────────────────────────────────────

七、本篇小结

通过五个核心机制生成高质量TSC：

1.输入采集链：S17 → 审计 → 确认 → Stage 2，缺一不可

2.活动卡 × Lessons：一个管流程，一个管教训，每次执行自动加载

3.Spawn 调度：三级链路，改东西必须重走整条链

4.Excel 生成：解析→路由→排序→校验，细节全是坑

5.问题→Lessons 闭环：开口项评估可推广性，自动继承到下次

上述机制的核心价值不在“让 AI 帮你写需求”——而在每次产出有两层独立审查兜底，而且每次踩的坑都能自动变成下次的护栏。你不需要对着 161 条 TSR 一条条看，VR 和 CR 已经把不满足的列好了，你判定就行。

下一篇说怎么把这整套流程打成一个可移植的 TSC Skill，换个人、换个项目，装上去就能用。

──────────────────────────────────────

Next: Part 5 — TSC Skill 封装与系统扩展

────────────────────────────────────────