AI·系统·创造·人将如何自处

workflow（工作流）

10分钟阅读

一句话定义

Workflow 是为了完成一个目标而设计的一条流程。
它把多个步骤、多个角色、多个 skill 串起来，决定先做什么、后做什么、哪里需要人审、哪里可以重跑。

一句人话: workflow 是“流水线”，不是“工人”，也不是“工具”。

为什么重要

大任务整坨丢给 AI，最常见的结果不是“更聪明”，而是“更糊”。因为中间过程没被切开，你既看不清哪一步错了，也没法只重跑其中一步。

workflow 的价值，是把复杂任务拆成可观察、可审计、可替换的步骤。这样你能回答三个关键问题：

  1. 这一步到底该谁做
  2. 失败了该从哪里重来
  3. 哪些地方必须保留人工判断

本仓库最典型的例子就是 raw -> wiki：

  1. 收集原始材料
  2. AI 学者调用 kb-compile
  3. 产出 _candidates/
  4. 陈彬策展
  5. approved 后再搬正式 wiki
  6. 最后 kb-lint 守门

另一个更小的例子来自 Boris 的日常内循环：Plan → Implement → Verify。这说明 workflow 不一定是“大系统工程”，也可以是你每天重复几十次的小流程。

技术机制

workflow 和 agent、skill 不同，它不是一种独立文件类型。你不会在磁盘上找到“这是一个 workflow 文件”的统一格式。

它更像一种编排模式，常见落地方式有：

  • 一份 markdown 步骤单
  • 一个 slash command
  • 一个 orchestrator agent
  • 一组 agent + skill + 人工检查点
  • 非 AI 步骤和 AI 步骤混编

所以 workflow 的技术重点不在“文件长什么样”，而在“顺序和边界怎么设计”。一个靠谱 workflow 通常会明确：

  • 输入是什么
  • 每一步的负责人是谁
  • 哪一步允许 AI 自主，哪一步必须人工确认
  • 出错后从哪里恢复

如果要打比方，workflow 更像 AI 时代的 Apple Shortcuts 或 Zapier，只不过这里的节点不全是确定性脚本，其中一些节点会交给能判断的 AI worker。

最小可跑通例子

最小 workflow 不必上框架，哪怕只是一份明确步骤的 markdown 也能跑：

# publish-note workflow
 
1. 用 [[agent]] 起草初稿
2. 调 [[skill]] 做格式检查
3. 派 [[subagent]] 只读审一遍风险
4. 人工决定是否发布

如果换成本仓库更真实的版本，就是：

  1. raw/ 里有新对话或素材项目
  2. AI 学者读取输入
  3. kb-compile 生成候选和工单
  4. 人工策展 approved / rejected / needs-edit
  5. approved 条目搬到正式 wiki
  6. kb-lint 再做结构和质量守门

这整条链路才叫 workflow；其中任何单个 agent 或 skill 都只是参与者。

常见误解

  • workflow = agent。不是。agent 是一个角色；workflow 是多个步骤的编排。一个 workflow 可以没有 agent，也可以包含多个 agent。
  • workflow 一定要工具化。不是。先写清楚步骤让 AI 按单执行，就是最小可用 workflow。
  • workflow 一定线性。不是。它可以分支、并行、循环，也可以带人工检查点。
  • 只有大系统才需要 workflow。不是。Boris 那种“先 plan 再动手再验证”的日常内循环，本质上也是 workflow。

与其他术语的关系

  • [[agent]]：agent 适合放在需要角色判断的步骤里。
  • [[skill]]：skill 适合承接稳定、重复、可复用的步骤。
  • [[subagent]]：subagent 适合承接读很多文件、会污染主上下文的侧任务。
  • [[CLAUDE.md]]：CLAUDE.md 提供这条流程共享的项目背景、规则和禁区。
  • [[Harness]]：workflow 跑不稳，往往不是模型不行，而是 harness 没把权限、上下文、恢复机制配好。

陈彬视角

从 workflow 倒推 agent，不从 agent 发散出 workflow。这个方向反了，系统就会变成“一堆 agent 各干各的”。

