Điều phối multi-agent: Năm pattern và khi nào một agent thắng

Một công ty Bồ Đào Nha viết email về hóa đơn FT-2026-0918. Email nói VAT có vẻ sai và đính kèm hóa đơn: net EUR 248.00, VAT tính 21 %, EUR 52.08, tổng EUR 300.08.

Các dữ kiện cần để trả lời nằm ở ba nơi, và chỉ một trong số đó nằm trong email:

Ghép cả ba lại thì hóa đơn sai: áp dụng reverse charge, VAT lẽ ra phải bằng không, cần phát hành credit note EUR 52.08. Chỉ nhìn vào hóa đơn thì nó hoàn hảo về số học — 248.00 cộng 52.08 bằng 300.08 — và bạn sẽ nói vậy.

Email đúng là có nói "chúng tôi là một công ty Bồ Đào Nha". Đó là một lời khai, không phải hồ sơ, và không hệ thống billing nào phát hành credit note dựa trên một lời khai. Cái bẫy không phải mẹo: đó là hình dạng bình thường của công việc kinh doanh, nơi quyết định cần một dữ kiện mà không ai nghĩ phải lấy.

Mọi thứ ở trên chạy với một provider được kịch bản hóa theo phong cách Chương 23, với đúng một quy tắc:

Một câu trả lời chỉ được dùng dữ kiện có trong prompt của nó.

"Model" yêu cầu từng công cụ mà nó có, mỗi công cụ một lần, theo thứ tự catalogue, rồi áp dụng một quy tắc cố định lên văn bản nó nhìn thấy. Không có gì được kịch bản riêng theo từng cách sắp xếp, nên các khác biệt trong bảng mở đầu không phải tuyên bố về trí thông minh của model: chúng là định tuyến thông tin, được đo. Một model thật sẽ thêm các lỗi riêng của nó lên trên; nó không loại bỏ những lỗi này.

Năm tên bên dưới là của Anthropic, từ Building effective agents, nơi bộ từ vựng này ổn định.¹ Không ý tưởng nào trong năm ý tưởng là mới, và nói nhà nào đặt tên cho cái gì — và ý tưởng nào cũ hơn — là một nửa giá trị của việc biết chúng.

/* 1. Prompt chaining: a fixed pipeline. The control flow is yours. */
export async function chain(steps: Step[], first: string) {
  let carry = first, all = first;
  for (const s of steps) {
    const r = await step(s.role, s.system, s.accumulate ? all : carry);   
    carry = r.text;
    all = `${all}\n${r.text}`;
  }
  return carry;
}

/* 2. Routing: one cheap call picks the branch. The fallback is not a model. */
export async function route<T>(input: string, classify: Classifier,
                               routes: Record<string, Branch<T>>, fallback: Branch<T>) {
  let label: string | undefined;
  try { label = await classify(input); } catch { label = undefined; }
  return ((label && routes[label]) || fallback)(input);                    
}

/* 3. Parallelisation. The pattern IS this line. */
export const parallel = <T>(workers: Branch<T>[], input: string) =>
  Promise.all(workers.map((w) => w(input)));                              

/* 4. Orchestrator-workers: an agent behind a tool. Chapter 18's interface, unchanged. */
export function agentTool(o: WorkerSpec): Tool {
  return {
    name: o.name, description: o.description, readOnly: true,
    parameters: { type: "object", properties: { question: { type: "string" } } },
    async run(args: { question: string }) {
      const child = newRun(o.system, args.question);          // its own window
      await runTracked(child, o.tools, o.usage);              // its own limits
      const conclusion = child.output ?? "no result";
      if (!o.carryFindings) return conclusion;                             
      return `${conclusion}\nFINDINGS ${evidence(child)}`;                 
    },
  };
}

