Bảy agent AI làm việc thay chúng tôi mỗi đêm: agent định kỳ ngoài việc viết code, kèm prompt

Ngày 23 tháng 9, một người dùng tên Rob viết trên backlog công khai của chúng tôi: “would love to get examples of how you guys are doing stuff beyond coding”. Câu hỏi hợp lý. Mọi thứ trên trang này đều nói về agent lập trình, còn thứ chúng tôi thực sự chạy mỗi tối thì phần lớn không phải là viết code.

Từ ngày 28 tháng 8, bảy agent khởi động trên một chiếc Mac mini lúc 20:00. Chúng đọc các commit trong ngày, Search Console, các dashboard quản trị, backlog, phản hồi mọi người gửi đến, các báo cáo của đêm trước. Chúng sửa bug, sửa trang web, viết và dịch một bài blog mỗi ba ngày, đăng bài trên ba mạng xã hội, cập nhật một kho kiến thức sản phẩm, và lúc 22:00 agent thứ bảy đọc những gì sáu agent kia để lại rồi gửi một email 25 dòng. Không ai theo dõi. Nhà sáng lập đọc email trên điện thoại vào sáng hôm sau.

Bài viết này là câu trả lời cho Rob. Những gì đang chạy, chúng được nối với nhau thế nào, các agent giao việc cho nhau ra sao mà không bao giờ nói chuyện, mô hình nào làm việc nào và vì sao, bốn quy tắc mà prompt của chúng phải học qua những lần vấp ngã, và chính các prompt đó, rút gọn thành các khối bạn có thể sao chép. Mọi con số dưới đây đều lấy từ repo: các báo cáo được commit ở đó, đêm này qua đêm khác.

33 đêm đã tạo ra những gì

Thư mục báo cáo trong repo có 33 thư mục theo ngày, từ 28 tháng 8 đến 30 tháng 9. Đọc chúng cho ra kết quả sau:

• 31 email buổi sáng do người báo cáo gửi.
• 51 bug do người sửa bug xử lý, mỗi bug có link commit trên dòng báo cáo của nó. Một số do người dùng báo trên backlog công khai và đã nhận được phản hồi ở bản phát hành tiếp theo.
• 7 bài blog do đội SEO viết từ ngày 10 tháng 9, cứ ba ngày một bài, mỗi bài viết trước bằng tiếng Anh và tiếng Pháp, rồi thêm 18 ngôn ngữ khác ngay trong đêm đó.
• 29 ngày nhật ký mạng xã hội: ba mạng xã hội và năm nhóm Facebook mỗi tối, cộng với một bình luận cảm ơn dưới mỗi bài đăng mà một người dùng đã chia sẻ AgentsRoom.
• Một kho kiến thức sản phẩm khoảng một trăm phiếu thông tin, được cập nhật theo các commit trong ngày, được trợ lý trong ứng dụng đọc và được trang web phục vụ dưới dạng llms-full.txt.

Không việc nào trong số này cần đến con người sau 20:00. Một phần cần con người lúc 08:00, và đó chính là lý do tồn tại của agent cuối cùng.

Đội hình: ai chạy lúc 20:00

Mỗi agent là một Tác vụ định kỳ trong AgentsRoom: một prompt, một agent (vai trò, CLI, mô hình), một máy và một giờ. Cả bảy đều chạy Claude Code. Hai trong số đó không phải agent đơn lẻ mà là các đội hai bước, và chúng tôi sẽ quay lại lý do.

Các tệp .md ở cột cuối đều nằm trong reports/night/<date>/, đã được commit và push. Thư mục đó là toàn bộ hệ thống điều phối, và phần tiếp theo giải thích vì sao.

Chúng được nối với nhau thế nào

Mỗi agent trong bảy agent là một Tác vụ định kỳ có cùng một khuôn:

• Khởi động hằng ngày lúc 20:00 (22:00 với người báo cáo). Không có biểu thức cron; tần suất được chọn trong trình chỉnh sửa.
• Ghim vào một máy. Dự án được mở trên nhiều máy tính, và một bộ kích hoạt sẽ khởi động trên mọi máy có dự án đó trừ khi bạn giới hạn nó. Của chúng tôi được giới hạn vào chiếc Mac mini, nên một chiếc laptop mở lúc 20:05 không khởi động một CEO thứ hai.
• Đánh thức máy. Chiếc Mac mini ngủ. Tác vụ có tùy chọn “đánh thức máy”, lên lịch đánh thức bằng công cụ riêng của hệ điều hành (pmset trên macOS, Task Scheduler với tùy chọn đánh thức để chạy trên Windows, rtcwake trên Linux) vài giây trước lần chạy. Không có nó, một máy đang ngủ chỉ đơn giản là bỏ lỡ lần chạy.
• Chạy bù bật hoặc tắt, theo từng tác vụ. Nếu máy tắt lúc 20:00, một tác vụ bật chạy bù sẽ khởi động ở lần mở ứng dụng tiếp theo. CEO, PM và người báo cáo bật nó. Các tác vụ SEO, sửa bug, mạng xã hội và tài liệu tắt nó: một lần chạy bắt đầu lúc 11:00 sáng hôm sau sẽ va chạm với công việc trong ngày trên cùng một checkout.
• Chế độ quyền được đặt trên tác vụ, không phải trên nhà cung cấp. Một lần chạy không người trông không thể dừng lại ở một yêu cầu phê duyệt lúc 3 giờ sáng, nên tác vụ chạy không cần phê duyệt, trong khi các agent mà nhà sáng lập điều khiển bằng tay trên cùng CLI vẫn hỏi trước.
• Console tự đóng sau 60 phút không hoạt động. Một agent đã xong không nằm lại trong thanh bên cho đến khi có người đóng nó.
• Prompt là tin nhắn đầu tiên. Nội dung của mỗi prompt được lưu trong Thư viện prompt và giống hệt nội dung trong trường prompt của bộ kích hoạt, nên sửa cái này nghĩa là sửa cả hai. Các prompt viết bằng tiếng Pháp, vì nhà sáng lập đọc báo cáo bằng tiếng Pháp. Mọi thứ khác, từ thông điệp commit đến kho kiến thức, đều bằng tiếng Anh.

