湯是對的，但食譜抄錯人了：MCP 代理的來源問題，你家廚房早就遇過

2026年9月30日，APPI News 刊出一篇關於 MCP 代理來源驗證的長文。事情說來有點繞：AI 代理可以同時查資料庫、用搜尋工具、翻文件，再把找到的東西整理成一段回答。麻煩在於，答案裡的某句話明明有根據，它卻可能把功勞記到錯的來源頭上。

這件事搬進廚房，你一定秒懂。

味道對了，出處卻記錯了

你一定聽過家裡長輩這樣講：「這道紅燒肉是你阿嬤教我的。」燉出來的顏色也對，醬香也對，肥肉顫巍巍地亮著，筷子一夾就散。可是後來翻舊相簿才發現，這做法根本是當年隔壁巷子那位四川鄰居教的，阿嬤只負責在旁邊喊了句「糖色別炒過頭」。

菜沒有錯，錯的是出處。

那篇報導裡的客服代理也是這樣。它讀了帳戶紀錄和退款政策兩份資料，然後回答：「依帳戶紀錄，這個方案提供 30 天退款期。」30 天退款期確實存在，只寫在政策文件裡，帳戶紀錄半個字沒提。把兩份資料倒在一起看，文字好像有根據；一份一份分開核對，才發現答案指錯了依據。就像你把阿嬤和鄰居的話混在一起聽，紅燒肉的功勞就這樣記錯了人。

廚房裡記錯食譜出處，頂多年夜飯桌上被長輩糾正一下。但答案記錯依據文件，使用者可能照著錯的那份去判斷退款資格，事後要追溯也找不到答案到底依據哪份文件。這跟做菜時忘了「鹽是哪一步加的」一樣，下次要重現那個味道，就沒了線索。

一句一 fact，像備料一樣切開

報導介紹了一個叫 ProvenanceGuard 的方法，刊登在 Hugging Face 上的研究。它的做法拆開來看，跟廚房備料的邏輯很像。

首先是留記錄。代理每次呼叫工具、拿到輸出，都儲存成所謂的 MCP trace，每筆證據帶著工具類型、來源識別碼與內容。這就像你做菜時把每包食材的標籤留著：這把青蔥是哪個市場哪個攤的，這塊梅花肉儲存期限到哪天。標籤丟了，東西還能煮，但出了問題就查不回去。

接著是拆解。答案被切成「原子主張」，一句只保留一個可檢查的事實，連同句中的來源說法、數字、日期、單位一起留著。退款的例子拆出來，就是「退款期限為 30 天」這個主張，加上「帳戶紀錄」這個歸屬。這跟把一鍋湯的步驟拆開寫是一樣的：高湯熬多久、鹽下多少、起鍋前淋的酒是哪一種，一行一行列清楚，才知道哪一步出了問題。

最後是逐項比對。每項主張被路由到最相關的來源，用推論模型判斷那份資料是支持、矛盾，還是不足以判定，再獨立檢查答案宣稱的來源跟實際支持的來源是不是同一個。30 天退款期對照政策文件，成立；對照帳戶紀錄，落空。來源歸屬的錯，就是在這一步被抓出來的。

這讓人想起我們之前聊過的沒掛保證的 App 跟沒招牌的麵攤，餐桌上的信任向來是認來源的。誰說的、哪裡來的，跟說了什麼一樣重要。

數字會說話，但只在它的廚房裡

這份研究是篇 arXiv 預印本，測試場景是 281 筆醫療領域的 MCP trace，保留測試集裡 361 項主張經人工專家覆核。結果怎麼樣？應阻擋的 139 項主張裡，138 項被攔下、1 項放行，召回率相當高；但有支持依據的 222 項裡，67 項被誤攔，精確率因此只有 0.673。另外以 260 項有來源標註的主張計，來源準確率是 0.858。

白話一點：這個驗證器很會抓有問題的，但也常錯殺無辜的。像一位很嚴格的阿嬤試味道，一覺得不對就整鍋打掉重做，寧可錯殺，不放過。被誤攔的主張會送交覆核或修復，改寫成有來源支持的說法再重新驗證。報導也提醒，這些數字屬於特定測試設定，不能直接當成各產業的成效保證。

還有一個限制值得記著：相似來源之間的精確辨認仍然喫力。這就像市場裡兩攤都賣現摘的地瓜葉，葉片形狀、斷口的水色幾乎一樣，只有攤主知道哪把是自家田哪把是批來的。工具名稱跟來源識別碼不穩定時，方法只能退回用工具名稱當標記，判斷的細節就粗了。

事後把關，不能取代親自看鍋

報導的最後態度很清楚：這仍是事後檢查層，不會替來源本身背書，也不會自動證明沒列出的事實都正確。來源驗證，最終仍需人工把關。

其實這跟做一道新菜的過程差不多。你可以照著 一邊看食譜一邊動手問 的方式查資料、問工具、把答案拼起來，但起鍋前那一口，還是得自己嘗。湯頭是誰教的、鹽是照誰的方子下的、那份方子又是從哪抄來的，這些出處的帳，廚房裡的人從來都是一筆一筆自己記的。

下次聽到有人說「這是有根據的」，不妨多問一句：根據的是哪一份？就像聽到「這是阿嬤的味道」，可以問問，是阿嬤的手，還是阿嬤只是剛好在場。菜是真的，味道是真的，只是故事的主角，偶爾會記錯人。