七個 AI 代理替我們守夜：程式設計之外的定時代理，附完整提示詞

9 月 23 日，一位名叫 Rob 的使用者在我們的公開待辦清單上寫道：「would love to get examples of how you guys are doing stuff beyond coding」（想看看你們在程式設計之外都怎麼用的例子）。問得好。這個網站上的一切都在講程式設計代理，而我們每晚真正在跑的東西，大部分都不是程式設計。

從 8 月 28 日起，七個代理每晚 20:00 在一台 Mac mini 上啟動。它們讀當天的提交、Search Console、後台儀表盤、待辦清單、使用者發來的反饋、前一晚的報告。它們修 bug，修正網站內容，每三天寫一篇部落格文章並翻譯，在三個社交網路上發帖，更新一個產品知識庫；到了 22:00，第七個代理讀取另外六個留下的東西，發出一封 25 行的郵件。沒有人盯著。創始人第二天早上在手機上讀這封郵件。

這篇文章就是給 Rob 的回答。跑的是什麼，怎麼接線的，代理們如何在從不交談的情況下交接工作，哪個模型幹哪份活、為什麼，它們的提示詞吃了虧才學會的四條規則，以及濃縮成可複製程式碼塊的提示詞本身。下面的每一個數字都來自儲存庫：報告一晚接一晚地提交在那裡。

33 個夜晚產出了什麼

儲存庫裡的報告資料夾有 33 個帶日期的目錄，從 8 月 28 日到 9 月 30 日。讀下來是這樣：

• 彙報員發出的 31 封早間郵件。
• 修復員修好的 51 個 bug，每一個在它的報告行裡都附有提交連結。其中有幾個是使用者在公開待辦清單上報告的，並在下一個版本發布時收到了回覆。
• 自 9 月 10 日起 SEO 團隊寫的 7 篇部落格文章，每三天一篇，每篇先寫英語和法語，再在同一晚翻譯成另外 18 種語言。
• 29 天的社媒日誌：每晚三個網路和五個 Facebook 群組，外加在每一條有使用者分享了 AgentsRoom 的帖子下面留一條致謝評論。
• 一個約有一百張事實卡片的產品知識庫，按當天的提交保持更新，應用內助手會讀取它，網站則以 llms-full.txt 的形式對外提供。

20:00 之後，這些事都不需要人。其中一部分在早上 8:00 需要人，而這正是最後一個代理存在的意義。

陣容：20:00 誰在跑

每個代理都是 AgentsRoom 裡的一個定時任務：一段提示詞、一個代理（角色、CLI、模型）、一台機器和一個時間。七個都跑在 Claude Code 上。其中兩個不是單個代理，而是分兩步的團隊，原因後面再講。

最後一列的 .md 檔案都放在 reports/night/<date>/ 裡，已提交併推送。這個資料夾就是整個協調系統，下一節講為什麼。

怎麼接線的

七個都是同一種形態的定時任務：

• 每天 20:00 觸發（彙報員是 22:00）。沒有 cron 表示式，頻率在編輯器裡選。
• 固定在一台機器上。 專案在好幾台電腦上開啟著，除非你加以限制，否則觸發器會在每一台裝有該專案的機器上觸發。我們的觸發器限定在 Mac mini 上，所以 20:05 開啟的筆記本不會再啟動第二個 CEO。
• 喚醒機器。 Mac mini 會睡眠。任務有一個「喚醒機器」選項，會在執行前幾秒用作業系統自帶的工具（macOS 上是 pmset，Windows 上是開啟了喚醒執行的任務計劃程式，Linux 上是 rtcwake）預約一次喚醒。沒有這個選項，睡眠中的機器就會直接錯過這次執行。
• 補跑按任務開啟或關閉。 如果 20:00 時機器是關著的，開啟了補跑的任務會在下次啟動時觸發。CEO、PM 和彙報員開啟了補跑。SEO、修復員、社媒和文件任務關閉了補跑：第二天上午 11:00 才開始的執行，會在同一個檢出目錄裡和白天的工作撞車。
• 權限模式設在任務上，而不是設在 provider 上。無人值守的執行不能在凌晨 3 點卡在一個審批請求上，所以任務在無需審批的模式下執行，而創始人在同一個 CLI 上手動操作的代理，仍然會先徵求同意。
• 主控台空閒 60 分鐘後關閉。 跑完的代理不會一直待在側邊欄裡，等著有人去關。
• 提示詞就是第一條訊息。 每段提示詞的文字存放在提示詞庫裡，和觸發器的提示詞欄位是同一段文字，所以改一處就等於兩處都改了。提示詞是法語寫的，因為創始人用法語讀報告。其餘的一切，從提交資訊到知識庫，都是英語。

