Domain 1: Agentic Architecture & Orchestration — Ôn thi CCA-F

#Task 1.1: Thiết kế và triển khai agentic loop cho thực thi tác vụ tự chủ

#Knowledge of (Kiến thức về)

• Vòng đời agentic loop: Gửi request tới Claude, kiểm tra stop_reason ("tool_use" vs "end_turn"), thực thi tool được yêu cầu, trả kết quả về cho vòng lặp tiếp theo.
• Nối kết lịch sử: Cách tool result được nối vào lịch sử hội thoại dưới vai trò user để model suy luận bước tiếp theo.
• Mô hình dẫn dắt (Model-driven): Phân biệt quyết định do model dẫn dắt (Claude tự suy luận nên gọi tool nào dựa trên context) với decision tree / chuỗi tool cấu hình sẵn.

#Skills in (Kỹ năng về)

• Kiểm soát luồng: Cài đặt control flow tiếp tục khi stop_reason là "tool_use", dừng khi "end_turn".
• Nạp ngữ cảnh: Thêm tool result vào context giữa các vòng lặp để model tận dụng thông tin mới.
• Tránh các anti-patterns: Parse tín hiệu ngôn ngữ tự nhiên (text thô) để quyết định dừng loop, đặt giới hạn số vòng lặp tuỳ tiện làm cơ chế dừng chính, hoặc kiểm tra text của assistant làm dấu hiệu hoàn thành.

#🧠 Phân tích & Thực tế từ Delivery Manager:

Từ góc độ vận hành, một agentic loop sai lầm sẽ đốt tiền API cực kỳ nhanh hoặc bị treo vô hạn. Để đảm bảo hệ thống production chạy ổn định, mã nguồn phải điều khiển luồng dựa vào cấu trúc dữ liệu trả về của API, tuyệt đối không dùng logic phỏng đoán.

# Vòng lặp Agentic Loop chuẩn — điều khiển theo stop_reason
while True:
    response = client.messages.create(
        model="claude-3-5-sonnet",
        messages=messages,
        tools=tools
    )
    # Ghi nhận phản hồi của trợ lý vào lịch sử
    messages.append({"role": "assistant", "content": response.content})

    if response.stop_reason == "tool_use":
        # Trích xuất và chạy các tool call được yêu cầu
        tool_results = []
        for block in response.content:
            if block.type == "tool_use":
                result = run_tool(block.name, block.input)
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": result
                })
        # Gửi kết quả tool ngược lại cho Claude dưới vai trò user
        messages.append({"role": "user", "content": tool_results})
    else:  # stop_reason == "end_turn" → Hoàn thành nhiệm vụ
        break

• Bẫy câu hỏi cần lưu ý: Đề thi sẽ hỏi về anti-pattern điều khiển vòng lặp. Luôn chọn đáp án tránh parse text thô (như if "DONE" in response.text) và tránh việc chỉ dùng giới hạn lặp làm logic dừng chính.

#Task 1.2: Điều phối hệ multi-agent theo pattern coordinator–subagent

#Knowledge of (Kiến thức về)

• Kiến trúc Hub-and-Spoke: Coordinator quản lý toàn bộ giao tiếp giữa các subagent, xử lý lỗi và định tuyến thông tin.
• Context cô lập: Subagent hoạt động với context cô lập — không tự động thừa hưởng lịch sử hội thoại hay memory của coordinator.
• Vai trò coordinator: Phân rã task, uỷ quyền, gom kết quả, quyết định gọi subagent nào theo độ phức tạp câu hỏi.
• Rủi ro phân rã quá hẹp: Coordinator chia nhỏ task quá sâu làm các subagent mất tầm nhìn tổng quan, dẫn tới bỏ sót phạm vi khi chủ đề nghiên cứu rộng.

#Skills in (Kỹ năng về)

• Chọn subagent động: Thiết kế coordinator phân tích yêu cầu và chọn subagent động thay vì luôn chạy cứng nhắc đủ cả pipeline.
• Phân chia phạm vi: Chia phạm vi nghiên cứu giữa các subagent để giảm trùng lặp (giao subtopic hoặc loại nguồn tài liệu riêng cho từng agent).
• Vòng lặp tinh chỉnh: Coordinator đánh giá output tổng hợp xem có lỗ hổng (gaps) không, uỷ quyền lại cho search/analysis với truy vấn nhắm đích, gọi lại synthesis đến khi đủ độ phủ.
• Quan sát (Observability): Định tuyến mọi giao tiếp của subagent qua coordinator để có logging tập trung, xử lý lỗi nhất quán và kiểm soát luồng thông tin.

