智能体循环与编排

一个 AI Agent 拆到最底层，其实只是一个不断重复的小循环：把完整对话交给模型，看它"怎么停下来的"，照它说的去执行，把结果补进对话，再送一次。这是确定性的控制流，写死在代码里——不是一个提示词技巧，不是一个重试循环，也不是聊天机器人式的一问一答。这一讲把这套循环的四个步骤、以及围绕它的三种常见翻车方式讲透，是整个 Domain 1 的地基：这一点吃透了，后面大半内容都会顺理成章；吃不透，Agent 上线后就会在任务做到一半时莫名其妙地停住。

循环固定是这四步，一直重复到任务真正完成：①通过 Messages API 把请求发给 Claude，带上完整的对话历史(系统提示词、之前的消息、上一轮的工具结果)；②检查返回结果里的 stop_reason 字段——这是判断接下来该干什么的唯一权威信号；③如果 stop_reason 是 tool_use，就执行模型请求的工具，把工具结果作为一条新消息追加进对话历史，再把更新后的对话重新发回去；④如果是 end_turn，说明模型已经做完了，把最终结果呈现给用户，循环结束。最容易翻车的正是第③步：工具结果必须被追加进对话历史——漏了这一步，模型在下一轮完全看不到工具刚刚返回了什么，也就没有任何新信息可以继续推理。

考试之外，还有更新的现实：官方考试大纲(v1.0)只考 tool_use 和 end_turn 这两个值，一个基础循环靠这两个分支就够用。但真实的 Messages API 会返回更多取值，一个真正上生产的循环必须处理：pause_turn(一个耗时较长的服务器端工具调用还没跑完，先暂停一下)、max_tokens(输出被长度上限截断)、stop_sequence(命中了你设置的停止序列)、refusal(模型在一个本来正常的请求上拒绝了，比如新一代模型可能出现这种情况)，以及 model_context_window_exceeded(这一轮响应把上下文窗口塞满了，处理方式类似 max_tokens 被截断)。稳妥的做法是：只要不是 end_turn，一律当成"还没真正做完，得先查一下为什么"，而不是想当然地当成 tool_use 来处理。

模型驱动的流程控制，是让它是"智能体"而不是"写死脚本"的地方：在这个循环里，是模型自己看着当下的上下文——已经用工具学到了什么、还缺什么——决定要不要再调一次工具、调哪个，这和开发者提前写死的决策树或固定工具调用顺序完全是两回事。考试更偏爱"模型驱动"这个方向，因为它能灵活应对开发者没预料到的情况、能处理边界场景、能按谁都没规划过的顺序串联工具。但有一个例外必须记住：一旦业务逻辑要求"确定性合规"——涉及金钱操作、安全检查、监管要求——就应该用代码层面的强制盖过这份灵活性，这一点在 1.4 会深入展开。

三个反复出现的翻车方式，务必都能一眼认出来：①靠解析自然语言信号——检查模型有没有说"我做完了""任务完成"这类话来判断该不该停，问题在于自然语言天生模糊，模型完全可能一边说"我已经查完第一个文件了"一边其实还打算继续查后面的文件，stop_reason 存在的意义正是消灭这种模糊性；②把任意设定的迭代次数上限当成主要的停止机制——设"最多循环 10 次"当收工的主要依据，问题是它要么在任务真的需要 12 轮时被强行截断，要么在任务 3 轮就做完时白白空转，模型自己会通过 stop_reason 发出完成信号，迭代上限只该当一张"防止失控"的安全网，绝不能当主要控制机制；③把"这一轮有没有输出文字"当成"是不是做完了"的替身——用类似 response.content[0].type == "text" 这样的判断来收工，问题是模型完全可以在同一次回复里，一边给出解释性文字，一边紧跟着请求调用工具，文字的出现根本不能说明任务已经结束。一个常见的干扰选项是：把"设置迭代上限"包装成premature termination(过早终止)问题的解法——这个方向要拒绝，迭代上限治的是"失控空转"，治不了"过早收工"，过早收工唯一的正确修法，永远是把 stop_reason 判断对。

实战案例：过早终止的 bug——一个开发者做了一个客服 Agent，处理简单问题时一切正常，遇到复杂请求时却常常做到一半就停了。代码里用的判断逻辑是 response.content[0].type == "text"。真正的 bug 是：模型返回了一段解释性文字("我先查一下您的订单")，紧跟着在同一个响应里附带了一个请求调用 lookup_order 工具的 tool_use 块；代码只看到数组第 0 位是文字，就直接判定"任务已完成"，把这个还没做完的回复原样返回给了用户。修法很直接：把"检查内容类型"整个换成"检查 stop_reason"——stop_reason == "tool_use" 就继续循环，stop_reason == "end_turn" 才终止，这样无论响应里出现什么类型的内容块，判断都不会出错。