/* 5. Evaluator-optimiser: make, judge, remake. Rounds are calls. */
export async function refine(make: Make, judge: Judge, maxRounds: number) {
  let draft = "", feedback: string | undefined;
  for (let r = 1; r <= maxRounds; r++) {
    draft = (await make(feedback)).text;
    const j = await judge(draft);
    if (j.ok) return { draft, rounds: r };
    feedback = j.note;
  }
  return { draft, rounds: maxRounds };
}

Đó là toàn bộ bộ công cụ: năm hàm, không framework, và bản song song chỉ là một dòng — đó chính là lý do viết nó ra thay vì vẽ. Giờ xét từng cái, với nguồn gốc, giá của nó, và trường hợp nó sai.

Prompt chaining "phân rã một nhiệm vụ thành một chuỗi bước, trong đó mỗi lượt gọi LLM xử lý output của lượt trước".¹ Ý tưởng này có trước language model: nó là một pipeline, với đánh đổi của pipeline — rõ ràng đổi lấy luồng điều khiển được cố định trước khi dữ liệu đến.

Bốn bước cho nhiệm vụ của chúng ta: trích xuất các trường hóa đơn, kiểm tra số học, quyết định khoản nợ, viết phản hồi. Ở đây nó thất bại theo hai cách khác nhau, và điều đó dạy nhiều hơn việc chỉ thất bại một lần.

--- relay: each step sees only the previous step's output
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 vat_amount=52.08 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=unknown reason=no_invoice_in_context
draft:   "we are looking into invoice FT-2026-0918 and will come back to you."

--- accumulating: each step sees the email and everything produced so far
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=invoice_correct reason=net_248.00_plus_21pct_vat_52.08_equals_300.08
draft:   "we have checked FT-2026-0918 and it is correct... Nothing is owed back."

Chuỗi relay tốn $0.001940 và làm mất các trường hóa đơn giữa bước hai và bước ba, vì bước ba chỉ được đưa một câu về số học và không gì khác. Nó tạo ra một tin nhắn chờ xử lý: vô dụng, và vô dụng một cách thấy rõ.

Chuỗi tích lũy — hàng trong bảng mở đầu — tốn $0.003780, tức đắt hơn 95 % cho bốn lượt gọi giống hệt, vì giờ mỗi bước mang theo mọi thứ trước nó. Nó tạo ra output nguy hiểm. Trôi chảy, trích dẫn phép tính của mình, đúng trên mọi con số nó nhắc tới, và nói với khách hàng rằng không nợ gì trong khi đang nợ EUR 52.08.

Khác biệt giữa hai cái là một toán tử ternary. Một chain mang ít dữ liệu hơn tạo ra câu trả lời rõ ràng là thiếu; một chain mang mọi thứ tạo ra câu trả lời tự tin nhưng sai — và chỉ loại thứ hai được gửi đi.

Cả hai đều không phải thất bại thật sự. Thất bại thật sự là pipeline đã quyết định, trước khi đọc bất cứ thứ gì, rằng nhiệm vụ này gồm bốn bước trên nội dung của một email. Trong cấu trúc đó không có chỗ nào để nói "quốc gia đăng ký không nằm trong email này; đi lấy nó". Chaining đúng khi phân rã đã biết trước và ổn định. Ở đây nó là một phỏng đoán, và phỏng đoán đó đã được ship.

Routing "phân loại một input và hướng nó tới một tác vụ theo sau chuyên biệt".¹ Tên gọi thì mới; cơ chế là dispatcher, cũ hơn gần như mọi thứ khác trong cuốn này. Điều mới là classifier có thể là một model — và chính điều đó làm nó thất bại theo những cách mà một switch chưa từng thất bại.

const answer = await route(email,
  (q) => classifyWithSmallModel(q),          // cheap model, one call
  { billing: billingAgent, tax: taxAgent, dunning: dunningAgent },
  taxAgent,                                  // deterministic, chosen in advance
);

