Human Being — 用 tmux + Skill 組裝你自己的 Agentic Workflow

2026-04-10

最近研究比較常用的 Claude Code 時，想起它有 Agent Teams 的 feature，它的組合靠著 tmux 與設定好的訊息交換機制，達到多 agent 協作的目的。於是我就開始我的「重造輪子」歷程。

但說是重造輪子，只是自嘲，因為在 Threads 上看到，大家都在 vibe programming 卻都在造輪子。其實對我來說造輪子是一種個人學習與探索問題細節的重要歷程，在這過程中，親自與「問題」磨擦而獲得經驗。

說「所以」好像很有計畫，其實比較接近「反正手邊有 tmux，skill 用自然語言寫就好，那就試試看吧」。組完之後發現還真的能動，而且因為 tmux 不管你跑什麼 CLI，Claude Code、Codex、Gemini CLI 要混著用也行，平台鎖定的問題直接不存在。最近想試試它能走多遠，乾脆準備了一份比做 TODO 大一咪咪的專案需求丟給它，看 agent 對 agent 能不能自己導航完成、交出可驗證的結果。

角色分工與運作方式

這次要做的事情很明確：給 skill 一份需求，讓它從頭做出一個 MVP。配置是開兩個 tmux pane，一個跑 Navigator 負責規劃，一個跑 Driver 負責實作。

在還沒有 human-being 這個 skill 之前，做法就是一個 Claude Code session 什麼都做，從規劃到實作一條龍。說是一條龍，其實是人機協作那種一條龍，開發者還是要一一指導細節。結果它常常做到一半就忘了原本的方向，或是因為 context 積多了，情境沒有完全對上你的指示，而改了預料外的部分，人也累。AI agent 這幾年已經能寫各種常見需求了，只要不是需要嚴肅處理的專案或部分，指導細節這件事其實可以放手。後來才拆成角色分工的做法，讓不同 agent 各管一段。

運作方式是這樣的。PO 就是我自己，如果你接觸過 Scrum，PO 就是 Product Owner，負責決定做什麼、不做什麼，給方向就好。PO proxy 代理我傳達意思，但你就想成 PO 就行了，只是我像個老闆一樣，只負責喊話、負責畫餅。神說要有光，於是就有了光。PO proxy 就是我們直接操作的 Claude Code session，透過 skill 告訴它：你現在負責管理 tmux 裡的其他 agent。它就從「一個口令一個動作的助手」切換成「開發週期的主控者」，負責翻譯意圖、指派任務、巡查進度。Navigator 掌握技術方向，Driver 動手做事。

PO (我)
  ↕ 只跟 PO proxy 說話
PO proxy (主 terminal 的 Claude session)
  ↕ 透過 tmux send-keys / capture-pane 控制
Navigator (tmux pane) ←→ Driver (tmux pane)

每一層只管自己該管的事，訊息往下傳遞，結果往上回報。PO 不需要盯著螢幕，交代完就去喝咖啡。LIKE A BOSS。

實戰

這次想試的是很簡單的一件事：給 agent 一個小目標，讓它們自己導航做完，然後看結果合不合理。為了有東西跑，挑了一份小專案的 requirements.md 當題目，小團隊用的內部影片分享平台 MVP，Go backend + Vue SPA + SQLite + 單 container。題目選什麼其實不是重點，scope 剛好夠一次 session 跑完就行。順帶一提，這份 requirements.md 本身也是跟 Claude Code 簡單聊一聊請它寫的，不是我手打的。

# Internal Video Sharing — 需求文件

## 1. 專案目的
為小型團隊打造一個內部影片分享平台，用於團隊知識分享（教學、會議錄影、技術分享等），讓成員可以上傳影片、搜尋、觀看。

## 2. 使用情境與規模
- 使用情境：團隊知識分享
- 團隊規模：小型（< 20 人）
- 定位：MVP，優先驗證可用性，功能聚焦

## 3. MVP 功能範圍

### 納入
- 影片上傳（檔案上傳）
- 影片列表
- 標題與描述搜尋
- 標籤（tag）分類
- 線上觀看

### 不納入（MVP 不做）
- 登入 / 使用者帳號
- 存取權限控制（公開 / 私人）
- 留言、按讚、收藏、觀看次數、進度記憶等互動功能
- 影片轉檔（不做 ffmpeg 處理）
- 多畫質 / HLS 串流
- 外部連結（YouTube 等）整合

## 4. 使用者互動流程（概念層級）
1. 使用者進入網站，看到影片列表
2. 可用關鍵字搜尋標題 / 描述，或點標籤篩選
3. 點選影片進入觀看頁，直接瀏覽器內播放
4. 透過上傳頁上傳新影片，填寫標題、描述、標籤

## 5. 非功能需求

