TL;DR

AI 编程正在从「模型实时判断」走向「确定性执行」——这是本文的核心论点。Dynamic Workflows（脚本化）和 iii agent harness（总线化）同天发布，表面是两种路线，实则是同一个问题的两个解法：都在解决「当 agent 工作规模大到需要协调几十上百个并行任务时，纯靠模型逐轮判断不够用」这个问题。

关键观察：

  • 把编排从「实时决策」变成「静态资产」——Workflow 写进 JS 脚本，iii 拆成独立 workers，路径不同但本质相同
  • 确定性换可预测性，可组合性换集成度——不再依赖全知全能的 orchestrator，而是让每个组件只做一件事，通过组合而非集成来实现复杂功能
  • 强模型是 Workflow 的承重墙——Opus 4.8 的诚实性提升，让「数百 agent 交叉验证」这套打法得以成立
  • 共同的赌注——两套方案都依赖模型能力持续提升，如果 LLM 遇到不可逾越的瓶颈，大规模 agent 协作本身就失去前提

这不是工具的进化，这是范式的转移。

5 月 28 日，Anthropic 发布了 Opus 4.8。同一天，Mike Piccolo 发了那篇关于 iii agent harness 的长推（191K views），riba2534 发了一篇关于 Dynamic Workflows 的深度解析（201K views）。两篇相隔几小时出现，讲的几乎是同一个问题：当 agent 工作规模大到需要协调几十上百个并行任务时，纯靠模型实时判断已经不够用了，我们应该怎么编排？

这两篇文章给出的答案截然不同，但指向的终点是同一个。

两个解法，一个问题

Anthropic 的解法是”脚本化”。 Dynamic Workflows 让 Claude 把整个编排逻辑写成一段 JavaScript 脚本——循环、分支、中间结果的收集全部固化在代码里——再交给一个无脑的确定性运行时去执行。模型只在 agent() 调用时临时”醒来”干活，其他时候全程在睡觉。Jarred Sumner 用这套工作流，11 天迁移了 75 万行 Rust 代码，99.8% 测试通过。

Piccolo 的解法是”总线化”。 iii 把 agent harness 的 15 种职责拆成独立的 worker，每个 worker 通过 WebSocket 总线连接，通过 iii.trigger() 通信。框架不再是 monolith，而是一组可独立版本化、可替换的组件。

表面上看，这是两条完全不同的路：一个是让模型写脚本，一个是让 worker 们通过总线组合。但它们的核心是一样的——都在解决”模型实时做编排决策”这个模式的失效问题。

实时编排为什么不工作了

原因很直观：当任务规模小、并行度低的时候，模型逐轮判断下一步派谁去干什么，是很灵活的。但一旦要协调几十上百个并行任务，问题就来了——上下文窗口装不下那么多中间结果，Claude 的注意力被海量过程信息稀释，每一次”决定下一步”都变成了一次对上下文容量的消耗。

Bun 的案例最能说明这个问题：75 万行代码的迁移，涉及数百个并行 agent，每个 agent 还要配两个 reviewer 做交叉验证。如果这些全靠主 Claude 逐轮协调，光是把所有中间结果塞回上下文这件事，就能让整个系统陷入瘫痪。

两条路的共同答案是：把编排从”实时决策”变成”静态资产”。Workflow 把编排写进代码，iii 把编排拆成独立 workers——目的都是让”决策”这件事离线化、确定化、可复用化。

15 种职责：一个被忽视的复杂度

Piccolo 在那篇长推里列了一张表，把一个生产级 agent harness 必须具备的职责拆成了 15 项：

  • 接收 turn 请求并持久化
  • 解析凭证（多模型 provider 的认证）
  • 查询模型能力（vision、tools、streaming、context window）
  • 驱动 per-turn 状态机（provision → assistant → function → steer → teardown）
  • 加载和提供 skill bodies（函数定义、错误码、使用说明）
  • 组装 system prompt（mode paragraph、identity preamble、working directory、default skills appendix）
  • 流式返回 token 给客户端
  • 每个 tool call 执行前过 policy 检查
  • 暂停需要人工审批的 tool call
  • 跟踪 LLM 花费（按 workspace 或 agent 的预算）
  • 执行 tool call 前后置 hook（日志、脱敏、副作用）
  • 将会话持久化为分支树（支持 fork 和 resume）
  • 当 context window 满时压缩会话历史
  • 发送事件流供 UI 订阅
  • 携带 OpenTelemetry trace 跨越每一步以便调试

这 15 项里，有些是”每跑一个 agent 都要做一次”的（如 policy 检查、hook 执行），有些是”跑之前初始化一次”的（如 provisioning、prompt 组装），有些是”持续运行的”（如 session 持久化、事件流）。把它们打包成一个 monolith，代价就是：当你需要对某一项做定制的时候，你往往得动整个 harness。

历史先例：这不是新问题

计算机科学里，这个问题早就以另一种形式出现过。

1970 年代，操作系统从”单一监控程序”演进到微内核架构，核心思路和 iii 几乎一模一样：内核不再承担所有职责（文件系统、内存管理、网络协议栈、设备驱动），而是把每种职责拆成独立的服务进程，通过消息传递总线通信。微内核的代价是更高的通信开销（进程间消息传递比函数调用慢），收益是每个服务可以独立开发、独立测试、独立替换——Linux 的设备驱动可以在不重启内核的情况下动态加载，这正是微内核思想的遗产。