Còn một mảnh nữa được cả bảy dùng chung: một skill tên là “agent ban đêm, quy tắc chung”. Mỗi prompt bắt đầu bằng “nạp skill này và áp dụng nó”, và skill chứa mọi thứ đúng cho tất cả: ai phụ trách gì, chốt chặn một đêm, một lần chạy, quyền git, định dạng báo cáo, quy tắc backlog, và định dạng email cho người báo cáo. Khi một quy tắc thay đổi, nó thay đổi ở một chỗ duy nhất.

Chúng giao việc cho nhau thế nào mà không nói chuyện

Bảy agent không bao giờ nhắn tin cho nhau. Chúng có thể làm vậy, AgentsRoom có hộp thư giữa các agent, nhưng một tin nhắn thì vô hình vào sáng hôm sau và không grep được. Mọi thứ đi qua ba thứ tồn tại qua đêm:

Repo. Mỗi agent ghi reports/night/<date>/<agent>.md, mở nó ngay trong phút đầu tiên của lần chạy, viết lại nó sau mỗi phần việc hoàn thành, commit và push nó. Báo cáo có bốn phần cố định: “Tóm gọn” (một danh sách gạch đầu dòng, mỗi gạch cho một việc đã làm), “Cần quyết định” (chỉ những gì prompt dành cho con người), “Cần kiểm tra” (một URL cục bộ hoặc một màn hình cần mở), “Chi tiết” (dài bao nhiêu cũng được). Nó kết thúc bằng một mốc lần chạy: commit cuối cùng mà agent đã thấy.

Backlog. Một agent tìm thấy việc cho agent khác thì không tự làm việc đó. Nó mở một ticket kèm tag: ceo-fix cho một bug nhỏ đã được xác minh mà người sửa bug sẽ nhận; ceo-seo cho một việc về nội dung kèm truy vấn mục tiêu; ceo-decision cho mọi thứ cần đến con người (cơ sở dữ liệu, thanh toán, xác thực, mã hóa, giá, một URL đã được lập chỉ mục, một hành vi mặc định). Người giữ tài liệu, khi đọc các commit, phát hiện một tính năng chưa có trang trên website: nó tạo một ticket ceo-seo, và SEO nhận nó vào đêm hôm sau. CEO, khi đọc log lỗi, phát hiện một bug cùng nguyên nhân của nó trong code: ceo-fix, và người sửa bug nhận nó vào đêm hôm sau.

Báo cáo hôm qua. Trước khi bắt đầu bất kỳ việc nào, mỗi agent đọc báo cáo của chính nó từ đêm trước, cùng danh sách các ticket đã đóng trong ngày. Điều nó nêu hôm qua thường đã được sửa trong ngày. Một chủ đề đã xử lý thì không nêu lại; một ticket đã mở thì không tạo lại.

Vòng lặp khép lại với con người. Email của người báo cáo kết thúc bằng một dòng: để trả lời product manager, thêm một phần “## Quyết định” vào cuối rapport.md (P1 OK / P2 KHÔNG: lý do / P3 ĐỂ SAU), commit, push. PM đọc phiên bản đã push vào tối hôm sau và thực hiện những gì đã được duyệt: tạo ticket, gộp các ticket trùng, xếp phần còn lại sang một bên kèm lý do. Một quyết định không được trả lời trong ba đêm cũng là một quyết định: đề xuất rời khỏi email và ở lại dưới dạng ticket.

Mô hình nào làm việc nào, và vì sao

Bảng ở trên cho thấy hai mô hình. Đây là cấu hình hiện tại, không phải một bài benchmark, và nó thay đổi. Nhưng cách chia là có chủ ý.

