多智能体框架五花八门，但底层的协作结构其实只有几种。这篇用同一任务在两个框架各实现一遍的方式，把选型依据落到成本结构上，而不是功能清单上。
四个框架的底色
CrewAI 走声明式角色分工，上手最快，适合原型和非工程师协作；AutoGen/AG2 是双层设计，core 层给研究型系统最大自由度，事件驱动集成是强项；MetaGPT 把软件公司的 SOP 固化成流水线，"一行需求出交付物"在软件开发域无可替代；OpenAI Agents SDK 反着来——框架够薄，handoffs（移交控制权）和 agents-as-tools（子 Agent 包成工具、独立上下文干活）两条路都给你，加 guardrails 和 tracing 内建，模式自选。
成本账：框架不改变物理，但改变结构
多 Agent 系统的 token 开销仍是单 Agent 的十几倍量级，框架改不了这个物理事实，但影响成本结构。三个观察：
共享上下文 vs 独立上下文。 AutoGen 的 GroupChat 让成员共享一条消息流，每个成员每轮重读全部历史，token 按 O(n²) 涨；agents-as-tools 是独立窗口加压缩回传，O(n) 但损失共享视野。成员多、任务长，优先独立窗口。
协调开销是隐性 token。 Selector/manager 每轮决定"谁来干"都要烧推理；CrewAI 的 sequential 模式没有调度决策，协调成本最低，hierarchical 每一步都在付调度税。
默认值缺上限。 多数框架默认不限制迭代：LangGraph 要设 RecursionLimit，AutoGen 要设 max_turns，Agents SDK 得自己包循环。没有预算守卫的多 Agent 系统，等于一个会自己烧钱的循环。
同一任务，两种形态
CrewAI 版本（Supervisor 形态）：
from crewai import Agent, Task, Crew, Process, LLM
llm = LLM(model="deepseek/deepseek-chat",
api_key=os.environ["DEEPSEEK_API_KEY"])
researcher = Agent(role="研究员", goal="收集关键事实与来源",
backstory="只回传带来源的压缩发现",
llm=llm, allow_delegation=False, max_iter=10)
writer = Agent(role="撰稿人", goal="写成结构化摘要",
backstory="拒绝无来源论断", llm=llm,
allow_delegation=False, max_iter=10)
crew = Crew(agents=[researcher, writer],
tasks=[Task(description="调研: {topic}", agent=researcher),
Task(description="写300字摘要", agent=writer)],
process=Process.hierarchical, manager_llm=llm)
print(crew.kickoff(inputs={"topic": "token成本结构"}).raw)
Agents SDK 版本把子 Agent 包成工具，主 Agent 拿到的是"调研工具"和"写作工具"，子任务各自带独立上下文。
增量提醒（原文未提的验收法）：对比两版实现时别只看最终产出，记录三个数——总 token 消耗、端到端耗时、失败重试次数。判定基准：Supervisor 形态因共享上下文 token 普遍更高，若 agents-as-tools 版本 token 反而更多，通常是子 Agent 结果回传没有压缩，先修回传再下结论。
选型口径
按场景倒推：快速原型选 CrewAI；要完全自控协作结构选 Agents SDK 或裸写；复杂图状流程选 AutoGen core；需求直出软件交付物选 MetaGPT。拿不准要不要多 Agent？先单 Agent 加技能清单跑通——框架不会帮你省 token，只会改变 token 花在哪。
评论0