一位略懂 AI的創辦人對於大規模運營 LLM 與自主 Agent究竟需要什麼的《略懂》觀點
兩年前我決定將原本的對話式商務 SaaS進行 Pivot，創辦了一家 AI 基礎設施公司。當初的立論很簡單：隨著 AI 從研究領域的新奇事物轉變為生產環境的現實，必須有人來打造讓它穩定運作的基礎設施層。我沒料到的是，「可運作在生產環境的 AI」和我過去接觸過的所有基礎建設與軟體開發類別竟然有著遠超出我預期的鴻溝。
這篇文章試圖分享我一路走來的心得（未完待續），不只是關於在這個領域創業的經驗，更關於組織在試圖將大型語言模型和日益自主的 AI 代理投入運營時，正在經歷的深層轉變。無論你是每天與這些系統搏鬥的實務工作者、試圖看懂這個領域的投資人，還是在相似航道上摸索的創業者，希望這裡的內容對你有所幫助。
讓我先從一個令人不安的事實說起，這個事實我花了兩年才真正體會。
「AI 上線」的迷思
當我 Pivot #戴伊爾斯 這家公司時，業界/市場普遍認為 #MLOps 的問題大致上已經解決了。我們有特徵儲存庫、模型註冊中心、編排框架和監控方案，方法論已經成形，只需要把它延伸到 LLM 就好。
結果證明這個想法與事實偏差的有些遠。
將大型語言模型投入維運的挑戰，並不是只是傳統 MLOps 挑戰的延伸，它們在本質上是全然不同的問題，需要截然不同的方法。自主 Agents更是如此，它帶來的複雜度讓駕馭 LLM 相形之下顯得單純。
具體點來說是這樣的：在傳統 MLOps 中，你的模型是一個函數，給定輸入 X，產生輸出 Y。這個函數或許複雜，但它是確定性的、有邊界的。你可以用準確率、精確率、召回率等指標來描述它的行為，可以對它做版本控制、測試，然後有信心地部署，清楚知道它會怎麼運作。
LLM 則打破了這個模式，它們不是函數，而是具有湧現行為（幻覺可能、機率性輸出）的推理引擎，無法用靜態指標完整描述。它們的輸出取決於提示的建構方式、上下文視窗的內容管理、溫度參數設定，以及這眾多因素之間的微妙交互作用。兩個完全相同的查詢可能產生截然不同的回應，而「正確性」往往是主觀的、依賴情境的，沒有人類判斷就無法評估。
Agent 讓情況更加複雜，現在你要處理的不只是非確定性的輸出，還有非確定性的行動序列、工具呼叫和決策，而這些都可能在真實世界中造成後果。失敗的影響範圍不再只是一個錯誤的預測，而是一個自主系統在你無法完全掌控的環境中，採取了你意想不到的行動。
這不是複雜度的漸進式增加，而是一個相變（Phase Transition）與複合式的複雜度提升，讓傳統 MLOps 工具的許多基本假設都瀕於失效邊緣。
真正重要的五大挑戰
在這個領域耕耘幾年後，與近五十家試圖將 AI 系統上線的團隊合作之後，我逐漸確信有五個挑戰凌駕一切。把這些做對，你才有成功的機會；做錯了，再高明的工程也救不了你。
挑戰一：可觀測性落差
傳統監控告訴你系統是否在運行、回應速度多快。這是必要的，但對於生產環境 AI 遠遠不夠。
你真正需要知道的是：輸出品質好不好？有沒有在變差？模型為什麼這樣說？推理過程中發生了什麼？當代理決定採取某個行動時，是什麼導致了這個決定？
這就是可觀測性落差，也就是我們能測量的和我們需要理解的之間的距離。要彌合這個落差，需要的儀表化程度遠超出請求延遲和錯誤率。
對 LLM 應用程式而言，實用的可觀測性至少需要包含：
- 語義追蹤：不只追蹤請求，還要追蹤推理路徑，包括中間步驟、工具呼叫和決策點。當 Agent失敗時，你需要理解導致失敗的思維鏈。
- 輸出品質訊號：捕捉關於輸出是否真正優良的隱性和顯性回饋，可能是使用者的修正、下游任務的成功與否，或是人工評估的樣本。沒有這些，你就是在盲目飛行。
- 漂移偵測：識別模型行為何時正在改變，無論是因為模型本身變了，還是因為輸入的分布發生了變化。不同於傳統 ML 的漂移，LLM 的漂移往往以微妙的方式顯現，需要語義層面的理解才能偵測。
- 成本歸因：了解推論成本流向何處、哪些提示比較昂貴、哪些使用者或使用情境在推高帳單。由於推論成本經常超過基礎設施成本，這在規模化後將會是日常維運必須要考量的重要因子。
在生產環境中成功的團隊，會在早期就建立這些能力。掙扎的團隊則往往是等到問題浮現後才補上，但到那時候，技術債已經讓有意義的改進變得極為困難。
挑戰二：評估難題
你怎麼知道你的 AI 系統有在運作？這個問題聽起來簡單，但當你試圖嚴謹地回答時，就會發現有多棘手。
對於分類模型，你有附帶真實標籤的測試集。但對於生成自然語言、創意方案或複雜推理的 LLM，通常沒有可供比較的正確答案。即使有，判斷一個回應是否「正確」也可能需要昂貴且無法規模化的領域專業知識。
評估難題其實是三個不同的問題：
- 部署前評估：在你推出變更之前，怎麼知道它不會讓情況變糟？這需要涵蓋所有可能輸入和預期行為的測試套件。但對 LLM 來說，那個空間是無限且很難定義邊界的，而「預期行為」往往定義不清。
- 執行期評估：上線之後，怎麼知道一切正常運作？這需要結合自動化品質訊號和抽樣人工審查。挑戰在於如何在不造成人力瓶頸的情況下獲得足夠的訊號。
- 持續評估：隨著時間推移，怎麼知道系統是在進步還是退化？這需要基準指標、趨勢分析，以及在生產環境中進行對照實驗的能力。
我見過合作夥伴們用截然不同的方式處理這個問題，有些大量投資於合成測試生成，用模型來產生測試邊界條件的測試案例；有些則依賴生產環境抽樣配合人工審查。最成熟的團隊兩者兼用，以自動訊號確保覆蓋率，以人工評估進行校準。
行不通的做法是：在沒有任何評估框架的情況下推出變更，然後指望使用者會在出問題時抱怨。等到投訴浮出水面時，你通常已經影響了數千名使用者的體驗，失去了難以重建的信任。
挑戰三：可靠性的必要性
AI 系統的失敗方式是傳統軟體不會有的，模型會產生幻覺，Agent 會採取出乎意料的行動，上下文視窗會溢出，API 會逾時，單一請求的成本可能超出你整個月的預算。
在這個脈絡下，可靠性的意義不只是正常運行時間，它意味著：
- 優雅降級：當主要模型無法使用或太慢時，能夠回退到替代方案，且不對使用者造成可見的干擾。這需要路由邏輯、回退鏈，以及謹慎的逾時管理。
- 輸出驗證：在將模型輸出傳遞到下游之前，檢查它們是否符合基本的合理性要求。JSON 能不能解析？回應是否包含禁止的內容？信心度是否高到足以據此行動？
- 護欄與約束：防止系統採取違反業務規則、安全要求或使用者信任的行動或輸出。這對 Agent來說這尤其關鍵，你需要能在事情出錯時中斷自主行動序列的熔斷器。
- 冪等性與復原：當故障發生在序列中間時，能夠恢復執行而不重複工作或重複執行動作。當你的系統牽涉到多次模型呼叫、工具調用和狀態變更時，這出乎意料地困難。
縱深防禦是必要的，我們必須假設每一層都會失敗，並在每個層級建立偵測和復原機制。真正達到可靠性的團隊，並不是失敗得更少，而是偵測得更快、控制得更好、復原得更優雅。
挑戰四：推論的經濟學
這裡有件事會讓許多剛接觸生產環境 LLM 的團隊大吃一驚：推論成本經常比傳統基礎設施成本高出一個數量級。
一次使用完整上下文視窗的 GPT-5.2 呼叫，成本比服務一個傳統網頁請求整整一個月還要高。放大到數百萬使用者，你面對的基礎設施帳單足以決定單位經濟學的成敗。
管理這些經濟因素需要：
- Token 最佳化：你的提示中每一個 token 都要花錢。積極壓縮上下文、謹慎選擇放入上下文視窗的內容，以及快取重複內容，都能大幅降低成本。
- 模型路由：不是每個請求都需要你最強大的模型。智慧路由可以將簡單查詢送往較便宜的模型，將昂貴模型保留給複雜案例，如此可在品質不明顯下降的情況下削減 50% 以上的成本。
- 快取策略：許多 LLM 查詢與先前的查詢有顯著重疊。語義快取可以識別新查詢何時與已快取的查詢足夠相似，從而重用回應，帶來可觀的節省。
- 成本可見性與治理：了解成本從何而來、設定預算與上限，並提供團隊做出具成本意識決策所需的資料。沒有可見性，成本往往會失控成長。
我見過擁有可行產品的團隊，因為無法讓經濟學運作而失敗。「在 demo 中能跑」和「在規模化後以可持續的單位經濟學運作」之間的落差，往往比預期的更大。從一開始就將成本意識內建到基礎設施中，比事後改造要容易得多。
挑戰五：開發者體驗的悖論
這是一個悖論：AI 系統同時比傳統軟體更容易建構，也更難建構。
說它更容易，是因為你可以很快做出令人驚艷的 demo。抓一個 API、寫一段提示，你就有了感覺像魔法的東西。打造一個能獨立運作的東西，門檻比以往任何時候都低。
說它更難，是因為要讓這些系統達到生產就緒，需要新的技能、新的工具和新的思維方式。從 demo 到生產的距離，比傳統軟體開發更遠。
這就造成了開發者體驗的挑戰。你如何賦予開發者 AI 能力的力量，同時幫助他們避開陷阱？如何讓正確地建構變得容易，又不讓建構本身變得不可能？
我見過最好的開發者體驗有幾個共同特徵：
- 預設護欄：讓安全的路徑成為容易的路徑。如果開發者必須主動退出最佳實務而非主動加入，他們更可能交付可靠的系統。
- 漸進式揭露：從簡單開始，按下要來揭露複雜性。不是每個人都需要在第一天就理解上下文視窗管理，但當他們準備好時，這個能力應該在那裡。
- 快速回饋循環：讓開發者能夠迅速看到變更的效果，無論是透過預覽環境、測試框架還是可觀測性主控台。
- 清晰的心智模型：提供思考 AI 系統行為的框架，幫助開發者建立關於什麼行得通、什麼行不通的直覺。
能打造出色 AI 應用程式的團隊，背後通常有強大的 AI 平台能力在支撐。無論是自建還是從供應商組裝而成，基礎設施層決定了開發者的生產力。
Agent前沿：當 AI 開始採取行動
到目前為止我描述的一切，都同時適用於 LLM 應用程式和自主 Agent。但 Agent引入了額外的挑戰，值得特別關注。
當你的 AI 系統可以在真實世界中採取行動（發送電子郵件、執行程式碼、呼叫 API、修改資料庫），賭注就從根本上改變了。聊天介面中的幻覺只是一個麻煩，自主系統中的幻覺可能是一場災難。
這就是 Agent運營的核心挑戰：你如何給 AI 系統足夠的自主權使其有用，同時保持足夠的控制使其安全？
我見過最有效的框架包含：
- 明確的行動邊界：清楚定義 Agent可以採取什麼行動、在什麼條件下、有什麼限制。這不只是技術約束，而是塑造 Agent能完成什麼的設計決策。
- Human-in-the-Loop 的斷點：識別哪些決策在執行前應該需要人類核准。藝術在於把斷點放在正確的位置，太少你會失去控制，太多你會失去自動化的好處。
- 可逆性作為設計原則：優先選擇可以撤銷的行動，而非不可逆的行動。當代理必須採取不可逆的行動時，需要更高的信心門檻和額外的驗證。
- 全面的稽核軌跡：記錄的不只是代理做了什麼，還有為什麼這樣做。當出問題時，你需要理解導致結果的決策鏈與 Context Graph。
- 模擬與 Sandbox：在複製生產環境但沒有實際後果的環境中測試 Agent行為。這比聽起來更難，Agent 往往對難以複製的環境細節很敏感。
成功打造 Agent驅動產品的公司，往往從狹窄、定義明確的使用案例開始，然後逐步擴展。他們抵制在早期就給 Agent廣泛能力的誘惑，並大量投資於讓人類操作員能夠理解和糾正代理行為的監控與介入能力。
市場動態：產業的走向
讓我從技術挑戰轉向市場觀察。在這個領域三年之後，某些模式已經變得清晰。
整合週期即將到來
目前 AI 基礎設施的版圖極度分散，有數十家公司（其實超多）處理問題的每一個切片（可觀測性、評估、部署、成本管理、安全），每個月還有更多公司冒出來。
這種分散對任何人都沒有好處。客戶最後得把多個無法順暢整合的單點方案拼湊在一起；供應商則用沒有差異化的產品競爭重疊的使用案例；資本分散到太多玩家身上，導致沒有任何一家能達到真正的規模。
整合是不可避免的，問題是它會以什麼形式發生。我看到三種可能的模式：
- 平台整合：少數幾個涵蓋完整生命週期的綜合平台興起，類似於 Datadog 整合監控市場的模式。客戶偏好整合體驗，勝過同類最佳的單點方案。
- 雲端供應商吸收：AWS、Google Cloud 和 Azure 自建或收購關鍵能力，讓 AI 基礎設施成為雲端平台的一個功能，而非一個獨立類別。
- 工作流程導向的垂直整合：成功的公司不是圍繞水平平台出現，而是圍繞特定工作流程（程式碼助手、客服自動化、內容生成、製造業 AI、醫療保健 AI、建築業 AI、部署廠房 AI…etc）出現，並內建基礎設施能力。
我猜測我們會看到這三種模式同時發生，不同的方法在不同的市場區隔勝出。企業買家可能偏好平台，新創公司可能偏好雲原生方案，垂直領域的專家可能偏好垂直整合。
我確信不會持續的是目前的分散狀態。市場根本無法支撐數十個可觀測性供應商、數十個評估框架和數十個部署平台。現實終將迫使整合發生，不管我們喜不喜歡。
高度客製化交付的誘惑
Marc Andrusko 最近那篇談「The Palantirization of Everything」的文章，非常值得閱讀。他的核心論點是：許多 AI 公司把自己定位為高度客製化的方案提供商，承諾派遣駐點工程師去讓 AI 在複雜的企業環境中運作。
這種模式很誘人，尤其是對專注企業市場的 AI 基礎設施公司。客戶的環境很混亂，整合很困難，派工程師去解決問題感覺是阻力最小的路。
但正如 Andrusko 指出的，大多數採用這種模式的公司，正在把自己變成一家擁有軟體估值的服務公司。Palantir 的成功來自數十年的平台投資、高到足以支撐永久工程駐點的合約金額，以及沒有替代方案的關鍵任務客戶。這些條件對我們大多數人來說並不存在。
從他論述中我理解到的事情是：高度客製化的導入必須是通往產品能力的橋樑，而非永久狀態。如果你的工程師在每個客戶那裡都在手動解決相同的問題，那不是差異化，那是產品的失敗。目標應該是把那些專業知識編碼成可規模化的軟體。
這對我們如何建構 AI 基礎設施有直接影響，每一個客製化整合、每一個一次性方案、每一個「我們會幫你處理」的承諾，都應該附帶一個產品化計劃。會勝出的公司，是那些搞清楚如何讓複雜的導入變簡單的公司，而不是對每個問題都砸人力的公司。
開源是一把雙面刃
AI 基建領域與開源有一種不尋常的關係，一方面，像 LangChain、LlamaIndex 和各種可觀測性框架這樣的開源專案已經佔據了開發者的 mindset，並塑造了開發者思考問題空間的方式。另一方面，變化的速度之快，意味著昨天的開源寵兒可能是明天的技術債。
對商業供應商來說，這形成了一個策略難題。是透過提供開源無法匹敵的專有能力來與開源競爭？還是建立在開源之上，透過整合、支援和企業功能來差異化？還是開源自己的技術來建立標準？
不同公司採取了不同的做法。我觀察到的是，成功的商業供應商不是直接與開源競爭，而是補充它。他們解決的是開源處理得不好的問題：規模化下的可靠性、企業安全要求、合規需求，以及自己運行基礎設施的運營負擔。
新創的風險在於建立一個開源可以複製的業務，如果你的差異化純粹來自功能，開源專案終將追上。持久的差異化來自商業投資具有結構性優勢的領域：大規模的廣泛測試、安全認證、支援與 SLA，以及讓各元件無縫協作的整合工程。
給創辦人的框架
最後我想分享一些建議給在正這個領域建構產品的創辦人，這些建議來自我們自己的經驗，以及觀察是什麼把成功的公司和處於掙扎中的公司區分開來。
原則一：從工作流程出發，而非技術
人們很容易先建構技術，再去找使用案例，但這很少奏效。成功的公司從特定的工作流程出發，也就是客戶迫切想要自動化的痛點流程，然後建構技術來實現它。
這意味著你必須非常具體地了解你的客戶是誰、他們試圖完成什麼工作。「需要可觀測性的 ML 工程師」太籠統了。「在成長階段新創公司部署第一個 LLM 驅動產品、需要了解它是否正常運作的 ML 工程師」才更具可操作性。
具體性能催生有主見的設計。當你確切知道自己在解決什麼問題時，就能做出通用方案做不到的取捨。你的產品可以對工作流程應該怎麼運作有自己的觀點，而不是試圖成為對所有人都萬能的工具。
原則二：為生產環境的邊緣案例而建構
Demo 之所以能跑，是因為它們避開了邊緣案例。Production 環境之所以會 GG，是因為邊緣案例。這兩種狀態之間的落差，正是公司成敗的關鍵。
這意味著要大量投資於理解真實部署中會發生的怪事：意外溢出的上下文視窗、API 更新後開始回傳格式錯誤 JSON 的模型、刻意製作會破壞你解析邏輯的輸入的使用者、因為兩個工具給出矛盾資訊而陷入迴圈的代理。
我們（戴伊爾斯）維護著一份邊緣案例清冊，記錄我們遇到過的每一個奇怪故障、我們如何偵測到它、以及我們如何處理它。這份清冊為產品開發提供指引。每個新功能在發布前，都會針對已知的邊緣案例進行壓力測試。
原則三：測量重要的，而非容易的
測量延遲和錯誤率很容易，這些指標是必要的，但不充分。你真正需要知道的是：你的系統是否為使用者產生好的結果。
這需要定義針對你的使用案例的品質指標，並為你的系統建立擷取這些指標的儀表化機制。對某些應用程式，品質或許可以透過自動訊號來測量；對其他應用程式，你需要人工評估；對許多應用程式，你兩者都需要。
最重要的測量往往是趨勢，而非絕對值。品質是否隨時間改善？你是否越來越擅長偵測和糾正問題？系統是否變得更可靠？這些方向性指標比達成任意目標更重要。
原則四：為適應性而建構
AI 領域的變化速度比我接觸過的任何技術領域都快。你今天為之建構的模型，一個季度後可能就過時了。今年的最佳實務，明年（下個季度）可能就是錯的。
這意味著要為適應性設計，而非為當前狀態最佳化。把模型特定的細節抽象化，建構能容納新能力的介面，抵制在約束可能改變時為今天的約束過度最佳化的誘惑。
我以艱難的方式學到了這個教訓。早期看似合理的架構決策，隨著領域演進變得處處受限。現在我們明確地為適應性而建構，接受一些短期效率損失以換取長期靈活性。
原則五：投資於信任
AI 系統是在信任赤字中運作的，使用者已經被過度承諾、交付不足的 AI 能力傷害過。企業對安全、可靠性和成本控制抱持謹慎。監管機構正以越來越嚴格的目光注視這個領域。
建立信任需要持續超越期望，這意味著對限制保持透明，意味著提供讓客戶能夠理解和治理 AI 行為的可見性與控制機制，意味著優先考慮可靠性而非功能。
及早贏得信任的公司，在市場成熟時將擁有顯著優勢。那些過度承諾、交付不足的公司，會發現那種名聲很難擺脫。
前方的路
我們正處於軟體建構和運營方式發生重大轉型的早期階段，大型語言模型和自主 Agent正以加速的步伐從實驗走向生產系統。讓這一切成為可能的基礎設施層，仍在被發明中。
對於我們這些在這個領域建構的人來說，機會是龐大的，責任也是。我們創造的系統將塑造 AI 如何在真實世界中被部署。我們在可觀測性、可靠性、安全和治理方面做出的決策，將影響 AI 系統是運作良好還是災難性地失敗。
我沒有所有的答案，也不認為在這個階段已經有人能給出答案。但我確信的是：這些問題很重要，這些問題是可以解決的，而那些以嚴謹和謙遜的態度面對它們的公司，將會是最終成功的那些。
如果你正在處理這些問題，無論是作為創辦人、工程師還是研究人員，我很想聽聽你正在學到什麼。這個社群的集體智慧，是我們把這件事做對的最好希望。
本文反映的是在 AI 基礎設施領域建構的個人觀察。所表達的觀點為作者個人意見，不構成投資建議或對特定公司的預測。