Có hai điều về đối số cuối cùng đó. Nó không phải xử lý lỗi; nó là pattern. Router dựa trên model có một failure mode mà dispatcher không có: nó có thể trả về một nhãn không tồn tại, timeout, hoặc — trường hợp đắt đỏ — trả về một nhãn sai nhưng nghe hợp lý mà không có tín hiệu nào cho biết nó sai. Cả ba đều phải rơi vào đâu đó, và nơi đó không thể là một lượt gọi model khác, vì bạn đã ở nhánh nơi các lượt gọi model thất bại.

Điều thứ hai là prompt của chính router không miễn phí. Để chọn một model, router cần một catalogue các model để chọn, và mỗi mục trong đó là input mà router phải trả tiền trước khi nó đọc câu hỏi của người dùng. Ở mức giá input mà khóa học này dùng để định giá, một catalogue khoảng 3,800 token đã tốn ngang toàn bộ lượt chạy agent năm-call trong bảng mở đầu. Trên thực tế, lượt routing chạy trên một model rẻ, đó là toàn bộ lý do routing tự hoàn vốn; nhưng phép tính đáng được làm theo hướng đó thay vì giả định. Routing sai chính xác khi tác vụ được route rẻ hơn quyết định routing.

Anthropic chia mục này làm hai: sectioning — "chia một nhiệm vụ thành các subtasks độc lập chạy song song" — và voting — "chạy cùng một nhiệm vụ nhiều lần để nhận output đa dạng".¹ Chúng dùng chung một sơ đồ và gần như không có gì khác chung.

Sectioning là thắng lợi rẻ, và là dòng từ patterns.ts: ba specialist — billing, tax, policy — mỗi người có cửa sổ và công cụ riêng, trên cùng email, với một lượt gọi tổng hợp ở cuối. Cùng một công việc, sắp xếp theo hai cách:

Giống nhau từng token, nhanh hơn 1,8 lần. Đó là lý do pattern này xứng đáng có tên riêng: nó là pattern duy nhất trong năm cái cải thiện được một thứ mà không tốn gì thêm. Điểm mắc là các phần phải thật sự độc lập — đưa cho phần B một dữ kiện do phần A tạo ra và Promise.all sẽ chạy cả hai trên một trạng thái chưa tồn tại. Vòng lặp for che giấu bug đó; bản một dòng phơi nó ra.

Voting là một loài khác đội cùng bức tranh. Chạy cùng câu hỏi k lần rồi lấy đa số là self-consistency, được Wang và cộng sự công bố vào tháng 3 năm 2022 như một chiến lược decoding, gần ba năm trước khi có ai gọi nó là một pattern orchestration. Tóm tắt của bài báo rất chính xác về cơ chế — "đầu tiên lấy mẫu một tập đa dạng các đường suy luận thay vì chỉ lấy đường greedy, rồi chọn câu trả lời nhất quán nhất bằng cách marginalizing out các đường suy luận đã lấy mẫu" — và về mức tăng: +17.9 điểm trên GSM8K.²

Từ đó có hai hệ quả mà bức tranh che khuất. Thứ nhất, voting đòi hỏi sampling của Chương 17: ở temperature bằng không, mọi mẫu k đều là cùng một mẫu, và đa số là một câu trả lời được trả tiền k lần. Thứ hai, nó chỉ hiệu quả ở nơi đa số có ý nghĩa — với phản hồi hóa đơn ở trên thì không có gì để đếm, vì năm bản nháp là năm câu khác nhau. Voting dành cho tác vụ có câu trả lời ngắn, có thể so sánh, đúng như các benchmark của Wang và gần như không có gì mà một agent hướng khách hàng làm.

Đo ở đây trên 20 bài toán lời văn ba bước có đáp án được tính chứ không phải được phán xét, với model cục bộ của Chương 23 suy luận từng bước:

Gấp năm lần lượt gọi, gấp năm lần token, đúng gấp năm lần hóa đơn, và không thêm một câu trả lời đúng nào. Voting là một ván cược, không phải một cải tiến, và lượt chạy này đã thua.

