CCAR-F: 120 câu ôn tập

Domain này hỏi gì

D1 là domain nặng nhất của CCAR-F: 27% đề, khoảng 16 trên 60 câu, trải trên 7 task statement. Nó xuất hiện trong ba scenario của bank — Customer Support Resolution Agent, Multi-Agent Research System và Developer Productivity with Claude — nên bạn gần như chắc chắn gặp nó ở ít nhất hai trong bốn scenario được rút ra cho lượt thi của mình.

Điều examiner thực sự đo không phải là bạn có thuộc lòng signature của Agent SDK hay không. Đề mô tả một hệ thống agentic đang hỏng theo một cách rất cụ thể, rồi hỏi sửa ở tầng nào. Hình dạng đáp án đúng lặp đi lặp lại: khắc phục đúng nguyên nhân gốc, ở đúng tầng kiến trúc, với chi phí tương xứng. Nếu triệu chứng là một guarantee bị vi phạm, đáp án là cơ chế deterministic — hook, prerequisite gate, configuration — chứ không phải một system prompt mạnh hơn. Nếu triệu chứng là một configuration flag bị thiếu, đáp án là sửa flag đó, không phải viết lại prompt cho rõ hơn.

1.1 Thiết kế và triển khai agentic loop

Vòng đời một lượt agentic gồm bốn bước lặp lại: gửi request → kiểm tra stop_reason của response → thực thi tool nếu được yêu cầu → append tool result vào message history → gọi lại API với history đã cập nhật. Điểm mấu chốt về mặt kiến trúc: API không thực thi tool của bạn. Claude chỉ phát ra một block tool_use mô tả tool nào và tham số gì; harness — tức code của bạn — chạy tool đó rồi append một block tool_result có tham chiếu đúng ID của lời gọi tương ứng.

stop_reason	Ý nghĩa	Harness phải làm gì
tool_use	Model yêu cầu chạy một hoặc nhiều tool	Thực thi, append tool_result, gọi lại — tiếp tục vòng lặp
end_turn	Model đã hoàn tất lượt của mình	Thoát vòng lặp, trình bày kết quả cho người dùng

Một response có thể chứa đồng thời content text và block tool_use. Claude thường viết một câu giải thích trước khi gọi tool. Vì vậy sự hiện diện của text không là tín hiệu hoàn thành.

Anti-pattern được nêu đích danh trong exam guide:

• Parse natural-language text để tìm tín hiệu hoàn thành — dò chuỗi kiểu "I have finished". Đây là parsing prose ở nơi đã có một enum máy đọc được.
• Lấy iteration cap làm cơ chế dừng chính. Giới hạn số vòng là một safety net chống loop vô hạn, không phải logic điều khiển. Hệ thống dùng nó làm cơ chế dừng sẽ cắt ngang công việc chưa xong.
• Coi việc có text content là đã xong — biến thể phổ biến nhất, vì nó chạy đúng trong hầu hết trường hợp rồi hỏng đúng lúc Claude vừa giải thích vừa gọi tool.

Đề cũng phân biệt model-driven decisions (Claude tự chọn tool nào, theo thứ tự nào, dừng khi nào) với pre-configured decision tree (bạn hard-code luồng). Agentic loop thuộc loại thứ nhất; chọn loại thứ hai khi luồng thực sự cố định và bạn cần tính lặp lại tuyệt đối.

1.2 Điều phối hệ multi-agent (coordinator–subagent)

Kiến trúc chuẩn là hub-and-spoke: một coordinator ở giữa, các subagent chuyên môn hóa ở ngoài. Coordinator sở hữu toàn bộ giao tiếp giữa các subagent và toàn bộ xử lý lỗi. Lý do không phải thẩm mỹ mà là observability — khi mọi thông điệp đi qua hub, bạn có một chỗ duy nhất để log, đo và can thiệp. Cho subagent nói chuyện trực tiếp với nhau là đánh mất điều đó.

Sự thật quan trọng nhất của task statement này: subagent có context bị cô lập hoàn toàn. Không có kế thừa tự động lịch sử hội thoại của coordinator, không có shared memory giữa các lần invoke. Subagent chỉ biết đúng những gì bạn viết vào prompt của nó. Mọi kết luận từ subagent trước, nếu subagent sau cần, phải được coordinator truyền lại tường minh.

Ba hành vi coordinator mà đề hay kiểm tra:

• Chọn subagent động thay vì luôn chạy đủ pipeline. Một câu hỏi chỉ cần web search thì không nên kéo theo document analysis; coordinator quyết định dựa trên bản chất request.
• Phân vùng scope để tránh trùng lặp. Hai subagent research được giao hai lát cắt tách bạch, không phải cùng một câu hỏi diễn đạt khác đi.
• Iterative refinement: coordinator đánh giá output của synthesis, phát hiện coverage gap, re-delegate các truy vấn nhắm đúng chỗ thiếu, rồi gọi lại synthesis — lặp cho tới khi đạt tiêu chí. Đây là vòng lặp ở tầng orchestration, song song với vòng lặp stop_reason ở tầng dưới.

1.3 Cấu hình invocation, truyền context và spawning cho subagent

Tool Task chính là cơ chế spawn subagent. Hệ quả trực tiếp: nếu allowedTools của coordinator không liệt kê "Task", sẽ không có delegation nào xảy ra, bất kể prompt mô tả kiến trúc multi-agent rõ ràng đến đâu. Triệu chứng trong đề rất đặc trưng: coordinator tự làm hết mọi việc một mình, log không hề có lời gọi Task nào, chất lượng đi xuống vì một agent phải ôm mọi vai trò.

AgentDefinition mang ba thứ cho mỗi subagent: description (dùng để chọn đúng subagent), system prompt và tool restrictions. Tool restriction là configuration được enforce lúc runtime, không phải lời khuyên: một subagent bị giới hạn ở Read và Grep thì không thể gọi Write, kể cả khi nó "muốn".

Parallel spawning = phát ra nhiều lời gọi Task trong cùng một response của coordinator. Nếu coordinator gọi Task ở lượt này rồi gọi tiếp ở lượt sau, đó là tuần tự — dù bạn có viết "chạy song song" trong prompt. Đây là chi tiết đề dùng để phân biệt người đã dựng hệ thật với người chỉ đọc tài liệu.

Fork-based session dùng khi bạn muốn thử nhiều hướng tiếp cận khác nhau trên cùng một baseline đã phân tích: fork ra các nhánh độc lập, mỗi nhánh đi một chiến lược, không nhánh nào nhiễm context của nhánh kia, và bạn không phải trả lại chi phí phân tích baseline.

1.4 Workflow nhiều bước: enforcement và handoff