延伸阅读

  • [[agent]]
  • [[skill]]
  • [[subagent]]
  • [[02-基建/平台/claude-code/plan-mode]]
  • [[04-系统/02-机制/raw → wiki 知识沉淀机制]]
  • [[04-系统/02-机制/多 Agent 协作实战]]

🎬 3 个场景（读者最可能用到的情境）

场景 1 · 写作者”选题 → 初稿 → 审校 → 发布”

撰稿人每周两篇稿。workflow 拆成 4 步：选题会（agent 提 5 个方向 · 人挑）→ 初稿（写作 skill）→ 审校（编辑 agent）→ 发布（格式检查 skill + 人工最终批）。每一步可单独重跑。

场景 2 · HR 盘点”抓数据 → 打分 → 生成报告”

季度盘点。workflow：从 HR 系统抓数据（MCP 或 Bash）→ 按指标打分（skill）→ 异常人工核查（人工检查点）→ 生成报告（报告 skill）。哪一步出问题，只重跑那一步。

场景 3 · 散户”收盘价 → 分析 → 复盘记录”

每日内循环。workflow：拉收盘数据 → 让 AI 做持仓/盘面/情绪三维分析（3 个并行 subagent）→ 合并结论 → 写进日记模板。简单但稳定重复。

⚖️ 和最像的邻居比

术语本质区别适用边界
workflow步骤编排（顺序/分支/并行/人工检查点）多步任务需要可观察/可重跑
agent某个步骤里的判断者单一角色，不负责顺序
skill某个步骤里的做法单一能力，不负责编排
Building Effective Agents 里的 “agent”LLM 自主决定流程流程不能预先规定的开放任务

🚫 反例（不该这么用）

反例 1 · 把 workflow 当成一条纯线性 prompt 链

“第一步做 A，然后做 B，然后做 C”全塞进一个 mega-prompt 让 AI 一次跑完。结果中间出错了不知道哪一步，也没法只重跑。正确做法：步骤之间有明确交接物（文件/JSON），每一步可单独重放。

反例 2 · 所有步骤都必须人工确认

每一步都加 “等我确认” 卡点。结果流程比纯手工还慢，AI 的价值没兑现。正确做法：只在”错了很贵 / 不可逆 / 需要判断”的关口放人工检查，其他步骤放手让 AI 跑。

❓ 常见误解

  • 误解 1：“workflow 只能线性” → 实际：workflow 支持分支（routing）、并行（parallelization）、循环（evaluator-optimizer），Anthropic《Building Effective Agents》直接给了 5 种模式。
  • 误解 2：“workflow 一定要用框架（LangGraph 等）” → 实际：一份写清楚步骤的 markdown + 按步骤派 agent/skill，就是合格的 workflow；框架只是规模化后的选项。
  • 误解 3：“有 workflow 就不用 agent” → 实际：workflow 是骨架，agent/skill 是填在骨架每个节点上的执行体，互补不互斥。

🧬 历史坐标（最早谁提 · 本质 · 分型 · git）

最早谁提

“Workflow” 是计算机界古老概念（BPM、工作流引擎）。LLM 语境下的 workflow 严谨定义，是 2024 年 12 月 Anthropic 发布《Building Effective Agents》时划出的分界线：把 “workflow（编排好的 LLM + 工具路径）” 和 “agent（LLM 自主决定流程）” 明确区分开。博客：https://www.anthropic.com/research/building-effective-agents

本质（一句话 · 20 字内）

为完成一个目标预先编排的步骤链路。

分型 / 演化（2-4 行主线）

  • 2022-10 · LangChain “Chains” 首次把 prompt + tool 串成可复用链路
  • 2023 中 · LangGraph 引入图结构，支持分支、循环、并行
  • 2024-12 · Anthropic《Building Effective Agents》给出 5 模式教科书（Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer）
  • 2025+ · workflow vs agent 的选择权下放：先写 workflow，必要时才升 agent

代表 git / 文档

关系图谱

反向链接