Hai lưu ý, trước khi ai đó trích câu đó như một phản bác Wang. Hai mươi thử nghiệm không thể phân biệt 45 % với 60 % — khoảng này rộng bằng chính tuyên bố, tức kỷ luật của Chương 4 áp lên kết quả của chính tôi. Và các mức tăng đã công bố đến từ các model lớn hơn nhiều bậc, nơi các đường suy luận đa dạng mà voting marginalises over thật sự đa dạng. Điều chuyển giao không phải con số: đó là hệ số nhân là chính xác và biết trước, còn mức tăng thì không.

Trong workflow orchestrator-workers, "một LLM trung tâm phân rã tác vụ một cách động, ủy quyền cho các worker LLM, và tổng hợp kết quả của chúng", và khác biệt so với sectioning là "subtasks không được định nghĩa trước, mà do orchestrator xác định".¹ Nguồn gốc ở đây hoàn toàn không đến từ language model: đây là master-worker, và phiên bản nơi các worker ghi phát hiện vào một không gian chung để controller đọc là kiến trúc blackboard, từ nghiên cứu speech understanding thập niên 1970. Điều mới vào năm 2026 là controller là một model và vì thế việc phân rã có thể được quyết định theo từng input — vừa là linh hoạt, vừa là chi phí, trong một câu.

Nó tốn 12 lượt gọi model so với 5 của single agent, và đạt cùng kết luận. Rồi nó làm một điều đáng nhìn kỹ:

orchestrator final: VERDICT=credit_note_due amount=52.08 source=worker_unverified
                  | PO_MISMATCH=yes source=worker_unverified
single agent:       VERDICT=credit_note_due amount=52.08 reason=reverse_charge_should_have_applied
                  | PO_MISMATCH=yes invoice_says=PO-4417 order_says=PO-4471

Cả hai đều đúng. Chỉ một cái biết vì sao. Tax worker có hóa đơn, đơn hàng và bảng thuế trong cửa sổ riêng, đi đến kết luận, và cũng nhận thấy — không ai yêu cầu — rằng số purchase order trên hóa đơn không khớp với đơn hàng. Rồi nó trả về một summary. Orchestrator có thể lặp lại cả hai phát biểu và không kiểm tra được phát biểu nào, vì bằng chứng nằm lại trong một cửa sổ mà nó chưa từng thấy. Đó là câu hỏi kết thúc Chương 24, đã có câu trả lời: agent cha được nhìn vào bất cứ thứ gì agent con chọn ghi xuống.

Cách sửa là một flag, và nó có giá:

Nhiều hơn mười hai phần trăm input tokens, thêm 8.3 % tiền, và cụm source=worker_unverified biến mất khỏi câu trả lời. Đó là đánh đổi trong mọi multi-agent system và gần như không bao giờ được nói rõ: cửa sổ sạch của agent con đáng có, khả năng audit của agent cha đáng trả tiền, và bạn không thể có cả hai miễn phí.

Vậy khi nào orchestrator-workers sai? Ở đây, trên tác vụ này. Nó mua một câu trả lời đúng mà một agent với cùng bốn công cụ cũng đạt được, với chi phí gấp 1.66 lần và wall clock gấp 2.3 lần, đồng thời làm câu trả lời đó khó bảo vệ hơn. Chính hướng dẫn của Anthropic cũng nói vậy trước khi các pattern bắt đầu: tìm "giải pháp đơn giản nhất có thể, và chỉ tăng độ phức tạp khi cần", vì "agentic systems thường đánh đổi latency và chi phí để có hiệu năng tác vụ tốt hơn".¹ Các bảng trên là câu đó với con số bên dưới.