#🧠 Phân tích & Thực tế từ Delivery Manager:

Trong các dự án lớn, việc gom tất cả prompt vào một agent duy nhất luôn dẫn đến việc agent bị "quá tải sự chú ý" và hoạt động chập chờn. Giải pháp Hub-and-Spoke giúp cô lập trách nhiệm. Tuy nhiên, rủi ro lớn nhất là điều phối (orchestration) kém: coordinator phân việc quá vụn vặt khiến báo cáo cuối cùng thiếu tính tổng hợp.

#Task 1.3: Cấu hình gọi subagent, truyền context và spawning

#Knowledge of (Kiến thức về)

• Task tool: Đây là công cụ hệ thống để coordinator spawn (khởi tạo) subagent. Cấu hình allowedTools của coordinator bắt buộc phải chứa "Task" mới gọi được subagent.
• Context passing: Context của subagent phải được truyền tường minh trong prompt của nó — subagent không tự thừa hưởng context cha, không chia sẻ memory giữa các lần gọi.
• Cấu hình AgentDefinition: description, system prompt, giới hạn tool (allowedTools) cho từng loại subagent.
• fork_session: Tạo nhánh độc lập từ một baseline phân tích chung để khám phá các hướng khác nhau.

#Skills in (Kỹ năng về)

• Truyền dữ liệu đầy đủ: Đưa đầy đủ kết quả của agent trước trực tiếp vào prompt của subagent (VD: truyền kết quả web search + phân tích tài liệu cho synthesis subagent).
• Dữ liệu có cấu trúc: Dùng định dạng dữ liệu có cấu trúc tách nội dung khỏi metadata (URL nguồn, tên tài liệu, số trang) khi truyền context giữa agent để giữ provenance (nguồn gốc dữ liệu).
• Spawning song song: Spawn subagent song song bằng cách phát nhiều Task tool call trong một response của coordinator, thay vì rải ra nhiều lượt chat.
• Prompt định hướng mục tiêu: Viết prompt coordinator nêu mục tiêu nghiên cứu + tiêu chí chất lượng thay vì chỉ dẫn từng bước, để subagent linh hoạt thích ứng.

#🧠 Phân tích & Thực tế từ Delivery Manager:

Để giảm latency tối đa cho người dùng cuối, lập trình viên phải biết cách cấu hình spawn subagent song song. Nếu gọi tuần tự, thời gian chờ sẽ là tổng thời gian của các agent con.

✅ Đúng: Coordinator trả về 2 Task calls song song trong cùng 1 response:
[Task: "Search mảng Nhạc"] và [Task: "Search mảng Phim"]

❌ Sai: Coordinator gọi Task search nhạc → Chờ kết quả → Lượt sau mới gọi Task search phim.

#Task 1.4: Triển khai workflow nhiều bước với enforcement và handoff pattern

#Knowledge of (Kiến thức về)

• Chặn nghiệp vụ lập trình: Khác biệt giữa enforcement lập trình (hooks, cổng điều kiện tiên quyết) và hướng dẫn qua prompt cho thứ tự workflow.
• Tính tất định (Determinism): Khi cần tuân thủ tất định (VD: xác minh danh tính trước khi hoàn tiền), chỉ dẫn prompt luôn có tỷ lệ thất bại khác 0.
• Handoff protocol: Giao thức bàn giao có cấu trúc khi escalate giữa chừng: gồm thông tin khách hàng, phân tích nguyên nhân gốc, hành động đề xuất.

#Skills in (Kỹ năng về)

• Prerequisite lập trình: Cài đặt prerequisite chặn tool call downstream đến khi bước tiên quyết hoàn thành (VD: chặn process_refund cho tới khi get_customer trả về customer ID đã xác minh).
• Xử lý song song: Phân rã yêu cầu khách hàng nhiều vấn đề thành từng mục riêng, điều tra song song với context chung, rồi tổng hợp thành một giải pháp thống nhất.
• Bàn giao có cấu trúc: Soạn handoff summary có cấu trúc (customer ID, nguyên nhân gốc, số tiền hoàn, hành động đề xuất) khi escalate cho nhân viên — người không xem được transcript hội thoại.