七個代理還共用一個部件：一個名為「夜間代理，共同規則」的技能。每段提示詞都以「載入這個技能並執行」開頭，技能裡裝著對所有代理都成立的內容：誰負責什麼、「一晚一次執行」守衛、git 權限、報告格式、待辦清單規則，以及給彙報員用的郵件格式。一條規則改動時，只在一個地方改。

它們如何不交談就交接工作

七個代理之間從不互發訊息。它們本可以這樣做，AgentsRoom 有代理間訊息，但一條訊息到第二天早上就看不見了，也沒法 grep。所有東西都經過三樣能挺過一夜的東西：

儲存庫。 每個代理寫 reports/night/<date>/<agent>.md，在執行的第一分鐘開啟它，每完成一項工作就重寫一遍，提交併推送。報告有四個固定小節：「簡而言之」（專案符號列表，每做完一件事一條）、「待決定」（只寫提示詞留給人的事）、「待檢查」（一個本地 URL 或一個要開啟的介面）、「詳情」（需要多長就多長）。最後以一個執行標記結尾：代理看到的最後一次提交。

待辦清單。 一個代理發現了該由別的代理做的工作，它自己不做。它開一張帶標籤的工單：ceo-fix 給一個已核實的小 bug，修復員會接手；ceo-seo 給一項帶目標搜尋詞的內容工作；ceo-decision 給任何需要人來定的事（資料庫、計費、認證、加密、價格、已被收錄的 URL、預設行為）。文件員在讀提交時發現某個功能在網站上沒有頁面：它提一張 ceo-seo 工單，下一晚由 SEO 接手。CEO 在讀錯誤日誌時發現一個 bug，且原因就在程式碼裡：ceo-fix，下一晚由修復員接手。

昨天的報告。 在開始任何一項工作之前，每個代理都會讀自己前一晚的報告，外加白天關閉的工單列表。它昨天指出的問題，常常在白天就已經修好了。已經處理過的話題不再提，已經開著的工單不再重建。

閉環靠人來完成。彙報員的郵件以一行結尾：要回復產品經理，就在 rapport.md 末尾加一個「## 決定」小節（P1 OK / P2 不行：理由 / P3 以後再說），提交，推送。PM 在下一晚讀取推送後的版本，執行被批准的內容：建立工單，合併重複項，其餘的註明理由後擱置。一個連續三晚沒有答覆的決定本身就是一個決定：這條提議從郵件裡撤下，以工單的形式留著。

哪個模型幹哪份活，為什麼

上面的表格裡出現了兩個模型。這是當前的配置，不是基準測試，而且會變。但這種拆分是有意為之的。

活的核心是判斷時，用 Fable。 CEO 要判斷預言機收到的一個差評是真正的錯誤還是個人偏好。修復員要判斷一份 bug 報告是真的 bug 還是某台機器特有的配置，然後在程式碼裡找到原因。SEO 的第 1 步要決定今天的提交讓網站上的哪句話變得不對了，寫哪篇文章，哪一頁不去碰。社媒的第 1 步要挑當晚的主題，併為一群三行之內就能認出生成文字的讀者寫作。這些提示詞都很長（SEO 那段大約 4,000 詞），充滿了「你來決定，不要問」的規則，外加簡短的例外清單。最強的模型正是在這裡物有所值。

活的核心是體量時，用 1M 上下文的 Opus。 用子代理（每個負責三種語言）把一篇文章翻譯成 18 種語言，再對照法語參考版檢查合併結果，這是大量的讀和寫，同樣的規則要執行 18 遍。文件員要拿一天的 diff 對照上百張事實卡片來讀。PM 要讀一份 8 MB 的退出對話匯出檔案。彙報員讀五份報告然後照抄，它不需要思考。在這些地方，大上下文和更低的單 token 成本比判斷力更重要。

