Dàn nhạc các tác tử viết mã - Cách khiến lập trình đa tác tử thực sự hoạt động

• Đang diễn ra một sự chuyển dịch từ cách cộng tác với một trợ lý AI đơn lẻ theo vòng lặp đồng bộ sang mô hình điều phối viên, nơi nhiều tác tử hoạt động bất đồng bộ với cửa sổ ngữ cảnh và phạm vi tệp riêng của mình, tính đến năm 2026
• Ba mẫu cốt lõi gồm Subagents, Agent Teams, và ủy quyền phân cấp tạo thành cấu trúc nền tảng của lập trình đa tác tử, mỗi mẫu mang lại các hiệu quả như song song hóa, chuyên môn hóa, cô lập và học tập tích lũy
• Danh sách tác vụ dùng chung và nhắn tin ngang hàng là cơ chế điều phối cốt lõi của Agent Teams, cho phép tự động gỡ phụ thuộc và tránh nút thắt cổ chai
• Tính đến năm 2026, hệ sinh thái công cụ được chia thành ba tầng: subagent trong cùng tiến trình (Tier 1), orchestrator cục bộ (Tier 2), và tác tử bất đồng bộ trên đám mây (Tier 3), và hầu hết nhà phát triển đều kết hợp cả ba tầng tùy theo mục đích sử dụng
• Nút thắt cổ chai đã chuyển từ sinh mã sang xác minh (Verification), và các cổng chất lượng cùng đánh giá của con người thông qua phê duyệt kế hoạch, hooks và AGENTS.md là những yếu tố then chốt quyết định độ tin cậy của hệ thống đa tác tử

---

Chuyển dịch hiện tại: từ conductor sang orchestrator

• Cho đến 6 tháng trước, đa số nhà phát triển vẫn làm việc đồng bộ với một trợ lý AI đơn lẻ, và một cửa sổ ngữ cảnh duy nhất là giới hạn trên của công việc
• Hiện nay, những nhà phát triển có năng suất cao nhất đang chuyển sang cách điều phối bất đồng bộ nhiều tác tử, mỗi tác tử có cửa sổ ngữ cảnh, phạm vi tệp và vùng trách nhiệm riêng
• Mô hình Conductor: hướng dẫn một tác tử đơn theo cách đồng bộ thời gian thực; Claude Code CLI và agent mode trong trình soạn thảo Cursor là các công cụ tiêu biểu
• Mô hình Orchestrator: điều phối bất đồng bộ nhiều tác tử, mỗi tác tử có cửa sổ ngữ cảnh riêng; Agent Teams, Conductor, Codex và Copilot Coding Agent là các công cụ tiêu biểu
• Với vai trò orchestrator, cần có những năng lực mới như viết đặc tả rõ ràng, phân rã công việc và xác minh kết quả

8 cấp độ của lập trình có AI hỗ trợ

• [Orchestration]
  • L8 — Tự xây orchestrator của riêng mình: tự triển khai lớp điều phối bằng mã để trực tiếp tạo, định tuyến và quản lý tác tử
  • L7 — Hơn 10 tác tử, quản lý thủ công: "Ôi không, mọi thứ thành mớ hỗn độn rồi." Ngữ cảnh sai được chuyển cho sai tác tử, và câu hỏi "Điều gì xảy ra nếu Claude Code chạy Claude Code?" bắt đầu xuất hiện
  • L6 — Multiplexing tác tử: vì chờ đợi quá chán nên chạy thêm từng tác tử một, rồi rơi vào trạng thái không thể dừng khi liên tục chuyển qua lại giữa nhiều luồng
• [Agent-first]
  • L5 — Agent-first, IDE đứng sau: cuộc hội thoại với tác tử là không gian làm việc chính, IDE dùng để kiểm tra mã
  • L4 — diff biến mất, hội thoại dẫn dắt: không còn xem xét diff mỗi lần, mà tập trung quan sát hành vi của tác tử và đưa định hướng