Task statement này đối lập hai họ giải pháp: programmatic enforcement (hook, prerequisite gate) và prompt-based guidance. Prerequisite gate chặn tool phía sau cho tới khi tool phía trước hoàn tất — ví dụ kinh điển của exam guide: chặn process_refund cho tới khi get_customer đã trả về một ID đã xác minh.

Đây chính là nội dung sample question số 1. Tình huống: agent thỉnh thoảng hoàn tiền trước khi xác minh danh tính khách hàng. Vì hậu quả mang tính tài chính, yêu cầu ở đây là một guarantee, và guarantee không thể dựng bằng prompt. Đáp án đúng là prerequisite gate mang tính deterministic. Ba distractor kèm theo đáng học thuộc: một system prompt mạnh hơn (probabilistic), few-shot examples về quy trình đúng (cũng probabilistic), và — tinh vi nhất — gỡ bỏ hẳn process_refund khỏi tool set. Cái cuối cùng sai vì nó thay đổi tool availability trong khi khiếm khuyết nằm ở tool ordering: agent vẫn cần refund được, chỉ là phải đúng thứ tự.

Phần thứ hai của task statement là decomposition một request nhiều mối quan tâm: tách thành các item riêng biệt, điều tra song song trên cùng shared context, rồi tổng hợp thành một câu trả lời thống nhất — không phải ba câu trả lời rời rạc dán lại.

Phần thứ ba là structured handoff summary khi escalate sang người. Nội dung bắt buộc: customer ID, phân tích root-cause đã thực hiện tới thời điểm đó, các con số và order number liên quan, và hành động được khuyến nghị. Escalation mà chỉ chuyển nguyên transcript sang cho người là một anti-pattern — nó đẩy toàn bộ chi phí đọc lại sang phía con người.

1.5 Hooks của Agent SDK để intercept và normalize

Hook PostToolUse chạy sau khi tool trả kết quả và trước khi model nhìn thấy kết quả đó. Hai công dụng đề hay hỏi:

• Normalization: chuẩn hóa các định dạng không đồng nhất từ nhiều backend — Unix timestamp so với ISO 8601, mã trạng thái số so với chuỗi. Model nhận vào một hình dạng dữ liệu duy nhất thay vì phải tự suy luận từng biến thể.
• Interception để cưỡng chế tuân thủ: chặn mọi process_refund vượt ngưỡng và chuyển hướng sang escalate_to_human.

Câu này là chìa khóa để loại đáp án nhanh. Hễ stem chứa các từ như "must never", "always", "under no circumstances", "compliance", "audit", hoặc mô tả hậu quả tài chính hay pháp lý, thì đáp án đúng nằm ở tầng cơ chế: hook, gate, hoặc tool restriction. Prompt và few-shot chỉ dùng để cải thiện chất lượng phán đoán, không dùng để bảo đảm bất biến.

1.6 Chiến lược task decomposition

Hai mô hình, chọn theo uncertainty profile của workflow:

Mô hình	Bản chất	Dùng khi
Prompt chaining (pipeline tuần tự cố định)	Các bước biết trước, cùng thứ tự mỗi lần	Code review luôn kiểm tra đúng năm hạng mục; phân tích từng file rồi tới pass cross-file
Dynamic adaptive decomposition	Subtask được sinh ra từ finding trung gian	Điều tra mở, bước kế tiếp phụ thuộc vào phát hiện của bước trước

Sai lầm hai chiều đều bị đề trừng phạt: dùng adaptive planning cho một quy trình đã cố định là bỏ mất tính lặp lại và thêm biến thiên vô ích; dùng pipeline cứng cho một cuộc điều tra mở là buộc hệ thống chạy tiếp một kế hoạch đã bị dữ liệu bác bỏ ngay từ bước hai.

1.7 Session state, resumption và forking

--resume <session-name> khôi phục context của một named session. fork_session tạo các nhánh độc lập từ một baseline chung. Khác biệt: resume là tiếp tục một dòng, fork là tách nhiều dòng từ cùng một điểm.

Điểm đề thích hỏi nhất ở đây là đánh đổi khi resume:

Tình huống	Lựa chọn đúng
Context trước phần lớn vẫn đúng, file thay đổi ít	--resume, kèm thông báo cho agent biết file nào đã đổi
Tool result cũ đã stale (file bị merge nhiều lần)	Bắt đầu session mới, inject một structured summary: giữ kết luận, bỏ bằng chứng đã cũ
Hai chiến lược cần thử trên cùng một baseline	fork_session

Lý do phải chủ động: Claude không tự động verify lại các tool result đã cũ. Một session resume mang theo nội dung file của tuần trước sẽ suy luận trên nội dung đó như thể nó vẫn đúng hôm nay. Nghĩa vụ báo "những file này đã thay đổi" thuộc về kiến trúc sư, không thuộc về model.

Domain này hỏi gì

D2 chiếm 18% đề, khoảng 11 trên 60 câu, gồm 5 task statement. Nó gắn với các scenario Customer Support Resolution Agent, Multi-Agent Research System và Developer Productivity — tức là thường đi kèm D1 trong cùng một scenario, và đề hay đặt một câu D1 (kiến trúc) cạnh một câu D2 (giao diện tool) trên cùng một bối cảnh.

Toàn bộ domain xoay quanh một luận điểm duy nhất: tool là giao diện mà model dùng để nhìn thế giới, nên chất lượng của giao diện đó quyết định chất lượng hành vi agent. Khi agent chọn nhầm tool, mặc định là lỗi thiết kế giao diện, không phải lỗi model. Hình dạng đáp án đúng: sửa đúng chỗ hỏng, ở mức chi phí nhỏ nhất có tác dụng. Đề đặc biệt thích đối lập một bản sửa rẻ và trúng đích với một bản kiến trúc lớn nghe có vẻ nghiêm túc hơn nhưng lại vòng qua nguyên nhân gốc.

2.1 Thiết kế tool interface

Một description đủ dùng phải chứa: input format, ví dụ truy vấn, edge case, và — quan trọng nhất — ngôn ngữ ranh giới tường minh so với các tool tương tự. Kiểu câu mà exam guide dùng làm mẫu: "dùng X khi request có order number; dùng Y để xác minh danh tính trước mọi thao tác trên tài khoản". Ranh giới phải nằm trong chính description, vì đó là thứ model đọc lúc quyết định.

Hai kỹ thuật khắc phục được nêu đích danh:

• Xóa bỏ chồng lấn chức năng bằng cách đổi tên kèm viết lại description. Ví dụ của guide: analyze_content đổi thành extract_web_results. Đổi tên một mình chưa đủ; description phải nói rõ tool này làm gì và không làm gì.
• Tách một tool có mode parameter chung chung thành nhiều tool chuyên biệt, mỗi tool có contract input/output riêng. Tác dụng thật sự: nó biến một quyết định mode bị giấu bên trong tham số thành một quyết định lựa chọn hiện rõ — thứ mà tool-selection machinery của model vốn giỏi hơn nhiều.

Đây chính là nội dung sample question 2. Agent chọn nhầm giữa hai tool có phạm vi chồng lấn. Đáp án đúng: viết lại description của đúng hai tool đó để phân định ranh giới. Các distractor: dựng một lớp keyword pre-routing trước khi gọi model, hoặc gộp hai tool thành một tool có mode parameter. Cả hai đều là over-engineering vượt qua bản sửa rẻ nhất — và lớp pre-routing còn tệ hơn ở chỗ nó thay thế phán đoán ngữ nghĩa của model bằng so khớp từ khóa cứng.

2.2 Structured error response cho MCP tool

Cờ isError của MCP làm cho một thất bại trở nên máy nhận biết được, thay vì là văn xuôi đội lốt kết quả thành công. Đây là phân biệt trung tâm của task statement này: một tool trả về chuỗi "Sorry, the order service is currently unavailable" mà không đặt isError thì với agent, nó là dữ liệu. Agent sẽ tường thuật lại cho khách hàng như một sự thật về đơn hàng, hoặc coi như đã tra cứu xong và đi tiếp.

Bốn loại lỗi cần phân biệt:

Loại	Ví dụ	Hành vi đúng của agent
Transient	Timeout, service unavailable	Retry — isRetryable true; subagent tự khôi phục tại chỗ
Validation	Sai định dạng input	Sửa tham số rồi gọi lại; retry nguyên si là vô nghĩa
Business	Vi phạm policy, ví dụ quá thời hạn hoàn tiền	retriable: false + giải thích thân thiện để agent trình bày lý do từ chối
Permission	Không đủ quyền	Không retry; escalate hoặc đổi đường đi

Payload lỗi chuẩn gồm ba phần: errorCategory, một boolean isRetryable, và một mô tả người-đọc-được đủ để agent hành động. Trong hệ multi-agent, quy tắc bổ sung: subagent tự xử lý các lỗi transient tại chỗ và chỉ propagate lên coordinator những gì nó không giải quyết được.

2.3 Phân phối tool và cấu hình tool choice

Kho tool lớn làm giảm độ tin cậy của việc chọn tool. Exam guide đối lập trực tiếp một agent cầm 18 tool với một agent cầm 4–5 tool. Và agent được trao tool nằm ngoài chuyên môn của nó sẽ dùng sai chúng. Nguyên tắc thiết kế: scope bộ tool theo vai trò của từng agent, cộng thêm vài tool dùng chung cho nhu cầu tần suất cao. Đây là phiên bản D2 của nguyên tắc cô lập ở D1 — mỗi agent chỉ nhìn thấy đúng phần thế giới thuộc về nó.

Ba giá trị của tool_choice:

Giá trị	Ngữ nghĩa	Chọn khi
"auto"	Model tự quyết có gọi tool hay không	Hội thoại bình thường, trả lời bằng text là chấp nhận được
"any"	Bắt buộc gọi một tool, model chọn tool nào	Có nhiều extraction schema và text hội thoại không bao giờ chấp nhận được
Forced {"type":"tool","name":"..."}	Ép đúng một tool đã nêu tên	Cần bảo đảm một bước cụ thể chạy — ví dụ extraction phải chạy trước enrichment

Cách phân biệt cho nhanh: "auto" để ngỏ khả năng có text thay vì tool call; "any" đóng khả năng đó nhưng vẫn để model chọn schema; forced đóng cả hai.

2.4 Tích hợp MCP server

Scoping là điểm hỏi nhiều nhất:

• .mcp.json ở mức project — dành cho tooling dùng chung của cả team, được version-control, ai clone repo cũng có.
• ~/.claude.json ở mức user — dành cho server cá nhân hoặc thử nghiệm, không đi theo repo.

Đặt server dùng chung của team ở mức user là lỗi kinh điển: cấu hình không đi theo version control nên đồng nghiệp clone repo về sẽ thiếu tool và không hiểu tại sao hành vi khác nhau. Chiều ngược lại — nhét server thử nghiệm cá nhân vào .mcp.json — thì áp đặt lên cả team.

Mở rộng biến môi trường trong .mcp.json, ví dụ ${GITHUB_TOKEN}, cho phép commit file cấu hình mà không commit bất kỳ secret nào. Nếu một đáp án đề nghị viết thẳng token vào file rồi thêm nó vào .gitignore, đó là distractor: nó đánh mất chính lợi ích chia sẻ mà cấu hình project-level tồn tại để cung cấp.

Ba điểm còn lại của task statement:

• Tool của mọi server đã cấu hình đều được discover lúc kết nối và khả dụng đồng thời — không có bước "bật" thủ công từng server giữa phiên.
• MCP resources phơi bày các catalog: cây tài liệu, danh sách tóm tắt issue, listing schema của database. Chúng cho agent tầm nhìn về dữ liệu nào đang tồn tại mà không phải đốt một loạt tool call thăm dò. Khi stem than phiền agent "mò mẫm nhiều lượt mới tìm ra tài liệu cần", resources là câu trả lời.
• Ưu tiên MCP server cộng đồng đã có sẵn cho các tích hợp tiêu chuẩn thay vì tự xây. Và nhớ làm giàu description của MCP tool, nếu không agent sẽ mặc định quay về built-in tool quen thuộc.

2.5 Chọn built-in tool

Đây là task statement kiểm tra kiến thức thực hành, và nó rất dễ ăn điểm nếu bạn thuộc ranh giới:

Tool	Dùng cho	Ví dụ
Grep	Tìm theo nội dung file	Tên hàm, chuỗi thông báo lỗi, câu lệnh import
Glob	Khớp đường dẫn / tên file	Mẫu như **/*.test.tsx
Read / Write	Đọc và ghi toàn bộ file	Xem trọn file; ghi đè nội dung hoàn chỉnh
Edit	Sửa có nhắm đích qua một đoạn khớp duy nhất	Đổi một dòng có anchor không trùng lặp
Bash	Chạy lệnh	Build, test, thao tác git

Khi Edit thất bại vì đoạn anchor không duy nhất, fallback được tài liệu hóa là: Read toàn bộ file rồi Write lại nội dung đã sửa hoàn chỉnh. Không phải chuyển sang sed qua Bash, không phải retry Edit nhiều lần với hy vọng khác đi, và tuyệt đối không phải sửa méo file để tạo ra một khớp duy nhất giả tạo.

Phần thứ hai là chiến lược khám phá codebase. Xây hiểu biết theo lối incremental: Grep tìm entry point trước, rồi Read có chọn lọc để lần theo luồng thực thi. Anti-pattern được nêu tên: đọc file theo thứ tự bảng chữ cái cho tới khi cạn context — nó lấp đầy context bằng phần lớn nội dung không liên quan rồi hết chỗ đúng lúc cần chỗ nhất.

Một mẫu cụ thể nữa: truy vết cách dùng xuyên qua các wrapper module bằng cách xác định các tên được export ra, rồi Grep từng tên đó. Grep thẳng tên module gốc sẽ bỏ sót mọi call site đi qua wrapper.

Domain này hỏi gì

D3 chiếm 20% đề, khoảng 12 trên 60 câu, trải trên 6 task statement. Nó là domain chủ đạo của scenario Code Generation with Claude Code và Claude Code for Continuous Integration, đồng thời góp mặt trong Developer Productivity with Claude — ba trong sáu scenario của bank.

Khác với D1 (kiến trúc) và D4 (chất lượng phán đoán), D3 kiểm tra kiến thức về hệ thống file và flag có thật. Rất nhiều câu ở đây được quyết định chỉ bằng việc bạn có biết đúng tên đường dẫn, đúng tên khóa frontmatter, đúng tên flag CLI hay không. Distractor family phổ biến nhất của D3 chính là một cơ chế không tồn tại — được viết nghe rất hợp lý. Sample 4 đưa ra một mảng commands trong .claude/config.json; sample 10 đưa ra biến môi trường CLAUDE_HEADLESS=true và flag --batch. Không cái nào có thật. Nếu bạn không nhớ chính xác bộ mặt thật của cấu hình Claude Code, những phương án đó đọc lên hoàn toàn thuyết phục.

Trục thứ hai của domain là ranh giới enforcement so với guidance, giống D1 nhưng đặt trong Claude Code: allowed-tools trong frontmatter là ràng buộc thật; cùng nội dung ấy viết trong phần body của skill chỉ là lời khuyên có xác suất thất bại khác không.

3.1 Phân cấp CLAUDE.md, scoping và modularity

Ba tầng memory, đọc theo thứ tự bao trùm dần:

Tầng	Đường dẫn	Đi theo git?	Dùng cho
User	~/.claude/CLAUDE.md	Không bao giờ	Sở thích cá nhân của một lập trình viên, trên mọi project
Project	.claude/CLAUDE.md hoặc CLAUDE.md ở root	Có	Chuẩn chung của team, áp dụng cho toàn repo
Directory	CLAUDE.md trong thư mục con	Có	Quy ước bó hẹp trong đúng một cây thư mục

Đây là chỗ sinh ra bug kinh điển nhất của D3: một tech lead viết coding standards của team vào ~/.claude/CLAUDE.md của chính mình, thấy Claude tuân thủ hoàn hảo, rồi ngạc nhiên khi đồng đội báo Claude "phớt lờ chuẩn của team". File user-level nằm ngoài repo — nó không bao giờ được clone. Cách sửa duy nhất đúng là chuyển nội dung sang project-level và commit nó. Mọi phương án kiểu "viết lại chuẩn cho rõ hơn", "nhắc lại chuẩn trong từng prompt" hay "thêm hook kiểm tra" đều là sửa sai tầng.

Về tổ chức nội dung: cú pháp @import cho phép tách CLAUDE.md thành nhiều file thay vì để nó phình thành một khối đơn. Đi xa hơn nữa là .claude/rules/ — thư mục chứa các file theo chủ đề (testing.md, api-conventions.md, deployment.md), là lựa chọn modular thay cho một CLAUDE.md khổng lồ.

Công cụ chẩn đoán bắt buộc phải nhớ tên: /memory cho biết session hiện tại thực sự đã nạp những memory file nào. Khi triệu chứng là "Claude hành xử không nhất quán giữa các máy hoặc giữa các session", bước đầu tiên là chạy /memory để xem file nào có mặt, file nào không — chứ không phải viết lại nội dung.

3.2 Custom slash command và Skills

Slash command tùy chỉnh có hai phạm vi, và sự khác biệt hoàn toàn nằm ở version control:

• .claude/commands/ — project-scoped. Nằm trong repo, được commit, mọi người clone repo đều có ngay. Đây là đáp án khi stem nói "cả team phải dùng chung quy trình này".
• ~/.claude/commands/ — user-scoped. Cá nhân, nằm ngoài repo, theo lập trình viên đó qua mọi project. Đáp án khi stem nói "tôi muốn shortcut riêng, không áp đặt cho team".

Skills sống trong .claude/skills/, mỗi skill có một SKILL.md với frontmatter. Ba khóa mà đề hỏi trực tiếp:

Frontmatter	Làm gì	Chọn khi
context: fork	Chạy skill trong context subagent cô lập; chỉ kết quả đã chắt lọc quay về hội thoại chính	Skill sinh ra output khám phá dài dòng (quét toàn repo, đọc hàng chục file) làm ngập context chính
allowed-tools	Giới hạn tập tool skill được phép gọi khi chạy — cơ chế enforcement	Skill chỉ được đọc, tuyệt đối không được ghi/xóa/chạy lệnh
argument-hint	Nhắc người gọi nhập tham số bắt buộc khi skill được gọi trống	Skill vô nghĩa nếu thiếu tham số (tên file, số PR, tên môi trường)

Điểm phải khắc sâu: allowed-tools là ràng buộc, một câu trong body của SKILL.md thì không. Viết "đừng sửa file nào" trong phần hướng dẫn là guidance mang tính xác suất; liệt kê allowed-tools chỉ gồm các tool đọc là cấu hình được enforce. Khi stem nói "phải bảo đảm", chọn frontmatter.

Ranh giới CLAUDE.md so với Skills, gần như chắc chắn xuất hiện trong đề:

Chuẩn đặt tên, quy tắc lint, kiến trúc thư mục — luôn đúng, luôn nạp, thuộc CLAUDE.md. Quy trình phát hành, quy trình migrate schema, quy trình dựng một endpoint mới — chỉ dùng khi cần, thuộc Skills. Nhồi một procedure dài vào CLAUDE.md khiến nó chiếm chỗ trong mọi session dù chẳng session nào cần.

3.3 Rule theo path

File trong .claude/rules/ mang YAML frontmatter với glob paths: để kích hoạt có điều kiện: rule chỉ được nạp khi Claude đang làm việc với file khớp glob. Hai lợi ích cộng hưởng — ít context không liên quan hơn, và ít token hơn cho mọi session không chạm tới loại file đó.

Sự thật quyết định của task statement này: glob áp quy ước theo loại file bất kể thư mục. Một pattern như **/*.test.tsx bắt được mọi file test co-located rải rác khắp cây source. Một CLAUDE.md đặt trong thư mục con thì bị trói vào đúng thư mục đó và không thể làm điều tương tự.