### 上傳限制
- 檔案格式限制為瀏覽器相容的 MP4（H.264），不做轉檔
- 單檔大小上限：約 200 MB（採用單次 request 上傳即可）

### 儲存
- 影片檔：本地檔案系統，架構上抽象成可替換介面，未來可切換到 S3-compatible 物件儲存
- Metadata：輕量資料庫（SQLite 等級即可）

### 部署環境
- 目標 OS：Linux 或 macOS
- 部署方式：Container

## 6. 技術方向
- Backend：Go
- Frontend：主流但簡單的框架（推薦 Vue 3 + Vite）
- MVP 架構：Go API + Vue 3 SPA 分離部署
- 未來演進：將前端 build 產物 embed 進 Go binary，收斂成單一 container

## 7. 未來（post-MVP）可能納入的功能
以下功能有討論過，但 MVP 不做，保留之後評估：
- 登入與使用者帳號
- 影片公開 / 私人權限控制
- YouTube 連結整合（考慮用 yt-dlp 自動備份到本地）
- 影片轉檔、多畫質、thumbnail 產生
- 觀看次數、留言等互動功能

## 8. 成功判準
MVP 算完成的條件：
- 團隊成員可從瀏覽器上傳 MP4 影片，填入標題、描述、標籤
- 其他成員可瀏覽列表、用關鍵字或標籤找到影片、線上觀看
- 以 container 方式部署在一台 Linux 或 macOS 機器上穩定運行

我只說了「讀一下我的需求，我想讓你自動開發」，然後下 /tl-dx:tl-dx-human-being 交給你了，剩下交給 PO proxy 去調度。這次順便試了一下 model escalation，Navigator 跑 Opus 4.6 多想一點，Driver 跑 Sonnet 4.6 求快，各用適合的模型。

我中間只介入兩次：一次是 PO proxy 問時間預算，我回「30 min, checkpoint」+「B」（代審計畫，不用每步都回報）；另一次是它跑完 checkpoint 列了幾個收尾方向問我，我回「你來規劃收尾，並 push」。其他時間我去忙別的，讓 agent 自己導航。

回來的時候東西都出來了：backend、storage、API、Vue 前端、go:embed 打進 binary、Dockerfile、smoke test 一路跑完。commit 85816a9 進 main，可以拉下來 docker build 直接跑。我對了一遍需求文件，MVP 的 success criteria 都有對到，可以上傳 MP4、可以搜尋、可以線上播放，看起來都對得上。

過程中有兩個小插曲，都是機制內該處理的：go:embed 的 path pattern 撞過一次，Navigator 跟 Driver 自己消化掉沒回報；Pasted text 又卡了一次，PO proxy 偵測到就補 Enter。我這邊一個訊息都沒看到。

從 kickoff 到雙 pane /exit 大約 25 分鐘。這個例子想看的就是 agent 對 agent 自己把一個小目標從需求跑到可驗證結果這條迴路能不能走通，這次是走通了，題目換成什麼應該都差不多。

全程錄了 asciinema，裡面標了幾個時間點方便跳：https://asciinema.org/a/PMPNCorE0cn6bxXw

從踩坑到機制：skill 怎麼長出來的

human-being 的前身叫 like-a-boss。一開始是叫 Claude 幫我準備骨架，我大概只交代了角色分工，以及告訴它 tmux 可以讓 pane 互相觀察、互相操作。其他細節就沒多講，所以最初只有一個 stop event hook，也沒特別提醒它要去讀寫好的 event file；巡查靠 for-loop 每 30 秒 capture-pane 比對畫面；Pasted text 卡住（明明訊息都貼上去了，就是差一個 Enter 沒送出，停在那）也沒有任何處理機制。在 event log 出現之前，跑起來很苦。

每次跑完一個 session、踩到坑，我就叫 Claude 做個 retro/reflection，想一下怎麼修 skill。這跟我平常的習慣有關：專案的 CLAUDE.md 規則要求它把學到的東西和還沒想好的問題隨手寫進 daily log，所以踩坑隔天就有一份現成的事後檢討可以翻。改的不是 code，是自然語言，這就是 LLM 的優勢，迭代單位是文字不是程式碼。

一開始最卡的是 events 的角色識別。hook 本身一直是 agent 幫我裝的，沒有手動編 JSON 那一齣，但 agent 對 tmux 機制不熟，events 寫出來分不清是誰發的，PO proxy 讀完也不知道到底是自己、Navigator 還是 Driver 剛停下來。後來在事件格式裡加上明確的 role 欄位，並把 hook 安裝收成 human-being-hooks.sh 一鍵完成（避免蓋掉專案其他 hook），這個問題才算解掉。

