AI agent 上線後怎麼改進？Linear 讓 agent 自己開工單回報「這件事我做不到」

先問你一個問題。

你公司那個 AI 客服，上線到現在，一共有幾次被問倒？

我猜你答不出來。不是你不用心，是這個數字根本沒有人在記。客人問了一句它答不上來的話，它打太極打過去，對話結束，視窗關掉，這件事就從世界上消失了。

而那，很可能是你手上最值錢的一份資料。

先打掉一個預設：問題不在模型不夠聰明

專案管理工具 Linear 的產品負責人 Nan Yu（Head of Product），在 Peter Yang 的 podcast 上講了一句話，我覺得是整集最重要的判斷：

「現在應用 AI 最大的問題，不是 agent 不夠聰明，也不是模型不夠先進。問題是大家講的那個『能力過剩』（capability overhang）：模型其實很聰明，是我們用得不夠。」

這句話很值錢，因為它跟大部分人的直覺相反。

你的 AI 表現不好，你的第一個念頭是什麼？多半是「是不是要換更強的模型」，再不然就是「prompt 是不是要再寫長一點」。

Nan Yu 說，方向錯了。

模型的能力早就跑在你前面。真正卡住的是：你根本不知道使用者拿它想做什麼，也不知道它每天在哪裡默默失敗。 你沒有這兩份資料，換再強的模型也只是讓它用更漂亮的句子繼續答錯。

所以這篇不談架構怎麼搭。台灣多數電商團隊買的是別人做好的 AI，架構輪不到你決定。這篇談的是上線之後你自己得建的東西：回饋管線。

能力過剩（capability overhang）：模型的容量遠大於你實際用掉的那一小截。

先講清楚立場：這集 podcast 由 Linear 付費贊助，兩位來賓都是 Linear 員工，全片沒有引用任何第三方數據。所以下面我只取工程判斷，數字一個都不用。節目裡那個「6 分鐘生出 PR」的示範，是廠商拿自己的工具跑自己的一次 demo，我不當效益數據，你也不要。

管線一：讓 AI 自己開工單，說「這件事我做不到」

這是我聽完整集，覺得最該被抄走的一個機制。

Linear 的工程師 Jacob Shumway 是這樣描述的：

「我們有一個機制，讓 agent 可以回報它做不到的功能。如果使用者要它做一件它沒有工具能做的事，它會呼叫一個工具、把這件事回報給我們，我們再自動接進系統：去查有沒有既有的工單，有就併進去，沒有就開一張新的。所以我們會有一條持續流進來的工單，內容全部是『我們做不到什麼』。」

關鍵在第二步。agent 遇到做不到的事，沒有含糊帶過，而是呼叫一個專門用來「回報」的工具。剩下的查重、併單、開新單，全部自動。

所以 Linear 的 agent，是在 Linear 裡面，幫自己開缺功能的工單。

它不會自己把自己修好，修的還是人。它只負責一件事，把失敗講出來，而且講到一個有人會看的地方。

遇到做不到的事，agent 不是含糊帶過，是把它填成一張會被看到的工單。

這件事讓我想到我在雨傘產業那七年。

我在百貨當過櫃哥。站在櫃上你會遇到一種客人，他走過來問「你們有沒有那種可以自動收的、傘面再大一點的」，你翻了翻，沒有，你說不好意思這款我們沒進。他點點頭走了。

然後呢？然後就沒有了。

那句話不會出現在任何一張報表上。月底檢討會看的是賣掉的東西，沒有人在看「客人開口要、而我們給不出來」的東西。櫃上真正的情報不在成交的單子裡，在那些沒成交的對話裡。

你的 AI 客服現在就站在那個櫃位上。差別只在於，它一天遇到的客人比櫃哥多好幾百倍，而且它有能力把每一次「我給不出來」都記下來。

如果你問我，這是所有台灣電商今年最該補的一個洞。

管線二：驗收案例要從線上的意外長出來，不是在會議室裡想出來

站內我寫過 MCP server 開了就夠嗎？Linear 為什麼還要自己做原生 agent，那篇談的是「該驗什麼」，結論是驗收要對準你敢對外承諾的那幾條路。

這篇補的是下一個問題：那些驗收案例，你從哪裡生出來？

Nan Yu 的答案很直接：

「我們的 eval（自動化評測）有很大一部分，是從那些『這個行為很奇怪、或者很蠢，我跟你說為什麼』的時刻裡長出來的。然後那件事本身就變成一個 eval。」

