大型語言模型（LLM）具備生成與推理能力，但單靠一段提示詞無法保證穩定完成長流程任務。InfoQ 在 2026 年 10 月刊登、由 Karthik Ramgopal 撰寫的技術文章，回顧了 LinkedIn 建構代理式系統的經驗，並把近年出現的 agentic harness 歸納為三種架構範式：鏈（Chains）、圖（Graphs）與程式碼（Code）。所謂 agentic harness，是指包在機率性模型外面的結構化執行框架，負責工具呼叫、狀態管理、驗證、重試與觀測，讓模型輸出不只「看起來可用」，而是能進入生產環境。文章的核心判斷是，這三種範式並非彼此取代，而是對應不同任務複雜度、可靠性、延遲與成本需求；真正的工程能力在於選對最簡單且足夠可靠的抽象。
鏈式流程：最快抵達，也最容易斷裂
早期做法是把多個提示詞串成線性流程：第一步的輸出餵給第二步，依此類推。LinkedIn 早期的一個生成式 AI 代理便以 LangChain 建立固定三步鏈。第一步是路由，判斷查詢是否在範圍內，並決定由哪個專門的 AI「專家」處理；第二步是檢索，呼叫 Bing 網路搜尋或 LinkedIn 內部 API 等工具，收集資料形成背景材料，支援檢索增強生成（RAG，讓模型根據外部資料回答，而非只憑參數記憶）；第三步是生成，過濾並綜合檢索結果，產出連貫答案。這種鏈的優點是直觀、開發快、上線快，模型呼叫與狀態管理也最少，因此延遲和運算成本通常最低。
問題在於，鏈式流程把每個步驟的成敗幾乎完全綁在前一步的文字輸出上。只要上游有一次分類錯誤、檢索偏差或格式失真，錯誤就會沿著流程放大，而系統沒有內建機制能系統性偵測與回復。這種「盡力而為」的模式，讓前 80% 的體驗很快就能做出來，但最後一段品質落差往往需要大量評估、提示調整與工程投入才能補上。對摘要、草稿撰寫、內容審核或從固定格式擷取資料等窄而線性的任務，鏈仍然很有效率；但對需要多步判斷與例外處理的流程，它的脆弱性會迅速暴露。
圖形編排：把控制流顯式化
當任務變長、分支變多，開發者開始用圖來描述代理流程。圖形框架以節點代表不同任務，例如 LLM 呼叫、工具調用或驗證；以邊代表控制流。關鍵不只是「加上分支」，而是把條件判斷、平行處理、重試、回退與狀態轉移變成可檢查、可修改、可推理的宣告式結構，而不是把邏輯藏在提示詞或散落的程式碼裡。這樣的控制流讓模型能在動態環境中路由並執行長時間任務，也促成多代理系統的出現：由頂層協調者管理任務拆解、依賴關係與代理間通訊。
多代理架構需要代理間通訊協定。文章中提到的 A2A 與 ACP，是讓不同代理非同步交換任務與結果的協定，ACP 後來併入 A2A。由於代理的認知能力有限，圖形系統也強調 human in the loop（HITL，人類介入循環），也就是在關鍵決策點讓人類補充資訊、審核或批准，而不是放任代理全自動執行。LinkedIn 的做法是重用既有的訊息系統來處理長生命週期任務，把任務拆成訊息序列，確保先進先出（FIFO）交付與可查詢的訊息歷史，並借此取得多執行緒平行、持久重試與最終交付，以及同步串流或非同步串流等彈性回應方式。實作上以 LangGraph 這類圖形編排框架疊出條件執行、重試與回退、跨步驟狀態管理，以及結構定義、業務規則或第二模型等明確驗證，避免盲目信任 LLM 輸出。
這些能力支撐了 LinkedIn 的 Hiring Assistant。招募人員可把找尋候選人、協助審查申請者等耗時工作委派給代理，把心力留給策略性與人際互動的部分。系統也把認知記憶（Cognitive Memory）做成另一個代理，讓應用代理能與之整合，從互動中學習並逐步個人化。不過，圖形架構仍有本質限制：它終究是圍繞人類預先定義流程的「有界自動化」。當狀態空間與例外路徑愈來愈多，開發者必須不斷補上回復路徑、驗證邏輯與邊界案例，流程定義和評估框架容易變得龐雜、僵硬且難維護；對無法清楚寫成確定性工作流的任務，圖也不見得合適。
程式碼執行：用可驗證性換取可靠性
最新的轉向，是把程式碼而非自然語言提示當成推理的主要媒介。代理不再只是在文字中「想一想」，而是在沙箱環境中產生程式碼、執行、觀察結果、修正，再重新執行。自然語言輸出本質上是機率性的，除非經過驗證，否則不可信；程式碼則有明確的通過或失敗：能編譯、能執行、產出符合條件的結果，或不能。這種清楚的二元回饋形成緊密循環，讓系統可靠性大幅提高。
要安全地使用這條路徑，文章中歸納出四個核心元件。執行沙箱提供隔離且受控的環境，讓產生的程式碼安全運行；儀器化與日誌記錄捕捉執行過程中的所有輸出、錯誤與中間狀態，供事後檢查；驗證框架以單元測試、斷言或檢查條件，自動比對輸出是否符合正確性標準；迭代修正循環則讓代理根據失敗結果修改程式碼並重試，直到滿足條件。LinkedIn 以此建置內部分析工具，讓開發者、產品經理、資料科學家甚至業務營運人員用自然語言提出分析問題，並取得根據平台彙總資料的答案。代理在既有隱私、存取控制與安全框架內運作，執行角色與目的導向的資料存取，對輸出加上自動治理審查，並讓模型互動透過合規基礎設施進行。它把問題轉成宣告式 SQL 與命令式 Python 的組合，先對樣本資料執行，再依隱私、可見性與治理等嚴格限制驗證，必要時循環修正。
這種做法的效益不只是準確率。由於不必為每個情境手工打造提示、工具與工作流程圖，再反覆跑評估微調，上線速度反而更快；最終系統也更可審計、可重現。代價是它通常需要最高的運算與延遲成本，因為包含反覆推理、外部工具執行與驗證週期。因此，程式碼執行框架適合正確性、可驗證性與可回復性遠比速度或成本重要的領域，例如軟體工程代理、財務分析、法律文件驗證、科學工作流與基礎設施自動化。
可靠性原則與抽象選擇
不論採用哪一種範式，文章提出幾個共通原則。首先，把 LLM 輸出視為不可信輸入，任何輸出在影響下游邏輯前都應經過結構定義、業務與合規規則或第二模型驗證。其次，把規劃與執行解耦，讓模型提出計畫，但由受控的軟體框架執行，以提升透明度與控制力。再者，投資可觀測性，保存每一步狀態、執行軌跡與驗證結果，同時遮罩敏感資訊，否則難以除錯高度非確定性的系統。最後，建立持續改善的回饋循環，分析失敗、更新提示與政策記憶，並透過評估與模擬環境系統性提升表現。
抽象選擇則是工程取捨，而不是架構競賽。窄而線性的任務，例如客服回覆草稿、文件摘要、內容審核或固定格式擷取，鏈通常已足夠，且延遲與成本最低。需要條件分支、重試、工具呼叫或明確狀態轉移的多步流程，例如客服案件解決、企業 IT 自動化、合規流程或入職系統，適合圖形架構；它比鏈可靠，但協調層與多次模型呼叫會增加延遲、成本與維運複雜度。只有當產出必須被測試、編譯、模擬或形式驗證時，程式碼框架的價值才足以支撐其成本。常見失誤是模型能力提升、成本下降後就過度工程化；更複雜的抽象往往先推高花費與延遲，卻未必等比例改善業務結果。
這場演進也改變了開發者的角色：從調整提示詞的「提示設計者」，轉向設計執行流、管理狀態與依賴、建立驗證與回復機制的「系統架構師」。早期系統把不可預測性視為必然，只能盡力而為；現代代理式執行框架則要求在可能之處追求確定性，只在必要之處使用受控的非確定性，並為失敗定義清楚模式與回復路徑。限制仍然存在：沙箱安全、驗證條件的完備性、治理與成本，都不是自動解決的問題；但方向已很清楚，代理系統不再是神奇黑箱，而是需要和其他關鍵基礎設施同等嚴謹對待的軟體系統。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。