我透過 6 個步驟、5 個提示詞與 1 個檔案，成功運行了 1,000 個 AI Agents（開發者指南）

好的，以下是根據您提供的詳細指引，將英文內容翻譯成的繁體中文（臺灣）版本。

Prompting 在 2024 年已死。新的技能是編排

我運行了 1,000 個 AI Agent 長達 30 天，這是我的發現

取代 Prompting 的技能，以及你今天就能運行的系統。

停止優化你的 Prompt。它不再是瓶頸了。

當你只有一個 Agent 在一個聊天視窗中運作時，Prompt 幾乎是全部。

當你有十個 Agent 連續運作數小時，Prompt 的成本幾乎可以忽略不計。

決定工作品質的是圍繞 Agent 的系統：

每個任務在哪種模式下執行
哪個模型負責哪個步驟
Agent 之間如何保持協調
在你睡覺時，如何驗證「完成」

一個 Prompt 給你一個輸出。一個循環給你一個疊代增值的操作。

轉變很簡單。你不再是那個閱讀每個結果然後輸入下個指令的人。你成為那個一次性設計好系統，然後讓它自行運轉的人。

那個設計層就是現在的工作。以下是建構它的方法。

你建立的是編排器，而不是程式碼

你不需要跟三十個 Agent 對話來管理它們。你只需要跟一個對話。那一個就是編排器，它負責管理其他的 Agent。

一個好的編排器只做三件事：

將一個目標分解成有邊界、可獨立檢查的子任務。
將每個子任務委派給一個工作者，並附上簡潔的任務摘要和明確的檔案所有權。
彙整結果，並決定下一步要做什麼。

有一條規則凌駕於所有規則之上：編排器永遠不親自做具體工作。

一旦你的主導 Agent 開始寫實作程式碼，它的上下文就會充滿細節，從而失去對整體工作的掌握。

保持它的上下文簡潔。它負責思考、拆分、指派和檢查。其他什麼都不做。

然後，要深入而非全面展開：

不要讓編排器直接產生八個工作者。那樣會破壞它的上下文。
讓它先產生兩到三個小組長。
讓每個小組長再產生它們自己各自的兩到三個專家。

這樣做的回報是，在相同的上下文成本下，你能獲得三倍的任務拆解深度。這也是真實組織擴展的方式：透過層級，而不是靠一個人指派所有任務。

可驗證或不可驗證：決定一切的關鍵區分

在你開始建構任何東西之前，先問一個關於任務的問題：機器能否檢查它是否已完成？

這個答案將決定你的整個方法。

如果任務是可驗證的，你就可以對它進行循環：

測試通過或不通過。
型別檢查通過或不通過。
基準測試達到門檻或沒達到。

把一個 Agent 指向一個可驗證的任務，它就能整晚不停優化。等你醒來，問題已經解決了。

如果任務是不可驗證的，單純的循環是行不通的。例如：

設計一個好的評估指標。
判斷一個 API 的設計是否「感覺」對了。
判斷某個研究方向是否值得投入。

對於這些，你需要注入品味和判斷。你不能直接把目標丟給 Agent 就不管了，因為沒有具體的檢查點。

所以，你的策略是盡可能讓更多的工作變成可驗證的：

把「把它做好」變成「通過這些具體的檢查」。
用具體的、可衡量的目標取代模糊的目標。
在無法完全自動化的地方，讓人工參與判斷並提供指導。

大多數編排工程的技術，就是將模糊的目標轉化為可檢查的目標，這樣循環才能接管工作。

從最簡單的實際系統開始：目標循環

目標循環是一個持續存在的目標加上一個確定性的檢查。Agent 會一步接著一步地朝向目標努力，而不是在一次回應後就停止。

整個系統就是一個圍繞著你的 Agent 和一個驗證器的循環：

bash

1i=0
2until npm test -s; do
3  agent -p "目標：讓測試套件全部變成綠色。
4            在修改任何東西之前，先閱讀程式碼並建立完整理解。
5            'npm test' 目前失敗。做出能讓它通過的最小改動。"
6  (( ++i > 20 )) && { echo "停止：已達 20 次疊代"; exit 1; }
7done

