| workflow | LLM 与工具被预定义代码路径编排的系统——步骤由代码写死，模型只在每一步内部自主。它和 agent 是一对架构区分，本课教的五个模式都属于这一端。 | Building Effective AI Agents — Anthropic Engineering |
| agent | 模型自主决定自己流程、自己掌控完成方式的系统。实现通常很简单，就是在循环里根据环境反馈使用工具的 LLM。 | Building Effective AI Agents — Anthropic Engineering |
| 链式 | prompt chaining：把任务拆成一串步骤，每次 LLM 调用处理上一次的输出，中间可以插程序化检查。适用于能干净拆成固定子任务的活。 | Building Effective AI Agents — Anthropic Engineering |
| 路由（routing） | 对输入先分类、再分发到专门化的后续任务，换来关注点分离和更专门的提示词。前提是类别清晰、分类本身能被准确完成。 | Building Effective AI Agents — Anthropic Engineering |
| 并行化 | LLM 同时处理多个子任务、输出由程序聚合的工作流，两个变体是分段和投票。 | Building Effective AI Agents — Anthropic Engineering |
| 分段 | Sectioning：把一个任务拆成互相独立的子任务并行跑，比如 12 份文档各审一遍。 | Building Effective AI Agents — Anthropic Engineering |
| 投票 | Voting：同一个任务跑多次拿到多样化的输出，再由代码聚合。 | Building Effective AI Agents — Anthropic Engineering |
| 编排者-工人 | orchestrator-workers：一个中心模型动态拆解任务、把子任务派给工人、再综合结果。关键是子任务不是预定义的，由编排者看输入现场决定。 | Building Effective AI Agents — Anthropic Engineering |
| 评审-优化 | evaluator-optimizer：一个 LLM 生成响应，另一个在回路里给评估与反馈，反复直到过关。适用于有明确评价标准、且迭代确有可测改进时。 | Building Effective AI Agents — Anthropic Engineering |
| 程序化关卡 | gate：链或回路里用代码（而非再一次模型调用）做的确定性检查，同样输入永远同样结论，用来拦住不合格的中间结果。 | Building Effective AI Agents — Anthropic Engineering |
| gate | 程序化关卡的英文原名，Anthropic 的模式图里就用这个词（原文引号一直一弯是它自己的排版）。 | Building Effective AI Agents — Anthropic Engineering |
| harness 循环 | 以 stop_reason 驱动的那个 while 循环：发消息、看停止原因、是 tool_use 就执行工具再发回、不是就返回。本课每个「节点」内部都是它。 | Building Effective AI Agents — Anthropic Engineering |
| stop_reason | 模型每次返回里说明「这轮为什么停」的字段，harness 循环靠它决定继续调工具还是收尾。 | Building Effective AI Agents — Anthropic Engineering |
| 最大轮数 | 给循环设的迭代上限，是一根保险丝——保证代码在任何情况下都会停。它维持控制,不判断质量。 | Building Effective AI Agents — Anthropic Engineering |
| 保险丝 | 本课对「最大轮数」这类兜底停止条件的比喻：平时不该触发,一旦触发说明别的停法没拦住。 | Building Effective AI Agents — Anthropic Engineering |
| 确定性验证器 | 能用代码判定对错的检查器：能用代码判的就别花钱问模型。本课把它从「终态」搬到了链的「环与环之间」。 | Building Effective AI Agents — Anthropic Engineering |
| 分层判分 | 能用代码判的先用代码判完，剩下代码判不了的才交给模型。本课把这条纪律照搬进回路的节点顺序（gate 在裁判前）。 | Building Effective AI Agents — Anthropic Engineering |
| 可测量的改进 | 只在复杂度能被证明改善了结果时才考虑增加它——每加一个节点、一层模式都要过这一关。 | Building Effective AI Agents — Anthropic Engineering |
| 谁持有计划 | 判断一个系统落在确定性哪一端的那根轴：计划在代码手里（workflow）还是在模型手里（agent）。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 工作流脚本自己持有循环、分支与中间结果 | 一手材料里描述 workflow 的那句话，也是本课「图」这个隐喻唯一的一手锚点：计划在脚本里，模型上下文只装最终答案。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 逐步留痕 | 运行时随运行推进逐步记录每个代理/节点的结果。这是一次运行能在同一会话内恢复的原因；跨进程续跑还要靠自己把状态落盘。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 查-修-再查 | 评审回路在产品里的形态：跑一个检查器、修掉没过的、重复直到通过或不再有进展。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 不再有进展 | 一种比最大轮数聪明的停法：盯这一轮有没有比上一轮好（分数没涨、未通过项没减少），没变好就止损。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 对抗式互审 | 让独立的代理对抗式地评审彼此的发现之后再上报。它是上报前的一次交叉互评，没有回边、不迭代——本课把它并进评审回路是归类,不是原文说的同一拓扑。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 组合成图 | 本课自己的工程隐喻,不是官方术语:把五个模式组合在一起时用来说清它们关系的一套画法。它唯一的一手锚点是「工作流脚本自己持有循环、分支与中间结果」。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 节点 | 本课画法里图的一个点:内部是一个完整的 runAgent 循环,或一段纯代码。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 回边 | 评审回路那条把产出绕回生成节点的连线。前四个模式都是直线,评审回路是第一个带回边的。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 分叉点 | 本课画法里路由那种「按判断结果走不同边」的点,对应代码里的分支。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 16 个并发代理 | Claude Code 工作流运行时的并发上界,CPU 更少时更少;单次运行总共 1000 个代理封顶。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 90.2% | 多 Agent 系统相对单 Agent 的提升,只在完整语境里成立:他们的内部研究评测、Opus 4 主代理配 Sonnet 4 子代理、尤其广度优先查询。 | How we built our multi-agent research system — Anthropic Engineering |
| 4 倍 | 按他们自己的数据,代理消耗的 token 大约是聊天式交互的 4 倍。 | How we built our multi-agent research system — Anthropic Engineering |
| 15 倍 | 按他们自己的数据,多 Agent 系统消耗的 token 大约是聊天式交互的 15 倍;要在经济上成立,任务价值得高到配得上这份提升。 | How we built our multi-agent research system — Anthropic Engineering |
| 90% | 引入两级并行(主代理并行起 3-5 个子代理、子代理并行用 3 个以上工具)后,对复杂查询把研究时间砍掉最多的比例。它是延迟数字,不是质量数字。 | How we built our multi-agent research system — Anthropic Engineering |
| 派工提示词 | 编排者交给每个工人的那份任务说明。派工提示词必须自包含,四要素齐全,否则工人之间会重复劳动、留空白、找不到必要信息。 | How we built our multi-agent research system — Anthropic Engineering |
| 四要素 | 一份合格派工要写全的四段:目标、输出格式、工具与来源的使用指引、清晰的任务边界。 | How we built our multi-agent research system — Anthropic Engineering |
| 配额规则 | 写进编排者提示词的伸缩刻度:按任务复杂度规定子代理数量和每个子代理的工具调用上限,因为代理不擅长自己判断该投入多少。 | How we built our multi-agent research system — Anthropic Engineering |
| 伸缩规则 | 他们嵌进提示词的伸缩规则示例:简单事实查证 1 个代理 3-10 次调用;直接对比 2-4 个子代理各 10-15 次;复杂研究 10 个以上子代理并明确分工。 | How we built our multi-agent research system — Anthropic Engineering |
| 同步执行 | 编排者等所有工人跑完再进下一步的执行方式。瓶颈在于:一步卡住整批等,结果都落回编排者。 | How we built our multi-agent research system — Anthropic Engineering |
| 传引用不传载荷 | 工人把产出存进外部系统,只把轻量引用(文件路径 + 一行摘要)传回编排者,而不是把详细结果整个塞回主对话。 | How we built our multi-agent research system — Anthropic Engineering |
| 工件系统 | 让专门的代理把产出创建成能独立留存的东西(文件、外部记录),而不是全都通过主代理转达。传引用不传载荷靠它实现。 | How we built our multi-agent research system — Anthropic Engineering |
| 轻量引用 | 传回编排者的那条短记录:id、文件路径、一行摘要。谁要看全文照路径去读。 | How we built our multi-agent research system — Anthropic Engineering |
| 涌现行为 | 多 Agent 系统里,子代理各自的小决定叠起来产生的、单看每一步预测不到的整体行为;微小改动会沿着链路放大。 | How we built our multi-agent research system — Anthropic Engineering |
| 关注点分离 | 每个子代理带不同的工具、提示词、探索轨迹,天然不互相污染,还减少路径依赖。这是扇出除了提速之外买到的东西。 | How we built our multi-agent research system — Anthropic Engineering |
| 路径依赖 | 一个循环里,后一步的判断被前一步的措辞带偏的现象。多条独立轨迹不共享同一个偏差,因此减少路径依赖。 | How we built our multi-agent research system — Anthropic Engineering |
| 共享同一份上下文 | 多 Agent 今天不擅长的场景之一:要求所有代理看同一份上下文、或代理之间依赖很多的活(比如大多数编码任务),真正可并行的部分比研究少。 | How we built our multi-agent research system — Anthropic Engineering |
| 确定性护栏 | 包在非确定性代理外面的那层确定性机制:重试逻辑、定期检查点这类。图的骨架是确定性的,节点内部是非确定性的。 | How we built our multi-agent research system — Anthropic Engineering |
| 确定性系统 | 给定相同输入每次都产生相同输出的系统。代码写的关卡、验证器、聚合都属于这一类。 | Writing effective tools for agents — with agents — Anthropic Engineering |
| 非确定性 | 即使起始条件相同也可能给出不同回应的特性,agent 就是这一类。 | Writing effective tools for agents — with agents — Anthropic Engineering |
| 一条评测任务配一个循环 | 官方给评测推荐的跑法:直接调 LLM API、用简单的 agentic while 循环,一条评测任务配一个循环。本课借它说明「链的一个阶段是一个完整循环」。 | Writing effective tools for agents — with agents — Anthropic Engineering |
| 子代理 | 主对话派出去、在自己独立上下文窗口里干活、只把摘要交回来的代理。用来把探索和实现挡在主对话之外、保住上下文。 | Create custom subagents — Claude Code 官方文档 |
| 主对话 | 编排者那条主线上下文。子代理完成后结果回到这里,所以回传要轻,否则保护变负担。 | Create custom subagents — Claude Code 官方文档 |
| 20 个子代理 | Claude Code 默认的并发上界:一个会话里 20 个子代理在跑时再起一个会失败,且明确告诉模型不要重试。 | Create custom subagents — Claude Code 官方文档 |
| 顺序使用子代理 | Claude Code 对多步骤工作流的建议:让 Claude 按顺序用子代理,每个做完把结果交回,再把相关上下文传给下一个。这是链式在产品里的样子。 | Create custom subagents — Claude Code 官方文档 |
| 专门化 | Specialization:把活路由给带领域专属系统提示词和工具的代理(安全代理、文档代理),而不是把所有能力塞进同一个代理。是路由在现行第一方词汇里的名字。 | Multiagent orchestration — Claude API 文档（Managed Agents） |
| 升级 | Escalation:就一部分复杂子任务去咨询能力更强的代理或模型。注意是「咨询」(协调者仍持有控制),不是整体移交。 | Multiagent orchestration — Claude API 文档（Managed Agents） |
| Parallelization | 现行 Claude 平台多代理编排文档里的一条:并行扇出独立子任务(检索多个来源、分析不同文件),再由协调者汇总。 | Multiagent orchestration — Claude API 文档（Managed Agents） |
| 25 个并发线程 | Managed Agents 支持的并发上界;协调者可以调用同一个代理的多个副本,各自开线程。 | Multiagent orchestration — Claude API 文档（Managed Agents） |
| 并发池 | 固定开 N 条泳道,每条跑完手上这个就从共享游标取下一个,永远有 N 个在飞。比分批少了木桶效应。本课脚本里叫 runPool。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 并发上界 | 同时在飞的任务数的硬顶。三个真实产品(Claude Code 20、工作流运行时 16、Managed Agents 25)都设了,无界扇出是事故不是优化。 | Create custom subagents — Claude Code 官方文档 |
| 分批 | 每批 N 个、批与批之间串行的限流办法。能用,但有木桶效应:每批都要等本批最慢的跑完才开下一批。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| Promise.all | 把一组异步任务并发跑、全部完成再返回的写法。脾气是任何一路 reject 整个就 reject,其余哪怕跑完结果也拿不到。 | Building Effective AI Agents — Anthropic Engineering |
| 扇出 | fan out:把一件工作同时铺给多个代理/节点跑。买到速度、独立视角、并行上下文容量,代价是结果落回编排者、真实产品都设上界。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 汇合 | merge:扇出的结果回来后由代码做筛选、汇总、判定的那一步。本课让它只从文件读回引用,不把全文塞进上下文。 | Building Effective AI Agents — Anthropic Engineering |
| 载荷 | 工人产出的详细内容本身。汇合时载荷回灌会撑爆上下文,所以传引用不传载荷。 | How we built our multi-agent research system — Anthropic Engineering |
| 分类器 | 路由最前面那一步:判输入归哪一类,输出收紧到一个词。可以是模型,也可以是传统分类模型或算法。 | Building Effective AI Agents — Anthropic Engineering |
| 兜底 | 分类收不进合法标签表时走的那条分支(比如归入「其他」)。模型偶尔回一整句而不是一个词,兜底把这份不确定关在一行里。 | Building Effective AI Agents — Anthropic Engineering |
| 确定性光谱 | 本课自创的说法,不是官方术语:把 workflow 到 agent 之间那根「谁持有计划」的轴当成一条从确定到自主的连续区间。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 逐步留痕带来可恢复 | 每个节点跑完就把状态落一次,而不是跑完全程才落。挂在半路时磁盘上已有前面几步的完整结果,能接着跑。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 受控崩溃 | 本系列第 9 门课的做法:在指定点主动把进程停掉,验证状态确实落到了磁盘。本课的 STOP_AFTER 是它的简化版。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 空转 | 循环连续几轮做同样的事、没有任何进展的状态。本系列第 7 门课的阀3(空转检测)就是拦它的。 | Building Effective AI Agents — Anthropic Engineering |
| 原子写 | 先写 .tmp 再 rename 替换的落盘法:任何时刻被杀,磁盘上要么是上一份完整状态、要么是新的完整状态,不会出现半截 JSON。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| run-state.json | 本课脚本记执行留痕的文件(每个节点跑完落一次、评审里每判一条再落一次),用原子写保证任何时刻可读。它记的是执行进度,不是「图的状态那几个变量」。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| run.jsonl | 本课脚本的结构化日志:一行一个 JSON 事件,带 ts 和 run_id,只记 id/类别/文件名/计数,不记回复正文。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| 桩 client | 用固定响应队列冒充真实 API 的测试替身:client.messages.create() 按顺序返回预先写好的响应,让整段编排零依赖、可复现地跑。 | Writing effective tools for agents — with agents — Anthropic Engineering |
| STOP_AFTER | 本课脚本的受控崩溃开关:设成 merge 就在评审之前停下、退出码 2,用来验证扇出/汇合的状态确实落了盘。只认 merge 这一个值。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |
| needs_human | 回路给不出合格产出时的结局标记:退出码 1 那类工单会停在这里,转人工接手。 | Orchestrate subagents at scale with dynamic workflows — Claude Code 官方文档 |