1. 从“记忆污染”说起为什么 Managed Agents 需要 Dreaming如果你深度用过 Claude Code 或者任何长时间运行的 Agent大概率撞过同一堵墙跑了几十轮之后Agent 开始“犯迷糊”。同一个偏好你上周刚纠正过这周它又忘了两个子任务里记下的配置互相打架早期已经废弃的接口名还躺在记忆里被反复引用。这不是模型变笨了而是记忆库在长期运行中被污染了——重复条目堆积、过时信息占位、跨会话的局部视角拼不出全局。Claude Code 开发者大会Code w/ Claude上Anthropic 把 Managed Agents 的三项进化摆到了台面上Dreaming复盘学习、Outcomes结果评估、Multi-agent Orchestration多智能体编排。这三件事对应的正是长期运行 Agent 的三个痛点——记不住经验、不知道自己干得好不好、复杂任务单线程跑不动。本文不聊发布会通稿直接给你能落地的配置片段和验证步骤帮你在本地把“做梦”式任务规划和结果收敛流程复现出来。适合谁看已经在用 Claude Code 做多文件、多会话工程的开发者正在评估 Managed Agents 能不能进生产流程的团队技术负责人以及被 Agent 记忆混乱折磨过、想搞清楚 Dreaming 到底怎么工作的同学。核心检索词就三个Claude Code、Managed Agents、Dreaming后面会围绕它们把 Outcomes 和 Multi-agent Orchestration 串成一条可执行的链路。先说结论Dreaming 不是上下文压缩的升级版它是一个跨会话、跨智能体、定期异步运行的记忆重构流程。它会读取现有记忆库加上过去最多 100 个会话的完整记录输出一份全新的记忆库副本——注意是副本原始记忆不动你可以审完再决定要不要采纳。这个设计很关键后面配置时会用到。2. TaoToken 前置把 Managed Agents 的调用链路接起来在本地复现这三项能力之前得先把请求链路打通。Managed Agents 的接口走 Claude Platform API需要一个能稳定访问的入口。我这边用的是 TaoToken 作为统一接入层官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 这个不加 UTM直接配到 Base URL 里。为什么先讲这个而不是直接上 Agent 配置因为 Managed Agents 的 beta 能力需要特定的 header 和模型 ID如果 Base URL 和 Key 没配对后面所有验证都会卡在 401 或者 model not found 上。我试过在没配好的情况下直接跑 Dreaming 的 session 订阅结果连 session_id 都拿不到排查了半天才发现是鉴权层的问题。你需要准备三样东西这也是后面所有配置的“三件套”第一Base URL。填https://taotoken.net/api注意结尾不要带斜杠很多 SDK 会自动拼接/v1/messages多一个斜杠会 404。第二API Key。在 https://taotoken.net/api-keys 生成格式通常是一串以特定前缀开头的字符串。生成后立刻复制页面刷新就看不到了。第三Model ID。Managed Agents 相关能力目前挂在 Claude 的较新模型上具体 ID 以你账号下/v1/models返回的为准。可以用下面这条命令先探一下curl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 | jq .data[].id返回列表里挑一个带claude且版本较新的 ID记下来后面配置里的model字段就填它。如果这条命令返回 401说明 Key 没生效或者 header 拼错了返回空列表多半是 Base URL 写成了带/v1的完整路径导致重复拼接。对于长期跑编码和 Agent 任务的场景可以考虑 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite 它在多会话、长上下文的调用上更划算。如果你只是想先验证模型对话行为用模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite 快速试一下也行。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite 遇到 header 细节可以对照查。这里要提醒一句Managed Agents 的 beta 能力需要在请求头里带上anthropic-beta: managed-agents-2026-04-01少了这个 headerDreaming 和 Outcomes 的接口会直接返回 400提示 feature not enabled。这个坑我在第一次配的时候踩过报错信息很含糊只说 invalid request实际是 beta header 缺失。3. 可复制配置Dreaming、Outcomes 与多智能体编排的落地片段这一节是全文的技术核心给你三份可以直接抄的配置。先说清楚路径约定我本地把 Agent 相关配置统一放在~/.claude/agents/下Managed Agents 的运行时配置放在项目根目录的.managed-agents/里。你可以按自己的习惯改但下面片段里的路径要和你的实际目录一致否则加载会失败。3.1 Dreaming 的 JSON 配置片段Dreaming 的核心是instructions字段它决定这次“做梦”聚焦什么。下面这份配置放在.managed-agents/dreaming.json{ dreaming: { enabled: true, schedule: 0 3 * * *, source_memory_store: ~/.claude/agents/memory.json, output_memory_store: ~/.claude/agents/memory.dreamed.json, max_sessions_scan: 100, instructions: 聚焦最近两周内与构建失败相关的记忆条目合并重复的错误处理模式标记已废弃的接口引用。保留所有与认证流程相关的条目不要合并。, review_mode: manual, beta_header: managed-agents-2026-04-01 } }几个字段解释一下。schedule用的是 cron 表达式这里表示每天凌晨 3 点跑一次异步执行不阻塞主流程。source_memory_store是原始记忆库output_memory_store是输出副本——注意这两个必须不同Dreaming 不会原地修改这是它的安全设计。review_mode设成manual表示产出后等你审核设成auto则自动采纳生产环境建议先 manual 跑一段时间。instructions是这份配置里最值得花时间写的部分。它相当于告诉 Agent“做什么梦”。你可以聚焦特定模块、特定时间范围、特定任务类型。因为原始记忆库从不被修改理论上你可以基于同一份原始记忆跑多次 Dreaming每次换不同的 instructions产出不同维度的优化结果。比如一次专门合并重复项一次专门挖掘跨会话的高效工作流。3.2 Outcomes 的评估标准配置Outcomes 的关键是 rubric也就是“什么算成功”。下面这份放在.managed-agents/outcomes.toml[outcomes] enabled true max_iterations 3 beta_header managed-agents-2026-04-01 [outcomes.rubric] name release-note-quality criteria [ 每个变更条目必须包含对应的 PR 编号, 破坏性变更必须单独成段并标注 BREAKING, 不得出现未验证的性能数字, 语气与上一版 Release Note 保持一致 ] [outcomes.webhook] url https://your-endpoint.example.com/outcomes/callback on [completed, failed]max_iterations控制成本超过次数还没达标就停下并上报。评分模块在独立的上下文窗口里运行和执行任务的 Agent 完全隔离所以不会受 Agent 自身推理过程的干扰。如果输出不符合标准评分模块会指出具体哪条 criteria 没过Agent 重新处理后再评直到达标或触顶。Webhook 那段是可选的但强烈建议配上。你可以预先设定成果目标后让 Agent 自主运行任务完成后通过 Webhook 收通知不用一直盯着。on字段里completed和failed都监听失败时能第一时间知道。3.3 多智能体编排的 settings 片段多智能体编排采用“主导-专项”模式。主导 Agent 拆任务专项子 Agent 并行执行。下面这份放在.managed-agents/orchestration.json{ orchestration: { enabled: true, lead: { model: claude-sonnet-4-5, max_sub_agents: 4, shared_fs: ./workspace }, sub_agents: [ { name: log-scanner, model: claude-haiku-4-5, tools: [read_file, grep], scope: ./workspace/logs }, { name: deploy-checker, model: claude-haiku-4-5, tools: [read_file, bash], scope: ./workspace/deploys }, { name: metrics-analyst, model: claude-sonnet-4-5, tools: [read_file, python], scope: ./workspace/metrics } ], trace: { enabled: true, store: ./workspace/.traces } } }这里有个模型分配策略值得说不是所有子 Agent 都要用大模型。像日志扫描、部署历史检查这种模式识别类任务用 Haiku 这类小模型足够成本和延迟都低而指标分析、需要推理的任务再上 Sonnet。shared_fs是共享文件系统子 Agent 在上面并行读写权限边界要提前划好别让扫描日志的 Agent 有权限改部署文件。trace打开后每一步由哪个 Agent 执行、什么顺序、什么原因都能追溯。这个在 Claude Console 里也有对应的溯源视图调试编排链路时非常有用。三件套再强调一遍Base URL 填https://taotoken.net/apiKey 从 API Keys 页面拿Model ID 用/v1/models探出来的那个。这三样在 Dreaming、Outcomes、编排配置里都要对应上任何一处不一致都会导致请求失败。4. 验证请求从 session_id 到成功结果配置写完不代表能跑。这一节给你完整的验证步骤从发请求到看到结果每一步都有预期输出。4.1 触发一次 Dreaming 并订阅事件流Dreaming 任务启动后会暴露一个session_id你可以流式订阅完整事件流实时看到 Agent 在读哪些记忆、写哪些新条目。先触发curl -X POST https://taotoken.net/api/v1/managed-agents/dreaming \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 \ -H anthropic-beta: managed-agents-2026-04-01 \ -H content-type: application/json \ -d .managed-agents/dreaming.json预期返回里会有一个session_id字段形如dream_sess_xxxxxxxx。拿到后订阅事件流curl -N https://taotoken.net/api/v1/managed-agents/sessions/$SESSION_ID/events \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H anthropic-beta: managed-agents-2026-04-01 \ -H accept: text/event-stream你会看到类似memory.read、memory.write、pattern.detected这样的事件逐条推过来。如果发现某条写入不对随时可以取消任务——这就是“叫醒”机制。任务完成后底层会话会被归档事后还能回看完整的梦境记录。4.2 验证 Outcomes 的迭代收敛Outcomes 的验证更直观。先准备一个故意有瑕疵的输入比如一份缺 PR 编号的 Release Note 草稿然后触发评估curl -X POST https://taotoken.net/api/v1/managed-agents/outcomes/evaluate \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H anthropic-beta: managed-agents-2026-04-01 \ -H content-type: application/json \ -d { rubric: release-note-quality, input_file: ./workspace/release-note.md, max_iterations: 3 }预期返回里会有iterations字段和每轮的failed_criteria。第一轮大概率会指出“缺少 PR 编号”Agent 修正后第二轮通过。如果三轮都没过返回status: max_iterations_reached这时候要看是哪条 criteria 一直卡住多半是 rubric 写得不够明确。4.3 验证多智能体编排的并行执行编排的验证看 trace。触发一个调查任务curl -X POST https://taotoken.net/api/v1/managed-agents/orchestrate \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H anthropic-beta: managed-agents-2026-04-01 \ -H content-type: application/json \ -d { task: 调查最近一次构建失败的根因, config: .managed-agents/orchestration.json }跑完后看./workspace/.traces下的记录应该能看到三个子 Agent 的并行时间线——log-scanner、deploy-checker、metrics-analyst 的启动时间几乎重叠而不是串行排队。主导 Agent 在中间会做状态同步最终汇总成一份根因报告。如果 trace 里子 Agent 是串行执行的检查max_sub_agents是不是设成了 1或者共享文件系统有锁冲突。成功结果的判断标准很简单Dreaming 产出memory.dreamed.json且条目数少于原始库说明合并生效Outcomes 返回status: passed且 iterations 小于等于 max编排 trace 里子 Agent 时间线重叠。三个都满足说明链路通了。5. 本篇常见错排查401、local proxy failed 与 reading choices配置和验证跑下来最容易卡在几个固定报错上。这一节按真实报错对照排查都是我实际遇到过的。401 Unauthorized。最常见的原因是 Key 没带上或者带错了。检查三处环境变量TAOTOKEN_API_KEY是否在当前 shell 生效echo $TAOTOKEN_API_KEY看有没有值header 里是不是写成了Authorization: Bearer加空格加 KeyKey 本身有没有过期。还有一种隐蔽情况Base URL 写成了https://taotoken.net/api/带尾斜杠SDK 拼接后变成//v1/messages有些网关会返回 401 而不是 404容易误判。改成不带尾斜杠即可。local proxy failed。这个报错通常出现在你本地配了转发层的情况下。如果你在 settings 里配了HTTP_PROXY或HTTPS_PROXY指向本地某个端口而那个端口没起来请求就会在本地就失败。排查方法临时unset HTTP_PROXY HTTPS_PROXY再跑一次如果通了就是转发层的问题。另外检查.managed-agents/下的配置里有没有硬编码的本地地址比如http://127.0.0.1:8080这种在换机器后会直接失效。reading choices 相关报错。这个一般出现在 Outcomes 的评分模块返回结构不符合预期时。典型报错是failed to read choices from response原因是评分模块的输出被截断或者格式不对。检查max_iterations是不是设得太小导致评分没跑完就中断检查 rubric 的 criteria 是不是写得太模糊导致评分模块反复纠结。把 criteria 改得更具体比如把“语气一致”改成“不得使用感叹号段落开头用动词”通常能解决。OAuth 相关报错。如果你用的是 Claude Code 的 OAuth 登录态而不是 API Key在调 Managed Agents 的 beta 接口时可能会遇到oauth token not authorized for managed-agents。原因是 OAuth 的 scope 和 API Key 不同beta 能力需要 API Key 的权限。解决办法是切到 API Key 鉴权在配置里显式指定auth_mode: api_key。这也是为什么前面强调三件套要配全——Base URL、Key、Model ID 缺一不可OAuth 和 API Key 不能混用。CC Switch / Cline MCP / Codex auth.json 场景。如果你是通过这些工具间接调 Managed Agents配置要写全三件套。以 CC Switch 为例它的配置文件里需要同时有base_url、api_key、model三个字段少一个就会 fallback 到默认值然后报错。Cline 的 MCP 配置里env段要带上ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY。Codex 的auth.json里则是api_base和api_key两个键。这些工具的字段名不一样但本质都是三件套对照着填就行。排查顺序建议先确认 401鉴权层再确认 beta header能力层最后看业务逻辑报错配置层。大部分问题在前两步就能定位。6. 把三项能力串成闭环从验证到长期运行三项能力单独跑通只是第一步真正的价值在叠加效应。多智能体编排让复杂任务被拆解并行处理Outcomes 为每个环节提供独立的质量把关和自动迭代Dreaming 在任务间隙复盘全局、沉淀经验、避免同样的错误在下一轮重演。三者合起来是一个正向飞轮不重复犯错、能自我评估、能群体协作。落地路径我建议分三步走。第一步找团队里一个高频重复、成功标准容易定义的任务比如每周的 Release Note 或者 API 文档更新用 Outcomes 定义 rubric 跑起来先感受自动迭代的效果。第二步识别一个数据源分散、需要同时查多个系统的任务比如系统事故调查或跨仓库代码审计用多智能体编排并行化配合 trace 观察子 Agent 的行为路径。第三步等前两步稳定运行一段时间、积累了足够的会话记录后再开 Dreaming让它去复盘这些记录、合并重复、挖掘规律。顺序别反没有足够的会话数据Dreaming 的输入不够产出质量也上不去。长期运行还要关注几个工程细节。共享文件系统的权限边界要提前划好扫描类子 Agent 只给读权限别让它有写权限。编排链路的失败恢复机制要设计某个子 Agent 挂了主导 Agent 是重试还是降级得在配置里明确。Dreaming 的 review_mode 在生产环境先保持 manual人工审核几轮确认产出质量稳定后再考虑 auto。最后说个实际经验这三项能力目前 Dreaming 还在研究预览阶段需要申请访问权限Outcomes 和多智能体编排在公测中通过 Claude Platform API 配合 beta header 使用。如果你的团队已经在跑长期的多智能体流程现在正是申请 Dreaming 试用的窗口因为它的效果在跨会话、跨智能体的记忆管理场景下最明显。配置片段和验证步骤上面都给全了照着跑一遍你应该能在本地看到“做梦”式任务规划从触发到收敛的完整过程。 
长河君 · 2026/10/18 9:28:00 · 阅读 1.2k Claude Code开发者大会系列3｜Managed Agents的“做梦”机制：三项核心进化拆解
1. 从“记忆污染”说起为什么 Managed Agents 需要 Dreaming如果你深度用过 Claude Code 或者任何长时间运行的 Agent大概率撞过同一堵墙跑了几十轮之后Agent 开始“犯迷糊”。同一个偏好你上周刚纠正过这周它又忘了两个子任务里记下的配置互相打架早期已经废弃的接口名还躺在记忆里被反复引用。这不是模型变笨了而是记忆库在长期运行中被污染了——重复条目堆积、过时信息占位、跨会话的局部视角拼不出全局。Claude Code 开发者大会Code w/ Claude上Anthropic 把 Managed Agents 的三项进化摆到了台面上Dreaming复盘学习、Outcomes结果评估、Multi-agent Orchestration多智能体编排。这三件事对应的正是长期运行 Agent 的三个痛点——记不住经验、不知道自己干得好不好、复杂任务单线程跑不动。本文不聊发布会通稿直接给你能落地的配置片段和验证步骤帮你在本地把“做梦”式任务规划和结果收敛流程复现出来。适合谁看已经在用 Claude Code 做多文件、多会话工程的开发者正在评估 Managed Agents 能不能进生产流程的团队技术负责人以及被 Agent 记忆混乱折磨过、想搞清楚 Dreaming 到底怎么工作的同学。核心检索词就三个Claude Code、Managed Agents、Dreaming后面会围绕它们把 Outcomes 和 Multi-agent Orchestration 串成一条可执行的链路。先说结论Dreaming 不是上下文压缩的升级版它是一个跨会话、跨智能体、定期异步运行的记忆重构流程。它会读取现有记忆库加上过去最多 100 个会话的完整记录输出一份全新的记忆库副本——注意是副本原始记忆不动你可以审完再决定要不要采纳。这个设计很关键后面配置时会用到。2. TaoToken 前置把 Managed Agents 的调用链路接起来在本地复现这三项能力之前得先把请求链路打通。Managed Agents 的接口走 Claude Platform API需要一个能稳定访问的入口。我这边用的是 TaoToken 作为统一接入层官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 这个不加 UTM直接配到 Base URL 里。为什么先讲这个而不是直接上 Agent 配置因为 Managed Agents 的 beta 能力需要特定的 header 和模型 ID如果 Base URL 和 Key 没配对后面所有验证都会卡在 401 或者 model not found 上。我试过在没配好的情况下直接跑 Dreaming 的 session 订阅结果连 session_id 都拿不到排查了半天才发现是鉴权层的问题。你需要准备三样东西这也是后面所有配置的“三件套”第一Base URL。填https://taotoken.net/api注意结尾不要带斜杠很多 SDK 会自动拼接/v1/messages多一个斜杠会 404。第二API Key。在 https://taotoken.net/api-keys 生成格式通常是一串以特定前缀开头的字符串。生成后立刻复制页面刷新就看不到了。第三Model ID。Managed Agents 相关能力目前挂在 Claude 的较新模型上具体 ID 以你账号下/v1/models返回的为准。可以用下面这条命令先探一下curl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 | jq .data[].id返回列表里挑一个带claude且版本较新的 ID记下来后面配置里的model字段就填它。如果这条命令返回 401说明 Key 没生效或者 header 拼错了返回空列表多半是 Base URL 写成了带/v1的完整路径导致重复拼接。对于长期跑编码和 Agent 任务的场景可以考虑 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite 它在多会话、长上下文的调用上更划算。如果你只是想先验证模型对话行为用模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite 快速试一下也行。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite 遇到 header 细节可以对照查。这里要提醒一句Managed Agents 的 beta 能力需要在请求头里带上anthropic-beta: managed-agents-2026-04-01少了这个 headerDreaming 和 Outcomes 的接口会直接返回 400提示 feature not enabled。这个坑我在第一次配的时候踩过报错信息很含糊只说 invalid request实际是 beta header 缺失。3. 可复制配置Dreaming、Outcomes 与多智能体编排的落地片段这一节是全文的技术核心给你三份可以直接抄的配置。先说清楚路径约定我本地把 Agent 相关配置统一放在~/.claude/agents/下Managed Agents 的运行时配置放在项目根目录的.managed-agents/里。你可以按自己的习惯改但下面片段里的路径要和你的实际目录一致否则加载会失败。3.1 Dreaming 的 JSON 配置片段Dreaming 的核心是instructions字段它决定这次“做梦”聚焦什么。下面这份配置放在.managed-agents/dreaming.json{ dreaming: { enabled: true, schedule: 0 3 * * *, source_memory_store: ~/.claude/agents/memory.json, output_memory_store: ~/.claude/agents/memory.dreamed.json, max_sessions_scan: 100, instructions: 聚焦最近两周内与构建失败相关的记忆条目合并重复的错误处理模式标记已废弃的接口引用。保留所有与认证流程相关的条目不要合并。, review_mode: manual, beta_header: managed-agents-2026-04-01 } }几个字段解释一下。schedule用的是 cron 表达式这里表示每天凌晨 3 点跑一次异步执行不阻塞主流程。source_memory_store是原始记忆库output_memory_store是输出副本——注意这两个必须不同Dreaming 不会原地修改这是它的安全设计。review_mode设成manual表示产出后等你审核设成auto则自动采纳生产环境建议先 manual 跑一段时间。instructions是这份配置里最值得花时间写的部分。它相当于告诉 Agent“做什么梦”。你可以聚焦特定模块、特定时间范围、特定任务类型。因为原始记忆库从不被修改理论上你可以基于同一份原始记忆跑多次 Dreaming每次换不同的 instructions产出不同维度的优化结果。比如一次专门合并重复项一次专门挖掘跨会话的高效工作流。3.2 Outcomes 的评估标准配置Outcomes 的关键是 rubric也就是“什么算成功”。下面这份放在.managed-agents/outcomes.toml[outcomes] enabled true max_iterations 3 beta_header managed-agents-2026-04-01 [outcomes.rubric] name release-note-quality criteria [ 每个变更条目必须包含对应的 PR 编号, 破坏性变更必须单独成段并标注 BREAKING, 不得出现未验证的性能数字, 语气与上一版 Release Note 保持一致 ] [outcomes.webhook] url https://your-endpoint.example.com/outcomes/callback on [completed, failed]max_iterations控制成本超过次数还没达标就停下并上报。评分模块在独立的上下文窗口里运行和执行任务的 Agent 完全隔离所以不会受 Agent 自身推理过程的干扰。如果输出不符合标准评分模块会指出具体哪条 criteria 没过Agent 重新处理后再评直到达标或触顶。Webhook 那段是可选的但强烈建议配上。你可以预先设定成果目标后让 Agent 自主运行任务完成后通过 Webhook 收通知不用一直盯着。on字段里completed和failed都监听失败时能第一时间知道。3.3 多智能体编排的 settings 片段多智能体编排采用“主导-专项”模式。主导 Agent 拆任务专项子 Agent 并行执行。下面这份放在.managed-agents/orchestration.json{ orchestration: { enabled: true, lead: { model: claude-sonnet-4-5, max_sub_agents: 4, shared_fs: ./workspace }, sub_agents: [ { name: log-scanner, model: claude-haiku-4-5, tools: [read_file, grep], scope: ./workspace/logs }, { name: deploy-checker, model: claude-haiku-4-5, tools: [read_file, bash], scope: ./workspace/deploys }, { name: metrics-analyst, model: claude-sonnet-4-5, tools: [read_file, python], scope: ./workspace/metrics } ], trace: { enabled: true, store: ./workspace/.traces } } }这里有个模型分配策略值得说不是所有子 Agent 都要用大模型。像日志扫描、部署历史检查这种模式识别类任务用 Haiku 这类小模型足够成本和延迟都低而指标分析、需要推理的任务再上 Sonnet。shared_fs是共享文件系统子 Agent 在上面并行读写权限边界要提前划好别让扫描日志的 Agent 有权限改部署文件。trace打开后每一步由哪个 Agent 执行、什么顺序、什么原因都能追溯。这个在 Claude Console 里也有对应的溯源视图调试编排链路时非常有用。三件套再强调一遍Base URL 填https://taotoken.net/apiKey 从 API Keys 页面拿Model ID 用/v1/models探出来的那个。这三样在 Dreaming、Outcomes、编排配置里都要对应上任何一处不一致都会导致请求失败。4. 验证请求从 session_id 到成功结果配置写完不代表能跑。这一节给你完整的验证步骤从发请求到看到结果每一步都有预期输出。4.1 触发一次 Dreaming 并订阅事件流Dreaming 任务启动后会暴露一个session_id你可以流式订阅完整事件流实时看到 Agent 在读哪些记忆、写哪些新条目。先触发curl -X POST https://taotoken.net/api/v1/managed-agents/dreaming \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 \ -H anthropic-beta: managed-agents-2026-04-01 \ -H content-type: application/json \ -d .managed-agents/dreaming.json预期返回里会有一个session_id字段形如dream_sess_xxxxxxxx。拿到后订阅事件流curl -N https://taotoken.net/api/v1/managed-agents/sessions/$SESSION_ID/events \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H anthropic-beta: managed-agents-2026-04-01 \ -H accept: text/event-stream你会看到类似memory.read、memory.write、pattern.detected这样的事件逐条推过来。如果发现某条写入不对随时可以取消任务——这就是“叫醒”机制。任务完成后底层会话会被归档事后还能回看完整的梦境记录。4.2 验证 Outcomes 的迭代收敛Outcomes 的验证更直观。先准备一个故意有瑕疵的输入比如一份缺 PR 编号的 Release Note 草稿然后触发评估curl -X POST https://taotoken.net/api/v1/managed-agents/outcomes/evaluate \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H anthropic-beta: managed-agents-2026-04-01 \ -H content-type: application/json \ -d { rubric: release-note-quality, input_file: ./workspace/release-note.md, max_iterations: 3 }预期返回里会有iterations字段和每轮的failed_criteria。第一轮大概率会指出“缺少 PR 编号”Agent 修正后第二轮通过。如果三轮都没过返回status: max_iterations_reached这时候要看是哪条 criteria 一直卡住多半是 rubric 写得不够明确。4.3 验证多智能体编排的并行执行编排的验证看 trace。触发一个调查任务curl -X POST https://taotoken.net/api/v1/managed-agents/orchestrate \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H anthropic-beta: managed-agents-2026-04-01 \ -H content-type: application/json \ -d { task: 调查最近一次构建失败的根因, config: .managed-agents/orchestration.json }跑完后看./workspace/.traces下的记录应该能看到三个子 Agent 的并行时间线——log-scanner、deploy-checker、metrics-analyst 的启动时间几乎重叠而不是串行排队。主导 Agent 在中间会做状态同步最终汇总成一份根因报告。如果 trace 里子 Agent 是串行执行的检查max_sub_agents是不是设成了 1或者共享文件系统有锁冲突。成功结果的判断标准很简单Dreaming 产出memory.dreamed.json且条目数少于原始库说明合并生效Outcomes 返回status: passed且 iterations 小于等于 max编排 trace 里子 Agent 时间线重叠。三个都满足说明链路通了。5. 本篇常见错排查401、local proxy failed 与 reading choices配置和验证跑下来最容易卡在几个固定报错上。这一节按真实报错对照排查都是我实际遇到过的。401 Unauthorized。最常见的原因是 Key 没带上或者带错了。检查三处环境变量TAOTOKEN_API_KEY是否在当前 shell 生效echo $TAOTOKEN_API_KEY看有没有值header 里是不是写成了Authorization: Bearer加空格加 KeyKey 本身有没有过期。还有一种隐蔽情况Base URL 写成了https://taotoken.net/api/带尾斜杠SDK 拼接后变成//v1/messages有些网关会返回 401 而不是 404容易误判。改成不带尾斜杠即可。local proxy failed。这个报错通常出现在你本地配了转发层的情况下。如果你在 settings 里配了HTTP_PROXY或HTTPS_PROXY指向本地某个端口而那个端口没起来请求就会在本地就失败。排查方法临时unset HTTP_PROXY HTTPS_PROXY再跑一次如果通了就是转发层的问题。另外检查.managed-agents/下的配置里有没有硬编码的本地地址比如http://127.0.0.1:8080这种在换机器后会直接失效。reading choices 相关报错。这个一般出现在 Outcomes 的评分模块返回结构不符合预期时。典型报错是failed to read choices from response原因是评分模块的输出被截断或者格式不对。检查max_iterations是不是设得太小导致评分没跑完就中断检查 rubric 的 criteria 是不是写得太模糊导致评分模块反复纠结。把 criteria 改得更具体比如把“语气一致”改成“不得使用感叹号段落开头用动词”通常能解决。OAuth 相关报错。如果你用的是 Claude Code 的 OAuth 登录态而不是 API Key在调 Managed Agents 的 beta 接口时可能会遇到oauth token not authorized for managed-agents。原因是 OAuth 的 scope 和 API Key 不同beta 能力需要 API Key 的权限。解决办法是切到 API Key 鉴权在配置里显式指定auth_mode: api_key。这也是为什么前面强调三件套要配全——Base URL、Key、Model ID 缺一不可OAuth 和 API Key 不能混用。CC Switch / Cline MCP / Codex auth.json 场景。如果你是通过这些工具间接调 Managed Agents配置要写全三件套。以 CC Switch 为例它的配置文件里需要同时有base_url、api_key、model三个字段少一个就会 fallback 到默认值然后报错。Cline 的 MCP 配置里env段要带上ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY。Codex 的auth.json里则是api_base和api_key两个键。这些工具的字段名不一样但本质都是三件套对照着填就行。排查顺序建议先确认 401鉴权层再确认 beta header能力层最后看业务逻辑报错配置层。大部分问题在前两步就能定位。6. 把三项能力串成闭环从验证到长期运行三项能力单独跑通只是第一步真正的价值在叠加效应。多智能体编排让复杂任务被拆解并行处理Outcomes 为每个环节提供独立的质量把关和自动迭代Dreaming 在任务间隙复盘全局、沉淀经验、避免同样的错误在下一轮重演。三者合起来是一个正向飞轮不重复犯错、能自我评估、能群体协作。落地路径我建议分三步走。第一步找团队里一个高频重复、成功标准容易定义的任务比如每周的 Release Note 或者 API 文档更新用 Outcomes 定义 rubric 跑起来先感受自动迭代的效果。第二步识别一个数据源分散、需要同时查多个系统的任务比如系统事故调查或跨仓库代码审计用多智能体编排并行化配合 trace 观察子 Agent 的行为路径。第三步等前两步稳定运行一段时间、积累了足够的会话记录后再开 Dreaming让它去复盘这些记录、合并重复、挖掘规律。顺序别反没有足够的会话数据Dreaming 的输入不够产出质量也上不去。长期运行还要关注几个工程细节。共享文件系统的权限边界要提前划好扫描类子 Agent 只给读权限别让它有写权限。编排链路的失败恢复机制要设计某个子 Agent 挂了主导 Agent 是重试还是降级得在配置里明确。Dreaming 的 review_mode 在生产环境先保持 manual人工审核几轮确认产出质量稳定后再考虑 auto。最后说个实际经验这三项能力目前 Dreaming 还在研究预览阶段需要申请访问权限Outcomes 和多智能体编排在公测中通过 Claude Platform API 配合 beta header 使用。如果你的团队已经在跑长期的多智能体流程现在正是申请 Dreaming 试用的窗口因为它的效果在跨会话、跨智能体的记忆管理场景下最明显。配置片段和验证步骤上面都给全了照着跑一遍你应该能在本地看到“做梦”式任务规划从触发到收敛的完整过程。