所以七個代理中有兩個是分兩步的代理團隊，每一步都是一個擁有自己模型的代理。跑在 Fable 上的第 1 步，最後會在共享報告裡寫一個「交接」小節：翻譯員必須交付的檔案和鍵的精確清單，或者發布員必須發出的帖子的精確內容。跑在 Opus 上的第 2 步讀取這個小節，只做它列出的事。團隊的流程圖是線性的，只有一個週期，報告會一直保留「執行中」這一行，直到第 2 步把它刪掉。從外面看，22:00 時仍標著「執行中」的報告，要麼是一次被切斷的執行，要麼是一個處在兩步之間的團隊，彙報員會寫明是哪一種。

提示詞不得不學會的四條規則

最早的提示詞是崗位說明書。現在的提示詞大多是規則，每條規則都有一個日期，因為每一條都是在某個出了岔子的夜晚之後寫下的。

1. 一個執行標記，從昨天的報告裡讀。 SEO 代理的第一個版本讀的是「過去 24 小時的提交」。兩個問題：20:00 的一次執行和第二天 20:10 的一次執行看到的不是同樣的 24 小時；而代理沒跑的那一晚，就會變成一整天沒人看的提交。現在每份報告都以 最後看到的提交：<sha> 結尾，下一次執行從這個提交開始，不管時鐘怎麼說。沒有標記（第一晚、報告缺失）：往回看兩天，並在報告裡寫明。

2. 歷史就在磁碟上，所以提任何問題之前先 grep。 頭兩週裡被抱怨得最多的是：「你已經跟我說過了，我昨天就修好了。」解決辦法是一條裡面帶命令的規則：在指出一個話題或開始一項工作之前，先跑 grep -ril "<話題>" reports/night/ 和 git log --since="30 days ago" -- <檔案>。有匹配就先讀那份報告。允許重提一個已處理話題的情況有三種，只有三種：修復沒起作用，而你剛剛驗證過；修復只完成了一部分，你要點明剩下的是什麼；話題的性質變了。隨之而來還有兩條推論。一晚一次執行：如果今晚的報告已經存在，包含「簡而言之」，並且不再寫著「執行中」，代理就停下。還有，一條連續三晚沒有答覆的提議從報告裡撤下，工單保留。

3. 報告在工作開始之前就開啟。 過去一次在 21:30 被切斷的執行什麼都不會留下。現在，代理在載入技能之後做的第一件事，就是 mkdir -p reports/night/$(date +%F)，然後寫好報告骨架，帶上四個小節標題和一行 執行中，20:01 開始。每完成一項工作就把整個檔案重寫一遍。被切斷的執行會留下一份彙報員可以照抄的不完整報告，這比一個「沒跑」的代理好得多。

4. 邊做邊提交，絕不留到最後。 9 月 9 日實測：兩個代理在同一分鐘被停掉。每完成一項工作就提交的那個什麼都沒丟。另一個留下了 45 個已修改、未推送、無法認領的檔案，創始人第二天早上只能手動收拾，而它的報告根本不存在。從那以後規則是：每完成一項工作提交一次，檔案逐個點名，最後為報告單獨提交一次，執行期間至少推送一次。提交同時也是一條帶日期的痕跡，而這正是規則 2 要 grep 的東西。

第五條規則講的不是記憶而是勇氣，也是最能改變產出的那一條。SEO 的提示詞寫道：「你不是一個彙報發現的審計員：到了夜裡，網站歸你管。一次以六條待確認線索收尾的執行，就是一次失敗的執行。」接著它列出了六種、也只有六種代理必須先問而不是直接動手的情況：刪除或重新命名一個 URL，修改一個有排名的頁面的標題，法律文字，價格或配額，關於隱私或加密的說法，一次會動到五個以上頁面的改動。其他的一切它都自己做，創始人第二天早上把不喜歡的刪掉。修復員也有同樣的規則，例外是三種情況。在這條規則之前，報告是一串建議。有了它之後，報告是一串提交。

提示詞

原版是法語，而且很長。下面是可以搬走的部分，去掉了我們專案特有的路徑和名稱。三個程式碼塊：每個代理都會載入的共同規則、彙報員，以及兩段「你來決定，不要問」。

程式碼塊 1：共同規則（七個代理都以技能形式載入）

# 夜間代理：共同規則
如果與你自己的提示詞衝突，以本規則為準。