Do đó phép chọn rất gọn: quy ước bó trong một cây thư mục ⇒ CLAUDE.md của thư mục đó cũng được; quy ước bám theo loại file nằm rải rác ⇒ bắt buộc là rule có paths:.

3.4 Plan mode so với thực thi trực tiếp

Plan mode cho phép khám phá và thiết kế trước khi có thay đổi nào được thực hiện. Chọn nó khi có ít nhất một trong các dấu hiệu: thay đổi quy mô lớn, tồn tại nhiều hướng tiếp cận đều hợp lệ, quyết định mang tính kiến trúc, hoặc phải sửa nhiều file cùng lúc. Thực thi trực tiếp dành cho thay đổi nhỏ, phạm vi rõ, cách sửa đã hiển nhiên.

Sai lầm đề trừng phạt ở cả hai chiều: bắt plan mode cho một lỗi typo là nghi thức thừa; thực thi trực tiếp một cuộc refactor chạm mười file là cam kết vào hướng đi đầu tiên nghĩ ra, trước khi kịp so sánh.

Đi cùng plan mode là Explore subagent: nó cô lập phần discovery dài dòng và chỉ trả về bản tóm tắt. Cùng một logic với context: fork ở 3.2 — giữ cho context chính sạch để dành cho việc ra quyết định.

3.5 Tinh chỉnh lặp

Khi output của Claude "gần đúng nhưng không nhất quán", exam guide xếp hạng các kỹ thuật khá rõ:

• Ví dụ input/output cụ thể (2–3 cặp) là cách hiệu quả nhất để truyền đạt một phép biến đổi mong muốn khi prose đang bị diễn giải mỗi lúc một khác. Diễn đạt lại yêu cầu bằng văn xuôi lần thứ tư gần như luôn là distractor.
• Iteration theo hướng test-driven: viết bộ test trước — hành vi mong đợi, edge case, ràng buộc hiệu năng — rồi đưa các test đang fail cho Claude. Test biến "chưa đúng" thành một tín hiệu máy kiểm chứng được.
• Interview pattern: yêu cầu Claude đặt câu hỏi cho bạn trước khi bắt tay, để lộ ra những cân nhắc bạn chưa nghĩ tới. Đây là kỹ thuật cho giai đoạn đầu, khi chính yêu cầu còn chưa đủ rõ.
• Gộp toàn bộ vấn đề vào một message khi trao đổi, nhưng sửa tuần tự khi các vấn đề độc lập với nhau.

3.6 Tích hợp CI/CD

Bộ ba flag phải thuộc lòng, vì đây là kiến thức được hỏi trực tiếp:

Flag	Vai trò	Bỏ đi thì sao
-p / --print	Chạy non-interactive	Lệnh treo chờ input tương tác; job CI timeout
--output-format json	Output máy đọc được	Pipeline phải regex-parse prose
--json-schema	Ràng buộc hình dạng của JSON đó	JSON hợp lệ nhưng field thay đổi giữa các lần chạy

CLAUDE.md tiếp tục làm việc của nó trong CI: nó cấp project context cho các lần gọi headless — chuẩn testing, quy ước fixture, thế nào là một test có giá trị, tiêu chí review. Không có nó, Claude review một diff mà không biết gì về repo chứa diff đó.

Sự thật có sức nặng nhất của D3 nằm ở đây: session context isolation.

Vì vậy review trong CI phải chạy trong một instance độc lập, không mang theo context sinh code. Đây cũng chính là 4.6 nhìn từ phía hạ tầng — cùng một nguyên lý, một bên là thiết kế review, một bên là cấu hình pipeline.

Hai chi tiết vận hành hay bị bỏ sót:

• Chạy lại sau commit mới: đưa vào findings của lần review trước và yêu cầu Claude chỉ báo cáo vấn đề mới cộng với vấn đề cũ chưa được xử lý. Không làm vậy thì mỗi lần push lại đổ nguyên danh sách cũ lên PR và người ta ngừng đọc.
• Sinh test: cung cấp các file test hiện có, để Claude không sinh trùng kịch bản đã được phủ.

Domain này hỏi gì

D4 chiếm 20% đề, khoảng 12 trên 60 câu, 6 task statement. Nó thống trị scenario Structured Data Extraction và chia sẻ scenario Claude Code for Continuous Integration với D3.

Chủ đề xuyên suốt của domain là thay yêu cầu bằng cơ chế. Ở mỗi task statement đều có một cặp: một cách "nhờ Claude làm cho đúng" và một cách khiến việc làm sai trở nên khó hoặc bất khả. Nhờ Claude trả về JSON so với định nghĩa một tool có input schema. Nhờ Claude "cẩn thận" so với viết ra tiêu chí phân loại cụ thể. Bảo Claude tự kiểm tra so với trích cả calculated_total lẫn stated_total rồi so sánh bằng code. Đáp án đúng gần như luôn là vế thứ hai.

Nhưng D4 cũng kiểm tra giới hạn của cơ chế — và đây là nơi thí sinh khá thường mất điểm. Schema chặt không sửa được lỗi ngữ nghĩa. Retry không tạo ra thông tin vốn không có trong tài liệu. Nhiều pass review không được gộp bằng biểu quyết đa số. Biết một kỹ thuật không giải quyết được gì cũng được chấm điểm ngang với biết nó giải quyết được gì.

4.1 Dùng tiêu chí tường minh để tăng precision

Bài toán điển hình: một CI review tạo quá nhiều false positive ở một hạng mục. Cách sửa đúng là tiêu chí phân loại tường minh. So sánh trực tiếp từ exam guide: "check that comments are accurate" là vô dụng; "flag comments only when the claimed behaviour contradicts the actual code" thì dùng được — nó nêu điều kiện kiểm chứng được.

Chúng không có nội dung vận hành: model vẫn phải tự quyết định thế nào là "high confidence", tức đúng cái quyết định đang sai. Tiêu chí tốt nói rõ loại vấn đề nào báo cáo (bug, lỗ hổng bảo mật) và loại nào bỏ qua (style vặt, pattern nội bộ của repo), kèm ranh giới cụ thể.

Hai chi tiết đắt giá khác của task statement này:

