要讓 AI Agent 真正勝任複雜的長程任務，我們必須放棄單純擴大上下文視窗的迷思，轉而擁抱更精妙的記憶治理策略。核心在於將 Agent 的記憶從無限追加的「對話流」轉變為可變、顯式且可被檢查的「執行狀態」。這不僅能解決上下文污染、性能衰減與成本失控等問題，更能大幅提升系統的可觀測性與可預測性。透過狀態承諾、污染控制與可觀測性這三大支柱，我們才能為 AI Agent 建立一個可信任、可擴展的記憶基礎，使其從被動的紀錄複誦者，進化為主動的記憶管理者。
目前許多 Agent 框架的基本運作邏輯，是將每一步的觀察、思考與行動，都當作新的對話內容，不斷附加到歷史紀錄中。隨後，這整串越來越長的文本會被塞給大型語言模型（LLM）進行下一步決策。這種「append-only」的模式在短任務中尚可運作，一旦任務時間拉長、步驟變多，就會立刻面臨三大挑戰：
這種模式就像要求一位專案經理在不准做筆記、只能從頭到尾反覆重聽所有會議錄音的情況下，管理一個為期三個月的專案。這顯然是違反直覺且效率低下的。
為了解決上述困境，一個更成熟的範式是將 Agent 的記憶從「歷史紀錄」轉向「狀態管理」。這篇名為 SKILL.state 的研究雖然是個概念，但它精準地指出了這個方向：我們應該維護一個顯式的、可變的執行狀態，而不是一個只能追加的歷史紀錄。這就像專案經理的筆記本或儀表板，它只記錄當前最重要的資訊，並會隨著專案進展而更新。
「歷史」與「狀態」的區別，是理解這個轉變的核心：
將 Agent 記憶視為一個有限狀態機（Finite-State Machine），意味著 Agent 在每一步執行的，不僅是任務本身，還包括對自身記憶的維護。它需要判斷哪些舊資訊可以被捨棄、哪些新資訊需要被整合進當前的狀態表徵中。這讓 Agent 從一個被動的紀錄複誦者，變成一個主動的記憶管理者。
要建立一個基於狀態的記憶系統，我認為需要三大支柱，也就是「Memory Governance」的核心實踐：
1. 狀態承諾（State Commitment）
這指的是 Agent 在完成一個子任務或達到某個里程碑後，有意識地將其推理過程和觀察結果，提煉、壓縮並「提交」到其結構化狀態中的行為。這個過程類似於軟體開發中的 git commit。開發者不會把每一次的按鍵、每一次的測試失敗都記錄在版本歷史中，而是將一個完整的功能變更，連同清晰的提交訊息，合併到主幹。
同樣地，Agent 應該捨棄中間的思考鏈（Chain-of-Thought）細節，只保留結論和關鍵發現，更新到如 "current_goal"、"files_modified"、"last_error_code" 等狀態變數中。這種主動的記憶管理，確保了狀態的精煉與相關性。
2. 污染控制（Contamination Control）
透過定期的狀態承諾，Agent 能主動進行記憶的「垃圾回收」。這是一種積極的污染控制策略，旨在確保 Agent 的上下文始終保持乾淨、相關且聚焦，從根本上避免被過時資訊干擾的風險。
例如，一個負責分析數據的 Agent，在完成一份報表的初步分析後，可以將「數據源路徑」和「初步洞察摘要」存入狀態，並將載入數據過程中的所有中間步驟、嘗試與錯誤的細節完全拋棄。這確保了在進入下一個分析階段時，其決策依據是精煉且無雜訊的。
3. 可觀測性與可檢查性（Observability & Inspectability）
當 Agent 的記憶是一個定義清晰的結構化物件（例如一個 JSON 或 Python dataclass），而不是一長串非結構化的對話時，系統的可觀測性將大幅提升。這讓 Agent 的內部運作不再是難以捉摸的黑盒子。
我們可以輕易地監控狀態的變化、設定警報（例如，當 "retry_count" 超過 5 時），甚至在必要時由外部操作者介入，手動修正 Agent 的狀態，引導它回到正確的軌道上。這種透明度對於建立可信任的自主系統至關重要。
一個無法被有效觀察和理解的自主系統，本質上是不可信任的。將記憶狀態化，是打開 Agent「黑盒子」、實現有效治理的第一步。
像 Voyager 這樣的早期自主遊戲 Agent，雖然已經具備了某種形式的長期記憶（技能庫），但其運作依舊高度依賴對話歷史。從這個角度看，轉向顯式狀態管理，是從學術探索邁向工業級可靠應用的必經之路。這不僅是技術上的優化，更是關乎 AI 安全與對齊的嚴肅議題。我們需要的不只是能完成任務的 Agent，而是行為可預測、過程可追溯、失敗可診斷的 Agent。而這一切，都始於對其最核心的「記憶」進行徹底的結構性改革。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>當我們談論 AI Agent 時，往往聚焦於底層模型的強大程度，卻忽略了一個更根本的問題：Agent 透過與環境互動所獲得的寶貴經驗，最終去了哪裡？多數情況下，這些經驗被鎖死在特定模型的權重或上下文歷史中，一旦模型更迭，知識便隨之流失。真正的突破不在於訓練更強大的單一模型，而在於建立一套機制，將 Agent 經驗轉化為獨立於模型、可遷移、可審核、可持續演化的「技能資產」。這不僅是技術效率問題，更是組織能否建立長期、可治理 AI 能力的關鍵所在。
目前主流的 Agent 學習方式，無論是透過長上下文的 In-context Learning，或是針對特定任務的微調，都存在一個共同的弱點：經驗與模型本身高度耦合。這帶來了幾個顯著的挑戰。
首先是「知識的脆弱性」。當 OpenAI 釋出 GPT-5，或我們決定從 Claude 3 Opus 切換到 Llama 4 時，那些透過無數次 API 調用和使用者互動積累下來的「默契」和「技巧」很可能需要從頭來過。經驗無法被有效繼承，每一次技術升級都可能伴隨著一次隱性的知識重置。
其次是「成本與治理的失控」。將所有經驗都塞進模型的上下文中，意味著更高的 token 成本和更長的處理延遲。更重要的是，這些儲存在模型內部的隱性知識是個黑盒子，我們難以審核 Agent 究竟「學會」了什麼，也無法針對性地修正或優化某個特定技能。
當 Agent 犯錯時，我們除了調整提示（prompt）或祈禱下個版本會更好之外，缺乏精準的介入手段。這種模式讓 AI 系統的長期維護與治理變得極其困難。
最近一篇由普林斯頓大學、Google DeepMind 與北京大學研究者發表的論文《WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution》提出了一個極具啟發性的框架，正面回應了這個挑戰。他們主張，我們應該將 Agent 的經驗明確地分為三個層次，並將其編譯成一個持久化的知識庫（他們稱之為「Wiki」），而非僅僅依賴模型的即時推理。
這個三層結構清晰地劃分了知識的抽象程度：
solve_recaptcha_with_audio()。這些技能是模組化的、可複用的，並且可以被任何具備工具使用能力的 Agent 調用。這個分層結構的精妙之處在於，它將隱性的、與模型綁定的「經驗」，轉化成了顯性的、獨立於模型的「資產」。組織可以建立、審核、版本控制並持續擴充這個技能庫，就像維護一個內部軟體庫一樣。
WikiSkill 框架最令人振奮的成果，在於它證明了技能庫的「可遷移性」。研究團隊進行了一項實驗：他們先讓一個強大的「老師」模型（如 GPT-4o）在複雜的網路瀏覽任務（WebArena 基準測試）中探索並積累經驗，再將這些經驗編譯成 WikiSkill 技能庫。
接著，他們讓一個規模小得多的「學生」模型（如 Meta Llama-3-8B）搭載這個技能庫去執行同樣的任務。結果令人驚訝。搭載了從 GPT-4o 經驗中學習到的技能庫後，Llama-3-8B 的任務成功率達到了 57.0%。
相比之下，單獨執行任務的老師模型 GPT-4o，其成功率僅為 52.2%。這意味著，一個 80 億參數的開源模型，在「前人經驗」的加持下，不僅能彌補自身推理能力的不足，甚至在特定領域超越了比它先進許多的閉源模型。
這項成果的戰略意義遠大於技術本身。它揭示了一種可能性：組織可以利用最強大的前沿模型進行成本高昂的「探索與創新」，然後將提煉出的核心技能，部署在成本更低、速度更快、甚至可以本地部署的小模型上進行「規模化執行」。
這種「教與學」的分離模式，徹底改變了我們對模型選擇的思考。我們不再需要為所有任務都選擇最大、最昂貴的模型。相反，我們可以建立一個由不同規模、不同專長的模型構成的生態系，而串連起這一切的，正是那個獨立於任何單一模型、由組織所擁有的共享技能庫。
將技能視為一種跨模型、跨時間的持久資產，而非特定模型的短暫記憶，這才是在 AI 時代建立可持續競爭優勢的正確路徑。我們累積的不再是無數次的 API 調用紀錄，而是一個可審計、可演化、可傳承的智慧資本。這讓我們能夠打造出更可靠、更具成本效益，也更易於治理的 AI Agent 系統。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>當前多數 AI Agent 的設計，本質上仍是特定大型語言模型的短暫實例，一旦執行環境（runtime）終止或模型更迭，其身份、記憶與累積的經驗便隨之消逝。我認為這條路走不遠。要打造能夠與我們長期協作、值得信賴的 AI 系統，關鍵在於建立一個獨立於模型的持久化身份層。透過將 Agent 的核心身份、記憶與程式資產，從其暫時的「軀殼」（如特定 LLM 或伺服器）中解耦，我們才能實現真正可遷移、可接手、可治理的數位心智，讓它們的價值能夠跨越時間與技術的限制而累積。
目前主流的 Agent 框架，例如 LangChain 或 AutoGen，雖然大幅簡化了開發流程，但其 Agent 實例的生命週期往往與一次性的任務或對話 session 緊密綁定。當一個任務結束，或使用者關閉對話視窗，這個 Agent 的「心智狀態」幾乎就歸零了。即使有外部記憶體（如向量資料庫）的輔助，其核心的身份認同（identity）與執行邏輯，依然與底層的 LLM 及運行它的伺服器環境（harness）高度耦合。關於記憶體增強型 LLM 的研究，可參考 Mialon 等人於 2023 年的綜述。
這種設計的侷限性非常明顯：
這些問題讓我們不得不思考：Agent 的本質，究竟應該是一個拋棄式的模型實例，還是一個擁有獨立身份的持久化實體？
Google 研究員 Timo Schuster 等人在 2024 年 4 月發表的論文 《Runtime-Independent Persistent Agents》中，提出了一個極具啟發性的架構，直指問題核心。他們主張將 Agent 的構成拆解為兩個獨立但可互動的組件：持久化底層（Substrate）與部署綁定（Binding）。
這個概念的核心是分離「Agent 是什麼」與「Agent 當下如何運作」。前者是永恆的，後者是暫時的。
這個架構將 Agent 的核心拆解為以下兩大關鍵組件：
透過一個標準化的協議，Substrate 可以在不同的 Binding 之間無縫遷移。論文中，研究團隊成功展示了同一個 Agent 身份在三種完全不同的執行環境中遷移，而其核心狀態與記憶都得以完整保留。這就像將你的意識從一台電腦上傳到另一台，甚至換了一個作業系統，但你依然是你，記得所有過去的事情。
將 Agent 的身份與執行環境解耦，其意義遠不止於技術上的優雅，它為我們打開了實現長期、可信賴人機協作的大門。我認為這將帶來三個層面的根本性轉變：
一個解耦的 Agent 可以在技術浪潮中倖存。當 GPT-5 或 Llama 4 問世時，我們可以輕易地將 Agent 的 Substrate 遷移到新的、更強大的 Binding 上，而無需拋棄它長達數年的記憶與經驗。這使得 Agent 從一個消耗品，轉變為一個可以與個人或組織共同成長、持續演進的資產。
一旦 Agent 的核心價值（身份與記憶）可以被打包、遷移，它就具備了數位資產的屬性。這意味著 Agent 的所有權可以被明確定義、轉讓甚至交易。在企業內部，一個負責管理供應鏈的 Agent，可以在相關負責人職位調動時，像一份資產一樣被完整交接給下一個人，確保業務知識與流程的延續性。這也為AI 的治理提供了清晰的對象與邊界。
這種架構打破了模型供應商的鎖定效應。使用者可以自由地為他們的 Agent 選擇最合適的「大腦」（LLM），無論是基於成本、性能還是隱私考量。這將催生一個更加開放的 Agent 生態系，開發者可以專注於打造獨特的 Agent Substrate（例如，一個精通財務分析的 Agent 核心），而使用者則可以為它搭配各種不同的 Binding，實現最佳組合。
從 ephemeral instances 到 persistent entities 的轉變，是 AI Agent 發展的必然趨勢。這不僅是關於如何保存記憶，更是關於如何定義一個數位實體的身份、權利與責任。唯有建立起獨立的身份層，我們才能開始嚴肅地討論如何與這些日益強大的 AI 系統建立起長期的信任與協作關係。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>在建構長期運作的 AI Agent 時，我們常陷入追求單一、完美記憶結構的迷思。然而，無論是結構化的知識圖譜或線性的對話紀錄，任何單一記憶形式都存在固有盲點。最新研究指出，過度結構化的記憶雖擅長整理事實，卻會犧牲原始脈絡與表面形式。真正的解方，並非尋找「最好」的單一結構，而是擁抱「認知多樣性」，建立能容納異質表徵的記憶架構，並將選擇性遺忘視為一種主動策略。這不僅平衡了成本、效率與資訊保真度，更關乎 AI 能否在複雜的長期互動中，真正做到可信與可靠。
知識圖譜（Knowledge Graph）長久以來被視為組織 AI 記憶的理想工具，其發展歷程可追溯至語意網（Semantic Web）的早期探索，並在近年來成為主流（A Brief History of Knowledge Graph's Mainstreaming）。它能將非結構化的資訊轉化為實體與關係的節點，形成一張清晰的語意網路，非常適合邏輯推理與複雜查詢。然而，這個「結構化」的過程本身就是一種有損壓縮。當我們將一段對話「今天下午三點，Maki 在會議上對專案進度表示擔憂」轉換成 (Maki) --[表示擔憂]--> (專案進度) 這樣的圖節點時，我們保留了核心事實，卻丟失了許多隱性資訊：Maki 的語氣是急切還是無奈？「擔憂」的具體用詞是什麼？這個發言是在什麼樣的對話流中出現的？
一篇名為 Selective Forgetting: A Graph-Based Memory Framework for Long-Term LLM Agents 的研究便透過實驗證實了這一點。他們發現，純粹依賴圖記憶的 Agent，在被要求回憶特定對話回合的細節時，表現甚至不如僅使用簡單向量檢索的扁平記憶系統（如 ChromaDB）。圖譜擅長回答「Maki 擔心什麼？」，卻很難回答「Maki 當時是怎麼說的？」。這種對「表面形式」（surface form）資訊的喪失，正是單一記憶結構的根本限制。它提醒我們，高效的資訊組織與完整的脈絡保存之間，存在著無法迴避的權衡。
既然沒有任何一種記憶結構能涵蓋所有需求，那麼答案就是放棄尋找「萬靈丹」，轉而建構一個擁抱異質性的混合系統。這正是我所說的「認知多樣性」在 AI 記憶架構中的體現。上述研究提出的 SF-GraphMem 框架，便是一個很好的例子。它並非試圖用圖譜取代一切，而是將兩種不同性質的記憶模組結合起來：
這種雙軌制架構，讓 Agent 能同時擁有兩種認知能力：既能像歷史學家一樣，從結構化的知識中進行宏觀的推理與總結；也能像速記員一樣，精確回溯不久前的對話細節。這兩種表徵並非相互競爭，而是互補。當需要理解長期關聯時，調用圖記憶；當需要查證具體說法時，則求助於緩衝記憶。這就像人類大腦同時擁有語意記憶（semantic memory）和情節記憶（episodic memory），不同類型的記憶服務於不同的認知功能，並與「生成式代理」（Generative Agents）研究中隱含的設計哲學，以及人類記憶的複雜性有異曲同工之妙（Memory (Stanford Encyclopedia of Philosophy)）。
在 AI 系統中，遺忘不是記憶的失敗，而是治理的成功。
一個能夠長期運作的系統，其記憶庫必然會無限膨脹，帶來失控的儲存與運算成本。因此，「遺忘」不僅是不可避免的，更應該是一種主動、有策略的治理行為（Memory Governance）。
前述研究提出的「選擇性遺忘」機制，便將遺忘從被動的資訊流失，轉化為主動的成本與品質管理工具。他們設計了兩種獨立的遺忘策略：
這種做法的本質，是承認「所有資訊都同等重要」是一個偽命題。透過建立明確的遺忘規則，我們賦予了 AI 系統區分主次、管理資源的能力。這不僅是為了節省成本，更是為了確保核心知識不被海量的瑣碎細節淹沒，從而提升決策品質。當我們在 AutoGen 這類框架中設計複雜 Agent 時，主動的記憶治理策略將是系統能否長期穩定運作的關鍵。
最終，打造一個強健的 AI 記憶系統，重點不在於「記住所有事」，而在於「知道該記住什麼、以何種形式記住，以及何時可以放手」。擁抱認知多樣性，並將選擇性遺忘作為核心治理策略，我們才能建構出既博學又不臃腫、既能洞察全局又能明察秋毫的 AI 協作者。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>Meta AI 最近發表的 CORAL 研究，向我們揭示了大型語言模型（LLM）在生產環境中的一個更成熟、更具實用價值的角色：作為一個受控的「代理調優器」（agent tuner）。其核心價值不在於直接取代人類專家進行複雜的參數微調，而在於建立一個能夠讀取觀測訊號、使用窄化工具集、並在人類監督下形成回饋閉環的自動化系統。這種模式讓我們能以更低的成本和風險，持續優化複雜系統，同時確保整個過程的可控性與安全性，這正是 AgentOps 思維的體現。
推薦系統是當代網路服務的核心，但也是出了名的難以維護。它們的表現受到用戶行為、內容變化、季節趨勢等多重動態因素影響，導致傳統上需要耗費大量工程資源進行持續的手動調優或昂貴的模型重新訓練。Meta 的研究人員在他們兩個生產環境的推薦模型上，導入了名為 CORAL（Control and Optimization via Reasoning and Language）的框架，試圖解決這個問題。這項研究詳細說明了其應用與成效。
CORAL 的運作方式相當直觀：它將一個 LLM Agent 放入一個與推薦系統互動的閉環中。這個 Agent 的任務不是去改動模型本身的權重，而是像一位系統操作員一樣，透過一組定義好的「工具」來調整系統的超參數（hyperparameters）。
整個流程大致如下：
這個循環不斷重複，讓系統能夠近乎即時地適應環境變化。實驗結果證明，CORAL 框架在不需要重新訓練模型的情況下，能夠顯著提升用戶參與度或降低伺服器成本。這不僅節省了大量的運算資源，更重要的是，它提供了一種輕量級、低風險的持續優化路徑。
直接讓 LLM Agent 在生產環境中調整參數，聽起來可能有些冒險，但相較於傳統的 fine-tuning 或 re-training，CORAL 所代表的 AgentOps 模式反而提供了更強的控制力與安全性。其戰略價值體現在幾個層面：
關鍵的轉變在於，我們不再將 LLM 視為一個需要不斷重新訓練的、龐大而單一的「大腦」，而是將其視為一個可被管理的、使用工具的「決策元件」。
首先是成本與速度。微調一個大型模型動輒需要數百甚至數千個 GPU 小時，而 CORAL 的 Agent 進行一次決策可能只是幾次 API 呼叫的成本。這種效率差異，讓系統優化的迭代週期從數天或數週縮短到數分鐘或數小時。
其次是可解釋性與可逆性。模型微調的過程像是一個黑盒子，我們很難確切知道模型學到了什麼，而且一旦部署就很難復原。相反地，Agent 的每一次行動（例如 set_parameter('freshness_boost', 0.6)）都是一個離散、可記錄、可解釋的操作。如果某次調整產生了負面效果，我們可以立刻撤銷該操作，將系統恢復到前一個穩定狀態。
最後是風險控制。Agent 的能力被嚴格限制在其可用的工具集內。它無法存取資料庫、無法修改程式碼，更無法任意更改模型架構。它只能在一個被嚴格定義的「沙盒」環境中，調整幾個被允許的參數。這種做法為系統建立了一道天然的安全邊界，大幅降低了自動化決策失控的風險。
將 LLM Agent 導入生產環境，成功的關鍵不在於 Agent 有多「聰明」，而在於我們為它設計的框架有多「穩固」。從 CORAL 的實踐中，我們可以歸納出建立有效安全邊界的三個核心要素：
1. 嚴格限制的工具集（Constrained Toolset）：這是最重要的安全層。Agent 的所有行為都必須透過預先定義的工具來執行。設計這些工具時，必須包含嚴格的輸入驗證與邊界檢查，例如，一個調整權重的參數，其值可能被限制在 0.1 到 2.0 之間。這種模式是「ReAct (Reason and Act)」等思想的延伸，確保了 Agent 的行動永遠在預期範圍內。
2. 全面的可觀測性（Comprehensive Observability）：我們必須能夠清楚地追蹤 Agent 的每一個決策過程。這不僅包括記錄它呼叫了哪個工具、傳入了什麼參數，更應該記錄它「看到」了什麼觀測數據，以及它做出決策的「思考鏈」（Chain of Thought）。完整的日誌與追蹤是除錯、審計以及事後分析的基礎，也是建立對系統信任感的必要條件。
3. 人在迴路中的監督（Human-in-the-Loop Oversight）：自動化不等於完全放任。在系統初期，Agent 的決策可以先以「建議模式」運行，由人類專家審核後再執行。隨著系統穩定性與信任度的提升，可以逐步過渡到「半自動」或「全自動」模式，但始終保留人類隨時介入、暫停或接管系統的權力。
同時，我們也可以透過類似 Constitutional AI 的方法，為 Agent 設定高層次的指導原則，確保其行為符合我們的價值觀與商業目標。
CORAL 的探索，為我們展示了 LLM 在生產環境中更務實且影響深遠的應用方式。它提醒我們，與其追求一個無所不能的通用人工智慧，不如專注於打造一系列目標明確、工具受限、行為可觀測的專用 AI Agent。透過這種 AgentOps 的思維，我們才能在享受 AI 帶來效率提升的同時，將風險牢牢地控制在手中，逐步建立起真正可信任、可治理的 AI 系統。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>當前 AI Agent 的發展，常讓我們對其單次程式碼生成能力抱持過高期待，彷彿複雜的軟體工程問題能一蹴可幾。然而，這可能忽略了軟體開發的本質：它是一個迭代、試錯、持續改進的過程。一篇名為 Harness-of-Harness 的最新研究，為我們展示了一條更貼近工程實務的自主開發路徑。它強調，長程任務的關鍵不在於單點突破的生成能力，而是建立一個能有效管理小增量、維持版本化狀態，並透過驗證機制持續改善的系統性框架。這標誌著我們正從「期待 AI 的靈光一閃」轉向「建構 AI 的工程紀律」。
當前的許多編碼 Agent，例如早期的 OpenDevin 或 SWE-agent，在處理單一、界線清晰的任務時表現出色。它們能在一個獨立的「Harness」（可控的執行環境）中，根據指令、分析程式碼、提出修改、並進行測試。然而，一旦任務尺度拉長到數小時甚至數天，這些 Agent 的侷限性便暴露無遺。
問題根源在於它們多半是「無狀態」的。每一次互動都是一個相對獨立的循環，缺乏對長期進度的記憶與管理。這會導致幾個常見的失敗模式：
這種模式就像一個記憶力只有七秒的程式設計師，雖然單次程式碼編寫能力很強，卻無法完成任何需要超過十分鐘的複雜專案。真實世界的軟體開發，從來就不是一蹴可幾的線性過程，而是一個充滿試錯、回滾、重構與持續整合的循環。
Harness-of-Harness (HoH) 框架的設計，正是為了解決上述困境。它的概念非常直觀，卻極其有效：既然單一 Agent（Inner Harness）無法處理長程任務，那我們就在它外面再套上一層更高階的管理器（Outer Harness），形成一個雙層迴圈結構。
這個結構的運作方式，很像一位資深工程師在指導一位初階開發者：
HoH 的核心貢獻，是將軟體工程的最佳實踐——模組化、版本控制、自動化測試——應用於 AI Agent 的工作流程管理。這使得 Agent 的可靠性不再僅僅依賴於底層模型的智慧，更來自於上層框架的結構韌性。
HoH 的實驗結果相當驚人。研究顯示，在知名的軟體工程基準測試 SWE-bench 上，透過為現有的編碼 Agent 套上 HoH 框架，其解決問題的成功率（pass rate）最高能提升 82.86%。
這個數字的意義需要被正確解讀。它並非指底層的 LLM 變得更「聰明」了 82.86%。事實上，Inner Harness 裡的 Agent 還是同一個。真正的提升來自於「系統的韌性」。過去那些會因為單點失敗而導致整個任務中斷的案例，現在有了重試與修正的機會。HoH 就像一個永不疲倦的專案經理，它允許 Agent 犯錯，並確保每一次的嘗試都是基於一個已知的、穩定的基礎之上。
當然，這個框架也有其限制。首先，Outer Harness 的任務拆解能力，完全依賴其背後所使用的 LLM。如果第一步的拆解就出現邏輯錯誤，後續的執行也很難成功。其次，驗證閘門的品質至關重要。如果一個專案缺乏足夠的自動化測試覆蓋，Outer Harness 就很難判斷 Inner Harness 的修改是否真的「成功」。
此外，HoH 依然受制於 Inner Harness 中基礎 Agent 的能力上限。它無法讓一個連簡單演算法都寫不出來的 Agent，去解決複雜的系統架構問題。這意味著，HoH 提升的是系統的可靠性與效率，而非底層 AI 的「智慧」本身。
儘管如此，Harness-of-Harness 的研究為我們指明了一個重要方向：打造可信任、可長期協作的 AI 系統，其關鍵可能不在於等待一個全知的通用人工智慧（AGI）誕生，而在於如何設計出能夠有效管理、驗證、並引導現有 AI 模組協同工作的工程框架。這是一種從神話走向工程的思維轉變，也是讓自主 Agent 從實驗室走向真實生產環境的必經之路。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>我們常談論如何用 RAG 或長上下文視窗優化模型，但這些方法本質上仍是被動的資訊灌輸。我認為，真正的突破在於讓模型能「主動宣告」它需要哪些資訊。最近提出的 Declarative Attention 機制，將注意力控制工具化，讓模型自行決定讀取哪些 KV cache 區塊。這不僅能大幅降低推理成本，更重要的是，它提供了一種可觀察、可治理的上下文管理框架，是打造可信任 AI 系統的關鍵一步。
大型語言模型（LLM）的推理成本，尤其是在處理長序列時，一直是個棘手的問題。自從 Attention Is All You Need 論文問世以來，Transformer 架構雖然強大，但其注意力機制的計算複雜度與序列長度成二次方關係，記憶體佔用也隨之劇增。為了解決這個問題，業界發展出各種長上下文技術與近似注意力演算法，但它們大多圍繞著一個核心挑戰：如何管理與日俱增的 KV cache。
KV cache 儲存了先前 token 的鍵（Key）與值（Value）向量，避免了重複計算，是提升生成效率的關鍵。然而，當上下文長度達到數十萬甚至數百萬 token 時，這個快取本身就成了巨大的記憶體負擔與 I/O 瓶頸。
現有的解決方案，如 Sliding Window 或各種 RAG（Retrieval-Augmented Generation）策略，本質上都是在模型「外部」進行的篩選與過濾。我們像一個圖書管理員，猜測模型可能需要什麼資料，然後把一整疊書（上下文）塞給它，讓它自己費力地在裡面尋找答案。這個過程不僅效率低落，而且是一個黑盒子，我們無從得知模型真正關注了哪些資訊。
近期由 Salesforce AI Research 等機構提出的 Declarative Attention 提供了一個截然不同的思路：與其由外部演算法被動篩選，不如讓模型自己「主動宣告」它需要哪些上下文。這個概念的核心是將注意力控制「工具化」。
具體來說，研究者們讓模型學會生成一個特殊的控制指令，例如 [DECLARE: "summarize_document_chunk_3"]。這個宣告會被系統攔截，並解析為一個指令：只從 KV cache 中讀取被標記為 "summarize_document_chunk_3" 的那一部分。如此一來，模型就不再需要遍歷整個龐大的 KV cache，而是可以像進行一次精準的資料庫查詢一樣，只載入它明確宣告需要的資訊。這種作法有幾個顯著的優勢：
我們可以簡單比較一下兩種模式的差異：
| 傳統上下文管理 (RAG / 長上下文) | Declarative Attention | |
|---|---|---|
| 控制方 | 外部演算法 (被動) | 模型自身 (主動) |
| 資訊流 | 灌輸 (Push) | 宣告與拉取 (Pull) |
| KV Cache 存取 | 全量或近似掃描 | 精準、稀疏的區塊讀取 |
| 可觀察性 | 低，注意力權重難以解釋 | 高，宣告指令明確可記錄 |
Declarative Attention 的價值遠不止於性能優化，它為 AI 的「可治理性」（Governance）帶來了新的可能性。當模型的資訊取用行為從隱晦的注意力權重分佈，轉變為一系列明確、可記錄的「宣告」時，我們就獲得了前所未有的觀察與控制窗口。
核心的轉變在於，我們將上下文管理從一個外部、通常不透明的過濾演算法，轉移到模型內部、一種明確且可觀察的宣告行為。
想像一個應用場景：在處理敏感的醫療或金融資料時，我們可以透過審計模型生成的宣告指令，來確保它沒有存取權限之外的資訊。我們可以分析這些宣告的模式，了解模型解決特定問題時的「思考路徑」，從而更好地偵錯、優化其行為。
這種透明度是建立可信任 AI 系統的基石。過去，我們試圖透過複雜的 可解釋性 AI（XAI）技術來窺探模型的內心世界；現在，Declarative Attention 讓模型有機會「開誠布公」地告訴我們它需要什麼。
當然，這項技術仍處於早期階段，如何讓模型學會更複雜、更高效的宣告策略，以及如何設計對應的記憶體架構，都還有待深入研究。但我認為，這個從被動接收到主動宣告的範式轉移，指明了一個重要的方向：未來的 AI Agent 不應只是被動的資訊處理器，而應該是能夠主動、高效且可控地管理自身認知資源的參與者。這不僅關乎效率，更關乎我們能否建立與 AI 長期、可信的協作關係。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>Google 近期開源的 Agent Skills 專案，其真正意義並非為 Gemini 模型增添了幾項新工具，而是揭示了一種更根本的架構轉變：將 AI 代理的「技能」（Skill）從特定模型或平台的私有設定，轉化為標準化、可移植、可版本化的「能力資產」。這項轉變，讓我們得以從「能力供應鏈」（capability supply chain）的視角重新思考企業導入 AI 代理的治理邊界。當技能可以被獨立審核、跨模型部署時，我們才真正開始擁有可長期維護與信任的自動化系統。
過去幾年，AI Agent 的能力通常與其背後的基礎模型或平台深度綁定。例如，OpenAI 的 GPTs 擁有一個封閉的生態系，其能力（Actions）難以轉移到其他模型，如 Anthropic 的 Claude 或開源的 Llama 模型上。這種模式雖然簡化了初期開發，卻也形成了強大的技術壁壘與供應商鎖定，限制了企業在技術選型上的彈性與自主性。
Google 透過 google/skills 這個開源儲存庫，並在官方部落格中闡述其願景，提出了一個截然不同的 AI 代理能力管理模式。它不僅僅是為 Google Cloud 上的自家產品（如 BigQuery、Cloud Run、GKE）提供操作能力，更重要的是，它定義了一套基於 SKILL.md 檔案的開放格式。這套格式讓「技能」本身成為一個獨立的實體，可以脫離特定的 AI 代理而存在。
最近就有開發者進行了一項極具啟發性的實驗：將 Google 為 Gemini 設計的 BigQuery 技能，成功整合到 Anthropic 的 Claude Code 代理中。這個案例有力地證明，一個標準化的技能框架，能夠讓能力在不同模型、不同供應商的 AI 代理之間自由流動。這就像是軟體開發領域的容器化革命：我們不再需要為每個環境重新配置應用程式，而是打包一個標準化的容器（如 Docker Image），使其在任何地方都能一致地運行。AI 技能，正在成為 AI 代理的「能力容器」。
標準化的核心在於其定義格式。Google 選擇了 SKILL.md 這種 Markdown 格式的檔案來描述一個技能，這不僅僅是為了人類的可讀性，更蘊含了深層的治理意涵。一個 SKILL.md 檔案通常包含以下幾個關鍵部分：
這種結構化的描述，讓每一個技能都變成了一個清晰、可審核的單元。當企業要導入一個新的技能時，安全與合規團隊不再需要去審查整個 AI 代理的黑盒子，而是可以專注於審核 SKILL.md 檔案本身。由於這些檔案可以存放在 Git 等版本控制系統中，每一次的修改都有跡可循，每一次的部署都能經過嚴格的 CI/CD 流程。這使得 AI 代理的能力，從過去難以捉摸的「模型行為」，轉變為可管理的「軟體資產」。
我們管理的不再是單一、全能的 AI 模型，而是一個由無數個小型、專用、可驗證的能力所組成的生態系。
這種將思考與行動分離的架構，也呼應了如 ReAct (Reason and Act) 等前沿的 Agent 研究框架，讓大型語言模型專注於推理（Reasoning），而將具體的執行（Action）交給這些標準化的外部工具。
當技能成為可移植的資產後，企業內部導入 AI 代理的模式也將隨之改變。過去，可能是由一個中央的 AI 團隊負責所有模型的微調與工具整合。未來，將會演變成一個更分散、更專業的「能力供應鏈」。
想像一下，在這種新的能力供應鏈中，企業內部可以劃分為不同的專業團隊：
這種模式劃定了清晰的治理邊界。平台團隊專注於基礎設施，而領域專家則專注於業務邏輯。技能的安裝與分發，可以透過像 npx skills 這樣的指令行工具來完成，整個流程就像現代軟體開發中的套件管理一樣成熟。這不僅提升了開發效率，更重要的是，它將能力的控制權交還給了最懂業務的團隊，同時確保了企業整體的安全與合規性。根據 Gartner 的 AI TRiSM（Trust, Risk and Security Management）框架，這種可追蹤、可解釋的模組化能力，是建立可信任 AI 系統的關鍵一步。
Google 的 Agent Skills 或許只是個開端，但它所代表的標準化、開放與可移植的理念，為我們展示了 AI 代理走向成熟、進入企業核心應用的必經之路。未來，企業的競爭力，或許不再只取決於擁有哪個最強大的模型，更取決於能否建立起一條高效、安全、可擴展的「能力供應鏈」。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>AI 驅動的程式碼現代化，真正的分水嶺不在於模型能否將數十年的 COBOL 重構為 Java，而在於這個過程能否被企業既有的治理框架所接納。每項由 AI 提出的建議、程式碼變更、資料存取與部署決策，都必須形成一條可審批、可追溯、可驗證、可回滾的治理證據鏈。最近 AWS Transform 的一項更新看似微小——允許用戶將轉換過程產生的中介產物（artifacts）儲存於自己的 S3 儲存桶——卻是將 AI 工具從一個難以管理的「黑箱」，轉變為可深度整合企業合規流程的關鍵一步，為高合規性需求提供了實質解方。
大型語言模型在程式碼理解與生成方面的進展，確實為解決困擾業界數十年的遺留系統（legacy system）問題帶來了曙光。這些系統通常由過時的語言寫成，文件稀缺，維護成本極高。根據統計，全球仍有超過 8000 億行 COBOL 程式碼在金融、保險等關鍵領域運行。利用 AI 自動分析、重構、甚至遷移這些系統，潛在效益巨大，也因此備受期待。
然而，對於高度監管的行業而言，單純的「程式能跑」遠遠不夠。一個無法解釋其決策過程、無法追蹤其變更來源、無法被現有安全工具掃描的 AI 系統，不僅是技術債，更是潛在的合規災難。想像一下這個場景：AI 工具修改了銀行核心交易系統的一段程式碼，幾個月後，審計人員要求提供該變更的完整紀錄——誰觸發的？AI 依據什麼資料提出建議？經過誰的審批？變更前後的程式碼差異是什麼？如果所有答案都指向一個由服務商管理的、不透明的儲存空間，這條關鍵的證據鏈就斷了。
真正的企業級 AI 現代化，追求的不是一個神奇的「一鍵轉換」按鈕，而是一個能融入現有軟體開發生命週期（SDLC）與 DevOps 流程的輔助工具。它必須尊重並強化既有的治理原則，而非繞過它們。
在此次更新之前，AWS Transform 在執行應用程式現代化任務時，會產生大量的「中介產物」，例如轉換計畫、原始碼分析報告、程式碼變更差異（diffs）等。這些產物被儲存在由 AWS 服務自身管理的 S3 儲存桶中。用戶雖然可以取用結果，但對於這些資料的生命週期、加密方式和存取控制權，幾乎沒有主導權。
現在，用戶可以指定將這些產物儲存到自己 AWS 帳戶下的 S3 儲存桶。這項改變看似只是換了個儲存位置，但它解鎖了企業治理的三個核心能力：
雖然目前這項功能要求 S3 儲存桶必須與 AWS Transform 任務位於同一個 AWS 區域，但它已經為建立一個透明、可控的 AI 輔助開發流程奠定了基礎。
將 AI 生成的產物納入自有儲存只是第一步。一個完整的治理鏈，需要將 AI 的輸出視為一種特殊的「程式碼提交」，並讓它通過與人類開發者提交的程式碼同樣嚴格的審查流程。這條鏈路應至少包含以下環節：
真正的挑戰是將大型語言模型整合到軟體工程工作流程中，這需要的不僅是提示工程，更是對測試、驗證和可追溯性的系統性思考。
—— A Survey of Large Language Models for Code: Evolution, Application, and Theory
當我們將 AI 從一個答案生成器，重新定位為一個需要遵循嚴格協作協議的「開發夥伴」時，它的潛力才能在企業環境中被安全、可靠地釋放。AWS Transform 的這次更新，正是朝著這個方向邁出的重要一步。未來，我們期待看到更多 AI 工具擁抱這種「治理優先」的設計哲學，因為信任，始終建立在透明與可控之上。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>為 AI Agent 選擇外部搜尋 API，從來都不只是一項功能或成本的評估，而是一項根本性的架構決策，它直接定義了 Agent 系統與外部世界的資料邊界。當我們將搜尋能力賦予 Agent，真正的挑戰並非來自 API 的性能，而是如何治理查詢資料的外流、驗證供應商的零資料留存（Zero Data Retention, ZDR）承諾、在執行敏感任務時最小化資訊揭露，並為所有工具路由留下可供稽核的紀錄。這篇文章的目的，便是將搜尋 API 的選型，從單純的工具比較，提升到建立可信任 Agent 外部資料邊界的治理層次。
當一個 AI Agent 為了完成任務而呼叫外部搜尋 API 時，它所傳遞的查詢字串（query）本身就是一種資料外洩。這個查詢可能包含了來自內部任務的上下文、使用者的意圖，甚至是經過推斷的敏感資訊。這不僅僅是將一個問題拋向 Google 或 Bing，而是在 Agent 的封閉系統與不受控的外部網路之間，打開了一道資料交換的閘門。每一次 API 呼叫，都是一次對系統邊界的穿越，也因此成為資料治理必須嚴格把關的第一道防線。
傳統的應用程式開發，我們習慣於將 API 視為功能模組，關注其延遲、吞吐量與成本。但在 Agent 架構中，搜尋 API 的角色更像是一個外部記憶體或感測器，它深刻影響著 Agent 的認知與決策。如果我們對這道閘門缺乏有效的治理，就等於允許 Agent 的「思考過程」與內部狀態，在未受監管的情況下暴露給第三方服務。這不僅帶來隱私風險，在金融、醫療或法律等高度監管的領域，更可能引發嚴重的合規問題。
Zero Data Retention (ZDR) 承諾只是信任的起點，而非終點。真正的挑戰在於如何驗證與稽核，確保供應商的實踐與其聲稱一致。
最近一份在 2026 年 5 月發布的市場分析，比較了 AWS Marketplace 上四款主流的 Web 搜尋 API：Tavily Search、Brave Search、Perplexity Search API 與 Exa Search。報告中除了價格，也特別強調了數據保護與 ZDR 政策的重要性。例如，Tavily 明確承諾其付費方案遵循 ZDR 政策，不會儲存用戶的 API 請求或數據，這對於需要處理敏感資訊的 Agent 應用至關重要。同樣地，Perplexity API 也提供了詳細的隱私與安全說明，供使用者參考。
然而，供應商的 ZDR 聲明本身並不足夠。一個成熟的治理框架，需要我們將評估標準從「供應商說了什麼」轉向「我們能控制與驗證什麼」。透過 AWS Marketplace 這類平台採購，帶來的不只是統一帳單的便利，更重要的是提供了一個集中的控制平面。我們可以利用 IAM 角色進行精細的權限管理，限制特定 Agent 或任務只能存取經過審核的 API，並透過 CloudTrail 記錄每一次的 API 呼叫，建立起初步的稽核軌跡。
那麼，當我們將選型視角拉高，不再只看功能與價格，一份更全面的供應商評估清單會是什麼樣子呢？以下是一些關鍵考量點：
這樣的評估框架，才真正觸及了建立信任邊界的核心。
要打造一個安全、可控且可信任的 Agent 搜尋機制，我們需要一套系統性的設計原則，而不僅僅是選擇一個「安全」的 API。這套設計涵蓋了從任務定義到技術實現的完整鏈條。
首先是資料分級與任務路由（Data Classification & Task Routing）。並非所有 Agent 任務都需要存取外部網路。我們應根據任務的敏感性進行分級。處理高度機密資訊的任務，應預設禁止其呼叫任何外部搜尋工具；而需要即時資訊的低敏感度任務，則可以被路由到經過審核的 ZDR API。這種基於風險的存取控制，是防止資料外洩的基礎。
其次是最小必要查詢（Minimal Necessary Query）。Agent 的 Prompt Engineering 應該包含如何建構「資訊熵最小化」的查詢。這意味著 Agent 在提出問題時，應盡可能地抽象化、匿名化，只包含解決問題所必需的關鍵字，去除任何可能洩漏使用者身份、內部專案代號或具體情境的細節。這需要對 Agent 的思考鏈（Chain-of-Thought）進行引導與約束，確保其對外溝通的「語言」是經過消毒的。
最後是建立不可變的稽核軌跡（Immutable Audit Trail）。每一次 Agent 決定使用搜尋工具，從意圖的產生、查詢的建構、API 的選擇，到最終的回應，都應該被記錄下來。這份紀錄不僅是為了事後追溯，更是為了即時監控。學術界已有不少關於 LLM Agent 安全性的研究，強調監控與可解釋性的重要性。一個完整的稽核軌跡，讓我們有能力分析 Agent 的行為模式，偵測異常的查詢行為，並向監管機構證明我們的系統設計符合合規要求。
總結來說，當我們將搜尋 API 整合進 AI Agent 時，我們不僅是在擴充其能力，更是在定義其與世界的互動邊界。將焦點從 API 的功能與成本，轉移到資料治理、供應商控制與稽核軌跡上，我們才能打造出真正能夠在複雜商業環境中長期運作、值得信賴的 AI 系統。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>當大型語言模型（LLM）應用從實驗性的原型走向正式的產品服務，我們的品質驗證方式也必須隨之進化。過去那種依賴開發者主觀感受、手動抽查幾個案例的「感官測試」已遠遠不足。我認為，建立一套嚴謹、可自動化且整合進日常開發流程的 Agent Evaluation Operations，將 LLM 評估納入 CI/CD 的品質閘門，才是確保 AI 系統穩定、可靠與可信的唯一途徑。這不僅是技術上的最佳實踐，更是將 AI 開發從「煉金術」轉化為「工程學」的關鍵一步。
在 AI 應用開發的初期，我們常常滿足於「看起來不錯」的結果。開發者手動輸入幾個查詢，看看回應是否通順、相關，然後就宣稱模型可用。這種方式在概念驗證階段或許還行得通，但一旦進入維運，就會暴露其致命缺陷：
首先，這種評估方式主觀且無法重現。不同的人、在不同時間點，對於「好」的定義可能天差地遠，缺乏客觀標準，難以追蹤品質的細微變化。其次，它無法規模化。當應用需要處理數百種情境或每天有數千次互動時，手動檢查根本不可行。
更重要的是，它容易忽略隱性衰退（Regression）。LLM 系統的複雜性在於，一個看似微小的 prompt 修改，或更換一個底層模型版本（例如從 Claude 3 Sonnet 升級到 Opus），可能會在不經意間破壞掉數個原本運作良好的邊緣案例。手動測試幾乎不可能捕捉到這種「按下葫蘆浮起瓢」的衰退現象。
如果我們對待 AI 程式碼的方式，就像對待傳統軟體一樣，那麼它的品質保證流程也應當如此。沒有人會接受一個僅靠開發者「感覺」程式碼沒問題就上線的軟體，我們對 AI 系統也應抱持同樣的標準。
將 LLM 評估工程化的核心，是把它當作軟體測試的一部分，整合到持續整合（Continuous Integration, CI）流程中。這意味著每一次程式碼（包含 prompt、模型設定、工具邏輯）的變更，都必須自動觸發一系列評估，並用量化指標來判斷是否通過品質門檻。這個領域，我稱之為「Agent Evaluation Ops」。
最近，觀測與評估平台 Langfuse 推出了一個名為 langfuse/experiment-action 的 GitHub Action，正是這個理念的具體實踐。開發者可以在 GitHub 工作流中定義一個步驟，當有新的 Pull Request 時，自動執行預先設定好的評估集，並將結果回報。如果關鍵指標（如準確率、回應格式正確率）低於設定的閾值，CI 流程就會失敗，從而阻止有問題的程式碼被合併。
建立這樣的自動化評估流程，大致可以分為三個步驟：
這是所有評估的基石。你需要一個「黃金標準」資料集，涵蓋應用的核心功能、已知的失敗案例與各種邊緣情境。例如，一個客服 Agent 的測試集應包含常見問題、模糊的提問、甚至是帶有攻擊性的言論。這個資料集應該像程式碼一樣被版本控制，確保每次測試都在相同的基準上進行。
除了簡單的正確與否，我們需要更細緻的指標。對於 RAG 系統，可以使用如 RAGAS 框架中的 Faithfulness（忠實度）和 Answer Relevancy（答案相關性）等指標。對於結構化輸出任務，可以檢查 JSON 格式是否正確。甚至可以訓練一個小模型作為評估器（Evaluator Model），專門判斷回應的語氣是否符合品牌要求。
使用前述的 GitHub Action 或類似工具，將測試集與評估指標串連起來。例如，在一個辨識圖片國旗的多模態 Agent 專案中，我們可以設定一個工作流：當 main 分支有更新時，自動使用 Vercel AI SDK 呼叫最新的 Claude 模型，跑完 100 張國旗圖片的測試集。如果辨識準確率從 95% 下降到 88%，低於我們設定的 90% 門檻，CI 就會亮起紅燈，PR 也會被阻擋。
將評估視為程式碼（Evaluation as Code），讓 AI 系統的品質從一種「信念」轉變為可被量化、監控與管理的工程指標。這才是專業開發與業餘實驗的根本區別。
自動化評估系統並非萬靈丹。評估器本身也可能存在盲點，或者其判斷標準會隨著時間「漂移」（drift），逐漸與真實的用戶期望脫節。例如，一個用來判斷回應是否有害的評估器，可能無法識別新出現的網路俚語或攻擊手法。
因此，一個成熟的 Evaluation Ops 流程必須包含「人機迴圈」（Human-in-the-loop）。這並不是要我們回到完全手動評估的老路，而是採取更聰明、更具策略性的做法：
首先，定期抽樣審查。每週或每月，隨機抽取一小部分（例如 1-3%）由自動化系統評斷為「通過」與「失敗」的案例，交由人工專家進行複審。其次，當發現人工判斷與機器評估有系統性差異時，這就是一個訊號，代表我們的評估指標或評估器本身需要校準評估器。最後，在人工審查中發現的新失敗模式，應立即被製作成新的測試案例，擴充測試集，納入我們的黃金測試集中。這形成了一個持續學習與改善的飛輪效應。
這種結合自動化規模與人工智慧的監督機制，讓我們既能享受 CI 帶來的效率與即時回饋，又能確保整個評估系統本身是準確且與時俱進的。史丹佛大學的 HELM (Holistic Evaluation of Language Models) 框架，便是一個大規模評估模型的學術範例，其背後也蘊含著對多維度、標準化評估的重視。
總結來說，將 LLM 評估整合進 CI/CD 流程，是 AI 應用開發從手工作坊邁向工業化生產的必然過程。它強迫我們用更嚴謹的工程思維來對待 prompt、模型與整個系統的品質。這條路或許初期建置成本較高，但對於任何想要打造長期、可靠、可信任 AI 服務的團隊而言，這筆投資絕對是值得的。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>將 AI Agent 導入安全維運（SecOps）的真正價值，並不在於打造一個能自動隔離主機、封鎖 IP 的「全自動反制系統」，而在於建立一套可治理的「威脅分析工作流程」。當前業界最大的痛點是警報疲勞，而非回應速度。一個更成熟的模型是：讓 Agent 扮演初級分析師，在偵測到異常時，自動生成假設、蒐集可追溯的證據、提出初步建議，最後將一份濃縮後的、有脈絡的報告提交給人類專家裁決。這種區分「調查」與「執行」的模式，不僅大幅降低了誤判造成的營運風險，也讓 AI 的應用更具備可追溯性與信賴度。
在資安領域，自動化是個誘人但充滿風險的目標。安全協作、自動化與回應（SOAR）平台雖然行之有年，但「全自動反制」（fully automated remediation）的實踐案例卻相對稀少，尤其是在核心生產環境中。原因很簡單：誤判的代價過於高昂。一個錯誤的自動化規則，可能因為誤判一個正常的商業行為而阻斷關鍵服務，造成比原始威脅更大的損失。例如，自動封鎖一個被標記為可疑的 IP，結果該 IP 可能是某個重要客戶或第三方服務的出口，導致服務中斷。
此外，現代的攻擊手法日益複雜，許多進階持續性威脅（APT）擅長偽裝成正常流量，單純依賴規則或簡單模型很難準確判斷。根據 Ponemon Institute 的研究，安全營運中心（SOC）的分析師平均每天要處理數千個警報，其中大量是誤報。這就是所謂的「警報疲勞」（alert fatigue），它會嚴重侵蝕維運團隊的反應能力。在這種情況下，導入一個可能產生更多自動化「噪音」或錯誤行動的系統，無疑是雪上加霜。我們需要的不是更快的「執行」，而是更準確、更有效率的「調查」。
我認為，一個更穩健、更具實務意義的 AI Agent 整合模式，是將其嚴格限制在「調查」階段，並將最終的「執行」權力保留給人類。這個工作流程可以拆解成以下 5 個受控的步驟：
這種模式的關鍵在於，AI Agent 的職責是「賦能」而非「取代」。它將人類從繁瑣、重複的初步調查工作中解放出來，讓我們能專注於最需要經驗與判斷力的決策環節。這也是人機迴圈（Human-in-the-Loop）精神在安全維運領域的最佳體現。
最近的一個具體案例，很好地詮釋了上述理念。在 2023 年發表的開發者社區文章中，展示了如何將一個概念性的 AWS DevOps Agent（實際產品可能為 DevOps Guru 的一部分）整合進安全警報管線。透過 AWS Security Hub 匯總來自多個帳號的 GuardDuty 警報，再利用一個通用的 Webhook 將警報推送給 DevOps Agent。
這個 Agent 收到警報後，會利用預先配置好的 IAM 角色，跨帳號地去調查與警報相關的資源。例如，它會去描述（describe）被標記的 EC2 執行個體、檢查其 IAM 角色權限、分析相關的 CloudTrail 日誌等。完成調查後，Agent 會生成一份包含關鍵資訊的摘要，並透過 Slack 通知給維運團隊。整個過程從偵測到通知，實現了調查的自動化，但最後的處置決策權，仍然掌握在人類手中。
這個案例的巧妙之處在於，它並未試圖讓 Agent 執行任何高風險的變更操作。它的權限被嚴格限制在調查和報告的範疇內，完美地扮演了初級分析師的角色。這不僅提升了回應效率，更重要的是，它在一個清晰的治理框架下運作，確保了每一步都有跡可循，且最終風險可控。
總結來說，將 AI Agent 整合到安全維運中，重點應放在如何將海量的原始「警報」轉化為少量高品質的「洞察」。透過建立一個明確區分調查與執行的工作流程，我們可以最大化 AI 在效率上的優勢，同時最小化其在自動化決策上的風險，這是我認為在當前技術階段最為務實且可持續的發展方向。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>隨著企業在不同應用中導入 OpenAI、Anthropic、Google 或開源等多種大型語言模型（LLM），一個統一的入口（Gateway）已從便利工具演變為必要的基礎設施。它不應只被視為屏蔽 API 差異的轉接器，而是一個集中化的「控制平面」（Control Plane）。這個控制平面承擔了模型路由、成本歸因、身份驗證與政策執行，以及 Prompt 和 Tool Call 的稽核，是確保 AI 系統可治理、安全且具成本效益的核心。若缺乏這個集中化的治理層，企業將很快陷入技術債、安全風險與預算失控的泥沼。
當前的 AI 開發現況是，沒有任何單一模型能完美適用於所有場景。開發團隊會基於效能、成本、資料隱私或特定能力，為不同任務選擇不同模型。例如，行銷文案可能採用 OpenAI 的 GPT-4o，客服對話則使用 Anthropic 的 Claude 3.5 Sonnet 以求更安全的對話風格，而內部資料分析或許會選擇在本地部署的 Llama 3。這種「為工作選擇最佳工具」的務實作法，雖能提升單點應用的表現，卻也為企業帶來了系統性的混亂。
然而，當每個應用程式都直接與不同的模型 API 對接時，企業將很快面臨一系列棘手問題：
這種分散式的作法，讓每個應用程式都變成一個獨立的孤島，使得整體的 AI 系統變得脆弱、昂貴且難以治理。
一個設計良好的多模型 Gateway，其價值遠不止於將所有模型的 API 呼叫統一成 OpenAI 的格式。我認為，它的真正潛力在於成為 AI 應用的「控制平面」，一個集中執行治理與營運策略的中樞。這個概念借鏡自雲端原生架構中的服務網格（Service Mesh），將應用邏輯與基礎設施的控制邏輯分離。
當 Gateway 成為控制平面，它便能承擔以下關鍵職責：
將治理邏輯從數十個應用程式中抽離，集中到一個控制平面上，不僅降低了開發者的負擔，更重要的是，它讓安全與營運團隊獲得了全域的視野與控制力。
將開源工具如 LiteLLM 部署為企業級的控制平面，需要的不只是運行一個 Docker 容器。它需要一套穩健的基礎設施來確保其高可用性、安全性與可擴展性。最近一篇來自 DevelopersIO 的實作案例，便展示了一個優秀的架構藍圖。
該架構將 LiteLLM Proxy 部署在 AWS 的無伺服器容器服務 ECS Fargate 上，並圍繞它建立了一整套安全與維運機制。關鍵的設計包括：
這個架構展示了如何將一個開源工具，透過與雲端平台原生服務的深度整合，打造成一個符合企業安全與合規標準的關鍵基礎設施。LiteLLM 支援超過 100 種 LLM API，這樣的架構讓企業能安全地擁抱多樣化的模型生態系。
對於剛起步的小型專案，讓開發團隊直接呼叫模型 API 或許是最快的方式。但當企業內部的 AI 應用數量從 3 個成長到 30 個時，分散式架構的弊病將會被迅速放大，最終形成難以償還的技術與治理債務。
將多模型 Gateway 視為 AI 系統的控制平面，是一種架構上的策略選擇。它要求我們在初期投入更多精力來建構這個集中化的基礎設施，但這份前期投資，將在後續的系統擴展、安全管理與成本優化上，帶來數倍的回報。在一個 AI Agent 將日益普及、自主性越來越高的未來，一個強大、可信賴的控制平面，將是確保這些智慧體在我們的掌控之中的必要前提。根據 史丹佛大學基礎模型研究中心（CRFM）的報告，模型生態系的透明度與可治理性仍有極大改善空間，而一個企業級的控制平面正是彌補這道鴻溝的關鍵實踐。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
AI Agent 的發展正處於一個關鍵的十字路口。我們一方面驚嘆於無數能自主規劃、執行複雜任務的展示，但另一方面，這些成果大多停留在一次性的「概念驗證」（Proof of Concept），難以轉化為穩定、可複用、可信賴的工業級能力。我認為，要跨越這道從 Demo 到 Production 的鴻溝，關鍵不在於訓練出更強大的單體模型，而是需要建立一套制度化的基礎設施，將零散的「技能」轉化為可交換、可驗證、可組合的「能力」。這不只是一場技術思維的轉變，更是從工程到產業生態的全面升級。
當前的 Agent 開發現況，很像一個個獨立的手工作坊。每個團隊都在自己的工作坊裡，用獨特的工具和流程，打造出精美的作品。這些作品（Demo）或許在特定場景下表現優異，但存在幾個根本性的問題，阻礙了它們的規模化應用：
這些問題的本質，是我們一直在專注於提升 AI 的「智力」，卻忽略了建立一個能讓這些智力被有效組織、管理和應用的「工業體系」。
最近一篇關於建築工程領域的論文 Buildrix: An Open Platform for Sharing and Benchmarking Agentic AI Skills in Building Engineering (arXiv:2606.25139)，為解決上述問題提供了一個極具參考價值的實踐框架。儘管它專注於特定領域，但其背後的設計哲學，正是我所說的「能力工業化」的具體體現。
Buildrix 的核心並不是一個更聰明的 Agent，而是一個旨在標準化、共享和驗證 Agent 技能的開源平台。它由三個關鍵部分組成：
這個框架的重點，是將 AI 的能力從模糊、內隱的「模型潛能」，轉化為具體、可管理的「工程資產」。
只有當一項技能能夠被清晰地定義、封裝、測試和交換時，它才真正具備了工業價值。這就像是從手工業時代的師徒傳承，演進到現代製造業的標準化零件與供應鏈體系。
Buildrix 框架中，我認為最具變革潛力的一環，是它強調由領域專家來貢獻和驗證測試案例（expert-curated test cases）。這點至關重要，因為它直接解決了通用評估基準在專業領域的局限性。
在建築、法律、醫療等行業，一項任務的「完成」與「高品質完成」之間有著天壤之別。AI Agent 輸出的結果是否符合行業規範？是否考慮到了某些隱性的安全要求？這些都不是單純的程式碼正確性或語意相似性能夠衡量的。
例如，一個能為 Python 程式碼生成單元測試的 Agent，其產出的測試案例是否真的涵蓋了邊界條件，需要資深軟體工程師的判斷，這也是 Stanford HELM 等評估框架持續強調的「多維度評估」概念。
將專家知識融入基準建立的過程，意味著：
總結來說，AI Agent 的未來，不應是追求一個無所不能的「超級大腦」，而更可能是一個由無數經過標準化、通過專家驗證的「微能力」所組成的、充滿活力的生態系統。就像現代軟體工程是由可複用的函式庫、API 和微服務構成一樣，未來的複雜 AI 應用，也將由這些可信賴、可組合的技能模組搭建而成。
從 Buildrix 這樣的專案中，我們看到的不仅是一個特定領域的解決方案，更是一條將 AI 從實驗室推向工廠的清晰路徑。下一步的挑戰，不再是問 AI「能做什麼」，而是建立一個能確保它「做得對、做得好」的工業體系。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>大型語言模型在多數協作任務中，預設追求平衡、禮貌且不得罪人，這在程式碼審查（Code Review）等需要批判性分析的場景中，反而成為一種負債。這種「和諧偏誤」常產出低摩擦但低價值的共識，難以揭露深層缺陷。要發揮 AI 的真正潛力，我們必須在協作系統中明確設計「結構化異議」（Structured Dissent），賦予 AI 敵對角色與反證責任，讓有目的的「不同意」成為品質控制的核心機制。這不僅是個提示工程技巧，更是未來人機協作設計的關鍵思維轉變。
如果你曾讓 ChatGPT 或 Claude 這類模型幫你審查程式碼，大概會對以下的回應模式感到熟悉：「整體來說，這段程式碼寫得很好。不過，這裡有幾個可以改善的小建議⋯⋯」。這種回應模式是 AI 經由 RLHF（人類回饋增強學習）微調後的典型產物。模型被訓練得要友善、有幫助、避免產生衝突，因此它們傾向於先肯定、再提出溫和建議，以維持流暢的互動體驗。
然而，在品質保證、風險評估或程式碼審查這類工作中，我們的目標並非尋求和諧，而是找出潛在的失敗點。AI 預設的和諧溝通，反而容易讓我們陷入一種「認知安逸」的狀態，忽略了那些最需要被挑戰的假設。
當 AI 總是扮演一個溫和的建議者，而非嚴格的檢驗者時，它所提供的價值便大打折扣。這種低摩擦的互動，最終只會導向低價值的表面共識，無法真正提升系統的強韌性（robustness）。
日本一個 Web 開發團隊 coelia-system 的實踐，為我們提供了一個將「結構化異議」具體落實的絕佳範例。他們在其專案的架構決策紀錄（ADR 0082）中，對所有十幾種審查相關的 AI 技能（包含架構、資安、效能、可靠性等）導入了一套名為「敵對性驗證」（Adversarial Verification）的作法。這套作法的核心，就是透過明確的規則，強制 AI 擺脫和諧的預設，轉而扮演一個專注於尋找缺陷的敵對角色。
他們制定了三項簡單而強大的規則：
這套作法看似只是改變了提示詞，但其本質是在人機協作流程中，制度性地嵌入了一個「魔鬼代言人」。它不再依賴 AI 的自發性批判，而是透過系統設計，確保批判性視角的存在與作用。
將「敵對性驗證」僅僅視為一種高明的提示工程，會錯失其更深層的意義。它的核心價值在於，它是一種「協作系統設計」的思維——我們主動定義了 AI 在系統中應扮演的角色、應承擔的責任，以及它與人類協作者之間的互動模式。
我們需要的不是一個總是附和的夥伴，而是一個被賦予了反對責任、且能力足以挑戰我們的嚴謹對手。
這個概念與幾個重要的領域緊密相關：
從這個角度看，這套作法更像是為 AI 設定了一套「微型憲法」，類似於 Anthropic 提出的 Constitutional AI 概念，只是應用範疇更為具體。我們不再只是向一個通用的、黑箱的模型提問，而是正在設計一個有特定角色分工、有明確流程的、可預測的協作系統。
當我們開始以「系統設計」而非「單次互動」的視角來思考與 AI 的協作時，才能真正駕馭它的力量。與其期待一個溫和的 AI 夥伴，不如動手設計一個嚴格的 AI 對手。因為在建構可靠系統的漫長道路上，有價值的異議，遠比廉價的共識來得重要。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。
]]>