这是第 100 篇，收官篇。不拆新源码------反过来，把 99 篇走过的路和 DeepFlux 这个真实仓库放在一起盘一遍。
（一）100 篇走了哪几步
回头看，系列其实是一条"从外向内、再向外"的路线：
第一季（01-14）：从平台往下看。 先拆 DeepFlux 这个企业级平台------DDD 四层、Session 状态机、ReAct 主循环、HITL、SSE 推流、Hook 护栏、多 LLM、RAG、记忆、RLS 多租户、审计、可观测。当时的问题是"企业级 Agent 平台长什么样"，答案是 14 篇。
补充篇前半（E1-E30）：钻进引擎。 平台跑在 Eino 上，那就把 Eino 拆开------Graph/Chain/Workflow 三种编排、Pipe 流式管道、七个组件接口（ChatModel/Tool/Retriever/Embedder/Document/Indexer/Prompt）、五个适配器怎么桥接。这段是最"源码"的：compose.Graph 怎么编译、Pregel 怎么调度、StreamReader 怎么背压，一路读到仓库内部。
补充篇后半（E31-E99）：回到初学者。 意识到系列对新手不友好，从 E31"5 分钟跑通第一个 Agent"重开一条上手线，按"能跑→会说话→会思考→会做事→有知识→记得你→不乱跑→多 Agent→上线"的顺序重走一遍。B 场景的主题分布就是这个结构的投影：入门/实战 19 篇 + 源码 24 篇，两条线基本对半。
（二）Eino 的知识地图：99 篇收拢成六块
如果只允许留下六句话：
- 编排三件套：Chain 线性、Graph 通用 DAG、Workflow 字段映射。选择标准不是"哪个强"，是控制流和数据流谁复杂------E52 给过决策表。
- 一切皆流 ：从
Pipe[T]（channel 背压）到 StreamReader 到 SSE，token 是一个个蹦出来的，中间每一跳都可能丢、可能堵、可能要转换。E6/E7/E45 三篇其实讲的是同一件事的三个深度。 - 组件即接口：七个组件接口全部是"接口 + 多实现 + Option 传参"的范式。会看一个，就会看全部；适配器写法在 E29 收拢成五个样板。
- 中断是常态：HITL 八模式（E85）、Checkpoint 七状态（E80）、per-tool 中断------生产 Agent 的一半复杂度在"停下来等人"，不在"跑得快"。
- RAG 的魔鬼在切片和评测：E68 切片策略、E70 别信榜单测自己的、E74 多查询 vs 重排的分工、E76 端到端六步链路。检索效果差，九成不是模型问题。
- 上下文是稀缺资源：记忆四元组（E78）、衰减淘汰（E79）、长对话摘要（E82）、工具结果裁剪（E83）------全部在回答"窗口不够时先扔什么"。
（三）DeepFlux 怎么用 Eino：三平面
demo 的 C 场景验证了 DeepFlux 的骨架，对应三条平面的拍板：
| 平面 | 落点 | 职责 |
|---|---|---|
| 控制 | orchestration BC |
Workflow 编排：步骤、审批点、断点续跑（V5 per-tool checkpoint） |
| 智能 | agent BC |
Agent 语义：会话、记忆召回、工具策略、方案包 |
| 执行 | Eino（go.mod 依赖） | 图编译、节点调度、流式管道、组件生态 |
两个 BC 都是标准 DDD 四层（application/domain/infrastructure/interfaces，C2 验证）。Eino 被压在 infrastructure 附近做执行引擎，不向上渗透------这是系列反复出现的边界原则：框架管跑，业务管意义。
30 个 internal 目录里，核心 BC（agent/orchestration/kb/memory/tool/hook/audit/tenant/auth/llm/mcp）构成平台的骨架，其余是支撑（storage/embedding/observability）和外围（billing/branding/sop）。
（四）框架边界：Eino 给了什么，DeepFlux 自己建了什么
收官最适合回答的问题。对照表：
| 能力 | Eino 提供 | DeepFlux 自建 | 为什么自建 |
|---|---|---|---|
| 图编排/调度 | ✅ Graph/Chain/Workflow | --- | 引擎能力，直接用 |
| 流式管道 | ✅ Pipe/StreamReader | SSE 会话层（HertzStreamer） | 业务要 critical 帧语义、断线恢复 |
| ChatModel 适配 | ✅ 多 Provider | profiles.yaml + Quirks 修复链 | 配置驱动 + 模型脾气数据化 |
| 记忆 | ❌ 无官方组件 | 四元组 scope + DecayScore + Profile | 作用域语义是业务决策 |
| 多租户 | ❌ 不在框架范围 | Postgres RLS + SET LOCAL + 双防线 | 隔离是合规要求不是功能 |
| 工具安全 | 中间件钩子 | 五层防线（白名单→HITL→护栏→nonce→审计） | 纵深防御，单层都会被绕过 |
| HITL | ✅ Interrupt/Resume + Checkpoint | 审批中心、超时兜底 CronJob | 面向人的流程完整闭环 |
| 可观测 | ✅ Callback 切面 | OTel 三信号 + Langfuse 双链路 | 企业要的是 trace_id 串日志和成本账单 |
规律很清楚：Eino 给的都是"引擎级"能力（跑、流、调、断），DeepFlux 建的都是"企业级"能力（租户、审计、防线、成本）。框架选型时真正该问的不是"它功能全不全"，而是"它的边界划在哪里、边界外的东西我建起来顺不顺手"。Eino 的 Callback/中间件留了足够的切面，这是自建部分能立起来的原因。
（五）诚实复盘：被推翻和会变的
- Qdrant → pgvector。README 顶部的注就是坦白：E09/E11 写于迁移前，Qdrant 内容是当时实现。少一个独立存储组件，运维面小一半------但代价是 HNSW 2000 维上限这类约束（E72）。
- FlowAgent / Supervisor 被标 NOT RECOMMENDED 。E92/E93 拆源码时反复遇到：Agent 间 Transfer 全量共享上下文，实践中效果不如预期，官方建议改用 AgentTool（Agent 就是 Tool，E91 的 Host-Worker 模式）。看源码注释里的"不推荐"比看功能列表更接近真相。
- 迁移数在长。143 → 145，两周 +2。任何"当前状态"的数字都是快照，复盘的价值在趋势和结构（序号连续、embed.FS 单一事实源），不在冻结的数值。
- CozeLoop 自建被否、Langfuse 双链路。生产可观测走过弯路：先自建，内存开销否决，最终 Langfuse JP 区 + 已有 OTel 并行------E88/E89 拆的就是最终形态，弯路只在篇尾提了一句。
（六）写作方法复盘：demo-first
99 篇每篇都有一个 /tmp/eNNdemo：纯标准库 Go、不连网、自检 panic。这个约束逼出了三件事：
- 没跑过的结论写不出来 。demo 崩了就是理解错了------E87 复刻 Callback 时自检抓出 3 处断言错误，E99 假客户端漏抄 nil 守卫当场空指针。复刻失败的地方，恰恰是源码里最值得讲的细节。
- 小白友好不是少讲，是讲能跑的。入门线每篇的最小示例都是"复制粘贴能跑"的，复杂度靠 demo 场景数递增，不靠文字堆砌。
- 每篇结尾"git 没动"。一个锚点：系列只读不写，两个仓库（eino/eino-ext/deepflux）在写作期间零改动------所有"实测"都是只读探测，这话说得出口是因为它可验证。
小结
100 篇，一句话收拢：企业级 Agent = 引擎（Eino）× 工程化（DDD/RLS/审计/防线）× 运维（迁移/可观测/交付），缺一条腿都站不稳。
系列到这里收官。两个仓库还在长（迁移 +2 只是开始），如果哪天 Eino 出了 ADK 正式版的多 Agent 方案、或者 DeepFlux 的 orchestration 上了新玩法，再来写续篇也不迟------老规矩，先跑 demo 再说话。