打造真的能運作的 AI 代理

一個 AI 代理是一個具備採取行動能力的 LLM。它不只是產生文字,還能呼叫 API、查詢資料庫、發送訊息、觸發工作流,並在迴圈中做決策。它承諾的是自動化:一個不需要人類持續監看就能處理任務的系統。

實情更微妙。代理在範圍清楚、邊界明確的任務上表現傑出。當被交付模糊目標、無限工具存取、零護欄時,它們會壯烈崩潰。demo 代理與生產 代理的差別不在 LLM — 而在 LLM 周圍的一切。

代理到底是什麼

撕掉炒作,代理有四個組成:

LLM 接收輸入(使用者訊息、排程觸發、事件)。決定要呼叫哪些工具。透過 MCP 伺服器呼叫。接收結果。決定下一步要做什麼。這個迴圈會持續到任務完成,或 代理決定停下來。

理論上很簡單。魔鬼藏在每一個細節裡。

在 Zubnet 打造代理

在平台上,建立一個代理有四個步驟。每一步都有一些決策,決定你的代理是穩定運作,還是變成凌晨 3 點電話的來源。

1. 建立代理

給它一個名字、選一個模型、寫一個系統提示詞。

模型比你想的還重要。對於必須可靠呼叫工具的代理,用推理能力強的模型。Claude Sonnet 4、GPT-4.1 或 Gemini 2.5 Pro。小模型比較省錢,但工具呼叫的決策較差,而 代理裡一個爛工具呼叫不只是爛回答 — 而是爛動作。

系統提示詞是你代理的憲法。對以下內容要寫明白:

• 代理應該做什麼(還有絕對不能做什麼)
• 何時使用每個工具、何時跳過
• 如何處理錯誤與模糊情境
• 何時問使用者釐清 vs. 直接做決定
• 訊息裡用什麼語氣

2. 連一個通道

通道是代理跟世界溝通的方式。在 Zubnet 你可以連:

• Telegram — 從 @BotFather 貼上你的 bot token
• Discord — 從 Discord Developer Portal 貼上你的 bot token
• Webhook — 任何可以收發 JSON 的 HTTP 端點

通道決定代理住在哪裡。Telegram bot 代理在 Telegram 聊天裡回應。Discord bot 代理住在你的 Discord 伺服器裡。Webhook 代理回應 API 呼叫。

挑一個通道開始。第一天不要嘗試打造跨通道代理。先在一個平台上把它做到穩定再說。

3. 加上工具(MCP 伺服器)

工具是讓代理超越聊天機器人的東西。在 Zubnet,工具是由 MCP 伺服器(Model Context Protocol)提供。我們有 117 個。一些範例:

• GitHub — 搜尋儲存庫、建立 issue、讀檔案、列 PR
• PostgreSQL / MySQL — 查詢資料庫(夠聰明就設成唯讀)
• Brave Search — 網頁搜尋
• Filesystem — 讀寫檔案
• Slack — 傳訊息、讀頻道

啟用你需要的伺服器、設定它們的憑證(API 金鑰、資料庫 URL),然後代理就能使用它們。

4. 設定觸發條件

觸發條件決定代理何時啟動:

• 使用者訊息 — 有人傳訊息給 bot 就回應(聊天代理的預設)
• Cron 排程 — 在固定時間跑(例如「每天早上 9 點」)
• 事件 — 某件特定事情發生時觸發(webhook payload 符合某模式)

Cron 觸發的代理非常適合重複任務:每日站會摘要、每週分析報告、監控檢查。事件觸發的代理處理反應式工作流:新 GitHub issue → 分類並貼標、新客服工單 → 草擬回覆。

困難的部分

打造代理要 20 分鐘。讓它穩定要幾週。以下是生產 代理真正出包的地方:

錯誤處理:LLM 幻覺出一個工具呼叫時

LLM 有時會用錯的參數呼叫工具、呼叫不存在的工具,或在錯誤情境下呼叫對的工具。你的代理必須優雅地處理這些。

在 Zubnet,失敗的工具呼叫會把錯誤訊息回傳給 LLM,LLM 再決定要怎麼做。但你得在系統提示詞裡告訴它怎麼做:

If a tool call fails:
1. Do NOT retry the same call with the same parameters
2. Analyze the error message
3. If it is a permission error, tell the user you cannot do that
4. If it is a rate limit, wait and try once more
5. If it is an unknown error, summarize what happened and ask for help
6. Never retry more than twice total

沒有這些指令,代理會卡在重試迴圈,在同一個失敗的呼叫上一直燒掉 token 與時間。