Một lượt gọi tạo ra, một lượt khác đánh giá, và vòng lặp lặp lại cho đến khi đánh giá đạt.¹ Các tiền thân đã công bố là Self-Refine — cùng một model làm "generator, refiner, and feedback provider", báo cáo cải thiện tuyệt đối khoảng 20 điểm trung bình trên bảy tác vụ³ — và Reflexion, lưu critique trong một bộ đệm episodic qua các lần thử và báo cáo 91 % pass@1 trên HumanEval trong khi baseline đạt 80 %.⁴

Mô hình chi phí là đơn giản nhất trong năm cái: hai lượt gọi mỗi vòng, và số vòng không thuộc về bạn. Ba vòng refinement trên một tác vụ vốn tốn một lượt gọi là sáu lượt gọi, nên sàn của pattern là 6× và trần là bất kỳ cap nào bạn đặt — điều này làm lối thoát theo ngân sách của Chương 23 trở thành bắt buộc chứ không chỉ gọn gàng.

Trần thì tinh tế hơn, và đo được. Trên cùng 20 bài toán, model cục bộ trả lời đúng 9. Sau đó nó được cho xem từng câu trả lời đó và được hỏi liệu câu trả lời có đúng không — không cho biết đó là câu trả lời của chính nó, để loại bỏ nhiễu xu nịnh và chỉ còn năng lực:

Đó là một giám khảo tốt hơn tiêu đề mục gợi ý, và nói vậy chính là điểm của việc đo thay vì khẳng định: nó không chặn câu đúng nào và bắt được 8 trong 11 lỗi. Như một bộ lọc, nó đáng giá các lượt gọi.

Như một quy tắc dừng, tức thứ mà vòng lặp evaluator-optimiser thật sự dùng, ba phê duyệt đó là toàn bộ câu chuyện: chúng kết thúc vòng lặp với một câu trả lời sai trong tay, và không số vòng bổ sung nào chạm được tới chúng. Một vòng refinement không thể trở nên đúng hơn giám khảo của nó. Mua thêm vòng là mua thêm các lần thử nhắm vào lỗi mà giám khảo nhìn thấy, với giá đầy đủ, và hoàn toàn không có gì trước các lỗi nó không thấy.

Vì vậy quy tắc là: một evaluator chỉ xứng đáng với lượt gọi của nó khi nó có thứ mà generator không có. Một compiler, một test suite, một schema validator, một model khác, một con người. Kết quả của chính Self-Refine được đo theo human preference và metric tác vụ, không bao giờ theo ý kiến của model về chính nó. Nếu lợi thế duy nhất của evaluator là một prompt khác, bạn đang trả gấp đôi để mua sự đồng thuận. Chương 29 xây dựng phiên bản có lợi thế thật: một golden set với đáp án được viết sẵn từ trước.

Năm cái trên là hình dạng cho code của bạn. Bên dưới chúng có một họ thứ hai thường được liệt kê cùng và không nên như vậy: ReAct, Reflexion, plan-and-execute và tree of thoughts là reasoning loops, và chi phí của chúng nằm ở request.

Chương 12 nói về reasoning bên trong model, thứ bạn trả bằng output tokens trong một lượt gọi. Đây là loại còn lại. Khác biệt quan trọng khi hóa đơn đến: một chain of thought dài hơn làm một lượt gọi đắt hơn, còn reasoning loop biến một tác vụ thành nhiều lượt gọi, mỗi lượt lại gửi lại mọi thứ trước nó — độ bậc hai mà Chương 23 đã đo trong bảng runaway.

Bài báo tree-of-thoughts công bố bảng chi phí của chính nó, điều hiếm hơn mức nên có. Trên Game of 24 với GPT-4: input/output prompting best-of-100 giải được 33 % với $0.13 mỗi case, chain of thought best-of-100 giải được 49 % với $0.47, và tree of thoughts giải được 74 % với $0.74, với ghi chú của tác giả rằng nó "có thể cần số generated tokens nhiều hơn CoT 5-100 lần".⁷

