框架不是 Agent：什么时候需要 LangGraph、CrewAI 或 ADK

参考：来源 F · 第 24 章

学完你能做到

理解框架提供的抽象层而非背产品名
按状态、循环、协作和运维需求选择框架
避免在理解 Agent Loop 前被框架锁定

是搭建 Agent 的脚手架，不是智能本身。它通常帮你管理模型、工具、状态、节点、循环、事件和追踪。换一个框架不会自动修复目标不清、工具设计差或缺少评估的问题。

需求形态	适合的抽象	框架类别示例	先问的问题
固定线性步骤	链/流水线	LangChain 一类	真的需要 Agent 吗？
有循环和显式状态	状态图	LangGraph 一类	状态与停止条件是什么？
角色分工的多 Agent	团队/任务编排	CrewAI、ADK 一类	多角色是否真能降低错误？
以企业连接和权限为中心	平台/托管运行时	云 Agent 平台	数据、权限和审计边界在哪？
以知识检索为中心	索引与检索管线	LlamaIndex、Haystack 一类	核心难点是检索还是自主决策？

可迁移架构把业务契约放中间，框架只是外层适配器。

选框架前先做一个“裸循环”

能解释清这六行，才知道框架替你做了什么

state = initialize(goal, constraints)
while not stop(state):
  context = assemble_context(state)
  decision = model.choose(context, tool_schemas)
  observation = execute_with_policy(decision)
  state = reduce(state, decision, observation)
return verify_and_present(state)

常见误解

使用多 Agent 框架，就自然拥有可靠的多 Agent 系统。

实际上

框架只让消息能传递。角色边界、共享状态、冲突处理、授权和整体评估仍需产品团队设计。

框架选型评审

15 分钟

选择一个你要做的 Agent，画出最小裸循环。
指出框架必须替你解决的两个痛点。
写出一个防锁定方案：更换模型或框架时哪些业务契约保持不变。

案例推演：什么时候一个普通函数比 Agent 框架更好

团队只需“上传文件—抽取字段—校验—入库”，却引入多 Agent 框架、消息总线和图数据库。复杂度上升，但任务路径完全固定。

本节追问：应从需求选择运行时能力，还是从热门框架反推架构？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。

四步案例推演。手机上可左右滑动查看；每个箭头都代表一次需要证据支撑的状态转换。

阶段	本步要做的决定	什么算证据	最常见的失败
列需求	明确状态、分支、并发、暂停恢复与人工确认	每项能力都有真实用例	因为教程使用某框架就照搬
做最小实现	固定路径先用普通代码与队列	基线可测试、可部署、可观察	第一天就设计通用多 Agent 平台
识别拐点	图状态、长任务恢复或动态工具选择出现时升级	升级解决已测量的痛点	用未来可能需要解释当前复杂度
隔离依赖	业务状态与框架对象分开，保留迁移边界	核心数据可导出并重放	全部逻辑绑定框架内部内存

阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。

常见误解

用框架功能清单代替系统需求

实际上

可观察症状：组件都有，但数据契约、完成条件和错误语义仍缺失。

更可靠的修复：先定义任务模型和非功能要求，再比较框架的具体支持与代价。

案例工作坊 · 建议真正动手完成

25 分钟

为文件抽取流程写最小无框架实现。
列出三个出现后才值得引入图运行时的信号。
制作两个框架的需求对照表而非功能大表。

查看参考答案

框架是实现状态、编排、观察和集成的工具，不是 Agent 本身。固定任务应优先简单实现，复杂运行需求出现后再有证据地升级。

迁移检查：换一个场景还会不会

选择 Agent 框架前最先应该得到什么？