多智能体编排，说的是怎么让好几个 Claude Agent 一起协作完成一件复杂任务。考试对这件事的考法并不宽松，只考一种模式："总控台 + 分工位"(hub-and-spoke(中心—分支结构))，一个协调者(coordinator)坐在正中间。这套架构分两种角色：协调者——坐在中心，接收最初的任务、把任务拆解开、决定要调用哪些子智能体、把上下文传给它们、汇总它们的结果、处理错误、并且在它们之间路由信息；子智能体——也就是外围的分工位，各自负责一件专门的事(网页搜索、文档分析、综合信息、生成报告)，接受协调者下发的指令，再把结果交回给协调者。

这里有一条铁律：所有通信都必须经过协调者。子智能体之间永远不直接沟通——不为了效率，不为了方便，任何理由都不行。任何一条要在子智能体之间流转的信息，都必须先经过协调者这一站。现实情况的补充：这条"绝对不能"的铁律，是考试为了讲清楚道理而做的简化——当前版本的 Claude Code 里，一个子智能体其实是可以自己再派生出下一层子智能体的(嵌套的父子委派关系)，并不是产品层面的硬限制。但在考试里，任何"子智能体之间直接沟通"的选项，都应该判定为错误答案。把所有通信收口到协调者这一处，换来的是考试真正看重的三件事：可观测性(所有消息都能在一个地方被记录和监控)、一致的错误处理(协调者统一应用一套错误恢复策略)、可控的信息流(协调者决定每个子智能体到底能看到哪些上下文)。

多智能体系统里最容易被误解的一点，也是考试最爱利用这份误解出题的地方，叫隔离原则：子智能体不会自动继承协调者的对话历史。协调者派生出一个子智能体时，这个子智能体拿到手的，只有协调者明确写进它提示词里的那些内容——它看不到协调者的系统提示词(除非被明确包含进去)、看不到协调者对话里之前的消息、看不到其他子智能体查到的结果(除非协调者转交)、也没有任何"共享内存"或全局状态可以依赖。子智能体之间也不共享记忆：如果协调者两次调用同一个网页搜索子智能体，第二次调用对第一次调用一无所知，每一次派发都是完全独立的。正因如此，协调者必须刻意地管理上下文——子智能体需要的每一条信息，都得明明白白写进它的提示词里；如果综合信息的子智能体需要网页搜索的结果，协调者就必须把这些结果传过去，它没法自己"去查"，因为根本不存在什么共享存储可以查。这里有一个常考的陷阱：当一个多智能体系统产出的结果不完整或者不对，考试希望你能顺着往回追到问题真正的源头，而不是去怪产出结果的那个子智能体——该查的是协调者当初有没有给它对的输入。

协调者身上真正要担的四件事，也是考试反复考察的：①动态选择子智能体——协调者要分析这次请求具体需要什么，动态决定调用哪些子智能体，不应该每次都不假思索地把全套流水线走一遍；一个简单的事实性问题，可能只需要网页搜索这一个子智能体，根本用不上完整的"调研—分析—综合"全链路，把每个请求都塞进每个子智能体，只是在白白浪费时间和资源。②划分调研范围——往多个子智能体派发任务时，协调者要把调研范围拆分清楚，尽量减少重复劳动：把不同的子话题或不同类型的信息来源分配给不同的智能体(比如一个查学术论文，另一个查新闻报道，而不是两个都查同样的来源)。③迭代式的精炼循环——协调者要评估综合出来的结果有没有覆盖缺口，如果不完整，就带着更有针对性的问题，重新派发给调研和分析类的子智能体，反复调用综合环节，直到覆盖面真正够了为止——这不是一次性的单次流程，而是一个可以来回迭代的循环。④集中式的通信路由——所有子智能体之间的通信都要经过协调者路由，为的正是可观测性、一致的错误处理和可控的信息流这三件事。

这一讲最值得记住、也是考题里的一个特定模式，叫"拆解范围太窄"：官方样题里有一道题(常被引用为 Q7)，协调者把"AI 对创意产业的影响"这个大任务，拆解成了只包含视觉艺术方向的几个子话题，完全漏掉了音乐、写作和电影。根本原因出在协调者的任务拆解这一步，不在任何下游子智能体身上——负责搜索的子智能体认认真真查完了分给它的题目，综合子智能体也认认真真综合了它收到的一切信息，问题是协调者一开始就只分配了视觉艺术这一个方向，音乐、写作、电影这几个子话题根本没有被派发给任何人去查。这个规律适用范围很广：只要产出的结果在范围上不完整(而不是深度不够)，几乎总能追溯到协调者的拆解阶段。

实战案例：调研系统的覆盖缺口——一套多智能体调研系统被要求调研"可再生能源技术"，协调者把这个题目拆成了"太阳能板效率"和"风力发电机设计"两个子话题，两个子智能体各自都产出了详尽、来源可靠的调研内容。最终报告在太阳能和风能这两块写得很全面，却对地热能、潮汐能、生物质能、核聚变只字未提。这个覆盖缺口，不是因为搜索做得不好、也不是综合环节偷懒，而是因为协调者从一开始就没有把这些子话题分配出去。真正的修法，不是换更好的搜索关键词，不是换一个更强的综合智能体，也不是简单地多加几个子智能体——而是让协调者的拆解方案真正覆盖到这个主题应有的全部广度。