Fable ở nơi công việc cần óc phán đoán. CEO quyết định một lượt không thích trên một oracle là lỗi thật hay chỉ là sở thích. Người sửa bug quyết định một báo cáo bug là bug hay là cấu hình riêng của một máy, rồi tìm nguyên nhân trong code. Bước 1 của SEO quyết định câu nào trên trang đã trở nên sai sau commit hôm nay, nên viết bài nào, và nên để yên trang nào. Bước 1 của mạng xã hội chọn chủ đề của buổi tối và viết cho một đối tượng nhận ra văn bản do máy tạo chỉ sau ba dòng. Những prompt này dài (prompt SEO khoảng 4.000 từ) và đầy các quy tắc “bạn quyết định, bạn không hỏi” kèm những danh sách ngoại lệ ngắn. Đó là nơi mô hình mạnh nhất xứng đáng với chi phí của nó.

Opus với ngữ cảnh 1M ở nơi công việc là khối lượng. Dịch một bài viết sang 18 ngôn ngữ bằng subagent, mỗi subagent ba ngôn ngữ, rồi đối chiếu bản gộp với bản tham chiếu tiếng Pháp, là đọc và viết, rất nhiều, với cùng các quy tắc áp dụng 18 lần. Người giữ tài liệu đọc diff của cả một ngày đối chiếu với một trăm phiếu thông tin. PM đọc một bản xuất 8 MB các cuộc trò chuyện lúc rời đi. Người báo cáo đọc năm báo cáo và chép lại, nó không suy nghĩ. Ở đó, ngữ cảnh lớn và chi phí mỗi token thấp hơn quan trọng hơn óc phán đoán.

Vì vậy hai trong bảy agent là đội agent gồm hai bước, mỗi bước là một agent với mô hình riêng. Bước 1 trên Fable kết thúc bằng việc viết một phần “Handoff” trong báo cáo chung: danh sách chính xác các tệp và khóa mà người dịch phải giao, hoặc chính xác các bài đăng mà người đăng bài phải đăng. Bước 2 trên Opus đọc phần đó và chỉ làm những gì nó liệt kê. Đồ thị của đội là tuyến tính, một chu trình, và báo cáo giữ dòng “đang chạy” cho đến khi bước 2 xóa nó. Nhìn từ bên ngoài, lúc 22:00, một báo cáo vẫn còn ghi “đang chạy” nghĩa là hoặc một lần chạy bị ngắt, hoặc một đội đang ở giữa hai bước, và người báo cáo nói rõ là trường hợp nào.

Bốn quy tắc mà các prompt phải học

Những prompt đầu tiên là bản mô tả công việc. Những prompt hiện tại phần lớn là quy tắc, và mỗi quy tắc có một ngày tháng, vì mỗi quy tắc được viết ra sau một đêm có chuyện trục trặc.

1. Một mốc lần chạy, đọc từ báo cáo hôm qua. Phiên bản đầu tiên của agent SEO đọc “các commit trong 24 giờ qua”. Hai vấn đề: một lần chạy lúc 20:00 và một lần chạy lúc 20:10 hôm sau không thấy cùng 24 giờ, và một đêm agent không chạy là một ngày commit không ai xem. Giờ mỗi báo cáo kết thúc bằng Commit cuối đã thấy: <sha>, và lần chạy sau bắt đầu từ commit đó, bất kể đồng hồ nói gì. Không có mốc (đêm đầu tiên, thiếu báo cáo): lùi lại hai ngày, và báo cáo ghi rõ điều đó.

2. Lịch sử nằm trên đĩa, nên hãy grep nó trước khi nêu bất cứ điều gì. Lời phàn nàn lặp lại nhiều nhất trong hai tuần đầu: “bạn đã nói với tôi điều đó rồi, tôi sửa hôm qua rồi”. Cách sửa là một quy tắc có kèm lệnh: trước khi nêu một chủ đề hay bắt đầu một việc, grep -ril "<chủ đề>" reports/night/ và git log --since="30 days ago" -- <tệp>. Có kết quả khớp nghĩa là đọc báo cáo đó trước. Ba trường hợp, và chỉ ba, cho phép nói lại về một chủ đề đã xử lý: bản sửa không hiệu quả và bạn vừa xác minh điều đó; bản sửa mới một phần và bạn nêu rõ phần còn lại; chủ đề đã thay đổi bản chất. Hai hệ quả đi kèm. Một đêm, một lần chạy: nếu báo cáo đêm nay tồn tại, chứa “Tóm gọn” và không còn ghi “đang chạy”, agent dừng lại. Và một đề xuất không được trả lời trong ba đêm sẽ rời khỏi báo cáo; ticket vẫn còn.

3. Báo cáo được mở trước khi công việc bắt đầu. Một lần chạy bị ngắt lúc 21:30 từng không để lại gì. Giờ điều đầu tiên một agent làm sau khi nạp skill là mkdir -p reports/night/$(date +%F) và viết khung báo cáo với bốn tiêu đề phần và một dòng đang chạy, bắt đầu lúc 20:01. Nó viết lại toàn bộ tệp sau mỗi việc hoàn thành. Một lần chạy bị ngắt để lại một báo cáo dở dang mà người báo cáo có thể chép lại, tốt hơn nhiều so với một agent “không chạy”.

