嗨大家,我是 Debuguy。

昨天我們完成了 N-1 的架構，今天其實我們什麼 code 都不用改，
聽起來很神奇？其實這一切都是從 Day 3 就開始鋪陳的...
這個架構從一開始就是為了讓多個 Bot 協作而設計的。

重新聊一下為什麼會有這個實驗性的 project

以終為始

讓我們先聊聊真實的業務需求:

「我們公司有好幾個產品部門，每個部門都有自己的 domain 和資料。另外還有 Platform、DevOps、DBA 這些跨產品的團隊。當發生跨部門的 issue 時，查問題就變成一場災難...」

想像這個場景:

• 產品 A 團隊有自己的業務邏輯和錯誤日誌
• 產品 B 團隊有自己的服務監控和資料
• Platform 團隊負責共用的基礎服務和框架
• DevOps 團隊管理所有產品的部署和基礎設施
• DBA 團隊維護所有產品共用的資料庫

當使用者回報「某個功能壞了」時，問題可能橫跨多個產品和團隊。常態性的做法是:

1. 開個會議, 拉所有相關人員
2. 每個團隊各自查自己的 log
3. 輪流報告發現
4. 最後拼湊出完整的問題

「這個過程至少要花 2-3 小時甚至更久，而且 log 量大的時候根本看不完...」

讓 LLM 讀 log 不是更合適嗎?

突然靈光一閃:

「LLM 最擅長的就是處理大量文字資料啊！」
「如果每個產品部門都有自己的 Bot，專門負責分析自己的 log...」
「Platform、DevOps、DBA 也各有專門的 Bot...」 「然後讓這些 Bot 自己討論問題...」

這就是整個設計的核心理念: 讓專業的 Bot 做專業的事,然後讓它們協作。

當然,這個願景目前還在想像階段，真正要實現還有很長的路要走。但重要的是，架構已經為這個未來做好準備了。

從 Day 3 開始的鋪墊

每一步設計都是有目的的:

Day 3: 賦予身份

Your Slack ID is {{botUserId}}

→ 不只是讓 Bot 知道自己，更是為了識別其他人（包含 bot）

Day 3: Tag back 機制

When you finish your response, tag the user who originally mentioned you

→ 這不只是禮貌,而是創造 Bot 之間的互動循環

Day 5: 標準化對話格式 → 讓不同的 Bot 能理解同一個對話歷史

Day 6: 多人識別

Identify who mentioned you in the latest message

→ 讓 Bot 能在複雜場景中找到正確的對話對象

「所有的設計都是為了今天做準備!」

架構的神奇之處

當我把這些設計拼在一起時，突然發現:N-N 協作是自然湧現的結果。

完美的循環

想像這個流程:

1. Bot A 收到 mention,處理後 tag 回 User
2. User 的回覆中可能 mention Bot B
3. Bot B 被觸發,處理後可能 tag Bot A
4. Bot A 再次被觸發...

這就形成了一個自然的協作循環!

而且因為:

• 每個 Bot 都用 app_mention 觸發
• 每個 Bot 都能識別對話歷史
• 每個 Bot 都會 tag back

所以: Bot 可以 mention Bot!

意外的驚喜: 狼人殺實驗

Workshop 的創意發現

在某次公司內部 workshop 帶大家學習如何使用 GenKit 以及講述未來規劃時，
有位同事突發奇想:

「既然 Bot 可以互相對話,那...能玩狼人殺嗎?」

結果顯示: 可以,而且超有趣!

他設定了幾個不同角色的 Bot: 村民、狼人、預言家、女巫、主持人。
遊戲過程中，Bot 們展現出了驚人的策略思考、推理能力,甚至還會說謊和欺騙。
（雖然遊戲一開始的指派就已經寫出哪個 bot 是誰了但 bot 們還是玩得很起勁）

這個實驗的重要性:

1. 證明了架構的彈性 - 同一套系統可以處理完全不同的場景
2. 展示了湧現行為 - Bot 展現出我們沒有明確編程的複雜互動
3. 驗證了協作可能 - 如果能玩狼人殺,就能協作解決真實問題

未來上線需要考量的問題

當然目前這個架構要真正要投入生產環境還有很多重要的問題要解決:

1. 避免無限迴圈

目前的架構理論上可能產生 Bot 之間沒完沒了的對話:

🤖 Bot A: @BotB 你覺得呢? 🤖 Bot B: @BotA 我同意你的看法,你呢? 🤖 Bot A: @BotB 我也同意,那你... （無限循環...）