• [Kỷ nguyên IDE]
  • L3 — Chế độ YOLO: tác tử được tự do chạy trong IDE, mức độ tin cậy tăng lên
  • L2 — Tác tử trong IDE, phê duyệt quyền thủ công: tự mình cho phép mọi thay đổi tệp, kiểm soát hoàn toàn bằng tay
  • L1 — Không có AI: quy trình phát triển truyền thống
• Theo khung 8 cấp độ sử dụng công cụ AI do Steve Yegge tổng hợp, phần lớn nhà phát triển vẫn dừng ở cấp độ 3–4
• Lớp orchestration bắt đầu từ cấp độ 6, và đòi hỏi bộ kỹ năng khác biệt về bản chất so với năng lực tích lũy đến cấp độ 5
• Nội dung này đề cập đến cấp độ 5–8

Giới hạn của tác tử đơn

• Quá tải ngữ cảnh: một tác tử đơn có giới hạn về lượng thông tin có thể giữ, và codebase quy mô lớn sẽ áp đảo một cửa sổ ngữ cảnh đơn lẻ
• Thiếu chuyên môn hóa: một tác tử xử lý cả lớp dữ liệu, API, UI và kiểm thử rốt cuộc chỉ là một generalist, trong khi tác tử chỉ chuyên trách lớp dữ liệu viết mã DB tốt hơn nhiều
• Thiếu điều phối: ngay cả khi thêm các tác tử trợ giúp, chúng vẫn không thể giao tiếp với nhau, chia sẻ tác vụ hay giải quyết phụ thuộc; càng tăng số tác tử mà không có primitive điều phối thì càng khó quản lý
• Subagent giải quyết hai vấn đề đầu, còn Agent Teams giải quyết cả ba vấn đề

Vì sao cần đa tác tử

• Tính song song (thông lượng gấp 3): tác tử frontend, backend và kiểm thử làm việc đồng thời
• Chuyên môn hóa (ngữ cảnh tập trung): mỗi tác tử chỉ nhận biết các tệp mà mình phụ trách; tác tử chỉ biết db.js sẽ viết mã DB tốt hơn tác tử phải xử lý toàn bộ codebase
• Cô lập (thực thi an toàn): Git worktree cung cấp thư mục làm việc độc lập cho từng tác tử, không có xung đột khi hợp nhất
• Học tập tích lũy: tệp AGENTS.md tích lũy các mẫu và lưu ý qua nhiều phiên, để mỗi phiên tiếp theo được cải thiện từ phiên trước
• Ba tác tử tập trung luôn cho kết quả tốt hơn một tác tử generalist làm việc lâu gấp ba

Mẫu 1: Subagent — ủy quyền tập trung

• Dùng công cụ Task để tạo các tác tử con chuyên môn hóa từ orchestrator cha; đây là mẫu đa tác tử đơn giản nhất và nên thử trước
• Ví dụ cụ thể: khi đưa cho Claude Code prompt "hãy xây dựng trình quản lý bookmark Link Shelf bằng Express và SQLite", orchestrator cha sẽ phân rã thành ba brief cho subagent
  • Subagent lớp dữ liệu: xây db.js rồi viết báo cáo DATA.md
  • Subagent logic nghiệp vụ: xây validation.js rồi viết báo cáo LOGIC.md
  • Subagent route API: đọc DATA.md và LOGIC.md rồi xây server.js
• Hai subagent đầu chạy song song một cách độc lập, subagent thứ ba chỉ bắt đầu sau khi hai báo cáo hoàn tất; tác tử cha quản lý đồ thị phụ thuộc theo cách thủ công
• Giới hạn của subagent: tác tử cha phải tự quản lý đồ thị phụ thuộc, không có nhắn tin ngang hàng hay danh sách tác vụ dùng chung giữa các tác tử; nếu quản lý phạm vi tệp lỏng lẻo thì có thể phát sinh xung đột
• Tổng chi phí ở mức gần như trung lập, khoảng 220 nghìn token

