Orchestrator
Also: 編排器 · 編排層 · orchestration · lead agent
The layer that decides which task goes to whom, in what order, and how results are collected; in a lead/worker pattern, the lead that delegates rather than does.
When you will meet it
You meet it at the step from one agent to several. If you cannot see where orchestration logic lives, you will assume the model intuits the division of labour — when in fact task splitting, ordering and re-assignment are mostly rules written in ordinary code, with the model consulted only at a few fuzzy decision points.
An analogy
Like an orchestra conductor: plays no instrument, but decides who enters at which bar and at what tempo. Without a conductor the players can still play — they will just each play their own piece.
Minimal example
Orchestrator（普通程式為主，少量模型決策）：
1. 收到目標「調研 A、B 兩家公司並出對比報告」
2. 拆任務 → 調研A / 調研B / 對比分析 ← 規則，或問模型
3. 派工 → 子代理1 拿調研A，子代理2 拿調研B ← 程式
4. 收結果 → 兩份都到齊才進入對比 ← 程式（barrier）
5. 失敗處理 → 子代理2 超時 → 重派或降級 ← 程式Steps 3–5 are deterministic code. Keeping orchestration in ordinary code rather than begging the model to self-coordinate is what makes a multi-agent system debuggable: when it breaks you know which line to read.
What people get wrong
- Assuming the orchestrator is a bigger model. It can contain no model at all — plenty of production orchestrations are a task queue plus a few ifs, with the model appearing only for fuzzy calls like how to split the work.
- Letting the lead both delegate and do the work. Its context fills with task-level detail and delegation quality drops with it — which is exactly why execution goes to the workers.