我曾经体验过一个被称作 ultrawork 的实验性工作流：模型没有直接处理任务，而是先写出一段 JavaScript，再由脚本安排多个 Agent。这个名字对应的安装方式、触发词和运行时约定，在当前可核验的公开仓库里没有权威说明。因此，本文不提供安装命令，也不把那次体验写成仍然可用的产品教程。
值得保留的是背后的工程问题：能不能把多 Agent 的“指挥官”从 LLM 的临场判断里拿出来，交给可审查的代码？
Token 税：多 Agent 系统的隐疾
之前所有人都怎么搞多 Agent？一个主 Agent（LLM）当编排器：决定派哪个 sub-agent、收到结果后再决定下一步、所有中间产物堆在自己上下文里。听起来很顺，因为这是 LLM 的强项。
问题出在三个地方：
- Token 税：每个 sub-agent 跑完，结果都得回流到主编排器，再被打包送进下一个。10 个 agent 跑下来，主上下文 60KB 起步。
- 上下文漂移：上下文塞满之后，主编排器开始”健忘”。早期的指令被中间结果挤走，越往后编排越敷衍。条件分支特别容易被”忘记”。
- 不可观测、不可复用：主编排器靠模型即兴发挥，今天能跑出漂亮结果，明天可能跑歪。prompt 写得再细，模型也只是”参考”，不是”执行”。
一种更可控的回答是：别让 LLM 独自承担编排，让 JS 管控制流。
用代码做代码擅长的事（控制流），让模型做模型擅长的事（每一步里的判断）。
这句话来自 Reddit 上那条高赞贴，是这个功能背后的设计哲学。
三种 Agent 协作方式：拓扑各不相同
把市面上的多 Agent 协作梳成三档，看一眼拓扑就知道差异。
- Subagents（信使）：临时派遣，结果回汇。启动成本低、灵活，但 sub-agent 之间没契约——输出格式、调用时序、聚合方式全靠主 agent 临场决定，难复跑。
- Agent Teams（工作室）：长期共事，人在中间调度。多个角色（Planner / Reviewer / Implementer）在并行会话里跑，控制感强但难以一键复跑，更像”IDE + 多个长期 chat”。
- Workflow（流水线）：脚本编排，阶段·并行·schema。每个
agent()都有 schema、phase、label——能复跑、能追踪、能做质量门禁。代价是要写脚本、要审脚本。
第三种范式最大的不同不是“能跑多个 Agent”，而是把临场建议固化成可复跑、可审查、可版本化的代码资产。至于某个具体产品是否支持这样的脚本、支持哪些 API，应以它当前公开仓库的代码和文档为准。
一个最小 Workflow 长什么样
下面是一段概念性伪代码，不对应某个公开 SDK。它展示的是“先写剧本，再演戏”的结构：
const findings = await Promise.all([
runAgent("检查 correctness 风险", findingSchema),
runAgent("检查 security 风险", findingSchema),
runAgent("检查 testing 覆盖", findingSchema),
])
const verified = await runAgent("挑战并核验这些发现", findings)
return runAgent("合成最终 PR 评审报告", verified)这里有三个可迁移的设计点：结构化输出是阶段之间的契约；Promise.all 表达可以并行的独立任务；独立核验阶段负责挑战初步结论。真正实现时，还要由所选运行时补上权限、超时、重试、日志和预算边界。
Schema 是 Workflow 的灵魂，也是它最容易翻车的地方
实测下来一个反直觉的发现：Workflow 写不好，往往不是 Agent 不给力，是 schema 没设计好。
aivi.fyi 那篇博客提到一个翻车案例：作者写了一个 generator → critic → repairer 工作流，schema 字段叫 ok，意思是”修复结果是否通过”。结果 critic 把 ok=false 理解成了”草稿不合格”，整个脚本断言失败。换成字段名 reviewed 就稳定了。
同一篇文章还提到代码审查里另一类失误：reviewer 把一个看似 SQL 注入的发现标成 critical。人工复核才发现，上游早就有 UUID 正则约束兜底。Agent 看到的是孤立片段，没有调用链上下文，就敢下”重大风险”的判断。
两个事故说明两件事：
- Schema 字段名是 prompt 的一部分：模型不只填数据，会用字段名”反推语义”。
ok比reviewed容易引导歧义。 - 覆盖面 ≠ 判断力：Workflow 能并行拉 5 个 reviewer，但替代不了人对全链路的把握。高风险任务必须人工复核 finding。
实战的稳妥姿势是两步走：先生成或编写编排逻辑，人工检查它将调用的工具、数据和退出条件，再交给经过隔离的运行时执行。
为什么必须是 JS，不是 prompt：沙箱在干吗
模型生成的 JS 不应默认直接在本机拥有完整权限。可靠的实现通常需要把脚本放进受限运行时，并通过受控接口调用模型和工具。
为什么要绕这一圈？三个原因：
- 控制权限：文件、网络和进程能力只按任务需要开放。
- 限制破坏半径：危险调用需要拦截或人工批准，不能把“沙箱”当作绝对安全承诺。
- 留下证据：模型与工具调用经统一接口后，才容易记录输入、输出、耗时和失败原因。
打个不严肃的比方：Skill 是临时工，给老板一句话就开干，干得好不好看人；Workflow 是请了个项目经理过来，先写排期表、列预算、定验收标准，然后按表干活。
六种常见 Workflow 形态
下面六种是通用编排模式，不是某个 ultrawork 产品的内置能力清单。
- Pipeline · 流水线：A → B → C 串行结构。
- Parallel + Barrier · 同步聚合：N 个 Agent 同时开干，全部完成才进入合成。深度研究、规格文档生成都靠这个。
- Adversarial Verify · 对抗验证：开一个”反方 Agent”专门挑刺。压制大模型幻觉特别有效——把判断权交给独立的第三方。
- Judge Panel · 评委制：一份候选丢给多个评委 Agent 打分汇总。适合方案对比、文案打分。
- Loop-until-x · 累积式：循环跑直到某个验收条件才退出。适合”试到对为止”的探索任务。
- Nested · 嵌套式：Workflow 里调 Workflow。复杂业务能拆成 Workflow 树。
这六种里我最看重 Adversarial Verify。它不是“一句话上保险”，而是明确安排一个独立角色，要求它给出证据并挑战初步结论。
真正能跑起来的六类场景
光有形态还不够，要知道组装到哪些场景能用：
- 大代码库分片审查：把仓库切成 correctness / security / performance / data-integrity / testing / packaging 六个分片，aggregator 合并去重排序。
- PR 多角色 Review：同时跑行为正确性、安全风险、测试缺口、API 兼容性、性能影响五个 reviewer，输出 blocking / non-blocking / merge-recommendation 三档结论。
- 生成-批评-修复闭环：generator → critic → repairer → final judge。文档、方案、Prompt、Release Note 这种需要”质量闭环”的内容生产。
- 深度研究：分头研究官方文档、论文、社区讨论、GitHub 项目、实测结果，synthesizer 出报告。换主题改改参数就能复用。
- Prompt / Agent Eval：N 个 prompt 版本不知道哪个最好？并行测试再让 judge agent 评分排序。
- Release 前质量门禁：上线前自动跑安全扫描、性能基线、文档同步检查，作为 CI 最后一道闸。
共性：重复发生、流程稳定、结果可结构化。这才是 Workflow 真正的价值锚点。一次性、需要随机应变的任务，反而更适合留给传统 Subagent。
给 AI 立规矩：预算、版本化、团队共享
预算应成为运行时的硬限制，而不是自然语言里的愿望；脚本应进入普通版本管理，而不是依赖某个未经证实的隐藏目录。团队共享时，要同时提交依赖版本、权限声明、输入输出契约和验证方式。这样，工作流才从一次性 prompt 变成可以审查和复跑的协作产物。
不放心 AI 写的脚本？让另一个 AI 审它
模型自己写的调度脚本里要是埋了死循环或偷偷调高危工具，怎么办？
最稳妥的姿势是先生成、不执行；审完再启动。这时你有几个选择：
- 自己读脚本：重点看外部写入、网络访问、并发上限和退出条件。
- 让独立审查者复核：它可以是另一位工程师，也可以是另一个模型，但结论必须能回到代码证据。
- 先跑只读演练：用最小数据集确认控制流和失败行为，再逐步放开权限。
确认无问题再启动。人类的角色从”写代码的”变成了”做最后一道签核的”——审计员，不是搬砖工。
后记：编排逻辑回到了它该待的地方
很长一段时间里，我们都在用 prompt 解决一切问题。包括”该派哪个 Agent、串还是并、出错怎么重试、怎么合成”——这些本来是控制流问题，被一并塞进 prompt，期望模型每次都恰好执行。
把这一层抽出来，还给它更合适的载体：代码。
- 控制流交给 JS：循环、条件、并行、重试、预算——本来就是程序语言擅长的。
- 判断交给模型：每个
agent()内部，模型继续做”在有限上下文里思考”。 - 结果直接串联：子 Agent 产物不污染主上下文，token 税被砍掉。
这套划分一出来，多 Agent 系统就从”写得好不好看人品”变成了”写得好不好看 schema”。前者是玄学，后者是工程。
更有意思的是这段 JS 是 AI 自己写的。你说一句中文需求，它写一段确定性 JS。 之前需要既懂业务又懂 LangGraph 才能干的事，现在压成一句自然语言。
人类的位置在不断后撤——从写代码，到审代码，到审”代码生成器”。每后撤一步，能驱动的能力规模就放大一档。
最后留一个动手建议：先拿一个只读、可回滚的小任务，把它拆成并行执行、独立核验和最终汇总三段，用你能公开核验的运行时实现。重点不是追逐某个触发词，而是让每一步都有输入、输出、权限和验收标准。
参考资料
- Anthropic 工程博客：Effective harnesses for long-running agents
- Anthropic 工程博客：Scaling Managed Agents: Decoupling the brain from the hands