• Một hạng mục nhiều false positive có tính lây lan. Nó dạy reviewer thói quen bỏ qua, và thói quen đó lan sang cả những hạng mục đang chính xác. Vì thế biện pháp được exam guide tán thành là tạm tắt hẳn hạng mục đó để bảo vệ lòng tin, trong khi prompt của nó được sửa offline — chứ không phải để nó chạy tiếp kèm lời nhắn "hãy nghiêm khắc hơn".
• Định nghĩa severity kèm ví dụ code cụ thể cho từng mức. Chỉ khi đó severity gate ("chặn merge nếu có high") mới đáng tin, vì "high" mới có nghĩa ổn định giữa các lần chạy.

4.2 Few-shot prompting

Exam guide gọi few-shot là kỹ thuật hiệu quả nhất để có output định dạng nhất quán và actionable. Nhưng phần được chấm điểm nằm ở cách chọn ví dụ:

• 2–4 ví dụ nhắm vào các tình huống thực sự mơ hồ, mỗi ví dụ trình bày lý do dẫn tới hành động được chọn. Chất lượng nhắm trúng thắng số lượng — một bộ hai mươi ví dụ tầm thường kém hơn ba ví dụ đúng chỗ đau, và còn ngốn context.
• Few-shot dạy model khái quát phán đoán sang ca mới, không chỉ khớp lại đúng những ca đã liệt kê. Đây là lý do ví dụ phải phủ ranh giới quyết định chứ không phải các ca dễ.
• Bao gồm ví dụ thể hiện đúng định dạng output, và các cặp đối chiếu phân biệt pattern idiomatic được chấp nhận với vấn đề thật sự.
• Few-shot bổ sung cho tiêu chí tường minh của 4.1, không thay thế chúng.

Ứng dụng đề hay dùng: xử lý ca mơ hồ khi chọn tool, đánh giá coverage gap ở mức nhánh, và giảm hallucination trong extraction.

4.3 Structured output bằng tool use và JSON schema

Cơ chế đúng, phát biểu đầy đủ: định nghĩa việc trích xuất như một tool mà input schema chính là JSON schema của bạn, rồi đọc dữ liệu có cấu trúc từ block tool_use. Nó loại bỏ lỗi cú pháp JSON ngay từ cấu trúc, khác hẳn việc xin JSON trong prose rồi phải gỡ markdown fence, cắt lời dẫn thừa và vá dấu phẩy cuối.

tool_choice — ba giá trị, ba tình huống:

tool_choice	Hành vi	Dùng khi
"auto"	Model tự quyết có gọi tool hay không	Gọi tool là tùy chọn — và chấp nhận được nếu nó trả về text hội thoại
"any"	Bắt buộc gọi một tool, nhưng model chọn tool nào	Có nhiều schema extraction và text hội thoại không bao giờ chấp nhận được
{"type":"tool","name":"..."}	Ép đúng một tool đã nêu tên	Phải bảo đảm một phép trích cụ thể chạy — ví dụ trước bước enrichment

Ranh giới quan trọng nhất của task statement:

Một payload hoàn toàn hợp lệ với schema vẫn có thể có các line item không cộng ra stated_total, hoặc ngày phát hành nằm nhầm vào field ngày đến hạn. Schema kiểm tra hình dạng, không kiểm tra sự thật. Đó là lý do 4.4 tồn tại.

Thiết kế schema — bốn quyết định được hỏi:

• required so với optional. Đặt optional/nullable cho field mà tài liệu nguồn có thể thực sự không chứa. Một field required trên thông tin vắng mặt ép model bịa, vì schema không chừa chỗ nào cho câu trả lời trung thực.
• enum cộng "other" cộng một chuỗi detail cho các danh mục còn mở rộng — giữ được tính máy đọc mà không mất thông tin ở đuôi phân phối.
• Thêm một thành viên enum "unclear" cho ca mơ hồ, để "không đọc được" là một giá trị hợp lệ chứ không phải một phỏng đoán.
• Field phái sinh phục vụ validation (xem 4.4) được khai báo ngay trong schema, không tính sau.

4.4 Validation, retry và vòng phản hồi

Retry-with-error-feedback có ba thành phần bắt buộc trong lần gọi lại: tài liệu gốc, kết quả extraction đã fail, và các lỗi validation cụ thể. Model chỉ có thể tự sửa dựa trên những gì nó được cho thấy; một lần retry chỉ nói "lần trước sai, làm lại" là một lần rút thăm mới, không phải một vòng sửa lỗi.

Và ranh giới phải nhớ: retry vô ích khi thông tin đơn giản là không có trong nguồn. Không vòng lặp nào tạo ra được một số PO không được in trên hóa đơn. Đúng cách xử lý là ở tầng schema (nullable, xem 4.3) cộng với định tuyến sang human review (xem 5.5).

Phân biệt hai loại lỗi, vì cách xử lý khác nhau:

Loại lỗi	Ví dụ	Cơ chế bắt
Schema / cú pháp	Thiếu field, sai kiểu, JSON hỏng	Loại bỏ từ gốc bằng tool_use + schema
Ngữ nghĩa	Line item không cộng ra tổng; giá trị nằm nhầm field	Validation ở tầng ứng dụng, rồi retry có feedback

Pattern tự kiểm tra mà exam guide nêu đích danh: cho model trích calculated_total song song với stated_total, rồi đánh dấu chênh lệch bằng một boolean conflict_detected. Điểm hay của pattern này là nó biến một lỗi ngữ nghĩa thành một field máy đọc được — hạ nguồn có thể route, đếm và cảnh báo trên nó mà không cần đọc lại tài liệu.

Cùng tinh thần đó: gắn field detected_pattern lên mỗi finding để về sau phân tích được việc dismissal diễn ra một cách hệ thống — hạng mục nào bị bỏ qua nhiều nhất, và vì sao. Không có nhãn này, bạn chỉ có cảm giác "review nhiễu quá".

4.5 Xử lý theo lô (Message Batches)

Ba con số và một giới hạn năng lực:

• Tiết kiệm 50% chi phí.
• Cửa sổ xử lý tới 24 giờ.
• Không có latency SLA — thực tế thường nhanh hơn nhiều, nhưng "thường nhanh hơn" không phải là cam kết và không được thiết kế dựa trên nó.
• Không hỗ trợ multi-turn tool calling trong một request. Đây là giới hạn năng lực, không phải giới hạn hiệu năng: một workflow agentic nhiều vòng không thể chạy trong batch.

Phép chọn: batch cho công việc không chặn ai và chịu được độ trễ — sinh test qua đêm, báo cáo audit hàng tuần, xử lý tồn kho tài liệu. Bất cứ thứ gì một developer đang ngồi chờ — điển hình là blocking pre-merge check — phải ở lại synchronous API.

