第22章 打造Skill蒸馏书和视频
第 22 章 打造skill：将书和视频蒸馏为可执行 Skill
制作skill，除了把自己的SOP沉淀为skill外，给大家推荐一个更简单方便的办法。
可以使用[cangjie-skill](https://github.com/kangarooking/cangjie-skill)把知识蒸馏成skill。
cangjie-skill 开源项目（v1 蒸馏书，v2 增加视频蒸馏），以及 Andrej Karpathy 关于 LLM 个人知识库的思路。
本章回答：如何将书本和视频中的方法论转化为 Agent 可自动调用的 Skill，以及这与 RAG 检索的本质差别在哪里。
问题起点：知识读了但用不起来
AI 在训练时已经摄入了大量经典著作，但在实际问答中，它往往输出"正确的废话"——每个字都对，但缺乏针对特定问题的可落地步骤。这不是幻觉问题，而是调用机制问题：AI 知道书里有什么，但不知道该在什么场景下主动调出哪个框架。
人类读者面临同样的问题。读完一本书，笔记做了、金句划了，合上书以为升级了。两周后遇到真实问题，那些方法论却抓不住。知识在记忆里，但激活路径不清晰。
知识精馏要解决的，就是这个"学了用不上"的问题。
知识精馏的定义
知识精馏（Knowledge Distillation for Skills）是指：从书本或视频中，提取出具有独立触发条件和执行步骤的原子化知识单元（Skill），使 Agent 在遇到对应场景时能够自动激活并给出可落地的行动路径。
化学中的精馏是按沸点将混合物分离成不同纯净组分。知识精馏按"框架 / 原则 / 案例 / 反例 / 术语"五个维度，将书或视频中的知识分离成不同类型的纯净组分，然后只把真正有用的提纯成可执行的 Skill。
知识精馏不是：
知识精馏是：将方法论转化为 Agent 能够在真实场景下自动调用的执行单元。
六阶段蒸馏 SOP
cangjie-skill 使用六个阶段将一本书或一组视频蒸馏成一套 Skill。
```mermaid
flowchart TD
A[阶段 0：整书/整片理解] --> B[阶段 1：五个 Agent 并行提取]
B --> C[阶段 2：三重验证筛选]
C --> D[阶段 3：构造 Skill]
D --> E[阶段 4：链接——建立 Skill 关系网络]
E --> F[阶段 5：压力测试]
```
以蒸馏《文案创作完全手册》为例
阶段 0：整书 / 整片理解
不从摘取金句开始，而是先读清整本书的骨架：
这一步决定后续提取的质量上限。跳过这一步直接提取，容易把作者反对的观点当成他支持的方法论。
阶段 1：五个 Agent 并行提取
五个 Agent 同时从五个维度扫描全文，独立工作，互不干扰：
| Agent | 提取目标 |
|-|-|
| 框架提取 Agent | 作者构建的分析或决策框架 |
| 原则提取 Agent | 可跨场景复用的行为原则 |
| 案例提取 Agent | 作者援引的正面案例和成功路径 |
| 反例提取 Agent | 作者援引的失败案例和反面教训 |
| 术语词典 Agent | 作者专有术语及其定义 |
五个角度并行，避免单线阅读中的视角遗漏。
阶段 1.5：三重验证筛选
每个候选知识单元必须通过三关，未通过直接淘汰：
| 验证类型 | 检查内容 |
|-|-|
| 跨域验证 | 该方法论在书中至少两个独立场景出现过，不是孤证 |
| 预测力测试 | 能用它推导出书中没有直接讨论的问题吗 |
| 独特性检验 | 是不是任何人都能说出来的常识？常识不构成 Skill |
宁缺毋滥。一本书通常有 50–100 个候选单元，通过三重验证后保留 10–25 个。
阶段 2：构造 Skill
每个通过验证的知识单元被构造成一个 Skill，核心是设计触发条件：
触发条件的设计是最难也最关键的一步。没有触发条件的 Skill，在实际使用中无法被 Agent 正确识别和调用。
阶段 4：链接
找出 Skill 之间的关系，形成知识网络：
链接层让 Agent 在遇到复杂问题时，能够选择一组 Skill 而不只是单个 Skill。
阶段 5：压力测试
诱饵测试：故意给不该触发的场景，检验 Skill 是否能忍住不激活。一个没有边界的 Skill，在错误场景下调用反而帮倒忙。
执行验证：给出真实问题，验证 Skill 是否能输出可落地的步骤而不是正确的废话。
蒸馏产物结构
一本书蒸馏完成后，产物是一套 Skill 集合：
```text
book-skill/
├── README.md # 书目信息、蒸馏说明、适用场景
├── skills/
│ ├── skill-01.md # 每个 Skill 独立文件
│ ├── skill-02.md
│ └── ...
├── index.md # Skill 关系网络（链接层产物）
└── tests/
├── skill-01-test.md # 每个 Skill 的测试用例
└── ...
```
每个 Skill 文件包含：触发条件、执行步骤、输出格式、边界限制、测试用例。测试用例格式兼容 darwin-skill（自动 Skill 进化工具），蒸馏产物可以持续自动优化。
知识精馏 vs RAG
这是使用者最常问的问题。
| 维度 | RAG | 知识精馏（Skill） |
|-|-|-|
| 本质 | 检索——找出最相关的原文片段 | 提炼——从原文中提取可执行的方法论 |
| 使用前提 | 用户需要知道该问什么 | 用户描述问题，Skill 自动识别并激活 |
| 质量控制 | 无——任何内容都可以入库 | 三重验证过滤，宁缺毋滥 |
| 调用方式 | 被动等待查询 | 主动匹配场景并触发 |
| 知识形态 | 存储原文（记住知识） | 提纯为执行步骤（运用知识） |
| 边界控制 | 无 | 诱饵测试确保不乱激活 |
| 资源消耗 | 较重（需维护向量索引） | 较轻（Skill 文件即可） |
RAG 解决"知识管理"问题——让你能查到书里有什么。知识精馏解决"知识运用"问题——让 Agent 在对的时刻主动拿出对的框架。
当你不知道该问什么时，RAG 帮不了你。Skill 不需要你记得书里有哪些方法论。
与 Karpathy LLM Wiki 思路的对比
Andrej Karpathy 提出 LLM 知识库（LLM Wiki）的思路：将原始资料索引到目录，让 LLM 编译成 Wiki，然后对 Wiki 做 Q&A，产出结果再回填，持续增强。
cangjie-skill 的阶段 0（整书理解）和阶段 1（并行提取）吸收了这一核心思想：先让 AI 深度阅读、结构化整理、建立索引、维护一致性。
两者的差别在于最后几步：
| 对比点 | LLM Wiki | 知识精馏 |
|-|-|-|
| 产物形态 | Wiki 条目（结构化知识库） | Skill 集合（可执行单元） |
| 使用方式 | 用户主动查询 | Agent 被动触发后主动激活 |
| 解决问题 | 知识管理 | 知识运用 |
两种方案不互斥，但目标不同。
视频蒸馏工作流（v2 新增）
cangjie-skill v2 在书本蒸馏基础上增加了视频蒸馏能力（借助[video-downloader skill](https://github.com/kangarooking/kangarooking-skills/tree/main/video-downloader)）。视频与书的区别在于：需要先完成"视频 → 文字"的转换，再进入六阶段 SOP。
视频获取与转写
整体流程：
```mermaid
flowchart LR
A[输入视频链接] --> B[video-downloader skill：下载视频]
B --> C[提取音频]
C --> D[ASR 转写为文案]
D --> E[cangjie-skill：六阶段蒸馏]
E --> F[输出 Skill 集合]
```
视频下载：使用 yt-dlp（开源工具）支持 YouTube、B 站等主流平台，只需输入视频链接即可自动下载。视频号因平台限制暂不支持自动化。
音频转写：本地 Whisper 模型可用，但长视频转写耗时显著（一小时视频约需 48 分钟本地转写）。推荐使用 ASR API 服务，速度快，适合批量处理。
多视频合并蒸馏
同一主题的多个视频可以合并蒸馏，产出统一的 Skill 集合。合并时 Agent 自动处理内容去重和知识单元合并，避免同一原则在不同视频中被重复提取为多个 Skill。
video-downloader skill 与 cangjie-skill 的分工
视频处理逻辑（下载、提取音频、转写）独立封装在 video-downloader skill 中，不集成到 cangjie-skill 内部。原因是职责分离：cangjie-skill 专注文本蒸馏，视频获取是前置准备步骤，两者可以独立演进。
```text
使用方式：
1. 用 video-downloader skill 获取视频文案
2. 将文案交给 cangjie-skill 进行六阶段蒸馏
3. 输出对应的 Skill 集合
```
适用与不适用场景
适合蒸馏的材料
| 类型 | 适合程度 | 说明 |
|-|-|-|
| 方法论密度高的书 | ★★★★★ | 框架清晰，原则可提取，最适合 |
| 访谈 / 课程视频 | ★★★★☆ | 内容结构化程度较高，适合蒸馏 |
| 长视频 / 播客 | ★★★☆☆ | 可用，知识密度因内容而异 |
| 金句散文类书籍 | ★★☆☆☆ | 方法论少，蒸馏产物质量有限 |
| 小说 / 叙事文学 | ★☆☆☆☆ | 不适合，缺乏可提取的方法论框架 |
蒸馏的前置条件
蒸馏前最好读过或看过一遍原材料。原因：
蒸馏不是替代阅读，而是阅读后的知识结构化工具。
蒸馏产物的持续优化
cangjie-skill 产出的每个 Skill 自带测试用例，格式兼容 darwin-skill（达尔文.Skill）。
darwin-skill 是自动 Skill 进化工具：将 Skill 喂给它，它会自动评估、改进、测试，且分数只升不降。
这意味着蒸馏产物不是静态的。随着 Agent 实际使用反馈的积累，Skill 可以持续自动优化，逐步接近书中方法论在真实场景下的最优表达。
资源消耗与模型选择
知识精馏是 Token 消耗密集型任务，主要来源于：
| 场景 | 大致 Token 消耗 | 大致耗时参考 |
|-|-|-|
| 蒸馏一本普通书 | 数万至十余万 Token | 30–90 分钟 |
| 蒸馏 26 集课程视频（4 小时） | 较高 | 约 1 小时 |
| 蒸馏 4 个主题视频（80 分钟） | 中等 | 约 40 分钟 |
模型选择建议：
【图片占位：Token 消耗过程截图，展示蒸馏过程中 Token 使用量的增长曲线】
蒸馏产物的分享与复用
知识精馏的一个重要特点是：产物（Skill 集合）可以直接分享和复用。
使用已蒸馏的 Skill：将 GitHub 仓库地址提供给 Agent，让 Agent 自动安装对应 Skill 即可使用，无需重新蒸馏。
社区协作：同一本书不需要被每个人重复蒸馏。任何人蒸馏的成果都可以开源，其他人直接复用。
扩展应用：视频课程的蒸馏产物可以进一步构建课程 Agent，供学员问答和辅助实践，即课程内容的结构化知识服务化。
常见误区
误区 1：AI 训练过的书不需要再蒸馏
对于大众熟知的经典书籍，AI 确实有一定记忆。但对小众书籍、新出版书籍以及时效性强的视频内容，AI 大概率没有训练过。此外，即使 AI 训练过某本书，蒸馏的价值在于建立触发条件——让 AI 知道在什么场景下应该调出该书的哪个框架，而不只是"知道书里有什么"。
误区 2：蒸馏完就不需要看书了
蒸馏是阅读的补充，不是替代。没读过就蒸馏，会在关键判断节点上缺乏背景，导致蒸馏结果遗漏重点。阅读过一遍后再蒸馏，蒸馏产物的质量和完整度显著更高。
误区 3：AI 给了建议就能直接执行
即使 Skill 被正确激活并给出了可落地的步骤，方向对不对、能不能执行、效果好不好，仍然需要人来判断。AI 给出的是选项和分析，决策是人的责任。
误区 4：Skill 覆盖越多越好
覆盖太宽的触发条件会导致 Skill 在不适用的场景下被错误激活，反而产生误导。三重验证和诱饵测试的目的正是控制边界，宁可覆盖窄一点，也不要乱激活。
蒸馏结果示例
以吴恩达《给所有人的 AI 入门课》（2026 版，26 个视频，时长约 4 小时）为例：
总结：知识精馏在技能包体系中的位置
知识精馏是 Skill 的一种生产方式。它和第 25 章讨论的 SOP → Skill 封装流程是并行的：
| 来源 | 适用场景 |
|-|-|
| 从业务流程提炼（SOP → Skill） | 企业内部操作规范、重复性业务流程 |
| 从书本 / 视频蒸馏（知识精馏） | 专家方法论、经典著作、高价值课程内容 |
两者产物格式一致，都是带有触发条件的可执行 Skill，可以在同一个 Agent 框架下混合使用。
第23章 WorkBuddy实操案例集
第 23 章 其他用法补充：WorkBuddy 实操案例集
前面的章节介绍了 Agent 工具链的核心能力：文件处理、数据库操作、MCP 连接和企业协作。这一章补充几类容易被忽略但实际价值很高的用法，以 WorkBuddy 为例，覆盖短任务、设计创意、Skill 联动、浏览器自动化和项目管理等场景。
WorkBuddy 与大多数 AI 聊天软件的核心区别在于三点：能直接读取和修改本地文件，学习门槛低，入口清晰。对于还没有系统搭建 Agent 工作流的读者，这些案例可以作为起点。
模型与成本：先把免费额度用透
WorkBuddy 内置了多款国产大模型。每日签到领取的积分基本能覆盖轻度使用的全部消耗。新发布的模型通常附带免费体验期——以 HY3 为例，发布后有两周免费额度，即使过期，定价也属于国产模型性价比第一梯队。
如果拿不准做什么，WorkBuddy 已经按应用场景预设了模板，选一个直接开始即可。
短任务实战：Excel 可视化与数据清洗
HY3 在短任务上表现突出。PPT 生成、数据清洗、Excel 图表可视化分析都能直接完成。
从开屏界面出发，输入任务描述后点击右下角"优化提示词"按钮，WorkBuddy 会自动补全细节并执行。
提示词示例：
```text
帮我可视化这份流水账数据并分析一下。
重点关注：
1. 每月收支趋势；
2. 支出分类占比；
3. 异常大额支出标注；
4. 给出 3 条可操作的省钱建议。
```
执行过程可能较慢，但最终产出的可视化效果通常超出预期——包括图表、趋势分析和文字总结。数据清洗和 PPT 生成同理。
设计创意：用提示词生成完整网站
这是一个容易被低估的用法。勾选"网站设计"场景后给出提示词，可以生成可运行的前端页面。以下是两个经过验证的模板。
模板一：个人作品集 Hero Section
生成一个带有视频背景、鼠标交互和响应式布局的全屏 Hero 页面。
提示词：
```text
Build a full-screen hero section for a creative portfolio using React, Vite, Tailwind CSS, and the Figtree Google Font.
要求：
1. 三个全屏循环视频作为背景，通过 crossfade 切换，透明度过渡 1200ms；
2. 顶部导航栏：左侧导航项格式为"01 / Works"，右侧显示邮箱和实时时钟；
3. 底部内容区：左侧大字名称（200px），右侧介绍文案和 CTA 按钮；
4. 按钮 hover 效果：背景色从底部填充上来；
5. 支持平板和手机端的响应式适配；
6. prefers-reduced-motion 下禁用所有动画。
```
模板二：创意机构 Landing Page（鼠标控制视频）
这个模板的特色是视频不自动播放，而是跟随鼠标水平移动控制播放进度。
提示词：
```text
Build a full-screen hero landing page for a creative agency called "Mainframe" using React, TypeScript, Vite, and Tailwind CSS.
核心交互：
1. 全屏视频背景，不自动播放；
2. 鼠标水平移动控制视频播放进度（sensitivity = 0.8）；
3. 顶部导航：左侧 Logo + 装饰星号，中间导航链接用逗号分隔，右侧 CTA；
4. Hero 内容：模糊的介绍文字 + 打字机效果的主文案 + 圆角药丸按钮组；
5. 移动端：汉堡菜单，CSS Grid 展开动画；
6. 按钮 hover：白色填充变黑色文字。
```
以上两个模板全程使用 HY3 模型完成。
Skill 联动：跨服务的智能推荐
WorkBuddy 的 Skill 系统允许 Agent 连接日常使用的各类服务。这种跨服务联动是 Skill 生态的核心价值——不是替代某个 App，而是成为多个 App 之间的连接层。
示例：微信读书 + QQ 音乐
安装并连接微信读书和 QQ 音乐的 Skill 后，可以实现跨服务的智能推荐：
提示词：
```text
根据我最近在微信读书中阅读的书目，推荐适配阅读氛围的歌单。
要求：
1. 先读取最近 7 天的阅读记录；
2. 分析书目的情绪基调和主题；
3. 在 QQ 音乐中匹配风格相近的歌单；
4. 输出推荐理由和歌单链接。
```
微信读书 Skill 的安装链接可以在官方页面获取：`https://weread.qq.com/r/weread-skills`。
第24章 多Agent系统设计
第 24 章 如何进行多 Agent 系统设计
一人公司产品宣传部实践（HyperFrames + 多 Agent）、WorkBuddy 专家团产品。本章以产品宣传片专家团的实际案例，回答：多 Agent 系统如何设计分工、如何串联产物、何时值得拆分。
单 Agent 和多 Agent 的真正差别
| 维度 | 单 Agent | 多 Agent |
|-|-|-|
| 上下文 | 所有信息在一个任务 | 角色只接收必要上下文 |
| 分工 | 一个执行体串行完成 | 多角色并行或接力 |
| 工具 | 同一组权限 | 可按角色隔离工具和权限 |
| 质量 | 自己生成、自己检查 | 可设置独立评审者 |
| 成本 | 较低 | 协调、模型和工具调用更多 |
| 风险 | 一处错误影响整体 | 错误可能在角色间传播 |
多 Agent 的价值来自专业分工、并行、权限隔离或独立评审，不来自角色数量。
任务是否值得拆分
满足越多，越适合多 Agent：
只改一封邮件、总结一份 PDF 或格式化一个表格，不需要专家团。
案例：产品宣传片专家团
任务背景
HyperFrames 是 HeyGen 开源的视频渲染框架（截至案例时 GitHub 17.7K Star），核心特点是对 AI Agent 友好：Agent 可以自动生成基于 HTML 的视频帧并渲染输出。产品宣传片具有相对固定的套路——无需口播和演员，主要由产品展示、概念字幕和 BGM 构成。这类任务适合 Agent 团队分工处理。
工序设计
产品宣传片专家团的完整工序如下：
```mermaid
flowchart TD
A[主理人：接收任务，拆解子任务] --> B[Brief 角色：调研产品，输出内容简报]
B --> C[分镜师：按 Brief 拆解镜头序列]
C --> D[素材师：生成或抓取每帧所需素材]
C --> E[剪辑师：按分镜表在 HyperFrames 中逐帧渲染]
D --> E
E --> F[配乐师：分析情绪曲线，生成并选择 BGM]
F --> G[主理人：整合所有产物，输出成片]
```
角色契约
| 角色 | 输入 | 输出 | 禁止动作 |
|-|-|-|-|
| 主理人 | 用户任务描述、素材空间 | 任务拆解、状态追踪、成片 | 不跳过子任务验收直接交付 |
| Brief 角色 | 产品官网、介绍文档 | brief.md（产品定位、核心价值、目标用户） | 不直接写脚本 |
| 分镜师 | brief.md | 分镜表（时间码、画面、字幕、转场、动效） | 不引入 Brief 未确认的信息 |
| 素材师 | 分镜表 | 产品截图、概念图、界面素材 | 不使用无版权来源素材 |
| 剪辑师 | 素材、分镜表 | 逐帧 MP4 片段 | 不改动分镜结构 |
| 配乐师 | 分镜表、情绪标注 | BGM 候选及推荐理由 | 不只输出一个选项 |
专家团演示
在做产品宣传片之前，需要先把相关素材放到工作空间内。
```Plain Text
我希望你做一个产品宣传片，具体的话，是宣传腾讯的workbuddy最新的专家团，主打opc场景。当前空间下我放了一些素材，成片风格可以偏apple风格、真实软件界面。整个过程全自动
```
团长先接到任务：把"做一支宣传片"拆成了一串子任务：先得搞清楚 WorkBuddy 专家团到底是什么、卖给谁、核心价值是什么；再决定叙事结构、镜头数量、节奏；然后再分头去做素材、剪辑、配乐。
brief 角色先开工：去把 WorkBuddy 官网、产品介绍、专家团列表都翻了一遍，输出一份 brief ，这是什么产品、目标用户是谁、最值得放进 60 秒的几个核心点。
分镜师接着 brief 干活：把 60 秒拆成了 7 个镜头，每个镜头都细到时间码、画面、文字、转场、动效、需要的素材类型。
然后 素材师 和 剪辑师 开始干活：一个去生成 / 抓产品截图、概念图，另一个把素材按分镜表往 HyperFrames 里塞，逐镜头渲染出每一段 MP4。
最有意思的是 配乐师：它不是简单写个"科技感 BGM"的 prompt 完事，它会先把分镜表读一遍，研究每个镜头的情绪曲线，标好哪些地方需要鼓点卡产品 reveal、哪些地方需要降下来做留白、哪些地方需要一个 hit point 推 CTA。然后再去调用音乐模型生成候选 BGM。
最后由 团长 把所有产物整合，跑最后一道剪辑，输出成片。
整个过程我基本就是个旁观者：偶尔在关键节点拍一下板，比如分镜要不要这么排、BGM 喜不喜欢、字幕文案要不要改。
最后出来的片子，还挺不错的。
共享产物层
多个 Agent 不应各自维护一份"产品事实"。建立单一产物路径：
```text
project/
├── brief.md # 产品简报（Brief 角色产出，主理人确认）
├── storyboard.md # 分镜表（分镜师产出，主理人确认）
├── assets/ # 素材（素材师产出）
│ ├── screenshots/
│ └── concepts/
├── clips/ # 逐帧片段（剪辑师产出）
├── bgm/ # BGM 候选（配乐师产出）
└── output/final.mp4 # 成片（主理人整合）
```
下游角色只读取上游已确认的产物。角色之间不通过对话传递关键内容细节。
并行与串行
可以并行： 素材生成与剪辑准备、不同镜头段落的渲染。
必须串行： Brief 确认后才写分镜、分镜确认后才生成素材、素材就绪后才剪辑、成片完成后才配乐合成。
并行计划必须标明汇合点。素材和剪辑可以并行准备，但最终合成必须等待所有素材就位。
主理人的职责
主理人（制片人）是工作流控制器：
三个必须由人确认的点
1. Brief 确认：产品定位、目标用户、核心卖点是否准确；
2. 分镜确认：叙事结构、镜头数量、节奏是否符合预期；
3. BGM 选择：情绪风格是否与成片调性匹配。
Agent 负责生成和执行，不能替代品牌方向和风格判断。
产品化路径：从自建到预置专家团
自建团队
将上述角色封装为一套 Skills，在 Agent 框架中自行编排。适用场景：开发者需要完全控制每个角色的提示词、工具权限和交接格式。门槛包括：定义角色职责、设计交接格式、调试并行与串行逻辑。
预置专家团
WorkBuddy 专家团将上述分工产品化：团长负责任务拆解和分配，团员并行执行，用户只需描述任务。
创建专家团也很简单在专家->我的专家->创建专家
就会跳转到workbuddy的对话框，根据它给定的格式即可快速创建属于自己的专家。
当前专家团覆盖的典型场景：
| 场景类别 | 代表专家团 |
|-|-|
| 内容创作 | 产品宣传片、爆款内容创作、全域分发 |
| 软件研发 | 软件开发、代码测试 |
| 商业分析 | 深度研究、投资分析、数据分析 |
| 业务支持 | SEO、销售、营销、财税合规、HR |
| 法律合规 | 中文法律 |
两种路径的选择
| 维度 | 自建 Skills | 预置专家团 |
|-|-|-|
| 适用人群 | 开发者，需要深度定制 | 一人公司，直接使用 |
| 上手门槛 | 高（需定义角色、调试流程） | 低（描述任务即可） |
| 灵活度 | 高（可修改任意环节） | 中（支持自定义模型接入） |
| 速度 | 取决于搭建时间 | 即开即用 |
质量影响因素
成片质量主要受以下因素影响：
全自动方案适合快速出片（开源项目介绍视频、产品演示视频等）。对品质要求高的场景，建议以 Agent 产物为基础再做一轮人工二次剪辑。
失败传播控制
| 角色失败 | 降级方式 |
|-|-|
| Brief 角色无法获取产品信息 | 用户补充基础信息后重试 |
| 素材生成失败 | 使用用户预置素材或标记空缺位置 |
| 剪辑渲染超时 | 交付已完成的片段和分镜表 |
| BGM 生成失败 | 提供推荐 BGM 类型描述，由用户自选 |
| 主理人合成失败 | 交付各角色产物清单，由用户手动合成 |
降级交付必须说明缺失内容，不伪装成完整成果。
多 Agent 任务 Brief 模板
```text
目标：为 [产品名称] 制作一支 [时长] 的产品宣传片。
风格：[参考风格，如 Apple 风、极简风]。
素材：[素材空间路径或已提供的图片/视频]。
角色：主理人、Brief、分镜师、素材师、剪辑师、配乐师。
确认节点：Brief 完成后、分镜完成后、BGM 选择时，需用户确认后继续。
模型：Agent 模型 [指定]；图像生成模型 [指定]。
全自动/半自动：[说明是否需要中间节点人工介入]。
```
第25章 自动化工作流可靠性
第 25 章 自动化工作流的可靠性
以"每日 AI 热点选题聚合"为贯穿案例，说明自动化工作流在从手动运行到定时可靠执行的过程中，需要处理哪些问题。
案例背景：内容博主的每日选题任务
AI 内容领域更新速度快，每天需要从多个信息源中筛选当日值得写的选题。手动逐一翻阅各个平台耗时且容易遗漏。一个典型的 AI 博主选题需求如下：
```text
我是一名 AI 领域的博主，主要内容方向是 AI 教程、AI 工具、AI Coding、AI 测评等。
帮我找今日的 AI 领域热点，方便筛选当天的选题内容。
来源：
```
手动运行一次这个任务，WorkBuddy 会同时调用五个数据源，整合输出一份当日 AI 热点清单，供博主快速判断和筛选。
跑通一次后，下一步是把它设置为定时自动化任务：每天早上 9:00 自动运行，结果推送到指定位置，无需每天手动触发。
本章围绕这个场景，说明从"能用"到"可靠自动化"需要处理哪些问题。
自动化前的三个门槛
不是所有任务都适合立即自动化。判断标准：
1. 同一 Prompt 已手动运行至少三次，输出质量和格式基本稳定；
2. 触发条件、输入来源和验收标准清楚：什么时候运行、依赖哪些数据源、输出什么格式；
3. 有 owner、有告警、有停用方法：任务失败时谁处理，如何临时停用不影响其他流程。
选题任务满足以上三点：Prompt 结构固定、每天早上 9:00 触发、输出内容为当日热点清单。
频繁改 Prompt 或数据源还不稳定的任务，先手动运行，不急于自动化。
在 WorkBuddy 中设置自动化任务
手动运行确认效果后，在同一对话框中直接告诉 WorkBuddy：
```text
把这个任务设置为自动化，每天早上 9:00 运行，
结果发送到 [指定飞书群 / 邮件 / 企微通知]。
```
WorkBuddy 会将当前 Prompt 和数据源配置保存为定时任务，按设定时间自动执行。
设置完成后，每天早上 9:00，WorkBuddy 自动调用五个数据源，整合结果并推送。博主打开通知，直接开始筛选选题，不需要手动触发。
把自动化任务设计成状态机
自动化不是让任务"跑起来就行"。真实环境中，每次运行都可能遇到：某个数据源返回超时、热搜榜当日无 AI 相关条目、GitHub API 限流、推送目标不可达。
将任务设计成状态机，每个状态都有明确的成功条件和失败出口：
```mermaid
stateDiagram-v2
[*] --> WaitingTrigger
WaitingTrigger --> Fetching: 9:00 触发
Fetching --> Aggregating: 数据源全部响应
Fetching --> PartialAggregating: 部分数据源超时
Aggregating --> Filtering: 聚合完成
PartialAggregating --> Filtering: 超时来源标记缺失
Filtering --> Delivering: 筛选完成，有有效条目
Filtering --> Blocked: 所有来源均无有效 AI 内容
Delivering --> Completed: 推送成功
Delivering --> Blocked: 推送失败
Blocked --> WaitingTrigger: 次日重新触发
```
关键原则：部分数据源失败不应阻断整体任务，而是标记缺失后继续聚合；推送失败应保留结果并告警，不丢失已生成的内容。
数据源就绪检查
定时触发不等于数据源已就绪。每次运行开始时，先检查各数据源的可用性：
| 数据源 | 检查项 | 不可用时的处理 |
|-|-|-|
| @wechat-article-search | 搜索 API 可达，返回非空结果 | 标记缺失，继续其他来源 |
| @蜜度热搜榜 | 当日热搜列表可获取 | 标记缺失，继续其他来源 |
| @GitHub热门项目 | GitHub API 未限流，热门列表正常 | 退避重试一次，失败则标记缺失 |
| @多引擎搜索 | 搜索引擎可达 | 标记缺失，继续其他来源 |
| @AIHOT | 热点追踪服务正常 | 标记缺失，继续其他来源 |
五个来源中至少有三个正常，才输出热点清单。全部失败时，进入 Blocked 状态并推送告警，次日重新触发。
内容质量门禁
数据源可达不代表内容有效。聚合后需要过滤：
质量状态：pass（正常输出）、warning（部分来源缺失，在输出顶部说明）、blocked（有效条目不足，不推送正文，只推送说明）。
输出结构
聚合完成后，输出一份结构固定的热点清单，方便博主快速扫描和判断：
```text
📋 AI 热点选题日报 — 2026-07-10
【今日概况】
有效条目：18 条 | 来源：5/5 | 运行时间：09:02
━━━━━━━━━━━━━━━━
🔥 高热度（适合快速蹭热点）
1. [模型名称] 发布，[核心能力] — 来源：AIHOT + GitHub
热度指数：★★★★★ | 建议角度：功能测评 / 使用教程
2. [工具名称] 开源，[功能描述] — 来源：GitHub热门项目
热度指数：★★★★ | 建议角度：上手教程 / 对比测评
━━━━━━━━━━━━━━━━
📈 潜力方向（适合深度分析）
3. [话题] 引发讨论 — 来源：微信公众号
热度指数：★★★ | 建议角度：观点分析 / 案例拆解
━━━━━━━━━━━━━━━━
⚠️ 数据来源说明
蜜度热搜榜：正常 | GitHub：正常 | 微信：正常
多引擎搜索：正常 | AIHOT：正常
```
输出格式固定后，博主可以在 5 分钟内完成选题判断，而不是每次重新整理格式。
推送目标与幂等
每次运行的输出需要推送到固定位置。常见推送目标：
| 推送目标 | 适用场景 | 注意事项 |
|-|-|-|
| 飞书群消息 | 团队共享选题 | 记录 message ID，避免重复推送 |
| 个人飞书通知 | 个人使用 | 同上 |
| 飞书文档（追加） | 保留历史记录，便于回溯 | 每日一条，按日期追加，不覆盖历史 |
| 邮件 | 跨平台通知 | 记录发件 ID |
幂等原则：如果某次任务因推送失败而重试，不应重复发送已成功推送的内容。每次运行生成唯一批次 ID（如 `ai-hotspot-2026-07-10`），推送成功后记录状态，重试时检查状态跳过已完成步骤。
超时和重试策略
| 失败类型 | 是否重试 | 策略 |
|-|-|-|
| 数据源 API 超时 | 是 | 等待 10 秒后重试一次，仍失败则标记缺失 |
| GitHub API 限流（429） | 是 | 按响应头中的 Retry-After 等待，最多等待 2 次 |
| 认证失效（401/403） | 否 | 转人工处理，不自动重试 |
| 推送目标不可达 | 是 | 指数退避重试 2 次，失败则告警并保留结果 |
| 聚合结果为空 | 否 | 进入 blocked 状态，推送说明，次日重新触发 |
重试只针对临时性故障，不对输入问题或配置问题重试。
断点续跑
每次运行生成状态文件，记录已完成的步骤和产物：
```json
{
"batch_id": "ai-hotspot-2026-07-10",
"trigger_time": "2026-07-10T09:00:00+08:00",
"state": "delivering",
"completed": ["fetching", "aggregating", "filtering"],
"source_status": {
"wechat": "ok",
"midu": "ok",
"github": "ok",
"multi_search": "ok",
"aihot": "ok"
},
"item_count": 18,
"last_error": null,
"updated_at": "2026-07-10T09:02:14+08:00"
}
```
推送失败后重试，从 `delivering` 步骤继续，不重新抓取和聚合。
告警要可行动
自动化任务失败时，告警内容必须包含足够信息，让收到告警的人能够立即判断如何处理：
```text
⚠️ AI 热点选题任务告警
批次：ai-hotspot-2026-07-10
状态：Blocked
触发时间：09:00
失败原因：所有数据源均返回空结果或超时
已完成步骤：fetching（部分失败）
影响：今日热点清单未生成，未推送
建议处理：
1. 检查各数据源 API 状态
2. 如为临时故障，可手动触发一次任务重跑
3. 如需跳过今日，确认后标记为已处理
恢复入口：WorkBuddy → 自动化任务 → 手动运行
```
"任务失败，请查看"不足以让人处理。
降级交付
当部分数据源失败，不应等待全部就绪再输出：
降级结果必须显式标记来源覆盖情况，不伪装成完整运行。
日志
每次运行记录：
日志不记录热点内容正文（避免日志过大）。
成本预算
选题任务的主要成本来源：
| 成本项 | 说明 |
|-|-|
| WorkBuddy 调用次数 | 每次运行调用五个 Command，按平台计费规则计算 |
| 外部 API 调用 | GitHub、热搜榜等数据源的 API 调用费用 |
| 模型推理 | 聚合和过滤阶段的 LLM 推理 |
| 推送服务 | 飞书等推送 API 的调用 |
设置预算上限：单次运行超过设定成本时，记录告警并继续运行，但下一次运行前需确认。
自动化任务定义模板
以选题任务为示例，记录完整的自动化任务定义：
```text
任务名称：AI 热点选题日报
触发方式：每天 09:00（工作日）
触发条件：无前置检查，定时直接运行
Prompt：[完整 Prompt 文本]
数据源：@wechat-article-search / @蜜度热搜榜 / @GitHub热门项目 / @多引擎搜索 / @AIHOT
质量门禁：有效 AI 相关条目 ≥ 5 条；数据源可用数量 ≥ 3 个
输出格式：结构化热点清单（含来源、热度、建议角度）
推送目标：[飞书群 / 个人通知 / 飞书文档追加]
幂等控制：批次 ID = ai-hotspot-{date}，推送成功后标记，不重复推送
重试策略：数据源超时重试 1 次；推送失败退避重试 2 次；其他失败转人工
告警接收：[个人飞书通知]
owner：[博主本人]
停用方式：WorkBuddy 自动化任务管理页 → 暂停
```
上线前演练
正式开启定时任务前，手动模拟以下场景，确认任务行为符合预期：
| 场景 | 预期行为 |
|-|-|
| 所有数据源正常 | 输出完整清单，推送成功 |
| GitHub API 限流 | 退避重试，仍失败则标记缺失，继续聚合其他来源 |
| 当日无 AI 相关热点 | 有效条目不足，输出说明，不推送空清单 |
| 推送目标不可达 | 重试 2 次，失败则告警并保留结果 |
| 重复触发（手动触发与定时同时） | 检测批次 ID，跳过重复执行 |
演练通过后再开启定时运行。
运行指标
稳定运行后，定期检查以下指标：
指标出现持续下降时，检查对应数据源或推送配置是否发生变化。
从个人自动化到团队服务
个人选题任务运行稳定后，可以扩展为团队共享：
| 维度 | 个人使用 | 团队服务 |
|-|-|-|
| 推送目标 | 个人通知 | 团队飞书群 |
| 选题方向 | 单一方向 | 多方向分类推送 |
| 审核流程 | 个人判断 | 主编确认后分发 |
| 故障处理 | 自己处理 | 有 owner 和备份处理人 |
| 成本归属 | 个人账户 | 团队预算 |
扩展为团队服务时，需要补充：明确 owner、建立运行手册、设置权限（谁能修改 Prompt 和推送配置）、制定变更流程（修改数据源需测试后生效）。
自动化的高级形态，不是完全没有人，而是正常路径少打扰人，异常路径能及时找到正确的人。
选题任务的迭代优化
自动化任务上线后，根据实际使用反馈持续迭代：
Prompt 优化：根据哪类条目真正被采用、哪类被忽略，调整过滤维度和描述。修改 Prompt 后需手动运行三次确认效果再重新保存自动化配置。
数据源调整：某个数据源长期质量差或可用率低，考虑替换或降低其权重。
输出格式迭代：根据筛选习惯调整清单格式（如增加"本周已覆盖"标记，避免重复选题）。
时间调整：根据实际使用习惯调整触发时间（如改为 8:30 或 10:00）。
每次调整都是一次小型配置变更，遵循"改 → 手动验证 → 重新保存"的流程，不直接在定时任务上实验。