Giá gần sáu lần phương pháp rẻ cho tỷ lệ thành công hơn gấp đôi một chút. Đó có phải món hời hay không phụ thuộc vào một case thất bại khiến bạn tốn gì — câu hỏi cần đặt ra trước khi áp dụng bất kỳ cái nào trong bốn cái này.

Khóa học này không reimplement chúng. Cả bốn đều có reference implementations do chính tác giả viết, bằng Python, và giá trị của chúng là nguồn gốc chứ không phải bản dịch: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm và AGI-Edgerunners/Plan-and-Solve-Prompting. Hãy đọc các prompts trong những repository đó; prompts chính là các bài báo.

Giờ là multi-agent đúng nghĩa, nơi phần lớn nhầm lẫn sống. Có hai cách để một agent lôi agent khác vào, chúng không phải biến thể, và khác biệt nằm ở ai còn nắm quyền sau đó.

Agent như một công cụ. Agent cha gọi nó, nhận câu trả lời, rồi tiếp tục. Đó là giao diện công cụ của Chương 18 với cả một agent phía sau, và agent cha không bao giờ mất quyền kiểm soát. Đây là điều orchestrator ở trên làm.

Handoff. Agent cha chuyển cuộc hội thoại đi và không nhận lại. Hướng dẫn của OpenAI là phát biểu công khai rõ nhất: handoffs là "một chuyển giao một chiều cho phép một agent ủy quyền cho agent khác... Nếu một agent gọi một hàm handoff, chúng tôi lập tức bắt đầu thực thi trên agent mới được handoff tới, đồng thời cũng chuyển trạng thái hội thoại mới nhất."⁸

Một cảnh báo về từ vựng, vì điều này liên tục làm mọi người vấp: "handoff" là từ của một SDK, không phải một chuẩn. Đó là thuật ngữ từ OpenAI Agents SDK và hướng dẫn đó, nơi cũng đặt tên hai cách sắp xếp là "manager" và "decentralized" và ghi rằng trong manager pattern "các cạnh biểu thị tool calls, còn trong decentralized pattern, các cạnh biểu thị handoffs".⁸ Trong không gian này có một chuẩn mở — A2A, ở phiên bản 1.0.0, thuộc bản quyền của Linux Foundation, có lịch sử phát hành được version hóa và danh sách documented breaking changes, với nguyên tắc được nêu là opaque execution: agents "cộng tác dựa trên năng lực đã khai báo và thông tin trao đổi, mà không cần chia sẻ suy nghĩ nội bộ, kế hoạch hay implementation công cụ của chúng".⁹ Đó không phải một handoff, và phép so sánh thuộc về Chương 26. Điều quan trọng ở đây là một trong hai từ là API của một library, còn từ kia là một specification có governance.

Sự phân biệt là một cấu trúc dữ liệu, không phải sơ đồ:

export type EdgeKind = "tool" | "handoff";
export interface AgentEdge { from: string; to: string; kind: EdgeKind }
export interface AgentGraph { root: string; agents: Record<string, AgentSpec>; edges: AgentEdge[] }

/** One agent may not be both a tool of X and a handoff target of X. */
export function conflicts(g: AgentGraph): AgentEdge[] {
  const seen = new Map<string, EdgeKind>();
  const bad: AgentEdge[] = [];
  for (const e of g.edges) {
    const key = `${e.from}->${e.to}`;
    const other = seen.get(key);
    if (other && other !== e.kind) bad.push(e);                            
    else seen.set(key, e.kind);
  }
  return bad;
}

/** Every agent reachable from the root, and at what depth. */
export function reachable(g: AgentGraph): Map<string, number> {
  const depth = new Map([[g.root, 0]]);
  const queue = [g.root];
  while (queue.length) {
    const id = queue.shift()!;
    for (const e of g.edges.filter((x) => x.from === id)) {
      if (depth.has(e.to)) continue;
      depth.set(e.to, depth.get(id)! + 1);
      queue.push(e.to);
    }
  }
  return depth;
}

