一人成军_从零搭建基于 OpenClaw 的功能安全 Agent(6)TSC Skill 封装与扩展

可移植 Skill 封装 · 跨 Agent 移植 · 后续活动扩展

前面五篇，我们在 FUSA Head 下完整跑通了 TSC 全流程。S17 提取数据、Stage 1 审计接口、Stage 2 产出 148 条 TSR、VR 四轮修正、CR 认可评审、最后生成了完整的Excel版TSC。

但这里有一个很现实的问题：换个项目、换台机器——难道所有流程要重新再来一遍吗？

这一篇就来告诉大家：怎么把 TSC 流程打成可移植的 Skill 包，怎么跨 Agent 移植，以及接下来要往哪个方向继续扩展。

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

一、为什么非要封装

FUSA Head 的 workspace 里什么都有：52 张活动卡、十来个 checklist、十几份 ISO 标准全文和各种规范、AGENTS.md 调度规则。它们全都耦合在一起，基本不可能只把 TSC 那部分单独拆出来给别人用。

Skill 封装就干四件事：

把 TSC 相关文件全部打进一个独立目录

换到任何Agent 上都能跑

不依赖特定的配置或路径

跟已有的 fusa-Agent 完全隔离——装了这个 Skill 不会把原来的体系搞乱

说白了，就是把一篇”长在我电脑里的东西”变成”拷给你就能用的工具”。

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

二、Skill 包里有什么

一个 TSC Skill 就是一个自包含目录，16 个文件，我生成的大概 840KB：

全文本，跨平台零依赖。单独提取出来的所有TSC相关核心。

2.1 SKILL.md — 调度引擎

SKILL.md 是整个 Skill 的大脑，定义了 Head 的五步执行流程：

每一步都写清楚了：调哪个角色、输入材料在哪、参考什么文件、产物放哪里、用户判定节点在哪。Head 拿到 SKILL.md，按图索骥就行。

2.2 AGENTS 裁剪版

完整 FUSA 体系里，AGENTS.md 包罗万象——Process、System、HW、SW 的规则全混在一起。但 TSC Skill 只用得到 System 层面那部分。所以我们做了裁剪：

裁剪原则一句话：Process/HW/SW 相关的一律砍掉，只留 TSC 要用的。

2.3 保真机制：怎么把裁剪版 AGENTS 塞进子 session

这地方藏了一个关键设计：spawn 出去的 Engineer 和 Manager，默认用的是它们自己 workspace 里的 AGENTS.md——也就是完整版，该怎么对这部分md做裁剪呢？

做法很直接：在 spawn 的 task 开头，把裁剪版 AGENTS 全文贴进去。

这样子 session 的第一条消息就是裁剪版规则。子 Agent 先读到规则、再读到任务——行为完全由裁剪版控制，不会被完整版里不相关的 Process/HW/SW 规则干扰。

2.4 怎么生成这个 Skill：手动 vs 用 skill-creator

这里有一个很容易被忽略的问题：TSC Skill 这个包，是谁生成的？

你可以自己手写——建目录、写 SKILL.md、剪 AGENTS、拷活动卡、拷标准文件。第一次我们就是这么干的，大概花了两个小时，其中一大半时间在检查「有没有漏文件」「路径写对了没有」。

但 OpenClaw 自带了一个叫 skill-creator 的 skill，专门用来生成和管理 Skill 包。它知道 Skill 的标准结构、验证规则、裁剪原则。用它来生成 TSC Skill，流程变成这样：

你告诉 skill-creator：

目标：生成 TSC Skill

来源：FUSA Head workspace 下的相关文件

要求：只含 System 层面，跟 fusa-* 隔离

然后 skill-creator 自己读源文件、自己裁剪 AGENTS、自己建目录、自己验证结构。

两种方式的对比如下：

两个关键收益：

第一，省时间。两小时变五分钟，不是夸张——skill-creator 把「创建目录、复制文件、校验格式」这些体力活全自动化了。你只做判断：哪些文件要放进去，哪些不相关。