## 一晚一次執行
DAY=$(date +%F); F=reports/night/$DAY/<你>.md
如果 F 存在，包含「簡而言之」，並且不再包含「執行中」：
停下。什麼都不寫，什麼都不發，用一行訊息結束。
如果它仍寫著「執行中」：那是你自己的執行，幾分鐘前被切斷了。
從停下的地方接著做，不要從頭再來。

## 你可以做什麼
- Git：add <點名的檔案>、commit、push 你自己的工作，邊做邊來。
  禁止：add -A、commit -a、push --force、stash、reset、checkout、clean、新建分支。
- 建置：typecheck、lint、檢查腳本、用於驗證的本地建置。
  禁止：任何會部署或發布的腳本。
- 待辦清單：建立工單、在工單後追加內容、關閉你修好的工單。
  禁止：回覆使用者（那會發出一封郵件）、刪除工單、覆蓋描述。
- 絕不編造數字。資料來源不可用：照實說，然後繼續。
- 任何 git 寫操作之前：git status --short。工作樹是和其他代理共用的。

## 跟上進度，並弄清哪些事「已經」做過
git fetch && git status -sb
落後且乾淨：git pull --ff-only。落後且有未提交改動：不要 pull，在報告開頭寫明。
你的執行標記：昨天報告末尾那一行「最後看到的提交：<sha>」。
沒有標記：--since="2 days ago"，並寫明。
任何分析之前必須讀的三樣東西：
1. git log --no-merges --format='%h %s' <sha>..HEAD 和 git diff --stat <sha>..HEAD
2. 昨天以來關閉的工單，以及被人設為暫緩的工單
3. 你自己昨天的報告：「簡而言之」和「待決定」

## 報告資料夾就是你的歷史
在提出一個發現或開始一項工作之前：
grep -ril "<話題>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <檔案>
有匹配：在做任何決定之前先讀那份報告。
連續兩晚做同一個話題：第二晚是白費的。
你改過的頁面或文字，三週內不再碰，
除非是為了修正已經變得不對的內容。

## 同一件事絕不提兩次
一個已經處理過的發現第二天又冒出來，是一種過失。
只有三種情況允許：
1. 修復沒起作用，而你剛剛驗證過：「<date> 已由 <commit> 修復，仍然壞著：<證據>」
2. 修復只完成了一部分：準確點明剩下的是什麼
3. 話題的性質變了：新的原因、新的度量、新的範圍
不要重新清點存量。報告變化量，絕不報告存量。

## 沒有答覆的提議三晚後作廢
第 1 到第 3 晚：這一行帶上計數和首次提出的日期（「第 2 晚，9 月 7 日提出」）。
從第 4 晚起：它從「待決定」中撤下。工單保留；在「詳情」裡最多一行。
如果這個決定在你的職權範圍內，就在第 3 晚拍板，並寫明。

## 邊做邊提交、邊做邊推送
第一項工作完成並驗證後立刻做第一次提交。之後每項工作一次。
最後一次提交留給你的報告。執行期間至少推送一次，結束時再推送一次。
推送被拒（遠端已前進）：git pull --ff-only，然後 push。仍被拒：不要強推，
不要 rebase，寫進報告。

## 你的報告：開工時就開啟，絕不只在最後才寫
reports/night/<YYYY-MM-DD>/<你>.md，在工作「之前」建立，內容為：
  # <Agent> - <date>
  _執行中 - <HH:MM> 開始_   （結束時刪除）
  ## 簡而言之      （3 到 5 行，或專案符號列表：每做完一件事一條）
  ## 待決定        （只寫你的提示詞留給人的事；否則寫「無」）
  ## 待檢查        （- [ ] 查什麼：在哪裡：應該看到什麼；否則寫「無」）
  ## 詳情          （需要多長就多長：證據、檔案、命令）
  ## 執行標記
  最後看到的提交：<你最後一次提交之後的 git rev-parse HEAD>
每完成一項工作就把整個檔案重寫一遍。
讀者用手機看，只看兩分鐘：句子要短，第一個小節裡不要有檔案路徑、
不要有 SHA、不要有函式名。只有會改變決定的數字才寫。

程式碼塊 2：彙報員（22:00）