Hai mươi dòng, hai bug mà nếu không bạn sẽ tìm thấy trong production. reachable tìm agent mà không ai tới được — đã cấu hình, đã trả tiền, chưa bao giờ được gọi. conflicts từ chối cạnh vừa thuộc cả hai loại cùng lúc, nghe có vẻ soi mói cho đến khi bạn đọc thành tiếng: agent cha vừa giữ quyền kiểm soát vừa trao nó đi. Chạy nó trên một hệ năm agent có một orphan và một double edge:

reachable: lead@0 billing@1 tax@1 dunning@1
orphans:   ghost
conflicts: lead->tax

Giờ là phép đo mà mục này tồn tại vì nó, và là phép đo duy nhất trong chương chạy với model thật thay vì model kịch bản.

Một khách hàng nêu một ràng buộc trong tin nhắn đầu tiên — tài khoản của chúng tôi đăng ký ở Bồ Đào Nha, không phải Tây Ban Nha; mọi thứ liên quan đến thuế phải dùng Bồ Đào Nha — trò chuyện về chuyện khác, rồi hỏi một câu mà billing phải trả lời. Case được chuyển giao. Hai mươi bốn thử nghiệm, mỗi lần một quốc gia và công ty khác nhau, bốn payload chuyển giao, và agent nhận sau đó được hỏi một câu: tài khoản của khách hàng này đăng ký ở quốc gia nào?

Hàng thứ ba là một control và hành xử như control: dữ kiện không có ở đó, nên không thể nhớ lại. Ba hàng còn lại là phát hiện.

Transcript đầy đủ là 173 tokens và hoạt động 83 % số lần, bốn lần thất bại của nó là chủ đề của Chương 24 chứ không phải chương này. Typed record là 69 tokens — nhiều hơn summary bảy token — và lần nào cũng hoạt động, vì ràng buộc nằm trong một field có tên thay vì một câu.

Và summary là hàng cần nhìn chằm chằm. Nó thất bại 24 trên 24 lần, và lý do không phải người đọc bỏ sót. Ràng buộc chỉ xuất hiện trong 1 trong 24 summary. Agent nhận không bất cẩn; nó được đưa một văn bản không chứa câu trả lời. Summary là một phép nén mà bạn không viết, được tạo bởi một model có cửa sổ bạn không thấy, tối ưu để đọc như một summary — và "khách hàng nói hồ sơ của chúng ta đang ghi sai quốc gia" chính xác là kiểu mệnh đề mà summariser bỏ đi như nhiễu thủ tục.

Một giới hạn trung thực cho con số đó: summariser là model nửa tỷ parameter và model lớn hơn sẽ giữ lại nhiều hơn. Điều không cải thiện theo kích thước là hình dạng của rủi ro — agent gửi quyết định, theo từng handoff, theo từng cách diễn đạt, một cách không quan sát được, dữ kiện nào sống sót. Typed record hoàn toàn không phụ thuộc vào phán đoán đó, đó là lý do nó thắng theo cấu trúc chứ không phải theo trí thông minh. Bất cứ thứ gì phải sống sót qua một lần chuyển giao nên là field, không phải sentence.

Lập luận tương tự áp dụng theo chiều ngược lại, với topology agent-as-tool, và bảng trước đó đã định giá rồi: thứ trở về từ một worker cũng là một summary, và trả thêm 8.3 % để nhận bằng chứng kèm theo là cùng cách sửa nhìn từ phía agent cha.

Ba sự thật kết thúc, tất cả từ các bảng bên trên.

Một multi-agent system nhân số lượt gọi, và các lượt gọi có chi phí bậc hai theo context. Orchestrator thực hiện 12 lượt gọi model trong khi một agent thực hiện 5, và mỗi lượt mang transcript đang lớn dần của riêng nó — 3,628 input tokens so với 2,697, một khoảng cách sẽ rộng ra theo độ dài tác vụ.

