Day 39 / 共 68 天 · 阶段 7 编排框架

为什么要编排框架

昨天(Day 38)你亲手写出了一个能跑的 Agent,阶段 6 通关!但那 60 行只是"能跑",离"能上线"还差一截。今天(阶段 7 开篇)我们诚实地算一笔账:手写循环会撞上哪五道墙(状态/分支/并行/可视化/持久化),为什么几乎所有人最后都投奔了"编排框架"。想清楚这笔账,你才知道明天(Day 40)学 LangGraph 到底在解决什么。

📍 你在阶段 7（编排框架 D39-44）的位置
D39 为什么要框架→ D40 LangGraph①→ D41 LangGraph②→ D42 CrewAI→ D43 eino→ D44 选型
💡 用一个类比兜住今天（今天全程沿用「从一个人的小面馆，开到连锁餐厅」的世界观） 昨天的手写 Agent = 一个人的路边小面馆:一个人点单、下面、端菜、收钱,忙但转得动。今天要面对的是:客人变多、菜单变复杂、还要开分店。状态持久化 = 打烊后账目要留档、明天接着用;分支/循环 = 客人有各种特殊要求,得看情况走不同流程;并行 = 三桌同时点单,不能一桌一桌排队死等;可视化/观测 = 后厨要有叫号屏和监控,哪道菜卡住一眼看见;编排框架 = 一整套连锁店的标准化后厨系统(工位、传菜、监控、可复制)。今天你会明白:小面馆没错,但要开连锁,得换套系统。
L01

手写循环到底够不够用？

🤔 痛点昨天那 60 行明明能跑,为啥还要学一堆花名的框架?会不会是"为了显得高级而套框架"?
💡 本质手写循环够学、够小项目、够原型——真别一上来就套框架。但当需求变复杂,你会发现自己在一遍遍重写同样的水管:存状态、写 if 分支、搞并行、加日志……框架就是"别人已经把这些水管铺好了,你直接接上"。判断标准很简单:当你开始在 Agent 里手搓这些基础设施,就是该上框架的信号。
👶 一句话小面馆(手写)没错,是"连锁扩张"(复杂/上线)时手写才吃力。今天不是否定昨天,是告诉你手写的边界在哪。
"编排(orchestration)"这个词,就是指把多个步骤/多个 Agent 按顺序、按条件、按并行组织起来协同干活——像乐队指挥调度各个声部。框架 = 帮你做编排的工具。
L02

痛点①：状态与持久化，全得自己焊

🤔 痛点昨天的对话历史存在一个内存变量里。程序一关就没了。想"用户明天回来接着聊""跑挂了断点续跑"(Day 37 讲的),你得自己写存文件、读文件、按用户区分存档栏……这些和业务无关的水管,越焊越多。
💡 本质框架自带 state + checkpointer(正是 Day37 学的):你只管定义"黑板上有哪些字段",存哪、怎么按用户区分、怎么读档续跑,框架全包了。像连锁店总部给你一套现成的账务系统,你不用自己发明记账法。
📝 举个例子：同一件事，手写 vs 框架 "让 Agent 支持多用户、各自会话不串、关机还能续":
手写 → 你要设计存档文件命名、加锁、序列化、按 user_id 隔离、崩溃恢复……几十行且容易出 bug。
框架 → 开一个内置 checkpointer,传个 thread_id 区分用户,一两行搞定,续跑白送。
L03

痛点②：分支与循环，if 越堆越乱

🤔 痛点真实流程不是一条直线:检索到资料就写稿、没检索到就换个查法;写完要审校,审校不过要打回重写。手写就是一层层 if/else 套 while,三五个分支后,没人(包括你自己)看得懂流程长啥样了。
💡 本质框架让你把流程画成一张图(graph):每个环节是一个节点,环节之间用边连,"满足什么条件走哪条边"单独声明(叫条件边,Day41 细讲)。流程从"埋在代码里的 if 迷宫",变成"一眼看懂的路线图"。像后厨把"什么情况走哪个工位"贴成流程图,新人也能照着走。
埋在 if 里的分支 vs 画成图的分支 ❌ 手写：嵌套 if 迷宫 if 检索到: 写稿 if 审校不过: while 重写... else: 换查法... ✅ 框架：画成路线图 检索 写稿 审校 不过↩
图注：同一套"检索→写稿→审校→不过就回炉"的逻辑，右边这种"节点+边"的图，改流程时只需挪一条边。

👶 小白：if/else 我熟啊，画成图反而多学一套概念，值吗？