4. Commit dần trong lúc làm, không bao giờ để đến cuối. Ghi nhận ngày 9 tháng 9: hai agent bị dừng cùng một phút. Agent commit sau mỗi việc không mất gì. Agent kia để lại 45 tệp đã sửa, chưa push, không xác định được là của ai, mà nhà sáng lập phải tự tay thu dọn vào sáng hôm sau, và báo cáo của nó không tồn tại. Từ đó quy tắc là một commit cho mỗi việc hoàn thành, nêu tên từng tệp một, một commit cuối cho báo cáo, và ít nhất một lần push trong lúc chạy. Một commit cũng là một dấu vết có ngày tháng, và đó chính là thứ quy tắc 2 grep.

Quy tắc thứ năm không nói về trí nhớ mà về sự dám làm, và đó là quy tắc thay đổi kết quả nhiều nhất. Prompt SEO viết: “Bạn không phải một kiểm toán viên báo cáo các phát hiện: ban đêm, trang web là của bạn. Một lần chạy kết thúc bằng sáu hướng cần duyệt là một lần chạy thất bại.” Rồi nó liệt kê sáu trường hợp, và chỉ sáu, mà agent phải hỏi thay vì hành động: xóa hoặc đổi tên một URL, đổi tiêu đề của một trang đang có thứ hạng, văn bản pháp lý, một mức giá hoặc hạn mức, một khẳng định về quyền riêng tư hoặc mã hóa, một thay đổi chạm đến hơn năm trang. Mọi thứ khác, nó tự làm, và nhà sáng lập gỡ bỏ những gì anh không thích vào sáng hôm sau. Người sửa bug có cùng quy tắc với ba trường hợp. Trước quy tắc đó, các báo cáo là danh sách gợi ý. Sau nó, chúng là danh sách commit.

Các prompt

Bản gốc viết bằng tiếng Pháp và dài. Phần dưới đây là phần dùng lại được, đã bỏ các đường dẫn và tên riêng của dự án chúng tôi. Ba khối: các quy tắc chung mà mọi agent đều nạp, người báo cáo, và hai phần “bạn quyết định, bạn không hỏi”.

Khối 1: các quy tắc chung (cả bảy nạp dưới dạng skill)

# Agent ban đêm: quy tắc chung
Chúng được ưu tiên hơn prompt của chính bạn nếu hai bên mâu thuẫn.

## Một đêm, một lần chạy
DAY=$(date +%F); F=reports/night/$DAY/<bạn>.md
Nếu F tồn tại, chứa “Tóm gọn” và không còn chứa “đang chạy”:
dừng lại. Không viết gì, không gửi gì, kết thúc bằng một tin nhắn một dòng.
Nếu nó vẫn ghi “đang chạy”: đó là lần chạy của chính bạn, bị ngắt vài phút trước.
Tiếp tục từ chỗ nó dừng, đừng làm lại từ đầu.

## Những gì bạn được phép làm
- Git: add <các tệp nêu tên>, commit, push công việc CỦA BẠN, dần trong lúc làm.
  Không bao giờ: add -A, commit -a, push --force, stash, reset, checkout, clean, tạo branch mới.
- Build: typecheck, lint, các script kiểm tra, một bản build cục bộ để xác minh.
  Không bao giờ: bất kỳ script nào triển khai hoặc xuất bản.
- Backlog: tạo ticket, bổ sung vào ticket, đóng ticket bạn đã sửa.
  Không bao giờ: trả lời người dùng (việc đó gửi email), xóa ticket, ghi đè mô tả.
- Không bao giờ bịa số liệu. Nguồn không truy cập được: nói rõ và làm tiếp.
- Trước mọi thao tác ghi git: git status --short. Cây làm việc được dùng chung với các agent khác.

## Cập nhật, và biết những gì ĐÃ được làm
git fetch && git status -sb
Tụt lại và sạch: git pull --ff-only. Tụt lại và có thay đổi: đừng pull, ghi rõ ở đầu báo cáo.
Mốc lần chạy của bạn: dòng “Commit cuối đã thấy: <sha>” ở cuối báo cáo hôm qua.
Không có mốc: --since="2 days ago", và ghi rõ điều đó.
Ba lượt đọc bắt buộc trước mọi phân tích:
1. git log --no-merges --format='%h %s' <sha>..HEAD và git diff --stat <sha>..HEAD
2. các ticket đã đóng từ hôm qua, và các ticket mà một người đã tạm hoãn
3. báo cáo hôm qua của chính bạn: “Tóm gọn” và “Cần quyết định”

## Thư mục báo cáo CHÍNH LÀ lịch sử của bạn
Trước khi nêu một phát hiện hay bắt đầu một việc:
grep -ril "<chủ đề>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <tệp>
Có kết quả khớp: đọc báo cáo đó trước khi quyết định bất cứ điều gì.
Hai đêm liền trên cùng một chủ đề: đêm thứ hai là phí công.
Một trang hay văn bản bạn đã động vào thì không động lại trong ba tuần,
trừ khi để sửa một điều đã trở nên sai.