可能的保護機制:

System Prompt 層面:

## Conversation Guidelines  
- Keep responses concise and actionable
- Avoid open-ended questions that might lead to endless back-and-forth
- If a conversation gets too long, summarize and conclude

程式層面的保護:

// 對話深度檢查
const botMessages = messages.filter(m => 
  m.user.startsWith('U_BOT') && m.user !== currentBotId
);

if (botMessages.length > 5) {
  // 超過閾值,可能需要人工介入
  await notifyAdmin('Bot conversation too long, possible loop detected');
  return;
}

2. 成本控制

多個 Bot 協作意味著更多的 LLM API 呼叫，成本可能快速累積。需要考慮:

• 設定每個 Thread 的 token 使用上限
• 監控異常的高頻互動
• 實作優先級機制

3. 責任追蹤

當多個 Bot 參與決策時，如何追蹤「誰做了什麼決定」也很重要。

這些都是未來要解決的挑戰，但好消息是:架構本身已經支援這些擴展了。

設計哲學: 讓複雜自然湧現

好的架構不是「實現」複雜功能，而是讓複雜功能「湧現」出來。

我沒有寫:

• Bot 應該如何協作的 pormpt
• 複雜的 flow 來應對多個 bot
• 撰寫複雜的狀態管理

我只做了:

• 給 Bot 清楚的身份
• 建立簡單的互動規則
• 利用 Slack 現有的（mention）機制

然後協作就自然發生了。

從 0 到 1 的完整路徑

現在回顧從 Day 1 到 Day 7 的旅程:

• Day 1-2: 建立基礎 (技術選型)
• Day 3: 賦予身份 (自我認知)
• Day 4: 管理複雜度 (Prompt 版本控制)
• Day 5: 建立記憶 (多輪對話)
• Day 6: 理解複雜場景 (多人識別)
• Day 7: 自然湧現 (Bot 協作)

每一步都是為了下一步做準備，這就是這個 project「從 0 到 1」的過程。

未來的可能性

雖然跨部門 issue 追蹤還在規劃階段,但已經可以想像:

產品與支援團隊的 Bot 網路

想像一個由各個部門 Bot 組成的協作網路:

• 產品 Bot 群:各個產品線的專門 Bot
• Platform Bot:共用服務和框架
• DevOps Bot:部署和監控
• DBA Bot:資料庫效能和優化

當問題出現時，它們能自動組成「專案小組」來解決，不需要人工協調。

持續學習的系統

每次協作都在累積經驗:

• 學會產品間的依賴關係
• 學會問題的常見模式
• 建立跨部門的知識圖譜

小結: 設計的藝術

昨天我們完成了 N-1 的架構
而今天其實我們什麼 code 都沒改就已經自然而然的達到了 N-N 協作的基礎架構
雖然真正的應用還在規劃中, 但更重要的是理解了背後的設計思維:

這個架構之所以能支援 N-N 對話，完全是因為前面一連串的設計決策：

Day 3 的身份認知：

• 讓每個 Bot 知道「我是誰」
• 為 N-N 建立了基礎的身份系統

Day 5 的多輪對話：

• 利用 Slack Thread 作為對話容器
• 讓所有參與者（包含 Bot）共享同一個對話歷史

Day 6 的多人處理：

• 學會識別不同的對話參與者
• 理解「誰在對誰說話」

這些設計加在一起讓 bot 區別出「我」「你」「他」，自然而然的就形成了一個分散式的協作系統！

就像 Douglas Hofstadter 說的「當系統足夠複雜且能 self-reference 時，某種自我會出現」—— 我們的 Bot 網路也開始展現出超越設計的智慧了。

關鍵原則:

好的設計, 是讓系統的各個部分自然組合出預期的行為, 而不是強制實現每個功能。

明天我們要來聊另一個實務話題: 如何讓 AI 擁有我們的知識? 當然也就進到了 MCP 的部分了

當 Bot 處理複雜問題時，我們需要的不是跟 LLM 聊天，而是要能真正解決問題，明天將會分享如何利用 MCP 讓 LLM 擁有更多的知識

完整的原始碼在這裡
試著建立多個不同的 Bot 讓 Bot 們玩起來吧!

AI 的發展變化很快,目前這個想法以及專案也還在實驗中。但也許透過這個過程大家可以有一些經驗和想法互相交流,歡迎大家追蹤這個系列。

也歡迎追蹤我的 Threads @debuguy.dev