巡查機制的改變比較大。巡查本質就是 event-loop 那種定時檢查有沒有事件要處理的東西。原本 PO proxy 用 for-loop 定時抓畫面，靠字串比對猜 agent 在幹嘛，又慢又不準。後來改成 event-driven：每個 agent 停下來的時候自動寫一筆事件到檔案，PO proxy 讀事件就知道誰在忙、誰閒著、誰卡住。再加上 role-status 一次看所有 role 的最後狀態，stale 偵測忙太久沒回應的 role，巡查這件事才算真的堪用。

Pasted text 的問題本質上就是：訊息都貼上去了，就是差一個 Enter 沒送出。處理方式也是一路演化，一開始只在 skill 的 Important Notes 裡寫「送長文字後要 capture-pane 確認有沒有卡住」，純粹靠 agent 自覺。後來 agent 在 retro 時自己演化出 send 和 send-file 子指令，送完自動檢查，卡住就補 Enter。

即使這樣，像前面案例那樣偶爾還是會漏掉，要 PO proxy 事後偵測。agent 在 reflection 裡自己說過原因：等久了會有點急，忍不住想幫旁邊的 pane 按一下。我後來也沒強力禁止「互相幫忙」這件事，它在 reflection 裡甚至用 rude 來形容這種跨界行為，像是覺得自己無視了某種禮儀規範。機制存在是一回事，agent 自己選擇要不要照做，是另一回事。

模式也從固定變成可選。原本只有 Navigator + Driver 雙 pane，後來發現有些事情一個人就能搞定，有些又需要好幾個 Driver 同時動手，硬塞進同一種模式不合理。現在有 Simple（1 Worker，PO proxy 直接指揮）、Standard（Navigator + Driver）、Multi-driver（1 Navigator + 多 Driver 平行做事）三種，開工前選一個就好。

整理一下這些改動的前後對照：

每一項都是找個模擬專案跑過、跟 agent 一起停下來 reflection 改出來的。這就是自己做的好處，你會知道每個設計決定的由來，背後都是某次真的卡在哪裡才長出來。

不綁平台的好處

前面那個案例裡的混搭是 model escalation，Navigator 跑 Opus 4.6，Driver 跑 Sonnet 4.6，讓規劃那邊多點思考、實作那邊求快。這只是一種組合，哪天想把其中一個換成 Codex 或 Gemini CLI 也行，同一個 tmux session 裡混著跑都沒差。tmux 不在乎 pane 裡跑什麼 CLI，skill 用自然語言寫，不綁特定 API。想改 workflow 就改文字，上面那些演化每一項都是改幾行的事。

大家都在做 multi-agent 平台，各家都在比誰的 orchestrator 更強。但自己用 tmux 組一個，學到的東西是不一樣的。

不是全自動的，這才是重點

前面的數字已經說明了，這不是一個「設定好就放著跑」的系統。最近 Anthropic 也在取締那些把所有資源一次用盡的第三方 agent 跑法，那種路線本來就不是我想要的。human-being 技術上可以做到全自動，但我刻意在流程裡留 checkpoint。它模擬的是人類工作的節奏：觀察、決策、休息、卡住就換方向。一個問題最多試 3 次，不是 3 次指令，是 3 次方向性的嘗試，第 3 次還是不行就記錄下來換題目，不要鐵頭。每 20 分鐘 check-in 一次，時間到了 Navigator 暫停問 PO 要繼續還是收工。這裡的 time budget 不是「這個專案只能做這麼久」，也不是拿來對 agent 施壓，純粹是「人該回來看一下了」的提醒時間。token 是有成本的，人類的判斷力不應該被自動化取代。

human-being 不是一個多厲害的工具，它就是一份用自然語言寫的 SOP，告訴 LLM 怎麼扮演人類操作者的角色。對我來說有趣味的部分，是把它弄成可以用的過程。每次跑 session、遇到情境不明確的地方，跟 AI 小伙伴一起停下來回想：剛剛那段卡在哪、為什麼、下次可以怎麼處理？答案可能跟你原本想的不一樣。知道什麼時候該停、什麼時候該換方向，這些看似「低效」的特質，恰恰是讓 workflow 不會失控的關鍵。

如果你也想試試，不需要用我的 skill。這塊肯定有更成熟的 Open Source 專案，Claude Code 官方也有 Agent Teams（多個獨立 session 一個當 team lead 協調、其他當 teammates 彼此溝通）可以參考。想要自己兜，也就是開個 tmux session，分幾個 pane，各跑一個 AI agent，再用另一個 agent 當指揮官就好了，這樣你就能弄出相似的成果。真正要花力氣的其實是想清楚每個角色該做什麼、不該做什麼。這個部分我自己也還在摸索。

skill 可至 gist 上參閱：https://gist.github.com/qrtt1/4b9061dcaee5ee81753ffafcd77bf3d8

那如果是你，你會怎麼排角色？Navigator + Driver 這種兩人組，或是像在龍蝦上看過有人直接弄一整個國家的文武百官？