超越 Harness:面向 Agent 可靠性、安全性與效率的平台解法

TL;DR

• 第三波平台演進:第一波是硬體與軟體分離、高階語言誕生;第二波是雲端運算與跨資料中心的分散式應用。兩波各自催生了一個「作業系統」——一層把應用與基礎設施隔開的抽象,同時提供韌性、擴展性與效率的原語。AI 應用是企業架構史上最不確定、最不可靠的元件,將需要第三個這樣的基礎。
• 兩類新挑戰:結構性(structural)——agent 的指令集是開放式的,在 runtime 才決定用哪些操作、以什麼順序執行,這直接破壞 zero-trust 安全(需要事先知道互動模式)、傳統復原(補償與 rollback 變得難以實作)與部署前測試;加上 context 裡指令與資料沒有分離、agent 之間又靠交換 context 溝通,執行隔離消失,blast radius 控不住。語義性(semantic)——無法完整指定 agent 目標(「該做什麼」難寫,「不該做什麼」更難),缺乏形式化方法驗證目標,模型又不擅長回報自身狀態(沒有可靠的 error code),導致成功/失敗/活性(是否在收斂而非卡住)都難以判斷,判斷不了就無法復原。
• 解法方向:不重造平台,而是在既有雲端平台上加一層攔截層,能同時接上三類 agent(自建的、可用 hook/plugin 控制的知名 harness、只能從外部觀察的黑箱),用統一方式觀察與修改 agent 對外界的所有互動;控制功能建在這層之上。首先攻的是 zero-trust 安全,再往語義層(context 管理、tool call 正確性、資料流分析)延伸。專案為 Rossoctl。
• 應用模式是 serverless:把 agent loop 當成無狀態元件,與管理 context 的 durable session 儲存、以及由多樣化 sandbox 組成的執行層分離——換來更好的韌性、正確性、效能與擴展性,並在成本上有實測收益。

重點整理

為什麼需要第三個作業系統(約 00:33:26–00:34:50)

Steinder 認為我們正進入應用平台演進的下一波:

她對「作業系統」的定義是雙重的:一層把應用與基礎設施隔開的抽象,以及一組應用可以倚賴來取得韌性、擴展性與效率的原語。AI 應用當然能跑在現有基礎上——問題是現有基礎對這些新挑戰幾乎幫不上忙。

結構性挑戰:開放式指令集(約 00:34:52–00:36:10)

「指令集」在這裡指的是 agent 能對外部世界執行的操作集合。Agent 的指令集是開放式的,而且在 runtime 才決定用哪些、怎麼排序。這打破了現有平台的幾個關鍵假設:

• Zero-trust 安全變得很難,因為它依賴在設定時就理解應用之間的互動模式。
• 復原變得很難,補償(compensation)與 rollback 這類傳統手法變得難以實作。
• 這些應用在部署前無法被完整測試。

再加上兩件事:context 裡指令與資料沒有分離(這正是 agent 出現這麼多新型安全威脅的原因),而 agent 之間又是靠交換 context 溝通,於是不同 agent 之間的執行隔離也消失了——結果就是韌性與安全問題的 blast radius 難以控制。

語義性挑戰:沒有可靠的 error code(約 00:36:15–00:37:30)

這一段她明確接上 Ion Stoica 前一場的主題:

• 我們無法完整指定 agent 的目標。用敘述表達「agent 該做什麼」就已經很難,「agent 不該做什麼」更難;而且仍然缺乏形式化方法來表達與驗證 agent 目標。
• 更糟的是,AI 模型不擅長回報自己的狀態——我們基本上沒有可靠的 error code。因此判斷 agent 是否正確運作、是否成功、偵測失敗、以及判斷 liveliness(有沒有在推進、是在收斂還是卡住),全都變得很困難。而如果無法判斷問題是什麼,就無法從中復原。
• 還有一層語義落差:agent「思考與規劃」的方式,與真實世界介面那種 schema-based、又不斷改版的本質之間對不上,持續製造新錯誤。

