一个团队兴冲冲地搭了一套"五 Agent 协作系统"：意图理解 Agent、路线规划 Agent、订单处理 Agent、客服 Agent、审计 Agent。上线后发现：80% 的用户请求都只需要意图理解 + 订单处理两个步骤，但每次都要走完整个五 Agent 链路，延迟翻了三倍，成本翻了四倍，出了问题不知道是哪个 Agent 的锅。
他们最终把系统重构成：一个主 Agent 处理大部分请求，只有涉及复杂路线规划时，才临时调用路线规划子 Agent。这才是对的。
目录 · Table of Contents
- 什么时候才需要多个 Agent When to Actually Introduce Multi-Agent
- 四种协作拓扑结构 Four Collaboration Topologies
- 任务拆分：怎么才算拆得对 Task Decomposition: What Good Splitting Looks Like
- 仲裁机制：意见不一致时怎么办 Arbitration: Resolving Agent Disagreements
- 成本控制：多 Agent 的隐形账单 Cost Control: The Hidden Bill of Multi-Agent
- 出行场景的协作设计实践 Multi-Agent Design in Mobility Scenarios
- 中英术语对照表 Bilingual Glossary
什么时候才需要多个 Agent
When to Actually Introduce Multi-Agent
A team enthusiastically built a "five-Agent collaboration system": an intent-understanding Agent, a route-planning Agent, an order-processing Agent, a customer service Agent, and an audit Agent. After launch, they discovered: 80% of user requests only required intent understanding + order processing — two steps. But every request had to traverse the full five-Agent chain, tripling latency and quadrupling cost, with no clear ownership when things broke. They ultimately refactored to: a single primary Agent handling most requests, with the route-planning Agent only invoked on-demand for complex itinerary tasks. That was the right design.
多 Agent 不是"更高级的架构"，而是解决特定问题的工具。引入多 Agent 的合理理由，只有以下几种：
Multi-Agent is not a "more advanced architecture" — it's a tool for solving specific problems. The only legitimate reasons to introduce multiple Agents are:
引入多 Agent 的合理理由
① 任务天然并行：两个子任务相互独立，可以同时进行，并行完成比串行快很多（如同时查火车和酒店）；
② 上下文窗口不够：单次任务的信息量超过单个模型的上下文限制，需要拆分后分别处理；
③ 专业化明确提升质量：某一类子任务用专门训练/提示的模型处理，质量明显好于通用 Agent；
④ 风险隔离：高风险操作（支付、数据写入）隔离在独立 Agent 中，出了问题不影响整体流程；
⑤ 任务量太大、需要规模扩展：并发任务数量超出单 Agent 处理能力，需要横向扩展。
Five legitimate reasons to introduce Multi-Agent: ① Naturally parallel tasks — two subtasks are independent and can run simultaneously, making parallel significantly faster than serial (e.g., simultaneously querying trains and hotels). ② Context window exhaustion — a task's information volume exceeds a single model's context limit, requiring decomposition. ③ Specialization clearly improves quality — a specifically tuned/prompted model handles a subtask category measurably better than a general Agent. ④ Risk isolation — high-risk operations (payment, data writes) are quarantined in a dedicated Agent so failures don't cascade. ⑤ Scale — concurrent task volume exceeds a single Agent's throughput, requiring horizontal scaling.
⚠ 不要为了"看起来高级"而用多 Agent
多 Agent 系统的调试难度是单 Agent 的平方级。每增加一个 Agent，你就增加了：一个可能出错的节点、一段 Agent 间通信可能丢失或错误传递的路径、一层需要监控和日志的链路。
先问自己：这个任务用一个优化过的单 Agent + 工具调用，真的搞不定吗？大多数时候，答案是"能搞定"。
Multi-Agent debugging complexity scales as the square of the number of Agents. Before reaching for Multi-Agent, always ask: can this task be solved with one well-optimized Agent + tool calls? Most of the time, the answer is yes.
四种协作拓扑结构
Four Collaboration Topologies
就像公司的组织架构有扁平制、层级制、矩阵制，Agent 系统的协作方式也有不同拓扑。选错了拓扑，系统会在你意想不到的地方出问题——要么协调成本太高，要么出了问题无人负责，要么扩展起来代价巨大。
Just as companies have flat, hierarchical, and matrix org structures, Agent systems have different collaboration topologies. Choosing the wrong topology causes problems in unexpected places — coordination overhead too high, unclear ownership when failures occur, or prohibitive scaling costs.
Multi-Agent 四种拓扑示意图 · 从简到复杂，引入门槛依次升高 · Four topologies from simple to complex
Topology 1
单 Agent + 工具
Single Agent with Tool Calls
一个 Agent 配备完整的工具集，处理所有任务。看起来不是"多 Agent"，但它其实是大多数场景的正确答案。
适用：任务流程清晰、工具集完备、并发需求不高的场景
调试简单
成本最低
并发能力有限
Topology 2
主从结构（Orchestrator-Worker）
Orchestrator + Worker Agents
"指挥官 Agent"负责理解目标、分解任务、分配给多个"执行者 Agent"，收集结果后汇总。
适用：任务可以拆解、子任务相互独立、需要并行提速的场景
可并行
职责清晰
指挥官是单点
Topology 3
对等网络（Peer Network）
Peer-to-Peer Agent Network
多个 Agent 平级协作，各自负责不同模块，可以相互调用和传递结果，没有单一指挥中心。
适用：任务模块边界清晰、模块间需要双向通信、无法预知任务流向的场景
无单点故障
协调复杂
调试最难
Topology 4
流水线（Pipeline）
Sequential Agent Pipeline
任务按固定顺序在多个 Agent 之间传递，每个 Agent 完成一个处理环节，输出作为下一个 Agent 的输入。
适用：任务处理有明确的先后顺序、每个环节质量需要独立保障的场景
流程清晰
质量可控
延迟叠加
Topology selection is determined by three axes: task coupling (how interdependent are subtasks?), quality requirements (does each stage need independent validation?), and team capability (can you debug distributed Agent interactions?). Start simple — most products begin with Topology 1 and graduate to Topology 2 only when a concrete bottleneck appears.
| 拓扑 Topology |
协调复杂度 Coordination |
调试难度 Debugging |
并行能力 Parallelism |
推荐使用阶段 When to Use |
|---|---|---|---|---|
| 单 Agent + 工具 | 最低 | 最低 | 低 | MVP 及大多数生产场景 |
| 主从结构 | 中 | 中 | 高 | 任务可拆分、有并发需求 |
| 对等网络 | 高 | 最高 | 最高 | 复杂生产系统、模块边界清晰 |
| 流水线 | 低 | 低 | 低 | 需要按序多级质检的场景 |
任务拆分：怎么才算拆得对
Task Decomposition: What Good Splitting Looks Like
"帮我规划一个从北京出发的三天两夜行程，顺便订好火车票和酒店。"
糟糕的拆分：把"规划行程"和"订火车票"、"订酒店"拆成三个独立 Agent，然后发现：规划的行程确定了，才能决定订哪个方向的票；订了票，才知道出发时间，才能订合适的酒店。三个任务之间有强依赖，并行起来乱成一锅粥。
好的拆分：先规划（单 Agent 决策），再并行执行订票和订酒店（两个 Worker 同时跑），既利用了并行，又保持了依赖顺序。
糟糕的拆分：把"规划行程"和"订火车票"、"订酒店"拆成三个独立 Agent，然后发现：规划的行程确定了，才能决定订哪个方向的票；订了票，才知道出发时间，才能订合适的酒店。三个任务之间有强依赖，并行起来乱成一锅粥。
好的拆分：先规划（单 Agent 决策），再并行执行订票和订酒店（两个 Worker 同时跑），既利用了并行，又保持了依赖顺序。
"Help me plan a 3-day Beijing departure trip and book the train and hotel." Bad decomposition: split "plan itinerary," "book train," and "book hotel" into three independent Agents — but the itinerary must be decided before knowing which direction to book; the train must be booked before knowing the departure time for the hotel. Strong dependencies between tasks make parallel execution chaotic. Good decomposition: plan first (single-Agent decision), then parallel-execute train booking and hotel booking (two Workers running simultaneously) — exploiting parallelism while respecting dependency order.
好的任务拆分，需要满足三个条件：
Good task decomposition requires three conditions:
好的任务拆分标准
① 子任务有明确的输入/输出边界：A 任务的输出是 B 任务的输入，两者之间的接口必须预先定义清楚，不能靠"Agent 自己理解"来传递信息；
② 子任务内聚、任务间松耦合：每个子任务内部逻辑完整，不依赖其他子任务的中间状态；需要信息共享时，通过明确的接口传递，而不是直接读写共享状态；
③ 拆分后可以带来实际收益：要么并行提速（两件事可以同时做），要么专业化提质（特定模型处理特定子任务明显更好），否则拆分只增加复杂度。
Three conditions for good decomposition: ① Clear input/output boundaries per subtask — the interface between subtask A's output and subtask B's input must be pre-defined, not left to "the Agent will figure it out." ② High cohesion within subtasks, loose coupling between them — shared information passes through explicit interfaces, not through shared mutable state. ③ Decomposition delivers actual benefit — either parallel speedup (two things done simultaneously) or specialization quality improvement (a specific model handles a specific subtask measurably better). Otherwise, decomposition only adds complexity.
依赖图：拆分前必须画的一张图
Dependency Graph: The Diagram You Must Draw Before Splitting拆分任务之前，先画依赖图：找出哪些子任务可以并行（没有依赖关系），哪些必须串行（B 依赖 A 的输出）。只有真正独立的子任务才值得并行执行。强行让有依赖的任务并行，只会引入同步问题和竞态条件。
Before splitting tasks, draw the dependency graph: identify which subtasks can run in parallel (no dependencies between them) and which must run in series (B depends on A's output). Only genuinely independent subtasks are worth parallelizing. Forcing dependent tasks to run in parallel only introduces synchronization problems and race conditions.
依赖图示例：先串行规划，再并行执行，最后汇总 · Serial planning → parallel execution → aggregation
仲裁机制：意见不一致时怎么办
Arbitration: Resolving Agent Disagreements
一个多 Agent 路线规划系统：路线 Agent A 推荐高铁（快但贵），路线 Agent B 推荐大巴（慢但省钱），两个 Agent 的结论互相矛盾，主 Agent 没有仲裁逻辑——于是它把两个答案都返回给了用户，并说"您可以自己选择"。用户愤怒地投诉："我要你们帮我决定，不是让我自己想。"
没有仲裁机制的多 Agent 系统，遇到分歧就会"甩锅"给用户。
没有仲裁机制的多 Agent 系统，遇到分歧就会"甩锅"给用户。
A multi-Agent route planning system: Route Agent A recommends high-speed rail (fast but expensive); Route Agent B recommends coach (slow but cheap). The two Agents' conclusions contradict each other, and the main Agent has no arbitration logic — so it returned both answers to the user with "you can choose for yourself." The user complained furiously: "I asked you to decide for me, not make me think." A multi-Agent system without arbitration logic offloads its conflicts onto the user.
当多个 Agent 产生不同结论时，系统必须有明确的仲裁机制，而不是把矛盾暴露给用户。常见的三种仲裁方式各有适用场景：
When multiple Agents produce conflicting conclusions, the system must have a defined arbitration mechanism — not expose the conflict to the user. Three common arbitration approaches, each suited to different contexts:
| 仲裁方式 Arbitration Method |
适用场景 When to Use |
优点 Pros |
风险 Risks |
|---|---|---|---|
| 指挥官最终决策 Orchestrator Decides |
有主 Agent，各 Worker 意见仅供参考 | 决策链短、速度快、责任清晰 | 指挥官若判断失误，无法被纠正 |
| 置信度加权投票 Confidence-Weighted Vote |
多个同级 Agent，各自有置信度评分 | 综合多方信息，减少单点偏差 | 置信度本身不可靠，可能误导投票 |
| 人工介入 Human Escalation |
高风险操作、置信度普遍低、分歧超过阈值 | 最安全，用户保有控制权 | 打断自动化流程，增加等待时间 |
Design your arbitration logic before deployment — not as a patch when conflicts appear in production. The key question: when two Agents disagree, who (or what) has the final word? The answer must be deterministic, not left to runtime improvisation. For high-stakes decisions (payment amounts, irreversible actions), always default to human escalation when confidence is below a defined threshold.
📋 产品负责人决策清单 · PM Decision Checklist
- 是否定义了"Agent 分歧阈值"？超过多大的分歧才触发仲裁，还是只要分歧就仲裁？
- 人工介入的等待时间是否可接受？对于时间敏感场景（如即将发车），人工仲裁可能来不及。
- 指挥官 Agent 失败时，系统有什么降级方案？指挥官是单点故障，必须有 fallback。
- 是否记录了每次仲裁的过程和结果？仲裁日志是日后改进仲裁策略的唯一依据。
- 用户是否需要知道背后有多个 Agent 在协作？通常不需要，但出错时如何解释需要设计。
Is an "Agent disagreement threshold" defined? How large must the divergence be before triggering arbitration? Is the human escalation wait time acceptable in time-sensitive scenarios (e.g., a train departing soon)? Does the Orchestrator Agent have a failure fallback? It's a single point of failure. Is every arbitration decision logged? Arbitration logs are the only basis for improving arbitration strategy over time. Do users need to know multiple Agents are collaborating? Usually no — but how to explain failures requires deliberate design.
成本控制：多 Agent 的隐形账单
Cost Control: The Hidden Bill of Multi-Agent
一个团队上线了主从结构的 Agent 系统。第一个月账单出来：LLM 调用费用是预算的 7 倍。他们以为是用量增长，但仔细一查，发现是设计问题：主 Agent 每次分配任务时，都把完整的对话上下文传给每个 Worker，每个 Worker 处理完再把完整上下文传回来——每次任务循环，上下文长度翻三倍，调用了 8 个 Worker，费用就是 24 倍。
上下文设计，是多 Agent 成本控制最容易被忽视的杀手。
上下文设计，是多 Agent 成本控制最容易被忽视的杀手。
A team launched an orchestrator-worker Agent system. The first month's bill: LLM costs were 7× budget. They assumed it was usage growth — but on close inspection, found a design problem: the Orchestrator was passing the full conversation context to every Worker on each task assignment, and every Worker was returning the full context back. Each task cycle tripled the context length. With 8 Workers, costs were effectively 24×. Context design is the most commonly overlooked cost killer in Multi-Agent systems.
多 Agent 系统的成本主要来自四个来源，需要分别应对：
Multi-Agent system costs come from four sources, each requiring a different mitigation strategy:
| 成本来源 Cost Source |
典型表现 How It Appears |
控制策略 Mitigation Strategy |
|---|---|---|
| 上下文膨胀 Context Bloat |
Agent 间传递完整对话历史，token 数量随轮次线性增长 | 只传必要的结构化摘要，而非完整上下文；Worker 只接收任务相关信息 |
| 不必要的大模型调用 Unnecessary Large Model Calls |
简单的格式校验、路由判断也调用 GPT-4 级别的模型 | 路由、格式处理用小模型（如 GPT-3.5、Haiku）；只有复杂推理才用大模型 |
| 结果缓存缺失 Missing Result Caching |
相同的查询重复调用工具/模型，没有缓存层 | 查询类结果加缓存（余票、路况可缓存 30-60 秒）；相同 prompt 的模型结果可短暂缓存 |
| 非关键路径串行化 Non-Critical Serial Execution |
可以异步处理的任务（如发通知、写日志）阻塞了主流程 | 非关键任务异步化，不阻塞主 Agent 的响应路径 |
The single most impactful cost-control intervention is context management: never pass the full conversation history to Worker Agents. Pass only the structured task spec. Workers are specialists — they don't need the full context of every prior turn to do their job. This one change typically reduces token consumption by 50-80% in orchestrator-worker architectures.
模型分层使用策略
Tiered Model Usage Strategy不是所有 Agent 都需要用同一个模型，也不是用最贵的模型系统就最好。合理的分层策略是：
Not every Agent needs the same model, and using the most expensive model everywhere doesn't produce the best system. A sensible tiered approach:
模型分层使用参考
🔴 大模型（GPT-4o / Claude Sonnet）：用于核心推理、复杂规划、需要高准确率的意图理解
🟡 中等模型（Claude Haiku / GPT-3.5）：用于任务路由、格式转换、简单信息提取、Worker 的标准化操作
🟢 规则/脚本：用于格式校验、数据清洗、确定性操作——不需要调用模型的地方坚决不调用
💡 原则：用最小够用的模型完成任务；复杂度决定模型级别，而不是"担心不够好就用大的"
Tiered model usage reference: ① Large models (GPT-4o / Claude Sonnet) — core reasoning, complex planning, high-accuracy intent understanding. ② Mid-size models (Claude Haiku / GPT-3.5) — task routing, format conversion, simple extraction, Worker standardized operations. ③ Rules/scripts — format validation, data cleaning, deterministic operations — never invoke a model where deterministic code suffices. Core principle: use the smallest sufficient model for each task; complexity determines model tier, not "use the biggest model just to be safe."
出行场景的协作设计实践
Multi-Agent Design in Mobility Scenarios
一个出行平台的 Agent 系统处理用户的综合出行请求：跨城出行涉及火车、打车、酒店，往往需要多个信息源同时查询，再统筹规划。单 Agent 串行处理时，用户等待时间超过 15 秒，差评率很高。引入并行架构后，三类信息同时查询，总响应时间压到了 4 秒以内，满意度显著提升。
但同一个平台，处理普通的"打一辆车"请求，依然是单 Agent 处理——没有必要为简单任务引入复杂架构。
但同一个平台，处理普通的"打一辆车"请求，依然是单 Agent 处理——没有必要为简单任务引入复杂架构。
A mobility platform's Agent system handles complex multi-modal travel requests: cross-city journeys involving trains, rides, and hotels require querying multiple information sources simultaneously and then integrated planning. With serial single-Agent processing, user wait times exceeded 15 seconds, generating high negative review rates. After introducing parallel architecture, the three information types were queried simultaneously, bringing total response time below 4 seconds with significant satisfaction improvement. Yet for simple "book me a ride" requests, the same platform still uses a single Agent — no reason to introduce complex architecture for a simple task.
出行场景的 Multi-Agent 设计，遵循一个核心原则：按任务复杂度选架构，而不是一刀切用最复杂的那个。以下是一个参考的分层架构：
Multi-Agent design in mobility scenarios follows one core principle: select the architecture based on task complexity, not a one-size-fits-most-complex approach. Here is a reference layered architecture:
出行场景 Multi-Agent 分层架构：路由 → 按复杂度分流 → 单 Agent 或并行 Worker · Layered architecture: route by complexity, then single or parallel
| Agent 角色 Agent Role |
职责 Responsibility |
推荐模型 Recommended Model |
关键设计要点 Design Notes |
|---|---|---|---|
| 意图路由 Agent Intent Router |
分析请求复杂度，决定走单 Agent 还是多 Agent 路径，提取关键参数 | 中等模型（Haiku） | 路由决策必须快速（<500ms）；路由错误成本高，需要测试集覆盖 |
| Orchestrator Agent Orchestrator |
接收复杂任务，拆解为子任务，分发给 Worker，收集结果后综合规划 | 大模型（Sonnet / GPT-4o） | 只传结构化任务参数给 Worker，不传完整上下文；设置任务超时 |
| 查询类 Worker Query Workers |
并行查询特定信息源（火车/酒店/打车），返回结构化结果 | 中等模型 / 直接 API | 查询结果可缓存 30-60 秒；失败要有默认返回值，不能让 Orchestrator 空等 |
| 异常处理 Agent Exception Handler |
处理退款申诉、行程异常、超出规则的边缘情况 | 大模型 + 人工 escalation | 异常 Agent 独立部署，出问题不影响主流程；需要完整的案例日志 |
Key insight from real deployments: the Intent Router is the most critical Agent in this architecture. Its job — deciding whether a request needs single or multi-Agent processing — determines the cost and latency of every user interaction. Invest heavily in testing and validating the router. A misrouted simple request through the full multi-Agent pipeline is pure waste; a complex request misrouted to single-Agent processing results in degraded output quality.
多 Agent 系统的调试难度是单 Agent 的平方级。
能用简单方案解决的问题，不要引入多 Agent。
能用简单方案解决的问题，不要引入多 Agent。
Multi-Agent debugging complexity scales as the square of the Agent count. If a simpler solution works, don't reach for Multi-Agent.
🏗 架构师视角 · Architect's Perspective
Multi-Agent 系统在出行场景最大的价值，不是"让 AI 更聪明"，而是"让系统在高并发场景下还能保持质量"——多个查询任务并行，比串行快 3-5 倍，这在时间敏感的出行场景里是真实的体验差距。
但要为此付出的代价是：每个 Agent 的输出都需要被验证（Worker 返回的结果对不对？Orchestrator 的规划合理吗？）、Agent 间的通信格式需要标准化、整体系统的可观测性要求成倍提升。
建议的演进路径：先把单 Agent 做稳定、做高质量；发现了具体的并行瓶颈（如多信息源查询慢）后，只在那一个环节引入多 Agent。不要一开始就设计完整的多 Agent 体系。
The greatest value of Multi-Agent in mobility scenarios is not "making AI smarter" — it's "maintaining quality at high concurrency." Running multiple queries in parallel is 3-5× faster than serial, which is a real and tangible experience gap in time-sensitive travel scenarios. But the price is real: every Agent's output needs validation, inter-Agent communication formats need standardization, and observability requirements multiply. Recommended evolution path: first make the single-Agent system stable and high-quality. When you identify a specific parallel bottleneck (e.g., slow multi-source queries), introduce Multi-Agent only for that specific bottleneck. Do not design a full multi-Agent system from day one.
中英术语对照表
Bilingual Terminology Glossary本篇涉及的核心概念，中英对照及简明释义。
多 Agent 系统
Multi-Agent System (MAS)
多个 AI Agent 协作完成任务的系统架构，各 Agent 有独立的职责和推理能力。
A system architecture in which multiple AI Agents collaborate to complete tasks, each with independent responsibilities and reasoning capability.
主从结构
Orchestrator-Worker Pattern
一个"指挥官 Agent"分解任务并分配给多个"执行者 Agent"的层级协作结构。
A hierarchical collaboration pattern where an Orchestrator Agent decomposes tasks and delegates to Worker Agents.
对等网络
Peer-to-Peer Agent Network
多个平级 Agent 相互协作、无单一指挥中心的网络拓扑，适合模块边界清晰的复杂系统。
A network topology where Agents collaborate as peers without a single coordination center, suited for complex systems with clear module boundaries.
流水线拓扑
Pipeline Topology
任务按固定顺序在多个 Agent 间传递，每个 Agent 处理一个环节，适合多阶段质检场景。
A topology where tasks are passed sequentially through multiple Agents, each handling one processing stage; suited for multi-stage quality validation.
任务拆分
Task Decomposition
将复杂任务分解为多个子任务的过程，好的拆分使子任务独立、可并行且有明确的输入输出边界。
The process of breaking a complex task into subtasks; good decomposition produces independent, parallelizable subtasks with clear input/output boundaries.
依赖图
Dependency Graph
描述任务间依赖关系的有向图，用于确定哪些子任务可以并行，哪些必须串行。
A directed graph depicting dependencies between tasks, used to determine which subtasks can run in parallel and which must run serially.
仲裁机制
Arbitration Mechanism
多 Agent 产生冲突结论时的决策规则，如指挥官决策、置信度投票或人工介入。
The decision rules applied when multiple Agents produce conflicting conclusions, e.g., Orchestrator decision, confidence-weighted voting, or human escalation.
意图路由
Intent Routing
根据用户请求的复杂度和类型，决定由哪个 Agent 或路径来处理的调度机制。
A dispatching mechanism that determines which Agent or processing path handles a request based on its complexity and type.
上下文膨胀
Context Bloat
多 Agent 间传递过多冗余上下文导致 token 消耗急剧增加的常见成本陷阱。
A common cost trap where Agents pass excessive redundant context to each other, causing token consumption to grow rapidly.
模型分层
Tiered Model Strategy
按任务复杂度选用不同能力/成本的模型，用最小够用的模型完成每类任务。
Using models of different capability/cost tiers based on task complexity — always using the smallest sufficient model for each task type.
并行执行
Parallel Execution
多个独立子任务同时运行，相比串行可显著缩短总响应时间，是多 Agent 最主要的价值来源。
Running multiple independent subtasks simultaneously; significantly reduces total response time compared to serial execution — the primary value driver of Multi-Agent architecture.
单点故障
Single Point of Failure (SPOF)
系统中一旦失败就会导致整体不可用的关键节点，主从架构中 Orchestrator 是典型的单点。
A critical node whose failure causes entire system unavailability; the Orchestrator in an orchestrator-worker architecture is a classic SPOF.
结果缓存
Result Caching
将工具调用或模型调用的结果临时存储，避免短时间内重复执行相同查询，降低成本和延迟。
Temporarily storing tool call or model call results to avoid re-executing identical queries within a short window, reducing cost and latency.
人工升级
Human Escalation
当 Agent 无法处理或置信度低时，将任务转交给人工处理的机制。
The mechanism of transferring a task to human handling when an Agent cannot resolve it or confidence is below threshold.
松耦合
Loose Coupling
Agent 或模块间通过明确接口交互，不直接依赖彼此的内部实现，便于独立修改和替换。
Agents or modules interacting through explicit interfaces without directly depending on each other's internals, enabling independent modification and replacement.
竞态条件
Race Condition
多个 Agent 并行操作共享资源时，因执行顺序不确定而导致结果异常的并发问题。
A concurrency issue where multiple Agents concurrently accessing shared resources produce inconsistent results due to non-deterministic execution order.
可观测性
Observability
通过日志、追踪、指标了解系统内部状态的能力，多 Agent 系统中尤为重要。
The ability to understand a system's internal state through logs, traces, and metrics; especially critical in Multi-Agent systems where failures are hard to reproduce.
任务超时
Task Timeout
设定子任务的最长执行时间，超时后触发 fallback，防止单个 Worker 阻塞整体流程。
A maximum execution time set for a subtask; triggers fallback upon expiry, preventing a single slow Worker from blocking the overall process.