动态 Workflow 把什么搬进了代码

不是「多开几个子智能体」那么简单。模型不再一步步亲自背着计划往前走而是临时设计一个小执行系统控制流、状态、覆盖这三样从对话上下文搬进了代码和运行时。Anthropic 管这叫动态生成的 harnessLangChain Deep Agents 叫 dynamic subagents。壳不同底层动作差不多模型写一段编排脚本受限运行时执行它脚本再去派发隔离的子智能体。比起记住产品名词更值得看的是这三样各自补哪类失败。三层结构判断层主模型写出脚本控制流层运行时记账执行层子任务回传结构化结果判断层主模型写出脚本控制流层运行时记账执行层子任务回传结构化结果先分清谁持有计划Claude Code 文档里有一张对照挺有用。Subagent、Skill、Agent Team、Workflow 都能做多步任务差别在谁决定下一步、中间结果放哪、什么东西可复用。Subagent 是工人。下一步仍由主模型临场决定中间结果常回到上下文。它解决局部隔离不解决长期编排。Skill 是做事原则。它告诉模型「应该怎样做」流程却仍活在提示词和对话判断里。原则重要但不是执行账本。Agent Team 是同伴会话。lead agent 监督多个长时同伴协调仍靠一轮轮判断。适合需要持续协作的少数角色不太适合成百上千次同质派发。Workflow 不一样。编排脚本持有循环、分支和中间变量主上下文尽量只收最终结论。可复用的也不只是工人定义或提示词而是编排本身。我把动态 workflow 压成一句设计阶段用智能执行阶段用结构。这里有个容易被忽略的含义。动态指编排图由模型按当前任务临时生成一旦脚本提交执行应当尽量确定。不是让模型在运行时每一步继续「随便跳」。设计用概率智能执行用结构约束分层才成立。搬进代码的第一样控制流控制流包括循环几次、能否并行、哪个阶段是屏障、失败是否重试、何时停止。这些事模型其实也会「说」但它说在自然语言里下一轮还可能改口。搬进代码之后控制流变成可执行语句。审查一百个文件不再是模型每轮决定「要不要再开一个任务」而是一个map/pipeline明确派发。先发现再验证也不再靠提醒「请先验证」而是脚本里先跑发现阶段再对每个 finding 派验证者最后按结果过滤。LangChain 有个干净例子三百页文档一页一个子智能体。与其调用任务工具三百次、每轮再决定要不要继续不如写一个循环让覆盖成为结构保证。Claude Code 侧同样是普通 JavaScript外加agent、pipeline这类派发原语中间结果留在脚本变量里不灌回主会话。这里至少有两种同步方式值得分开看。屏障式合成fan-out 之后先等齐再合并。适合所有局部结果都要用同一标准收口的任务比如统一分级的安全报告。流水式推进对象一个个进入后续阶段不必等全世界结束。适合迁移、修复循环或前面阶段产出会持续喂给后面阶段的场景。两者都是控制流只是同步点不同。单上下文 Agent 很难稳定维持这种同步点因为它每轮都在重新理解「现在该不该等」。模型仍然负责判断这个 finding 严不严重这个方案值不值得保留。但它不再负责在脑子里维持「还有没有下一轮」。控制流搬走之后上一篇里的流程漂移会明显下降——不是因为模型更听话而是因为流程不再只活在可遗忘的叙述里。搬进代码的第二样状态长任务必须有账本已处理、待处理、待验证、已确认、已驳回、重复项、失败项、当前第几轮。单上下文里账本伪装成对话摘要摘要一压缩账就糊。Workflow 运行时把状态放在脚本变量和执行层记录里。哪些 agent 跑完了、哪些失败了、能否在同会话 resume由系统记账。官方文档也强调workflow 在隔离环境执行脚本本身通常不直接碰文件系统和终端真正读改世界的是被派出去的 agents。脚本负责协调不该越权操作。可以把状态想成一张最小必要表。工作集里每个对象当前处于什么阶段每个发现有没有进入验证验证结果是确认、驳回还是因错误未完成本轮相对上轮新增了什么停止条件是否已满足这些字段如果只存在于模型印象里就会随上下文波动如果存在于运行时就能被观察、恢复、复盘。Claude Code 的/workflows能展示阶段、agent 数、耗时和局部结果背后依赖的正是这类外置状态而不是主会话的自我叙述。状态外置有两个直接好处。主上下文不再被过程日志塞满判断质量更稳流程也不容易因为一次摘要丢失「做到哪一步了」。模型少背账系统多记账——harness 思维落到 workflow 上大概就是这个意思。还有一个常被低估的好处失败可局部处理。某个文件审查超时不必让整次任务的「记忆」一起崩。脚本可以记录失败项、选择重试或跳过并在最终报告里显式列出。单上下文里一次工具失败常常会污染后续叙事模型甚至会在总结时把失败暗示成「该项不重要」。搬进代码的第三样覆盖覆盖最容易被提示词假装解决也最容易在规模上穿帮。「请全部审查」听起来完整却答不了全部到底是多少处理了多少跳过了多少失败了多少动态 workflow 的做法是先把工作集物化成明确集合——文件列表、页面列表、候选方案列表——再围绕这个集合派发。完成不再等于模型说「我做完了」而更接近结构能回答的账集合大小、成功数、失败数、未覆盖项。工作集从哪里来本身就是设计问题。有的任务工作集事先已知某个目录下的全部文件、某次变更里的全部 diff。这时先列出再 fan-out。有的任务工作集要先发现先让一个 agent 枚举路由、抽取声明、收集候选。发现本身也要产出结构化列表而不是一段「大概有这些」。有的任务工作集边做边长死代码、漏洞、间歇失败测试。这时覆盖证据变成「按停止条件收敛」而不是「对固定 N 做完」。连续两轮无新发现本身就是一种覆盖陈述。有了工作集覆盖证据才能成立。安全审计可以报告「共 N 个路由确认 M 个问题驳回 K 个」循环探索可以报告「跑了 R 轮连续两轮无新发现后停止」。完成变成可核对的陈述而不是完整语气。还有个常被忽略的前提子任务返回值要可聚合。如果每个子智能体都回一段风格不同的自由文本并行之后主模型还得再读一遍、理解一遍、整理一遍可靠性又塌回自然语言。所以好的 workflow 会约定结果协议甚至用 schema 约束字段。代码审查稳定返回位置、级别、描述、证据事实核查返回说法、结论、来源、置信度方案评估返回优点、风险、取舍、建议。内部可以自由推理对外必须是能 filter、sort、merge 的结构。覆盖不是「多跑一点」就自动获得的。它依赖工作集、派发闭环和结果协议同时成立。少一块最后仍可能回到「看起来做完了」。三样东西如何一起工作一次动态 workflow大体可以看成三层。判断层是主模型。它决定这次任务怎么拆、要不要验证、用什么停止条件、结果最终如何呈现。控制流层是脚本和运行时。它负责循环、并发、等待、状态推进和恢复。执行层是子智能体。它们在隔离上下文里做局部判断按协议回传不把全过程塞回主会话。一次典型运行大致是这样用户提出规模任务主模型判断任务形状并写出脚本人在需要时批准计划运行时在后台执行子智能体并行或分阶段产出结构化结果脚本聚合并过滤主会话只接收收敛后的结论和覆盖证据。中断后可 resume也是因为状态在运行时不在某段容易丢失的对话摘要里。长时间任务终于更像系统任务而不像一场不能中途喝水的长对话。这和传统 DAG 工作流有同构处都用结构保证阶段与依赖。差别在于动态 workflow 的编排图常常是模型按当前任务临时写出来的而不是人事先为所有边角情况写死的通用流程。静态流程更可控、更好测动态流程更贴任务形状。代价也明显更贵更依赖模型写编排代码的能力也更需要权限边界和人工批准。Anthropic 自己也区分过过去为了 research、安全分析、code review常常要在 Claude Code 上另做定制 harness动态 workflow 试图让模型为每个任务现场生成专用 harness。这不是否定静态流程。通用静态流程为了覆盖边角往往会变得很泛任务足够复杂时临时特化的结构更有杠杆。一个最小例子看三样如何落地鉴权审计最小流程列出路由文件、逐个审查、独立验证、只保留确认项、输出覆盖账本列出路由文件、逐个审查、独立验证、只保留确认项、输出覆盖账本假设任务是审查src/routes/下所有路由是否缺鉴权并且只报告经得住独立验证的问题。用接近 Claude / LangChain 的伪代码写会更清楚三样东西各自落在哪// 1) 覆盖先物化工作集 const listed await agent(列出 src/routes 下全部路由文件只返回路径数组, { schema: { type: object, required: [files], properties: { files: { type: array, items: { type: string } } }} }) const files listed.files // 2) 控制流按集合派发再独立验证 const findings [] for (const file of files) { const audit await agent(审查 ${file} 是否缺鉴权按协议返回 findings, { schema: { /* path, severity, evidence, claim */ } }) findings.push(...(audit.findings || [])) } const confirmed [] for (const item of findings) { const verdict await agent( 只根据证据判断是否成立不要继承原结论。claim${item.claim}; evidence${item.evidence}, { schema: { type: object, required: [status], properties: { status: { type: string, enum: [confirmed, refuted, unverified] } }} } ) if (verdict.status confirmed) confirmed.push(item) } // 3) 状态 / 覆盖证据最终交账不只交观点 return { filesTotal: files.length, findingsTotal: findings.length, confirmedTotal: confirmed.length, confirmed: confirmed.sort((a, b) rank(b.severity) - rank(a.severity)) }这段里模型仍然负责「这是不是鉴权缺口」「证据够不够」。脚本负责「还要不要继续」「验证有没有漏做」「待确认有没有混进确认」。上一篇那些失败模式对应的结构性补丁大致就在这里。如果最后只能交回一段自然语言总结没有filesTotal/confirmedTotal那编排脚本也白写了——覆盖账本必须出现在输出里不能只活在运行时变量的寂寞里。没有搬进代码的是什么判断本身没有搬走。风险是否成立、方案是否更好、证据是否足够仍然需要模型。Workflow 不是用 if-else 替代智能而是把不该由概率性记忆承担的部分交给确定性执行。权限边界也不会因为「动态」自动变好。模型可以临时设计很强的执行安排但如果编排层或子角色权限过大风险也会被放大。读不可信公开内容的角色不应同时拥有高权限写操作负责分类的角色不一定能改代码负责生成方案的角色不一定能直接发布。动态生成的是执行结构不是无限授权。成本也不会凭空消失。更多 agent、更长并行、更严验证通常意味着更多 token。Workflow 适合高价值任务不适合当默认油门。边界不清时它甚至会把跑偏放大成大规模跑偏。所以「能搬进代码」不等于「事事都该搬」。收一收动态 workflow 把三样东西搬进了代码。控制流压住流程漂移状态让进度不靠上下文硬背覆盖让完成能被核对。模型继续做判断系统开始做账。上一篇的几类失败几乎都能在这三样上找到对应补丁。漏项靠覆盖自证靠控制流拆出独立验证漂移靠控制流外置上下文污染靠状态与隔离执行。看到这层就不太会把 workflow 误解成「多开几个 Agent 更热闹」。下一篇会讲有了这套机制之后任务形状不同组织方式也不同——六种常见 pattern以及它们怎么组合。