• Subagent phân cấp (team của các team)

  • Thay vì để orchestrator trực tiếp tạo 6 subagent, cấu trúc này tạo 2 feature lead, và mỗi feature lead tự tạo 2–3 chuyên gia của riêng mình
  • Orchestrator cha chỉ quản lý hai tác tử nên giữ ngữ cảnh gọn gàng; feature lead A nhận brief "xây dựng chức năng tìm kiếm" rồi tự phân rã tiếp
  • Đây cũng chính là nguyên lý vận hành của các tổ chức kỹ thuật ngoài thực tế: VP không giao việc trực tiếp cho từng kỹ sư riêng lẻ mà truyền qua tech lead

Mẫu 2: Đội tác tử — thực thi song song thực sự

• Tính năng thử nghiệm của Claude Code, được kích hoạt bằng lệnh export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• Kiến trúc 3 tầng:
  • Team Lead: phân rã công việc, tạo danh sách tác vụ, tổng hợp kết quả
  • Danh sách tác vụ dùng chung: trạng thái (pending, in_progress, completed, blocked)·theo dõi phụ thuộc·khóa tệp
  • Teammates: mỗi người là một phiên bản Claude Code độc lập, có context window riêng, chạy trong các panel tmux được chia nhỏ
• Teammates tự chọn tác vụ từ danh sách dùng chung và giao tiếp trực tiếp bằng nhắn tin ngang hàng, không đi qua lead
• Khi một teammate đánh dấu hoàn thành tác vụ, các tác vụ bị chặn phụ thuộc vào nó sẽ tự động được mở khóa
• Có thể bật/tắt lớp phủ trực quan của danh sách tác vụ bằng Ctrl+T

• Cơ chế cốt lõi của đội tác tử

  • Danh sách tác vụ dùng chung: khi tác tử backend đánh dấu API tìm kiếm là hoàn thành, tác vụ viết test đang bị chặn sẽ tự động chuyển sang trạng thái pending; khóa tệp giúp ngăn chỉnh sửa đồng thời
  • Nhắn tin ngang hàng: tác tử backend chuyển trực tiếp hợp đồng API cho tác tử frontend — "GET /search?q= returns [{id,title,url}]"; tránh để lead trở thành nút thắt điều phối
  • Khi teammate rơi vào trạng thái nhàn rỗi, lead sẽ tự động được thông báo

• Khuyến nghị cốt lõi cho đội tác tử

  • 3~5 teammate là điểm tối ưu; chi phí token tăng tuyến tính theo quy mô đội
  • Phê duyệt kế hoạch: nếu teammate viết kế hoạch trước khi triển khai, lead sẽ xem xét rồi phê duyệt hoặc từ chối; phát hiện vấn đề kiến trúc trước khi có mã rẻ hơn rất nhiều
  • 3 teammate tập trung luôn cho kết quả tốt hơn 5 teammate thiếu tập trung

• Mẹo tăng độ tin cậy cho đội tác tử

  • Loop guardrail + bước phản tư: đặt giới hạn MAX_ITERATIONS=8 cho mọi teammate; trước mỗi lần thử lại, buộc dùng prompt phản tư: "Điều gì đã thất bại? Thay đổi cụ thể nào sẽ giúp sửa lỗi? Có đang lặp lại cùng một cách tiếp cận không?" → giảm mạnh số tác tử bị kẹt
  • Teammate @reviewer chuyên trách: chỉ định Claude Opus 4.6 (chỉ đọc) làm reviewer, chỉ dùng công cụ lint·test·quét bảo mật, tự động kích hoạt ở mỗi sự kiện TaskCompleted; tỷ lệ 1 reviewer cho mỗi 3~4 builder; lead luôn chỉ nhận mã đã được rà soát

Mẫu 3: Điều phối ở quy mô lớn

• Khi quản lý từ 5, 10, 20 tác tử trở lên trên nhiều repo và tính năng, bạn cần công cụ điều phối chuyên dụng
• Tier 1 — Sub-agent·đội nội tiến trình: sub-agent Claude Code·đội tác tử; một phiên terminal duy nhất, không cần công cụ bổ sung; hãy bắt đầu từ đây
• Tier 2 — Orchestrator cục bộ: chạy nhiều tác tử trong các worktree độc lập, vẫn giữ dashboard·review diff·kiểm soát merge; tối ưu cho 3~10 tác tử trong codebase đã quen thuộc; Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents
• Tier 3 — Tác tử bất đồng bộ trên đám mây: giao tác vụ rồi đóng laptop và chờ PR; chạy trên cloud VM; Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, Codex Web by OpenAI
• Đến năm 2026, phần lớn lập trình viên sẽ dùng cả ba tầng: Tier 1 (công việc tương tác), Tier 2 (sprint song song), Tier 3 (xử lý backlog qua đêm)

