让 Claude 托管智能体自己写工作流：dynamic workflows 公测实操——开启配置、事件流跟踪与限额治理

# 1) 请求带上 beta 头：
#    anthropic-beta: managed-agents-2026-04-01
#
# 2) 更新智能体的 multiagent 字段：
{
  "multiagent": {
    "type": "multiagent_20261001",
    "workflows": { "type": "enabled" }
  }
}
# 保存后该智能体即具备「写工作流」的能力

这两个配置是开关：beta 头声明你使用托管智能体公测能力，multiagent 字段里的 workflows.enabled 决定这个智能体能不能起工作流。注意开关是按智能体粒度的——同一个会话里可以有一个开了工作流的智能体和若干没开的，互不影响。配置好之后可以先创建一个测试智能体，跑一轮普通对话确认基础链路没坏，再进入下一步。

# 系统提示词示例（代码审查场景）：
# 「当任务是审查整个代码库或超过 20 个文件时，
#  启动一次工作流运行：
#  - 阶段 1：按模块拆分，每个子智能体审查一个
#    模块，输出 bug 清单（文件、行号、严重级别）
#  - 阶段 2：交叉复核阶段 1 的发现，
#    剔除误报
#  - 阶段 3：合并成最终报告
#  小于 20 个文件的任务直接自己处理，不起工作流。」

这段提示词就是你的「编排策略」：什么时候值得起工作流、怎么分阶段、每个阶段产出什么。官方明确说启动由智能体判断——只有智能体能发起工作流运行，向会话发事件不会触发一个。所以触发条件要写得可判断（阈值、任务类型），否则它要么该起不起，要么小任务也大动干戈烧 token。

# 会话事件流上会出现的事件（示意）：
#   workflow_run.started        运行启动
#   workflow_run.phase_started  进入某阶段
#   workflow_run.thread_started 某子智能体线程启动
#   workflow_run.thread_message 子智能体产出了消息
#   workflow_run.phase_completed阶段完成
#   workflow_run.completed      运行结束
#
# 前端消费示例（伪代码）：
# for event in session_stream:
#     if event.type.startswith("workflow_run."):
#         render_progress(event)   # 阶段/线程级进度

把任务发给智能体（比如「审查这个仓库的认证模块」），它判断符合条件后会写程序并启动运行。你订阅会话事件流，就能看到阶段推进与每个子智能体的动静——每个子智能体跑在自己的会话线程里，线程内的消息有独立的流可以读，也就是说你既能看「全局进度条」也能钻进任意一个子智能体看它到底读了什么文件、得出了什么结论。审计与调试都靠这层可见性。

# 官方文档列出的限额：
#   一次运行内启动的智能体总数   1000
#     → 超限：不再启动新智能体，运行报错结束
#   运行生命周期                默认 24 小时
#     → 智能体可自设更短；超时以错误结束
#   单会话同时打开的运行数      默认 10
#     → 超限：拒绝再起新运行
#   会话预算                    由你设置
#     → 预算耗尽：所有打开的运行暂停，
#        会话进入空闲，直到调高或移除预算

四条限额里有三条的默认值可以直接用，会话预算这一条强烈建议自己设——工作流的 token 消耗是主智能体模式的几十倍量级，官方自己都提醒「这类工作流会大量消耗 token，建议从小任务开始」。还有两个容易踩的语义细节：暂停不等于结束，暂停中的运行时钟照走，挂着不管仍可能超时报错；运行打开期间无法更新该会话的智能体配置（会报错），要改配置先等运行结束。

# 上线前自查清单：
#   1) 从一个 20-50 文件的小仓库跑通全链路，
#      记录 token 消耗作为基线
#   2) 关键产出（最终报告、写操作）设人工确认点，
#      未复核前不落库不外发
#   3) 会话预算从保守值起步，观察一周再放宽
#   4) 子智能体工具权限按任务最小化

官方的 bug 测试数字（66/70 对 14-27）来自「可按模块干净拆分」的任务——子任务之间依赖越少，扇出的收益越大。换成论证链强耦合的任务（比如写一份逻辑严密的长报告），拆分收益没有公开数据支撑，别默认套用。媒体上也不乏对「智能体集群大量浪费 token」的批评，冷静的做法是拿自己的真实负载跑 A/B：同样任务，单智能体跑一遍、工作流跑一遍，比质量和总成本，用数据说话。

# 决策参考：
#   Claude Code（客户端跑脚本）
#     → 个人开发者的本机仓库分析，代码与数据不出本机
#   Managed Agents 动态工作流（服务端跑程序）
#     → 团队级服务化：异步执行、事件流可集成、
#        限额与预算由平台兜底
# 两边都是 beta，先在低风险任务上练手感

Claude Code 在今年 5 月下旬以研究预览的形式引入过工作流，脚本跑在你自己的机器上；托管智能体版则是程序跑在 Anthropic 服务端，多了异步执行、平台级限额、事件流集成这些「服务化」属性。个人开发者做本机代码分析，Claude Code 版更顺手也更省心——代码不用上传；要把它做进产品或团队流水线（比如每天定时对主分支做安全审计、结果推到内部系统），托管版的事件流与预算管控才是为此设计的。

把视角拉远一点：动态工作流代表了一个明显的方向——编排的写法正在从「工程师写死流程图」走向「模型现场生成程序」。你今天写的那份系统提示词，就是未来工程师的核心交付物：定义什么任务值得拆、怎么拆、结果谁验收。把这套提示词当代码管理，版本化、评审、持续迭代，是现在就能做对的事。