速率限制:頻率上限

一個連上擁有 500 位活躍使用者的忙碌 Discord 伺服器的代理,每分鐘可能收到幾百則訊息。沒有速率限制,它會:

• 幾小時內燒光你的 API token預算
• 撞上供應商的速率上限、開始回傳錯誤
• 產生太多回應,讓頻道無法使用

設定頻率上限。在 Zubnet 你可以設:

• 每分鐘最多回應幾則(每個通道)
• 每小時最多 token(預算控制)
• 對同一使用者的回應之間的冷卻時間
• 佇列深度上限(落後太多時丟棄訊息)

權限:限制代理能做的事

這是會救你一命的部分。代理該有的,是做好工作所需的最小權限。

• 資料庫工具:除非明確需要寫入,否則只讀
• GitHub 工具:讀取 + 建立 issue,但不能關閉/合併/刪除
• 檔案系統工具:只指定特定目錄,絕對不是 /
• 訊息工具:只指定特定頻道,絕對不要 DM 給主管

這樣想:這個代理用它現有的工具,最糟能幹出什麼事?如果答案讓你緊張,就把權限收掉。

優雅降級

當某個工具當掉,代理不該直接失敗。它該承認限制、並在沒有那個工具的情況下做它能做的事。把這寫進系統提示詞裡:

If a tool is unavailable or returning errors:
- Acknowledge it to the user: "I cannot access GitHub right now"
- Do what you can without that tool
- Never make up data to compensate for a missing tool
- Suggest the user try again later

真實範例

範例 1:客服機器人

一個用你的知識庫回答客戶問題的 Telegram bot。

• 模型:Claude Sonnet 4(擅長遵循指令)
• 工具:Brave Search(文件)、PostgreSQL(唯讀、查帳號用)
• 通道:Telegram
• 觸發:使用者訊息
• 速率上限:每分鐘 30 則回覆、每位使用者之間 2 秒冷卻

系統提示詞重點在:先從文件回答;不確定就升級給真人;絕不洩漏其他客戶的資料;不要對功能或時程做保證。

範例 2:每日摘要代理

一個在早上張貼「昨晚發生了什麼」摘要的 Discord bot。

• 模型:GPT-4.1(擅長結構化摘要)
• 工具:GitHub(讀 PR 和 issue)、Slack(讀頻道)
• 通道:Discord(#daily-summary 頻道)
• 觸發:cron,平日早上 9:00
• 速率上限:每次觸發 1 則訊息(只觸發一次)

系統提示詞重點在:摘要合併的 PR、開/關的 issue、Slack 重要討論。控制在 500 字以內。用項目符號。標記相關團隊成員。

範例 3:內容監控

一個盯著特定事件、在團隊需要時發出警示的代理。

• 模型:Gemini 2.5 Pro(快、擅長分類)
• 工具:Brave Search(監控提及)、Slack(發警示)
• 通道:webhook(由監控服務觸發)
• 觸發:事件(帶搜尋結果的 webhook)
• 速率上限:每小時 10 則警示(避免警示疲勞)

系統提示詞重點在:把提及分類為正向/負向/中立、只在負向或關鍵情況發警示、附上來源 URL 和一句話摘要。

測試:從小開始

Zubnet 代理有兩種模式:

• 快速模式 — 簡化設定,適合測試。有限的工具設定、基本觸發。用來驗證你的代理概念能不能動。
• 進階模式 — 完整設定、可上線。詳盡的系統提示詞、細緻的速率上限、權限控制、多重觸發。

永遠從快速模式開始。把基本行為做到好。然後升級到進階模式並加上護欄。

關於代理的不舒服真相

代理不是魔法。它們是帶著工具存取的迴圈式 LLM。它們會犯錯。有時候會做錯事。問題不是「我的代理會不會犯錯?」— 而是「它犯錯的時候會怎樣?」

在生產裡真正能運作的代理都具備:

• 緊湊的範圍(「把這一件事做好」)
• 明確的邊界(「這些事永遠不要做」)
• 有限的權限(最小權限,永遠)
• 速率上限與預算上限(避免成本失控)
• 人工升級管道(「有疑問就問人」)
• 監控與記錄(才能知道發生了什麼)

---

Zubnet 上的代理開放給所有使用者。從一個簡單的 Telegram 或 Discord bot 開始,把它做對,再擴展。基礎設施會處理困難的部分 — 你只要專注在系統提示詞、工具與護欄上。

準備打造?到 zubnet.com 建立你的第一個代理