Tiêu điểm công cụ

• Conductor by Melty Labs

  • Cách nhanh nhất để bắt đầu điều phối đa tác tử trên Mac; chạy song song nhiều tác tử Claude Code·Codex trong các git worktree độc lập
  • Cung cấp dashboard trực quan và giao diện review ưu tiên diff; chỉ tốn chi phí API (miễn phí); chỉ dành cho macOS (Apple Silicon·Intel)
  • Phù hợp nhất khi làm song song 3~8 tính năng trong cùng một repo và cần giám sát trực quan

• Claude Code Web

  • Truy cập tại claude.ai/code; hoàn toàn dựa trên trình duyệt, không cần terminal; kết nối repo GitHub rồi nhập mô tả tác vụ → chạy trên cloud VM do Anthropic quản lý
  • Hỗ trợ điều hướng giữa chừng, tạo PR tự động và truy cập từ ứng dụng iOS
  • Đội (terminal) là cách làm việc cùng tác tử, còn web (trình duyệt) là cách giao việc rồi rời đi

• GitHub Copilot Coding Agent

  • Khác với chế độ Copilot agent trong IDE (đồng bộ·tương tác); Copilot Coding Agent trên GitHub là hoàn toàn bất đồng bộ
  • Gán mọi issue GitHub cho @copilot hoặc khởi chạy từ panel Agents → tạo draft PR trong môi trường GitHub Actions
  • Chạy vòng lặp tự review trước khi được gắn thẻ; cũng có thể truy cập các tác tử bên thứ ba như Claude Code·Codex từ cùng panel; có thể kích hoạt từ Slack, Jira, Linear, Azure Boards

• Jules by Google

  • Tác tử viết mã bất đồng bộ trên đám mây của Google, dựa trên Gemini; kết nối repo GitHub → mô tả tác vụ → Jules tạo kế hoạch → sau khi được phê duyệt sẽ chạy trên cloud VM → trả về PR kèm toàn bộ quá trình suy luận và log terminal
  • Cung cấp changelog bằng âm thanh, dừng tác vụ giữa chừng, và Jules Tools CLI để chuyển trực tiếp GitHub issue vào
  • Tự động đọc AGENTS.md của repo mà không cần cấu hình thêm

• OpenAI Codex Web

  • Mỗi tác vụ chạy trong một container sandbox độc lập với repo GitHub đã được nạp sẵn
  • Có hệ sinh thái bề mặt kết nối Web, CLI (mã nguồn mở), ứng dụng macOS, extension IDE và tích hợp GitHub với tài khoản ChatGPT
  • Tính năng Verifiable Evidence: trả về trích dẫn log terminal và đầu ra test cho mọi tác vụ để có thể kiểm toán lịch sử thực thi

• Cursor Cloud Agents + Glass

  • Có thể khởi chạy tác tử từ web, ứng dụng desktop, Slack, Linear, GitHub, API, PWA (cài tại cursor.com/agents)
  • Glass: giao diện mới của Cursor, biến quản lý tác tử thành màn hình mặc định, còn editor cũ thành công cụ phụ chỉ truy cập khi cần
  • Phản ánh mô hình mà control plane trở thành trải nghiệm chính trong toàn bộ hệ sinh thái, còn editor trở thành một nhạc cụ bên dưới

• Vibe Kanban

  • Giải quyết "khoảng trống doomscrolling" (2~5 phút trống khi tác tử đang làm việc); tạo thẻ tác vụ rồi kéo sang "In Progress" để tạo worktree·branch riêng cho từng thẻ
  • Có thể review diff trong bảng và gửi phản hồi cho tác tử đang chạy; hỗ trợ Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI, v.v.; đa nền tảng (Mac, Windows, Linux), miễn phí, BYOK

