Fable5.2用1000 个 Agent 不是 1000 个程序员，多agent到底怎么个“多”法？

2026 年 11 月 9 日，Anthropic 发布 Claude Fable 5.2，并披露了一项内部实验。实验从一个空文件夹开始，Fable 5.2 协调超过 1000 个子 Agent，连续工作 8 天，最终做出一个能在笔记本电脑上启动的操作系统原型。

核心价值：本文不复述宣传，而是结合 Anthropic 公开的多 Agent 工程资料，讲清楚 Orchestrator、Subagent、Advisor、Workflow 各自的角色，说明任务该怎么拆、成本为什么会涨、可靠性怎么设计。最后给出一份开发者能直接落地的实践清单。

Claude Fable 5.2 操作系统实验核心信息速览

先把已经确认的事实和尚未披露的部分分开，这是理解多 Agent 协作门槛的前提。

官方的说法是 working prototype operating system，也就是“能工作的操作系统原型”，并不是成熟的商业操作系统。另外需要注意，Anthropic 同期还有其他实验，例如费马大定理相关实验披露过“1 名 Lead + 999 名 Helper”的结构，但那是独立实验，不能直接套用到操作系统项目上。

这项实验真正值得关注的地方，不在于代码写了多少，而在于模型能在 8 天里组织一个长期软件工程项目：拆分任务、并行推进、汇总成果、发现错误、安排修复。这就引出了本文的核心问题：1000 个 Agent 背后，真正难的是组织。

多 Agent 协作如何工作：Claude Fable 5.2 背后的角色分工

在讨论“要不要多 Agent”之前，需要先把几个容易混淆的概念讲清楚。下面这张表按照 Anthropic Managed Agents 文档的思路做了归纳。

多 Agent 的三种协作模式

Anthropic 的 Managed Agents 文档把多 Agent 协作分成三种模式，适用场景各不相同。

• Subagents 直接委派：主 Agent 自己决定创建哪些子 Agent、派什么任务、何时读取结果、是否追问。每个子 Agent 有独立的 Session Thread，但委派只有一层，单 Session 最多 25 个直接子线程。适合需要持续跟进的少量专业任务。
• Dynamic Workflows 动态工作流：主 Agent 不再逐个管理子 Agent，而是生成一段工作流程序。程序可以划分阶段、并发运行多个 Agent、传递结果、根据结果选择下一阶段，并在审查不通过时重复执行直到达到轮次上限。适合大规模文件审查、多模块代码迁移这类任务。
• Advisor 顾问模式：主 Agent 仍然亲自执行，只在困难或关键节点咨询能力更强的模型。它的好处是不需要把任务拆散，协调开销最小。

可以用一个具体例子理解三者的区别。假设要把一个电商后台从 Python 迁移到 Go：只迁移支付和库存两个模块，用直接委派就够了；要迁移 200 个独立接口并逐个审查，适合动态工作流；如果只是一个工程师级 Agent 在做，偶尔需要请高级模型审一下数据库事务设计，用 Advisor 最划算。

何时增加 Agent：多 Agent 任务拆分的正确方法

Anthropic 在 2026 年 1 月 23 日的文章《Building multi-agent systems: When and how to use them》中提到一个真实现象：有团队花几个月搭建复杂的多 Agent 系统，最后发现改进单 Agent 的 Prompt 就能达到相近效果。所以第一个问题永远是“该不该拆”，而不是“拆成多少个”。

多 Agent 真正有价值的三种场景

根据这篇文章，多 Agent 能稳定创造价值的场景主要有三类：

1. 上下文隔离：例如客服 Agent 先读了大量订单历史，再去诊断技术问题，订单数据会挤占上下文、干扰判断。把订单查询交给独立 Agent，只传回必要摘要，主 Agent 就能保持清醒。
2. 并行处理：分别调研不同地区市场、并行审查不同文件、同时检查不同代码模块。Anthropic 特别指出，这类架构的主要价值往往是提高任务覆盖度和完整性，而不是保证总耗时更短。
3. 专业化分工：不同 Agent 配置不同的 System Prompt、工具、MCP Server、Skills 和模型，避免单一 Agent 同时背负太多职责。

按上下文边界拆分，而不是按角色拆分

Anthropic 提出的设计原则是 Context-centric decomposition，即按上下文边界拆分，而不是按问题环节机械拆分。很多团队的第一反应是“规划 Agent + 编码 Agent + 测试 Agent + 审查 Agent”，看起来像一个分工明确的研发团队，实际上问题很大。

测试 Agent 不知道代码为什么这样设计，审查 Agent 不了解前面的探索过程，信息在 Agent 之间反复传递，容易出现类似“电话传话”的失真。更合理的做法是：让一个 Agent 负责某个完整功能模块，包括实现和对应测试；另一个 Agent 负责一个有独立接口的模块；第三个 Agent 只做黑盒验证，拿到的是待验证成果、明确的验收标准和测试工具。

