Quy Trình Làm Việc Động Claude Code: Chạy Hàng Trăm Tiểu Tác Tử Song Song với Opus 4.8

Claude Opus 4.8 được phát hành với một tính năng nổi bật cho Claude Code: Quy trình làm việc động (Dynamic Workflows). Trong một phiên, một tác nhân điều phối (orchestrating agent) có thể tạo ra hàng trăm tác nhân phụ song song (parallel subagents) để xử lý một nhiệm vụ lớn và phân nhánh: tái cấu trúc nhiều tệp, chạy ma trận kiểm thử rộng, hoặc thử nhiều hướng triển khai cùng lúc.

Dùng thử Apidog ngay hôm nay

Bài viết này tập trung vào cách Quy trình làm việc động hoạt động, khi nào nên dùng, và cách tự xây dựng mô hình điều phối tương tự bằng API thô. Nếu bạn cần bối cảnh về mô hình, xem Claude Opus 4.8 là gì. Nếu bạn muốn đào sâu kiến trúc tác nhân, xem thêm bài phân tích kiến trúc khai thác tác nhân của Claude Code.

Quy trình làm việc động thực sự là gì

Trong Claude Code, Quy trình làm việc động xuất hiện dưới dạng chế độ ultracode trong menu effort.

Điểm quan trọng: ultracode không phải là một cấp effort API mới. Nó là sự kết hợp của hai khả năng đã có trong Opus 4.8:

1. Cấp độ effort là xhigh
2. Thông báo hệ thống giữa cuộc trò chuyện (mid-conversation system messages)

Khi kết hợp, chúng cho phép tác nhân điều phối:

• lập kế hoạch cho một nhiệm vụ lớn;
• chia nhiệm vụ thành nhiều đơn vị độc lập;
• khởi chạy các tác nhân làm việc song song;
• thu thập và hợp nhất kết quả.

Nói ngắn gọn: phần “động” đến từ khả năng thêm quyền/hướng dẫn mới giữa phiên, còn phần “sâu” đến từ effort: xhigh.

Thành phần 1: effort: xhigh

Tham số effort kiểm soát lượng token mà Opus 4.8 dùng cho một phản hồi, bao gồm cả quá trình gọi công cụ.

Với Quy trình làm việc động, xhigh phù hợp vì tác nhân điều phối phải làm nhiều việc hơn một phản hồi thông thường:

• phân tích phạm vi codebase;
• xác định các phần có thể chạy song song;
• quyết định số lượng tác nhân làm việc;
• tạo nhiệm vụ con rõ ràng cho từng tác nhân;
• hợp nhất kết quả cuối cùng.

Các mức effort thấp hơn có thể không đủ không gian lập luận cho các phiên dài hoặc nhiệm vụ có nhiều nhánh.

Khi dùng xhigh, hãy đặt max_tokens đủ lớn. Ví dụ, 64000 là một điểm khởi đầu hợp lý cho tác vụ điều phối lớn:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    thinking={"type": "adaptive"},
    messages=[
        {
            "role": "user",
            "content": "Lập kế hoạch tái cấu trúc module auth trên 14 service."
        }
    ],
)

Thành phần 2: Thông báo hệ thống giữa cuộc trò chuyện

Trước Opus 4.8, system prompt thường được đặt ở đầu cuộc trò chuyện và giữ nguyên trong suốt phiên.

Với thông báo hệ thống giữa cuộc trò chuyện, bạn có thể chèn một mục system vào giữa mảng messages để bổ sung hướng dẫn hoặc quyền mới trong lúc nhiệm vụ đang chạy.

Điều này hữu ích cho mô hình điều phối vì bạn có thể:

• bắt đầu bằng một phiên lập kế hoạch;
• sau đó cấp quyền cho tác nhân điều phối tạo các tác nhân làm việc;
• thay đổi phạm vi hoặc ràng buộc khi đã hiểu rõ nhiệm vụ hơn.

Ví dụ hình dạng message có thể như sau:

[
  {
    "role": "user",
    "content": "Phân tích codebase và đề xuất kế hoạch refactor."
  },
  {
    "role": "assistant",
    "content": "Tôi sẽ chia công việc thành các module độc lập..."
  },
  {
    "role": "system",
    "content": "Bạn được phép điều phối các tác nhân làm việc song song. Mỗi tác nhân chỉ xử lý một module và phải trả về diff summary."
  },
  {
    "role": "user",
    "content": "Tiếp tục và tạo kế hoạch phân tán công việc."
  }
]

Đây là thay đổi nhỏ ở cấp API, nhưng tác động lớn: tác nhân có thể nhận thêm khả năng dựa trên những gì nó phát hiện trong quá trình chạy.

Bật Quy trình làm việc động trong Claude Code

Trong Claude Code, Quy trình làm việc động nằm sau tùy chọn ultracode trong menu effort.

Khi chọn ultracode, Claude Code sẽ:

• đặt effort thành xhigh;
• cấp quyền cho phiên khởi chạy các tác nhân phụ song song;
• dùng thông báo hệ thống giữa cuộc trò chuyện để điều phối quá trình này.

Sau đó, bạn mô tả nhiệm vụ lớn theo cách đủ rõ để tác nhân điều phối chia nhỏ công việc.

Ví dụ prompt thực tế:

Refactor toàn bộ luồng xác thực trên các service.
Mục tiêu:
- Chuẩn hóa middleware auth.
- Loại bỏ logic duplicate.
- Giữ backward compatibility.
- Chạy hoặc đề xuất test cho từng service.
- Trả về summary theo từng service và rủi ro migration.

Claude Code sẽ tự động:

• lập kế hoạch nhiệm vụ;
• chia nhiệm vụ thành các phần độc lập;
• khởi chạy tác nhân làm việc song song;
• thu kết quả về phiên chính;
• hợp nhất thành kết quả cuối cùng.

Nếu bạn đang thiết lập Claude Code với một plan, xem hướng dẫn thiết lập Claude Agent SDK với Claude plan.

Khi nào nên dùng Quy trình làm việc động

Dùng Quy trình làm việc động khi nhiệm vụ có thể song song hóa rõ ràng.

Các trường hợp phù hợp:

• tái cấu trúc cùng một pattern trên nhiều tệp hoặc nhiều service;
• tạo và chạy ma trận kiểm thử lớn;
• phân tích nhiều module độc lập trong codebase;
• thử nhiều phương án triển khai song song rồi so sánh;
• rà soát nhiều API endpoint theo cùng một tiêu chí.

Ví dụ nhiệm vụ tốt:

Phân tích 20 endpoint trong module billing.
Với mỗi endpoint:
- kiểm tra validation;
- kiểm tra handling lỗi;
- xác định test còn thiếu;
- đề xuất thay đổi nhỏ nếu cần.
Trả về bảng tổng hợp theo endpoint.

Nhiệm vụ này phù hợp vì từng endpoint có thể được xử lý độc lập.

Khi nào không nên dùng

Không nên dùng Quy trình làm việc động cho nhiệm vụ hẹp hoặc tuần tự.

Tránh dùng nếu:

• chỉ sửa một tệp nhỏ;
• mỗi bước phụ thuộc chặt vào bước trước;
• nhiệm vụ cần một luồng suy luận tuyến tính;
• chi phí token quan trọng hơn tốc độ;
• bạn chưa có tiêu chí hợp nhất kết quả rõ ràng.

Ví dụ không phù hợp:

Đổi tên một biến trong một file duy nhất.

Khởi chạy nhiều tác nhân phụ cho loại nhiệm vụ này chỉ làm tăng chi phí mà không tạo thêm giá trị.

Xây dựng mô hình tương tự bằng API

Bạn không cần Claude Code để xây dựng điều phối đa tác nhân. Với Messages API, bạn có thể tự triển khai cùng một mô hình.

Anthropic có ví dụ trong tài liệu về xây dựng chế độ điều phối.