你是彙報員。你在其他代理之後兩個小時執行。
你唯一的工作：讀它們留下的東西，發出「一封」郵件，讓創始人在手機上
一分鐘讀完，不用開啟任何別的東西就能看懂。
你不分析，不修復，不提議。你只彙總和理清。

你要彙報的那一晚從磁碟上讀，而不是看時鐘：
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch；如果工作樹乾淨就 git pull --ff-only：報告都是提交過的。
2. ls reports/night/$DAY：等五個檔案（ceo, seo, pm, fixer, social）到齊。
   缺了：sleep 9 分鐘再數，最多 6 輪。然後照樣傳送，並點名缺了誰。
3. 仍寫著「執行中」的報告是一次被切斷的執行，不是缺席的執行。
   照抄它的內容，並在「沒成功的事」裡寫明這個代理被切斷了。
4. 每份報告只取三個小節：「簡而言之」「待決定」「待檢查」。
   絕不引用「詳情」。
5. 修復員修好的 bug 是用 " > " 分成三段的專案符號：
   使用者遇到的問題 > 一句話說明原因 > 提交的 URL。
   連同連結一字不差地照抄到「已修復的 bug」裡。
6. git status -sb 和 git log --oneline --since="4 hours ago"：聲稱做了工作卻沒有提交的報告、
   沒人認領的已修改檔案、未推送的提交：放在郵件第一行。

寫 reports/night/$DAY/rapport.md。正文最多 25 行
（小節標題和「已修復的 bug」的各行不計入）。
六條規則，逐行執行：
1. 一條專案 = 一個能獨立成立的完整句子。絕不寫「如昨天所報」。
2. 一個話題只出現在「一個」小節裡。
3. 零術語：不要路徑、不要 SHA、不要鍵名、不要內部縮寫。
   唯一例外：提交的完整 GitHub URL，「已修復的 bug」的每一行都必須有。
4. 只有會改變決定的數字才寫，而且寫的是變化量，絕不是存量。
5. 每條專案最多兩行。細節在代理的報告裡。
6. 壞訊息先於好訊息，第一行就說清楚是否有東西壞了。

小節順序：待決定 / 待檢查 / 已修復的 bug / 已完成的事 /
社交網路（最多 3 行，含連結） / CLI 與模型（1 行） /
沒成功的事。空的小節只寫一個詞：「無」。
絕不刪減：「待決定」、帶連結的「已修復的 bug」、帖子連結、SEO 文章。
傳送。檢查 HTTP 狀態碼。在底部追加「已傳送至 ... - HTTP <code>」。
提交併推送 rapport.md。絕不發兩次：如果今天的 rapport.md 裡已經有
一行「已傳送至」，就停下。

程式碼塊 3：「你來決定，不要問」的兩段

SEO 代理，提示詞第 0 節：

# 0. 你來決定，不要問
這是本提示詞最重要的一條規則，它壓過你想要謹慎行事的本能。
你不是一個彙報發現的審計員：到了夜裡，網站歸你管。
一次以「這裡有 6 條線索，請確認」收尾的執行，就是一次失敗的執行。
猶豫時，站在創始人的位置上，用四個參照來拍板：
- 產品真正做了什麼，從儲存庫和已發布的版本里讀，絕不從現有文案裡讀；
- 網站已經在說什麼：它的切入角度、語氣、承諾。你是延續，不是重新發明；
- Search Console 在說什麼：哪些頁面是活的，哪些搜尋意圖真實存在；
- 受眾：在 Google 上搜尋的開發者，以及推薦工具的 AI 助手。
  對他們重要的是：可驗證、可標註日期的說法；回答一個明確問題的頁面；
  與各頁面保持一致的最新 llms.txt；誠實的對比。
創始人第二天早上會讀你的報告，並告訴你把他不喜歡的刪掉。
多改一處的代價是五分鐘；一個沒有產出的夜晚永遠找不回來。

只有以下六種情況才徵求他的意見：
1. 刪除或重新命名一個現有 URL；
2. 修改一個有排名的頁面的標題或 meta description，而它並沒有錯；
3. 法律文字（條款、隱私、授權）；
4. 價格、商業配額、套餐承諾；
5. 關於隱私、加密或資料在哪裡執行的說法；
6. 一次會同時動到五個以上頁面的改動。
這六種情況：一張標註待決定的工單，「待決定」裡寫一行，然後繼續往下做。
其餘的一切，今晚就做。如果「待決定」裡出現了別的東西，
說明你把一個本該由你做的決定推給了別人。

