Better Agent Terminal

外觀

把腦力留給判斷 ​

記憶交給檔案，跑腿交給 BAT，判斷留給你。

其他頁面講 Better Agent Terminal（BAT）與 Control Tower 做什麼、怎麼做。這一頁講它們為什麼這樣設計：把原本要靠你記住、靠你的手搬運的事移出你的腦袋，只把判斷留給你。

起點 ​

我同時顧著三到七個專案。最常出事的不是 AI 不夠聰明，而是我把 A 專案寫好的 prompt 貼進了 B 專案。

好一點的情況，AI 帶著 A 的假設在 B 裡找檔案，燒了一堆 token，最後回我「找不到」。更糟的是我沒發現貼錯，它就照 A 的邏輯改了 B 的程式。

問題出在我的工作記憶裝不下：現在在哪個專案、脈絡是什麼、這段 prompt 該貼去哪。每多一個專案，就多一份要記的東西。所以有了 Control Tower 和現在這個 BAT，原則只有一條：能移出腦袋的，都移出去。

每個設計都先問：這份負擔去哪了？ ​

要記住、要處理的事不會憑空消失，只會換個地方放。能放的地方有四個，好壞差很多。

你的腦袋
最不該去裝得下的不多，切一次專案、隔一個晚上就漏掉，也沒有人能幫你檢查。
repo 裡的檔案
好去處放得下、留得住，能進版控、一起 review。換人、換 Agent、隔天再開，都讀得回來。
塔台的對話脈絡
有成本，但負擔得起塔台只放全局：進度、相依關係、做過的決定；程式碼細節交給 Worker 去讀。重要的事最後還是寫進檔案。
工具與規則
一次設計，之後每次受益開分頁、送指令、標出狀態交給 BAT；流程規則寫一次，之後每張工單都照著走。

三種負擔，三種處理 ​

認知負荷理論（Cognitive Load Theory）把工作時的腦力消耗分成三種。BAT 與 Control Tower 對它們各有一種處理：拿掉、切小、留給你。

跟工作無關的雜事：拿掉 ​

跟工作本身無關、卻佔住注意力的雜事，認知負荷理論稱為外在負擔。這一類直接拿掉：

  • 開分頁、送指令：塔台派工時，BAT 在正確的工作區開好 Worker 分頁、送出指令，你不用自己複製 prompt。
  • 認出誰是誰：分頁標題標明哪個是塔台、哪個 Worker 在做哪張工單。
  • 誰在等誰：縮圖直接標出 ⚠️ 在等你、? 在等塔台答覆、✓ 已回報。
  • 有沒有真的啟動：派工時確認 Agent 真的啟動了（Claude CLI 與新版 Codex CLI）。
  • 回報與收尾：Worker 做完，通知直接回到塔台；塔台收單後，分頁等輸出安靜才自動回收。

這幾件事在首頁的7 個卡關時刻裡各有一章；細節見看得見每個 Agent。

工作本身的難度：切小 ​

工作本身有多難，認知負荷理論稱為內在負擔。難度拿不掉，但可以切小：

  • 工單寫清楚目標、範圍、驗收條件與不准碰的東西。
  • Worker 只帶一張工單的脈絡上工。
  • 你一次只審一張工單的結果。

一張工單從對齊到合併怎麼走，見一張工單的一生。

理解與判斷：留給你 ​

真正用來理解與判斷的部分，認知負荷理論稱為有益負擔。這一份不拿掉，前兩種處理都是為了替它騰出空間。

範圍內的技術小決定，塔台可以依工單與專案慣例代你決定，並記下理由（yolo 模式）。下面這些事，一定停下來問你：

  • 範圍要擴大
  • 刪除，或其他不可逆的操作
  • 對外發布：push、發版
  • 需要你的偏好才能決定的選擇
  • 連續失敗

各種自主程度下誰做什麼，見自主程度與斷點。

負擔去哪了 ​

把前面的設計攤開來看：要記住或處理的事，以前在哪裡，現在在哪裡。

負擔去哪了
要記住或處理的事以前現在
現在在哪個專案、做到哪張工單你的腦袋repo 裡塔台的進度檔，塔台啟動時先讀
prompt 要貼到哪個分頁你的手和記憶BAT 依工作區開分頁、送指令
誰在等誰你輪流切分頁看縮圖標記：⚠️ 在等你、? 在等塔台答覆、✓ 已回報
Agent 有沒有真的啟動你切過去確認派工時自動確認
做完要回報、關分頁你通知回到塔台，分頁自動回收
決定了什麼、為什麼你，或沒有人決策紀錄：repo 裡的檔案
學到了什麼散在各次對話經驗紀錄，跨專案與本專案分開放
該由人判斷的事你還是你：這一格刻意保留

  • 現在在哪個專案、做到哪張工單

    以前
    你的腦袋
    現在
    repo 裡塔台的進度檔，塔台啟動時先讀

  • prompt 要貼到哪個分頁

    以前
    你的手和記憶
    現在
    BAT 依工作區開分頁、送指令

  • 誰在等誰

    以前
    你輪流切分頁看
    現在
    縮圖標記：⚠️ 在等你、? 在等塔台答覆、✓ 已回報

  • Agent 有沒有真的啟動

    以前
    你切過去確認
    現在
    派工時自動確認

  • 做完要回報、關分頁

    以前
    你
    現在
    通知回到塔台，分頁自動回收

  • 決定了什麼、為什麼

    以前
    你，或沒有人
    現在
    決策紀錄：repo 裡的檔案

  • 學到了什麼

    以前
    散在各次對話
    現在
    經驗紀錄，跨專案與本專案分開放

  • 該由人判斷的事

    以前
    你
    現在
    還是你：這一格刻意保留