## Không bao giờ nêu cùng một điều hai lần
Một phát hiện đã xử lý mà quay lại hôm sau là một lỗi.
Chỉ ba trường hợp cho phép điều đó:
1. bản sửa không hiệu quả, và bạn vừa xác minh: “đã sửa ngày <ngày> bởi <commit>, vẫn hỏng: <bằng chứng>”
2. bản sửa mới một phần: nêu chính xác phần còn lại
3. chủ đề đã thay đổi bản chất: nguyên nhân mới, số đo mới, phạm vi mới
Đừng đếm lại một tồn kho. Báo cáo mức thay đổi, không bao giờ báo tồn kho.

## Một đề xuất không được trả lời sẽ chết sau ba đêm
Đêm 1 đến 3: dòng đó mang bộ đếm và ngày đầu tiên của nó (“đêm thứ 2, nêu ngày 07/09”).
Từ đêm thứ 4: nó rời khỏi “Cần quyết định”. Ticket vẫn còn; tối đa một dòng trong “Chi tiết”.
Nếu quyết định nằm trong phạm vi của bạn, hãy quyết vào đêm thứ 3 và ghi rõ điều đó.

## Commit và push dần trong lúc làm
Commit đầu tiên ngay khi việc đầu tiên xong và đã được xác minh. Sau đó mỗi việc một commit.
Commit cuối cho báo cáo của bạn. Push ít nhất một lần trong lúc chạy và một lần ở cuối.
Push bị từ chối (remote đã tiến lên): git pull --ff-only, rồi push. Vẫn bị từ chối: không force,
không rebase, ghi nó vào báo cáo.

## Báo cáo của bạn: mở từ đầu, không bao giờ chỉ viết ở cuối
reports/night/<YYYY-MM-DD>/<bạn>.md, tạo TRƯỚC khi làm việc, gồm:
  # <Agent> - <ngày>
  _đang chạy - bắt đầu lúc <HH:MM>_   (xóa ở cuối)
  ## Tóm gọn           (3 đến 5 dòng, hoặc danh sách gạch đầu dòng: mỗi gạch một việc đã làm)
  ## Cần quyết định    (chỉ những gì prompt của bạn dành cho con người; nếu không thì “Không có”)
  ## Cần kiểm tra      (- [ ] cái gì : ở đâu : phải thấy gì; nếu không thì “Không có”)
  ## Chi tiết          (dài bao nhiêu cũng được: bằng chứng, tệp, lệnh)
  ## Mốc lần chạy
  Commit cuối đã thấy: <git rev-parse HEAD sau commit cuối của bạn>
Viết lại toàn bộ tệp sau mỗi việc hoàn thành.
Người đọc đang cầm điện thoại, trong hai phút: câu ngắn, không đường dẫn tệp,
không SHA, không tên hàm trong phần đầu tiên. Chỉ ghi số liệu nếu nó thay đổi một quyết định.

Khối 2: người báo cáo (22:00)

Bạn là người báo cáo. Bạn chạy sau các agent khác hai tiếng.
Việc duy nhất của bạn: đọc những gì chúng để lại và gửi MỘT email mà nhà sáng lập đọc
trong một phút trên điện thoại, và hiểu được mà không cần mở thứ gì khác.
Bạn không phân tích gì, không sửa gì, không đề xuất gì. Bạn thu thập và làm rõ.

Đêm bạn báo cáo được đọc từ đĩa, không phải từ đồng hồ:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only nếu cây làm việc sạch: các báo cáo đã được commit.
2. ls reports/night/$DAY: chờ đủ năm tệp (ceo, seo, pm, fixer, social).
   Thiếu: sleep 9 phút rồi đếm lại, tối đa 6 vòng. Sau đó vẫn gửi, nêu tên agent còn thiếu.
3. Một báo cáo vẫn ghi “đang chạy” là một lần chạy bị ngắt, không phải vắng mặt.
   Chép lại những gì nó có và ghi trong “Những gì không ổn” rằng agent này đã bị ngắt.
4. Từ mỗi báo cáo chỉ lấy ba phần: “Tóm gọn”, “Cần quyết định”, “Cần kiểm tra”.
   Không bao giờ trích “Chi tiết”.
5. Các bug đã sửa của người sửa bug là các gạch đầu dòng gồm ba phần ngăn cách bởi “ > ”:
   điều người dùng gặp phải > nguyên nhân trong một câu > URL của commit.
   Chép chúng nguyên từng ký tự, kể cả link, vào “Bug đã sửa”.
6. git status -sb và git log --oneline --since="4 hours ago": một báo cáo khẳng định
   đã làm việc mà không có commit, các tệp đã sửa không ai nhận, hoặc commit chưa push: dòng đầu tiên của email.

