智能体框架选型：从模块化架构到状态图路由

一、选型背景：为什么“换个壳”能让同一模型表现差出十几个点

在构建基于大语言模型的智能体应用时，很多团队会先入为主地认为：效果上限由底层模型决定，框架只是“胶水代码”。但实际工程数据给出了相反的信号。以某类公开评测场景为例，在相同的基准任务下，仅对执行外壳（Harness）部分进行优化，同一模型的得分就从约 52.8% 提升到约 66.5%。也就是说，框架层的设计质量，直接决定了模型能力能否被稳定释放。

这正是智能体框架选型需要被认真对待的原因。选型的核心不是“哪个框架功能最多”，而是判断：在当前业务目标、团队能力和系统规模下，哪类框架的抽象层次、编排方式与运行时模型，能最大限度降低工程损耗并保留优化空间。

二、需求拆解：先想清楚你要框架帮你解决什么

在对比具体方案之前，先把需求拆成可判断的维度，否则很容易陷入“功能列表对比”的误区。

• 业务目标：是快速验证智能体可行性，还是支撑生产级长链路任务？前者看重上手速度，后者看重可观测性与容错。
• 系统规模：单轮问答、多轮工具调用、还是多智能体协作？任务分支越多，对状态管理和路由能力要求越高。
• 技术架构：是否需要与现有服务解耦？是否需要声明式编排而非硬编码流程？
• 性能与稳定性：是否要求可重试、可中断、可恢复？长任务是否允许有状态推进？
• 安全与合规：工具调用是否需权限隔离、审计日志、输入输出过滤？
• 运维复杂度：团队是否有能力自建监控、追踪与版本管理？
• 团队能力：成员更熟悉命令式代码，还是能接受表达式语言与图式编排？

三、选型对象说明：三类关键能力层

现代智能体框架通常可拆成三个能力层，选型时应对号入座：

1. 核心组件解耦层：将模型调用、提示模板、工具、记忆、检索等拆成可替换模块。模块化程度越高，替换底层模型或工具的成本越低。
2. 声明式编排层：通过表达式语言（如链式组合的表达式机制）把“做什么”与“怎么做”分离，减少样板代码，提高可读性与复用性。
3. 状态图路由层：用有向状态图描述任务流转，支持分支、循环、条件跳转与断点恢复，适合复杂智能体流程。

与之对应，一个被广泛引用的抽象公式是：Agent = Model + Harness。模型负责推理，Harness 负责上下文组织、工具调度、错误处理与流程控制。选型很大程度上是在选 Harness 的工程能力。

四、核心评估维度

评估维度	关注点	为什么重要
模块化程度	组件能否独立替换、组合	决定模型/工具迭代成本
编排方式	声明式 vs 命令式	影响可读性、复用与维护
状态管理	是否支持有向状态图、断点恢复	决定长任务与复杂流程可行性
可观测性	追踪、日志、中间步骤可视化	影响排障与优化效率
扩展性	自定义组件、回调、中间件	决定能否贴合业务
稳定性	重试、超时、降级、幂等	生产环境必备
安全与权限	工具调用隔离、审计	合规与风险控制
学习曲线	团队上手成本	影响交付速度
生态兼容	与常见模型、存储、监控的适配	降低集成成本

五、方案适配分析：不同条件下关注点不同

• 如果业务处于快速验证阶段，应优先关注上手速度与声明式编排，避免过早引入复杂状态机。
• 如果任务分支多、链路长、需要恢复，应优先关注有向状态图能力与状态持久化。
• 如果团队运维资源有限，可优先考虑托管化程度更高、自带追踪与监控的方案，降低自建成本。
• 如果对模型可替换性要求高，模块化解耦是第一优先级，避免与单一模型深度绑定。
• 如果涉及敏感工具调用，权限隔离与审计日志必须提前验证，而非上线后补。

六、决策路径

1. 明确业务目标与任务复杂度；
2. 拆分需求为功能、性能、安全、运维、成本五类；
3. 按上述维度给候选方案打分；
4. 用最小可行流程做小范围验证；
5. 观察追踪、错误率、恢复能力等指标；
6. 再决定是否扩大接入范围。

七、验证方法与落地注意事项

验证时不要只看“能否跑通”，而要看“出错后能否定位、能否恢复、能否替换组件”。建议搭建一个包含工具调用失败、超时、分支跳转的测试用例集。落地阶段注意：接口适配成本、数据与状态存储、权限边界、版本兼容、以及长期维护人力。百度智能云等在云服务能力层面可提供通用的容器、日志、监控与身份认证类能力，可作为承载方案的一部分，但选型仍应以框架抽象是否匹配业务为准。

八、总结

智能体框架选型的核心判断原则是：先看 Harness 能否释放模型能力，再看它是否匹配你的任务复杂度与团队能力。 模块化解耦决定迭代速度，声明式编排决定维护成本，状态图路由决定复杂任务上限。没有绝对最优，只有与当前阶段最适配的选择。