Tôi đã vận hành 1.000 AI agent bằng 6 bước, 5 câu lệnh & 1 tệp tin (Hướng dẫn dành cho nhà phát triển)

Prompting đã chết vào năm 2024. Kỹ năng mới là Điều phối (Orchestration)

Tôi đã chạy 1.000 AI Agent trong 30 ngày và đây là những gì tôi phát hiện ra

Kỹ năng đã thay thế prompting, và các hệ thống bạn có thể chạy ngay hôm nay.

Đừng tối ưu hóa prompt của bạn nữa. Nó không còn là nút thắt cổ chai nữa.

Với một agent trong một cửa sổ chat, prompt là phần quan trọng nhất.

Với mười agent chạy trong nhiều giờ, prompt chỉ là một sai số làm tròn.

Thứ quyết định chất lượng công việc là hệ thống xung quanh các agent:

• chế độ nào cho mỗi tác vụ chạy
• mô hình nào chạy bước nào
• cách các agent phối hợp với nhau
• cách "hoàn thành" được xác minh trong khi bạn ngủ

Một prompt cho bạn một đầu ra. Một vòng lặp cho bạn một hoạt động nhân lên.

Sự thay đổi rất đơn giản. Bạn không còn là người đọc từng kết quả và gõ lệnh tiếp theo. Bạn trở thành người thiết kế hệ thống một lần và để nó tự chạy.

Lớp thiết kế đó mới là công việc bây giờ. Đây là cách xây dựng nó.

Bạn xây dựng bộ điều phối (orchestrator), không phải code

Bạn không quản lý ba mươi agent bằng cách nói chuyện với ba mươi agent. Bạn nói chuyện với một agent. Agent đó là bộ điều phối, và nó quản lý phần còn lại.

Một bộ điều phối tốt làm chính xác ba việc:

1. Phân rã một mục tiêu thành các nhiệm vụ con có giới hạn, có thể kiểm tra độc lập.
2. Ủy quyền mỗi nhiệm vụ con cho một worker, với một bản tóm tắt ngắn gọn và quyền sở hữu tệp rõ ràng.
3. Tổng hợp kết quả và quyết định bước tiếp theo.

Có một quy tắc trên hết: bộ điều phối không bao giờ tự mình làm công việc đó.

Khoảnh khắc agent chính của bạn bắt đầu viết code triển khai, ngữ cảnh của nó sẽ chứa đầy chi tiết và nó sẽ mất dấu toàn bộ công việc.

Giữ cho ngữ cảnh của nó sạch sẽ. Nó suy nghĩ, phân chia, giao việc và kiểm tra. Không làm gì khác.

Sau đó, đi sâu, không đi rộng:

• Đừng để bộ điều phối sinh ra tám worker trực tiếp. Điều đó sẽ làm vỡ vụn ngữ cảnh của nó.
• Thay vào đó, hãy để nó sinh ra hai hoặc ba trưởng nhóm.
• Để mỗi trưởng nhóm tự sinh ra hai hoặc ba chuyên gia riêng.

Phần thưởng là độ sâu phân rã gấp ba lần với cùng một chi phí ngữ cảnh. Đó là cách một tổ chức thực sự mở rộng quy mô, thông qua các lớp, chứ không phải bằng cách có một người giao mọi nhiệm vụ.

Có thể xác minh hay không: sự phân chia quyết định mọi thứ

Trước khi xây dựng bất cứ thứ gì, hãy đặt một câu hỏi về tác vụ. Một máy móc có thể kiểm tra xem nó đã hoàn thành hay chưa?

Câu trả lời đó quyết định toàn bộ cách tiếp cận của bạn.

Nếu tác vụ có thể xác minh, bạn có thể lặp lại nó:

• Các bài kiểm tra đạt hoặc không đạt.
• Trình kiểm tra kiểu (type checker) báo xanh hoặc không.
• Điểm chuẩn vượt qua ngưỡng hoặc không.

Hãy hướng một agent vào một tác vụ có thể xác minh và nó sẽ leo đồi (hill-climb) qua nó trong một đêm. Bạn thức dậy và thấy một vấn đề đã được giải quyết.

Nếu tác vụ không thể xác minh, chỉ một vòng lặp thôi sẽ không cứu được bạn. Ví dụ:

• Thiết kế một bộ đánh giá (eval) tốt.
• Quyết định xem một API có cảm thấy phù hợp hay không.
• Đánh giá xem một hướng nghiên cứu có đáng để theo đuổi hay không.

Đối với những tác vụ này, bạn cần đưa vào "gu" (taste). Bạn không thể giao mục tiêu và bỏ đi, bởi vì không có một cánh cổng nào để dừng lại.

Vì vậy, giải pháp là làm cho càng nhiều công việc càng tốt trở nên có thể xác minh:

• Biến "làm cho nó tốt" thành "vượt qua các kiểm tra cụ thể này."
• Thay thế các mục tiêu mơ hồ bằng những mục tiêu cụ thể, có thể đo lường được.
• Ở những nơi bạn không thể, hãy giữ một con người trong vòng lặp và điều chỉnh.

Hầu hết kỹ thuật điều phối là chuyển đổi các mục tiêu mơ hồ thành các mục tiêu có thể kiểm tra, để vòng lặp có thể tiếp quản.

