PART 03

进阶篇

从案例到系统,构建你的工作流

CH.22 第 22 章 打造skill:将书和视频蒸馏为可执行 Skill

进阶篇 - WorkBuddy高级玩法与技巧

制作skill,除了把自己的SOP沉淀为skill外,给大家推荐一个更简单方便的办法。

可以使用cangjie-skill把知识蒸馏成skill。

cangjie-skill 开源项目(v1 蒸馏书,v2 增加视频蒸馏),以及 Andrej Karpathy 关于 LLM 个人知识库的思路。

本章回答:如何将书本和视频中的方法论转化为 Agent 可自动调用的 Skill,以及这与 RAG 检索的本质差别在哪里。

问题起点:知识读了但用不起来

AI 在训练时已经摄入了大量经典著作,但在实际问答中,它往往输出"正确的废话"——每个字都对,但缺乏针对特定问题的可落地步骤。这不是幻觉问题,而是调用机制问题:AI 知道书里有什么,但不知道该在什么场景下主动调出哪个框架。

人类读者面临同样的问题。读完一本书,笔记做了、金句划了,合上书以为升级了。两周后遇到真实问题,那些方法论却抓不住。知识在记忆里,但激活路径不清晰。

知识精馏要解决的,就是这个"学了用不上"的问题。

知识精馏的定义

知识精馏(Knowledge Distillation for Skills)是指:从书本或视频中,提取出具有独立触发条件和执行步骤的原子化知识单元(Skill),使 Agent 在遇到对应场景时能够自动激活并给出可落地的行动路径。

化学中的精馏是按沸点将混合物分离成不同纯净组分。知识精馏按"框架 / 原则 / 案例 / 反例 / 术语"五个维度,将书或视频中的知识分离成不同类型的纯净组分,然后只把真正有用的提纯成可执行的 Skill。

知识精馏不是:

  • 摘要(压缩原文)
  • 读书笔记(结构化原文)
  • RAG 索引(存储原文片段供检索)

知识精馏是:将方法论转化为 Agent 能够在真实场景下自动调用的执行单元。

六阶段蒸馏 SOP

cangjie-skill 使用六个阶段将一本书或一组视频蒸馏成一套 Skill。

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 之间的关系,形成知识网络:

  • 依赖:Skill A 的执行需要先调用 Skill B 的输出;
  • 对比:Skill A 和 Skill B 适用于相似场景但方向相反;
  • 组合:Skill A 和 Skill C 联合使用效果更好。

链接层让 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)。视频与书的区别在于:需要先完成"视频 → 文字"的转换,再进入六阶段 SOP。

视频获取与转写

整体流程:

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 消耗密集型任务,主要来源于:

  • 阶段 0 的全书上下文理解(长上下文);
  • 阶段 1 的五个 Agent 并行调用;
  • 阶段 2 的三重验证(多轮推理);
  • 阶段 5 的压力测试(多组测试用例)。
场景大致 Token 消耗大致耗时参考
蒸馏一本普通书数万至十余万 Token30–90 分钟
蒸馏 26 集课程视频(4 小时)较高约 1 小时
蒸馏 4 个主题视频(80 分钟)中等约 40 分钟

模型选择建议

  • 任务拆解和蒸馏协调:使用推理能力强的模型负责 Agent 编排;
  • 并行提取和验证:可使用性价比高的 Coding 模型执行;
  • 长上下文场景:选择原生支持长上下文的模型,避免因上下文截断导致蒸馏不完整。

【图片占位: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 小时)为例:

  • 蒸馏耗时:约 1 小时
  • 产出:25 个 Skill
  • 特点:全部为时效性内容,AI 未经训练,蒸馏后可直接在对应场景下被 Agent 调用

总结:知识精馏在技能包体系中的位置

知识精馏是 Skill 的一种生产方式。它和第 25 章讨论的 SOP → Skill 封装流程是并行的:

来源适用场景
从业务流程提炼(SOP → Skill)企业内部操作规范、重复性业务流程
从书本 / 视频蒸馏(知识精馏)专家方法论、经典著作、高价值课程内容

两者产物格式一致,都是带有触发条件的可执行 Skill,可以在同一个 Agent 框架下混合使用。

CH.23 第 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

CH.24 第 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 团队分工处理。

