8.1 框架生态概览与选型指南

随着智能体工程化需求增加，各类开发框架快速涌现：它们把“提示词 + 工具 + 状态 + 评估”封装成更可维护的系统结构。

为什么需要框架？因为手写 Prompt 和 API 调用虽然灵活，但在处理 多智能体通信、状态管理、错误重试、上下文窗口优化以及流式输出 时，原生代码会迅速变成难以维护的"意大利面条"。

目前市场上已经形成了一个丰富但略显拥挤的生态。如何根据业务需求选择合适的工具，是每个开发者面临的第一个挑战。

8.1.1 核心框架图谱

与其记住每个框架的名字，更重要的是理解它们在工程抽象上的差异。常见的框架形态可以按“主矛盾”划分：

形态 A：链式编排

• 适合把多个模型调用与工具调用按固定顺序串起来。

• 优点：上手快、心智负担小。

• 局限：难以表达复杂控制流（分支/循环/回退）。

形态 B：图编排与类型安全

• 把工作流建模为状态机/有向图，强调可控性与可回放。

• 常见能力：条件路由、循环、检查点（checkpoint）、中断/恢复、人机协作节点。

形态 C：多智能体协作

• 目标是让多个角色分工协作：研究、写作、执行、审阅、裁判等。

• 典型模式：对话编排（群聊/轮次控制）与角色任务编排（SOP/流水线/层级）。

形态 D：数据/RAG 驱动

• 把“索引/检索/后处理/权限隔离”作为第一等公民。

• 适合知识密集型智能体：文档问答、对比分析、跨数据源查询。

形态 E：企业级 SDK/连接器

• 把身份、权限、审计、连接器与治理作为核心能力。

• 适合在既有系统中落地，而不是从零搭建智能体平台。

8.1.2 选型决策矩阵

维度	链式编排	图编排/状态机	多智能体协作	数据/RAG 驱动	企业级 SDK
可控性	中	高	中到高	中	高
易用性	高	中	中	中	中
代码执行闭环	依赖外部	可集成	常见强项	依赖外部	可集成
知识/检索能力	依赖外部	依赖外部	依赖外部	强	依赖外部
治理与审计	依赖外部	可增强	需要额外设计	需要额外设计	强

8.1.3 选型建议

1. 企业级业务流（审批、客服）：优先图编排/状态机形态，确保可控、可追踪、可回放。

2. 知识密集型任务（法律/政策/内部知识库）：优先数据/RAG 驱动形态，投入索引、权限与后处理。

3. 创意与自动化任务（内容生成、运营流程）：优先角色任务编排形态，强调 SOP 与交付模板。

4. 代码生成与执行闭环：优先具备沙箱执行、错误回传、评审回路的组合方案。

5. 传统企业系统集成：优先企业级 SDK/连接器形态，把权限、审计与连接器放在第一位。

8.1.4 小结

框架没有绝对的优劣，只有"适合"与"不适合"。

• 智能体本质是 While 循环，框架只是封装了这个循环里的脏活累活。

• 不要被框架绑定。理解底层的 Prompt 设计、工具调用和记忆管理才是核心。

• 很多时候，混合使用 也是一种策略（例如把数据/RAG 能力封装成工具，再挂载到多智能体编排系统中）。

下一节将通过一个“从链到图”的例子解释流程编排的演进。

---

下一节: 8.2 从链到图：流程编排进化