👨‍🏫 老师：三五个分支时 if 确实够。但 Agent 流程会长大——加个"人工审批"、加个"失败降级"、加个"某条件回炉重来"。图的好处是每个节点、每条边都是独立的、能单独测的,改一处不牵动全身;而嵌套 if 改一层容易碰坏另一层。更重要的是,图能画出来给别人看、能被框架监控——这正是下面两讲的痛点。

L04

痛点③：并行，手搓 async 容易翻车

🤔 痛点要同时查"天气、机票、酒店"三样,再汇总。串行做 = 一个查完再查下一个,慢三倍。想并行,你得自己上 asyncio(Day08)、管好三个结果怎么合并回同一块黑板、某个失败了怎么办——手搓并发是出 bug 的重灾区。
💡 本质框架里"并行"往往就是从一个节点画出几条边到多个节点,框架自动同时跑、自动等它们都回来、自动把结果合并进 state(还记得 Day37 说的"追加"吗?合并靠的就是那个)。你只画图,并发的脏活框架干。像后厨三桌同时点单,传菜系统自动调度,不用你一桌桌排队。
📝 举个例子：查旅行三件套 "查天气 + 查机票 + 查酒店,都好了再汇总":
手写 → asyncio.gather 起三个任务、逐个 try、结果拼字典、一个超时全盘处理……小心翼翼几十行。
框架 → 从"开始"节点连三条边到三个查询节点,再都汇到"汇总"节点。并行、等待、合并都是框架默认行为。
L05

痛点④：可视化与可观测，出了问题两眼一抹黑

🤔 痛点手写 Agent 跑挂了,你只能靠 print 猜:它到底走了哪几步?在哪一步卡住?这步给 LLM 发了啥、LLM 回了啥、花了多少 token、多少钱?全靠你自己埋日志,埋得还乱七八糟。上线后更是黑箱。
💡 本质框架能把流程图画出来(哪些节点、怎么连一目了然),还能接可观测平台(如 LangSmith / Langfuse,Day55 细讲):每次运行走了哪几步、每步的输入输出、耗时、token、报错,全自动记成一条可点开的轨迹(trace)。像后厨那块叫号监控屏——哪道菜卡在哪个工位,抬头就看见,不用逐个工位去问。
一次运行的轨迹（trace）：每步都留痕 检索0.8s · 320 tok 写稿2.1s · 900 tok 审校 ⚠️超时！卡这 未执行
图注：有了轨迹，"哪步慢、哪步崩、花了多少 token"一屏看清——这是从"能跑"迈向"能上线"的关键差距。
能力手写循环编排框架
状态 & 断点续跑自己焊存档/读档内置 checkpointer，两行开启
分支 & 循环嵌套 if/while，易乱节点+条件边，画成图
并行手搓 asyncio，易翻车多条边自动并行+合并
可视化 & 观测靠 print 猜流程图 + trace 一屏看清
人在环路(审批)自己实现暂停/恢复interrupt 内置
L06

今日小结 + 动手 10 分钟

🧠 今天你应该能回答

  • 手写循环什么时候够用?什么信号出现时该上框架?(开始手搓基础设施时)
  • "编排(orchestration)"是什么意思?(按顺序/条件/并行组织多个步骤)
  • 手写会撞上的四道墙分别是什么?(状态持久化 / 分支循环 / 并行 / 可视化观测)
  • 框架把流程画成"图"有什么好处?(每节点每条边可单独测、可视化、可监控)
  • "轨迹(trace)"能看到什么?对上线为什么重要?

✋ 动手 10 分钟：给昨天的手写 Agent 挑三个痛点

不写代码,做一次"需求体检"。拿出昨天(Day 38)的 60 行 Agent,拿张纸回答:

# 自问自答（写在注释里都行）：
# 1) 若要"用户关掉再回来、接着上次聊"，我得在这份代码里加哪些东西？大概几行？
# 2) 若流程变成"查资料→写稿→审校，审校不过就回炉重写最多3次"，
#    我的 if/while 会变多乱？画一画它的"节点+边"图。
# 3) 若要同时查天气+机票+酒店再汇总，我打算怎么并行？会卡在哪？
# —— 把这三题的"手写代价"写下来，就是你明天学 LangGraph 时最有共鸣的清单。

这一步看着虚,其实最值钱:先痛过,才知道框架的每个 API 在救你哪条命。

明日预告 · Day 40:主角登场——LangGraph①。明天你会用它最核心的三个概念 StateGraph / add_node(加节点) / add_edge(连边),把昨天手写的 Agent重新画成一张图,亲眼看到"痛点②分支"是怎么被"图"这个思路化解的。今天列的痛点清单,明天一条条被接住。
← Day 38 · 手写最小 Agent Day 40 · LangGraph① 把 Agent 画成图 →