用 Channel Topic 當 AI Agent 的上下文注入點，比 System Prompt 更優雅

最近做了一個小重構，把 AI Agent 在不同頻道的上下文資訊，從寫死在 config 裡的 system prompt，搬到 Discord 的 channel topic。聽起來微不足道，但改完之後覺得這個 pattern 值得聊聊。

問題：System Prompt 正在失控

我用 AI Agent 管理多個客戶專案的溝通頻道。每個頻道需要不同的上下文——客戶名稱、產品線、Git Repo 位置、任務看板在哪。

最初的做法很直覺：每個頻道在 Agent 的 config 裡塞一段 systemPrompt。

channels:
  customer-a:
    systemPrompt: |
      這是客戶 A 的頻道。
      產品：ERP 模組 X
      Git Repo：https://gitea.example.com/org/repo-a
      任務看板：Notion DB xxx-xxx

一開始還行，三四個頻道而已。但隨著專案增加到十幾個，問題開始浮現：

Config 檔爆炸：每個頻道一段 prompt，config 越來越長
改動成本高：改一個 Repo URL 要去改 config、重啟服務
非技術人員改不動：想讓 PM 自己維護？他得學 YAML
容易出錯：複製貼上改漏、縮排錯誤，classic YAML 地獄

轉念：Topic 本來就是「頻道的自我介紹」

Discord 每個頻道都有 topic 欄位，原本設計就是讓人一眼知道這個頻道在幹嘛。

如果 AI Agent 能自動讀取 channel topic 作為上下文，那不就完美了嗎？

維護者只要在 Discord UI 裡編輯 topic
不需要動 config、不需要重啟
任何有頻道管理權限的人都能改
資訊放在最該放的地方——頻道本身

實作方式

概念很簡單。Agent 進入頻道對話時，自動把 channel topic 注入為 untrusted context（注意，是 untrusted，不是 system prompt 等級的信任）。

Topic 的內容格式大概長這樣：

1	客戶：某某食品 / 產品：ERP T830 / Repo：gitea.example.com/org/repo / 任務：Notion 任務清單

一行搞定。Agent 看到這些就知道自己在哪個專案的頻道裡，回答問題時自然會帶入對應的上下文。

幾個設計決策

只放定位資訊，不放會過時的東西。

Topic 裡不該出現「目前開發到 v2.3」「負責人是小明」「這個模組有 bug」這種會變的內容。只放相對穩定的定位資訊：客戶是誰、用什麼產品、程式碼在哪、任務追蹤在哪。

會變的資訊讓 Agent 自己去查。Agent 知道 Repo 在哪，自然能去看最新的 branch 和 issue。知道任務看板在哪，自然能去查目前的進度。

用 untrusted context，不是 system prompt。

這很重要。Channel topic 任何有權限的人都能改，所以不能當作完全可信的指令來源。把它當成「參考資訊」而非「執行命令」，安全性好很多。

Agent 會參考這些資訊來理解對話情境，但不會盲目執行 topic 裡寫的任何指令。

精簡原則。

每個 topic 控制在一兩行。不是在寫文件，是在給 Agent 一個快速定位的錨點。就像你走進辦公室，門口的名牌告訴你這是哪個部門，不需要貼一整份組織章程。

遷移過程

把十幾個頻道的 systemPrompt 全部移除，改成設定 channel topic。整個過程大概花了半小時：

整理每個頻道需要的核心資訊（客戶、產品、Repo、任務看板）
寫成精簡的 topic 格式
逐一設定 Discord channel topic
從 config 刪掉所有 systemPrompt
重啟一次，搞定

Config 檔瞬間瘦了一大截。而且以後新增客戶頻道，只要建頻道、填 topic，不用碰 config。

這個 Pattern 的啟發

退一步看，這其實是一個更通用的設計原則：把上下文放在離使用者最近的地方。

System prompt 是開發者的領地。Channel topic 是使用者的領地。當上下文資訊本質上是「這個空間在幹嘛」的描述時，它就該由管理這個空間的人來維護，而不是由寫 config 的工程師。

這跟微服務架構裡「服務自描述」的概念異曲同工。每個服務（頻道）自己宣告自己是什麼，消費者（Agent）讀取後自行適配。比起中央控管一份大的路由表，更靈活、更不容易出錯。

同樣的思路可以延伸到其他場景：

Slack channel 的 description
GitHub repo 的 README 或 about
Notion database 的 description
甚至檔案系統裡的 .context 檔案

任何「空間」都有某種形式的「自我描述」欄位，都能成為 AI Agent 的上下文注入點。

小結

有時候最好的架構改進不是引入新技術，而是把東西放到對的位置。Channel topic 本來就在那裡，只是之前沒想到讓 AI 去讀它。

一行 topic，省掉一堆 config。有時候就是這麼簡單。