Luồng triển khai cơ bản:

1. Gọi tác nhân điều phối với effort: xhigh.
2. Yêu cầu nó chia nhiệm vụ thành các đơn vị độc lập.
3. Dùng thông báo hệ thống giữa cuộc trò chuyện để cấp quyền điều phối.
4. Chạy nhiều tác nhân làm việc song song.
5. Thu kết quả.
6. Gửi kết quả về tác nhân điều phối để hợp nhất.

Ví dụ bước điều phối:

import anthropic

client = anthropic.Anthropic()

orchestrator = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    thinking={"type": "adaptive"},
    messages=[
        {
            "role": "user",
            "content": """
            Lập kế hoạch refactor module auth trên 14 service.

            Trả về JSON gồm:
            - danh sách work_items
            - service_name
            - phạm vi thay đổi
            - tiêu chí hoàn thành
            - rủi ro cần kiểm tra
            """
        }
    ],
)

Sau khi có danh sách work_items, bạn có thể chạy worker calls song song. Mỗi worker thường có phạm vi nhỏ hơn, nên có thể dùng effort thấp hơn để kiểm soát chi phí.

Ví dụ worker:

worker = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=12000,
    output_config={"effort": "medium"},
    messages=[
        {
            "role": "system",
            "content": """
            Bạn là worker agent. Chỉ xử lý service được giao.
            Không thay đổi phạm vi ngoài work item.
            Trả về:
            - summary
            - files_changed
            - risks
            - tests_to_run
            """
        },
        {
            "role": "user",
            "content": """
            Work item:
            Service: auth-api
            Scope: Chuẩn hóa middleware xác thực.
            Completion criteria: Middleware mới phải tương thích với token hiện tại.
            """
        }
    ],
)

Nếu bạn đang so sánh cách tự xây với hạ tầng agent được lưu trữ, xem tác nhân được quản lý so với Agent SDK.

Mẫu kiến trúc điều phối

Một kiến trúc tối thiểu có thể gồm 4 phần:

User request
    |
    v
Orchestrator agent: effort xhigh
    |
    v
Task plan / work_items
    |
    +--> Worker agent 1: effort medium/low
    +--> Worker agent 2: effort medium/low
    +--> Worker agent 3: effort medium/low
    |
    v
Collected worker results
    |
    v
Orchestrator merge step
    |
    v
Final answer / patch / report

Điểm quan trọng là định dạng output của worker phải ổn định. Nếu không, bước hợp nhất sẽ dễ lỗi.

Ví dụ schema đơn giản cho worker result:

{
  "work_item_id": "auth-api-001",
  "status": "completed",
  "summary": "Chuẩn hóa middleware xác thực cho auth-api.",
  "files_changed": [
    "services/auth-api/src/middleware/auth.ts"
  ],
  "risks": [
    "Cần kiểm tra backward compatibility với token cũ."
  ],
  "tests_to_run": [
    "npm test -- auth-api"
  ]
}

Chi phí và kiểm soát

Quy trình làm việc động có thể tốn nhiều token. Nếu một phiên khởi chạy 200 worker và mỗi worker dùng hàng chục nghìn token, tổng chi phí sẽ tăng rất nhanh.

Ba cách kiểm soát chi phí:

• Giới hạn phạm vi worker thật chặt
  
  Mỗi worker chỉ nên xử lý một module, service, endpoint hoặc nhóm tệp cụ thể.

• Hạ effort cho worker khi có thể
  
  Dùng xhigh cho orchestrator, nhưng worker có thể dùng medium hoặc low nếu tác vụ con đủ hẹp.

• Đặt max_tokens cho từng worker
  
  Không để một worker tiêu thụ ngân sách quá mức.

Ví dụ cấu hình hợp lý hơn:

worker = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=8000,
    output_config={"effort": "medium"},
    messages=[...],
)