Vận hành: custom_id ghép cặp request với response, nên kết quả batch hoàn toàn đối chiếu lại được. Khi một phần items fail, cách đúng là resubmit chỉ những item đã fail theo custom_id, kèm sửa đổi — ví dụ chunk nhỏ các tài liệu vượt giới hạn — chứ không nộp lại cả lô. Tần suất nộp được tính ngược từ SLA nghiệp vụ. Và tinh chỉnh prompt trên một sample set trước khi batch khối lượng lớn: một prompt sai nhân với mười nghìn tài liệu là mười nghìn kết quả sai giá rẻ.

4.6 Review nhiều instance và nhiều pass

Self-review bị giới hạn: model giữ nguyên lập luận đã sinh ra code nên ít có xu hướng chất vấn chính lựa chọn của mình. Một instance review độc lập, không mang context sinh code, bắt được nhiều vấn đề tinh vi hơn. Đây là mặt kia của session context isolation ở 3.6.

Multi-pass review đối phó với attention dilution trên diff lớn. Triệu chứng đặc trưng của dilution: độ sâu review không đồng đều và mâu thuẫn nội tại — flag một pattern ở file này rồi chấp thuận đúng đoạn code ấy ở file khác. Cấu trúc đúng là chia pass theo chiều phân tích: một pass local phân tích từng file, cộng một pass riêng cho tích hợp cross-file.

Cảnh báo mà exam guide nêu thẳng, và sample 12 kiểm tra: biểu quyết đa số qua N pass đầy đủ sẽ triệt tiêu chính những bug thật mà chỉ vài pass bắt được. Quy tắc 2-trên-3 nghe rất giống kỹ thuật giảm nhiễu, nhưng bug hiếm và tinh vi theo định nghĩa là thứ chỉ một pass nhìn ra — bỏ phiếu chống lại nó là bỏ chính giá trị của multi-pass.

Pass verification trong đó model tự báo cáo confidence từng finding thì có ích — không phải để tự lọc, mà để cho phép calibrated routing: đưa các finding có confidence thấp sang một luồng xử lý khác. Lưu ý ràng buộc từ 5.5: confidence chỉ có nghĩa sau khi đã được hiệu chỉnh trên một tập nhãn.

Domain này hỏi gì

D5 chiếm 15% đề, khoảng 9 trên 60 câu, 6 task statement. Nó là domain có mặt rộng nhất theo scenario: xuất hiện trong Customer Support Resolution Agent, Multi-Agent Research System, Structured Data Extraction và Code Generation with Claude Code. Trọng số nhỏ nhưng phủ sóng lớn — bạn sẽ gặp D5 dù rút được scenario nào.

Điểm chung của cả sáu task statement là những chỗ hệ thống mất thông tin một cách âm thầm. Tóm tắt lũy tiến bào mòn các con số. Finding nằm giữa một input dài bị bỏ qua. Một lỗi được báo cáo bằng câu chữ chung chung khiến coordinator không phục hồi được. Một tỉ lệ chính xác 97% che mất một loại tài liệu đang hỏng. Attribution biến mất sau ba lần tổng hợp. Không cái nào ném ra exception — đó chính là lý do chúng được ra đề.

Hình dạng đáp án đúng ở đây gần như luôn là một cấu trúc dữ liệu tường minh thay cho một hy vọng ngầm: một khối case facts thay vì tin vào tóm tắt, một error object có trường thay vì một chuỗi trạng thái, một claim-source mapping thay vì việc tái dựng nguồn về sau.

5.1 Giữ thông tin trọng yếu qua các phiên dài

Ba cơ chế thất thoát, mỗi cái có một mitigation riêng:

Cơ chế thất thoát	Biểu hiện	Mitigation
Progressive summarisation	Giá trị số, phần trăm, ngày tháng và kỳ vọng khách hàng nói ra bị nén thành mơ hồ ("khách hàng muốn hoàn tiền" thay cho "hoàn 47,50 USD cho đơn ngày 3/6")	Trích các transactional fact — số tiền, ngày, order number, trạng thái — vào một khối "case facts" bền vững, đưa vào mọi prompt, nằm ngoài phần history bị tóm tắt
Lost in the middle	Phần đầu và cuối input dài được xử lý đáng tin; nội dung ở giữa bị bỏ sót	Đặt bản tóm tắt các key finding ở đầu input tổng hợp
Tool result tích tụ	Tool output ngốn token không tương xứng với độ liên quan của chúng	Trim tool output xuống các field liên quan trước khi chúng vào context — cắt tại nguồn, không dọn về sau

Thêm hai điểm: với session nhiều vấn đề cùng lúc, lưu dữ liệu issue có cấu trúc ở một context layer riêng thay vì để chúng chìm trong hội thoại; và yêu cầu subagent phát ra metadata (ngày tháng, vị trí nguồn, ngữ cảnh phương pháp) cùng với nội dung. Cũng nhớ sự thật vận hành nền tảng: toàn bộ conversation history phải được gửi lại trong mỗi request API kế tiếp — API không giữ trạng thái hộ bạn.

5.2 Escalation và xử lý mơ hồ

Ba trigger escalation hợp lệ:

1. Khách hàng nói rõ họ muốn gặp người. Đây là first-class trigger: honour ngay lập tức, không thử tự giải quyết một lượt trước cho phải phép.
2. Chính sách có ngoại lệ hoặc có lỗ hổng — tình huống mà policy không nói gì, hoặc nói điều mâu thuẫn. Lưu ý: điều kiện là chính sách không phủ, không phải cảm giác "ca này phức tạp".
3. Không thể tiến triển thực chất — agent đã cạn đường đi có ý nghĩa.

Hai tín hiệu không hợp lệ, và đề kiểm tra chúng trực tiếp:

Lập luận cho vế confidence rất đáng nhớ vì nó tự khép kín: một agent đã tự tin sai trên các ca khó thì không thể dùng chính điểm tự tin của nó để nhận diện ca khó. Vế sentiment thì lệch chiều theo kiểu khác: khách hàng bực bội về một chuyện agent xử lý được hoàn toàn không cần người, còn khách hàng lịch sự vẫn có thể đang đứng giữa một ngoại lệ chính sách.

Xử lý mơ hồ: khi tra ra nhiều khách hàng khớp, hãy xin thêm định danh — không bao giờ đoán bằng heuristic kiểu "chọn tài khoản hoạt động gần nhất". Khi escalation đang hoạt động kém, cách sửa là tiêu chí escalation tường minh cộng few-shot examples (nối thẳng vào D4). Và khi vấn đề nằm trong năng lực xử lý, hãy ghi nhận sự bực bội rồi vẫn đưa ra hướng giải quyết — thừa nhận cảm xúc không phải là escalate.