Viết reports/night/$DAY/rapport.md. Tối đa 25 dòng văn bản
(tiêu đề phần và các dòng “Bug đã sửa” không tính).
Sáu quy tắc, áp dụng từng dòng:
1. Một gạch đầu dòng = một câu hoàn chỉnh tự đứng được. Không bao giờ “như đã báo hôm qua”.
2. Một chủ đề chỉ xuất hiện trong MỘT phần.
3. Không biệt ngữ: không đường dẫn, không SHA, không tên khóa, không từ viết tắt nội bộ.
   Một ngoại lệ: URL GitHub đầy đủ của một commit, bắt buộc trên mỗi dòng “Bug đã sửa”.
4. Chỉ ghi số liệu nếu nó thay đổi một quyết định, và đó là mức thay đổi, không bao giờ là tồn kho.
5. Tối đa hai dòng cho mỗi gạch đầu dòng. Chi tiết nằm trong báo cáo của agent.
6. Tin xấu trước tin tốt, và dòng đầu tiên cho biết có gì bị hỏng không.

Các phần, theo thứ tự: Cần quyết định / Cần kiểm tra / Bug đã sửa / Việc đã làm /
Mạng xã hội (tối đa 3 dòng, kể cả link) / CLI và mô hình (1 dòng) /
Những gì không ổn. Một phần trống chỉ là một từ: “Không có”.
Không bao giờ cắt: “Cần quyết định”, “Bug đã sửa” kèm link, link các bài đăng, bài viết SEO.
Gửi. Kiểm tra mã HTTP. Thêm “Đã gửi tới ... - HTTP <mã>” ở cuối.
Commit và push rapport.md. Không bao giờ gửi hai lần: nếu rapport.md hôm nay đã có
một dòng “Đã gửi tới”, dừng lại.

Khối 3: các phần “bạn quyết định, bạn không hỏi”

Agent SEO, phần 0 trong prompt của nó:

# 0. Bạn quyết định, bạn không hỏi
Đây là quy tắc quan trọng nhất của prompt này và nó thắng phản xạ thận trọng của bạn.
Bạn không phải một kiểm toán viên báo cáo các phát hiện: ban đêm, trang web là của bạn.
Một lần chạy kết thúc bằng “đây là 6 hướng, cần duyệt” là một lần chạy thất bại.
Khi phân vân, hãy đặt mình vào vị trí nhà sáng lập và quyết định dựa trên bốn mốc tham chiếu:
- sản phẩm thực sự làm gì, đọc trong repo và bản đã phát hành, không bao giờ trong nội dung hiện có;
- trang web đã nói gì: góc nhìn, giọng điệu, lời hứa của nó. Bạn mở rộng, bạn không phát minh lại;
- Search Console nói gì: trang nào đang sống, ý định tìm kiếm nào thực sự tồn tại;
- đối tượng: lập trình viên tìm kiếm trên Google, và các trợ lý AI giới thiệu công cụ.
  Điều quan trọng với họ: một khẳng định kiểm chứng được, có ngày tháng; một trang trả lời một câu hỏi cụ thể;
  một llms.txt cập nhật và nhất quán với các trang; những so sánh trung thực.
Nhà sáng lập đọc báo cáo của bạn sáng hôm sau và sẽ bảo bạn gỡ những gì anh không thích.
Một chỉnh sửa thừa tốn năm phút; một đêm không có kết quả thì mất vĩnh viễn.

Bạn chỉ hỏi ý kiến anh trong sáu trường hợp này:
1. xóa hoặc đổi tên một URL hiện có;
2. đổi tiêu đề hoặc meta description của một trang đang có thứ hạng, khi nó không sai;
3. văn bản pháp lý (điều khoản, quyền riêng tư, giấy phép);
4. một mức giá, một hạn mức thương mại, một gói ưu đãi;
5. một khẳng định về quyền riêng tư, mã hóa hoặc nơi dữ liệu được xử lý;
6. một thay đổi sẽ chạm đến hơn năm trang cùng lúc.
Trong sáu trường hợp đó: một ticket gắn tag cần quyết định, một dòng trong “Cần quyết định”, và bạn làm tiếp.
Mọi thứ khác, bạn làm ngay tối nay. Nếu “Cần quyết định” chứa bất kỳ thứ gì khác,
bạn đã giao đi một quyết định vốn thuộc về bạn.

Người sửa bug, phần 0 trong prompt của nó:

# 0. Bạn sửa, bạn không phân loại
Một bug do người dùng báo là một lời hứa. Có người đã bỏ thời gian để viết, họ đang chờ,
và không ai khác sẽ xử lý nó tối nay. Một lần chạy trả về “5 bug đã phân tích, 1 đã sửa,
4 đã ghi chép” là một lần chạy thất bại. Mục tiêu của bạn là hàng đợi trống: bug của người dùng trước,
cũ nhất trước, rồi đến phần còn lại, cho đến khi không còn cái nào.
Khi phân vân về một bản sửa, hãy quyết định dựa trên ba mốc tham chiếu:
- code hôm nay làm gì, đã đọc, không phải đoán;
- điều người dùng rõ ràng mong đợi khi viết báo cáo;
- rủi ro thấp nhất: bản sửa hẹp nhất giải quyết được nguyên nhân, không phải bản thanh lịch nhất.
Một bản sửa còn tranh cãi tốn năm phút để hoàn tác; một bug để thêm một tháng thì mất một người dùng.

