先说结论：选框架前先选“模式”
如果你还没确定需要 Router/Graph/Planner-Executor 等模式，先别急着选框架。框架只是把模式工程化的实现。
你应该用哪些维度做选型
建议用下面四个维度（偏生产环境）：
- 可控：是否容易做预算、停止条件、人类确认点
- 可测：是否容易做回归评测、节点级对比、可重放
- 可观测：是否容易集成 tracing、可视化执行路径
- 可维护：节点契约是否清晰、图/流程是否可版本化
额外两个维度（现实约束）：
- 生态：工具/连接器多不多，社区活跃度
- 迁移成本：你未来换模型/换编排方式会不会很痛
LangGraph（Graph-first）的典型优势与风险
适合：
- 复杂分支、多回路、需要状态显式的工作流
- 需要“节点契约”与可视化路径的团队
优势：
- 图结构天然可版本化、可审计
- 节点化后易做局部回归（改一个节点不影响全局）
风险：
- 过早图化会增加设计成本（小任务用不上）
- 节点边界不清会把复杂度转移到 state 里
AutoGen（Multi-agent/Conversation-first）的典型优势与风险
适合：
- 多角色协作（planner/critic/executor）
- 需要快速验证“多智能体分工”想法的团队
优势：
- 角色拆分直观，上手快
- 适合探索型任务（research/triage）
风险：
- 若缺少硬约束（预算、停止条件），更容易发散
- 需要额外工程投入去做可观测与回归
CrewAI（Role/Task-first）的典型优势与风险
适合：
- 以任务编排为中心、希望快速搭建“数字员工流水线”
- 任务分工相对清晰的场景
优势：
- 任务/角色模型贴近业务表达
- 有利于把“工作流程”产品化
风险：
- 复杂分支与回路的表达能力需要验证
- 生产化同样依赖你自己的工具层与护栏
动手做：用一个“评测驱动”的 POC 来选框架
不要只写 demo。建议你用同一套 golden set 做对比：
- 同样的输入输出契约
- 同样的工具层（尽量共用）
- 同样的回归样本与 rubric
对比输出：
- 成功率
- 平均步数/调用次数
- 平均延迟/成本
- 可解释性（失败能否快速定位）
工程化清单（框架无关）
- 节点/步骤要有契约（input/output/failure）
- 有预算与停止条件（步数、成本、时间）
- 有人类确认点（写操作/低置信度/超预算）
- 工具层强校验与审计
常见坑
- 用“跑通一个 demo”当选型依据：生产事故会补齐所有缺失
- 只看框架能力不看工具层：工具层才是稳定性的底座
- 不做迁移预案：未来换框架会陷入重写