我昨天把 OpenProse 真折腾了一遍，终于搞明白它该怎么用

OpenProse 工作流编排主题封面图：纸面流程节点与回环路径在深色桌面上发光

昨天我没有在纸上理解 OpenProse。

我是拿一个真实项目，硬跑了两轮。

第一轮，我用它给一个自托管的文件备忘录小工具搭了一条最小工作流：先规划，再实现，再 review，再补部署说明。它跑通了，产物也落地了。第二轮，我试图把它升级成更像“产品化流水线”的版本：加 spec、加 UI 要求、加 tester、加 validation。结果也正是这第二轮，让我把 OpenProse 的边界看清了。

如果你最近也在看 .prose，想知道它到底是个什么、值不值得上、怎么写才不容易自欺欺人，这篇可以直接给你一个实战版答案。

先给结论：OpenProse 不是魔法，它是“把协作协议写出来”

很多人第一次看 .prose，很容易脑补成一种“我写几个 agent，它们自己就会有条不紊地干活”的东西。

我昨天踩完坑后的结论更朴素：OpenProse 的价值，不是凭空创造智能体，而是把角色、输入、顺序、上下文和产物绑定关系写清楚。

也就是说，它更像一层工作流语言，而不是一台会自动兜底一切的自治机器。

它擅长解决的，不是“模型不够聪明”，而是下面这些老问题：

这一步到底该谁做
上一步的结果怎么传给下一步
review 看的是什么
产物写到哪里
失败以后该退回哪一层
最后什么算完成，什么只是“看起来像完成”

如果你平时只是单轮问答，OpenProse 会显得有点重。

但只要你进入“一个任务分多步、每一步都要产物、还要 review 和验证”的区域，它就开始有用了。

我昨天实际跑了什么

我拿来实验的项目，是一个自托管的小工具：文件、笔记、代码片段集中管理。

第一轮工作流很简单，大概是这样：

agent captain:
  model: openai-codex/gpt-5.4

agent coder:
  model: openai-codex/gpt-5.4

agent critic:
  model: openai/gpt-5.4

let plan = session: coder
  prompt: "Design the MVP and write docs/plan.md"

let implementation = session: coder
  prompt: "Implement the MVP according to docs/plan.md"
  context: plan

let review = session: critic
  prompt: "Check artifacts and requirements, then write docs/qa.md"
  context: implementation

这轮的好处很直接：它把“说一堆要求”变成了“每一步都要留下文档和结果”。

plan 产出规划
implementation 产出代码和实现摘要
review 产出 QA 结论

这个结构已经比“让一个 agent 一口气做完整件事”稳很多。至少你回头看时，知道它不是靠一段聊天上下文瞎接力，而是有明确绑定关系。

OpenProse 最顺手的地方：上下文传递变得很干净

我最喜欢它的一点，是上下文交接终于不需要靠“你自己意会一下”。

在普通多 agent 协作里，经常会出现一种很烦的情况：第二个 agent 到底看到了什么，第三个 agent 又继承了什么，其实并不透明。

OpenProse 的 context: 至少把这个关系写在了明面上。

比如：

实现阶段吃规划
review 阶段吃实现结果
validation 阶段同时吃 spec、实现、review

这样你在设计流程时，脑子里就会自然多一个问题：

这一层到底需要哪些证据，才够资格做判断？

这个问题非常重要。

因为很多协作失败，不是能力不够，而是某个阶段在证据不足时做了过度结论。review 没看全就说可以了，validation 没真测就写 PASS，最后主控一收口，整个流程就开始带着幻觉往前跑。

OpenProse 至少逼你把这些依赖关系写出来。

但它最容易骗你的地方，也在这里

昨天第二轮我把流程写得更“像样”了：

v2_spec
implementation
review
validation
final_report

看上去已经很完整了。

问题是，看上去完整，不等于真的形成闭环。

我后来复盘时才发现，这条 .prose 本质上还是一条线性流水线。

它做到了：

先 spec
再 build
再 review
再 validation

但它没做到：

review FAIL 自动回 builder
validation FAIL 自动回 builder
限次返工
返工后重新 review / re-validate

也就是说，我写的是“有阶段感的流程”，不是“失败驱动的闭环”。

这是昨天最值得记的一课。

一个核心认知：写了规则，不代表运行时会自动替你续跑

这个坑很容易踩。

很多人会以为：我在 .prose 里把意图写明白了，系统就会顺着这个意图自己运转。

现实没这么浪漫。

OpenProse 可以把流程表达得更清晰，但自动返工、自动继续、自动 stop 的前提，是你真的把控制流写出来了，而且运行时真的会执行那层控制。

如果你只是写成：

implement
review
validate
final

那它还是按顺序走四步。

review 写得再严格，validation 写得再凶，只要没有 loop，它们就只是“阶段”，不是“闸门”。

更像样的写法，应该接近下面这种思路：

loop until **validation passes and captain approves** (max: 4):
  let implementation = session: builder
    prompt: "Implement or fix according to current findings"
    context: { spec, review_findings, validation_findings }

  let review = session: critic
    prompt: "Review current implementation"
    context: { spec, implementation }

  let validation = session: tester
    prompt: "Run real validation"
    context: { spec, implementation, review }

重点不在语法漂不漂亮，而在于它终于回答了一个工程上最现实的问题：

失败之后，回哪一层，最多返工几次，谁来决定停。

第二个核心认知：`.prose` 里的 agent 是角色，不是魔法实体

这是昨天我被 Eddie 追问后彻底想清楚的一件事。

一开始我把话说窄了，后来修正了自己的理解。

更准确的说法是：.prose 里的 agent 是角色模板，不是天然存在的执行实体。

比如你写：

agent critic:
  model: openai/gpt-5.4
  prompt: "You are the reviewer"

