最近看到個以 tmux send-key 做出來的 inter-agent communication 的做法。開 n+2 個 Claude Code。一個 A 負責跟人類溝通然後把所有工作交給 B。B 只負責分工跟蒐集結果,工作內容丟給其他 n 位去做。
揣摩試了好幾天發現基本上是個快速累積垃圾內容(重複性高的內容)跟把 Claude Code 玩到壞掉的方式 (?)
但接下來我就覺得應該寫個 AGENTS-BBS.md 來要它們用檔案系統來開個 BBS .. (??
最近看到個以 tmux send-key 做出來的 inter-agent communication 的做法。開 n+2 個 Claude Code。一個 A 負責跟人類溝通然後把所有工作交給 B。B 只負責分工跟蒐集結果,工作內容丟給其他 n 位去做。
揣摩試了好幾天發現基本上是個快速累積垃圾內容(重複性高的內容)跟把 Claude Code 玩到壞掉的方式 (?)
但接下來我就覺得應該寫個 AGENTS-BBS.md 來要它們用檔案系統來開個 BBS .. (??
實際上隨便做了個 AGENT-BBS.md 之後覺得還頂好玩的。配合簡單的 todo 消耗規則跟加上一些 role-play 之後可以看到 agent 們自己開版面要求 peer review...
token 消耗速度飛快 XD
前一陣子做完 BBS.md 後,昨天做了 IRC.md
在本機開個 container 跑 ergo ircd 然後讓 claude code 跟 codex 上聊天室來互相蹉跎(?)
意外發現 codex 很不想盯著一個跑不完的 background job (irc-client.py) 的進度跟輸出,但 claude code 很樂意進入這種無限迴圈。
額外寫另一個 bot 後端 LLM 大概才比較有的玩。但至少要給它主動講話的能力。跟以前寫作 irc bot 的狀況一樣。
重溫 1990-2000 的社群網路。
好處(?)是可以讓我在同一間頻道中控制多支 agent 的任務分配,甚至讓其中一位來專門盯進度。
壞處(?)是這種需求早就內建在 claude code 跟 codex 內了。
繼續研究各種用 LLM 做 irc bot 的方式。
研究了 claude 跟 codex 兩個命令的細節後,發現可用 claude -c 、codex exec resume --last 來載入上一個 session 內的對話。等於是不必微調 one-shot prompt了。
雖然是還會碰到 compaction 但是對於也可用一些輔助的 prompt 來事後載入舊情境。
也就是那句老話:在網路上,沒有人會知道你只是一個 shell script.