修復員，提示詞第 0 節：

# 0. 你來修，不要分類
使用者報告的 bug 是一個承諾。有人花時間寫了下來，他在等，
而今晚沒有別人會處理它。一次交出「分析了 5 個 bug，修復 1 個，
記錄 4 個」的執行，就是一次失敗的執行。你的目標是清空佇列：先修使用者的 bug，
從最早的開始，然後是其餘的，直到一個不剩。
在修法上猶豫時，用三個參照來拍板：
- 程式碼今天實際在做什麼，讀過確認，而不是猜；
- 使用者寫報告時顯然期望的是什麼；
- 風險最小：能解決根因的最窄修復，而不是最優雅的那種。
一個有爭議的修復撤回只要五分鐘；一個 bug 多留一個月，就會失去一個使用者。

只有在以下三種情況下，才可以讓一個已報告的 bug 不修，並且要在工單裡給出證明：
1. 經過真正的排查仍沒找到原因：寫下你排除了什麼，
   而不只是「無法復現」；
2. 這不是 bug，而是一個決定：資料庫、計費、認證、加密、隱私、
   已被收錄的 URL、預設行為。開一張待決定的工單，附上你的建議；
3. 某道關卡拒絕了你的修復，而你修不好它。
「改動太大」「要動好幾個檔案」「我寧願先問」都不是理由。
一個 bug = 一次提交。然後工單移到已完成，如果是使用者報告的，
就準備一條兩句話的訊息，隨下一個版本一起發出。絕不放進「暫緩」：那一列
屬於人。
每個修好的 bug 在你報告裡的那一行，會原樣照抄進早間郵件：
- <使用者遇到的問題> > <原因，一句簡單的話> > <提交的 URL>

其餘四段提示詞（CEO、PM、文件員、SEO 第 2 步）都遵循同一個骨架：載入技能，點名你可以寫的檔案，按順序列出要讀的東西，說明什麼寫進工單、什麼寫進報告，最後以執行標記結尾。

沒成功的事，以及至今仍沒解決的事

有些夜晚出現在郵件的「沒成功的事」小節裡，值得列出來，因為你也會碰上。

• 五個代理在同一分鐘推送到同一個分支。 因為遠端已前進，推送被拒。規則是先 git pull --ff-only 再推送，絕不強推；如果連續失敗兩次，報告裡寫明，由人早上來推送。大約每週發生一次。
• 一次提交把另一個代理暫存的檔案一起帶走了。 9 月 29 日，SEO 的第一次提交帶上了文件員在共享檢出目錄裡暫存的一個刪除操作。沒有丟失任何東西（這個刪除本來就是想做的），但這次提交被記在了錯誤的代理名下。從那以後，每次提交都使用明確的路徑，「檔案逐個點名」這條規則不是風格偏好。
• 磁碟剩餘空間在 20:10 降到零位元組，連續兩個晚上。 與代理無關，20:25 自行恢復，沒有丟失檔案。但報告裡會寫出來，因為磁碟滿了的一晚，看上去和某個代理什麼都沒做的一晚一模一樣。
• 彙報員為一份不會來的報告等了 54 分鐘。 上限是六輪、每輪九分鐘。22:00 時處在兩步之間的團隊看起來就像一次被切斷的執行，郵件裡會寫「尚未完成」，這是誠實的，讀起來也有點讓人心驚。
• 頭幾週裡反覆提同樣的發現。 上面的規則 2，是在創始人第四次寫下「你三天前就跟我說過了」之後才有的。

自己怎麼搭

你不需要七個代理。你需要的是一個會寫出你真的會讀的報告的代理，而彙報員要從第三個代理開始才有用。在 AgentsRoom 裡：

1. 在提示詞庫裡寫提示詞。先把上面的程式碼塊 1 作為技能，再加一段簡短的提示詞，說明這個代理負責什麼、可以寫哪些檔案。
2. 在專案上建立一個定時任務：每天在你想要的時間，代理的角色、CLI 和模型，提示詞，並在高階區塊裡設定適合無人值守執行的權限模式。把它固定到負責執行的那台機器上，如果那台機器會睡眠，就開啟「喚醒機器」。
3. 在儲存庫裡建立 reports/night/ 資料夾並提交。這就是整個協調層。
4. 等第一個代理開始為別人產出工單的那天，再加第二個代理：只有當下一晚有修復員去讀它時，ceo-fix 標籤才有意義。
5. 當一份工作拆成判斷和體量兩部分時，把它做成一個分兩步、用兩個模型的團隊，並讓第 1 步寫一個供第 2 步讀取的交接小節。

