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 从链到图:流程编排进化

Last updated