第 12 章：流式输出与子图
12.1 图的三种流式（stream_mode）
# 模式一 updates：每个节点跑完吐一次"谁更新了什么" ------ 进度条/调试首选
for chunk in graph.stream(inputs, config, stream_mode="updates"):
print(chunk) # {'agent': {'messages': [...]}} → {'tools': {...}} → ...
# 模式二 values：每步之后吐"完整白板快照"
for state in graph.stream(inputs, config, stream_mode="values"):
print(len(state["messages"]))
# 模式三 messages：LLM 的 token 级流式 ------ 打字机效果在图里的形态
for token, metadata in graph.stream(inputs, config, stream_mode="messages"):
if token.content:
print(token.content, end="", flush=True)现在图把它抬升了一层：updates 流"步骤"、messages 流"字"------真实产品往往两者组合（前端上方滚动"正在查询天气..."的步骤条，下方打字机输出正文）。FastAPI 会把这两路流转成 SSE 推给浏览器。
12.2 子图：把一张图当另一张图的节点
图也是可复用组件------编译好的图直接 add_node 进另一张图：
python
research_graph = build_research_graph() # 一张完整的"资料调研"图
report_builder = StateGraph(ReportState)
report_builder.add_node("research", research_graph) # ★整图作为一个节点
report_builder.add_node("write", write_node)
# State 字段同名的部分自动衔接；字段不同时用包装函数做映射三个用途：复用 （一套调研子图，周报/竞品/尽调三处引用）、解耦 （各团队维护各自子图，父图只管编排）、隔离 （子图有自己的内部状态，不污染父图白板）。它也是下一批多智能体层级架构的地基：所谓"主管调度专家"，工程形态常常就是"父图调度子图"。
第 13 章：Plan-and-Execute 与 Reflection 的 LangGraph 实现
第 4 章的两个范式，现在画成图。注意读法：不要背代码，盯着"State 设计 + 边的走向"看------范式的灵魂全在这两处。
13.1 Plan-and-Execute（含重规划）
START → planner → executor ⇄(条件边:还有步骤?) → replanner →(条件边:完成?) → END
▲______________没完成且计划有变_______________|
python
from pydantic import BaseModel, Field
class Plan(BaseModel):
steps: list[str] = Field(description="剩余待执行步骤，按顺序")
class PEState(TypedDict):
task: str
plan: list[str] # 待办
done: list[str] # 已完成步骤及其结果摘要
answer: str
planner_llm = llm.with_structured_output(Plan)
worker = create_agent(model=llm, tools=TOOLS, # 每步的执行者=一个工具Agent
system_prompt="你是执行专员，完成给定的单一步骤并给出结果。")
def planner(state: PEState) -> dict:
p = planner_llm.invoke(f"为任务制定不超过4步的执行计划：{state['task']}")
return {"plan": p.steps, "done": []}
def executor(state: PEState) -> dict:
step = state["plan"][0] # 领第一条待办
out = worker.invoke({"messages": [{"role": "user",
"content": f"总任务：{state['task']}\n已完成：{state['done']}\n当前步骤：{step}"}]})
result = out["messages"][-1].content
return {"plan": state["plan"][1:], # 出队
"done": state["done"] + [f"{step} → {result[:200]}"]}
def replanner(state: PEState) -> dict:
if not state["plan"]: # 计划清空 → 汇总作答
summary = llm.invoke(
f"任务：{state['task']}\n各步结果：{state['done']}\n请给出最终答案。")
return {"answer": summary.content}
return {} # 还有活，不动白板
def after_replan(state: PEState) -> str:
return END if state.get("answer") else "executor"
builder = StateGraph(PEState)
builder.add_node("planner", planner)
builder.add_node("executor", executor)
builder.add_node("replanner", replanner)
builder.add_edge(START, "planner")
builder.add_edge("planner", "executor")
builder.add_edge("executor", "replanner")
builder.add_conditional_edges("replanner", after_replan, {"executor": "executor", END: END})
graph = builder.compile()两处点睛：worker 本身是个 create_agent ------"图的节点里再跑一个 Agent"，Agent 套 Agent 从此不神秘；replanner 现在只做"完没完"判断，升级方向是让它也带 structured_output 修改剩余计划（步骤失败时换路）------留作练习。
13.2 Reflection（生成-批改回环）
START → generate ⇄ reflect →(条件边: 满意 或 轮数到? ) → END
python
class RefState(TypedDict):
task: str
draft: str
critique: str
rounds: int
def generate(state: RefState) -> dict:
prompt = (f"任务：{state['task']}\n"
+ (f"上一版：{state['draft']}\n修改意见：{state['critique']}\n请针对性修订。"
if state.get("critique") else "请给出第一版。"))
return {"draft": llm.invoke(prompt).content,
"rounds": state.get("rounds", 0) + 1}
def reflect(state: RefState) -> dict:
c = llm.invoke(
f"你是苛刻的审稿人。指出下文3处最需要修改的具体问题并给出改法；"
f"若已足够好，只回复'PASS'。\n\n{state['draft']}")
return {"critique": c.content}
def should_continue(state: RefState) -> str:
if "PASS" in state["critique"] or state["rounds"] >= 3: # 双保险出口
return END
return "generate"
builder = StateGraph(RefState)
builder.add_node("generate", generate)
builder.add_node("reflect", reflect)
builder.add_edge(START, "generate")
builder.add_edge("generate", "reflect")
builder.add_conditional_edges("reflect", should_continue, {"generate": "generate", END: END})
reflection_graph = builder.compile()第 14 章：低代码平台 ------ Dify 与 Coze（扣子）
14.1 为什么代码派也必须懂平台
国内相当比例的 Agent 岗位（业务线、交付、解决方案）JD 直接写"熟悉 Dify/Coze"。平台与代码不是对立面：平台 = 把你学过的所有概念做成可拖拽的积木。你现在去用它们，是降维体验：
|----------------|------------------------------|
| 平台里的积木 | 你手写过的对应物 |
| 应用编排 / 工作流画布 | LangGraph 的节点与边 |
| 知识库（上传即问答） | 整条 RAG 流水线（切分/向量库/召回参数它都让你调） |
| 插件 / 工具 | @tool + TOOL_REGISTRY |
| 变量 / 会话变量 | State 与 checkpoint |
| Prompt 编排 / 人设 | 系统提示词 |
| 发布成 API / 网页 | FastAPI 封装 |
两者速览：Dify ------开源 LLMOps 平台，可私有化部署（docker compose 一键起），企业自建首选，工作流能力强；Coze（扣子）------字节系，2025 年 7 月起核心（Coze Studio）开源，插件生态大、一键发布到飞书/微信等渠道，字节系与 To C 场景常见。另外阿里百炼、百度千帆 AppBuilder、字节 HiAgent 属于云厂商企业版同类。
14.2 两小时体验任务（必做）
在 Dify（cloud.dify.ai 或本地部署）或 Coze 上复刻你的 assistant_v1 + 知识库：建应用 → 粘入你的系统提示词 → 挂天气/计算插件 → 上传 04 批的员工手册建知识库 → 用你的评测集问 10 题 → 发布并分享链接。
体验后写三行对比笔记（面试原题素材）：平台快在哪（起步/发布/给非技术同事用）？代码强在哪（深度定制/复杂路由/评测自动化/版本管理）？选型口诀：验证想法与标准场景用平台，复杂逻辑与深度工程用代码，大型团队常"平台承接长尾需求 + 代码攻坚核心链路"并存。
第 15 章：2026 框架生态地图与选型
老规矩：记"定位"不背版本。截至 2026 年中的格局，选型前看官方最新文档。
|------------------------------|-----------|-------------------------------------------------------------|----------------------|
| 框架 | 出品 | 一句话定位 | 什么时候选它 |
| LangGraph | LangChain | 状态图编排，checkpoint/HITL/可观测配套最全 | 企业生产默认答案，复杂有状态流程 |
| OpenAI Agents SDK | OpenAI | 极简轻量（Agent/Handoff/Guardrail 三概念），迭代飞快 | 快速原型、深绑 OpenAI 生态的团队 |
| AutoGen → MS Agent Framework | 微软 | 多智能体对话研究起家，已与 Semantic Kernel 整合为 Microsoft Agent Framework | 微软云/.NET 系企业 |
| CrewAI | 社区 | "角色扮演小队"抽象（role/goal/task），上手最快 | 教学、内容生产类多角色流水线 |
| LlamaIndex | 社区 | 数据侧（RAG）起家的框架，Agent 能力完备 | 以文档/数据处理为核心的应用 |
| Qwen-Agent | 阿里 | Qwen 官方 Agent 框架，FC/RAG/浏览器使用开箱即用 | Qwen 私有化技术栈 |
| AgentScope | 阿里 | 面向多智能体的工程化框架（1.x），国内大厂背书 | 国内多 Agent 生产项目 |
| Eino | 字节 | Go 语言的编排框架 | 字节系/Go 后端团队 |
| Spring AI Alibaba | 阿里 | Java 生态的 Agent 开发 | Java 大厂存量团队 |
| Dify / Coze | ------ | 低代码平台（上一章） | 快速交付、非工程角色协作 |
面试选型题的万能答法（背结构不背结论）："先问四个约束------团队语言栈？流程复杂度与状态要求？部署形态（SaaS/私有化）？谁来维护（工程师/业务）？------再落到框架。例如：Python 团队+复杂有状态流程+要审批与断点→LangGraph；Java 存量系统→Spring AI Alibaba；业务同事要自己改逻辑→Dify。" 展示决策框架，比报一个"最强框架"高一个段位。