Mẹo để mở rộng quy mô

• Định tuyến đa mô hình

  • Không phải mọi tác vụ đều cần mô hình đắt nhất; tạo tệp MODEL_ROUTING.md để định tuyến theo vai trò:
    • Lập kế hoạch·kiến trúc → các mô hình Gemini/Claude/OpenAI giá rẻ hơn
    • Triển khai → Sonnet, Opus hoặc Codex
    • Review → mô hình bảo mật chuyên dụng

• Script vòng đời worktree

  • Tự động hóa công việc lặp lại bằng ba shell alias:
    • agent-spin <feature>: tạo worktree + branch + khởi động tác tử
    • agent-merge <feature>: rebase + review + tạo PR
    • agent-clean: xóa các worktree đã hoàn tất
  • Khoảng 12 dòng bash; Conductor xử lý việc này theo cách trực quan

• Chỉ cho phép AGENTS.md do con người viết

  • Nghiên cứu của ETH Zurich Gloaguen et al. xác nhận rằng tệp AGENTS.md do LLM tạo ra không mang lại lợi ích, đồng thời làm giảm tỷ lệ thành công trung bình khoảng ~3% và tăng chi phí suy luận hơn 20%
  • Tệp ngữ cảnh do lập trình viên viết mang lại cải thiện hiệu năng khoảng ~4%
  • Tuyệt đối không cho phép tác tử ghi trực tiếp vào AGENTS.md; trưởng nhóm phải phê duyệt mọi dòng
  • Giữ nội dung ngắn gọn với các mục rõ ràng: STYLE, GOTCHAS, ARCH_DECISIONS, TEST_STRATEGY

Cổng chất lượng: tin tưởng nhưng phải kiểm chứng

• Ba cổng chất lượng

  • Phê duyệt kế hoạch: thành viên nhóm viết kế hoạch trước khi bắt đầu viết code → trưởng nhóm review·phê duyệt hoặc từ chối → triển khai; chi phí sửa một kế hoạch tệ rẻ hơn rất nhiều so với sửa một đoạn code tệ
  • Hook: các kiểm tra tự động cho sự kiện vòng đời; hook TeammateIdle kiểm tra xem mọi test đã pass trước khi tác tử dừng làm việc hay chưa; hook TaskCompleted chạy lint·test trước khi đánh dấu hoàn tất; nếu hook thất bại thì tác tử tiếp tục làm việc cho đến khi pass
  • Học tích lũy thông qua AGENTS.md: ghi lại các mẫu, lưu ý và sở thích về phong cách đã được phát hiện; mọi tác tử đều đọc khi bắt đầu phiên và được bổ sung sau mỗi phiên

• Nút thắt chuyển sang khâu xác minh

  • Tác tử có thể tạo ra đầu ra ấn tượng với tốc độ đáng kinh ngạc; phần khó là chắc chắn rằng đầu ra đó là chính xác
  • Việc test pass trước thay đổi không đảm bảo sẽ bắt được hồi quy do thay đổi gây ra
  • Tác tử có thể viết các bài test hợp lệ về mặt kỹ thuật nhưng bỏ sót các trường hợp quan trọng
  • Do giới hạn context window, các tác tử làm việc trên codebase lớn có thể bỏ lỡ những ràng buộc quan trọng nằm ngoài phạm vi hiện tại
  • Một môi trường không ổn định vốn chỉ là edge case khó chịu với một lập trình viên, sẽ trở thành blocker mang tính hệ thống khi 40 tác tử cùng lúc gặp phải cùng một bài test flaky
  • Cho đến khi hạ tầng xác minh bắt kịp năng lực tạo sinh, review của con người không phải chi phí tùy chọn mà là hệ thống an toàn

Ralph Loop và tác tử tự cải thiện

