把一個 AI Agent 從展示推向生產，中間的差距遠比多數人想像的大。展示用的 agent 一個下午就能跑起來，但生產環境要求的條件完全不同：它必須持續可用、保持安全、控制成本，並且在出錯時讓工程師找得到原因。問題是，這些能力幾乎沒有一項來自模型本身。真正決定成敗的，是圍繞模型建置的一切：跨 session 的記憶、工具存取、模型路由、護欄、成本上限，以及事後追查用的 trace。這一整層基礎設施，就是所謂的 Agent Harness（代理器框架）。
「Agent harness」這個詞是今年才開始流行的概念，但背後的工作一點都不新。過去在建置 agent 的人其實早就在做同樣的事：把工具黏在一起、手動調整提示詞、加上重試與日誌，然後在每次故障吵醒人之後隔天早上補破洞。新的地方在於，這個詞讓團隊能把所有這些能力當成一個刻意設計的整體，而不是抽屜裡一堆一次性修補。InfoQ 這篇由 Trista Pan 撰寫的文章，引用 Vivek Trivedy 在《The Anatomy of an Agent Harness》中的框架：Agent 等於模型加上 harness。換句話說，如果你不是模型，你就是 harness。
核心概念：Agent 等於模型加 Harness
用汽車來比喻最容易理解。模型是引擎，動力來自這裡，但沒有人會把一顆裸引擎綁在棧板上出貨給客戶。底盤、煞車、儀表板、安全帶，才是讓這台車可以載著家人上路的原因。模型只負責最困難的認知工作，而讓產品安全、可靠、好用的部分，全部是 harness 的責任。
harness 內部可以切成兩半。Development（開發面）負責擴展模型的能力範圍：跨 session 的記憶、工具與 MCP（Model Context Protocol，模型內容協定，讓模型能呼叫外部工具的標準介面）、檢索、提示詞管理與編排。Operations（營運面）負責讓系統在使用者上線後持續穩定運作：可觀測性、評估、護欄、路由、漂移與成本監控、部署與擴展。值得注意的是，營運面本質上就是換了一頂新帽子的 DevOps。模型當然重要，更強的模型會拉抬上面所有東西，但 AI agent 不是模型，它是產品，而產品工程的大部分功夫都落在 harness 上。
兩種建置路線：HaaS 與自管
文章提出兩條路線，並強調兩者底層其實是同一種東西：都是你用來建置與維運 agent 的鷹架，包含模型存取、檢索、工具與 MCP、路由、護欄等相同積木。差別在於這些積木怎麼打包、你怎麼跟它們互動。
第一條是 Harness-as-a-Service（HaaS，框架即服務），由廠商營運的 runtime 把整個 harness 的開發與營運面都包成受管理的 API，你只需要填設定。例子包括 AWS 的 AgentCore、Google Vertex AI Agent Engine、Azure AI Foundry Agent Service，以及 LangGraph Platform。第二條是自管（self-managed），用 SDK 加上開源元件自己組裝，例如 LangChain 搭配 Agent Router（前身是 Envoy AI Gateway，一個建在 Envoy Proxy 上的開源 GenAI 閘道）或 LiteLLM，跑在 Kubernetes 上。兩邊的差別不是零件不同，而是誰來組裝、故障時誰會被 call 起來。
選擇坐在光譜哪個位置，取決於幾個考量：團隊有沒有能力維運 Kubernetes、閘道與 on-call 輪值；是否已經深度綁定某個雲端；成本偏好固定廠商帳單還是基礎設施加工程時間；治理要求（護欄、稽核軌跡、資料路徑是否必須留在自家 VPC）；可攜性需求；預期規模；以及你對凌晨三點被 page 的容忍度。HaaS 預算簡單，自管在規模大了之後可能更便宜，但前提是你本來就要付維運成本。
FinBot 實例：同一個 agent，兩種建法
文章用 FinBot 這個小型財務 agent 示範。使用者問「總結第三季營收」，FinBot 從文件庫抓出該季財報、把數字交給程式直譯器計算、叫模型寫摘要、然後回覆。兩個版本用同一份規格，但各自用該技術棧習慣的方式實作。開發面需要四樣東西：系統提示詞、工具（一個連到財報的 MCP server，一個跑程式碼執行的 MCP 容器）、財報檢索、跨 session 記憶。在 AgentCore 上，這些是 CreateHarness 呼叫裡的設定欄位；在自管版本，它們是各自有生命週期、需要部署與版本管理的程序。
文章挑了三個它認為最決定生產就緒度的能力來說明。首先是統一模型存取。每家 provider 都有自己的 SDK、認證與回應格式，自架模型又更多。你只需要一個前門，讓新增模型、金絲雀測試新模型或故障切換變成設定變更而不是改程式。AgentCore 把模型欄位設計成四種設定的聯集，可以在 harness 上設定、每次呼叫時覆寫，甚至 session 中途切換 provider 而不丟失上下文，第三方金鑰放在 Identity 的 token vault。自管版本則由 Agent Router 提供一個 OpenAI 相容端點，模型別名對應到後端，金鑰留在閘道，透過 EKS Pod Identity 或 IRSA 綁定 IAM 角色，叢集內沒有靜態金鑰。
第二個能力是成本控制。AgentCore 直接攻擊 runaway loop 問題，提供每次呼叫的 maxIterations（預設 75）、maxTokens 與 timeoutSeconds 硬上限，加上 CloudWatch 的 token 指標與成本分配標籤。閘道版本則把 token 當成請求成本來計量，在模型上設定每個使用者每日 token 預算，用完之後以 HTTP 429 拒絕後續請求。兩者的差異很關鍵：AgentCore 在上限內停止迴圈，閘道在租戶預算耗盡時拒絕下一個請求，只有後者知道「租戶」是什麼概念。
第三個能力是可觀測性。AgentCore 每次呼叫自動把 trace、日誌與指標送到 CloudWatch，涵蓋模型呼叫、工具呼叫與記憶操作，只需要一次帳戶層級的資源政策設定。自管版本則靠 OpenTelemetry 的 GenAI 語意慣例（semantic conventions）輸出標準指標，例如 gen_ai.client.token.usage 與 gen_ai.server.time_to_first_token，由 Prometheus 抓取；trace 則由兩個 producer（LangChain 應用與閘道的 ext_proc）送進同一個 OTLP collector，再進後端。Langfuse、Phoenix、OpenLIT 這些工具都同時提供 LangChain SDK 與後端，可以混搭。文章提醒一個常見陷阱：訊息內容預設不會被記錄，要在兩端都設定 OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=SPAN_ONLY 才會把提示詞本身放進 trace，而且要想清楚誰有權限讀取。
影響與限制
這篇文章的核心主張是：建置生產級 agent 與其說是魔法，不如說是架構。你要先決定產品必須做什麼、「好」的定義是什麼、硬界線在哪裡，然後把模型與 harness 當成工具來達成目標。harness 要跟著 agent 一起成長，但不要過度鍍金；價值來自工作被完成，而不是來自一個在需要之前就蓋好的豪華框架。
不過文章也誠實承認示範的界線。真正的 harness 有很多活動零件，FinBot 只示範了其中一部分，guardrails（護欄）、評估、提示詞編排、部署與擴展、多 agent 工作流都沒有涵蓋，這是實際的缺口而不是整齊的邊界。把 demo 推到生產，終究得面對這些。另外，選擇 HaaS 或自管不是非此即彼，很多團隊落在中間，這完全正常；關鍵是認清自己在團隊能力、成本結構、治理邊界與可攜性之間的取捨，而不是追求某個「正確答案」。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。