今天怎麼解,以及為什麼會收斂(約 00:37:37–00:39:05)

現況是:全部在應用層以 bespoke 方式處理。大家做 framework、做 harness,而且數量很多——每隔幾個月就有新的強力 agent 或 harness 出現,證明「解法存在」,但也造成嚴重的碎片化,而且 harness 本身很難開發、需要大量專業知識。

她的判斷是:我們明顯還在實驗階段,而歷史上每一波創新都經歷過同樣的事——一開始有多種 Unix;容器與 cloud native 時代一開始有各種容器、各種容器編排平台與彼此分歧的生態系;最後產業識別出共同模式、標準化、然後收斂。第一波收斂到 Unix 與 POSIX 語義,第二波收斂到 Kubernetes 與其生態。AI 時代也會發生同樣的事。

他們的做法:攔截層與三類 agent(約 00:39:08–00:41:30)

方法論是先看自己組織裡實際在跑的 agent,分成三類:

1. 自建:用某個 framework 或 SDK 自己實作,完全可控。
2. 知名 harness:可透過 hook 與 plugin 控制。
3. 黑箱 agent:什麼都不能改,只能從外部觀察來控制。

他們要建的是一層攔截層(layer of interception),能與這三種風格都整合,並提供統一的方式來觀察與修改 agent 與外部世界的所有互動;控制功能就建在這層抽象之上。

第一個攻的問題是安全,特別是 zero-trust,做成多層級權限系統:

1. 實作 identity,
2. 用該 identity 做帶授權的委派流程(delegation flows),
3. policy-based access,
4. 最後是 intent-based access——評估 agent 正在做的事是否真的符合使用者目標。

之後往語義層延伸:能不能在 agent 之外、以與業務邏輯無關的方式管理 agent 使用的 context?能不能管理 tool call 的正確性?能不能做資料流分析來理解並控制資料如何流動?這些收在 Rossoctl 專案裡(網頁上有更深入的 benchmark 與實驗結果);同事 Maya 當天也有相關海報。

關鍵是:他們不是要取代既有平台。所有東西都建在現有雲端平台上,沿用並延伸既有標準——OAuth 2、身分用 SPIFFE、既有的 policy 語言,在 Kubernetes 上編排;gateway 原本基於 Envoy proxy,現正轉向基於 Praxis 專案、效率更好的 Rust 實作。

成果:context compaction 帶來的成本下降(即使對 SOTA agent 也成立)、tool calling 正確率的穩定提升(轉化為 agent 品質提升)、以及透明的權限控管。

應用模式:serverless(約 00:42:21–00:43:30)

平台演進的另一半是應用模式。她主張 agent 的正確模式是 serverless:把 agent loop 當成無狀態元件,與(a)管理 context 的 durable session 儲存、(b)由多樣化 sandbox 提供的執行層分開。好處是韌性、正確性、效能與擴展性都更好。

實測收益:對 model-bound 的 agent 可省下大量基礎設施成本;可以彈性配置 sandbox(不是每個 agent 都需要最貴的那種,而昂貴的 sandbox 真的很貴);在安全政策允許的情況下還能重複使用 sandbox。

結語是一個公開邀請:她相信新一波平台會被建起來,他們已經上路,想聽到同意或不同意的意見,也想跟任何在做同方向的人合作。

金句

"AI applications are without any doubt the most non-deterministic and unreliable component that has ever been introduced in enterprise architectures."(約 00:34:20)

這句話定調了整場演講:不是要修好 AI,而是要為這種不可靠元件設計基礎設施。

"It's very difficult to express what agents should do … but it's even harder to specify what agent shouldn't do."(約 00:36:26)

與 Ion Stoica 的 requirement gap(omission vs. exclusion)直接呼應。

"We essentially do not have any reliable error codes."(約 00:36:45)

一句話講完為什麼 agent 的可觀測性與自動復原這麼難。