• Mẫu Ralph Loop

  • Được Geoffrey Huntley và Ryan Carson phổ biến; là mô thức phía sau “giao hàng khi bạn ngủ”; công cụ độc lập ralph (snarktank/ralph) của Carson triển khai vòng lặp cốt lõi, còn dự án Antfarm bổ sung điều phối đa tác tử trên OpenClaw
  • Chu kỳ 5 bước: Pick(chọn tác vụ tiếp theo từ tasks.json) → Implement(thực hiện thay đổi) → Validate(chạy test·type·lint) → Commit(commit và cập nhật trạng thái tác vụ nếu các kiểm tra pass) → Reset(xóa ngữ cảnh tác tử rồi chuyển sang tác vụ tiếp theo)
  • Insight cốt lõi: reset sau mỗi vòng lặp giúp ngăn tích tụ nhầm lẫn; các tác vụ nhỏ, phạm vi rõ ràng tạo ra ít hallucination hơn và code gọn hơn so với một prompt khổng lồ duy nhất
  • Thiết bị an toàn: đưa lỗi trở lại làm phản hồi để tự động retry, nhưng thoát và gán lại nếu bế tắc quá 3 lần; luôn làm việc trên feature branch; đặt giới hạn cho số vòng lặp, thời gian và token; tác tử tạo PR → con người review trước khi merge
  • Duy trì 4 kênh bộ nhớ giữa các lần reset ngữ cảnh: lịch sử git commit, log tiến độ, tệp trạng thái tác vụ (tasks.json), và AGENTS.md như bộ nhớ ngữ nghĩa dài hạn

• Làm cho tác tử thông minh hơn theo thời gian

  • Tự phản tư qua REFLECTION.md: sau mỗi tác vụ, bắt buộc ghi lại “điều gì gây bất ngờ, một mẫu nên thêm vào AGENTS.md, một cải tiến cho prompt”; trưởng nhóm review và hợp nhất các bài học đã được phê duyệt
  • Ngân sách token và tiêu chí dừng: đặt giới hạn cho từng tác tử (ví dụ: frontend 180 nghìn token, backend 280 nghìn token); tự động tạm dừng ở mức 85% ngân sách và báo cho trưởng nhóm; nếu bế tắc cùng một lỗi quá 3 lần thì dừng và gán lại cho tác tử mới
  • Beads / bộ nhớ bền vững: mẫu “beads” của Gastown — bản ghi bất biến, dựa trên git về mọi quyết định và kết quả cùng đầy đủ nguồn gốc; tác tử tra cứu các bead trong quá khứ qua đồ thị tác vụ và data plane có thể truy vấn bằng SQL; đây là bộ nhớ tổ chức có cấu trúc và truy vấn được, không phải RAG vector đơn giản

Kỷ luật giúp tất cả những điều này vận hành

• Nút thắt của con người hóa ra không phải bug mà là tính năng

  • Khi viết code ở tốc độ con người, bạn cảm nhận nỗi đau sớm; test fail, review code chỉ ra vấn đề, phát hiện trùng lặp — nỗi đau đến ngay lập tức nên bạn sửa trong lúc làm
  • Trong một đội quân tác tử được điều phối, không có nút thắt tự nhiên; những sai sót nhỏ (mùi code, trùng lặp, trừu tượng hóa không cần thiết) sẽ khuếch đại chồng chất với tốc độ không thể đuổi kịp
  • Bạn đã ra khỏi vòng lặp nên sẽ không cảm thấy nỗi đau cho đến khi kiến trúc không còn cho phép thêm tính năng mới
  • Lý do tồn tại của mọi cổng chất lượng (phê duyệt kế hoạch, hook, ngân sách token, review của con người): nếu không có chúng, lập trình bằng tác tử sẽ tự đẩy chính bạn vào ngõ cụt

• Ủy quyền tác vụ nhưng giữ lại phán đoán

  • Những gì nên giao cho tác tử: tác vụ có phạm vi rõ ràng với tiêu chí pass/fail rõ ràng, boilerplate, migration, dựng khung test, khám phá các cách tiếp cận mà bạn không có thời gian tự thử
  • Những gì nên tự giữ: kiến trúc và thiết kế API (tác tử có thể đã học nhiều kiến trúc tệ từ dữ liệu huấn luyện và áp nguyên các mẫu enterprise vào startup), quyết định không xây cái gì (nói No là khả năng mà tác tử không có), review đầu ra của tác tử với ngữ cảnh toàn hệ thống
  • Nếu bạn đánh mất hiểu biết về hệ thống của chính mình, bạn sẽ đánh mất khả năng sửa, mở rộng và phát hiện khi nó hoạt động sai

