放手讓 Agent 工作
這是一份公開草稿。內容還在迭代，歡迎一起把它變得更好。
你會用 Agent 嗎？
你有沒有發現，你在用 Agent 的時候，常常在做這件事：
Agent 產出了草稿，你覺得不夠好，自己重寫。Agent 執行了一個步驟，你覺得不太對，自己接手。Agent 跑了一個流程，你覺得沒有你做得精準，下次還是自己來。
你以為你在管 Agent。其實你在和 Agent 搶工作。
Agent 做了 30%，你做了 70%。效率比你自己做高一點，但距離「Agent 在幫你跑業務」還很遠。
你不是在用 Agent，你在用一個很聰明的草稿機
只要你還在「Agent 產出，我來修改完成」的模式裡，你就沒有真正讓 Agent 工作。它在做準備，你在做正事。
這個模式的根本問題不是 Agent 能力不夠。是你還沒切換到 Agent 原生思維。
Agent 原生思維只有一個核心：你的工作是設計讓 Agent 做好的條件，不是代替 Agent 把事情做好。
舊思維（工具思維）：Agent 是輔助，我在做事，它幫我省時間。 Agent 原生思維：Agent 在做事，我在設計讓它做好的系統——指令、上下文、框架。
這個差距，決定你的 Agent 是「偶爾有用的工具」還是「每天在跑的員工」。
讓 Agent 做得好的三件事
Agent 做得好不好，取決於你給了它什麼。三個層次：
Prompt Engineering：你說什麼，它做什麼。
Prompt 是你給 Agent 的指令。好的 Prompt 清楚、具體、有成功標準，Agent 第一次就知道你要什麼。壞的 Prompt 模糊、假設對方懂你、沒有邊界——Agent 只能猜，猜錯了你就接手重做。
Prompt Engineering 不是學魔法咒語。是把你腦袋裡的標準，翻譯成 Agent 能直接執行的語言。
Context Engineering：你給它什麼，它從哪裡出發。
Context 是你放進 Agent 工作記憶裡的所有東西——背景資料、語氣規範、任務限制、過去的決策紀錄。
Context 給對了，輸出和你的期待高度一致。給錯了——太少、太雜、放了不相關的東西——Agent 的判斷就會偏離。
核心問題：「Agent 需要知道什麼，才能做出我會滿意的決定？」
Harness Engineering：你設計什麼環境，它在什麼條件下工作。
Harness 是包裹在 Agent 外面的結構——CLAUDE.md 的設定、工具授權範圍、自動化觸發條件、回報格式規範。
Harness 決定 Agent 的行動邊界：能用哪些工具、什麼情況要回報、什麼情況自己決定、輸出符合什麼格式才算完成。
這是老闆設計工作環境的能力——你不親自做每件事，但你讓每件事的執行環境是正確的。
用最強的 Agent，設計你自己的 Engineering
一個很多人沒想到的做法：
讓 Claude Code 幫你逆向設計你的 Prompt、Context 和 Harness。
你不需要從零學怎麼寫最好的 Prompt。直接問你的 AI CEO：
「我想讓 Agent 每週做這件事：[描述任務]。請幫我設計一個讓它能獨立完成的 Prompt，包含目標、輸出格式和成功標準。」
「我有一個 Agent 任務一直做不到我的水準，這是它的輸出和我的修改版。請分析差距在哪裡，告訴我 Prompt 或 Context 要怎麼調。」
你用最強的 Agent，幫你設計讓其他 Agent 工作更好的系統。你不是自己想辦法寫出完美指令——你讓 AI CEO 幫你迭代到最好。
兩個月後的另一個你
想像另一個早晨——不是遙遠的未來，是兩個月後的週一。
你打開電腦，第一件事不是「今天要寫什麼」，而是看 Reporter Agent 昨晚準備好的報告。三個關鍵數字，一個建議。你看五分鐘，改一行 AI CEO 的指令，Executor 接手更新本週的執行計劃。
這週要產出的所有內容，Builder 已經在跑了。你今天真正的工作，是那個決定。
你的時間不是花在「做事」上。是花在「讓對的事發生」上。
這不是特殊技能。這是三個 Engineering 調到位之後，自然發生的狀態。那個版本的你，就在兩個月後等著——等你把 Agent 該做的條件設計好。
放手，不是盲飛
放手讓 Agent 工作，不是閉上眼睛希望它沒問題。
是你把 Prompt、Context、Harness 設計到位，讓 Agent 跑，看結果，根據結果繼續調整這三層——而不是跳進去自己做。
出了問題，回去改指令，不是自己接手執行。
這是老闆和執行者最根本的差別。執行者遇到問題，親自解決。老闆遇到問題，改善系統，讓問題不再發生。
今天的第一步
選一個你上週和 Agent 搶工作的任務——它做了，但你覺得不夠好，最後自己重做的那件事。
打開 Claude Code，把任務描述給它，把你的版本和 Agent 的版本都給它看，然後說：
「請分析這兩個版本的差距，告訴我 Prompt 和 Context 要怎麼調整，才能讓 Agent 第一次就做到我的版本的水準。」
下次用調整後的設定讓 Agent 重做一次，觀察差距是否縮小。
這個迭代，就是你真正開始使用 Agent 的起點。
給 Token，好辦事
你有沒有試過讓 Agent 做一件本來要花兩小時的事，結果它給你的東西讓你花了四小時修？
不是 Agent 不聰明。是你把「需要影片的任務」給了「只能說話的 Agent」。你在要求一位文案寫手剪片。
很多人搭 Agent 系統的時候，腦子裡只有「哪個 LLM 比較聰明」。但 Agent 的世界遠不只是語言模型——語言型 Agent 和功能型 Agent 是不同物種，混著用沒有章法，你就會一直在等一個永遠不夠好的輸出。
你的 AgentBML 團隊，是 LLM Agent + 專項功能 Agent 的組合。老闆的工作，是知道哪種任務配哪種 Agent。
你的系統全速運作，是這個樣子
想像本週的內容產出流程——
你要測三個 Blog 方向。DeepSeek 跑三篇草稿，成本幾乎零。草稿出來，你花十分鐘選出最有潛力的，交給 Claude Code 做高品質定稿。同時，主視覺需要一張圖，ChatGPT Image 接手。背景音樂這週要一首輕量的，Suno 兩分鐘出一首。
整個週期你做了什麼？選方向、確認品質、做決定。
每個輸出都有對應的 Agent 負責，每個 Agent 在最適合它的任務上工作。
兩大類 Agent
語言型 Agent（LLM-based）：處理文字、分析、推理、策略。你的 AI CEO 屬於這類，Builder、Reporter、Measurer 也大多是。Token 是它們的燃料，Token 費率決定成本。
專項功能 Agent（Function-specific）：不靠 LLM 推理，靠專門訓練執行特定任務——生影片、生圖、生音樂。計算的是 GPU 時間或 API 呼叫次數。程式碼執行和瀏覽器操作，Claude Code 和 Codex 已經完整涵蓋。
語言型 Agent 的三層架構
按能力和成本分三層，根據任務複雜度配對：
第一層：開源模型。 成本極低，本機跑幾乎免費。適合高頻、重複、格式固定的任務：數據格式化、訊息分類、模板填充。量再大都不會失控。
第二層：經濟型模型（如 DeepSeek）。 比主流商業模型便宜 5 到 10 倍，中文能力強，是日常工作流的主力。寫草稿、初步分析、提供選項——需要判斷但不是最終決策的任務，這層夠用。
第三層：主力模型（Claude Code + Codex）。 你的 AI CEO 和核心執行的所在。複雜推理、關鍵策略決策、高品質輸出、整個 AgentBML 系統的協調。這裡不要省——但也只用在值得用的地方。
專項功能 Agent：你的創作與執行手
語言模型說得再好，做不出一支影片。
影片生成：開源模型（如 Wan、LTX 系列）本機部署成本低，適合大量生成測試素材；商業選項（Sora、Runway、Kling）品質更高但按秒計費，適合最終版本。
圖片生成：ChatGPT Image 品質強、指令理解精準，適合對外的關鍵視覺；Google 的圖像工具適合大量生成或 Google 生態系整合。
音樂與語音：Suno / Udio 生成完整歌曲，適合背景音樂和內容配樂；ElevenLabs 做語音合成，適合 Podcast、課程配音、影片旁白。
老闆的任務分配邏輯
這個任務需要語言、推理、程式碼、瀏覽器操作？
→ 是：語言型 Agent（按三層架構選模型）
→ 否：需要影片？ → 開源測試 / 商業出最終版
需要圖片？ → 高品質用 ChatGPT Image，批量用整合工具
需要音樂或語音？ → Suno / Udio / ElevenLabs
把這個邏輯寫進你的 Boss Engineering SOP，AI CEO 調兵的時候就有依據——不需要每次你來決定，系統根據任務類型自動配對。
開源優先的成本邏輯
一個對老闆有利的原則：測試和大量生成用開源，最終版本用商業。
BML 的 Build 環節，很多時候在生成大量測試素材——10 個 Blog 方向的草稿、5 種影片風格、20 個標題選項。這些用開源跑，成本幾乎為零。
Learn 環節確認了哪個方向有效，才把最終版本交給商業模型做高品質輸出。
你的商業 API 費用，集中在已經驗證有價值的內容上——而不是在無數個沒有結果的測試上燒錢。
今天的第一步
列出你的業務每週需要生產的所有類型的輸出：文字、圖片、影片、音頻、數據報告、程式碼……
對每一類問自己：現在是我自己做，還是已經有 Agent 在做？如果是自己做，哪類 Agent 能接手？
把這張清單帶到 Claude Code，讓它為每類任務推薦對應的工具——開源還是商業、哪個模型、大概的成本。
這張清單，就是你 AgentBML 團隊完整招募計劃的起點。
找出你的 AI CEO
你有沒有試過同時跑三個 Agent？
一個在寫文章，一個在分析數據，一個在生成圖片——然後你發現你花了一個小時在協調它們：解釋彼此的輸出、確認格式對不對、下一步是什麼。
你比你一個人做還要忙。
這不是 Agent 的問題。這是沒有中央協調者的必然結果——每個 Agent 都很能幹，但它們不知道誰主導、誰配合、出了問題誰負責。它們不能自己決定這些事，只能等你進來協調。
你就成了那個中央協調者。本來想讓 Agent 幫你省時間，結果你的工作變成管理 Agent。
你的 OPC 需要一個執行長。
不是你。你是董事長，你管方向。執行長負責把你的方向翻譯成可執行的任務，調動對應的 Agent，確保整個系統在跑。
這個執行長，現在有兩個主要候選人：Claude Code 和 Codex。
什麼是 AI CEO
在多 Agent 系統裡，這個角色叫「Orchestrator」——協調者。
其他 Agent 是你的員工，各自負責不同的工作。AI CEO 是你的執行長：接收你的 Boss Engineering 指令，決定哪個任務交給哪個 Agent，追蹤進度，整合結果，回報給你。
你用 Boss Engineering 寫出的 SOP、角色定義、執行標準——這些就是 AI CEO 的工作依據。你的 Boss Engineering 寫得越精準，AI CEO 帶出來的團隊執行越準確。
Claude Code：在你的工作環境裡直接行動
Claude Code 讓你在終端機裡直接和 Claude 對話，而且它能直接讀寫你電腦上的檔案、執行指令、呼叫工具。
適合你，如果：你的工作有大量內容、檔案處理、自動化工作流；你想讓 Agent 直接操作流程，不只是生成文字；你的業務需要 Agent 讀本機資料、更新檔案、執行排程任務。
核心優勢：Claude 模型的推理能力和上下文理解；和本機環境深度整合；支援 MCP 呼叫外部工具；有 Skill 系統讓你定義客製化工作流程。
Codex：程式碼執行專家
Codex 是 OpenAI 的 Coding Agent，在隔離環境裡真的執行程式碼、測試、修 bug、提交變更。
適合你，如果：你的產品核心是程式碼，需要 Agent 持續開發維護；你的工作流程以 GitHub 為中心。
核心優勢：沙箱執行安全可控；和 GitHub 整合緊密；可平行處理多個任務。
你怎麼選
先選一個作為主要 AI CEO，讓它成為系統的核心。
業務以內容、行銷、自動化工作流為主——選 Claude Code。核心是軟體產品開發、以 GitHub 為中心——選 Codex。
對大多數 OPC 創業者，尤其是非工程師背景，Claude Code 是更全面的起點。它不只寫程式，還能處理內容、分析數據、管理檔案、呼叫服務。它更像一個全能的執行長，而不是只懂程式碼的技術主管。
有了 AI CEO，你的工作改變了
你不再需要告訴每一個 Agent 要做什麼。你只告訴 AI CEO 這週的目標，它去分解任務、調動資源、追蹤進度、整合結果。
週二，你說：「這週我要驗證兩個定價方案，A 方案 990，B 方案 1,490，請設計一個最小可行的 A/B 測試，告訴我需要哪些 Agent 各負責什麼。」
Claude Code 給你一份完整的執行計畫。你確認，它帶著團隊去跑。你週五看結果，做下一個決定。
你的注意力，從「協調 Agent」轉移到「決定方向」。
CLI：你把指令傳給 AI CEO 的通道
不管選哪個，你都需要懂一件事：CLI（命令列介面）——你用文字指令和電腦直接溝通的地方。
這是 Boss Engineering 真正發生的地方。你在 CLAUDE.md 裡寫好的角色定義、工作範圍、執行標準，透過 CLI 環境傳給 AI CEO，它帶著這份 SOP 去協調整個團隊。
聽起來很技術，但 Claude Code 的設計讓非工程師也能用——你用中文說你要做什麼，它幫你轉成行動。你需要懂的只有幾個基本操作：開終端機、切到工作目錄、輸入 claude 啟動。
今天的第一步
今天就安裝 Claude Code。打開終端機：
npm install -g @anthropic-ai/claude-code
裝完，在你的工作資料夾裡輸入 claude，它會啟動，問你要做什麼。
用中文說一個你現在想讓它做的任務，看它怎麼應對。
這是你第一次和你的 AI CEO 直接對話。不需要完美。需要的是開始建立這個習慣：遇到工作，先問 Claude Code 能不能處理，而不是自己先動手。
請 AI CEO 組織 AgentBML 團隊
四隻手，沒有一個負責人，做出來的東西是四個方向。
想像這個場景：你要測試一個新的 Blog 方向。Builder 寫了草稿，Measurer 設定了追蹤，Reporter 準備分析——但沒有人確認這三件事在追同一個目標。
Builder 的草稿對應你說的方向，但 Measurer 追蹤的指標是上週剩下的設定。Reporter 分析的是 Measurer 給的數字，但那個數字量的不是你這週真正想知道的事。
每個 Agent 都在工作。但它們在工作的平行宇宙裡。
AI CEO 解決「誰在主導」的問題。但 AI CEO 帶隊需要一份藍圖——你用 Boss Engineering 定義每個角色的職責和標準，AI CEO 根據你的設計協調執行。
老闆設計系統。AI CEO 執行系統。
AgentBML 團隊的四個核心角色
建造 Agent（Builder）——負責 Build 環節。把你的想法變成可以上線的東西：落地頁文案、Blog 草稿、電子報、程式碼初版、自動化腳本。你告訴 AI CEO 這週測什麼方向，Builder 把它做出來。
測量 Agent（Measurer）——負責 Measure 環節。持續收集數據、整理成你看得懂的格式：流量、轉換率、訂閱變化、收入、用戶回饋。你不需要自己抓數據，Measurer 自動整理好放在你指定的地方。
回報 Agent（Reporter）——把原始數據轉化成洞察。這週表現最好的是什麼？有什麼異常？和上週比有什麼變化？下一步建議測什麼？你看的不是數據，是分析後的結論和建議。
執行 Agent（Executor）——負責你決定之後的後續。你說「這個方向繼續推，那個暫停」，Executor 更新流程、調整排程、通知相關系統。你做決定，它把決定轉化成系統的實際調整。
當 Boss Engineering 設計好，AI CEO 居中協調，你看到的是一份整合過的報告——不是四個 Agent 各自遞過來的四堆輸出。
MCP：讓你的團隊能伸手到外部世界
Agent 本身是語言模型——能思考、能寫、能分析，但天生不能查今天的流量、不能發布內容到網站、不能讀你的試算表。
MCP（Model Context Protocol）是標準介面，讓 Agent 呼叫外部工具。連接一個 MCP 工具，Agent 就多了一隻手。
常用的連接：搜尋工具（即時查網路）、瀏覽器工具（打開網頁、提取內容）、檔案系統（讀寫文件）、資料庫（查詢業務數據）、API 呼叫（任何有 API 的服務）。
Claude Code 預設支援 MCP。你設定好要連接的工具，AI CEO 在需要時就能呼叫。
Plugin 和 Skill：團隊的專業技能
MCP 讓 Agent 能「用工具」。Plugin 和 Skill 讓 Agent「會特定的事」。
Plugin 是第三方開發的功能擴展——Notion、Slack、Google Workspace 都有對應的 Plugin。
Skill 是你自己定義的工作流程——也就是 Boss Engineering 的具體實現。你在 CH07-3 學到的四個組成，寫成文件之後就是一個 Skill。AI CEO 在需要時直接呼叫，不需要你每次重新說明。
比如你有一個「每週發布 Blog」的 SOP：根據上週熱門主題定標題 → 生成 1000 字草稿，語氣直接，結尾有行動步驟 → 套入 SEO 格式 → 輸出到 CMS 草稿區標記「等待確認」。
這份 SOP 就是這個 Skill 的內容。AI CEO 每週呼叫它，Builder 照著跑，你只做最後確認。
Skill = 老闆的 Boss Engineering SOP，被 AI CEO 可呼叫化。
設計團隊的三步流程
第一步：你用 Boss Engineering 草擬每個角色的定義。 寫下團隊需要哪些角色、職責、標準、邊界。初稿就能開始。
第二步：把草稿交給 AI CEO 檢查補強。 打開 Claude Code：
「這是我為 AgentBML 團隊設計的 Boss Engineering 草稿。請幫我檢查：（1）每個角色的職責有沒有不清楚的地方；（2）有沒有我遺漏的邊界情況；（3）角色之間的協作流程是否合理。」
AI CEO 幫你找出缺口，你調整，形成最終版。
第三步：AI CEO 根據確認的設計組隊執行。 它有了帶隊的依據——哪個 Agent 負責什麼、用什麼模型、遵守什麼標準、什麼情況回報你。你只看結果和做決策。
今天的第一步
在 Claude Code 裡輸入：
「我需要你幫我設計一個簡單的 AgentBML 系統。我的業務是 [你的業務描述]。請給我：（1）需要的 Agent 角色清單；（2）每個 Agent 的具體職責；（3）它們之間怎麼協作；（4）你建議先部署哪一個作為起點。」
這份規劃不是答案，是你的起草版本。你來調整和確認。
確認之後，你的 AI CEO 就有了組隊的藍圖。
BML 是 Agent 的主場優勢
你還記得 CH01 說的那個數字嗎——10 倍的業務成長？
那時候你可能想：聽起來不錯，但具體怎麼發生？
CH08 的每一章，你都在把「怎麼發生」拼起來。Agent 原生思維、三層 Engineering、AI CEO、AgentBML 團隊、MCP——這些不是分開學的東西，是同一個系統的不同層。
現在，把這個系統接上 BML。
發生的不是「快一點」。是進入另一個量級——10 倍數量 × 10 倍速度，100 倍的 BML 優化能力。
老闆決策，AI CEO 調兵
你每週的工作就是一件事：決定方向，交給 AI CEO 執行。
你說：「這週我想同時測三個 Blog 方向，看哪個受眾反應最好。」
AI CEO 開始調兵：Builder 三個方向各產出一篇草稿，格式一致方便對比。Measurer 設定三篇的追蹤標記。Reporter 在指定時間自動產出對比報告——哪個方向的點擊率、停留時間、轉換率最高。
你不管過程的任何細節。你管「三個方向是什麼」，以及「看完報告下一步怎麼走」。
10 倍數量：同時跑，不是排隊跑
傳統做法一次測一個方向。你現在同時跑十個。
不只 Blog 方向——產品定位、內容主題、定價方案、受眾細分——全部同時進行，每個都有 Agent 在執行，每個都有數據回來。
十個實驗裡，可能八個沒達到期待，兩個有信號。你把資源集中到這兩個。
這個淘汰速度，一次跑一個實驗的時候要花一年。現在，幾週。
10 倍速度：Scheduled Tasks 讓循環不等你
Build：你確認方向，Builder 幾小時內產出。Measure：自動追蹤，數據即時進來。Learn：Reporter 在指定時間自動產出分析。
從你做出一個決定，到看到第一批結果：24 到 48 小時。
Scheduled Tasks 是讓這個速度成真的關鍵。你不需要每次手動啟動 Measurer，不需要提醒 Reporter 該出報告了。設定一次，排程自動觸發，循環自己在跑。
你的角色是每週看報告、做決策——不是每天盯著系統。
Boss Engineering 品質 = 100 倍放大的品質
100 倍 BML 不是獨立運作的機器。它放大的是你的 Boss Engineering 品質。
這個等式要清楚：
Boss Engineering 精準 → AI CEO 方向正確 → 團隊執行有效 → 100 倍放大的是對的事。
Boss Engineering 模糊 → AI CEO 方向偏差 → 團隊把偏差執行 100 次 → 你快速跑向錯誤的地方。
這就是為什麼 CH07 要先學 Boss Engineering，CH08 才能啟動這個系統。你的 SOP 品質，是整個引擎的燃料品質。燃料越純，引擎越強。燃料不純，引擎跑得越快，偏得越遠。
老闆指錯方向，團隊會把錯的事做到極致
100 倍 BML 有一個關鍵前提：這個系統的能量乘以的是你的方向，不是自動修正你的方向。
你指對了，團隊把對的事做到 100 倍。你指錯了，它們把錯的事同樣做到 100 倍。
一個錯誤的假設，10 個 Agent 同時驗證，24 小時內給你 10 份「這個假設沒有市場」的數據——這是好事，你快速知道錯了。
但有一種更嚴重的錯誤：方向本身有問題，但數據看起來不錯。
比如你的 Blog 流量很高，但流量來的全是不會付錢的族群。Measurer 回報流量數字，Reporter 說「表現良好」，AI CEO 繼續往這個方向加碼——系統在努力工作，但你正在快速走向一個沒有收入的死胡同。
這種錯誤，Agent 不會自己發現。只有老闆才能看出來。
老闆的最核心職責，不是管理系統。是確保系統在追對的目標。
定期問自己三個問題：
我設定給 AI CEO 的目標，還是我真正想達到的目標嗎？ 系統跑出來的數字，量的是對的事嗎？ 我看到數字不錯就放心了——還是我真的理解背後發生了什麼？
每週的決策時間，不只是「看報告、給指令」。是「質疑自己的方向是否正確」。這是老闆的工作，沒辦法交給 Agent。
老闆的一週，現在長這樣
週一早上，Reporter 的週報在你的 Notion 等你。30 分鐘看完，標記需要決策的三件事。
週二，針對三件事做決定，更新 AI CEO 的指令。AI CEO 分派給對應的 Agent，本週的 Build 開始跑。
週三到週五，系統在執行。有問題會通知你，沒問題就繼續跑。
週末，數據在累積，Reporter 在準備下週一的週報。
你的注意力，用在最值得的地方：決定方向、判斷品質、思考下一步。
今天的第一步
打開 Claude Code，輸入：
「我想設計一個本週的 AgentBML 實驗。我的業務是 [你的業務]，我最想驗證的假設是 [你的假設]。請幫我設計：（1）這個實驗的 Build / Measure / Learn 分工；（2）需要哪些 Agent 角色；（3）哪些環節可以設定成 Scheduled Tasks 自動跑。」
設計出來，確認，部署，啟動。
你的 100 倍 BML，從這個循環開始算。
修訂紀錄 · Changelog
- 新增上架：完整章節內容（Fable5 版）