工序设计

产品宣传片专家团的完整工序如下:

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
我希望你做一个产品宣传片,具体的话,是宣传腾讯的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 确认后才写分镜、分镜确认后才生成素材、素材就绪后才剪辑、成片完成后才配乐合成。

并行计划必须标明汇合点。素材和剪辑可以并行准备,但最终合成必须等待所有素材就位。

主理人的职责

主理人(制片人)是工作流控制器:

  • 解释用户任务并维护子任务状态;
  • 分发最小必要上下文给各角色;
  • 检查上游产物是否满足交接格式;
  • 决定并行、等待或重试;
  • 在关键节点(如分镜确认、BGM 选择)请用户拍板;
  • 汇总所有产物,执行最终合成;
  • 对成片做一致性检查(画面、字幕、BGM 节奏是否对齐)。

三个必须由人确认的点

  1. Brief 确认:产品定位、目标用户、核心卖点是否准确;
  2. 分镜确认:叙事结构、镜头数量、节奏是否符合预期;
  3. BGM 选择:情绪风格是否与成片调性匹配。

Agent 负责生成和执行,不能替代品牌方向和风格判断。

产品化路径:从自建到预置专家团

自建团队

将上述角色封装为一套 Skills,在 Agent 框架中自行编排。适用场景:开发者需要完全控制每个角色的提示词、工具权限和交接格式。门槛包括:定义角色职责、设计交接格式、调试并行与串行逻辑。

预置专家团

WorkBuddy 专家团将上述分工产品化:团长负责任务拆解和分配,团员并行执行,用户只需描述任务。

创建专家团也很简单在专家->我的专家->创建专家

就会跳转到workbuddy的对话框,根据它给定的格式即可快速创建属于自己的专家。

当前专家团覆盖的典型场景:

场景类别代表专家团
内容创作产品宣传片、爆款内容创作、全域分发
软件研发软件开发、代码测试
商业分析深度研究、投资分析、数据分析
业务支持SEO、销售、营销、财税合规、HR
法律合规中文法律

两种路径的选择

维度自建 Skills预置专家团
适用人群开发者,需要深度定制一人公司,直接使用
上手门槛高(需定义角色、调试流程)低(描述任务即可)
灵活度高(可修改任意环节)中(支持自定义模型接入)
速度取决于搭建时间即开即用

质量影响因素

成片质量主要受以下因素影响:

  • Agent 底座模型:Agent 模型的指令跟随和推理能力直接影响分镜质量和任务拆解准确性;
  • 图像生成模型:影响产品截图的清晰度和概念图的视觉质量;
  • 用户提供的素材:提前放入素材空间(图片、视频)可显著提升成片质量;
  • 浏览器工具接入:若 Agent 具备浏览器操作能力,可自动抓取官网截图和产品界面,减少人工准备。

全自动方案适合快速出片(开源项目介绍视频、产品演示视频等)。对品质要求高的场景,建议以 Agent 产物为基础再做一轮人工二次剪辑。

失败传播控制

角色失败降级方式
Brief 角色无法获取产品信息用户补充基础信息后重试
素材生成失败使用用户预置素材或标记空缺位置
剪辑渲染超时交付已完成的片段和分镜表
BGM 生成失败提供推荐 BGM 类型描述,由用户自选
主理人合成失败交付各角色产物清单,由用户手动合成

降级交付必须说明缺失内容,不伪装成完整成果。

多 Agent 任务 Brief 模板

text
目标:为 [产品名称] 制作一支 [时长] 的产品宣传片。
风格:[参考风格,如 Apple 风、极简风]。
素材:[素材空间路径或已提供的图片/视频]。
角色:主理人、Brief、分镜师、素材师、剪辑师、配乐师。
确认节点:Brief 完成后、分镜完成后、BGM 选择时,需用户确认后继续。
模型:Agent 模型 [指定];图像生成模型 [指定]。
全自动/半自动:[说明是否需要中间节点人工介入]。
CH.25 第 25 章 自动化工作流的可靠性

第 25 章 自动化工作流的可靠性

以"每日 AI 热点选题聚合"为贯穿案例,说明自动化工作流在从手动运行到定时可靠执行的过程中,需要处理哪些问题。

案例背景:内容博主的每日选题任务