[HANDOFF SUMMARY]
- Customer ID: C-88213 (Đã xác minh qua get_customer)
- Vấn đề: Đơn #A-1023 giao thiếu 1 món ($34.50)
- Nguyên nhân: Lỗi đóng gói kho — ngoài chính sách tự xử lý của Agent
- Đề xuất: Nhân viên duyệt gửi bù hàng hoặc hoàn tiền thẻ gốc

#Task 1.5: Áp dụng Agent SDK hooks để chặn tool call và chuẩn hoá dữ liệu

#Knowledge of (Kiến thức về)

• Hook pattern: Hook (VD: PostToolUse) chặn tool result để biến đổi trước khi model xử lý.
• Chặn tool call đi ra: Hook chặn tool call đi ra để cưỡng chế quy tắc tuân thủ (VD: chặn refund vượt ngưỡng).
• Deterministic vs Probabilistic: Hooks đem lại bảo đảm tất định (luôn đúng 100%), trong khi prompt chỉ đem lại tuân thủ xác suất.

#Skills in (Kỹ năng về)

• Chuẩn hoá dữ liệu: Dùng PostToolUse hook chuẩn hoá dữ liệu hỗn tạp (Unix timestamp, ISO 8601, mã trạng thái số) từ các MCP tool khác nhau trước khi agent xử lý.
• Chặn hành động vi phạm: Cài hook chặn hành động vi phạm chính sách (VD: hoàn tiền > $500) và chuyển hướng sang workflow thay thế (escalate cho người).

# Ví dụ hook chặn tool call đi ra
def pre_tool_use_hook(tool_name, tool_input):
    # Quy tắc bắt buộc: hoàn tiền > $500 phải qua người duyệt
    if tool_name == "process_refund" and tool_input["amount"] > 500:
        return {
            "block": True,
            "message": "Số tiền vượt ngưỡng $500. Hãy chuyển hướng sang escalate_to_human."
        }
    return {"block": False}

#Task 1.6: Thiết kế chiến lược phân rã task cho workflow phức tạp

#Knowledge of (Kiến thức về)

• Chaining vs Adaptive: Khi nào dùng pipeline tuần tự cố định (prompt chaining) vs phân rã động thích ứng theo phát hiện trung gian.
• Prompt chaining: Chia review thành các bước tuần tự (VD: phân tích từng file riêng, rồi chạy một pass tích hợp cross-file).

#Skills in (Kỹ năng về)

• Chọn đúng pattern: Prompt chaining cho review nhiều khía cạnh dễ đoán, phân rã động cho điều tra mở rộng.
• Tránh loãng attention: Chia code review lớn thành pass phân tích cục bộ từng file + một pass tích hợp cross-file riêng để tránh loãng attention của mô hình.
• Lập kế hoạch thích ứng: Phân rã task mở (VD: "thêm test toàn diện cho codebase legacy"): map cấu trúc trước, xác định vùng tác động cao, rồi lập kế hoạch ưu tiên có thể điều chỉnh khi phát hiện dependency mới.

#Task 1.7: Quản lý session state, resume và fork

#Knowledge of (Kiến thức về)

• Resume session: Dùng --resume <session-name> để tiếp tục một cuộc hội thoại cụ thể.
• fork_session: Tạo nhánh độc lập từ baseline phân tích chung để thử các hướng khác nhau.
• Stale files: Tầm quan trọng của việc báo cho agent biết file đã phân tích trước đó bị thay đổi khi resume sau khi sửa code.
• Bắt đầu mới kèm summary: Tại sao bắt đầu session mới kèm bản tóm tắt có cấu trúc đáng tin hơn resume với tool result đã cũ (stale).

#Skills in (Kỹ năng về)

• Resume/Fork thực tế: Dùng --resume và fork_session phục vụ việc so sánh 2 chiến lược test hoặc refactor từ cùng một phân tích codebase gốc.
• Báo file thay đổi: Chỉ rõ cho session được resume về những file cụ thể đã thay đổi để mô hình tiến hành phân tích lại có mục tiêu, tránh việc agent sử dụng ngữ cảnh cũ đã lỗi thời.

Quay lại Trang Hub ôn thi CCA-F.