跳到正文

动态工作流程：从提示到运行时

2 分钟阅读
reading agents
agent-runtime workflows

Anthropic 的动态工作流程很容易描述为产品功能：Claude Code 可以生成临时工作流程并使用子智能体来完成任务。

更有意思的读法是把它当成架构问题。动态工作流指向一种通用智能体系统模式：

在运行时生成特定于任务的编排层，然后让该层管理分解、并行性、状态、验证、重试和综合。

这改变了对长期智能体失败的诊断。问题通常不是模型根本无法推理。问题是执行组织太软：

one context
 owns the goal
 remembers the plan
 calls tools
 tracks progress
 verifies itself
 decides when to stop

对于较长的任务，一个上下文窗口的责任太大了。

核心思想

动态工作流是一种在线工作流合成。自然语言任务被编译成临时执行图。

该图可能包括：

  • 独立分片的工作人员；
  • 对抗性检查的验证者；
  • 用于路由的分类器；
  • 做两两比较的评审器；
  • 用于合并结构化结果的合成器；
  • 停止条件检查以确定工作何时实际完成。

重要的转变是这样的：

plan hidden in the model's context
 ->
plan represented in runtime state

一旦计划在模型之外呈现，系统就可以对其进行调度、检查、重播其部分内容，并在满足明确条件之前拒绝完成。

这解决了哪些故障？

动态工作流程主要帮助解决三种故障模式。

失败会发生什么工作流程对策
智能体性懒惰模型在部分覆盖后停止，因为答案感觉完整外部任务队列和覆盖状态
自我偏好偏见相同的背景提出并验证了自己的答案独立的工作人员和验证者角色
目标漂移在长距离运行或压实过程中，约束消失了在工作流程状态中保留目标、标题、预算和停止条件

可靠性增益来自上下文分割、状态外部化和角色分离。更强大的模型会有所帮助，但 harness 正在发挥实际作用。

运行时组件

通用的动态工作流系统至少需要以下部分：

组件责任设计压力
工作流程生成器将任务变成可执行图它必须产生结构，而不仅仅是散文计划
state store保留任务、产物、决策和依赖关系状态不应该只存在于聊天记录中
调度程序决定什么现在可以运行，什么必须等待需要扇出、屏障、重试和循环
智能体路由器分配模型、角色、工具和上下文切片角色应具有不同的权限
验证层检查模式、证据、测试和反诉正确性不能是纯粹的自我报告
合成器合并已验证的产物它应该消费结构化输出，而不是口头总结

我最喜欢这个模式的规则：

让LLM做出本地判断。让运行时进行全局控制。

动态工作流程概述

静态与动态工作流程

静态工作流程是在任务到达之前设计的。它们最适合具有稳定输入的重复工作。

任务到达时才生成动态工作流。它们最适合一次性工作，因为这类任务的结构本身就是问题的一部分。

维度静态工作流动态工作流
创作时间提前设计每个任务生成
最适合稳定的生产管道探索性长期任务
可靠来源人工设计和回归测试针对特定任务的分解加验证
主要风险太死板昂贵且难以复制
长期价值耐用的自动化工作流程发现

它们之间的桥梁很重要：动态工作流程可以发现可重用的模式。一旦生成的工作流程反复证明有用，它就应该成为静态工作流程、skill 或模板。

我想重用的模式

扇出并合成

将此用于覆盖任务：代码审查、迁移、文档审核、源代码收集或声明检查。

shard -> independent workers -> barrier -> structured synthesis

价值不在于“很多智能体”。该值是孤立的本地上下文和显式覆盖。

对抗性验证

将其用于高风险声明。验证者的工作不是润色 worker 的答案，而是攻击它。

好的验证者输入应包括：

  • 索赔；
  • 来源证据；
  • 信心;
  • 什么会伪造该声明；
  • 未解决的疑虑。

锦标赛或生成并过滤

将其用于需要大量判断的任务，例如名称、设计、架构选项或研究假设。成对比较通常比绝对评分更稳定。

循环直到完成

将此用于未知持续时间的任务，例如片状测试再现或根本原因调查。困难的部分是停止条件：

no new high-severity finding
all claims have sources
tests pass N times
all shards have verified output

如果没有硬停止条件，循环只会放大主观收敛。

分类并采取行动

将其用于队列：错误报告、警报、支持票证、用户反馈或文档集合。

对于不受信任的输入，分类器和参与者应该分开。默认情况下，读取任意 Web 或用户内容的组件不应获得高权限操作。

值得付出的代价

动态工作流程的成本很高。我会将它们保留用于执行组织本身就是瓶颈的任务。

场景为什么适合
大型代码库审查覆盖范围、分片和验证比一个长答案更重要
深入研究可以独立收集来源，然后进行核对
技术博客验证索赔可一一提取、核对
根本原因调查相互竞争的假设需要不相交的证据
内存挖掘可以对过去的更正进行聚类、测试并提升为规则
智能体评测轨迹需要失败归因，而不仅仅是最终分数

验证工作流程

对于这个博客项目来说，最相关的应用是深度验证。完善的技术帖子仍然可能包含不受支持的主张。提取声明、分配验证者和返回证据的工作流程将是一个强大的写作助手。

成本和限制

动态工作流并不是免费的基础设施魔法。

  • 它会消耗更多 token 和工具调用。
  • 生成的工作流程比静态管道更难进行回归测试。
  • 如果工作人员和验证者共享相同的模型和证据，则他们的错误可以关联起来。
  • 除非明确表示冲突，否则综合可以消除少数信号。
  • 必须设计权限边界，特别是围绕代码编辑、浏览器、电子邮件、Slack 和不受信任的网页。

该模式很有用，因为它使这些成本变得可见。一个提示即可隐藏它们。

我的收获

智能体系统的未来不只取决于模型智能，也取决于运行时组织能力。动态工作流很重要，因为它把智能体工作从“在一个上下文中努力尝试”，变成“为这个任务创建一个临时执行系统”。

如果 prompt engineering 问的是如何让一个模型回答得更好，那么 workflow engineering 问的是如何组织模型、工具、状态和验证，让系统完成单个上下文无法安全完成的工作。

参考文献