Bắt đầu với hệ thống thực tế nhỏ nhất: một vòng lặp mục tiêu (goal loop)

Một vòng lặp mục tiêu là một mục tiêu bền bỉ cộng với một kiểm tra xác định. Agent làm việc từng bước một hướng tới một mục tiêu thay vì dừng lại sau một lượt.

Toàn bộ hệ thống là một vòng lặp xung quanh agent của bạn và một trình xác thực (validator):

1i=0
2until npm test -s; do
3  agent -p "Mục tiêu: làm cho bộ kiểm thử chuyển sang xanh.
4            ĐỌC code và xây dựng bức tranh toàn cảnh TRƯỚC KHI thay đổi bất cứ thứ gì.
5            'npm test' đang thất bại. Thực hiện thay đổi nhỏ nhất để vượt qua."
6  (( ++i > 20 )) && { echo "dừng: 20 lần lặp"; exit 1; }
7done

Trình xác thực là bất kỳ lệnh nào có mã thoát (exit code) là cánh cổng. Kiểm thử, kiểm tra kiểu, lint, hoặc một script tùy chỉnh.

Có hai điều không thể thương lượng:

1. Một giới hạn. Một vòng lặp không có điều kiện dừng là cách bạn thức dậy với hóa đơn token năm con số.
2. Một hướng dẫn đọc trước. Chế độ mặc định thất bại của mọi agent là bắn một phát ngẫu nhiên vào bản sửa lỗi có vẻ khả thi đầu tiên thay vì đọc code.

Buộc phải đọc. Nó chậm hơn mỗi bước nhưng nhanh hơn rất nhiều về tổng thể.

Làm cho "hoàn thành" trở nên bất khả thương lượng: người phán xét (judge)

Các agent thường bỏ cuộc sớm. Chúng được huấn luyện để dừng lại ngay khi có thể biện minh cho việc đó.

"Tôi đã cố gắng hết sức, dừng lại ở đây" không giống với "đã hoàn thành".

Nếu một agent tự chấm điểm bài tập về nhà của mình, nó sẽ gian lận. Không phải với ác ý. Nó chỉ tự thuyết phục mình rằng đã xong việc.

Giải pháp là một người phán xét riêng biệt:

• Một agent thứ hai có nhiệm vụ duy nhất là chấm điểm công việc dựa trên một tiêu chí cụ thể.
• Nó trả lời một câu hỏi: đã hoàn thành, hay chưa hoàn thành, và còn thiếu gì.
• Nó không có lợi ích gì trong việc dừng lại, vì vậy nó không nao núng.

Chạy builder và judge trên các dòng họ mô hình (model families) khác nhau. Các dòng họ khác nhau mắc những lỗi không tương quan, vì vậy judge sẽ thấy những gì builder bỏ sót.