第二，防低级错误。手写 SKILL.md 的时候，frontmatter 格式写错、引用路径写死、少拷了一个 checklist——这类问题 skill-creator 能自动检测。它内置了 Skill 包的验证规则，格式不对直接报错。

但也不是说 skill-creator 就能全自动了。AGENTS 裁剪、活动卡的内容审查、Lessons 文件的取舍——这些判断级的工作还是得你自己做。skill-creator 干的是”打包”，不是”决策”。

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

三、安装与使用

3.1 三种装法

装完重启 gateway，Skill 就生效了。

3.2 用起来什么样

你只需要说三句话，就可以生成高质量的完整TSC：

然后 Head 自动跑：S17 → TSC → VR 反馈给你 → 你判定 → 修改循环 → CR 反馈给你 → 你判定 → Excel 生成 → 交付。

任何时候说「中止」就能停。

3.3 前置条件

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

四、跨 Agent 移植：从一台机器到另一台

打包只是第一步。真正考验设计的是：换一个 Agent，Skill 还能不能直接跑？

4.1 三种移植场景

4.2 移植检查清单

不管哪种场景，装完 Skill 后过一遍这四步：

1.权限检查：`tools.allow` 里加了 `sessions_spawn` 和 `sessions_send` 没有？没加的话 Manager spawn 不了 Engineer

2.白名单检查：`agentToAgent` 里目标 Agent 是不是在白名单里？不在的话跨 session 通信直接断

3.路径检查：Skill 内部的产出路径用了 `{baseDir}` 占位符吗？写死绝对路径在别的机器上一定翻车

4.AGENTS 冲突检查：目标 Agent 自己的 AGENTS.md 会不会跟 Skill 内裁剪版 AGENTS 冲突？优先用裁剪版，完整版里不相关的规则 Skill 会自动屏蔽

4.3 与现有体系的关系

前面提过但值得再强调一遍——Skill 和 fusa-* 体系的关系是”物理隔离”：

装在 `skills/tsc/` 下，跟 `workspace-fusa-head/` 完全是两套目录

Skill 包内的 references/ 自带标准文件副本，不读外部的

同一个 Agent 上可以同时跑全体系 + Skill，互不干扰

冗余是真的冗余——5 份 ISO 标准在主 references/ 和 Skill 包里各存了一份。但对于”拷给别人就能用”这个目标来说，这份冗余是必要代价。

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

五、往硬件、软件、流程层面扩展

不管加哪个层面，流程是一样的：

1.写 Engineer 活动卡（描述 + 标准引用 + 输入输出）

2.建对应的 `-lessons.md`

3.写 Manager VR 活动卡 + checklist

4.写 Head CR checklist

5.在 Head AGENTS 的调度表里加一行新活动的映射

6.跑一遍 → 收开口项 → 迭代

架构不用动。加活动卡和 checklist 就行。这个体系设计之初就是为扩展准备的。

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

六、系列回顾与下一步

到目前为止，我们搭了这些东西：

这不是”一个会聊天的 AI”。这是一个有分工、有审查、有反馈闭环的工程流水线。它把你从功能安全活动里最耗时的那部分——翻标准、对清单、交叉核对、格式检查——解放出来。你的精力可以留在真正需要专业判断的地方。

下一步：系统安全分析

TSC 出完之后，下一个自然的问题是：怎么证明这套技术方案在各种故障场景下都能有对应的安全机制来覆盖？

答案就是系统安全分析——FTA（故障树分析）和 FMEA & FMEA-MSR（失效模式与影响分析）。这两项活动直接跟在 TSC 后面，用 TSC 产出的安全机制和接口定义作为输入，反过来验证 TSC 的设计是否自洽。

下一篇，我会把这个环节完整展开：FTA 和 FMEA 的选型逻辑、双路径活动卡的设计、安全分析结果如何反哺 TSC 修改、以及分析过程中发现的那类”直觉上没问题但方法论上过不了”的设计问题。

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

Next: Part 5 — 系统安全分析：FTA & FMEA / FMEA-MSR

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

© 2026 本文档内容受知识产权保护，未经作者许可，严禁以任何形式转载、复制或用于商业用途。