从循环到图：Agent 系统的编排工程

这是本系列的收官课，讲一个循环之上的那层工程。你在本系列第 7 门课手写的 harness 是一个循环——官方的说法就是「Agent 通常只是在循环里根据环境反馈使用工具的 LLM」。但任务大到一定程度，一个循环开始不够用：要跑的东西大过一个上下文窗口、同一步要在几十个条目上重复、或者需要的代理多到一场对话协调不动。这门课教你把控制流从模型手里拿回到代码手里：先分清 workflow（LLM 与工具被预定义代码路径编排）和 agent（模型自主决定自己的流程）这对架构区分，认清「谁持有计划」这根轴；然后把五个经过生产验证的工作流模式逐个写成代码——链式与路由、并行化（分段与投票）、编排者-工人、评审-优化回路；正视一个真实上线系统的账本：90.2% 的提升（他们的内部研究评测、Opus 4 主代理配 Sonnet 4 子代理、尤其擅长广度优先查询）与 15× 的 token 开销是同一枚硬币的两面，同步执行的瓶颈、协调复杂度的暴涨、派工提示词的四要素都是他们踩过的坑；最后把这些模式组合起来——本课把这种组合叫「图」，这是我们自己的画法，不是官方术语——亲手把你本系列第 7 门课的单循环 harness 升级成一段确定性的编排脚本：路由、扇出、汇合、评审回路，循环还是那个循环，只是计划搬进了代码。适合已完成本系列前 11 门课的读者。本课不教任何第三方编排框架（LangGraph 等一律不提），不重教多 Agent 协作的分工与沟通（那是本系列第 6 门课），也不重教工作流的概念与画图（那是本系列第 2 门课）——这门课管的是控制流怎么落成一段你能读、能跑、能重跑的代码。

课程大纲

学习目标

完成本课程后，你将能够：

说清 workflow 与 agent 的架构区分（预定义代码路径 vs 模型自主决定流程），用「谁持有计划」判断一个系统落在确定性的哪一端，并识别「一个循环不够用」的真实触发条件与不该上编排的场景
把链式与路由写成代码：每个阶段是一个完整的 harness 循环，阶段之间加程序化关卡，分类后分发到专门化的提示词，并知道这么做换来了什么、付出了什么
实现并行化的两种变体（分段与投票），用代码聚合结果，说清扇出的收益（速度、独立视角、并行上下文容量）与代价（结果落回编排者、真实产品都设并发上界），并用「传引用不传载荷」控制汇合成本
实现编排者-工人模式并说清它与并行化的关键差异（子任务不是预定义的，由编排者按输入决定）；给派工提示词配齐四要素（目标、输出格式、工具指引、任务边界），按任务复杂度配额，并正视同步执行的瓶颈与异步的三项代价
实现评审-优化回路（查-修-再查，直到通过或不再有进展）并用两个判断标志决定它值不值得建；把五个模式组合成本课所称的「图」——明知这是本课自己的工程隐喻，锚在「工作流脚本自己持有循环、分支与中间结果」这条一手依据上
亲手把本系列第 7 门课的单循环 harness 升级成一段确定性编排脚本：路由 → 扇出三个工人 → 汇合 → 评审回路 → 汇报，状态留在脚本变量里、逐步留痕可对账，并逐条核对它没有违背第 3、4、5 课与本系列第 7、9、10、11 门课立下的承诺

前置要求

完成本系列前 11 门课，或具备等同基础
能手写以 stop_reason 驱动的 harness 循环（本系列第 7 门课；本课的「图」的每个节点就是它）
了解多 Agent 协作的分工原则与派活提示词（本系列第 6 门课）、评测验证（第 10 门课）与观测（第 11 门课）
能读写基础的 JavaScript / Node.js 代码（第 6 课需要跟着写）

预计学习时间

约 3-4 小时，包括每课的动手练习