1while :; do
2  agent --model "$BUILD" -p "Nhiệm vụ: $TASK. Đọc trước, triển khai, chạy kiểm thử."
3  verdict=$(agent --model "$JUDGE" -p "Người đánh giá nghiêm khắc. Chấm điểm theo từng mục trong rubric.md.
4            Trả lời chính xác 'PASS' hoặc 'FAIL: <điều còn thiếu>'.")
5  [[ $verdict == PASS* ]] && break
6done

Làm cho tiêu chí (rubric) cụ thể và nhị phân:

• Tiêu chí tốt: "tất cả kiểm thử xanh, bao gồm cả migration, không có debug logging."
• Tiêu chí tồi: "làm cho nó tốt."

Một người kiểm tra vô tư với quyền phủ quyết là thứ duy nhất cho phép một lần chạy tiếp tục trong nhiều giờ thay vì sụp đổ ngay khi worker mệt mỏi.

Kích hoạt nó sau mỗi lần hoàn thành nhiệm vụ. Sau đó, bạn sẽ chỉ thấy công việc đã được đánh giá là xanh.

Thêm các vòng lặp bạn sẽ thực sự sử dụng

Vòng lặp mục tiêu là mẫu cơ bản. Một vài biến thể bao phủ hầu hết những gì bạn sẽ chạy.

1. Vòng lặp xác thực (validation loop).

Hành động, chạy trình xác thực, đưa kết quả thất bại trở lại, lặp lại cho đến khi cánh cổng xanh.

Sử dụng nó cho các đợt kiểm tra hồi quy (regression sweeps), kiểm tra kiểu và bất kỳ tình huống đạt/không đạt xác định nào.

2. Vòng lặp hàng đợi và đặt lại (queue and reset loop).

Chia công việc thành một danh sách các tác vụ nhỏ, nguyên tử. Xử lý từng tác vụ một.

Sau mỗi tác vụ, đặt lại agent về một ngữ cảnh sạch và nhận tác vụ tiếp theo.

Một ngữ cảnh chạy trong nhiều giờ sẽ chứa đầy sự nhầm lẫn. Việc đặt lại giữ cho mỗi tác vụ được sạch sẽ.

Bộ nhớ tồn tại bên ngoài agent, trong tệp tác vụ và lịch sử commit.

1while read -r task; do
2  agent -p "Nhiệm vụ: $task. Đọc trước. Triển khai, sau đó chạy kiểm thử."
3  npm test -s && git commit -aqm "tự động: $task"   # chỉ commit khi xanh
4done < tasks.txt

3. Vòng lặp giám sát (monitor loop).

Hướng một agent vào một luồng tín hiệu và để nó làm nổi bật những gì quan trọng. Các issue mở, bản dựng thất bại, log lỗi, phản hồi mới.

Nó không đợi bạn hỏi. Nó đọc, phân loại và báo cáo lên, hoặc mở một bản sửa lỗi dự thảo.

1while sleep 300; do
2  agent -p "Đọc 5 phút log lỗi gần nhất. Nếu một MẪU MỚI xuất hiện,
3            hãy mở một issue với một bản tái tạo tối thiểu. Nếu không, hãy nói 'không có gì mới'."
4done

4. Vòng lặp lập kế hoạch rồi xây dựng (plan-then-build loop).

Chạy vòng lặp trong hai giai đoạn. Đầu tiên là một lượt lập kế hoạch tạo ra một kế hoạch bằng văn bản và dừng lại.

Bạn xem xét kế hoạch. Sau đó, một lượt thực thi tuân theo kế hoạch đã được phê duyệt.

Kế hoạch thì rẻ để sửa. Code thì đắt để sửa. Hãy phát hiện hướng đi sai trong kế hoạch.

Các prompt thực sự làm công việc

Một prompt không phải là một điều ước. Đối với một agent, nó là một bản đặc tả (spec).

Khoảng cách giữa đầu ra tầm thường và đầu ra xuất sắc hầu như hoàn toàn là chất lượng của những prompt này.

Hãy giữ một bộ nhỏ các prompt có thể tái sử dụng. Năm prompt chịu hầu hết trọng lượng.

1. Prompt phân rã, dành cho bộ điều phối:

1Bạn là bộ điều phối. KHÔNG được viết code.
2Chia mục tiêu này thành 3 đến 6 nhiệm vụ con có giới hạn.
3Cho mỗi nhiệm vụ: một dòng tóm tắt, các tệp chính xác nó sở hữu, và kiểm tra hoàn thành của nó.
4Đánh dấu bất kỳ nhiệm vụ nào phụ thuộc vào nhiệm vụ khác. Xuất ra danh sách, sau đó dừng lại.
5Mục tiêu: <mục tiêu>

2. Bản tóm tắt worker, dành cho chuyên gia:

1Bạn CHỈ sở hữu các tệp này: <các tệp>.
2Nhiệm vụ: <một dòng>. Hoàn thành khi: <kiểm tra có thể xác minh>.
3Đọc các tệp đó và các caller của chúng TRƯỚC KHI chỉnh sửa. Không thay đổi bất cứ thứ gì bên ngoài tệp của bạn.
4Khi hoàn thành, viết một báo cáo 5 dòng vào <tên>.md, sau đó chạy kiểm thử.

3. Prompt judge, dành cho một dòng họ mô hình khác:

1Bạn là một người đánh giá nghiêm khắc, không khoan nhượng. Bạn không viết code này.
2Chấm điểm repo dựa trên MỌI mục bên dưới. Một thiếu sót là FAIL.
3<tiêu chí>
4Trả lời bằng chính xác một dòng: 'PASS' hoặc 'FAIL: <điều còn thiếu>'.

4. Prompt lập kế hoạch trước, dành cho chế độ lập kế hoạch:

1Tạo một kế hoạch bằng văn bản cho <mục tiêu>. Bao gồm: cách tiếp cận, các tệp cần động đến,
2các trường hợp ngoại lệ (edge cases), chiến lược kiểm thử, và những gì bạn SẼ KHÔNG làm.
3Chưa viết code. Dừng lại sau khi có kế hoạch để tôi có thể xem xét nó.

5. Prompt suy ngẫm hoặc hủy bỏ, khi một agent bị mắc kẹt:

1Bạn đã thất bại cùng một kiểm tra 3 lần. Hãy ngừng lặp lại cách tiếp cận.
2Trả lời trong 3 dòng: chính xác điều gì đã thất bại, giả định nào đã sai,
3và điều khác biệt nhỏ nhất để thử. Sau đó chỉ thử ĐIỀU ĐÓ.

Một mẫu hình xuyên suốt cả năm prompt. Nêu rõ vai trò, ranh giới, kiểm tra hoàn thành và những gì KHÔNG được làm.

Định tuyến mô hình: câu hỏi mà ai cũng hỏi

Câu hỏi thường được đặt ra như một sự lựa chọn. Tôi nên đặt mô hình đắt tiền vào lập kế hoạch hay triển khai?

Đó là một khung sai lầm. Thay vào đó, hãy định tuyến theo bán kính tác động (blast radius). Hãy tự hỏi một sai lầm sẽ khiến bạn tốn kém nhất ở đâu.

Logic rất đơn giản:

• Một quyết định tồi trong lập kế hoạch sẽ lan truyền khắp toàn bộ đội hình (fleet) của bạn.
• Một dòng code tồi trong một hàm có giới hạn, đã được kiểm thử sẽ bị phát hiện trong vài phút.
• Vì vậy, bạn chi tiêu ở những nơi lỗi đắt đỏ và không thể đảo ngược, và tiết kiệm ở những nơi lỗi rẻ và được kiểm soát.

Đây là cách định tuyến, từng tầng một:

1. Lập kế hoạch, kiến trúc và phân rã: tầng cao nhất, luôn luôn. Đòn bẩy cao nhất, khối lượng token nhỏ. Rẻ ở đây là sai lầm đắt giá nhất bạn có thể mắc phải.
2. Triển khai với đặc tả chặt chẽ: tầng trung bình, chạy song song. Bản đặc tả đã làm công việc suy nghĩ. Xác minh bằng kiểm thử.
3. Triển khai với đặc tả lỏng lẻo: tầng cao nhất. Lấp đầy khoảng trống là suy luận, và một mô hình rẻ sẽ đoán sai theo hàng tá hướng.
4. Đánh giá và phán xét: một dòng họ khác, và không phải là rẻ. Đây là nơi bạn bắt những thiếu sót đắt đỏ.
5. Điều hướng, tìm kiếm, tóm tắt và phân loại: mô hình rẻ nhất, nhanh nhất. Không suy luận, khối lượng lớn. Không bao giờ trả giá cao cho việc grep.

Vì vậy, câu trả lời thực sự cho "lập kế hoạch rẻ hay triển khai rẻ" không phải là cái nào một cách mù quáng.

Mô hình cao cấp cho lập kế hoạch và đánh giá, luôn luôn. Triển khai là cái có thể thay đổi.

Các dòng họ mô hình khác nhau cũng có những tính cách khác nhau, và điều đó quan trọng cho việc định tuyến:

• Một dòng họ lấp đầy khoảng trống. Khi đặc tả lỏng lẻo, nó đưa ra các giả định hợp lý và tiếp tục. Điều đó có ích khi các giả định tốt, và có hại khi chúng không tốt.
• Một dòng họ khác rất theo nghĩa đen. Nó làm chính xác những gì bạn nói và không hơn, giống như một con dao tiện ích chính xác.

Sử dụng kẻ lấp đầy khoảng trống ở nơi công việc có tính mở và đặc tả lỏng lẻo. Sử dụng kẻ theo nghĩa đen cho việc đánh giá và cho các thay đổi chính xác, được xác định rõ ràng.

Đòn bẩy kiểm soát việc triển khai là đặc tả (spec) của bạn

• Một đặc tả chặt chẽ cho bạn quyền chạy các worker rẻ, song song.
• Một đặc tả lỏng lẻo buộc bạn quay lại sử dụng một mô hình đắt tiền để lấp đầy khoảng trống.

Đầu tư vào kế hoạch một cách chính xác để bạn có thể rẻ hóa việc xây dựng.

Có một cái bẫy đáng để chỉ ra. Định tuyến rẻ tối ưu hóa giá của mỗi lần gọi, nhưng nó có thể âm thầm phá hủy tỷ lệ token tạo ra đầu ra có thể ship và merge được.

Một mô hình rẻ thử lại năm lần và tạo ra code bạn không thể merge sẽ đắt hơn một lần vượt qua sạch sẽ từ một mô hình cao cấp.

Đo chi phí của đầu ra hữu ích, không phải chi phí mỗi lần gọi.

Để mở rộng quy mô, hai con số sẽ hữu ích:

• Tầng cao cấp của bạn có chi phí đầu ra trên mỗi token gấp khoảng năm lần so với tầng rẻ.
• Định tuyến theo tầng thường cắt giảm chi tiêu từ 40% đến 60% so với việc chạy mô hình tốt nhất của bạn ở mọi nơi.

Kỹ năng (Skills): đóng gói một quy trình làm việc một lần, tái sử dụng nó mãi mãi

Khi bạn tiếp tục dán cùng một prompt hoặc chạy cùng một quy trình làm việc, hãy biến nó thành một kỹ năng.

Một kỹ năng là một tệp hướng dẫn nhỏ mà agent chỉ tải khi nó có liên quan.

Bạn viết quy trình làm việc một lần và mọi agent đều có thể với tới nó.

Một tệp kỹ năng có hai phần:

• YAML frontmatter với tên và mô tả.
• Phần thân markdown với các hướng dẫn thực tế.

Mô tả là dòng quan trọng nhất. Nó cho agent biết kỹ năng làm gì và chính xác khi nào nên sử dụng nó, để agent tự động chọn nó mà không cần bạn đặt tên.

Một tệp kỹ năng tối thiểu:

1---
2name: đánh giá-nhiệt-hạch
3description: Đánh giá code chuyên sâu, đối nghịch. Sử dụng sau bất kỳ thay đổi không tầm thường nào,
4  hoặc khi được yêu cầu đánh giá, kiểm toán, hoặc củng cố một diff trước khi merge.
5---
6
7# Đánh giá nhiệt hạch
8
9Đọc toàn bộ diff và các tệp nó động đến. Đừng lướt qua.
10
11Đánh giá trong ba lượt:
121. Tính đúng đắn: lỗi logic, trường hợp ngoại lệ, điều kiện tranh chấp (race conditions), lỗi lệch một (off-by-ones).
132. An toàn: injection, xác thực, bí mật, đầu vào không an toàn, các thao tác phá hủy.
143. Sự phù hợp: nó có phù hợp với kiến trúc hiện tại không, hay chỉ thêm một mẫu mới?
15
16Cho mỗi phát hiện: tệp, dòng, mức độ nghiêm trọng và bản sửa lỗi một dòng.
17Kết thúc bằng một phán quyết: SHIP hoặc BLOCK, cộng với 3 điều cần sửa đầu tiên.

Các quy tắc cho kỹ năng tốt:

1. Giữ tệp ngắn. Dưới vài trăm dòng. Chuyển tài liệu tham khảo dài sang các tệp riêng biệt mà kỹ năng trỏ đến.
2. Làm cho tên khớp với thư mục của nó, nếu không nó sẽ không tải.
3. Viết mô tả để kích hoạt. Viết rõ các trường hợp "sử dụng khi".
4. Không bao giờ để agent viết lại một kỹ năng. Một con người quản lý từng dòng.

Kỹ năng là cách một quy trình làm việc nhân lên. Lần đầu tiên bạn giải quyết tốt một vấn đề, bạn lưu nó lại và làm cho nó có thể khám phá được. Mỗi phiên sau đó, nó là miễn phí.

Chạy nhiều agent: đội hình (fleet)

Khi một vòng lặp hoạt động, bạn mở rộng quy mô.

Cung cấp cho mỗi worker hai thứ:

• Worktree git riêng của nó, để không có hai agent nào chạm vào cùng một tệp.
• Cửa sổ terminal riêng của nó, để bạn có thể theo dõi và nhắn tin cho nó.

1tmux new-session -d -s fleet
2for name in hilbert gauss poincare; do
3  git worktree add -B "agent/$name" "../wt-$name" main
4  tmux new-window -t fleet -n "$name" -c "../wt-$name" "$AGENT"
5done

• Đặt tên cho các agent của bạn. Chạy mười lăm agent, "agent_7" là vô dụng.
• Tên cho phép bạn nắm giữ toàn bộ đội hình trong đầu. Cái này sở hữu lớp dữ liệu, cái kia viết eval, cái kia đánh giá.
• Tính dễ đọc (legibility) là mục đích. Một đội hình bạn không thể theo dõi là một đội hình bạn không thể điều khiển.
• Sau đó, làm cho chúng hợp tác. Theo mặc định, các agent bỏ qua nhau và coi bất cứ thứ gì từ một agent cùng nhóm là nhiễu nền.

Mẹo là gửi tin nhắn giữa các agent dưới dạng lượt của người dùng. Các mô hình được huấn luyện để phản hồi người dùng và phần lớn bỏ qua các tín hiệu xung quanh.

1send() { tmux send-keys -t "fleet:$1" "$2" Enter; }
2send hilbert "GET /search?q= trả về [{id,title,url}]. Kết nối UI với nó."

Một động thái đó biến một đống các tiến trình biệt lập thành một đội nhóm chuyển giao hợp đồng và gỡ khối cho nhau.

Bạn ở lại trên đỉnh. Bạn nhắn tin cho trưởng nhóm, và trưởng nhóm chuyển tiếp cho các worker.

Quy trình làm việc động (Dynamic workflows): biên dịch sự phối hợp thành code

Một vòng lặp giữ sự phối hợp bên trong mô hình. Mô hình quyết định mỗi bước, điều này đốt token và lấp đầy ngữ cảnh của nó.

Một quy trình làm việc động đảo ngược điều đó. Bộ điều phối viết một script phối hợp các worker và một runtime riêng biệt chạy script ở nền.

Ý tưởng chính là nơi trạng thái tồn tại. Vòng lặp, sự rẽ nhánh và các kết quả trung gian nằm trong các biến của script, không phải trong bộ nhớ của mô hình.

Điều đó mang lại cho bạn những gì:

• Chi phí phối hợp bằng không token mô hình, bởi vì code thuần đang làm việc đó.
• Ngữ cảnh chính của bạn vẫn sạch sẽ. Chỉ có kết quả cuối cùng quay trở lại.
• Nó tỏa ra rộng. Hàng chục worker cùng một lúc, lên đến một nghìn trong một lần chạy.

Khi nào nên sử dụng nó:

• Mẫu hình đã biết và việc xác minh là khách quan.
• Công việc rộng và lặp đi lặp lại. Nhiều tệp, nhiều trường hợp, nhiều điểm cuối.
• Nó có thể chạy không cần giám sát.

Khi nào không nên sử dụng nó:

• Bạn vẫn đang tìm hiểu phải làm gì. Đó là một vòng lặp mục tiêu, không phải một quy trình làm việc.
• Nhiệm vụ cần một chuỗi suy luận mạch lạc duy nhất. Điều đó muốn một agent mạnh duy nhất, không phải một nghìn agent.

Một hình dạng cụ thể. Giả sử bạn cần di chuyển 200 tệp sang một API mới:

1// bộ điều phối viết cái này một lần; một runtime chạy nó, không phải mô hình
2const files = await glob("src/**/*.ts");
3
4const results = await mapLimit(files, 16, async (file) => {
5  const r = await subagent(`Di chuyển ${file} sang API mới. Chạy kiểm thử của nó.`);
6  return { file, ok: r.testsPassed };
7});
8
9const failed = results.filter(r => !r.ok);
10return `đã di chuyển ${results.length - failed.length} trên ${results.length}. ` +
11       `thử lại: ${failed.map(f => f.file).join(", ")}`;

Hãy đọc những gì nó làm:

1. Nó liệt kê 200 tệp trong code, không phải trong đầu mô hình.
2. Nó chạy 16 subagent cùng một lúc, mỗi agent di chuyển một tệp và chạy kiểm thử của nó.
3. Nó ghi lại đạt hoặc không đạt cho mỗi tệp trong một mảng đơn giản.
4. Nó trả về một bản tóm tắt ngắn. 200 bản ghi trung gian không bao giờ chạm vào ngữ cảnh của bạn.

Đó là toàn bộ mục đích. Mô hình đã suy nghĩ một lần, để viết script. Script đã làm việc phối hợp, miễn phí.

Lan can bảo vệ (Guardrails): điều gì giữ cho đội hình không tự ăn thịt mình

Nút thắt cổ chai của con người từng làm công việc thực sự. Ở tốc độ của con người, sai lầm gây hại sớm và bạn sửa chúng khi bạn tiến hành.

Hãy loại bỏ hoàn toàn bản thân bạn và những lỗi nhỏ sẽ kết hợp nhanh hơn bạn có thể cảm nhận được. Một sự trùng lặp ở đây, một sự trừu tượng hóa không cần thiết ở đó.

Một ngày nọ, kiến trúc sẽ không còn uốn cong được nữa và các bài kiểm tra của bạn không đáng tin cậy vì các agent cũng đã viết chúng.

Mọi lan can bảo vệ bên dưới thay thế sự điều chỉnh mà nút thắt cổ chai từng cung cấp:

1. Đọc trước khi đoán. Biến nó thành một quy tắc thường trực trong mọi prompt xây dựng, không phải một lời cầu xin cho mỗi tác vụ.
2. Giới hạn và hủy bỏ. Mọi vòng lặp đều có giới hạn lặp. Mọi agent đều có ngân sách token tự động tạm dừng ở gần 85%. Sau ba lần lặp bị mắc kẹt trên cùng một lỗi, hãy hủy bỏ agent và giao nhiệm vụ cho một agent mới.
3. Một tệp, một chủ sở hữu. Cô lập bằng worktrees. Không bao giờ để hai agent chỉnh sửa cùng một tệp.
4. Tiêm lại sứ mệnh. Trên các lần chạy dài, hãy đăng danh sách kiểm tra dưới dạng tin nhắn người dùng vài phút một lần để agent không bị trôi dạt khi ngữ cảnh của nó đầy lên.

1while sleep 900; do
2  send gauss "NHẮC NHỞ: vẫn đang làm nhiệm vụ? Đọc trước. Chạy kiểm thử sau mỗi thay đổi. Ở trong tệp của bạn."
3done &

Điểm sâu nhất nằm bên dưới tất cả:

• Xác minh hiện là nút thắt cổ chai, không phải là tạo sinh.
• Các agent tạo ra đầu ra có vẻ hợp lý nhanh hơn bạn có thể kiểm tra nó.
• Có vẻ hợp lý không có nghĩa là đúng.

Cho đến khi việc xác minh của bạn nhanh như việc tạo sinh, việc xem xét của con người không phải là chi phí chung. Nó là hệ thống an toàn.

Bộ nhớ: bạn là kho lưu trữ dài hạn

Một mô hình có bộ nhớ ngắn hạn, cửa sổ ngữ cảnh, và không có gì khác. Mọi thứ ngoài cửa sổ đó đều biến mất trừ khi bạn mang nó theo.

Vì vậy, hãy coi bản thân bạn và các tệp bạn giữ, như bộ nhớ dài hạn cho các agent chỉ có bộ nhớ ngắn hạn.

Hai thói quen quan trọng.

Đầu tiên, truyền trạng thái bằng tham chiếu (reference), không phải bằng bản tóm tắt (summary):

• Khi một ngữ cảnh đầy lên, bản sửa lỗi lười biếng là tóm tắt nó. Các bản tóm tắt bị mất mát và bỏ qua các chi tiết bạn sẽ cần sau này.
• Thay vào đó, hãy hướng các agent đến các tệp, bản ghi tác vụ và đầu ra trước đó mà chúng có thể đọc lại. Không có gì quan trọng bị âm thầm vứt bỏ.

Thứ hai, giữ bộ nhớ bền vững bên ngoài agent:

• Một tệp tác vụ với trạng thái.
• Một nhật ký tiến độ đang chạy.
• Lịch sử commit.
• Một tệp ghi chú dài hạn thu thập các mẫu hình và cạm bẫy.

Thiết kế như thể các agent của bạn sẽ chạy trong nhiều ngày, bởi vì với sự nén chặt tốt, chúng sẽ làm được.

Các mô hình chưa biết điều này về bản thân chúng. Chúng mang một sự thiên vị hướng tới việc giải quyết mọi thứ trong một ngân sách ngắn, như thể việc tiêu token là chết người. Giàn giáo (scaffolding) của bạn là thứ cho phép chúng chạy lâu mà không mất dấu.

Cấu trúc liên kết (Topology): bao nhiêu agent và theo hình dạng nào

Nhiều agent hơn không có nghĩa là nhiều đầu ra hơn. Quá một điểm nào đó, nó còn ít hơn, bởi vì sự phối hợp không miễn phí và nó kết hợp với mỗi agent bạn thêm vào.

Quy tắc quan trọng là khớp hình dạng với công việc:

• Suy luận tuần tự, phụ thuộc muốn ít agent hơn, đôi khi chỉ một. Chia một chuỗi suy luận duy nhất sẽ phân mảnh lý luận và làm giảm kết quả.
• Công việc độc lập, song song muốn bạn tỏa ra. Cấu trúc liên kết phẳng, quyền sở hữu tệp rõ ràng. Đó là nơi tính song song phát huy tác dụng.
• Một đội nhóm phối hợp muốn ba đến năm worker. Chi phí token tăng tuyến tính với quy mô. Chi phí phối hợp tăng tồi tệ hơn. Ba worker tập trung đánh bại năm worker phân tán.

Vậy làm thế nào để ai đó chạy hàng trăm agent? Không phải như một cuộc trò chuyện khổng lồ tự tranh luận với chính nó.

Họ chạy chúng như chiều sâu và sự độc lập:

• Một vài agent bạn thực sự nói chuyện, mỗi agent ủy quyền xuống các nhiệm vụ con có giới hạn không cần phối hợp.
• Bầy đàn (swarms) các vòng lặp độc lập tự làm việc riêng của chúng và báo cáo lên.

Quy mô đến từ chiều sâu ủy quyền và sự độc lập. Không bao giờ từ việc mở rộng một luồng duy nhất.

Tệp điều khiển: orchestration.md

Bạn có thể giữ một tệp cho các agent biết cách viết code trong repo của bạn. Phong cách, cạm bẫy, kiến trúc. Hãy giữ nó.

Tuy nhiên, nó trả lời sai câu hỏi cho việc điều phối.

Tệp orchestration.md trả lời một câu hỏi khác. Công việc nên được CHẠY như thế nào ở đây?

Nó là một hợp đồng do con người viết bao gồm:

• chế độ nào để sử dụng cho tác vụ nào
• tầng mô hình nào đi đâu
• các lan can bảo vệ là gì
• khi nào cần leo thang lên con người

Mọi agent đọc nó khi bắt đầu mỗi phiên và sử dụng nó để tự chọn cách tiếp cận của mình.

Đây là tệp có đòn bẩy cao nhất trong repo. Nó di chuyển quyết định chọn chế độ ra khỏi đầu bạn, nơi bạn đưa ra nó một cách không nhất quán mỗi phiên, vào một đặc tả mà đội hình tuân theo.

Một phiên bản ngắn trông như thế này:

1# orchestration.md. Cách công việc được CHẠY ở đây. Do con người quản lý. Agent không được chỉnh sửa.
2
3Chọn chế độ:
4- Vòng lặp mục tiêu (có giám sát): công việc mơ hồ hoặc thiết kế. Xác định kiểm tra hoàn thành.
5- Vòng lặp xác thực: cánh cổng xác định. Luôn giới hạn số lần lặp và chi phí.
6- Xây dựng cộng với phán xét: worker xây dựng, một judge từ dòng họ khác phê duyệt.
7- Đội hình (ba đến năm): các nhiệm vụ con phụ thuộc lẫn nhau, worktrees biệt lập, nhắn tin ngang hàng.
8- Hàng đợi và đặt lại: nhiều tác vụ nguyên tử nhỏ, ngữ cảnh mới mỗi lần.
9- Quy trình làm việc động: mẫu hình đã biết, cánh cổng khách quan, rộng và lặp đi lặp lại. Phối hợp trong code, không cần giám sát.
10
11Định tuyến mô hình theo bán kính tác động:
12- Lập kế hoạch và kiến trúc: tầng cao nhất, luôn luôn.
13- Xây dựng, đặc tả chặt chẽ: tầng trung bình, song song, xác minh bằng kiểm thử.
14- Xây dựng, đặc tả lỏng lẻo: tầng cao nhất, bởi vì lấp đầy khoảng trống là suy luận.
15- Đánh giá và phán xét: một dòng họ khác. Không bao giờ là mô hình của người triển khai.
16- Điều hướng, tìm kiếm, tóm tắt: rẻ nhất. Tối ưu hóa đầu ra có thể merge, không phải giá mỗi lần gọi.
17
18Lan can bảo vệ:
19- Ngân sách token cho mỗi agent. Tự động tạm dừng ở gần 85%. Hủy bỏ và giao lại sau 3 lần thử bị mắc kẹt.
20- Bất kỳ lần chạy nào trên một giờ cần một judge riêng biệt. Worker không bao giờ tự báo cáo hoàn thành.
21- Đọc code trước khi đưa ra giả thuyết. Lập kế hoạch bằng văn bản trước khi chỉnh sửa đầu tiên.

Hai quy tắc chi phối tệp:

1. Giữ nó ngắn.
2. Không bao giờ để agent viết lại nó.

Giá trị là một con người đã quản lý từng dòng.

Những gì thuộc về bạn

Điều phối làm cho các agent đáng tin cậy trong việc thực thi. Nó không chọn vấn đề và nó không biết thế nào là tốt.

Ba điều ở lại phía bạn của ranh giới, vĩnh viễn.

Đầu tiên, ủy quyền các nhiệm vụ, không phải sự phán xét:

• Giao cho các agent công việc có phạm vi với tiêu chí đạt/không đạt rõ ràng. Mẫu (boilerplate), di chuyển (migrations), giàn giáo kiểm thử (test scaffolding) và các cách tiếp cận mà bạn sẽ không bao giờ có thời gian để thử bằng tay.
• Giữ kiến trúc, quyết định về những gì không nên xây dựng và việc đánh giá toàn bộ ngữ cảnh cho chính bạn.
• Các agent đã hấp thụ một đại dương kiến trúc tầm thường, và chúng sẽ vui vẻ sao chép một cách mù quáng (cargo-cult) các mẫu nặng nề vào một dự án không nên có chúng. Nói không là một tính năng mà chúng không có.

Thứ hai, đặc tả của bạn là đòn bẩy:

Khi bạn triển khai trên một đội tàu, suy nghĩ mơ hồ không chỉ làm bạn chậm lại. Nó còn nhân lên gấp bội.

Một yêu cầu mơ hồ lan truyền qua hàng chục luồng chạy song song, mỗi luồng đi sai theo một hướng riêng.

Một đặc tả chính xác sẽ nhân lên thành những triển khai chính xác ở khắp mọi nơi.

Đây là lý do tại sao một kỹ sư giỏi lại tận dụng được nhiều hơn từ những công cụ này, chứ không phải ít hơn. Việc gõ phím đã được tự động hóa. Sự hiểu biết đã được khuếch đại.

Hãy dành phần lớn thời gian của bạn ở chế độ lập kế hoạch, với một kế hoạch bằng văn bản mà mọi người đều thống nhất, trước khi thực hiện chỉnh sửa đầu tiên.

Thứ ba, cố tình đầu tư thiếu:

• Giao một công việc cần bốn tác nhân cho hai tác nhân. Sự hạn chế buộc phải có hành vi mà bạn muốn.
• Bạn xây dựng các vòng lặp thay vì làm mọi thứ thủ công, và lần sau công việc đó đã được tự động hóa sẵn.
• Chuyển ngân sách của bạn từ nỗ lực thủ công sang token. Đầu tư cao ban đầu, chi phí biên gần như bằng không mãi mãi về sau.

Các nhóm làm điều này sẽ tích lũy sức mạnh. Những nhóm không làm thì phải trả giá đầy đủ mỗi lần.

Bạn không còn viết phần mềm nữa. Bạn đang xây dựng nhà máy viết ra nó.

Một nhà máy cần đầu vào chính xác, kiểm soát chất lượng tại mọi trạm, và một chủ sở hữu biết sản phẩm phải như thế nào.

Bắt đầu từ đây

Đừng cố chạy một trăm tác nhân vào thứ Hai. Hãy leo từng bậc thang:

1. Chạy một vòng lặp mục tiêu duy nhất cho một nhiệm vụ có vạch đích có thể kiểm chứng. Học cách cảm nhận một bước kiểm tra hoàn thành tốt.
2. Thêm một người đánh giá từ một họ mô hình khác cho bất kỳ nhiệm vụ nào kéo dài hơn một giờ. Cấm tự báo cáo hoàn thành.
3. Viết tệp orchestration.md của bạn. Yêu cầu các tác nhân của bạn đọc nó trước. Xem chúng bắt đầu chọn chế độ cho bạn.
4. Triển khai một cách cẩn thận. Một nhiệm vụ có thể song song hóa, ba đến năm công nhân, cây thư mục làm việc biệt lập, ngân sách token.
5. Định tuyến các mô hình của bạn. Cấp cao nhất cho lập kế hoạch và đánh giá, rẻ hơn cho các tác vụ xây dựng có giới hạn và công việc lặp đi lặp lại. Đo lường đầu ra có thể hợp nhất.
6. Để nó chạy không cần giám sát một khi mẫu hình đã được xác thực và có thể kiểm tra khách quan. Xử lý hết tồn đọng qua đêm.

Hệ thống chỉ cần đúng về mặt định hướng, không cần hoàn hảo:

• Tệp điều khiển cung cấp cho đội tàu đủ cấu trúc để tự định hướng.
• Người đánh giá bắt các trường hợp ngoại lệ.
• Vòng lặp nhắc nhở xử lý bộ nhớ.
• Gu thẩm mỹ của bạn xử lý các quyết định không thể ủy quyền.

Việc tạo prompt là kỹ năng của năm ngoái. Đây mới là kỹ năng bây giờ.

Các phiên bản có thể chạy được của mọi hệ thống ở đây, vòng lặp mục tiêu, vòng lặp đánh giá, trình khởi chạy đội tàu, bus tin nhắn, watchdog nhắc nhở và bộ định tuyến mô hình, đều có trong bộ công cụ đi kèm. Đặt một biến cho CLI tác nhân của bạn và bắt đầu.

Tuyên bố miễn trừ trách nhiệm

Bài viết này được viết bằng cách sử dụng các phiên Claude Code và các phiên codex của tác giả.

Được chỉnh sửa bởi tác giả và mô hình Kimi K2.6 về các vấn đề ngữ pháp và định dạng.