Jacob Shumway 接著講了一個我很喜歡的例子。有個使用者叫了 agent 一聲「dude」（老兄），結果 agent 的反應是：

「喔，好吧，我不打算回你，因為你對我不夠正式。」

這件事好笑歸好笑，重點是它的下場：它變成了一條測試案例。

以前你的測試清單，是上線前幾個人關在會議室裡想出來的。現在你的測試清單，是使用者每天在線上幫你寫的。

而且這不只是 Linear 一家的偏方。Anthropic 建議 eval 資料集從 20 到 50 個真實失敗案例起手，效果勝過 500 個憑空想像的合成案例；業界通用的作法也是把線上抓到的失敗升級成回歸測試、接進 CI/CD，讓同一個 bug 不會出貨兩次。

客訴截圖不是笑話集，整理過就是你的第一版 eval 資料集。

還有一種失敗，比答錯更難抓，Nan Yu 特別點出來了。

他說他們有很多評測是圍繞「分寸」在做的。舉例：在 Slack 對話裡，使用者丟出一個追問，agent 內部會先跑一段判斷，「我覺得我答得出這題，但我現在該不該插話？」

他形容那類評測針對的是 ergonomic（體感）的時刻。他還講了另一個判準：使用者說一句話的時候，他其實想完成某個任務，agent 有沒有聽懂那件事？還是太急了，衝出去做了一件又貴又煩、使用者根本沒要的事？

翻成你的生意，這題就很有畫面了。

你的 AI 客服在對話到一半的時候，主動跳出來推薦了一檔活動。它講的內容完全正確，優惠也是真的。但客人當下正在問退貨要怎麼寄。

沒有任何一條規則被違反。這次對話也不會被記成「錯誤」。可是客人被惹毛了。

這種失敗不會出現在你的正確率報表上，只會出現在你的客訴裡。

管線三：使用者的意外用法，就是你的產品路線圖

第三條管線最便宜，因為你什麼都不用建，只要看。

Nan Yu 說 Linear 團隊被使用者嚇到的一個用法是翻譯。他們有不少客戶在法國，於是有人乾脆設了一條自動化：只要進來一張法文的 Intercom 客服工單，先翻譯，再建成 issue。

他的原話是，他們從來沒想過會有人這樣用，「這件事根本沒有出現在我們腦子裡過。」

主持人 Peter Yang 收得很好：把產品交到人手上，新的用法自己會冒出來。

這裡還有一個配套的態度，Jacob Shumway 講的：

「只要不涉及安全疑慮，使用者想問什麼我們其實都可以。你想要 agent 幫你寫一首詩？那就讓它寫。我們給它相當大的自由度。想把它鎖得太死，最後只會變成一個很讓人火大的產品。」

我知道台灣老闆聽到這裡會皺眉。把 AI 放這麼開，出事怎麼辦？

分兩層看就好。安全與金流的邊界該鎖死就鎖死，這沒得商量。但在那條線以內的探索行為，你要留空間，因為那些你沒想過的用法，就是你下一版產品的需求清單，而且是免費的。

台灣電商這週可以做的四件事

► 第一，在你的 AI 客服後台加一個「我做不到」的事件。 不用做得多漂亮，就是當它判斷自己答不了、或要轉真人的時候，把當下那句原始問題寫進一張表。一週後你打開來看，你會發現前五名的問題長得都一樣，而那五題多半用不到 AI，補一頁常見問題就解決了。

► 第二，把客訴截圖變成你的測試清單。 你手上一定有一個資料夾，裡面全是同事傳來的「你看它又亂講」。那不是笑話集，那是現成的 eval 資料集。挑 20 則整理成表格，寫清楚「這題正確答案應該長怎樣」。每次你換模型、改 prompt、換供應商，就把這 20 題重跑一次。

► 第三，每週花十分鐘看「使用者拿它做了什麼你沒設計過的事」。 不要只看滿意度分數，去翻對話原文。你會看到有人拿客服機器人問尺寸換算、問庫存哪天補、問能不能改地址。這些就是你的下一版功能。

► 第四，把「該不該插話」列進驗收項目。 除了答得對不對，加一條：它有沒有在客人問 A 的時候硬推 B。這一條你的供應商多半沒在驗，但它是實際上最傷體驗的那種失敗。

