Agent 框架生态：四种协调原语

一句话：LangGraph、CrewAI、AutoGen、AgentScope 的差别不在功能多少，而在“用什么原语协调多个步骤”：状态图、角色流水线、群聊、事件运行时。选型先问“我要确定性还是涌现性、要不要回放和中断”，再问“它支持哪些工具”。

适用：2026 年主流 Agent 框架。各框架版本迭代快，API 以官方文档为准；本文只比较协调模型，不比较具体方法名。

为什么需要

单 Agent 的循环可以用一个 while 写完。一旦出现下面任一需求，循环就不够用了：

• 步骤之间要暂停、审批、恢复，进程重启后还能接着跑；
• 多个角色要按依赖顺序执行，而不是谁抢到谁说话；
• 出问题时要把整条轨迹回放，定位是哪一步的输入错了；
• 同一个流程要跑在 Java 服务里，而不是 Python 脚本里。

这些需求分别指向状态机、流水线、对话协议和事件运行时。框架的价值，是替你把其中一种协调模型和它的持久化、流式、人工介入做出来；代价是你被它的世界观约束。

核心机制

一、四种协调原语

框架	协调原语	执行路径	确定性	最适合
LangGraph	状态图（节点 + 边 + checkpoint）	显式图，可条件分支、可循环	高	长流程、需中断恢复与回放
CrewAI	角色 + 任务流水线	Sequential / Hierarchical	高	职责清晰的线性协作
AutoGen	群聊 + 发言者选择	LLM 动态决定下一个说话者	低	开放探索、对话式协作
AgentScope	消息 + 事件 + Hook 的 Agent 运行时	单 Agent 循环，多 Agent 由消息驱动	中	需要流式事件、拦截器、跨语言运行时

这张表的关键列是确定性。确定性高意味着同样输入大概率走同一条路径，便于测试与审计；确定性低意味着可能产生更好的方案，也可能原地打转，token 方差极大。多数生产事故不是“框架能力不够”，而是选了与任务确定性要求不匹配的原语。

选原语先看任务的下一步能不能在写代码时就定下来，再看中断恢复、分工方式、探索需求、流式与跨语言这几个约束。

选型不是找“最强的框架”，而是找与任务确定性匹配的原语；确定之后，统一轨迹、终止条件与权限仍然要自己做，框架不会自动补齐。

二、LangGraph：把流程画成图

LangGraph 的核心不是“Agent”，而是带 checkpoint 的状态图：节点读写共享状态，边决定下一步，条件边把判断逻辑显式化。因为每一步都落 checkpoint，所以可以中断等人审批、可以从任意节点恢复、可以按 thread_id 回放。

代价是你必须先把流程想清楚。图里出现环，就要自己设终止条件；状态字段一多，节点之间的耦合会迅速上升。它适合“流程相对稳定、但需要可靠执行”的场景，不适合“我也不知道下一步该干什么”的开放任务。

三、CrewAI：角色三元组是结构化 Prompt

CrewAI 用 role / goal / backstory 描述一个 Agent，再把任务按顺序或层级分给它们。它的本质是把“职责边界、成功标准、行为风格”写进 Prompt——这套方法不依赖 CrewAI 也能用。

• Sequential：任务按声明顺序执行，上一个的输出是下一个的输入。可预测、易审计。
• Hierarchical：一个 manager Agent 负责分派与验收，适合任务需要动态拆分的场景，但多了一层模型判断，成本和不确定性都上升。

CrewAI 的边界在于“流程由人预先定义”。如果任务本身需要边做边改目标，流水线会显得僵硬；反过来，如果流程稳定，它比群聊便宜得多，也更容易定位失败步骤。

四、AutoGen：群聊的灵活与代价

AutoGen 把多 Agent 协作建模成一场群聊：消息在 Agent 之间传递，由 GroupChatManager 或类似机制选择下一个发言者。它擅长头脑风暴、互相挑错、方案探索——这些场景里“下一步谁说话”本来就不该由人写死。