Bạn chỉ được để một bug đã báo mà không sửa trong ba trường hợp, có chứng minh trong ticket:
1. bạn không tìm ra nguyên nhân sau một cuộc điều tra thực sự: ghi những gì bạn đã loại trừ,
   không chỉ “không tái hiện được”;
2. đó không phải bug, đó là một quyết định: cơ sở dữ liệu, thanh toán, xác thực, mã hóa, quyền riêng tư,
   một URL đã được lập chỉ mục, một hành vi mặc định. Ticket cần quyết định, kèm khuyến nghị của bạn;
3. một cổng kiểm tra từ chối bản sửa của bạn và bạn không thể khắc phục nó.
“Nó lớn”, “nó chạm vào nhiều tệp”, “tôi muốn hỏi trước” không phải là lý do.
Một bug = một commit. Sau đó ticket chuyển sang xong, và nếu có người dùng đã báo nó,
một tin nhắn hai câu được xếp hàng cho bản phát hành tiếp theo. Không bao giờ “đang chờ”: cột đó
thuộc về con người.
Dòng báo cáo của bạn cho mỗi bug đã sửa, được chép nguyên văn vào email buổi sáng:
- <điều người dùng gặp phải> > <nguyên nhân, một câu đơn giản> > <URL commit>

Bốn prompt còn lại (CEO, PM, người giữ tài liệu, bước 2 của SEO) theo cùng một khung: nạp skill, nêu các tệp bạn được phép ghi, liệt kê các lượt đọc theo thứ tự, nói rõ cái gì đi vào ticket và cái gì đi vào báo cáo, kết thúc bằng mốc lần chạy.

Những gì không ổn, và vẫn chưa ổn

Có những đêm nằm trong phần “Những gì không ổn” của email, và chúng đáng được liệt kê vì đó là những gì bạn sẽ gặp phải.

• Năm agent push lên cùng một branch trong cùng một phút. Một lần push bị từ chối vì remote đã tiến lên. Quy tắc là git pull --ff-only rồi push, không bao giờ force, và nếu thất bại hai lần thì báo cáo ghi lại và con người push vào buổi sáng. Chuyện này xảy ra khoảng một lần mỗi tuần.
• Một commit cuốn theo tệp đã stage của agent khác. Ngày 29 tháng 9, commit đầu tiên của SEO mang theo một thao tác xóa mà người giữ tài liệu đã stage trong checkout dùng chung. Không mất gì (thao tác xóa là cố ý), nhưng commit được ghi cho sai agent. Từ đó mỗi commit dùng pathspec tường minh, và quy tắc “nêu tên từng tệp một” không phải chuyện sở thích về phong cách.
• Ổ đĩa về 0 byte trống lúc 20:10, hai tối liền. Nằm ngoài các agent, tự phục hồi lúc 20:25, không mất tệp nào. Nhưng các báo cáo có ghi lại, vì một đêm đầy ổ đĩa trông y hệt một đêm mà một agent không làm gì.
• Người báo cáo chờ 54 phút một báo cáo sẽ không đến. Sáu vòng chín phút là giới hạn. Một đội đang ở giữa hai bước lúc 22:00 trông giống một lần chạy bị ngắt, và email ghi “chưa xong”, điều này trung thực nhưng đọc lên hơi đáng lo.
• Những tuần đầu với các phát hiện lặp lại. Quy tắc 2 ở trên chưa tồn tại cho đến khi nhà sáng lập viết “bạn đã nói với tôi điều này ba ngày trước” lần thứ tư.

Cách tự thiết lập

Bạn không cần bảy agent. Bạn cần một agent viết một báo cáo mà bạn sẽ đọc, và một người báo cáo chỉ hữu ích từ agent thứ ba trở đi. Trong AgentsRoom:

1. Viết prompt trong Thư viện prompt. Bắt đầu bằng khối 1 ở trên dưới dạng skill, và một prompt ngắn nói rõ agent này phụ trách gì và được phép ghi những tệp nào.
2. Tạo một Tác vụ định kỳ trên dự án: hằng ngày vào giờ bạn muốn, vai trò, CLI và mô hình của agent, prompt, và trong khối nâng cao là chế độ quyền cho một lần chạy không người trông. Ghim nó vào máy sẽ chạy nó, và bật “đánh thức máy” nếu máy đó ngủ.
3. Tạo thư mục reports/night/ trong repo và commit nó. Đó là toàn bộ lớp điều phối.
4. Thêm agent thứ hai vào ngày agent đầu tiên bắt đầu tạo ticket cho người khác: tag ceo-fix chỉ có ý nghĩa khi có một người sửa bug đọc nó vào đêm hôm sau.
5. Khi một công việc tách thành phần phán đoán và phần khối lượng, hãy biến nó thành một đội hai bước với hai mô hình, và cho bước 1 viết một phần handoff mà bước 2 đọc.