5.3 Lan truyền lỗi trong hệ multi-agent

Khi một subagent thất bại, thứ nó trả về quyết định coordinator còn phục hồi được hay không. Structured error context gồm: loại thất bại, truy vấn đã thử, các kết quả một phần đã có, và các hướng thay thế. Một chuỗi kiểu "search unavailable" giấu đi đúng những thứ cần cho việc phục hồi.

Phân biệt phải thuộc lòng — hai tình huống nhìn giống nhau nhưng đòi hai quyết định khác nhau:

Tình huống	Bản chất	Coordinator nên
Access failure — timeout, service error	Truy vấn không chạy được	Cân nhắc retry, đổi nguồn, hoặc đánh dấu vùng chưa được phủ
Valid empty result — query chạy xong, không có match	Truy vấn đã chạy và câu trả lời là "không có gì"	Ghi nhận đây là một finding thật; retry không thêm được gì

Gộp hai thứ này vào cùng một biểu diễn là lỗi thiết kế bị hỏi thẳng trong đề.

Hai anti-pattern đối xứng, cả hai đều sai:

• Silent suppression — trả về rỗng và đánh dấu success. Coordinator kết luận trên một khoảng trống mà nó không biết là khoảng trống.
• Kết thúc toàn bộ workflow vì một subagent lỗi. Một nguồn hỏng không làm mất giá trị của bốn nguồn còn lại.

Đúng cách: subagent tự phục hồi cục bộ với lỗi transient và chỉ propagate cái nó không tự giải quyết được; synthesis output mang coverage annotation đánh dấu đâu là finding được hậu thuẫn tốt, đâu là vùng còn thiếu dữ liệu. Báo cáo nói rõ chỗ nào chưa phủ vẫn hữu ích; báo cáo im lặng về chỗ chưa phủ thì gây hại.

5.4 Khám phá codebase lớn

Triệu chứng của context degradation trong session kéo dài rất đặc trưng: câu trả lời không nhất quán giữa các lượt, và agent bắt đầu nói về "pattern thường gặp" thay vì gọi tên đúng các class cụ thể nó đã phát hiện trước đó. Đây là dấu hiệu chi tiết cũ đã trôi khỏi context hiệu dụng.

Bốn cơ chế đối phó:

• Scratchpad file — ghi các finding then chốt ra file để chúng tồn tại qua ranh giới context. Chúng đọc lại được, không phụ thuộc vào việc còn nằm trong window hay không.
• Subagent delegation — cô lập phần khám phá dài dòng ở subagent; main agent giữ context của nó cho việc điều phối. Cùng nguyên lý với context: fork (3.2) và Explore subagent (3.4).
• Structured state persistence cho crash recovery — mỗi agent export state ra một vị trí đã biết; khi resume, coordinator nạp một manifest để biết cái gì đã xong.
• /compact — giảm mức tiêu thụ context ngay trong session để phiên dài tiếp tục làm việc được.

Kỷ luật đi kèm: tóm tắt finding của một phase trước khi spawn subagent cho phase kế tiếp. Nếu không, mỗi phase mới bắt đầu từ một trạng thái vừa quá tải vừa thiếu chính xác.

5.5 Human review workflow và calibration

Câu chuyện điển hình: một pipeline extraction đạt 97% chính xác tổng thể, đội vận hành muốn cắt bớt human review. Câu trả lời của exam guide bắt đầu bằng một cảnh báo:

97% tổng thể hoàn toàn có thể là 99% trên loại tài liệu chiếm đa số và 70% trên một loại hiếm — hoặc chính xác trên mọi field trừ một field mà bên hạ nguồn quan tâm nhất. Hai việc bắt buộc làm trước khi giảm review:

1. Phân đoạn accuracy theo loại tài liệu VÀ theo field — cả hai chiều, không phải một. Một chiều vẫn che được chiều kia.
2. Stratified random sampling trên các extraction có confidence cao, chạy liên tục — để đo tỉ lệ lỗi thực tế và phát hiện pattern lỗi mới khi phân phối tài liệu đầu vào thay đổi.

Về confidence: field-level confidence score chỉ có nghĩa sau khi được hiệu chỉnh trên một labelled validation set. Trước khi hiệu chỉnh, "0.9" chỉ là một con số model phát ra, không phải xác suất đúng — và không đủ tư cách điều khiển bất cứ ngưỡng routing nào.

Khi confidence đã được hiệu chỉnh, hãy dùng nó để dồn năng lực reviewer vào nơi lỗi tập trung: extraction có confidence thấp, và tài liệu nguồn mơ hồ hoặc tự mâu thuẫn. Phân bổ theo thứ tự đến hoặc theo số trang là phân bổ mù.

5.6 Provenance và uncertainty trong tổng hợp đa nguồn

Attribution mất đi vì một lý do rất cơ học: mỗi bước summarisation nén finding lại mà không giữ ánh xạ claim→source. Sau hai ba tầng, báo cáo cuối cùng nói những điều đúng mà không ai truy được chúng đến từ đâu.

Cách sửa nằm ở tầng contract giữa các agent: yêu cầu subagent xuất ra structured claim-source mapping — claim, đoạn trích làm bằng chứng, URL nguồn hoặc tên tài liệu — và yêu cầu mọi agent hạ nguồn giữ nguyên và merge ánh xạ đó xuyên qua synthesis. Từ khóa để chọn đáp án: attribution được preserved, không bao giờ được reconstructed. Cố dựng lại nguồn ở bước cuối là đoán.

Khi hai nguồn đều đáng tin đưa ra số liệu mâu thuẫn, hành động đúng là annotate xung đột kèm cả hai giá trị và attribution của chúng, để coordinator đối chiếu một cách có chủ ý. Ba cách xử lý sai, đều là distractor quen mặt: âm thầm chọn một, lấy trung bình, hoặc bỏ cả hai. Trung bình đặc biệt nguy hiểm vì nó tạo ra một con số không nguồn nào từng phát biểu.

Ba yêu cầu bổ trợ:

• Bắt buộc có ngày công bố / ngày thu thập dữ liệu trong structured output. Rất nhiều "mâu thuẫn" thực ra là hai lát cắt thời gian khác nhau; thiếu ngày thì không phân biệt được.
• Cấu trúc báo cáo theo section tách bạch phần đã được xác lập vững với phần còn tranh cãi — người đọc thấy ngay ranh giới của sự chắc chắn.
• Render đúng loại nội dung: dữ liệu tài chính dạng bảng, tin tức dạng văn xuôi, finding kỹ thuật dạng danh sách có cấu trúc.