代价有三个：终止条件难写（聊到什么时候算完）、token 不可预测（可能三轮结束，也可能三十轮）、责任难归因（最终答案是集体涌现的，出错时不知道是哪一轮带偏的）。生产上必须加最大轮数、预算上限、超时和人工兜底，否则群聊会变成成本黑洞。AutoGen 0.4 之后转向事件驱动的 actor 模型，核心矛盾没变：灵活性与可控性的交换。

五、AgentScope：消息、事件与 Hook

AgentScope 把 Agent 之间的交互收敛为消息，把运行过程暴露为事件。一个 Agent 的一次调用通常经过：前置 Hook → 推理 → 工具执行 → 后置 Hook → 记忆写入 → 事件发布。

这套设计的价值在可观测与可拦截：

• 消息内容块：文本、思考、工具调用、工具结果、图片、文件用统一的块表达，前端按块渲染，不必为每种模态写一套协议。
• Hook：权限校验、敏感词过滤、审计、注入上下文都在 Hook 里做，业务代码不散落。
• 事件：思考开始/结束、工具调用、状态更新、人工介入请求都能流式推给前端；事件也是评测与回放的原始数据。
• 运行时适配：只要能把 Agent 调用编译成图节点，就能挂到 Spring 生态或其它图运行时里；跨语言不是重写 Agent，而是对齐消息与事件契约。

它的代价是抽象层多：消息、事件、Hook、Workspace 各有生命周期，排查问题要能分清是 Hook 改错了、事件丢了，还是模型本身错。

六、Claude Code 给框架设计者的几条经验

Claude Code 不是多 Agent 框架，但它的 Harness 设计暴露了所有 Agent 运行时都会遇到的问题：

• 缓存是上下文设计的一部分：子 Agent 复用父 Agent 的系统提示词可以命中前缀缓存；把动态内容（技能列表、可用 Agent 列表）放进用户消息而不是系统提示词，避免缓存键随用户变化。
• Plan Mode 不改系统提示词：通过前置工具 Hook 拦截写操作，而不是临时换一套 Prompt；这样缓存不失效，行为也可审计。
• 压缩要分层：热数据留上下文，温数据摘要，冷数据落盘；一次性全量摘要既贵又丢细节。
• 验证不是确认：让一个独立 Agent 专门找反例，比让执行者自检更容易发现错误。

这些经验可以直接迁移，但不要照抄具体参数——缓存 TTL、压缩阈值取决于你的模型与流量。

统一轨迹：跨框架比较的前提设施

统一轨迹的设施只有两段：把各框架的原始事件翻译成同一种记录，再在这份记录上做评测、排障和迁移比较。

适配层是唯一要维护的胶水；轨迹 schema 一旦定型，换框架只是换 translator——这就是"先定轨迹格式，再选框架"的设施形态。

实战场景

场景：同题实测"调研三个竞品并出选型建议"（选型靠数据不靠 README）

痛点：选型会的常态是拿功能清单和博客印象投票，上线后才发现选的框架与任务的确定性要求不匹配——返工成本远高于一次实测。四框架各写一版（LangGraph 图：research→compare→review；CrewAI：researcher→analyst→writer 顺序流水线；AutoGen：PM + 3 专家群聊；AgentScope：单 Agent + 工具），固定输入跑 20 次，只记四个数：

指标	为什么记它	决策含义
token P50 / P95	成本方差	AutoGen 型群聊的 P95/P50 常到 5–10 倍，报价按 P95
轮数分布	终止可控性	需要人工写死几道闸门才能收敛，说明原语与任务不匹配
失败归因耗时	运维成本	给一次注入错误，量"从发现到定位到第几步"的分钟数——群聊型显著最长
产出质量（评审 rubric）	收益上限	探索型任务里低确定性框架确实可能更优，这是唯一支持它的证据

实战结论的常见形态：线性分工任务 CrewAI/LangGraph 质量不差且成本约为群聊的 1/3——多数团队测完发现不需要涌现性；真有互相挑错价值的场景（方案对抗、红队），才为 AutoGen 的方差付费，并且配最大轮数 + 预算上限 + 人工兜底三件套。

场景：把"多 Agent"拆回单 Agent 的两次手术