Nếu có ngữ cảnh lặp lại giữa nhiều worker, hãy cân nhắc lưu trữ bộ đệm ngữ cảnh chung để giảm chi phí. Xem thêm phân tích giá của Opus 4.8 để hiểu tác động của effort và caching.

Kiểm tra luồng điều phối với Apidog

Khi xây dựng điều phối qua API, phần dễ lỗi nhất là fan-out/fan-in:

• worker có nhận đúng ngữ cảnh không;
• mỗi worker có bị vượt phạm vi không;
• response có đúng format để merge không;
• mid-conversation system message có được gửi đúng vị trí không;
• logic retry có làm trùng kết quả không.

Bạn không nên phát hiện các lỗi này sau khi đã chạy hàng trăm API call thật.

Apidog có thể giúp kiểm tra từng phần:

• lưu request điều phối đến https://api.anthropic.com/v1/messages;
• kiểm tra output kế hoạch trước khi fan-out;
• mock endpoint worker để test logic phân tán và hợp nhất;
• thêm assertion cho định dạng response của worker;
• phát lại cùng một worker request với nhiều cấp effort để so sánh chi phí và chất lượng.

Một quy trình kiểm thử thực tế:

1. Tạo request orchestrator trong Apidog.
2. Kiểm tra JSON kế hoạch trả về.
3. Mock worker responses theo schema mong muốn.
4. Chạy logic merge trên mock data.
5. Thêm assertion cho các trường bắt buộc như work_item_id, status, summary.
6. Sau khi ổn định, chuyển từ mock sang endpoint thật.

Bạn có thể bắt đầu từ request cơ bản trong hướng dẫn API Opus 4.8.

Checklist triển khai

Trước khi chạy Quy trình làm việc động hoặc tự xây orchestrator, hãy kiểm tra:

• [ ] Nhiệm vụ có thể chia thành nhiều phần độc lập.
• [ ] Orchestrator dùng effort: xhigh.
• [ ] Worker có phạm vi rõ ràng.
• [ ] Worker không cần toàn bộ ngữ cảnh codebase nếu không cần thiết.
• [ ] Mỗi worker có max_tokens.
• [ ] Output worker có schema ổn định.
• [ ] Có bước merge kết quả.
• [ ] Có cơ chế phát hiện worker lỗi hoặc trả về sai format.
• [ ] Đã test bằng mock trước khi chạy hàng loạt call thật.

Câu hỏi thường gặp

Quy trình làm việc động trong Claude Code là gì?

Đó là tính năng cho phép một phiên khởi chạy nhiều tác nhân phụ song song để xử lý nhiệm vụ lớn, phân nhánh. Nó dựa trên effort: xhigh và thông báo hệ thống giữa cuộc trò chuyện trong Opus 4.8.

Ultracode có phải là một cấp effort riêng không?

Không. Ultracode là tên Claude Code dùng cho cấu hình kết hợp effort: xhigh với quyền khởi chạy quy trình đa tác nhân. Các cấp effort API vẫn là low, medium, high, xhigh và max.

Thông báo hệ thống giữa cuộc trò chuyện là gì?

Đó là khả năng đặt một mục system vào giữa cuộc trò chuyện để thêm hướng dẫn hoặc quyền mới trong lúc nhiệm vụ đang chạy.

Có thể xây Quy trình làm việc động mà không dùng Claude Code không?

Có. Bạn có thể dùng Messages API thô, kết hợp effort: xhigh, mid-conversation system messages, và nhiều worker calls chạy song song.

Quy trình làm việc động có tốn kém không?

Có thể. Nhiều worker ở cấp xhigh có thể tiêu thụ hàng triệu token. Hãy giới hạn phạm vi worker, hạ effort khi có thể, đặt max_tokens, và dùng caching nếu phù hợp.

Khi nào nên tránh Quy trình làm việc động?

Tránh dùng cho nhiệm vụ nhỏ, tuần tự, hoặc chỉ thay đổi một vùng hẹp. Nếu công việc không thể song song hóa, nhiều tác nhân phụ chỉ làm tăng chi phí mà không cải thiện kết quả.