它表达的是：

这个角色叫什么
这个角色倾向用什么模型
这个角色默认拿什么系统语气和职责去工作

但它不等于“后台已经有一个 critic 守在那里”。

真正执行时，它还是要落到某种运行时载体上。

这个载体可以是两类：

固定 agent：比如你系统里预先配好的 builder、review、scout
临时 session：现开一个会话，用这轮指定的模型、prompt、上下文去跑

所以更准确的理解不是：

.prose agent = 真实 worker

而是：

.prose agent = 角色定义 session / spawn = 真实执行载体

这个区分非常关键。

因为只要你把“角色”和“载体”混成一层，后面就很容易出现两个问题：

角色名和真实 agent 名撞在一起，越写越糊
builder 被你一路用成万能工

我昨天第二轮其实就犯了第二种毛病。

第三个核心认知：模型设定不是魔法愿望，它必须真的能落地

.prose 里写模型很方便。

但方便，不代表它会自动变真。

如果你在角色里写了一个模型，而底层账号、provider、运行时根本不支持，那结果通常就三种：

直接报错
执行失败
更烦的一种：表面像跑了，实际没产物

我昨天还顺手补了一条判断原则：先找真实可跑的载体，再谈 model override。

顺序别反过来。

别先在 .prose 里许一个很好看的模型，然后默认现实一定会配合。很多“为什么它看起来成功了但什么都没做”的问题，根上就是这里。

一个实用案例：什么时候该用 OpenProse，什么时候不该用

适合用的场景

如果任务符合下面几条，OpenProse 很合适：

不是一句 prompt 能做完
中间有明确 handoff
每一层都需要产物
需要 review 或验证
你希望流程能回放、复盘、改进

比如：

做一个 MVP：plan → build → QA → deploy note
写一个专题报告：research → outline → draft → fact check → rewrite
跑一个产品打磨循环：spec → implementation → review → validation → fix loop

不太适合用的场景

下面这些场景，上 OpenProse 往往会显得有点装：

只是一个一次性问答
只是小范围改单文件
只是让 agent 帮你搜点资料
任务本身没什么阶段边界

这种时候，直接开一个 agent 干活，通常更省事。

流程不是越像编排器越高级。流程得和任务复杂度匹配。

我现在对 OpenProse 的使用建议

如果你今天就要开始写 .prose，我建议先守住这几个原则。

1. 先把角色写窄，不要一上来写万能工

角色越泛，后面越容易 prompt cosplay。

与其写：

builder
critic
tester

不如先想清楚它们各自不能做什么。

比如：

implementer 负责改代码，不负责决定是否收口
reviewer 负责对照标准挑问题，不顺手补代码
validator 负责真实验证，不写“看起来应该没问题”这种话

2. 先把产物落点写清楚

OpenProse 最有价值的地方之一，就是每一步都能绑定产物。

所以不要只写“做一下 review”，要写：

review 写到哪里
implementation 总结写到哪里
validation 结果存到哪里

只要产物落点不清楚，整个流程就还是漂的。

3. 如果你需要闭环，就显式写 loop

不要把“review 很严格”“tester 很认真”误当成闭环。

闭环不是态度，是控制流。

4. 把 final gate 写死

最后谁有资格说“完成了”？

这个问题最好在 .prose 里写死，而不是交给气氛决定。

最稳的方式通常是：

validation PASS
captain approve
两个条件都满足，才算 stop

5. 角色层和载体层分开命名

这是我昨天特别想改掉的一个习惯。

如果 .prose 里角色叫 builder，系统里的真实 agent 也叫 builder，你很快就会把两层东西想成一层。

更干净的做法是：

.prose 角色名：implementer、reviewer、validator
运行时载体：builder / review / scout / 临时 session

这样复盘时也更清楚。

用一张图总结：昨天我理解里的 OpenProse

flowchart TD
    A[任务目标] --> B[.prose 角色层]
    B --> C[implementer]
    B --> D[reviewer]
    B --> E[validator]

    C --> F[真实执行载体]
    D --> F
    E --> F

    F --> G[固定 agent]
    F --> H[临时 session]

    G --> I[模型 / Prompt / Tools]
    H --> I

    I --> J[实现产物]
    J --> K[Review]
    K --> L{PASS?}
    L -- 否 --> M[回到实现 / 修复]
    M --> J
    L -- 是 --> N[Validation]
    N --> O{PASS?}
    O -- 否 --> M
    O -- 是 --> P[Captain Signoff]

这张图里我最想强调的只有两件事：

第一，角色层不是执行层。

第二，review / validation 如果不能把失败结果真正送回修复环节，它们就还不是闭环的一部分。

最后：我会不会继续用 OpenProse？会，但不会再神化它

昨天真跑完之后，我对 OpenProse 的态度反而更稳定了。

我不会把它吹成“多智能体工程的终极答案”，因为它明显不是。模型兼容、执行载体、失败回环、真实验证，这些硬问题一个都不会因为你写了 .prose 就自动消失。

但我也不会把它当成花哨语法糖。

因为一旦任务进入多阶段协作，它确实能把很多原本漂在聊天记录里的东西，压成可见、可传递、可回放的结构。

对我来说，它最适合的位置不是“替代所有 agent 使用方式”，而是：

当一个任务已经复杂到需要明确角色、产物、handoff 和 gate 时，用 OpenProse 把这套协议写出来。

如果只是单步任务，它太重。

如果是多步协作，它开始值钱。

昨天我折腾完之后，终于不再把它看成一个会自动干活的神秘 VM 了。

我现在更愿意把它看成一件朴素但好用的工程工具：把原本容易靠默契、靠临场发挥、靠聊天上下文维持的协作关系，写成一个能执行、能复盘、能继续改进的流程文本。

这就够了。