• 手术一（CrewAI 型）：writer 经常收到 researcher 的超长中间结论跑偏 → 把"提炼要点"从角色降级为确定性节点（结构化输出 + schema 校验），三 Agent 变一 Agent + 两步预处理——效果持平，token 降四成；
• 手术二（AutoGen 型）：群聊里"critic"从未真正否决过任何方案（LLM 倾向于附和）→ 改成执行后由独立评审 Agent 找反例（验证与执行分离，见 09 第六节 Claude Code 经验），发言轮数砍半，错误捕获率反而上升。

两例的共同原理：先问这个角色是否在改变信息流，还是在改变 token 账单。没有改变信息流的角色（永远附和、永远照单全收的传递者）删掉不损失能力。

最小上手

先用同一件事（“调研三个方案并给出选型建议”）各写一版，比较轨迹而不是比较 API：

# LangGraph：流程显式，便于中断与回放
graph.add_node("research", research)
graph.add_node("compare", compare)
graph.add_node("review", human_review)
graph.add_edge("research", "compare")
graph.add_conditional_edges("compare", needs_review, {"yes": "review", "no": END})

# CrewAI：职责显式，适合顺序流水线
crew = Crew(
    agents=[researcher, analyst, writer],
    tasks=[research_task, analysis_task, writing_task],
    process=Process.sequential,
)

跑完记录三件事：总 token、总轮数、失败时能否指出是哪一步。这三项比“哪个框架功能多”更能决定生产可用性。

生产动作

• 先定轨迹格式，再选框架：至少记录 step / actor / input / tool / output / tokens / latency；没有统一轨迹，换框架等于从零开始排查。
• 终止条件写成代码，不要只写进 Prompt：最大轮数、最大 token、最大时长、连续无进展检测，四道闸门缺一不可。
• 人工介入点显式化：哪些工具调用必须审批、审批超时怎么办、恢复后从哪一步继续；这些要在图或状态机里，而不是靠模型自觉。
• 工具权限按 Agent 收窄：写手不给数据库写权限，研究 Agent 不给生产发布权限；权限在 Hook 或网关层校验，不能只靠 Prompt。
• 评测按轨迹评，不只看最终答案：同一答案可能来自正确路径，也可能来自碰巧；轨迹评估能区分“学会了”和“蒙对了”。
• 锁定版本并留迁移层：框架 API 变化快，把模型调用、消息、工具 schema 包一层自己的接口，换框架时只改适配层。

边界

• 多 Agent 不是默认答案：多数任务用单 Agent + 工具 + 好的上下文就能解决；多 Agent 增加的是状态一致性、调试成本和 token 开销，不是“智能”。
• 群聊不适合强流程：有明确步骤、强审计要求的任务，用图或流水线；让模型决定下一步，等于把确定性交给概率。
• 框架不替代 Harness：工具调度、权限、沙箱、上下文治理是运行时职责，换框架不会自动获得；参考 Harness 与参考架构。
• 不要照抄大厂内部实现：公开资料里的缓存比例、压缩阈值都绑定特定流量与模型；抄参数不如抄问题意识。
• 跨语言先对齐契约：消息结构、事件类型、错误码不一致，适配器只会把问题推迟到联调；先定契约再选运行时。

讲清楚

四个框架代表四种协调原语：LangGraph 是带 checkpoint 的状态图，强在确定性、中断恢复与回放；CrewAI 是角色加任务流水线，本质是结构化 Prompt，强在职责清晰、成本可预测；AutoGen 是群聊加发言者选择，强在开放探索，代价是终止难、token 方差大、责任难归因；AgentScope 是消息加事件加 Hook 的运行时，强在流式可观测、可拦截、可跨语言适配。

选型先看任务要确定性还是涌现性，再看是否需要暂停恢复、轨迹回放、跨语言部署；功能清单放在最后。生产上统一轨迹格式、把终止条件写成代码、显式人工介入点、按 Agent 收窄工具权限，这四件事比换框架更能提升可靠性。

框架只提供协调模型，不提供 Harness。工具调度、权限、沙箱、上下文治理仍要自己补；多 Agent 也不是默认答案，单 Agent 能解决时，多一层协作只会多一层故障面。

适用：LangGraph / CrewAI / AutoGen / AgentScope 2026 年版本 | 初稿 2026-10