PocketFlow 学习笔记：100 行代码的极简 LLM 框架
很多人第一次看到 PocketFlow，注意力都会停在“100 行代码”上。但这个项目真正有价值的地方，不是把框架做小，而是把 LLM 应用里最常见的骨架压得足够薄，薄到你能一眼看清它到底在抽象什么。
我读完 README 和官方文档后更认同一个判断：PocketFlow 不是拿来和 LangChain、AutoGen 拼功能表的，它更像一套最小可解释框架。你用它不是为了少背几个 API，而是为了把工作流、Agent、RAG 这些常见模式重新拆回底层结构。
PocketFlow 官方文档把自己的核心抽象写得很直白：Graph + Shared Store。
这套骨架里有三件事最重要：
Node负责单个任务Flow负责节点之间怎么跳转Shared Store负责节点之间怎么共享数据
这比“它支持多少种 Agent 模式”更关键。因为一旦这三件事是清楚的，很多上层模式都会自然长出来。官方首页把 Workflow、Agent、RAG、Map Reduce、Multi-Agent 都列成 design pattern，本质上也是在说明：这些不是额外魔法，而是同一套图结构的不同展开方式。
PocketFlow 之所以容易学，不是因为它偷工减料，而是它把职责切得很硬。
以 Node 为例，现有文档和示例都围绕 prep -> exec -> post 这条生命周期展开：
prep读取和整理输入exec执行主要计算post写回结果并决定下一步动作
这个切法有两个实际好处。
第一，它逼着你把“算什么”和“数据怎么流”分开。很多 LLM 应用后面会失控，往往不是模型不行，而是提示词、外部 I/O、状态更新和流程判断全揉在一个函数里。PocketFlow 用很小的约束，把这团东西拆开了。
第二，它让 Flow 的控制逻辑更清楚。官方文档里把边的跳转交给 Action，也就是由 post() 的返回值决定下一个节点。这样一来，分支、循环、子流程都不用再额外引入一层很重的 DSL。
如果你只是想理解一个 Agent 工作流到底怎么跑，这种“先把控制流看明白”的收益，比上来就用大框架更高。
PocketFlow 另一个很鲜明的取舍，是它不内建供应商相关的工具层。
官方文档专门列了一组 utility examples，比如 LLM wrapper、web search、embedding、vector database，但它们都不是框架内建能力。原因也写得很明确：供应商 API 变化快、不同团队优化目标不同、很多能力本来就不该被硬编码进一个通用框架。
这个选择带来的好处很直接：
- 不会被某一家模型或向量库绑定
- 你的包装层可以按项目需求定制
- Prompt caching、batching、streaming 这类优化更容易自己掌控
代价也同样直接：PocketFlow 不会替你把“能跑的应用脚手架”一次性搭好。你要自己决定怎么封装模型调用、怎么处理可观测性、怎么接入外部工具。
所以它适合的是“我想掌控骨架”的场景，不适合“我现在就要一整套现成企业能力”的场景。
PocketFlow README 里反复强调一个概念：Agentic Coding。这个词在这里不是营销话术，而是和它的设计方式绑在一起的。
因为框架足够薄，AI 代理更容易读懂它，也更容易在这套结构上继续写代码。人类负责把任务分解、数据流和关键约束想清楚，Agent 再去补节点、补流程、补工具函数，这套协作方式比在一个很厚的框架里到处查抽象层要顺畅。
从仓库里的教程也能看出这个方向。PocketFlow 并不只放一个 hello world，而是把 chat、workflow、RAG、memory、text2sql、agent skills、parallel 等例子都拆成独立 cookbook。它想教你的不是某个 API，而是“同一套图结构怎么反复套用到不同问题上”。
这也是我觉得它最适合作为学习框架的原因：你能顺着示例看到模式，而不是只学到一组调用方式。
如果你在下面几类场景里工作，PocketFlow 很值得认真读一遍：
- 想系统理解 LLM 工作流，而不是只会调用现成框架
- 想自己掌控模型、检索、工具调用这些包装层
- 想让 Agent 更容易参与实现，而不是先被框架复杂度绊住
- 想把一套流程模式讲清楚、教给团队或沉淀成教程
反过来，如果你的诉求是“开箱即用、生态齐全、供应商适配齐全、监控和集成一把梭”，PocketFlow 就不是最省事的选项。它的优势从来不是功能全，而是抽象够干净。
如果让我给它下一个更准确的定位，我会说：PocketFlow 更像 LLM 应用里的“数据结构与算法课”，而不是“全家桶平台”。
它最好的用法通常不是直接替代团队所有框架，而是拿它做三件事：
- 用最小骨架验证一个 Workflow 或 Agent 设计到底成不成立
- 在正式工程化前，把数据流和控制流先走通
- 用它训练团队对 Node、Flow、Shared Store 这些基本概念的直觉
当这三件事做完，你可以继续用 PocketFlow 往前搭，也可以再迁到更重的体系里。关键不在于最终是不是长期使用它，而在于你已经把问题拆清楚了。
PocketFlow 表面上卖的是“100 行代码”，真正交付的是一种很少见的清晰度。
它把 LLM 框架里最值得保留的东西留了下来，把最容易把人带偏的包装层留给你自己决定。对学习者来说，这种克制比功能堆砌更有价值；对已经在做 Agent 系统的人来说，它也提醒了一件很重要的事：不是所有复杂性都值得抽象进框架。