全书目录

第九编 框架层

第 41 章 为什么框架层值得被单独拆开

6 分钟 2,684 字 第 42 / 161 个阅读单元

前八编已经回答了一个更基础的问题：Agent 到底应该被理解成什么。

它不是一个 prompt，不是一段对话，也不是“会调工具”的聊天壳。 它更像一个由目标、状态、动作、控制流、外部系统、治理与评测共同组成的执行系统。

但只理解到这里还不够。

因为一旦真正落地，你迟早会遇到另一个问题：

text
同样都在做 Agent，为什么不同框架写出来的系统，
看起来像在解决完全不同的问题？

有的框架把图、状态和检查点当主语； 有的框架把 Agent 对象、工具、handoff 和 session 当主语； 有的框架把 plugin、kernel、process 当主语； 有的框架把多 Agent 消息传递和 runtime 当主语； 有的框架把 crew、task、flow 当主语； 还有的框架，其真正主语根本不是控制流，而是数据、索引、检索和 query engine。

因此，第九编第一条结论应该是：

text
所谓 Agent 框架，并不是中性的“封装层”，
而是在替你预设：系统的主对象是什么，状态放在哪里，控制权交给谁。

这件事很关键。

因为框架从来不只是“帮你少写代码”。 框架真正做的，是替你把某种系统观固化成默认路径。

如果你选的是图运行时框架，你会自然把问题拆成节点、边、状态、检查点和中断； 如果你选的是高层 agent SDK，你会自然把问题拆成 agent、tool、session、guardrail、runner； 如果你选的是角色化多 Agent 框架，你会自然把问题拆成角色、任务、交接、团队流程； 如果你选的是数据框架，你会自然先去想 reader、document、index、retriever 和 query engine。

这意味着：

text
框架不是“最后再选的实现细节”，
框架常常会反过来塑造团队如何理解 Agent。

所以，框架层不能用“功能表”去理解。 最差的写法，就是把每个框架都列成：

  • 支持工具
  • 支持 memory
  • 支持多 Agent
  • 支持 streaming
  • 支持 observability

这种比较几乎没有解释力。

因为今天主流框架到了一定成熟度，很多关键词都会出现。 真正有解释力的问题不是“支不支持”，而是：

  1. 它把什么对象显式化了？
  2. 它把状态压在什么地方？
  3. 它把控制权主要交给代码、模型、图、runtime，还是角色系统？
  4. 它最擅长处理哪一类不确定性？
  5. 它最容易让人误把什么当成 Agent？

因此，本编会严格用整本书前面建立的统一模板来拆框架。

具体来说，我们会对每个框架都追问九件事：

  1. 入口和生命周期
  2. 输入契约
  3. 状态模型
  4. 工作流编排
  5. 子 Agent 或节点职责
  6. LLM 基础设施
  7. 工程取舍
  8. 业务适配
  9. 治理与评测

如果把这九个问题再压缩成一套真正可执行的“框架阅读法”，可以进一步变成下面七步：

第一步，先找框架 README 或 overview 页面里的官方自我定位。 注意不是看别人怎么总结它，而是看它自己首先强调什么。 如果第一页强调的是 runtime、state、durable execution，那它大概率是运行时中心； 如果第一页强调的是 create_agent、middleware、structured output，那它大概率是高层接口中心； 如果第一页强调的是 reader、index、retriever，那它大概率是数据中心。

第二步，找最核心的入口对象。 问自己：用户第一次真正构造的对象是什么？

  • 是图？
  • 是 agent？
  • 是 kernel？
  • 是 crew？
  • 是 workflow？
  • 是 index？

这个问题通常比“它支持什么”更能暴露本质。

第三步，找生命周期驱动者。 问自己：到底是谁在推进系统前进？

  • 图运行时
  • agent runner
  • process engine
  • message runtime
  • flow state machine
  • query / retrieval chain

谁在推进系统，谁通常就掌握了真正的控制权。

第四步，找状态承载体。 问自己：状态到底住在哪里？

  • graph state
  • run state
  • session
  • thread
  • process state
  • flow state
  • ctx.store
  • memory / store

如果这个问题答不清，说明你其实还没有真正理解该框架。

第五步，找业务接缝。 问自己：业务对象、业务规则、业务流程，是通过什么方式进入框架的？

  • 靠 state schema
  • 靠 plugin / function
  • 靠 tool schema
  • 靠 tasks / crews
  • 靠 retriever / query engine

这一层决定了框架是否真的能落到业务，而不只是停在 demo。

第六步，找治理接缝。 问自己：HITL、guardrail、权限、审计、trace、eval 在哪里落地？

如果一个框架这层完全没有对象位置，通常就意味着它更偏原型，不够偏生产。

第七步，找最容易被误用成什么。 这一步非常关键。 因为真正理解一个框架，往往不是理解它“最擅长什么”，而是理解它“最容易把人带歪到哪里”。

一旦掌握这七步，你会发现后面七章其实不是七篇产品介绍，而是七次对不同系统中心的拆解实验。

一旦这样看，很多看似混乱的争论都会瞬间清楚。

比如：

  • LangGraph 的核心不是“又一个 agent 包”，而是状态图、检查点和中断系统；
  • LangChain 的核心不是运行时内核，而是高层入口、中间件与应用层 agent 接口；
  • OpenAI Agents SDK 的核心不是图，而是把 agent runtime 的稳定对象产品化；
  • Semantic Kernel 的核心不是“多 Agent 聊天”，而是 kernel、plugin、process 与企业系统连接；
  • AutoGen 的核心不是“让几个 prompt 对话”，而是消息传递、多 Agent runtime 与分层 API；
  • CrewAI 的核心不是某个单独 agent loop，而是角色、任务、crew、flow 与产品化运维；
  • LlamaIndex 的核心起点不是控制流，而是数据接入、索引、检索与 agentic RAG。

因此，本章第二条结论应该是：

text
理解框架最有效的方式，不是背 API，
而是先找出它真正把哪一种系统对象放到了中心。

本编选择七个最有代表性的框架，不是因为它们穷尽了一切，而是因为它们恰好代表了七种不同的“Agent 系统中心”：

  • 图与运行时中心
  • 高层 agent 接口中心
  • runtime 对象中心
  • kernel / plugin / process 中心
  • 多 Agent 消息运行时中心
  • 角色协作与流程中心
  • 数据与检索中心

一旦把这些中心看清楚，你再去看任何新框架，都会容易很多。

所以，本章最后要留下的判断是：

text
框架层真正值得研究，不是因为框架很多，
而是因为每个成熟框架都在替你回答：
Agent 系统到底应该先从什么对象开始组织。