回到操作系统实验，内核、驱动、文件系统、窗口系统之间确实存在相对清晰的模块边界，这也是它比“一个复杂业务系统的大规模重构”更适合大规模并行的原因之一。当然，Anthropic 没有公开具体分工方式，这一点只能作为合理推测，不能当作事实。

多 Agent 成本为什么更高：Claude Fable 5.2 时代的 Token 账本

很多人直觉上认为，任务分给更多 Agent 并行处理，成本会被摊薄。实际情况往往相反。Anthropic 2026 年 1 月的文章明确指出：对于相同任务，多 Agent 架构通常使用单 Agent 的 3—10 倍 Token。

额外的 Token 主要来自五个地方：每个 Agent 都要建立自己的上下文；Agent 之间要交换任务描述和结果；主 Agent 要阅读并汇总多个子 Agent 的输出；任务拆解本身会产生额外调用；多个 Agent 之间还可能重复做同一部分工作。

两组成本数据，基准完全不同

讨论多 Agent 成本时，经常有人把不同来源的数据混在一起。下面这张表把它们分开：

需要强调的是，90.2% 和 15 倍这两个数字都来自 2025 年的 Research 系统，前者只是特定内部评测的相对表现，不代表所有任务准确率都提升 90.2%。它们和 2026 年的操作系统实验没有关系，也不能和 3—10 倍直接比较。

总计算量、执行时间和覆盖度是三件事

理解多 Agent 成本，需要区分三个指标。总计算量通常会上升，因为上下文被复制、结果被反复阅读；执行时间可能缩短，前提是子任务真正互相独立；任务覆盖度往往会提升，因为多个 Agent 能同时探索更多方向。

以官方 API 标价估算，Fable 5.2 普通模式输入 8 美元/百万 Token、输出 40 美元/百万 Token，Batch API 可享 50% 折扣，缓存读取为 0.20 美元/MTok。如果一个单 Agent 任务本身就要消耗可观的 Token，放大到 3—10 倍后差距会非常明显。Anthropic 没有公布操作系统实验的实际账单，所以任何“8 天花了多少钱”的说法都没有依据。

如何设计可靠的多 Agent 系统：从 Claude Fable 5.2 学到的工程方法

模型分层：不是每个 Agent 都需要最强模型

Managed Agents 支持两种 Agent 定义方式。Predefined Agent 是提前配置好的，可以拥有独立的模型、System Prompt、工具、MCP Server 和 Skills；Inline Agent 在执行时动态定义，默认沿用主 Agent 的模型和工具配置。

这意味着可以做成本与能力分层：协调者和复杂审核用 Fable 5.2 这类强模型，普通资料检索用 Sonnet 级模型，简单分类用 Haiku 级模型。这只是一种设计示例，并不是 Anthropic 规定的固定架构，需要按实际任务测试调整。

验证：审查 Agent 不等于真实验证

Anthropic 在 Fable 5.2 的 Prompting 文档中提到一个新变化：在 xhigh、max 等较高 Effort 设置下，Fable 5.2 会主动调用 Subagent 检查自己的工作，而 Fable 5.1 在相同测试任务中没有这种行为。这是编排能力上的进步，但不能把它当作质量保证。

审查 Agent 本质上还是模型判断。真正可靠的验证需要三样东西：写清楚的验收标准、能执行的黑盒测试、对代码和外部系统修改的真实检查（例如真正运行测试、真正启动服务）。操作系统实验最有说服力的一点，恰恰是“能在真实笔记本电脑上启动”这个硬性结果，而不是某个 Agent 说“看起来没问题”。

防止过度委派与规则堆积

Agent 是否委派任务，不只取决于模型能力，也受 Harness 和工具说明影响。Anthropic 测试发现，当 Subagent 工具说明写明“每个子 Agent 的额外成本、哪些任务值得委派、哪些不值得、如何描述任务”时，模型在短任务中的委派频率比只强调委派理由的版本降低约三分之一，而任务成功率保持不变。

另一个容易被忽视的问题是规则堆积。Fable 5.2 对上下文中累积的限制性指令遵循得比较严格，如果历史文件、Reviewer 意见和 System Prompt 不断叠加禁止事项，模型可能在日常工作中不敢执行本来允许的操作。所以需要定期清理 Agent 的记忆、规则和审批要求。

运行时限制：公开产品里的真实天花板

“1000 个 Agent”在公开产品里同样有明确边界。下面是 Managed Agents 文档列出的限制，它们属于公开产品，不代表内部操作系统实验使用了相同的调度器：

