Workflow Designer 的设计哲学

英文版：The Design Philosophy of Workflow Designer

为什么我要为 Agent 驱动的项目做一个开源“宪法生成器”？以及，世界上最贵的模型到底该用在哪儿？

两百美元的启示

Anthropic 最新旗舰模型重新上线后，总有人问我同一个问题：这玩意儿到底该怎么用？ 它确实聪明绝顶，但也贵得离谱。我订阅了顶配的 200 美元/月套餐（20 倍速率），仅仅高强度用了一小时，就烧掉了整整一周额度的 10%。把这种级别的模型塞进流水线的每个环节，既烧不起，也没必要。

那它真正的用武之地在哪？

花了两个小时精心测试后，答案浮出水面：

最聪明的模型不该是你工作流里的打工仔，而应该是工作流的设计师。

把它当作工作流架构师。让它去设计、审计、升级整套系统，然后让那些便宜的模型和确定性代码去跑上一千次。设计是一次性投入，收益却会复利增长；执行是持续性开销，必须锱铢必较地压缩成本。好钢要用在刀刃上，最贵的 Token 要花在杠杆率最高的地方。

正是基于这个原则，我构建了 Workflow Design Bible。这是一个开源的元提示词（Meta-prompt），能在一次对话中把任何项目转化为结构完整、由 Agent 驱动的公司。这篇文章想聊的，就是它背后的设计哲学。

工作流即公司

核心心智模型很简单：自主工作流就是一家公司，主 Agent 就是 CEO。

CEO 不干体力活。它的职责是编排、监督、审核，以及向董事长（也就是你）汇报。所有固定、可重复的工作环节，都要分派给具体的“员工”。一旦建立起这种视角，组织设计里的经典问题就会接踵而至，而且必须白纸黑字写清楚：

• 公司的根本大法是什么？（Constitution）
• 公司具体生产什么？步骤如何衔接？（Workflow）
• 谁在这里工作？各自负责什么？（Roles）
• 员工们共享哪些培训手册？（Skills）
• 车间里跑着什么机器？（Functions & CLI tools）
• 班次之间如何交接？（Handover documents）

如果工作流只存在于模型的“脑子”里，每次会话都即兴发挥，那它就不是公司，只是个患有失忆症的自由职业天才。工作流设计的核心，就是把知识从模型的工作记忆中剥离出来，固化成一套文档系统，让任何合格的 Agent 都能据此启动。

宪法：稳定的根本大法，而非日常政令

每个生成的项目都以 CONSTITUTION.md 开局。这个名字是刻意选的。宪法是几乎永不更改的文件：它定义了使命、按优先级排序的底线原则（比如“账号安全 > 质量 > 数量 > 速度”）、能让整个项目停摆的红线，以及明确的“禁止事项”——分为“严禁”和“不建议”两类。

系统里其他一切都可以随会话迭代，唯独宪法是演化的锚点。当 CEO 在凌晨三点面临模糊决策、又找不到人类请示时，宪法就是它最后的依归。

工作流主干：从第零步到最后一步

紧跟宪法之后的是 WORKFLOW.md：这是流水线的主干，从第零步一直描述到最后一步。每一步都要声明三件事：做什么、产出什么、由哪个角色主导。

有两个细节比想象中更重要：

1. 步骤间传递的是“句柄”，不是“载荷”。 步骤之间只传 task_id 和必要的最小索引，绝不在聊天窗口里粘贴大段文本。每个执行者自行从磁盘读取输入。这样既能保持上下文窗口精简，又能实现步骤间的真正解耦。

2. 并发要在接缝处声明，而不是在执行者身上。 有些步骤天然独立，可以并行展开（比如稿件就绪后，编译、封面设计、文案撰写可以同时启动）。有些步骤是同构批处理（比如六十张场景图，五十张同时跑）。还有些角色纯粹是为了权责清晰，永远单线程运行。工作流文档必须在分流点明确标注这些区别。并行是流水线的架构属性，不是临场发挥。

角色：内部员工与外部承包商

这里有个关键区分，多数 Agent 框架都忽略了：为你工作的不一定都是你的员工。

在我的流水线里，Claude Code 的子 Agent 是内部员工。CEO 可以原生调度它们——共享运行时、遵循相同的工具约定、结果在进程内返回。但 Codex 是外部合作伙伴。它具备内部员工没有的能力（比如所有插画工作都归它），我也没法像调度员工那样直接指挥它。双方沟通要走正式协议：基于文件的桥接、描述交付物的书面合同、唤醒通知，以及最终的书面报告。

内部员工和外部承包商在关键维度上截然不同：

