Claude学会做梦自我进化了，能自己拆活、自己验收

今天凌晨，Anthropic 在旧金山的 Code with Claude 开发者大会上，把 Claude Agent 往云端又推了一大步。

这次主角已经不是 Claude Code，而是 Claude Managed Agents——Anthropic 托管的云端 Agent 运行平台。

Claude Code大家都熟悉，它部署在本地，通过调用大模型 API 来帮助大家写代码干活儿。

而 Claude Managed Agents 则是Anthropic托管的云端Agent运行平台。开发者可以直接定义一个Agent，再给他配一个自己的“电脑”（云端运行环境），之后通过简单的 API 接口持续使用这个Agent。

以前你电脑里跑一个 Claude Code。现在它在云端帮你跑 100 个，而且这 100 个 Agent 之间还能互相分工、互相验收、互相整理记忆。

四舍五入，这就是「无限 Claude Code + 无限子 Agent」的产线，也就是这次大会的主菜。理解了Managed Agents，再看这次大会的新功能，就顺了。

为了让这批 Agent 真正跑起来，Anthropic 一次性补上了 4 项能力：Dreaming（记忆整理）、Outcomes（结果验收）、Multi-agent orchestration（多智能体分工），还有 Webhooks（外部通知），分别回答了下面4个问题：

• Agent跑久了，记忆怎么整理？
• Agent干完活，结果怎么验收？
• 一个Agent干不动，任务怎么分工？
• Agent跑完以后，外部系统怎么知道？

◈一、记忆的制度：Claude 有了「昨天」

先说 Dreaming 吧，这次仍然是研究预览（Research Preview）阶段。

Anthropic 官方的说法是，Dreaming 是一个定时运行的过程，会回看 agent sessions 和 memory stores，从过去的工作记录里提取模式，整理记忆，让 Agent 在之后的任务里表现得更稳定。开发者可以让它自动更新记忆，也可以先审核再决定是否采纳。

这跟我们之前Claude code里的 autoDream 很接近。

但区别在于，cc 里的东西更像内部机制；而新版本明显加了产品层。这次的 Dreaming 是一个定时跑的异步任务。它会同时读 Agent 现有的记忆库，加上过去最多 100 个会话的完整记录，然后输出一份新的记忆库。

干 3 件事：

• 合并重复条目
• 用最新值替换矛盾内容
• 从历史会话里挖单 Agent 看不到的宏观规律

注意是「输出新的」，原记忆库不动，开发者审核后再决定要不要采纳。

这个细节很重要，因为 Agent 的记忆不是越多越好。跑久了以后，记忆库里会出现重复、过时、矛盾的内容。

Dreaming 做的是把 Agent 一次次任务里的临时经验，整理成下一次可以复用的长期知识。而且，这个长期知识可以通过 API 给任何你在云端制造的新Claude code拿去复用。

这个做梦，就可以让云端的 cc 集体复盘，集体拥有昨天的记忆了。

◈二、Outcomes：干完活，还要有人判卷

但光会有记忆还不够。

有时候你让 Agent 写报告，它写了；让它改代码，它改了；问它「完成了吗」它大概率会说完成了。

但——它说完成 ≠ 真的完成。

Outcomes（公测版）就是来解决这个的。

它的机制是，让开发者先定义 outcome，也就是“什么叫完成”；再写一份 rubric，描述成功标准和评分维度。

等 Agent 完成任务后，再调用一个独立的 grader 在上下文窗口里，对照标准给结果打分。如果结果不合格，grader 会指出哪里要改，干活的 Agent 再来一轮。

其实，过去很多 Agent 都会“自我检查”，但自己做、自己查、自己宣布成功，天然容易放水。于是，Outcomes 把执行和验收拆开了。

这背后其实是非常传统的组织原则。

人类公司为什么有 code review、QA、审计、合规、考试、验收？

因为执行者和评价者不能完全是同一个人。Outcomes 就是把这个组织原则放进了 Agent 系统。

Anthropic 的内部测试数据是，Outcomes 相比标准 prompt loop，任务成功率最多提升 10 个百分点；文件生成场景里，docx 任务成功率提升 8.4%，pptx 提升 10.1%。