最後一列刻意保留。BAT 與 Control Tower 拿掉的是雜事，不是你的判斷。

只自動化外殼，不把內容寫成劇本 ​

每張工單走的流程都一樣，裡面的內容每次都不同。BAT 與 Control Tower 只自動化前者。

外圈：每張工單都走的五步。內圈：每張工單不同的內容。

圖：外圈是每張工單都會走的五步，開單、派工、回報、收尾、記下經驗，依序循環； 內圈是每張工單不同的內容：要做什麼判斷、會碰到哪些例外、規格缺了哪一塊。

開單、派工、回報、收尾、記下經驗，每張工單都一樣，交給塔台和 BAT。

工單裡的內容卻每次不同：要做什麼判斷、會碰到哪些例外、規格缺了哪一塊。有的客戶給不出規格，只能先做、再測、回頭補規格；有的案子高度客製化，上一個專案的做法搬過來不一定適用。

所以 Control Tower 不把專案工作寫成固定劇本。Worker 在工單範圍內自己判斷，超出範圍就問塔台，該你決定的回到你手上。

經驗還是會累積：做過的事會長成規則與教戰手冊，幫 Worker 判斷得更貼近你的專案（見越用越懂你的專案）。它們是判斷的依據，不是不准例外的劇本。

這不是什麼 ​

三件常被誤會的事。

不規定開發方法 ​

SDD、TDD、BDD 或 BMad-Method，用哪一種由你和專案決定；Control Tower 管的是工單、派工、狀態與紀錄。專案規則寫下來之後，例如每張工單都要跑測試、型別檢查要零錯誤，塔台會把它帶進每張工單的驗收條件。（見一定要用 BMad-Method 嗎？）

不取代專業知識 ​

需求合不合理、架構怎麼切、驗收條件對不對、回報的證據夠不夠、Worker 有沒有走偏，都要懂這一行才判斷得了。BAT 與 Control Tower 拿掉的是雜事，把腦力留給這些判斷。工具會放大判斷的結果，好的壞的都會。

不是 Vibe Coding ​

不是丟一句需求、看起來能跑就收。每張工單先寫好目標、範圍、驗收條件與不准碰的東西；Worker 回報時附上證據：跑了什麼、結果如何、commit 是哪一個；塔台逐項核對才收單。重要的決定寫進檔案，該你決定的事一定停下來問你。

用工具，不用規定 ​

規定越多，反彈越大；工具若能讓人少做行政工作，大家才會用。

在 Control Tower 裡，工單、決策紀錄、學到的經驗都由 AI 寫，文件是工作的副產品。你只負責看，和做決定。

我自己是照這個順序學的：

  1. 學理論與概念。
  2. 動手練習，把流程一步步組起來。
  3. 整理出適合自己的工作流程。
  4. 用 AI 把它自動化，降低自己的認知負荷。

最後一步不是把複雜的流程寫成 SOP 要大家照做，而是讓工具替人做掉那些步驟。

放手的三個習慣 ​

檔案與 BAT 接得住，你才放得了手。下面三個習慣，讓它們接得住。

  • 有事跟塔台說，不要自己動 Worker 正在讀的檔：你手動改的檔案不在塔台的比對範圍裡，Worker 可能讀到改到一半的內容。見Worker 在跑的時候，我可以自己改檔案嗎？
  • 進度寫進檔案之後，放心清掉對話：進度、決定和經驗都在 repo 裡，塔台重開會先讀回來。什麼時候可以清，見可以放心清掉對話嗎？
  • 只在斷點回答：範圍內的事交給塔台推進，斷點出現時它會停下來問你，不必每一步都盯著。

還沒解決的事 ​

負擔沒有消失，只是換了位置。這套做法也有它的成本。

  • 負擔換了位置：你不必再記住所有狀態，但要審報告、做決定。要信任系統、願意放手，本身就要花時間學。
  • 小事不值得開工單：改一個錯字這種小事，塔台直接處理；哪些算小事，第一次用時的問答裡由你決定（見十分鐘問答）。
  • 塔台自己也有成本：規則與紀錄會越來越多。所以規則只寫一處、按需載入，結案的單據定期歸檔（見Control Tower 怎麼長出來的）。

接著看 ​