ROLES.md 必须显式划定这条界限。每个内部角色都有系统提示词，定义它是谁、负责哪个工作流步骤，以及最关键的一点：主要使用哪些技能。子 Agent 虽然能看到环境里的几十个技能，但看到不等于有权使用。每个角色的章程都会刻意收窄工具箱，就像职位描述会让会计远离喷漆车间一样。

技能：共享的培训手册

技能位于角色之下，两者是多对多关系：不同子 Agent 可以共享同一项技能，一个子 Agent 也能掌握多项。技能就是针对某项能力的培训手册——如何发布博客、如何执行图像生成合同、如何通过质量关卡——包括底层用了哪些工具。

这种分层防止了系统坍塌成一个巨型提示词。CEO 知道派谁去；角色知道用哪本手册；手册知道怎么实现能力；最底下才是具体的机器设备。

地基：Python 函数

在整个技术栈的最底层——CEO 之下、角色之下、技能之下——是纯函数。在我的项目里，它们是 Python 代码。它们是整个架构最基础的元素，也最被低估。

宏观层面的分工原则如下：

LLM 负责创造与决策。代码负责执行。

在两件过去必须由人完成的事上，大语言模型是人类造出的最强工具：创造（写剧本、设计场景、构思图像提示词）和决策（步骤失败怎么办、质量是否达标、模糊情况如何处理）。除此以外的一切——渲染、编译、上传、重试、文件管理、格式转换——都该交给确定性函数：严格按代码执行，快速、廉价、每次结果一致。

即便是小函数的组合，也不该让模型每次即兴发挥。高阶流水线函数会把原子模块确定性地串联起来。模型的参与范围被压缩到极窄的高价值切片：创作内容、在检查点做判断、决定异常处理方案。决策一旦做出，代码立刻接管。

这赋予了系统美妙的长期动态：每一个重复出现的决策，都是下沉为函数的候选者。 如果 CEO 发现连续五次会话都以相同方式做了相同判断，那就不再是决策，而是规则，规则就该写进代码。我的项目会定期运行自审计，专门做这件事：找出模型还在“实时”处理、但本应固化为确定性 CLI 的逻辑。随着时间推移，工作流会在设计层面变得更便宜、更快、更可靠，因为智能在不断下沉到基础设施中。

这也回应了文章开头的成本问题。贵模型设计公司，中端模型充当员工，函数负责运行。层级越低越便宜、越确定，架构的使命就是把尽可能多的工作推向底层。

文档系统即公司操作系统

把上述一切整合起来，就得到一套固定的、命名的文档集，每个项目都共享：

• CONSTITUTION.md — 法律：原则、优先级、红线、禁止事项。
• WORKFLOW.md — 主干：每个步骤、产出、负责人、分流点。
• ROLES.md — 组织架构：内部名册、外部伙伴、技能分配。
• Playbooks — 专题 SOP：质量关卡、合规、定价。
• NEXT_SESSION.md — 班次交接，每次结束时完整重写。
• IDENTITY.md / SOUL.md — Agent 的身份认同，以及随时间成长的性格。
• STRUCTURE.json — 机器可读的清单，记录文档声称存在的一切。

根指令文件（CLAUDE.md、AGENTS.md，或运行时读取的任何文件）刻意保持精简——只作启动路由器，指向上述文档。写在根文件里的内容，每一轮对话都要携带；写在命名文档里的内容，每个会话只加载一次。知识相同，成本却只是零头。

鉴于文档可能与现实脱节，每个项目都自带确定性的 doctor 命令，比对清单与实际文件系统，发现不一致就大声报错。宪法即代码：声明必须等于现实，由机器验证，而非靠良好意愿。

最后，每个会话都遵循生命周期——/start-session 从文档启动，执行工作，/finalize-session 进行反思、更新活文档、重写交接记录、运行 doctor。不执行 finalize，就没有闭环。 反思不是可有可无的收尾，而是公司学习的机制。

为什么做成 Bible

当我为内容频道、电子书出版社、游戏工作室分别重建了这套结构后，模式已显而易见——如此稳定的模式理应被生成，而非手工打造。

Workflow Design Bible 就是那个生成器。它是一个可复用的元提示词：通过访谈了解你的项目——使命、红线、品牌、流水线步骤、角色、资质——然后一次性搭建整个公司：宪法、工作流主干、组织架构、文档系统、会话生命周期、清单。它不写业务代码，也不部署任何东西。它只做聪明模型真正该做的事：设计公司，以便让比它便宜的一切去运行公司。

这就是设计哲学。角色分工明确，法律条文清晰，执行下沉至代码，智能保留给创造与判断——而这一切在第一天就完整文档化地诞生。

Workflow Design Bible 基于 MIT 协议开源：github.com/preangelleo/workflow-design-bible。