有了Outcomes，每个在云端干活的新 Claude code 自然可以让我们更放心一些。

◈三、Multi-agent：一个 Agent 不够，就组队干

记忆能整理、结果能验收。那如果任务本身太大、一个 Agent 干不动呢？

Anthropic 的解决办法是 Multi-agent orchestration。简单讲就是当任务太大，只调用一个云端 Agent 干不动的时候，就让一个 lead agent 负责拆任务，再分给多个 specialist agents。

等等，怎么有点眼熟，类似于subagent？

确实像。

但这里要注意一个区别：Claude Code 里的 subagent，更像是本地工具链里的“分身”；而Managed Agents 里的 multi-agent orchestration，则是云端平台里的“组织结构”。

Claude Code 的 subagent 是你在一个开发环境里，临时拉几个不同角色的助手来干活；而Managed Agents 的 multi-agent，是开发者可以在 API 层定义一组长期存在的 Agent：谁是 lead，谁是 specialist，各自用什么模型、什么提示词、什么工具、什么权限，甚至接什么 MCP server。

这就不是“一个 Claude 叫来几个小 Claude”这么简单了。

它更像是，你自己在云端搭了一支Claude code小队。

一个 lead agent 负责拆任务、分派任务、汇总结果；多个 specialist agents 各自拿着独立上下文去并行推进。

https://teamoteam.com/

多Agent编排这个方向，国内率先做的是Teamo，去年就上线产品了——队长拆任务、专业小组并行执行、结果汇总回队长。Anthropic这次是把同样的思路做进了API级的基础设施里。

如果以前，Claude code本地的思路是让一个 Agent 假装自己是一个部门，那Multi-agent 的思路是就是让 Agent 真的变成一个部门。而且开发者可以在 Claude Console 里能追踪每一步：哪个 Agent 干了什么，按什么顺序，为什么这么做。

这和人类公司非常像。只不过以前分工发生在人和人之间，现在分工开始发生在 Agent 和 Agent 之间。

Dreaming 解决记忆。

Outcomes 解决验收。

Multi-agent 解决分工。

但这些还都发生在 Agent 们自己的世界里。真正的业务系统里，还有一个问题：Agent 跑完以后，外面的系统怎么知道？

这就要提到 Webhooks。

Managed Agents 的 sessions 是 long-running interactions。一个任务可能跑很久，而开发者不可能一直在后台盯着。Webhooks 的作用，就是在重大状态变化发生时通知外部系统。

比如，Agent 完成任务了，通知飞书；Agent 改完代码了，通知 GitHub。

这一步看起来没有 Dreaming、Outcomes、multi-agent 那么有趣，但它非常重要。

因为没有 Webhooks，Agent 就像一个很聪明但关在房间里的人。如果它干完了什么，外面没人知道，下一步就进行不下去。

有了 Webhooks，Agent 就能变成软件系统里的一个节点，我们可以随时看到，事情是否卡在这里。

到这里，Anthropic 这次的产品逻辑就真正闭环了：Agent 开始能被记忆、被验收、被分工、被系统接力。也就是说，Anthropic 在搭一条云端 Agent 产线。

Claude Code 让一个开发者在自己的电脑上拥有一个 AI 工程师。而 Managed Agents 则让一个团队、一个产品、一个公司，在云端拥有一批可调度的 AI 工程师。

它们有记忆，有工具，有运行环境，有验收标准，还能互相协作。

当然，现在这些能力还不等于 Agent 已经能完全自治。Dreaming 还在研究预览，Outcomes 也还需要开发者写清楚评分标准，Multi-agent 也不是无限递归的子 Agent 宇宙。

但方向已经很清楚了。

以前，Claude Code 让大家第一次感受到，它真的进项目；现在，Managed Agents 往前走了一步，它想住在云端，住在 API 里，住在持续的业务流程里。

模型负责变聪明。

Claude Code 负责把聪明带到开发者电脑上。

Managed Agents 则负责把这套能力带到云端，让它可以被更多产品、更多团队、更复杂的工作流调用。

这就是一整套 Agent 生产线。