独立开发者 WeZZard 发了一篇长文，讲述他从 2025 年 8 月开始用 subagent 驱动的 loop 推进个人项目，到 2026 年 2 月做出一个比官方 dynamic workflow 早四个月的等效插件 charge，又自己把它放弃、并把经验沉淀到下一代工具 amplify 的完整过程。这篇文章把他走过的路、踩过的坑、留下的设计原则整理出来。
起点：subagent 驱动的长程 loop
WeZZard 从 2025 年 8 月开始，在 Claude Code 配 Opus 4.1 里跑一个长程 agentic loop。机制是写一份详细的 plan 文件，loop 里有 一个 evaluator 加若干 executor subagents，按 plan 推进开发、测试、排障、集成。
这个设计的关键是让 subagent 隔离 context：LLM 本质是 next-token prediction，把无关内容挡在 context 外是提升系统性能下限最有效的方法之一。每个子步骤都受益于这种隔离。
他在 2025 年 9 月写过一篇介绍这个 loop 的文章。两个月后，Anthropic 发表"harness"概念的文章里用了类似设计——这是后话。
模型变强之后，原来精心设计的 loop 被"绕过"
Opus 4.5 发布后，事情开始变。主 agent 开始直接跳过 evaluator-executor 模式，自己把任务推进完成——因为这些 subagent 返回的响应里已经包含任务细节，主 agent 看得见、能"接管"。
差不多同一时间，Claude Code 引入了 background tasks 和并行 subagent。这两个特性反而让"任务泄漏到主 agent"跑得更快——泄漏出去的任务有时会被进一步拆解并并行处理。到 2026 年 1 月，他用 Claude Code 在一次文件处理任务里生成过 70 多个并行的 subagent。
WeZZard 的洞察：随着模型变强，原来的"边界设计"会被模型能力本身消化掉。这是设计 subagent 编排系统时一个反复出现的现象——今天的护栏，明天变成多余的环节。
charge 的诞生：领先四个月，又踩进同一个坑
"既然运行和协调 subagent 变容易了，能不能创建和管理由 subagent 驱动的可复用 workflow，借鉴结构化并发编程里任务树和 DAG 的概念来构建依赖？"
2026 年 2 月，charge 出来了。机制非常 prompt-driven：
- 任务拆解和依赖构建通过 chain-of-thought 实现：理解用户意图 → 识别重复模式 → 划分任务边界（每个任务单一目标、输入输出清晰）→ 定义 schema 属性 → 把依赖映射为任务依赖图
- 沿这条链路，模型把简单 prompt 转换成一个 JSON 对象表示任务图
- workflow executor 直接消费这个 JSON
tasks 数组里每个 task 用 depends_on 字段指定依赖。读取这个 JSON 就能"神奇地"按依赖顺序执行任务。
WeZZard 自己说：charge 实现"出奇地简单"，完全由 prompt 驱动、用动态生成的 schema 约束。
charge 还有两个独特设计：
- 任务 schema 化：每个 task 显式声明
input/output字段，类似强类型接口 - plan mode 强制 review：任务依赖图生成后必须先经过用户审阅，再开始执行
这一步审阅至关重要——动态生成 subagent 是按 output token 计费的（主 agent 要输出生成 subagent 的 prompt，output token 单价贵得多）。review 实际上实现了一种token 消耗的"渐进式暴露"。
charge 的一个独特优势是编排保留在主 agent 中——任意时刻都可以中断、引导。这对创造性任务特别重要。
决定性时刻：复用率高的 workflow 该写代码就别用 prompt
用了一段时间 charge，WeZZard 得出一个反直觉的结论：
"实际场景中复用率最高的 workflow 其实更适合用确定性算法来实现。这部分工作本就该写在代码里，而不是 prompt 里。"
LLM 的价值在创造力。在可复用 workflow 里，LLM 通常只出现在分析、诊断、或者"把 Zig 重写成 Rust"这种"洗码"任务里。这些任务的特点是输入变化大、需要判断。如果是高度结构化的固定流程，让 LLM 去推断执行顺序是浪费——它本质上靠 next-token prediction，无法保证下一步执行是正确的，也无法保证会发正确的 tool call 启动下一个 agent。
WeZZard 认为官方采用 JS 写的确定性执行引擎是对的，至少对需要大规模编排 subagent 的系统来说。
他还提了三个值得记住的优化：
1. 用 generator 模式实现执行引擎，直接在主 agent 里跑。 不是"调外部脚本"那种进程间通信，而是用一个 shell 脚本（如 complete-task.sh）记录任务状态、返回接下来的可执行任务。这种设计下主 agent 仍然负责编排，但执行顺序由代码而不是模型推理。
2. 用代码生成更结构化的 tool outputs。 在 script 里内联多个工具、合并 tool calls，减少 context 噪音。对分析和诊断任务来说，tool output 越结构化、越可读，下游 subagent 的判断越准。
3. 用 agent SDK 替代进程间 tool call。 对注重可行性的任务，可以基于 OpenCode SDK 这样的 agent SDK，在数据传输和进程内通信中引入类型安全。OpenCode SDK 和 OpenCode 用相同的 session 格式，session 可以在 OpenCode 客户端里继续——这种互操作性给 LLM-driven workflow 带来了可调式性，是 agent 生态里被长期忽视的价值。
唯一例外是调研任务。WeZZard 指出调研离行动太远，需要经过判断才能转成行动；这种"判断密度低、跨度长"的任务就是 LLM 的菜——官方内置 /deep-research workflow 正是为此设计。
决策树：什么时候用 LLM 编排，什么时候用代码
WeZZard 画了一棵决策树，结论非常清晰：
- 要创造全新东西 → 保持 human in loop，在运行中随时引导
- 跑可复用 workflow → 更经济的选择：基于 OpenCode 搭配高性价比模型，或者直接写代码（代码只消耗 CPU 时间，不消耗 token）
主动放弃 charge，做出 amplify
WeZZard 公开承认 charge 是"伪需求"——动态生成 subagent 并复用其 workflow，实际上大部分场景是过度设计。但 charge 的三个设计原则被保留下来，沉淀到 2026 年 2 月开发的下一代工具 amplify（amplify@wezzard-skills）：
- 任务依赖图 + 每个任务专属的 subagent
- 基于 plan 的任务图 review 机制
- 在主 agent 中执行，以便在运行中随时引导
amplify 在此之上新增了一个关键机制：审计（audit）subagents。为了防止主 agent 过早宣布完成，amplify 让 audit agent 检查"规划的工作是否真的已经完成"——这是对抗 agentic laziness 的结构化方案。
WeZZard 已经把 charge 和 amplify 都开源了。amplify 凝聚了他构建 charge 时积累的所有经验教训。
三条值得记住的判断
-
subagent 编排的护栏会被模型能力消化。Opus 4.5 之后，WeZZard 精心设计的 evaluator-executor 模式被主 agent 直接绕过——这不是失败，是模型进步的副产品。设计 subagent 系统时，要预设"边界会失效"，而不是寄望"边界永远管用"。
-
复用率高的 workflow 该写代码就别用 prompt。LLM 在"创造力"和"判断"上值钱，在"按固定流程执行"上亏钱。charge 失败不是因为设计错，而是它要解决的问题本身就是代码比 LLM 干得更便宜。
-
任务图 + audit subagent 是动态工作流的核心。amplify 保留 charge 的三个设计原则，再加 audit 防偷懒——这是从"能跑"到"能信"的关键一步。结构上对抗 agentic laziness，比 prompt 上加约束稳定得多。