"Tôi đang dùng Claude Code, nhưng khi quy mô tăng lên, ngữ cảnh bị tràn và độ chính xác giảm."
"Cuối cùng, chính tay tôi đưa ra các chỉ thị sửa lỗi cho AI lại trở thành nút thắt lớn nhất."
Nhiều người có lẽ đang mắc kẹt ở điểm này. Lúc đầu tôi cũng vậy, ném code, kiểm thử và thảo luận thiết kế vào cùng một phiên, rồi chứng kiến độ chính xác của Claude giảm dần khi lịch sử hội thoại dài ra.
Điều tôi nhận ra gần đây là bản thân Claude Code chính thức cung cấp ba cơ chế để chạy nhiều phiên song song.
Hơn nữa, ba cơ chế này tương tự nhưng lại khác biệt; nhầm lẫn chúng có thể dẫn đến sự cố. Ngược lại, nếu bạn phân chia chúng theo vai trò, bạn có thể chuyển sang "phe chỉ huy" mà không cần tự mình viết một dòng code nào.
Hôm nay, tôi sẽ hệ thống hóa ba cơ chế này và cách đúng đắn để cố định ranh giới vai trò, đồng thời kiểm tra thông tin chính thống từ tài liệu chính thức.
Cụ thể, tôi sẽ chia nhỏ thành một cấu hình gồm 8 phiên được đặt trên ba lớp: Chỉ huy, Triển khai và Chất lượng.
Như một phần thưởng, tôi cũng sẽ sử dụng thông tin chính thống để giải thích tại sao các giải thích phổ biến như "viết ID vai trò trong CLAUDE.md để chuyển đổi" hay "chia sẻ bộ nhớ với SQLite" lại hơi lệch so với cơ chế chính thức.
Tôi là tatsuki (@nobel_824).
Tôi hỗ trợ ứng dụng AI cho các doanh nghiệp vừa và nhỏ, giúp triển khai Claude / Codex vào kinh doanh trong khi tự mình chạy Claude Code cả ngày. Vận hành song song là lĩnh vực tôi chạm tới hàng ngày cho cả công việc lẫn dự án cá nhân.
Bài viết liên quan: Giới thiệu Vibe Coding: 6 Bước cho Người Không Chuyên Xây Dựng Ứng Dụng với Claude. Kỷ Nguyên Tự Làm Trong Một Cuối Tuần
https://note.com/nobel/n/n8192ec07d689
1. Tại Sao "Nhồi Nhét Mọi Thứ Vào Một Phiên" Lại Thất Bại
Cái bẫy đầu tiên là làm quá tải một phiên duy nhất với quá nhiều thông tin. Dù mô hình Claude có thông minh đến đâu, nó cũng chạm phải các giới hạn về cấu trúc.
Cụ thể, bạn gặp phải ba vấn đề sau:
- Nhiễm Ngữ Cảnh: Khi code triển khai, kiểm thử, lịch sử gỡ lỗi và thảo luận thiết kế trộn lẫn trong cùng một ngữ cảnh, nền tảng lập luận trở nên mơ hồ và độ chính xác giảm.
- Xung Đột Chỉ Thị: Nếu "triển khai ưu tiên tốc độ" và "nghiêm ngặt về bảo mật" cùng tồn tại trong một chỗ, các phán đoán sẽ trở nên nửa vời.
- Phình Token: Tải một lịch sử khổng lồ mỗi lần là sự lãng phí cả về thời gian lẫn chi phí.
Giải pháp là ý tưởng "trở thành một chỉ huy duy nhất và xếp hàng các Claude chuyên biệt." Nó tương tự như việc một CTO có một Tech Lead và Backend Lead, nhưng điều quan trọng không phải là cảm tính—mà là tận dụng đúng đắn các cơ chế chính thức của Claude Code.
Một hành động bạn có thể thực hiện hôm nay: Hãy nghĩ về phiên làm việc hiện tại của bạn và kiểm tra xem "triển khai," "nghiên cứu" và "đánh giá" có đang cùng tồn tại trong một ngữ cảnh hay không. Nếu có, đó là điểm khởi đầu để bạn tách chúng ra.
2. Sửa Lại "Ba Cơ Chế Song Song" Được Cung Cấp Chính Thức
Đây là phần cốt lõi của bài viết. Claude Code có ba cơ chế cho tính song song, mỗi cơ chế có phạm vi khác nhau.
Cơ chế đầu tiên là subagent (một AI trợ lý chạy trong ngữ cảnh riêng biệt với hội thoại chính). Nó thực thi các tác vụ phụ như nghiên cứu hoặc đánh giá bằng cách sử dụng cửa sổ ngữ cảnh của riêng nó, hệ thống prompt chuyên dụng và quyền truy cập công cụ giới hạn, chỉ trả về một bản tóm tắt kết quả cho phiên chính. Điểm mấu chốt là subagent chạy trong cùng một phiên, chỉ báo cáo cho phiên chính, và các subagent không nói chuyện với nhau (Tài liệu chính thức).
Cơ chế thứ hai là agent teams (cơ chế nơi nhiều phiên Claude Code cộng tác như một nhóm). Một phiên trở thành trưởng nhóm và sinh ra các đồng đội, cộng tác qua một danh sách tác vụ và hộp thư chung. Không giống như subagent, các đồng đội có thể gửi tin nhắn trực tiếp cho nhau. Đây là tính năng thử nghiệm và bị tắt theo mặc định. Bạn cần đặt CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 và sử dụng Claude Code v2.1.32 trở lên (Tài liệu chính thức).
Cơ chế thứ ba là git worktree (một tính năng Git cho phép nhiều thư mục làm việc từ cùng một kho lưu trữ). Bằng cách khởi động với claude --worktree feature-auth, Claude khởi chạy trong một môi trường cô lập trên một nhánh/thư mục khác. Nếu bạn chạy một phiên khác trong một terminal khác, chúng có thể chạy song song mà không can thiệp vào file của nhau (Tài liệu chính thức). Khi sử dụng ứng dụng desktop, một worktree được tự động tạo cho mỗi phiên mới.
Dưới đây là bảng so sánh ba cơ chế:
Bạn sẽ không bị nhầm lẫn nếu nhớ rằng worktree xử lý việc cô lập file, trong khi subagent và agent teams xử lý việc điều phối bản thân công việc.
Một hành động bạn có thể thực hiện hôm nay: Đầu tiên, hãy thử gõ claude --worktree bugfix-test để cảm nhận việc khởi chạy một phiên cô lập. Khi bạn hoàn thành sau khi thực hiện thay đổi, nó sẽ hỏi bạn có muốn giữ lại hay xóa worktree.
3. Thực Hành: Triển Khai 8 Phiên Trong "Cấu Trúc 3 Lớp"
Ba cơ chế này chuyển hóa thành 8 phiên như thế nào? Tôi sử dụng một bố cục chia thành các lớp Chỉ huy, Triển khai và Chất lượng.
Lớp Chỉ huy/Thiết kế (2 Phiên)
- Phiên 1 PM (Quản lý dự án): Quản lý tiến độ tổng thể, phân chia tác vụ, báo cáo cho con người.
- Phiên 2 Kiến trúc sư: Quyết định tính nhất quán về kỹ thuật và cấu trúc thư mục. Yêu cầu phê duyệt kế hoạch để tạo ra các thiết kế mà không cần viết code.
Lớp Triển khai/Thực thi (4 Phiên)
- Phiên 3 Frontend: Tạo component, điều chỉnh giao diện người dùng.
- Phiên 4 Backend: Triển khai endpoint, tối ưu hóa truy vấn.
- Phiên 5 Hạ tầng/DevOps: Docker, bảo trì CI/CD.
- Phiên 6 Bảo mật: Kiểm tra lỗ hổng, củng cố xác thực.
Lớp Chất lượng/Bảo trì (2 Phiên)
- Phiên 7 QA/Người đánh giá: Đánh giá PR, chỉ ra các trường hợp ngoại lệ.
- Phiên 8 Người viết tài liệu kỹ thuật: Bảo trì README, tài liệu API.
Có ba mẹo cho bố cục này: Cô lập bốn phiên ở lớp triển khai bằng worktrees để chúng không can thiệp vào file của nhau. Cố định vai trò cho lớp chất lượng dưới dạng định nghĩa subagent hoặc đồng đội trong agent team. Và yêu cầu mỗi phiên chuyển tiếp thông tin qua các file Markdown dùng chung (ghi chú thiết kế hoặc kết quả đánh giá). Kiến trúc sư cập nhật thiết kế, lớp triển khai làm việc dựa trên đó, và Người đánh giá viết lại kết quả. Con người chỉ cần đưa ra chỉ thị cho từng phiên khi được kích hoạt bởi các bản cập nhật file này.
Một lưu ý: Hướng dẫn chính thức cho một agent team là 3–5 người, vì vậy đừng nhồi nhét cả 8 người vào một nhóm cùng lúc (Tài liệu chính thức). Sẽ an toàn hơn nếu kết hợp các phiên được cô lập bằng worktree với một agent team 3–5 người và các subagent khi cần để đạt tổng cộng 8 công nhân.
Một hành động bạn có thể thực hiện hôm nay: Chọn hai vai trò trong số 8 vai trò trên mà bạn thấy dễ tách ra trong dự án hiện tại của mình. Trong nhiều trường hợp, Kiến trúc sư và Người đánh giá là những điểm phân chia đầu tiên.
4. Cố Định Ranh Giới Vai Trò với "Định Nghĩa Subagent," Không Phải "CLAUDE.md"
Hãy để tôi sửa một hiểu lầm phổ biến về vận hành song song. Bạn có thể thấy các giải thích như "Viết vai trò (ID: arch, ID: dev-main...) trong CLAUDE.md và chuyển đổi tính cách khi khởi động," nhưng cơ chế này thực sự không tồn tại.
CLAUDE.md là một file hướng dẫn dùng chung mà Claude Code đọc khi khởi động. Tuy nhiên, tài liệu chính thức nói rõ rằng CLAUDE.md là "ngữ cảnh, không phải một thiết lập bắt buộc." Vì nó được truyền dưới dạng một tin nhắn người dùng sau system prompt, nên việc tuân thủ nghiêm ngặt không được đảm bảo. Nếu bạn thực sự muốn ngăn chặn điều gì đó, bạn nên sử dụng hooks (Tài liệu chính thức). Hãy coi nó như một khuyến nghị mạnh mẽ hơn là một "hiến pháp" tuyệt đối.
Vậy bạn cố định vai trò ở đâu? Câu trả lời là định nghĩa subagent. Bằng cách đặt một file trong .claude/agents/ với tên, mô tả, các công cụ khả dụng và mô hình trong phần frontmatter, bạn đã hoàn thành một chuyên gia có thể tái sử dụng. Dưới đây là một ví dụ tối thiểu:
name: security-reviewer
description: Đánh giá code một cách phê phán từ góc độ xác thực, xác thực đầu vào và quản lý phiên.
tools: Read, Grep, Bash
model: sonnet
Bạn là một người đánh giá bảo mật cấp cao. Tập trung vào xử lý token,
quản lý phiên và xác thực đầu vào, đồng thời báo cáo các phát hiện với mức độ nghiêm trọng.
Hơn nữa, các định nghĩa này có thể được gọi bằng tên như các đồng đội trong agent team. Nếu bạn yêu cầu "thiết lập một đồng đội với loại agent security-reviewer để kiểm tra module xác thực," nó sẽ trở thành một thành viên kế thừa các công cụ và mô hình từ định nghĩa đó (Tài liệu chính thức). Thiết kế này cho phép bạn viết một vai trò một lần dưới dạng định nghĩa subagent và tái sử dụng nó như cả subagent lẫn thành viên nhóm.
Ví dụ prompt để thử (yêu cầu Claude tạo định nghĩa vai trò):
Tạo một định nghĩa subagent để đặt trong .claude/agents/.
Vai trò là "người đánh giá chỉ ra các vấn đề về hiệu năng và truy vấn N+1 trong code triển khai."
Bao gồm name / description / tools / model trong phần frontmatter,
và viết phần thân dưới tính cách của một kỹ sư cấp cao.
5. Xây Dựng Một Nhóm "Kiến Trúc Sư-Người Đánh Giá" với Agent Teams để Tăng Độ Chính Xác
Một cấu hình rất hiệu quả trong vận hành song song là thiết lập riêng một "người tạo" và một "người nghi ngờ." Điều này không chỉ là lý thuyết; tài liệu chính thức cung cấp các ví dụ thực tế.
Trong ví dụ "Đánh giá code song song" chính thức, cho một PR, ba đồng đội được thiết lập cho bảo mật, hiệu năng và phạm vi kiểm thử, mỗi người nhìn từ một góc độ khác nhau trong khi trưởng nhóm tích hợp kết quả. Hơn nữa, trong ví dụ "Các giả thuyết cạnh tranh," năm đồng đội được gán các giả thuyết khác nhau cho một lỗi để tranh luận và bác bỏ lý thuyết của nhau, coi lý thuyết sống sót là nguyên nhân gốc rễ (Tài liệu chính thức). Vì một nhà điều tra duy nhất có xu hướng bị kéo về lý thuyết đầu tiên, cách tiếp cận này cố tình tạo ra xung đột để cải thiện độ chính xác.
Bạn cũng có thể triển khai một hoạt động nơi Kiến trúc sư "không được cấp quyền viết code" bằng cách sử dụng các tính năng chính thức. Bằng cách yêu cầu phê duyệt kế hoạch cho một đồng đội, đồng đội đó ở trong chế độ kế hoạch chỉ đọc, chỉ tạo ra các thiết kế cho đến khi trưởng nhóm phê duyệt. Tiêu chí phê duyệt có thể được viết trong prompt của trưởng nhóm, chẳng hạn như "chỉ phê duyệt các kế hoạch bao gồm phạm vi kiểm thử."
Ví dụ prompt để thử (thiết lập cấu trúc xung đột trong một lần):
Tạo một agent team để đánh giá PR #142. Thiết lập ba đồng đội:
một cho bảo mật, một cho hiệu năng và một cho phạm vi kiểm thử.
Yêu cầu họ đánh giá độc lập và xuất ra các phát hiện với mức độ nghiêm trọng, sau đó tích hợp chúng ở cuối.
Có hai chế độ hiển thị: in-process (tất cả đồng đội chạy trong cùng một terminal, chuyển đổi bằng Shift+Mũi tên xuống) và split panes (mỗi đồng đội trong một khung riêng; yêu cầu tmux hoặc iTerm2). Sẽ dễ dàng hơn khi bắt đầu với in-process vì nó không yêu cầu thiết lập thêm.
6. Chia Sẻ Bộ Nhớ qua Auto Memory Chính Thức (Markdown), Không Phải "SQLite"
Khi chạy nhiều phiên, rào cản tiếp theo là "chia sẻ bộ nhớ giữa các phiên." Mặc dù các kỹ thuật nâng cao như "lưu trữ bộ nhớ có gắn thẻ trong SQLite và chèn động vào" đôi khi được giới thiệu, đó không phải là một tính năng tiêu chuẩn của Claude Code. Điều đó có thể thực hiện được nếu bạn xây dựng một cơ sở dữ liệu qua MCP (Giao thức ngữ cảnh mô hình), nhưng bạn nên phân biệt điều đó với cơ chế bộ nhớ được cung cấp chính thức.
Auto memory chính thức hoạt động với các file markdown. Bên trong ~/.claude/projects/<project>/memory/, các file như MEMORY.md (chỉ mục) và các file theo chủ đề cụ thể như debugging.md được đặt, và Claude ghi vào chúng khi nó làm việc. Các quy tắc tải rất rõ ràng: mọi phiên đọc tối đa 200 dòng hoặc 25KB đầu tiên của MEMORY.md, và Claude chỉ đọc các file theo chủ đề khi cần thiết. Tính năng này có sẵn từ Claude Code v2.1.59, được lưu theo từng kho lưu trữ (do đó được chia sẻ giữa các worktree) và được lưu trữ cục bộ (Tài liệu chính thức).
Vẻ đẹp của thiết kế này là bằng cách "luôn tải chỉ mục và chỉ tìm nạp chi tiết khi cần," bạn có thể giữ cho cửa sổ ngữ cảnh sạch sẽ. Ngay cả với hàng ngàn quy tắc nhỏ, ngữ cảnh sẽ không bị nhiễm mỗi lần miễn là chỉ mục không bị phình.
Về thứ tự, hãy sử dụng auto memory dựa trên markdown chính thức hết mức trước khi cố gắng xây dựng một giải pháp SQLite tùy chỉnh.
Một hành động bạn có thể thực hiện hôm nay: Gõ /memory trong một phiên sẽ hiển thị danh sách các file CLAUDE.md và auto memory hiện đang được tải. Đầu tiên, hãy xem qua vị trí và số lượng bộ nhớ bạn có.
7. Ba Cạm Bẫy Trong Vận Hành Song Song (Chi Phí, Cơ Sở Dữ Liệu, Quyền Hạn)
Bây giờ bạn đã hiểu cơ chế, đây là ba điểm cần thận trọng khi vận hành.
Đầu tiên là chi phí token. Tài liệu chính thức nêu rõ rằng vì mỗi đồng đội trong một agent team có một ngữ cảnh độc lập, việc sử dụng token tăng tỷ lệ thuận với số lượng người. Sử dụng 5 người cho các tác vụ thường ngày sẽ dẫn đến lỗ chi phí. Đó là lý do tại sao khuyến nghị chính thức là 3–5 người, lưu ý rằng "ba thành viên tập trung thường đánh bại năm thành viên mất tập trung" (Tài liệu chính thức).
Thứ hai là phạm vi cô lập của worktrees. Một worktree chỉ là một cơ chế Git để phân tách file; cơ sở dữ liệu, biến môi trường và các dịch vụ đang chạy vẫn được chia sẻ. Nếu hai phiên chạy migration trên cùng một cơ sở dữ liệu cục bộ, nó sẽ bị hỏng. Tài liệu chính thức cảnh báo "hãy nhớ khởi tạo môi trường phát triển (cài đặt phụ thuộc, thiết lập môi trường ảo) trong mỗi worktree," và nếu các tác vụ chạm vào cơ sở dữ liệu, bạn cần tách biệt schema, container Docker hoặc file .env (Tài liệu chính thức).
Thứ ba là quyền hạn. Các đồng đội kế thừa cài đặt quyền của trưởng nhóm khi được sinh ra. Nếu bạn chạy trưởng nhóm với --dangerously-skip-permissions, tất cả các đồng đội cũng sẽ ở cùng trạng thái không được xác nhận đó. Vì tác động của một sự cố lan rộng song song, sẽ an toàn hơn nếu hạn chế quyền ở phía trưởng nhóm.
8. Câu Hỏi Thường Gặp cho Người Dùng Trung Cấp: Số Lượng Người, Mở Rộng và Cổng Chất Lượng
Cuối cùng, một số câu trả lời bổ sung cho các câu hỏi phổ biến.
H. Có bao nhiêu phiên là thực tế?
Một hướng dẫn tốt là cấu trúc 3 lớp, 8 phiên đã đề cập trước đó. Mấu chốt không phải là nhồi nhét 8 người vào một agent team, mà là sử dụng một nhóm 3–5 người làm nòng cốt và thêm vào các phiên worktree hoặc subagent. Điều này phù hợp với các khuyến nghị chính thức (3–5 người mỗi nhóm, 5–6 tác vụ mỗi đồng đội). Giới hạn cuối cùng là phạm vi bạn có thể giám sát và chỉ đạo. Nếu bạn tăng số lượng vượt quá khả năng chỉ huy, hiệu quả sẽ giảm.
H. Nếu tôi phát triển vượt quá subagent và agent teams thì sao?
Nếu bạn muốn giám sát một số lượng lớn các phiên độc lập từ một nơi duy nhất, trang subagents chính thức đề cập đến một cơ chế gọi là background agents. Hãy nghĩ về nó theo lớp: subagent để trợ giúp trong một phiên, agent teams cho một nhóm song song kiểu hội thoại và background agents để quản lý nhiều phiên độc lập.
H. Làm thế nào tôi có thể đảm bảo chất lượng?
Các khuyến nghị trong CLAUDE.md chỉ là "các hướng dẫn dễ làm theo." Đối với các kiểm tra bạn thực sự muốn thực thi, hãy ép buộc chúng bằng hooks. Agent teams có các hook như TeammateIdle, TaskCreated và TaskCompleted; trả về mã thoát 2 sẽ gửi phản hồi và buộc công việc phải tiếp tục (Tài liệu chính thức). Điều này có nghĩa là bạn có thể thực thi theo chương trình các quy tắc như "không hoàn thành cho đến khi các bài kiểm tra đều xanh."
Tóm Tắt: Từ Người Giám Sát Đến Người Thiết Kế/Ủy Quyền
Giá trị của Claude Code nằm nhiều hơn ở khả năng một người điều khiển nhiều Claude chuyên biệt hơn là chỉ viết code nhanh hơn. Dưới đây là các điểm chính:
Đừng nhầm lẫn ba cơ chế: subagent trả về kết quả, agent teams là các nhóm hội thoại và worktree cô lập file. Chia 8 phiên thành các lớp Chỉ huy, Triển khai và Chất lượng; cô lập triển khai bằng worktree và cố định vai trò chất lượng bằng định nghĩa subagent hoặc agent teams. Cố định ranh giới vai trò trong định nghĩa subagent thay vì CLAUDE.md và thực thi các quy tắc tuyệt đối bằng hooks. Tổ chức auto memory dựa trên markdown chính thức trước khi xây dựng giải pháp SQLite tùy chỉnh. Nhắm tới 3–5 người mỗi nhóm và xây dựng lên đến 8 công nhân bằng cách thêm các lớp.
3 bước để thử bắt đầu từ hôm nay:
- [ ] Gõ
claude --worktree test-1để cảm nhận việc khởi chạy một phiên cô lập. - [ ] Viết một định nghĩa subagent cho vai trò "người đánh giá" trong
.claude/agents/và yêu cầu nó đánh giá code triển khai của bạn. - [ ] Đặt
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1và thử chạy một PR review song song với ba đồng đội.
Thời gian bạn từng dành để liên tục gõ các chỉ thị sửa lỗi trong một phiên duy nhất sẽ chuyển thành thời gian dành cho việc thiết kế và ủy quyền vai trò. Quyết định nên buông bỏ điều gì và giám sát điều gì là công việc mang tính con người nhất còn lại trong vận hành song song.
Liên Kết Tham Khảo (Nguồn Chính Thức)
- Tạo subagent tùy chỉnh
- Điều phối các nhóm phiên Claude Code
- Chạy các phiên song song với worktrees
- Cách Claude ghi nhớ dự án của bạn / CLAUDE.md và auto memory
Tôi dự định chia sẻ thông tin hữu ích mà tôi không thể đăng trên X trong Open Chat này. Nếu bạn quan tâm, hãy tham gia ngay.