Mọi ranh giới là một kênh mất mát. Hai agent nghĩa là một summary. Bốn agent trong một chain nghĩa là ba summary, chồng lên nhau, mỗi summary do một model viết và tối ưu cho thứ khác với quyết định của bạn.

Single agent tìm thấy thứ không ai yêu cầu. Lỗi không khớp purchase-order xuất hiện vì một cửa sổ cùng lúc chứa hóa đơn và đơn hàng. Chia công việc cho các specialist cũng chia luôn khả năng nhận ra hai dữ kiện mâu thuẫn.

Không điều nào trong đó phản bác các framework multi-agent đã công bố, vốn đáng đọc như nguồn gốc thay vì qua tutorial.¹⁰ Nó lập luận rằng agent thứ hai phải tự chứng minh vị trí của mình.

Vì vậy, một bài kiểm tra chứ không phải một sở thích. Thêm agent thứ hai khi ít nhất một điều sau đúng: sub-task cần một cửa sổ sạch mà agent cha không được kế thừa (Chương 24); các sub-task thật sự độc lập và wall clock quan trọng, tức mức 1.8× ở trên; sub-task cần quyền khác hoặc một model khác, điều mà Chương 30 biến thành một lập luận bảo mật; hoặc sub-task thuộc về người khác, nơi một protocol thật bắt đầu quan trọng. Nếu câu trả lời là "để mỗi agent có prompt rõ hơn", hãy cho một agent prompt rõ hơn. Nó miễn phí.

Giờ bạn có thể gọi tên năm pattern, định giá chúng với nhau trên một tác vụ, phân biệt orchestrator với sectioner và tool call với handoff, và bảo vệ single agent bằng một bảng thay vì sở thích.

Mọi cách sắp xếp ở đây cùng chia sẻ một tiện lợi sẽ không sống sót khi chạm vào bất cứ thứ gì thật: tất cả công cụ đều thuộc về chúng ta. Hóa đơn, đơn hàng, bảng thuế, các worker phía sau orchestrator — cùng repository, cùng deploy, cùng type, cùng con người.

Giờ đặt một trong số chúng ở phía bên kia ranh giới công ty. Bảng thuế thuộc về một vendor kế toán, hồ sơ đơn hàng thuộc về một hệ thống kho, và không bên nào đã đọc giao diện Tool của bạn. Bạn cần một cách để một model bạn không viết có thể discover, describe và call một capability do người khác vận hành — với authentication (là nửa của Chương 27), versioning, và bảo đảm rằng server không thể đọc phần còn lại của cuộc hội thoại của bạn. Đó là một vấn đề protocol, nó có một specification với normative schema, và gần như mọi thứ được index về nó mô tả một revision không còn tồn tại.

Chương 26 đọc specification đó thay vì tóm tắt nó, và bắt đầu bằng cách gõ JSON-RPC vào terminal bằng tay.

Mọi chi phí và số token ở trên đến từ provider được kịch bản hóa mô tả trong mục thứ hai, trên Node 22 qua loopback interface, đếm bằng encoding o200k_base và định giá theo mức Chương 16 đọc vào ngày 6 tháng 9 năm 2026 — $2.00 mỗi triệu input tokens và $12.00 mỗi triệu output. Các số wall-clock đến từ cùng lượt chạy với latency của provider đặt là 400 ms mỗi lượt gọi và công cụ là 50 ms, nên chúng đo cách sắp xếp chứ không đo provider nào. Hai phép đo với model thật — bảng handoff và bảng voting-and-judging — dùng Qwen/Qwen2.5-0.5B-Instruct ở float32 trên CPU sau một endpoint cùng hình dạng, greedy trừ nơi có nêu temperature, với các khoảng được tính bằng phương pháp Wilson từ Chương 4. Không request nào trong chương này đi tới endpoint trả phí, và không con số nào trong đó là ước tính.