自訂工具 / MCP

先看 agent 現在的能力邊界。聊天,靠的是模型訓練時學過的舊知識。搜尋工具,能查公開網路。RAG 知識庫,能查你上傳的靜態文件。但有一種問題,這三個全都答不出來 —— 「這張訂單出貨了嗎、追蹤碼多少」。這個答案只活在你的訂單系統裡,而且每天在變。要拿到它,就得把你的系統,包成一個 agent 能呼叫的工具。

把這件事畫成一張圖就清楚了。左邊是 agent 的四種能力:聊天、搜尋、RAG,都碰不到你內部會變動的資料。第四種,自訂工具,才是伸手出去、接你活系統的那座橋。而這座橋有兩個方向:你的 agent 去用別人的系統,這叫當使用方;或是把你的系統開放出去、讓別的 agent 來用,這叫當提供方,也就是 MCP 的兩端。這一集先走最基礎的:讓你自己的 agent,接得到你自己的系統。

怎麼包?你給 Dify 一份 OpenAPI 說明書,其實只講四件事。系統在哪、有什麼動作、要帶什麼參數、還有這個動作叫什麼、拿來幹嘛。第四點最關鍵 —— agent 就是靠這句描述,判斷「這一題該不該用這個工具」。描述寫得夠清楚,它才知道什麼時候該伸手;寫得含糊,它可能就自己亂編了。

工具接好、agent 答得漂亮,你先別急著相信。這一集最重要的一條紀律:用三方獨立證據交叉驗證。第一,你系統自己的存取紀錄 —— 請求到底有沒有進來。第二,Dify 的資料庫 —— agent 到底有沒有真的呼叫工具、拿回什麼。第三,答案裡有沒有出現「它編不出來的真資料」,比如一組它猜不到的追蹤碼。三邊時間對得上、內容對得上,才算真的通了 —— 而不是它講得很順、其實在唬爛。

接真系統的第一道牆,馬上來。Dify 為了防止被濫用去打內網,預設會封鎖所有對「私有 IP」的呼叫 —— 而你公司的 ERP、資料庫,幾乎都在內網。所以「讓 agent 接內部系統」第一步,一定會撞到這道 SSRF 防護。解法有兩種:在設定裡放行你信任的那個內網位址;或者讓系統走一個有有效憑證的公開網域。這一條,是「給公司所有人用」時,每一個內部系統都會遇到的關卡。

第二個坑,是認證。demo 免登入,但真系統通常要先登入、拿一把 token,而 token 會過期 —— 你貼死一個進去,大概一小時後就斷了,工具整個掛掉。正規解法是做一層自動換 token 的代理;但更省事的是,很多企業系統其實提供「給整合用的、不會過期的金鑰」。找到它、貼進去,這個難題就直接消失了。接真系統前,先問一句:這個系統有沒有長效整合金鑰?

第三個坑,最陰險,而且最容易被騙過去。前面兩種幻覺 —— 沒呼叫工具就亂編 ——你查一下紀錄就抓到了。但這一種不一樣:工具「有」呼叫、「有」拿回真資料,可是模型在最後總結那一步,還是把內容改寫、甚至換成完全不同的東西。表面上一切正常:有呼叫紀錄、有真回傳,答案卻是假的。能力比較弱的小模型、尤其是在一般電腦上跑本機時,特別容易犯這種錯。

那怎麼辦?關鍵是分清楚兩種做法。用 Agent 讓模型自由呼叫工具、再自由總結 ——彈性大,但總結那一步,模型有機會改寫、有機會幻覺。換成 Chatflow:工具參數寫死,查完直接把原文吐出來,中間完全不經過模型總結。同樣接你的系統,Chatflow 這條路 —— 零改寫、零幻覺、又快。對錯不得的資料 —— 財務、醫療、法遵 —— 你要的是「忠實呈現原始紀錄」,而不是一個講得很流暢、卻可能改了字的助手。

Chatflow 的忠實版其實很簡單,三個節點:開始、工具、直接回覆。工具的參數直接填死,不讓模型有插手的空間;直接回覆那格,一定要指向「工具的輸出」,而不是某個模型節點的輸出 —— 這是最容易接錯的地方。如果原始資料是一包 JSON、看起來很醜,再加一個模板轉換節點,純粹排版、一個字都不改。整條線走完,你得到的就是「你系統裡的真資料,原封不動、排整齊」。

所以不是 Agent 比較高級、Chatflow 比較低階,而是看資料錯不錯得起。探索式的、可以容錯的、需要來回對話的,用 Agent。錯不得的、要一字不差的、流程固定的,用 Chatflow。接任何一個內部系統之前,先問自己一句:這份資料,錯得起嗎?答案會直接決定你該用哪一種架構。

留給你一句話:把系統包成工具不難,難在「別被漂亮的答案騙了」。接得到是第一步;更重要的是驗得穿 —— 用你系統的紀錄、平台的資料庫、還有那些「模型編不出來的真資料」,去確認它是真的查了、還是在唬爛。而對錯不得的資料,寧可用最笨、最忠實的 Chatflow,也不要一個會改字的聰明 agent。