Từ một đơn hàng giao trễ đến cách tổ chức subagents: tách ngữ cảnh, giới hạn quyền và bàn giao kết quả có thể kiểm tra.
Hãy hình dung một doanh nghiệp phân phối đang sửa cổng đặt hàng cho đại lý. Đây là tình huống giả định, nhưng cái khó thì rất quen.
Đội kinh doanh muốn khách nhìn thấy ngày giao dự kiến. Bộ phận kho nhắc rằng đơn thiếu hàng phải chờ bổ sung. Đội kỹ thuật cần sửa giao diện, cập nhật luồng xử lý và kiểm tra xem thay đổi có làm hỏng đơn hàng cũ hay không.
Một người mở AI lên, gửi tất cả vào cùng một cuộc trò chuyện. Yêu cầu nối tiếp yêu cầu; mã nguồn, nhật ký lỗi và các phương án thiết kế dồn vào một chỗ. Đến lúc kiểm tra, AI vẫn trả lời rất trôi chảy, nhưng lại bỏ qua điều quan trọng: ngày giao dự kiến không phải lời hứa giao hàng khi kho chưa xác nhận đủ hàng.
Phản ứng dễ nhất là viết thêm một prompt thật dài. Nhưng thử nhìn bài toán như người điều hành: liệu ta đang thiếu một lời nhắc tốt hơn, hay đang giao quá nhiều vai cho cùng một người?
Đó là điểm xuất phát hữu ích để hiểu subagents — các tác nhân AI chuyên trách nhận phần việc được giao từ tác nhân chính. Không phải nhân bản một trợ lý rồi hy vọng đông hơn sẽ giỏi hơn. Đó là thiết kế cách phân công, phối hợp và nghiệm thu.
1. Đừng tuyển thêm AI trước khi chia rõ việc
Trong Claude Code, subagent có ngữ cảnh, chỉ dẫn và bộ công cụ riêng. Tác nhân chính dùng mô tả để chọn vai, giao việc và nhận kết quả. Xem tài liệu chính thức về subagents.
Với cổng đặt hàng, tôi sẽ bắt đầu bằng một tác nhân chính giữ mục tiêu chung, không phải một đội AI đông ngay từ đầu. Khi cần chuyên môn riêng, nó có thể giao những phần việc như sau:
Ba vai là ba góc nhìn, không phải ba bên cùng được phép sửa mọi thứ. Người điều phối vẫn phải đối chiếu các kết quả, xử lý mâu thuẫn và chuyển quyết định quan trọng cho người phụ trách.
Nếu muốn nhìn rộng hơn về trách nhiệm điều phối, bạn có thể đọc tiếp Đội AI đông chưa chắc làm việc tốt: ai đang giữ nhịp?.
Điểm mấu chốt nằm ở ranh giới trách nhiệm. “Chuyên gia AI xuất sắc” là một danh xưng. “Đọc thay đổi của luồng đặt hàng, tìm nhánh có thể báo ngày giao khi chưa đủ hàng, không sửa tệp” mới là nhiệm vụ có thể đánh giá.
Một mục tiêu chung, những vai chuyên trách và đầu ra riêng: tổ chức đội AI trước khi tăng số lượng AI.
2. Ngữ cảnh riêng giống một bàn làm việc riêng, không phải trí nhớ chung
Hãy tưởng tượng người phụ trách kho được giao một phiếu kiểm tra. Họ không cần đọc toàn bộ nhóm chat của đội bán hàng để xác nhận một đơn còn thiếu hàng gì. Nhưng phiếu kiểm tra phải ghi đủ mã đơn, mặt hàng và điều kiện xử lý.
Giao việc cho subagent cũng nên theo tinh thần đó: không bê cả cuộc trò chuyện sang, nhưng không cắt mất điều kiện quyết định kết quả.
Trong ví dụ này, một phiếu giao việc có thể viết:
Rà soát phần thay đổi hiển thị ngày giao dự kiến. Phạm vi: các tệp được liệt kê trong bản thay đổi và những nơi sử dụng chúng. Quy tắc: đơn chưa đủ hàng phải thể hiện trạng thái chờ bổ sung, không hiển thị thông điệp xác nhận giao hàng. Chỉ đọc, không sửa. Trả về từng phát hiện với vị trí, tình huống gây lỗi, tác động và cách kiểm chứng. Nếu chưa đủ bằng chứng, ghi rõ phần cần người phụ trách xác nhận.
Nếu quên quy tắc “chưa đủ hàng”, tác nhân chuyên trách có thể rà soát rất chăm chỉ mà vẫn kiểm tra sai bài toán. Cách ly ngữ cảnh giúp giảm thông tin không cần thiết; nó không bù được một lần bàn giao thiếu thông tin.
Ngữ cảnh riêng không có nghĩa là không nhận chỉ dẫn dự án hoặc không đọc dữ liệu qua công cụ. Subagent thông thường không kế thừa hội thoại; chế độ fork thì có. Hãy kiểm tra cơ chế đang dùng trong tài liệu quản lý ngữ cảnh subagents.
Tôi dùng một câu hỏi để thử chất lượng phiếu giao việc: nếu một người mới chỉ đọc phiếu này, họ có biết thế nào là làm đúng không? Nếu câu trả lời là chưa, thêm agent chỉ nhân rộng sự mơ hồ.
3. Trao công cụ như trao chìa khóa kho
Một người đến kiểm kê không mặc nhiên được quyền xuất hàng. Tương tự, tác nhân rà soát mã nguồn không nhất thiết cần quyền sửa tệp, chạy mọi lệnh hoặc truy cập hệ thống đang vận hành.
Đừng chỉ ghi “không được sửa” trong prompt rồi vẫn cấp tất cả công cụ. Chỉ dẫn nói điều nên làm; cấu hình quyền giới hạn điều có thể làm. Hai lớp này phải đi cùng nhau.
Theo hướng dẫn cấu hình, định nghĩa dùng chung cho dự án có thể đặt tại .claude/agents/order-flow-reviewer.md. Mẫu chỉ đọc dưới đây minh họa một vai hẹp, không thay thế thiết kế bảo mật:
```yaml
name: order-flow-reviewer
description: Rà soát thay đổi luồng đặt hàng trước khi tích hợp.
tools: Read, Grep, Glob
Chỉ rà soát, không chỉnh sửa.
Đối chiếu thay đổi với quy tắc nghiệp vụ trong phiếu giao việc.
Mỗi phát hiện phải có vị trí, tình huống lỗi và tác động.
Tách phần có bằng chứng khỏi phần cần xác nhận.
Nếu thiếu thông tin, trả câu hỏi cụ thể; không tự đặt quy tắc.
```
Ở đây, description là nhãn giúp người điều phối chọn đúng vai. Phần chỉ dẫn bên dưới là cách vai đó thực hiện công việc. Nhãn nên ngắn và rõ; tiêu chí xử lý, cách báo cáo và điều kiện dừng nên nằm trong chỉ dẫn thực thi.
Danh sách công cụ chỉ đọc cũng không tự động giới hạn subagent vào vài tệp được nêu trong prompt. Nếu có dữ liệu nhạy cảm, đội kỹ thuật cần kiểm soát thêm phạm vi truy cập và môi trường chạy. Tách ngữ cảnh không đồng nghĩa với cách ly hệ thống tệp.
Vì vậy, đừng vội cài một định nghĩa agent tải từ nguồn chưa tin cậy. Hãy đọc cả mô tả, chỉ dẫn và quyền công cụ trước khi dùng. Một “vai chuyên gia” vẫn có thể chứa yêu cầu ngoài phạm vi mà doanh nghiệp định giao.
Góc nhìn này có thể đặt cạnh bốn lớp kiểm soát trước khi AI agent hành động: phân quyền là một phần của quy trình kiểm soát, không phải toàn bộ quy trình.
4. “Đã xong” chưa phải một lần bàn giao
Giả sử tác nhân thiết kế kiểm thử trả lời: “Tôi đã xây dựng bộ kiểm thử đầy đủ cho luồng đặt hàng.” Nghe rất yên tâm. Nhưng người điều phối vẫn chưa biết bộ kiểm thử nằm ở đâu, đã chạy chưa, hay “đầy đủ” được hiểu theo tiêu chí nào.
Đây là khác biệt giữa báo cáo hoạt động và bàn giao sản phẩm công việc.
Với ví dụ đang xét, tôi muốn nhận được ít nhất những thông tin sau:
Đầu ra cụ thể: nội dung ca kiểm thử hoặc đường dẫn tệp đã tạo, nếu vai đó có quyền tạo tệp.
Dấu vết kiểm chứng: đã chạy kiểm thử nào, kết quả ra sao; nếu chưa chạy thì nói rõ chưa chạy.
Điểm chưa giải quyết: trường hợp thiếu hàng một phần còn cần kho xác nhận cách xử lý hay không.
Đề xuất bước tiếp theo: có thể chuyển sang rà soát, cần sửa lại hay phải hỏi người phụ trách nghiệp vụ.
Một bản bàn giao có ích có thể ngắn như thế này:
Có ba tình huống: đủ hàng, thiếu toàn bộ, thiếu một phần. Đã soạn ca kiểm thử cho hai tình huống đầu; chưa chạy. Tình huống thiếu một phần chưa có quy tắc về tách giao hàng. Cần người phụ trách kho xác nhận trước khi chốt kết quả mong đợi.
Nó ít hào nhoáng hơn lời tuyên bố “hoàn tất”, nhưng giúp người nhận biết chính xác việc đang ở đâu. Kết quả gọn không có nghĩa là mất bằng chứng.
Mỗi lần bàn giao phải chuyển được cả kết quả lẫn trạng thái kiểm chứng. Thiếu bằng chứng thì chưa qua bước nghiệm thu.
Nếu subagent được giao tạo sơ đồ, hãy yêu cầu mã sơ đồ hoặc tệp có thể mở được, không chỉ một đoạn mô tả sơ đồ. Nếu được giao rà soát, yêu cầu phát hiện có vị trí và cách kiểm tra, không chỉ nhận xét chung rằng mã nguồn “ổn”.
5. Chạy song song khi việc độc lập, không phải vì AI có thể chạy song song
Khi đã có một bản thay đổi ổn định, tác nhân rà soát nghiệp vụ và tác nhân rà soát mã nguồn có thể xem cùng một phiên bản theo hai góc nhìn khác nhau. Đó là ứng viên hợp lý cho xử lý song song.
Phiếu giao việc nên nói rõ: “Rà soát song song trên cùng phiên bản; mỗi vai chỉ đọc và trả kết quả riêng.” Đừng chỉ yêu cầu “tạo hai agent” rồi mặc định chúng sẽ chạy đồng thời.
Ngược lại, nếu ca kiểm thử phụ thuộc vào quy tắc tách giao hàng chưa được chốt, chạy tác nhân kiểm thử thật nhanh cũng chỉ tạo ra giả định thật nhanh. Nó cần kết quả của bước trước.
Tôi sẽ chọn cách tổ chức theo bảng sau:
Đặc biệt, cửa sổ ngữ cảnh riêng không ngăn hai tác nhân sửa cùng một tệp trong kho mã dùng chung. Nếu muốn so sánh các cách triển khai, hãy cho mỗi cách một nhánh hoặc worktree riêng, cùng yêu cầu và cùng tiêu chí đánh giá. Người phụ trách chọn phương án sau khi kiểm chứng; đừng ghép tất cả chỉ vì chúng đều đã được tạo ra.
Chọn cách phối hợp theo quan hệ phụ thuộc của công việc. Song song là một lựa chọn thiết kế, không phải thước đo trưởng thành.
Thêm subagents cũng thêm lượt xử lý, chi phí và công việc tổng hợp. Ngữ cảnh chính gọn hơn không có nghĩa tổng token giảm. Muốn biết cách tổ chức mới có đáng dùng, phải tính đến chi phí cho một đầu ra được chấp nhận, chứ không chỉ thời gian từng agent trả lời.
Nếu chưa rõ công việc nên tách thế nào, hãy quay về câu hỏi trong bài Trước khi thêm AI agent, hãy chốt bản vẽ.
6. Thử một vai hẹp trước khi mở rộng cả đội
Quay lại cổng đặt hàng. Thay vì tự động hóa toàn bộ từ yêu cầu đến triển khai, đội có thể thử một subagent chỉ đọc, chuyên tìm những chỗ hiển thị ngày giao trái với quy tắc đã chốt.
Một vòng thử nghiệm nhỏ nên có năm bước:
Chốt một lỗi đáng tìm. Ví dụ: đơn thiếu hàng vẫn hiện thông điệp xác nhận giao hàng.
Viết phiếu giao việc và cấu hình quyền. Nêu rõ dữ liệu cần đọc, đầu ra phải có và lúc nào cần hỏi lại.
Dùng tình huống kiểm tra đã biết. Chuẩn bị bản đúng, bản có lỗi và bản thiếu quy tắc; dùng dữ liệu giả hoặc đã ẩn danh.
Đối chiếu kết quả với người phụ trách. Agent có tìm đúng lỗi, có báo nhầm và có nhận ra lúc chưa đủ thông tin không?
So sánh với cách làm hiện tại. Ghi thời gian rà soát của con người, số lần phải giao lại việc, lỗi bỏ sót và chi phí để đạt một kết quả được chấp nhận.
Nếu đầu ra chưa đạt, đừng mặc định phải đổi mô hình. Hãy kiểm tra theo thứ tự: nhiệm vụ có quá rộng không, đầu vào có thiếu điều kiện không, công cụ có phù hợp không, mẫu bàn giao có buộc nêu bằng chứng không?
Trong tình huống giả định đầu bài, một kết quả tốt không nhất thiết là AI tự sửa mọi thứ. Có khi giá trị lớn nhất là nó phát hiện đúng câu hỏi còn thiếu: “Đơn thiếu một phần có được tách giao hay không?” Câu hỏi được đưa đến người có thẩm quyền trước khi thành một giả định trong mã nguồn.
Đội AI làm việc tốt không chỉ là đội tạo ra nhiều nội dung. Đó là đội khiến trách nhiệm, bằng chứng và quyết định trở nên rõ hơn.
Trước khi hỏi “cần bao nhiêu agent?”, hãy hỏi “mỗi lần giao việc có đủ rõ để người nhận làm đúng, và đủ cụ thể để người giao nghiệm thu không?”. Khi trả lời được câu này, subagents mới trở thành một cách tổ chức công việc — thay vì một tầng phức tạp mới.
Nếu thử ngay một vai chuyên trách cho đội của bạn, bạn sẽ chọn việc nào: làm rõ nghiệp vụ, rà soát mã nguồn hay thiết kế kiểm thử?