此外，Workflow 内的 Agent 不能再创建嵌套 Workflow；达到预算后，运行中的 Workflow 会暂停；某个 Agent 失败后系统通常会重试一次，再次失败则由工作流决定如何处理。换句话说，1000 个 Agent 是“生命周期内累计启动”，同一时刻真正在跑的远没有那么多。

长时间运行还有一个体验问题：Fable 5.2 在长时间工具调用期间可能很少输出面向用户的文本，用户会误以为任务卡住。官方建议开启 thinking.display: "updates"，或让 Harness 在连续多次工具调用后提醒模型汇报进度。官方测试中，加入进度提醒后最长连续无反馈时间大约缩短了一半。

多 Agent 快速上手：用 Claude Fable 5.2 搭一个最小编排器

下面不依赖任何托管平台，用 OpenAI 兼容接口演示最基础的一步：让协调模型按上下文边界拆分任务。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)

resp = client.chat.completions.create(
    model="claude-fable-5-2",  # 以平台模型列表中的实际名称为准
    messages=[{"role": "user", "content": "把“为博客增加评论功能”按上下文边界拆成子任务，每个子任务包含实现和测试，输出 JSON"}]
)
print(resp.choices[0].message.content)

完整版本加入了模型分层、并发执行、Token 预算、失败重试一次和黑盒验收，结构上对应前文讲的工程方法：

import json
from concurrent.futures import ThreadPoolExecutor
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # 一个 Key 调用多家模型
)

ORCHESTRATOR_MODEL = "claude-fable-5-2"   # 协调与审核用强模型
WORKER_MODEL = "your-fast-model"          # 子任务用更快更便宜的模型,按需替换
TOKEN_BUDGET = 200_000                     # 整个任务的 Token 预算
used_tokens = 0


def call(model, system, user):
    global used_tokens
    if used_tokens >= TOKEN_BUDGET:
        raise RuntimeError("超出预算,暂停工作流")
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "system", "content": system},
                  {"role": "user", "content": user}],
    )
    used_tokens += r.usage.total_tokens
    return r.choices[0].message.content


def plan(goal):
    text = call(ORCHESTRATOR_MODEL,
                "你是协调者。按上下文边界拆分任务,简单任务不要拆。"
                "只输出 JSON 数组,每项含 name、spec、acceptance 字段。",
                goal)
    return json.loads(text)


def run_subagent(task):
    # 每个子 Agent 只拿到自己需要的上下文,失败重试一次
    for _ in range(2):
        try:
            return call(WORKER_MODEL,
                        "你负责一个完整模块,同时给出实现和测试。",
                        f"任务:{task['spec']}\n验收标准:{task['acceptance']}")
        except Exception:
            continue
    return "FAILED"


def review(task, output):
    # 黑盒验收:只给成果和标准,不给探索过程
    return call(ORCHESTRATOR_MODEL,
                "你是审核者,只依据验收标准判断,输出 PASS 或 FAIL 及理由。",
                f"验收标准:{task['acceptance']}\n成果:{output}")


if __name__ == "__main__":
    tasks = plan("为博客系统增加评论功能,含后端接口与前端组件")
    with ThreadPoolExecutor(max_workers=4) as pool:  # 控制并发
        outputs = list(pool.map(run_subagent, tasks))
    for t, o in zip(tasks, outputs):
        print(t["name"], "->", review(t, o)[:80])
    print("累计 Token:", used_tokens)

这段代码只是演示结构，审核环节仍然是模型判断。在生产环境里，review 应该替换成或补充真实的测试执行，例如运行单元测试、启动服务做接口探测。

🚀 快速上手建议：多 Agent 的关键是让不同角色用不同模型，并能随时对比消耗。建议通过 API易 apiyi.com 用一个 API Key 同时接入 Claude、OpenAI、Gemini 等模型，先用新用户免费测试额度跑通单 Agent 基线，再逐步加入协作层。

多 Agent 协作对开发者的影响分析

对开发者的影响

• 从单 Agent 开始：先用单 Agent 加好的 Prompt 建立基线，只有在出现上下文被污染、子任务可独立并行、需要专业化配置这三类瓶颈时，才增加协作层。
• 把基础设施当成一等公民：模型 API、工具 API、预算上限、并发控制和调用日志，决定了多 Agent 系统能否稳定运行。没有日志，就无法定位哪个子 Agent 在重复劳动。
• 多模型分工成为常态：协调者、执行者、审核者使用不同模型，是控制 3—10 倍成本放大的主要手段之一。

对行业的影响

