用"写文章"这个例子，讲透多 Skill 编排的三种模式
🧭 技术战略上一篇我们聊了多 Skill 编排的三种模式：路由、链式、Agent 化。
反馈最多的一条是：
“概念懂了，但实际怎么用，还是模糊。”
今天换个方式。
不讲客服系统，不讲数据分析，就拿一个大家都能理解的场景——用 AI 写文章——把三种模式从头到尾跑一遍。
一、先拆 Skill：一个 AI 写作系统里有哪些能力模块？
假设你要搭一个 AI 写作助手，帮你在不同平台发内容。
拆一下，大概需要这些 Skill：
| Skill | 职责 |
|---|---|
| 平台识别 | 判断这篇内容发哪个平台 |
| Brief 理解 | 读取写作需求，提取关键信息 |
| 信息调研 | 搜索相关资料，收集素材 |
| 选题生成 | 基于调研结果，给出选题方向 |
| 初稿生成 | 按选定方向写出完整初稿 |
| 事实核查 | 检查文中数据、时间、名称是否准确 |
| 风格审校 | 检查是否符合目标平台的风格要求 |
| 配图生成 | 根据文章内容生成或匹配配图 |
8 个 Skill，每个只做一件事。
问题来了：它们之间怎么配合？
这就是编排要解决的事。
二、路由：第一个问题是“这活该谁干”
用户说了一句：
“帮我写一篇关于 Claude Code 的内容。”
系统收到这句话，第一步不是写，而是判断：
- 这篇发头条号？
- 还是发小红书？
- 还是写成视频脚本？
不同平台，写法完全不一样：
| 平台 | 字数 | 风格 | 配图 |
|---|---|---|---|
| 头条号 | 1500-3000 字 | 深度、有干货 | 5-8 张 |
| 小红书 | 300-800 字 | 轻松、种草感 | 封面很关键 |
| 视频脚本 | 按分钟算 | 口语化、有节奏 | 不需要 |
如果路由错了，后面全白干。
你用小红书的风格写头条号文章，读者觉得太浅。用头条号的深度写小红书，没人看完。
这就是路由的价值：在最前面做一次判断，把请求送到对的流水线上。
实现也不复杂。一个分类 Skill，读用户的输入，判断平台类型，输出一个标签。后面的流程根据标签走不同分支。
- 准确率要求高。错了就是方向性错误。
- 适合用轻量模型。分类任务不需要最强的模型。
三、链式：确定了方向，就上流水线
路由判断完，假设确定了是头条号。
接下来的工作流是固定的，一步接一步：
每一步的输出，是下一步的输入。
这就是链式执行。
拿前三步举例：
Step 1：Brief 理解
输入：用户的原始需求（“写一篇 Claude Code 的使用体验”）
输出：
- 目标平台：头条号
- 内容方向：测评 + 教程
- 核心信息：Claude Code 的实际使用感受
- 字数要求：2000字左右Step 2：信息调研
输入：上一步提取的关键词（Claude Code、使用体验、2026）
操作：搜索 TechCrunch、Reddit、Hacker News，收集最新信息
输出：
- Claude Code 最新版本功能
- 社区真实评价
- 和竞品的对比数据Step 3：选题生成
输入：Brief + 调研结果
输出：3 个选题方向，带大纲和工作量评估
看到了吗？每一步做的事很单一，但串起来就完成了从“一句话需求”到“可执行选题”的转化。
链式的好处，说白了就是可控。
出了问题，你能精确定位是哪一步出的错：
- 选题不好？调研 Skill 的问题，搜索词不对。
- 初稿跑题？Brief 理解 Skill 的问题，关键信息提取有误。
- 数据错误？事实核查 Skill 没拦住。
每个环节都可以单独优化、单独测试、单独替换。
这比把所有要求塞进一个 Prompt 里让模型“一步到位”，稳定太多了。
四、Agent 化：链式搞不定的，交给它
链式好归好，有个前提：每一步都得顺利通过。
但现实不是这样的。
举个例子。初稿写完了，进入事实核查环节。核查 Skill 发现：
“文中提到 Claude Code 于 2025 年 3 月发布，但实际发布时间是 2025 年 5 月。”
这时候怎么办？
如果是纯链式，核查 Skill 只能标记“未通过”，然后整个流程停住，等人来处理。
但如果系统具备 Agent 能力，它可以自己决定下一步：
- 把错误信息回传给初稿生成 Skill
- 让它修正相关段落
- 修正后重新进入事实核查
- 核查通过，继续往下走
整个过程不需要人介入。
再来一个场景。风格审校 Skill 发现初稿“AI 味太重”：
“检测到 6 处典型 AI 套话，包括’在当今XXX的时代’’值得注意的是’等。”
Agent 会怎么做？
- 定位具体问题段落
- 调用风格改写 Skill 逐段修改
- 改完再过一遍审校
- 还有问题？再改一轮
- 直到审校通过
这就是 Agent 化的本质：
不是按固定路线走，而是根据结果决定下一步。
它和链式最大的区别在于：链式是“直线走到底”，Agent 是“走一步看一步，不行就回头”。
Agent 化的代价也很明显：
- 每多循环一次，就多一次模型调用，成本上去了
- 如果没设终止条件，可能死循环（改了五轮还是 AI 味）
- 排查问题更难，因为执行路径不固定
所以不是所有环节都需要 Agent 化。
五、实际系统：三种模式混着用
真实的 AI 写作系统，不会只用一种模式。
最合理的架构是这样的：
第一层：路由
用户请求进来，判断平台，分流到对应的写作流水线。
这一层用路由。快，成本低。
第二层：链式
每个平台有自己的标准流程：Brief → 调研 → 选题 → 初稿 → 审校 → 配图。
主流程用链式。稳定，可调试。
第三层：局部 Agent 化
在容易出错的环节——事实核查、风格审校——加入自动重试和自我修正循环。
这些环节用 Agent。灵活，能自我纠错。
这就是上篇文章结尾说的那句话：
结构化工作流 + 局部 Agent 化。
用写文章的例子走一遍，是不是就具体多了。
六、从写作系统看通用设计原则
虽然今天用的是写文章的例子，但背后的设计思路是通用的。
路由放在最前面
不管什么系统，第一步都是分流。
客服系统分流问题类型，写作系统分流目标平台，电商系统分流售前售后。
路由决定了后面所有流程的方向。所以路由的准确率，往往比后面任何一个 Skill 都重要。
链式覆盖主流程
80% 的场景，标准流水线就够了。
不要一上来就 Agent 化。先把链式跑通、跑稳，再考虑哪些环节需要加 Agent 循环。
Agent 只用在“会出错”的环节
Agent 的价值是自我纠错。
如果一个环节几乎不会出错（比如 Brief 理解），没必要 Agent 化。
如果一个环节经常需要反复调整（比如风格审校），那就值得加上 Agent 循环。
判断标准很简单：
这个环节失败后，能不能自动修复？如果能，就值得 Agent 化。
七、结语
回到最开始的问题：路由、链式、Agent 化，到底怎么用？
用一句话总结：
- 路由解决“谁来干”
- 链式解决“怎么干”
- Agent解决“干错了怎么办”
三者不是互斥的，而是分层配合的。
好的 AI 应用，不是把最强的模型丢上去就行。而是在每个环节，用对的模式、对的模型、对的策略。
这才是编排的意义。