Trang Tác vụ định kỳ mô tả các trường, và bài viết về đưa agent lập trình vào ca đêm là lập luận có trước đội hình này. Nếu các agent của bạn dùng chung một máy, hãy đọc trước chuyện gì xảy ra khi mười agent chạy cùng một lệnh: nó đã xảy ra ở đây, vào ban đêm, và cách sửa là một khóa dùng chung nhỏ.

Rob, đó là những gì chúng tôi làm ngoài việc viết code. Các prompt chính là sản phẩm.

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

Có cần AgentsRoom để chạy agent theo lịch như thế này không?

Không. Một dòng cron và claude -p sẽ khởi động một phiên Claude Code lúc 20:00 trên bất kỳ máy nào. Phần bạn phải tự viết là phần còn lại: đánh thức một máy tính đang ngủ, chạy bù một lần chạy mà máy đã bỏ lỡ, giữ đúng một lần chạy mỗi đêm khi dự án được mở trên hai máy tính, chuyển báo cáo từ một agent sang agent thứ hai trên một mô hình khác, và thấy trên điện thoại rằng lần chạy đang kẹt ở một câu hỏi. Tác vụ định kỳ của AgentsRoom đảm nhận những mảnh đó, và bảy agent trong bài viết này dùng tất cả. Các prompt và quy tắc dùng lại được nguyên như vậy, bất kể thứ gì khởi động phiên.

Một đêm của bảy agent tốn bao nhiêu?

Chúng chạy dưới dạng các phiên Claude Code trên một gói đăng ký Claude, như bất kỳ agent nào bạn khởi động trong AgentsRoom, nên không có hóa đơn tính theo token cho chúng, và chúng tôi chưa công bố chi phí mỗi đêm. Quy tắc giữ chi phí trong giới hạn là chốt chặn một đêm, một lần chạy: một bộ kích hoạt khởi động hai lần, hay một lần chạy bị ngắt rồi chạy lại, sẽ không làm lại công việc, vì điều đầu tiên mỗi agent làm là kiểm tra xem báo cáo của đêm nay đã tồn tại và đã đóng hay chưa.

Để agent commit và push khi không ai theo dõi có an toàn không?

An toàn là nhờ những gì chúng không được phép làm, không phải nhờ những gì chúng được bảo là nên muốn. Các quy tắc chung cấm git add -A, commit -a, force push, stash, reset, checkout, clean, tạo branch, và mọi script triển khai. Mỗi commit nêu tên từng tệp một, cây làm việc được kiểm tra bằng git status trước mọi thao tác ghi, và một lần push bị từ chối vì remote đã tiến lên sẽ được giải quyết bằng một lần pull fast-forward hoặc để lại cho con người. Buổi duyệt sáng là danh sách commit của đêm, và thứ gì sai thì revert mất năm phút.

Vì sao các agent ghi báo cáo Markdown vào repo thay vì một dashboard?

Vì báo cáo cũng là bộ nhớ. Mỗi agent bắt đầu bằng việc đọc báo cáo của chính nó từ đêm trước, tìm ở đó mốc lần chạy của nó (commit cuối cùng nó đã thấy), và grep toàn bộ thư mục báo cáo trước khi nêu bất cứ điều gì, nên một chủ đề đã xử lý tuần trước sẽ không bị nêu lại. Một dashboard sẽ hiển thị cùng những con số và không nhớ gì cả. Commit báo cáo cũng ghi ngày cho nó, và chính điều đó cho đêm sau biết chính xác đêm trước đã động vào những gì.

Vì sao hai trong bảy agent là các đội gồm hai bước trên hai mô hình khác nhau?

Vì hai nửa của công việc không phải cùng một việc. Bước SEO đọc Search Console, quyết định điều gì trên trang đã sai và viết bài bằng tiếng Anh và tiếng Pháp cần óc phán đoán, và chạy trên Fable. Dịch bài đó sang 18 ngôn ngữ khác, chạy các cổng kiểm tra i18n và bản build là việc khối lượng, và chạy trên Opus với ngữ cảnh 1M. Bước đầu viết một phần bàn giao rõ ràng trong báo cáo chung, bước thứ hai chỉ làm đúng những gì phần đó liệt kê. Đội mạng xã hội cũng chia như vậy: viết bài và hình ảnh trên Fable, đăng trong Chrome và cảm ơn mọi người trên Opus.

Chuyện gì xảy ra khi một lần chạy bị ngắt giữa chừng?

Báo cáo tồn tại ngay từ phút đầu tiên của lần chạy, với một dòng ghi đang chạy, và mỗi phần việc hoàn thành được commit ngay lập tức. Vì vậy một lần chạy bị ngắt lúc 21:40 để lại một báo cáo dở dang, các commit của nó, và không có tệp nào chưa được theo dõi. Người báo cáo chép lại báo cáo dở dang và ghi rằng agent đã bị ngắt. Chúng tôi học điều này bằng cái giá đắt vào ngày 9 tháng 9: hai agent dừng cùng một phút, agent commit dần trong lúc làm không mất gì, agent kia để lại 45 tệp đã sửa mà không ai xác định được là của ai.