1990 年代，Java 的 Enterprise JavaBeans（EJB）走的是相反的路：把所有业务逻辑打包进应用服务器的容器里，开发者失去了对执行流程的直接控制。Entity Bean 的 persistence 要走容器的管理，事务要靠容器声明，线程模型完全由容器控制——你想单独控制一行代码的执行方式？没门。后来 Spring 框架的崛起，某种程度上是”把控制权还给代码”的回归：Plain Old Java Object（POJO）+ 依赖注入，让业务逻辑重新变得可读、可控、可测试。Workflow 的脚本化，也是在”把控制权还给代码”——只不过这次控制的是 LLM agent 的编排。

甚至可以追溯到更远：1975 年 Brooks 在《人月神话》里写”没有银弹”，他真正警告的不是某项具体技术，而是”把复杂性封装进黑盒、期望它自动解决问题”的思路。框架模型的问题，和当年 EJB 的问题是一脉相承的——当你把所有编排职责打包成一个黑盒，你就失去了对每个组件的独立替换能力。Piccolo 在文章里说的”大多数团队一年后就得重写整个 harness”，和 Brooks 在 1995 年”银弹在哪里”续篇里说的”我们倾向于用过程掩盖复杂性，而不是消除它”，是同一件事的不同表述。

两种哲学，一个方向

两条路都在不约而同地指向同一个设计原则：用确定性换可预测性，用可组合性换集成度。

Workflow 的脚本是确定性的——给定同样的输入，每次都跑出同样的轨迹。它不可变、可审计、可复用。你可以在跑之前审一遍脚本，可以在运行中按 Ctrl+G 打开编辑器看它到底写了什么代码。模型在执行过程中全程在睡觉，只有在节点内部才调用 LLM——这和传统编程里”主程序调用函数”的结构几乎一样，只是函数的实现换成了 LLM。

iii 的 workers 也是确定性的——给定同样的触发，每个 worker 都以同样的协议通信，结果可预期。Piccolo 特别强调：thin vs thick 不再是一个二元选择，而是一个可调节的 slider。你可以在任何一层替换组件而不影响其他层。少了 approval gate？拔掉它。换个更严格的 policy engine？插进来。编排逻辑完全不动。

两条路都在远离那个”全知全能的 orchestrator”模型——无论是 LangChain 的 Chain，还是 Agent Teams 里那个实时决策的主 Claude，都不再被视为正确的设计范式。orchestrator 的问题不是它”不够聪明”，而是它承担了太多职责——它既是调度器，又是状态管理器，还是认证层、预算控制层、policy 执行层。当任务规模扩大，orchestrator 本身就变成了性能瓶颈和可靠性风险的集中点。

这对 AI 编程意味着什么

如果这个趋势是真实的，那么 AI 编程的下一阶段，就不只是”让模型帮你写代码”这么简单。它意味着“AI 编程”的含义本身在发生变化——从”模型实时生成代码和指令”，走向”模型生成编排逻辑，确定性运行时执行”。

这带来一个有趣的后果：编排变成静态资产后，可靠性问题就从”模型的推理是否正确”变成了”脚本的逻辑是否完备”。前者是概率性的，后者是确定性的。概率性问题无法彻底消除，但确定性问题的边界是清晰的——你可以通过审阅、测试、版本控制来逼近完备。这和传统软件工程走过的路一模一样：单元测试、集成测试、CI/CD，都是在用确定性手段控制概率性风险。

另一个值得关注的后果：Opus 4.8 和 Dynamic Workflows 同天发布不是巧合。Ribase2534 在文章里指出了这一点——当你让数百个 agent 并行干活、还要它们互相 review 彼此的结论时，每个节点的可靠性就被放大了。节点是概率性的 LLM，同一个问题换个角度问都可能给出不一致的答案，而多步流程里的不确定性会层层累积。Opus 4.8 专门强化了”让代码缺陷悄悄溜过、不被发现的概率比前一代低了约四倍”这个能力，更倾向于主动标记自己拿不准的地方。这种诚实性的提升，正是”数百 agent 交叉验证”这套打法能成立的前提——交叉验证要管用，前提是 reviewer 真的会指出问题，而不是一味点头。强模型不是 Workflow 的可选项，是它的承重墙。

一个被低估的事实

值得注意的是，这两篇文章的核心内容，其实都依赖同一个底层假设：agent 的执行结果是可预期的、可审计的、值得信赖的。如果一个 agent 调用了错误的工具、写了有 bug 的代码、或者在关键决策点给出了不可靠的答案，整个系统就会在某个环节悄悄失效。而这个假设的成立，依赖于模型本身的能力提升。

这意味着这两条路有一个共同的赌注：模型的能力会持续提升，使得更多复杂的工作可以被托付给 agent 协作完成。如果这个赌注落空——比如 LLM 在某些任务上遇到了不可逾越的能力瓶颈——那”大规模 agent 协作”本身就失去了成立的前提。

但如果这个赌注持续兑现，那”确定性执行”的路线就会越来越成为主流——因为模型的每一次进步，都在扩大”可以托付给确定性的工作量”的边界。

两个选题方向

这两篇文章同天出现，给了博客两个自然的选题：

方向一：从”模型实时判断”到”确定性执行”——AI 编程范式的转移。 从 Bun 案例入手，分析为什么”把编排写进代码”在这个时间点变得可能、可行、且必要。引入历史先例（微内核、Spring vs EJB、《人月神话》），聚焦于核心问题：为什么”全知全能 orchestrator”会在大规模时失效？确定性为什么是解药？

方向二：Workflow vs Harness——两套思路的直接对比。 两个团队在完全独立的情况下，几乎同时得出了相似的结论。一个用脚本，一个用 workers 总线；一个来自 Anthropic 的产品团队，一个来自独立的开源项目。他们各自的优劣是什么？分别在什么场景下更适用？这个对比本身就是价值——它帮助我们看清这场演进的真正驱动力，而不是被某一种具体实现牵着走。