AI 内容领域更新速度快,每天需要从多个信息源中筛选当日值得写的选题。手动逐一翻阅各个平台耗时且容易遗漏。一个典型的 AI 博主选题需求如下:

text
我是一名 AI 领域的博主,主要内容方向是 AI 教程、AI 工具、AI Coding、AI 测评等。
帮我找今日的 AI 领域热点,方便筛选当天的选题内容。
来源:
- 微信公众号近期爆款文章(@wechat-article-search)
- 蜜度热搜榜 AI 相关条目(@蜜度热搜榜)
- GitHub 今日热门 AI 项目(@GitHub热门项目)
- 多引擎 AI 新闻聚合(@多引擎搜索)
- AI 热点追踪(@AIHOT)

手动运行一次这个任务,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 限流、推送目标不可达。

将任务设计成状态机,每个状态都有明确的成功条件和失败出口:

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 状态并推送告警,次日重新触发。

内容质量门禁

数据源可达不代表内容有效。聚合后需要过滤:

  • 相关性:条目是否真正属于 AI 领域(排除泛科技话题的噪音);
  • 时效性:内容日期是否为当日(排除过期热点被重新推送的情况);
  • 重复性:同一事件是否已在多个来源出现,合并展示;
  • 最低数量:有效条目少于 5 条时,视为当日 AI 热点不足,在输出中标注。

质量状态: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 → 自动化任务 → 手动运行

"任务失败,请查看"不足以让人处理。

降级交付

当部分数据源失败,不应等待全部就绪再输出:

  • 3 个及以上来源正常 → 输出清单,顶部标注哪些来源缺失;
  • 2 个来源正常 → 输出简化清单,标注数据不完整;
  • 1 个或 0 个来源正常 → 不输出正文,只推送说明和告警。

降级结果必须显式标记来源覆盖情况,不伪装成完整运行。

日志

每次运行记录:

  • 批次 ID 和触发方式(定时 / 手动);
  • 各数据源响应状态和耗时;
  • 聚合条目数量和过滤后数量;
  • 推送目标和结果(成功 / 失败 / message ID);
  • 总耗时和错误信息;
  • 运行成本(Token 消耗、API 调用次数)。

日志不记录热点内容正文(避免日志过大)。

成本预算

选题任务的主要成本来源:

成本项说明
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,跳过重复执行

演练通过后再开启定时运行。

运行指标

稳定运行后,定期检查以下指标:

  • 按时触发率:09:00 定时是否准时触发;
  • 一次运行成功率:不需要重试的成功比例;
  • 数据源可用率:各来源的单独可用比例;
  • 有效条目数量趋势:监测 AI 热点信息量的波动;
  • 推送成功率:推送不丢失的比例;
  • 单次运行成本:追踪成本变化趋势。

指标出现持续下降时,检查对应数据源或推送配置是否发生变化。

从个人自动化到团队服务

个人选题任务运行稳定后,可以扩展为团队共享:

维度个人使用团队服务
推送目标个人通知团队飞书群
选题方向单一方向多方向分类推送
审核流程个人判断主编确认后分发
故障处理自己处理有 owner 和备份处理人
成本归属个人账户团队预算

扩展为团队服务时,需要补充:明确 owner、建立运行手册、设置权限(谁能修改 Prompt 和推送配置)、制定变更流程(修改数据源需测试后生效)。

自动化的高级形态,不是完全没有人,而是正常路径少打扰人,异常路径能及时找到正确的人。

选题任务的迭代优化

自动化任务上线后,根据实际使用反馈持续迭代:

Prompt 优化:根据哪类条目真正被采用、哪类被忽略,调整过滤维度和描述。修改 Prompt 后需手动运行三次确认效果再重新保存自动化配置。

数据源调整:某个数据源长期质量差或可用率低,考虑替换或降低其权重。

输出格式迭代:根据筛选习惯调整清单格式(如增加"本周已覆盖"标记,避免重复选题)。

时间调整:根据实际使用习惯调整触发时间(如改为 8:30 或 10:00)。

每次调整都是一次小型配置变更,遵循"改 → 手动验证 → 重新保存"的流程,不直接在定时任务上实验。

23-26 / 28
< Previous案例篇 Next >岗位与行业落地