定時任務頁面介紹了各個欄位，而那篇關於讓程式設計代理上夜班的文章，是這套陣容之前的思考過程。如果你的代理共用一台機器，請先讀當十個代理執行同一條命令時會發生什麼：這事就發生在這裡，在夜裡，解決辦法是一把小小的共享鎖。

Rob，這就是我們在程式設計之外做的事。提示詞就是產品。

常見問題

像這樣定時執行代理，需要 AgentsRoom 嗎？

不需要。一行 cron 加上 claude -p，就能在任何機器上於 20:00 啟動一個 Claude Code 會話。之後需要你自己寫的是剩下的部分：喚醒一台睡眠中的電腦，補跑機器錯過的執行，在專案同時在兩台電腦上開啟時保證每晚只執行一次，把一個代理的報告交給跑在另一個模型上的第二個代理，以及在手機上看到某次執行卡在一個問題上。AgentsRoom 的定時任務承擔了這些部件，本文的七個代理全部用上了。無論由什麼來啟動會話，提示詞和規則都可以原樣搬過去。

七個代理跑一晚要花多少錢？

它們和你在 AgentsRoom 裡啟動的任何代理一樣，以 Claude Code 會話的形式跑在 Claude 訂閱上，所以沒有按 token 計的帳單，我們也沒有公布每晚的成本。讓成本有上限的規則是「一晚一次執行」守衛：觸發了兩次的觸發器，或者中途被切斷又重啟的執行，都不會重複做同樣的工作，因為每個代理做的第一件事，就是檢查今晚的報告是否已經存在並且已經收尾。

在沒人盯著的時候讓代理提交和推送，安全嗎？

安全，靠的是它們不被允許做什麼，而不是它們被要求想要什麼。共同規則禁止 git add -A、commit -a、強制推送、stash、reset、checkout、clean、建立分支，以及任何會部署的腳本。每次提交都逐個點名檔案，任何寫操作之前都先用 git status 檢查工作樹，因為遠端已前進而被拒絕的推送，要麼用 fast-forward 的 pull 解決，要麼留給人來處理。早上的複查就是當晚的提交列表，有什麼不對，一次五分鐘的 revert 就能撤掉。

為什麼代理把 Markdown 報告寫進儲存庫，而不是做成儀表盤？

因為報告同時也是記憶。每個代理一開始先讀自己前一晚的報告，在裡面找到它的執行標記（它看到的最後一次提交），並在提出任何問題之前對整個報告資料夾做一次 grep，所以上週處理過的話題不會再被提一遍。儀表盤會顯示同樣的數字，卻什麼都記不住。提交報告還給它打上了日期，正是這一點讓下一晚能準確知道上一晚動過什麼。

為什麼七個代理中有兩個是分兩步、跑在兩個不同模型上的團隊？

因為這份工作的前後兩半不是同一種工作。讀 Search Console、判斷網站上哪些內容變得不對、用英語和法語寫文章的 SEO 步驟需要判斷力，跑在 Fable 上。把這篇文章翻譯成另外 18 種語言、跑 i18n 關卡和建置，是體量活，跑在 1M 上下文的 Opus 上。第一步在共享報告裡寫一個明確的交接小節，第二步只做這個小節列出的事。社媒團隊也是同樣的拆分：撰寫和配圖用 Fable，在 Chrome 裡發布和致謝用 Opus。

一次執行在中途被切斷會怎樣？

報告從執行的第一分鐘起就存在，裡面有一行寫著「執行中」，每完成一項工作就當場提交。所以一次在 21:40 被切斷的執行，會留下一份不完整的報告、它的那些提交，而不會留下未跟蹤的檔案。彙報員會照抄這份不完整的報告，並寫明這個代理被切斷了。這是我們在 9 月 9 日吃了虧才學到的：兩個代理在同一分鐘停下，邊做邊提交的那個什麼也沒丟，另一個留下了 45 個沒人能認領的已修改檔案。