23-框架选型与自建Agent框架

23 · 框架选型与自建 Agent 框架：LangGraph、AutoGen、CAMEL、AgentScope

「AI-Agent 面试深度指南」· 模块六 · 范式、框架与多智能体 · 第 23 篇 / 共 32 篇

引言

"你们用什么框架？"这道题的满分答案不是报一个名字，而是说清你为什么选它、以及它帮你解决了什么、又带来了什么约束。

框架的本质是一组设计取舍的固化：LangGraph 选择了可控，AutoGen 选择了涌现，AgentScope 选择了工程化。理解这些取舍，比记住 API 重要得多。本文对比四类主流框架的设计哲学，给出选型维度，并讲清自建框架时的分层结构与最容易踩的坑。

一、四个框架的设计哲学

1.1 AutoGen：以对话驱动协作

把多 Agent 抽象成一场"群聊"——定义若干带角色的 Agent，让它们在共享会话里轮流发言，协作从对话中自然涌现。

优势：上手极快，适合探索性任务与研究原型；角色设定直观。

风险：行为不可预测，容易跑偏（工程师 Agent 开始做产品决策）、陷入互相客套、或无人终止。终止条件与发言顺序必须精心设计。

1.2 CAMEL：角色扮演 + 引导性提示

用两个 Agent（用户 Agent + 助手 Agent）通过结构化提示自动推进对话，几乎无需人工干预即可完成协作。

优势：轻量、优雅，是研究双 Agent 协作与合成数据的好工具。

局限：工程能力与容错较弱，不适合生产环境。

1.3 AgentScope：面向工业级健壮性

关注多 Agent 系统在真实场景中的工程问题：高并发、分布式部署、容错（单个 Agent 崩溃不影响全局）、消息与服务解耦、可观测性与可视化。

价值：它代表了"从能运行到能稳定服务"的跨越。当你的系统要从 demo 走向生产，会遇到的问题它都提前处理了。

1.4 LangGraph：用状态机驯服不确定性

把 Agent 建模成有状态的图：State（共享数据结构）+ Node（纯函数）+ Edge（含条件分支）。

三个核心收益：

1. 可预测性：路径是定义好的；
2. 可观测性：能追踪到具体节点与状态快照；
3. 可控性：循环、回退、人工审核节点都可显式表达。

关键能力：checkpoint 持久化（支持长任务与断点续跑）、Human-in-the-loop 节点（天然支持审批流）、子图复用。

代价：样板代码多（先定义 state / node / edge），简单任务显得繁琐；调试需要理解整张图（节点内部错误、状态在传递中被污染、条件边判断写错是三类常见 bug）。

二、两条隐藏的评价维度

2.1 涌现式协作 vs 显式控制

AutoGen / CAMEL 靠定义"角色与目标"，让复杂行为从简单规则中涌现——贴近人类协作，但难预测、难调试。

LangGraph 要求显式定义每一步与跳转条件——牺牲了涌现的惊喜，换来可靠性、可控性与可观测性。

生产环境通常更偏后者，因为"可回放、可审批、可断点续跑"往往比"聪明"更重要。

2.2 工程化维度

无论选哪种协作范式，从原型走向生产都要面对：并发、容错、分布式部署、成本控制、可观测性。这一维度常被忽视，但它决定了系统能不能真的上线。

2.3 一个判断原则

出问题的时候，你能不能自己改？ 通用框架为了通用性会牺牲针对性，且排查时是黑盒。如果这个问题对你的业务很关键（比如需要精细控制上下文以省成本），自研可能更划算。

三、选型维度清单

按重要性排序：

1. 可控性要求：需要可预测/可审批 → 图模型（LangGraph）或自建；
2. 并发与规模：高并发、分布式 → AgentScope 或自建；
3. 团队能力：团队工程能力弱、要快速出成果 → 平台（Dify）或 AutoGen；
4. 生态与维护：框架是否活跃、文档是否完善、社区能否答疑；
5. 可替换成本：业务逻辑与框架的耦合有多深。

四、自建框架：分层结构与原则

4.1 六层结构

1. LLM 接入层（最该先做好的一层）
统一多厂商接口（OpenAI / 本地模型 / 私有云），统一消息格式与错误语义，内置重试、超时与自动 provider 检测。

价值：换模型不改业务代码；主模型超时可切备用模型；成本与 token 统计有统一入口。

2. 配置层：模型、温度、预算、工具白名单集中管理，支持环境隔离。

3. Agent 抽象层：基类定义 run() / step() / reset()；范式（Simple / ReAct / Reflection / PlanAndSolve / FunctionCall）作为不同实现。

4. 消息层：统一的 Message 结构（role / content / tool_calls / metadata），是所有组件间的通用语。

5. 工具层：基类 + 注册机制 + Schema 自动生成 + 执行前校验 + 异步并行执行 + 权限标签。

6. 可观测层：轨迹落盘、指标上报、成本统计。

原则：分层解耦、职责单一、接口统一。工具系统与模型接口要预留扩展点。

4.2 三个最容易踩的坑

坑一：跳过接入层直接调 SDK。 结果换模型要改所有业务代码，也无法做统一兜底与成本统计。

坑二：状态靠解析文本。 把"任务进度"藏在对话历史里，用正则去捞——这会在格式稍有变化时全线崩溃。状态必须是结构化对象，数据库存状态，上下文只是它的投影。

坑三：没有可观测性。 上线后无法回答"为什么这么贵"“这一步为什么失败”。轨迹落盘与指标采集应从第一天就做，而不是等出事再补。

4.3 自建的合理边界

自建的是主循环与治理能力（上下文组装、工具治理、验证、观测、评测），而不是所有东西。向量库、模型服务、消息队列等基础设施应该用成熟方案。

五、面试考点与答题框架

5.1 高频真题

Q1：LangGraph 和 ReAct 是什么关系？
答：ReAct 可以表示为两个节点（模型节点、工具节点）+ 一条条件边（是否还有工具调用）。图模型是更一般的抽象，ReAct 是它的一个特例。这也说明：图模型不会限制你实现经典范式，只是把控制流显式化了。

Q2：为什么很多公司最终选择自建框架？
答：三个原因——通用框架为通用性牺牲针对性（如无法精细控制上下文布局做缓存优化）；排障时是黑盒；以及核心业务往往只需要几百行主循环 + 自有基础设施，没必要背整个框架的依赖与复杂度。

Q3：多 Agent 群聊最常见的失败模式与对策？
答：无限客套、角色漂移、无人终止、上下文爆炸。对策：设置发言顺序与最大轮数、引入主持人 Agent 收敛、用结构化输出约束、设置明确的终止条件。

5.2 加分点

• 能用"涌现 vs 控制""原型 vs 生产"两个维度评价框架，而不是罗列特性；
• 能画出自建框架的六层结构并指出最易遗漏的接入层与可观测层；
• 能说出"数据库存状态、上下文只是投影"这一设计原则。

小结

框架之争的本质是两组取舍：涌现式协作 vs 显式控制，原型效率 vs 生产可靠性。选型时先亮出维度再给结论；自建时记住六层结构（接入、配置、Agent 抽象、消息、工具、可观测），其中接入层与可观测层最容易被忽略，却最救命。