• Đặc tả là đòn bẩy

  • Khi điều phối song song 50 tác tử, tư duy mơ hồ không chỉ làm chậm tốc độ mà còn khuếch đại trên hàng chục tiến trình chạy song song
  • Sự khác biệt giữa đầu ra tầm thường và đầu ra xuất sắc gần như hoàn toàn phụ thuộc vào chất lượng của đặc tả
  • Đặc tả mơ hồ sẽ khuếch đại lỗi trên toàn bộ đội hình; đặc tả chính xác với kiến trúc rõ ràng, ranh giới tích hợp, edge case và các điều kiện bất biến sẽ được khuếch đại thành triển khai chính xác trên toàn hệ thống
  • Công việc cơ học là gõ code đang được tự động hóa; công việc nhận thức là hiểu hệ thống sẽ được khuếch đại trên toàn bộ đội ngũ worker tự trị

Mô hình nhà máy

• Chúng ta không còn chỉ đơn giản là viết code, mà đang bước vào giai đoạn xây dựng nhà máy tạo ra phần mềm
• Dây chuyền sản xuất 6 bước: Plan(viết đặc tả có tiêu chí chấp nhận) → Spawn(tạo nhóm và phân tác tử) → Monitor(kiểm tra tiến độ mỗi 5~10 phút·gỡ blocker, không hover liên tục) → Verify(chạy test·review code; xác minh là nút thắt) → Integrate(merge branch·giải quyết xung đột) → Retro(cập nhật AGENTS.md với các mẫu mới; học tích lũy)
• Mẹo thực dụng:
  • Đặt giới hạn WIP: đừng chạy nhiều tác tử hơn mức bạn có thể review một cách có ý nghĩa; 3~5 là điểm tối ưu
  • Xác định tiêu chí dừng: nếu bế tắc cùng một lỗi quá 3 lần thì dừng và gán lại
  • Check-in bất đồng bộ: kiểm tra tiến độ mỗi 5~10 phút; để tác tử làm việc tự chủ
  • Một chủ sở hữu cho mỗi tệp: đừng để hai tác tử cùng chỉnh một tệp; xung đột giết chết tốc độ

5 mẫu để bắt đầu ngay hôm nay

1. Phân rã thành các tác tử con: Tạo tác tử con tập trung bằng công cụ Task với brief cụ thể và quyền sở hữu tệp; không cần thiết lập; có thể bắt đầu ngay hôm nay
2. Tính song song với đội tác tử: Bật CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1; tạo 1 người dẫn dắt + 3 thành viên; điều phối bằng danh sách tác vụ dùng chung
3. Cô lập bằng Git worktree: Cung cấp worktree riêng cho từng tác tử; không có xung đột hợp nhất; Conductor tự động xử lý
4. Cổng chất lượng để tạo niềm tin: Yêu cầu phê duyệt kế hoạch cho các thay đổi rủi ro; thêm hook chạy kiểm thử khi tác vụ hoàn tất; không tin đầu ra của tác tử nếu chưa được xác minh
5. Học tích lũy bằng AGENTS.md: Ghi lại các mẫu, lưu ý và sở thích về phong cách; mỗi phiên đều đọc và cập nhật; tri thức được khuếch đại theo cấp số nhân

[kurthong]

Không rõ đây có phải là đặc tính của các kỹ sư không, nhưng tôi không hiểu vì sao họ lại có thể dài dòng kể lể những điều nghe có vẻ hợp lý mà thiếu chiều sâu như vậy. Tôi cũng quan tâm đến chủ đề này nên đã đọc kỹ, nhưng chẳng có nội dung gì đáng giá.

[stroke33]

Lý do tối thượng để dùng Claude Code hăng hái - tự dựng dàn điều phối đa tác nhân của riêng mình

Hiện mình đang vận hành 5 tác nhân, nhưng token bay quá nhanh nên chỉ biết khóc ròng.