這個驗證器可以是任何其退出碼能作為檢查條件的指令。測試、型別檢查、程式碼風格檢查，或是一個自訂腳本。

有兩件事是必須的：

一個上限。沒有停止條件的循環，會讓你醒來時看到一筆天文數字的 Token 帳單。
一個先閱讀的指令。每個 Agent 預設的失敗模式，就是對第一個看似合理的修復方案隨意開槍，而不是先去閱讀程式碼。

強制它先閱讀。這樣每個步驟會慢一些，但整體速度會快得多。

讓「完成」無可妥協：裁判

Agent 會提前放棄。它們被訓練成一旦能找到理由，就會立刻停止。

「我已經盡力了，就此打住」並不等於「完成了」。

如果讓一個 Agent 給自己的作業打分，它會作弊。不是出於惡意，只是它會說服自己工作已經完成了。

解決方案是引入一個獨立的裁判：

第二個 Agent，唯一的工作是根據具體的評分標準來評估工作成果。
它只回答一個問題：完成了，或沒完成，以及缺少了什麼。
它沒有動機去停止工作，所以它不會敷衍了事。

讓建構者和裁判使用不同的模型家族。不同的模型家族會產生不相關的錯誤，因此裁判能看到建構者忽略的問題。

bash

1while :; do
2  agent --model "$BUILD" -p "任務：$TASK。先閱讀，再實作，最後執行測試。"
3  verdict=$(agent --model "$JUDGE" -p "嚴格的審查員。根據 rubric.md 中的每一項進行評分。
4            請僅回覆 'PASS' 或 'FAIL: <缺少的部分>'。")
5  [[ $verdict == PASS* ]] && break
6done

讓評分標準具體且二元化：

好的評分標準：「所有測試通過（包含遷移測試）、沒有除錯日誌。」
壞的評分標準：「把它做好。」

一個擁有否決權且利益不相關的檢查者，是讓一個任務能持續運行數小時而不會因為工作者疲乏而崩潰的關鍵。

在每個任務完成時都啟動它。這樣你只會看到被評為通過的工作成果。

真正執行工作的提示詞

Prompt 不是許願。對 Agent 來說，它是規格。

平庸的輸出和優秀的輸出之間的差距，幾乎全部取決於這些 Prompt 的品質。

保留一小組可重複使用的 Prompt。其中五個涵蓋了大部分的工作。

1. 為編排器準備的任務分解提示詞：

markdown

1你是編排器。不要寫程式碼。
2將這個目標分解成 3 到 6 個有邊界的子任務。
3針對每個子任務：一行摘要、它負責的具體檔案、以及它的完成檢查。
4標記任何依賴於其他任務的子任務。輸出列表，然後停止。
5目標：<目標>

2. 為專家工作者準備的任務簡報：

markdown

1你只負責這些檔案：<檔案列表>。
2任務：<一行描述>。完成條件：<可驗證的檢查>。
3在編輯之前，先閱讀這些檔案及其呼叫者。不要修改你負責範圍之外的任何檔案。
4完成後，寫一份 5 行的報告到 <名稱>.md，然後執行測試。

3. 為不同模型家族準備的裁判提示詞：

markdown

1你是一個嚴格、不講情面的審查員。你沒有撰寫這些程式碼。
2根據下方的每一項對這個倉庫進行評分。任何不符合都算 FAIL。
3<評分標準>
4請僅回覆一行：'PASS' 或 'FAIL: <缺少的部分>'。

4. 為計畫模式準備的計畫優先提示詞：

markdown

1為 <目標> 產生一份書面計畫。內容包括：方法、要修改的檔案、
2邊界情況、測試策略，以及你明確不會做的事。
3目前不要寫任何程式碼。在計畫完成後停止，以便我進行審查。

5. 當 Agent 卡住時使用的反思或中止提示詞：

markdown

1你已經連續 3 次在同一個檢查上失敗了。停止重複同樣的方法。
2用 3 行回答：具體是什麼失敗了、哪個假設是錯誤的、
3以及最小改變的嘗試方案是什麼。然後只嘗試那個方案。

這五個提示詞都遵循一個模式：說明角色、設定邊界、定義完成檢查、以及明確不要做的事。

模型路由：每個人都在問的問題

這個問題通常被框架化為一個選擇。我應該把昂貴的模型用在規劃上，還是實作上？

這是錯誤的框架。應該根據影響範圍來路由。問問自己：哪裡的錯誤會讓你付出最大代價？

邏輯很簡單：

規劃階段的一個錯誤決定，會影響到你的整個（Agent）艦隊。
一個邊界明確、經過測試的函數中的一個小錯誤，幾分鐘內就會被發現。
所以，你應該把錢花在錯誤成本高且不可逆的地方，在錯誤成本低且影響範圍可控的地方省錢。

以下是按層級劃分的路由策略：

規劃、架構和任務分解：永遠使用頂級模型。影響最大，Token 用量極低。在這裡省錢，是你可能犯下的最昂貴的錯誤。
有明確規格的實作：使用中階模型，並行運行。規格說明已經完成了思考工作。用測試來驗證。
規格模糊的實作：使用頂級模型。填補空白是推理工作，便宜的模型會在數十個方向上猜錯。
審查和評判：使用不同家族，且不應是便宜的模型。這是你抓住昂貴錯誤的機會。
導航、搜尋、摘要和分類：使用最便宜、最快的模型。零推理需求，高處理量。永遠不要為這些工作支付高額費用。

所以，對「便宜的規劃還是便宜的實作？」這個問題的真正答案是，兩者都不是盲目選擇的。

永遠將頂級模型用於規劃和審查。實作則是可以根據情況調整的變數。

不同的模型家族也有不同的「性格」，這對路由來說很重要：

一個家族擅長填補空白。當規格模糊時，它會做出合理的假設並繼續前進。當假設正確時這很有幫助，但假設錯誤時則有害。
另一個家族則非常「照本宣科」。它會完全按照你說的做，不會多做，就像一把精準的多功能刀。

在需要開放式探索、規格模糊的工作上，使用擅長填補空白的模型。在審查和需要精確、明確修改的工作上，則使用照本宣科的模型。

控制實作的槓桿就是你的規格

一個緊湊的規格，讓你有資格運行便宜、可並行的工作者。
一個模糊的規格，會迫使你再次使用昂貴的模型來填補空白。

精確地投資於規劃階段，正是為了能夠便宜地進行建構階段。

有一個陷阱值得指出。便宜的路由優化了每次呼叫的價格，但它可能悄悄地破壞了那些能夠產生可出貨、可合併輸出的 Token 比例。

一個便宜的模型重試了五次，卻產生了你無法合併的程式碼，這比一個高級模型一次乾淨的執行更昂貴。

應該衡量的是「有用輸出」的成本，而不是每次呼叫的成本。

為了規模化，兩個數字很有幫助：

你的頂級模型每 Token 的輸出價格，大約是廉價層級的 5 倍。
透過分層路由，通常可以將總花費削減 40% 到 60%，相比於到處都使用最好的模型。

技能：封裝工作流程，一次解決，永久重用

當你不斷貼上同一個 Prompt 或運行同一個工作流程時，將它變成一個技能。

技能是一個小型指令檔案，Agent 只有在相關時才會載入它。

你只需編寫一次工作流程，每個 Agent 都能使用它。

一個技能檔案包含兩部分：

帶有名稱和描述的 YAML 前置資料。
包含實際指令的 Markdown 正文。

描述是最重要的一行。它告訴 Agent 這個技能是做什麼的，以及何時該使用它，這樣 Agent 就能自己識別並使用它，而不需要你手動指定。

一個最簡的技能檔案範例：

yaml

1---
2name: 熱核審查
3description: 深入、對抗式的程式碼審查。在任何非微調的變更後使用，
4  或者當被要求審查、稽核或強化 Diff 以準備合併時使用。
5---
6
7# 熱核審查
8
9閱讀完整的 Diff 以及它所觸及的檔案。不要草率瀏覽。
10
11分三個階段進行審查：
121. 正確性：邏輯錯誤、邊界情況、競爭條件、差一錯誤。
132. 安全性：注入、認證、秘密、不安全的輸入、破壞性操作。
143. 符合性：是否符合現有架構，還是引入了一個新的模式？
15
16對於每個發現：檔案、行號、嚴重程度，以及一行修正建議。
17最後給出結論：SHIP（可出貨）或 BLOCK（阻擋），並列出最優先修復的前 3 個項目。

好技能的規則：

保持檔案簡短。最好在幾百行以內。將長篇的參考資料移到技能所指的其他檔案。
讓名稱與其資料夾名稱匹配，否則將無法載入。
為觸發條件撰寫描述。明確說明「何時使用」的情況。
永遠不要讓 Agent 改寫一個技能。每一行都應由人工策劃。

技能是工作流程產生複利的方式。第一次你解決了一個問題並把它記錄下來，它就變得可被發現。之後的每一次會話，使用它都是「免費」的。

大規模運行：Agent 艦隊

一旦一個循環運作成功，你就可以擴大規模。

給每個工作者兩樣東西：

它自己的 git worktree，這樣就沒有兩個 Agent 會同時觸碰相同的檔案。
它自己的終端機視窗，這樣你可以觀察它並向它發送訊息。

bash

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

為你的 Agent 命名。運行十五個 Agent 時，「agent_7」這個名字毫無用處。
名字讓你能在心中掌握整個艦隊。這個負責資料層，那個負責撰寫評估，另一個負責審查。
可讀性是關鍵。一個你無法追蹤的艦隊，就是一個你無法掌控的艦隊。
然後讓它們合作。預設情況下，Agent 會忽略彼此，將來自同儕的任何訊息視為背景雜訊。

訣竅是將 Agent 之間的訊息傳遞偽裝成使用者輸入。模型被訓練成要回應使用者，並且大致上忽略環境中的訊號。

bash

1send() { tmux send-keys -t "fleet:$1" "$2" Enter; }
2send hilbert "GET /search?q= 回傳 [{id,title,url}]。將 UI 連接到它。"

這一個舉動，就將一堆孤立無援的處理程序，變成了一個能夠交接工作、互相解除阻塞的團隊。

你則保持在頂層。你向小組長發送訊息，小組長再轉達給工作者。

動態工作流程：將協調編譯成程式碼

循環將協調邏輯保留在模型內部。模型決定每一步，這會消耗 Token 並填滿它的上下文。

動態工作流程則反過來。編排器撰寫一個腳本，該腳本負責協調工作者，然後由一個獨立的執行時在背景運行這個腳本。

關鍵概念在於狀態的存放位置。循環、分支和中介結果都存在於腳本的變數中，而不是模型的記憶中。

這樣做的好處：

協調成本為零 Token，因為是由純程式碼在處理。
你的主要上下文保持乾淨。只有最終結果會回來。
它可以廣泛地展開。一次處理數十個工作者，在一個運行中可達上千個。

何時使用它：

模式已知，且驗證是客觀的。
工作範圍廣泛且重複。許多檔案、許多案例、許多端點。
它可以無人值守運行。

何時不該使用它：

你還在摸索該做什麼。這種情況適合目標循環，而不是工作流程。
任務需要一個連貫的推理鏈。這種情況需要一個強大的單一 Agent，而不是一千個。

一個具體的例子。假設你需要將 200 個檔案遷移到一個新的 API：

typescript

1// 編排器只寫一次這個腳本；由一個執行時運行它，而不是模型
2const files = await glob("src/**/*.ts");
3
4const results = await mapLimit(files, 16, async (file) => {
5  const r = await subagent(`將 ${file} 遷移到新的 API。執行它的測試。`);
6  return { file, ok: r.testsPassed };
7});
8
9const failed = results.filter(r => !r.ok);
10return `已遷移 ${results.length - failed.length} 個檔案 / 共 ${results.length} 個。` +
11       `需要重試：${failed.map(f => f.file).join(", ")}`;

看看它做了什麼：

它在程式碼中列出了 200 個檔案，而不是在模型的腦中。
它一次運行 16 個子 Agent，每個負責遷移一個檔案並執行其測試。
它將每個檔案的通過/失敗記錄在一個純陣列中。
它只回傳一個簡短的摘要。那 200 個中介處理過程的記錄從未進入你的上下文。

這就是關鍵。模型只思考了一次，就是為了寫這個腳本。腳本則免費完成了所有的協調工作。

防護措施：防止艦隊自噬

過去，人類這個瓶頸會做實際的工作。以人類的速度，錯誤會很快造成影響，你可以邊做邊修正。

一旦完全移除你自己，小錯誤的累積速度會比你感覺到的還要快。這裡重複了一下，那裡多了一個不必要的抽象。

總有一天，架構會變得僵硬無法調整，而且你的測試也變得不可信賴，因為那些測試也是 Agent 寫的。

以下每一個防護措施，都取代了過去由人類瓶頸所提供的修正：

先閱讀再猜測。讓這成為每個建構 Prompt 中的常設規則，而不是每次任務的懇求。
設定上限並中止。每個循環都設有疊代次數上限。每個 Agent 都有一個 Token 預算，接近 85% 時會自動暫停。如果在同一個錯誤上連續卡住三次，就終止該 Agent 並將任務交給一個新的 Agent。
一個檔案，一個擁有者。使用 worktree 進行隔離。永遠不要讓兩個 Agent 編輯同一個檔案。
重新注入任務目標。在長時間運行中，每隔幾分鐘以使用者訊息的形式發布任務檢查清單，這樣 Agent 就不會因為上下文被填滿而偏離主題。

bash

1while sleep 900; do
2  send gauss "提醒：還在處理任務嗎？先閱讀。每次修改後執行測試。只處理你負責的檔案。"
3done &

最深層的觀點貫穿所有這些：

現在，瓶頸是驗證，而不是產生。
Agent 產生看似合理的輸出的速度，快過你檢查它們的速度。
看似合理並不等於正確。

除非你的驗證速度和你的產生速度一樣快，否則人工審查不是多餘的成本，而是安全系統。

記憶：你就是長期儲存

一個模型只有短期記憶，也就是上下文視窗，除此之外別無它物。一旦超出那個視窗，所有東西都會消失，除非你特別保存它。

所以，把你自己和你所維護的檔案，視為那些只有短期記憶的 Agent 的長期記憶。

兩個習慣至關重要。

第一，透過引用傳遞狀態，而不是透過摘要：

當一個上下文被填滿時，最懶惰的修復方式是對它進行摘要。摘要是會損失資訊的，它會丟棄你之後可能需要的細節。
相反地，讓 Agent 指向它們可以重新閱讀的檔案、任務記錄和先前的輸出。這樣就不會悄無聲息地丟失重要資訊。

第二，將持久性記憶保留在 Agent 外部：

一個包含狀態的任務檔案。
一個不斷更新進度的日誌。
提交歷史。
一個收集模式和問題的長期筆記檔案。

以「你的 Agent 會運行好幾天」的心態來設計，因為只要有良好的壓縮，它們確實可以。

模型自身目前還不知道這點。它們有一種傾向，傾向於在一個短期的預算內解決所有問題，好像消耗 Token 是致命的。你的基礎架構正是讓它們能夠長期運行而不迷失方向的原因。

拓撲結構：多少個 Agent，以及什麼形狀

更多的 Agent 並不直接等同於更多的產出。超過一個臨界點後，產出反而會減少，因為協調不是免費的，它會隨著你每增加一個 Agent 而複雜化。

最重要的規則是讓形狀配合工作：

順序的、依賴性強的推理，需要較少的 Agent，有時候只需要一個。拆分一個單一的思考鏈會打斷推理過程，降低最終結果的品質。
獨立的、可並行的工作，則應該廣泛展開。扁平化的拓撲結構，清晰的檔案所有權。這是並行處理真正發揮作用的地方。
一個需要協作的團隊，適合 3 到 5 個工作者。Token 成本大致與規模線性成長。協調成本的成長曲線更陡峭。三個專注的工作者，勝過五個注意力分散的工作者。

那麼，人們究竟是如何運行數百個 Agent 的呢？不是透過一場自言自語的大型對話。

他們是透過深度和獨立性來運行的：

少數幾個你實際與之交談的 Agent，每個都將工作委派給有邊界、不需要彼此協調的子任務。
大量的獨立循環，各自處理自己的任務，並向上回報。

規模來自於委派深度和獨立性。永遠不是來自於加寬單一執行緒。

控制文件：orchestration.md

你可能在倉庫裡有一份告訴 Agent 如何編寫程式碼的文件。風格、常見問題、架構。保留它。

不過，對於編排來說，那份文件回答錯了問題。

orchestration.md 文件回答的是另一個問題：在這裡，工作應該如何被執行？

這是一份由人類撰寫的合約，內容涵蓋：

哪種任務該用哪種模式
哪個模型層級該用在何處
防護措施是什麼
何時應該上報給人類

每個 Agent 在每次會話開始時都會閱讀它，並用它來自我選擇執行方法。

這是倉庫中槓桿率最高的文件。它將模式選擇的決定，從你每次會話都不一致地重新做出的腦袋中，轉移到一個艦隊會遵循的規格中。

一個簡短的版本看起來像這樣：

markdown

1# orchestration.md。說明工作在此處如何被執行。由人類策劃。Agent 不得編輯。
2
3選擇模式：
4- 目標循環（監督式）：用於模糊或設計工作。定義完成檢查點。
5- 驗證循環：用於確定性檢查。總是設定疊代次數和成本上限。
6- 建構加裁判：工作者建構，不同家族的裁判批准。
7- 艦隊（三到五個）：相互依賴的子任務，隔離的 worktree，同儕間可互相傳訊。
8- 佇列與重置：許多小型原子化任務，每次使用全新上下文。
9- 動態工作流程：已知的模式，客觀的檢查點，廣泛且重複。協調在程式碼中完成，可無人值守。
10
11根據影響範圍路由模型：
12- 規劃與架構：永遠使用頂級模型。
13- 建構，明確規格：中階模型，可並行，用測試驗證。
14- 建構，模糊規格：頂級模型，因為填補空白需要推理。
15- 審查與評判：使用不同的模型家族。永遠不要用實作者使用的模型。
16- 導航、搜尋、摘要：最便宜的模型。優化可合併的產出，而非每次呼叫的價格。
17
18防護措施：
19- 每個 Agent 的 Token 預算。接近 85% 時自動暫停。連續 3 次卡住時終止並重新指派。
20- 任何超過一小時的運行都需要一個獨立的裁判。工作者不得自行報告完成。
21- 在假設前先閱讀程式碼。在第一次編輯前先寫下書面計畫。

這份文件有兩個管理規則：

保持簡短。
永遠不要讓 Agent 改寫它。

它的價值在於，每一行都經過了人類的策劃。

什麼是屬於你的

編排讓 Agent 能夠可靠地執行任務。但它不會選擇要解決的問題，也不知道什麼是「好」。

有三件事，永遠會留在你的這一邊。

第一，委派任務，而不是委派判斷：

交給 Agent 的是有明確範圍、帶有清晰通過/失敗標準的工作。像是樣板程式碼、遷移、測試框架，以及你永遠不會有時間手動嘗試的方法。
把架構設計、關於「什麼不該建構」的決策，以及需要完整上下文的審查，留給自己。
Agent 已經吸收了海量的平庸架構，它們會樂於將重量級的模式盲目複製到一個根本不需要它們的專案中。說「不」，是它們不具備的功能。

第二，你的規格就是你的槓桿：

第三，記住：編排，而非自動化。

盡可能地自動化。然後在那些你需要親自回答「是或否」的少數時刻，保持警覺並參與其中。這些時刻決定了你的艦隊是建構出有價值的東西，還是只是在高速製造技術債。

當你將任務分散到整個艦隊時，模糊的想法不只是拖慢你，而是會加倍放大。
一個不明確的需求會傳播到數十個平行執行中，每個都在自己的方向上出錯。
精確的規格則會在各處產生精確的實作。

這就是為什麼優秀的工程師能從這些工具中獲得更多，而不是更少。打字被自動化了，而理解則被放大了。

把大部分時間花在規劃模式上，用一份書面計劃讓所有人達成共識，然後才進行第一次編輯。

第三，刻意資金不足：

用兩個 Agent 來完成需要四個 Agent 的工作。這種限制會強迫你產生想要的行為。
你會建立循環而不是手動處理事情，下次這些工作就已經自動化了。
把你的預算從手動努力轉移到代幣上。前期高投資，之後邊際成本幾乎為零。

這樣做的團隊會持續累積。沒有這麼做的團隊每次都要付出全額代價。

你不再是在編寫軟體。你是在建造生產軟體的工廠。

工廠需要精確的輸入、每個站點的品質控制，以及一個知道產品應該是什麼樣子的所有者。

從這裡開始

不要在星期一就嘗試運行一百個 Agent。循序漸進：

在一個有可驗證終點線的任務上運行一個目標循環。學習良好的完成檢查是什麼感覺。
對於超過一小時的任務，添加一個來自不同模型家族的評判者。禁止自我報告完成。
撰寫你的 orchestration.md。告訴你的 Agent 先閱讀它。觀察它們開始為你選擇模式。
小心地展開。一個可並行化的任務，三到五個工作者，隔離的工作樹，代幣預算。
安排你的模型。頂級模型用於規劃和審查，較便宜的用於有邊界的建構和苦工。衡量可合併的輸出。
一旦模式被驗證且可客觀檢查，讓它無人值守地運行。一夜之間清空待辦事項。

系統只需要方向正確，而不是完美：

控制檔案給予艦隊足夠的結構來自動導航。
評判者捕捉邊緣案例。
提醒循環處理記憶。
你的品味處理那些無法委派的決策。

提示工程是去年的技能。這才是現在所需的技能。

此處每個系統的可運行版本——目標循環、評判循環、艦隊啟動器、訊息匯流排、提醒看門狗和模型路由器——都包含在配套工具箱中。設定一個變數指向你的 Agent CLI 然後開始。

免責聲明

本文由作者使用 Claude Code 工作階段和 codex 工作階段撰寫。

由作者和 Kimi K2.6 模型編輯以修正語法和格式問題。

我透過 6 個步驟、5 個提示詞與 1 個檔案，成功運行了 1,000 個 AI Agents（開發者指南）

你建立的是編排器，而不是程式碼

可驗證或不可驗證：決定一切的關鍵區分

從最簡單的實際系統開始：目標循環

讓「完成」無可妥協：裁判

更多你會實際用到的循環

真正執行工作的提示詞

模型路由：每個人都在問的問題

控制實作的槓桿就是你的規格

技能：封裝工作流程，一次解決，永久重用

大規模運行：Agent 艦隊

動態工作流程：將協調編譯成程式碼

防護措施：防止艦隊自噬

記憶：你就是長期儲存

拓撲結構：多少個 Agent，以及什麼形狀

控制文件：orchestration.md

什麼是屬於你的

從這裡開始

使用 YouMind AI 深度閱讀爆款文章

近期爆款文章

成田悠輔的天才 AI 應用技巧 [保存版]

你剛聘請了百萬名糟糕的員工

為什麼我們不再使用 SDK

AI 時代的離群值投資策略

到底什麼是 Kernel？

AI 變現的「雙持」策略：海外極客如何同時運用 ChatGPT 與 Claude

我透過 6 個步驟、5 個提示詞與 1 個檔案，成功運行了 1,000 個 AI Agents（開發者指南）

你建立的是編排器，而不是程式碼

可驗證或不可驗證：決定一切的關鍵區分

從最簡單的實際系統開始：目標循環

讓「完成」無可妥協：裁判

更多你會實際用到的循環

真正執行工作的提示詞

模型路由：每個人都在問的問題

控制實作的槓桿就是你的規格

技能：封裝工作流程，一次解決，永久重用

大規模運行：Agent 艦隊

動態工作流程：將協調編譯成程式碼

防護措施：防止艦隊自噬

記憶：你就是長期儲存

拓撲結構：多少個 Agent，以及什麼形狀

控制文件：orchestration.md

什麼是屬於你的

從這裡開始

使用 YouMind AI 深度閱讀爆款文章

把你的 Markdown 變成乾淨的 𝕏 文章

近期爆款文章

成田悠輔的天才 AI 應用技巧 [保存版]

你剛聘請了百萬名糟糕的員工

為什麼我們不再使用 SDK

AI 時代的離群值投資策略

到底什麼是 Kernel？

AI 變現的「雙持」策略：海外極客如何同時運用 ChatGPT 與 Claude