• AI 能力边界在扩展：从“完成一个编程任务”走向“组织一个长期软件工程项目”。Vercel、Shopify、Datadog 等早期测试伙伴的反馈也指向这一点，例如 Datadog 工程师把它形容为能向更快模型派发任务的“事故指挥官”。需要注意，这些是发布时公布的合作伙伴反馈，不是独立盲测。
• 编排能力比 Agent 数量更重要：任务可并行程度、协调开销、共享状态、代码冲突、测试覆盖率和调用成本，共同决定多 Agent 的真实效率。

常见问题 FAQ

Claude Fable 5.2 多 Agent 协作核心要点 Key Takeaways

• 数量不等于效率：1000 个 Agent 的价值在于组织能力，不在于数量本身
• 角色要分清：Orchestrator 协调、Subagent 执行、Advisor 建议、Workflow 管流程
• 按上下文边界拆分：一个 Agent 负责完整模块加测试，避免按角色传话失真
• 成本要算清：相同任务多 Agent 通常是单 Agent 的 3—10 倍 Token
• 验证要落地：审查 Agent 之外，必须有验收标准和真实测试
• 从单 Agent 起步：遇到真实瓶颈再加协作层，可通过 API易 apiyi.com 多模型接入做分层测试

总结

Claude Fable 5.2 的操作系统实验带来的启示：

1. 编排能力是新的门槛：Fable 5.2 的进步在于更能胜任协调者角色，包括在高 Effort 下主动调用子 Agent 审查自己的工作
2. 多 Agent 有明确的适用边界：上下文隔离、并行处理、专业化分工值得拆，紧密耦合任务和简单查询不值得拆
3. 成本、并发和验证是三条硬约束：Token 放大、调度上限和真实测试，决定了系统能不能长期跑下去

对于大多数开发者，正确的路径是先用单 Agent 建立基线，再根据实际瓶颈引入 Subagent、Workflow 或 Advisor，同时把模型 API、预算、并发和日志做扎实。API 基础设施才是多 Agent 应用真正的底座。

推荐通过 API易 apiyi.com 快速验证你的多 Agent 方案，平台提供 OpenAI 兼容的统一接口和新用户免费测试额度，便于在不同模型之间做分工对比。

📚 参考资料

1. Anthropic 官方发布公告：Claude Fable 5.2 and Mythos 5.2（2026-11-09）
2. 链接： anthropic.com/claude-fable-and-mythos-5-2

3. 说明： 操作系统实验、编程评测和价格的一手来源

4. Building multi-agent systems: When and how to use them：多 Agent 适用场景与成本（2026-01-23）

5. 链接： claude.com/resources/articles/building-multi-agent-systems-when-and-how-to-use-them

6. 说明： 3—10 倍 Token 数据、按上下文边界拆分的原则

7. How we built our multi-agent research system：Anthropic Research 系统（2025-06-13）

8. 链接： anthropic.com/research/multi-agent-research-system

9. 说明： Orchestrator-Worker 架构、90.2% 内部评测与 15 倍 Token 数据

10. Managed Agents 多 Agent 编排与 Workflow 文档：协作模式与运行限制

11. 链接： platform.claude.com/docs/en/managed-agents/multiagent-orchestration

12. 说明： Subagents、Dynamic Workflows、Advisor 的定义与并发上限

13. Prompting Claude Fable 5.2：官方提示工程指南

14. 链接： platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-2

15. 说明： 自我审查行为、过度委派实验、进度反馈建议

16. Fable 5.2 模型规格文档：上下文、输出上限与计费

17. 链接： platform.claude.com/docs/en/models/fable-5-2/overview
18. 说明： 1M 上下文、128K 最大输出及 API Model ID

作者: APIYI 技术团队
技术交流: 欢迎访问 API易 apiyi.com 首页联系我们，交流多 Agent 架构与多模型接入实践

延伸阅读

• Claude Fable 5.2 有多强？编码、长任务的 4 条边界:用 Anthropic 发布文里的官方成绩和官方限制，讲清 Claude Fable 5.2 强在哪、强到哪里该停，以及何时不该从 Opus 5.5 换过去
• 多智能体落地生产现场：3 层划分管理智能体、专业智能体与人工审核点:以 NVIDIA FOX 的 SMT 产线参考示例为例，分 6 步讲清多智能体落地生产现场时，管理智能体、专业智能体与人工审核点如何划分。
• Claude Fable 5.2 发布，high or max？ 上数据，看看质量和成本:公开评测显示，Claude Fable 5.2 把推理档位从 high 提到 max 可能提高得分，也会抬高每任务成本。档位应按任务的质量门槛和预算一起决定。
• Claude Fable 5.2 对比 Claude Opus 5.5：怎么选:Claude Fable 5.2 对比 Claude Opus 5.5：标准价贵一倍，不是每一项都赢。本文从规格、价格、默认努力档和发布文成绩表四个角度，给出一张按任务选模型的表。