至於驗收迴圈本身怎麼設計、終點線要畫在哪，可以看我之前寫的 用 AI 的高手不寫更長的 prompt，他們設計「驗收迴圈」。想知道為什麼指令越加越多反而越糟，你的 AI 不是不夠聰明，是你管太多 那篇講得更完整。

最後

Linear 這套作法拆到底，其實只有一句話：他們讓系統自己把失敗講出來，而且講到一個有人會看的地方。

大部分公司導入 AI 的流程是這樣的：選型、簽約、串接、上線、然後看報表上的滿意度分數。分數還可以，那就繼續。

問題是那張報表只統計「它做了什麼」。它做不到什麼、使用者想要什麼卻要不到、它在什麼時候讓人覺得煩，全部不在上面。

以前你導入一套系統，上線就是專案結束，接下來叫維運。現在你導入一個 AI agent，上線只是資料開始流進來的那一天。你沒建回報管線，就等於這條線沒接上。

那個櫃上被問了卻給不出來的問題，我當年沒有工具可以記下來。

你現在有了。

所以這週先不用急著換模型。請客服主管拉出最近 20 則轉真人與客訴對話，整理成一張「AI 做不到清單」。

那張表，就是你的第一版 eval 資料集。

常見問題

Q：AI agent 上線之後要怎麼持續改進？ A：核心是建立回饋管線，而不是一直換更強的模型。Linear 團隊的三個作法是：讓 agent 主動回報它「沒有工具可以做」的請求並自動彙整成待辦、把線上出現的異常行為轉成評測案例、定期檢視使用者自己發明的非預期用法。三條管線的共同點是把原本會消失的資訊變成可以行動的紀錄。

Q：AI 的測試案例（eval）應該從哪裡來？ A：從真實使用中來。Linear 的 Nan Yu 說他們的評測很大一部分是從「這個行為很奇怪」的回報裡長出來的。Anthropic 也建議用 20 到 50 個真實失敗案例起手，勝過大量憑空想像的合成案例。實務上，你的客訴截圖和轉真人紀錄就是現成的資料集。

Q：AI 的 eval 資料集最小要怎麼開始做？ A：不需要先建系統。先收 20 則真實失敗案例就能開始，來源就是你的客訴截圖與轉真人紀錄。每一則記五個欄位：原始問題、AI 實際的回覆、理想答案應該長怎樣、失敗類型（答錯／答不出／時機不對）、是否應該轉真人。之後每次換模型、改 prompt 或換供應商，就把這 20 題重跑一次比對。這份表就是你的回歸測試，成本極低但擋掉的是重複犯的錯。

Q：為什麼我的 AI 客服換了更強的模型還是不好用？ A：因為多數情況下瓶頸不在模型能力。Linear 的 Nan Yu 用「能力過剩」（capability overhang）形容現況：模型其實很聰明，是我們用得不夠。如果你不知道使用者實際想拿它做什麼、也沒有紀錄它在哪裡失敗，換模型只會讓它用更好的句子繼續答錯。

Q：AI 答得都對，客人還是不滿意，問題出在哪？ A：很可能出在分寸而不是正確性。Nan Yu 指出他們有不少評測針對的是「體感」時刻，例如 agent 判斷「我答得出這題，但我該不該插話」，或者是不是太急著去做一件使用者根本沒要求、又貴又煩的事。這類失敗不會出現在正確率報表上，只會出現在客訴裡，所以要單獨列成驗收項目。

Q：AI 客服要不要限制使用者只能問特定問題？ A：Linear 的作法是安全相關的邊界鎖死，其餘給相當大的自由度。Jacob Shumway 的說法是，把它鎖得太死最後只會做出一個讓人火大的產品。實務建議是金流與個資相關動作嚴格限制，探索型的問答則保留空間，因為那些非預期用法往往就是下一版的需求來源。

資料來源

• Peter Yang podcast《5 Rules for Building AI Agents That Work in Production》，來賓為 Linear 的 Nan Yu（Head of Product）與 Jacob Shumway：YouTube
• AI Agent Testing Guide: Evals for Production（含 Anthropic 建議之 20-50 真實失敗案例）
• Evaluating AI Agents in Production, Arthur

利益揭露：本文引用的 podcast 由 Linear 付費贊助，兩位受訪者皆為 Linear 員工，全片未引用任何第三方數據。文中所有示範情境與時間數字皆為廠商自述，本文不予採用。該集標題所稱的「5 Rules」在對話全文中並未以清單形式出現。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。