Statewright: 為 AI Agent 引入確定性護欄

AI Agent 通常被描述為強大但脆弱。當給予大量的工具和開放式目標時，即使是最先進的模型也可能面臨困難，經常陷入「讀取迴圈死亡螺旋」，即重複分析同一個檔案卻從未採取任何行動。業界的預設回應通常是部署更大的模型或編寫更長的系統提示詞，但這些對於確保生產級別的可靠性往往是不夠的。

Statewright 引入了一種不同的哲學：「Agent 是建議，狀態是法律。」 Statewright 並非試圖讓模型變得更聰明，而是透過實施狀態機護欄來嚴格控制 Agent 在工作流特定階段可以存取的工具，從而縮小問題的範圍。

核心方法：限制解空間

Statewright 的核心是一個評估狀態機定義的確定性 Rust 引擎。它不使用 LLM 來管理狀態；相反，它作為協定層的守門人。透過限制工具和解空間，模型被迫在每個步驟中於聚焦的上下文內進行推理。

例如，一個典型的錯誤修復工作流可以分為幾個不同的狀態：

Planning: Agent 被授予唯讀工具（例如，Read, Grep, Glob）。它不能修改代碼，以確保它在嘗試修復之前完全理解問題。
Implementing: 一旦 Agent 轉換到此狀態，編輯工具就會被解鎖。然而，Statewright 可以應用進一步的限制，例如阻擋破壞性的 shell 操作（如 rm 或 shred）或限制每個狀態編輯的行數上限。
Testing: 僅允許指定的測試命令（例如，pytest 或 npm test）。如果 Agent 嘗試使用當前階段不允許的工具，請求將被拒絕，並附帶一條解釋可用工具及如何轉換狀態的消息。

模型性能的可衡量增益

Statewright 最引人注目的方面之一是其對較小、本地模型產生的影響。根據開發者進行的研究，限制可以顯著降低完成複雜任務所需的「智能門檻」。

在 SWE-bench 基準測試的一個包含 5 個任務的子集中，兩個模型（範圍從 13.8GB 到 19.9GB）在使用 Statewright 限制時，其成功率從 2/10 跳升至 10/10。雖然由於檔案內容保留能力有限（這是硬體/模型的限制，而非狀態機的限制），小於 13GB 的模型仍然面臨困難，但結果表明，結構性限制可以使中型本地模型在特定工作流中表現得像前沿模型一樣。

對於前沿模型，其益處不在於基礎能力，更不在於效率。透過將可用工具從 30 個以上減少到少數幾個，Statewright 減少了 token 使用量並防止模型「掙扎」或陷入重複的迴圈。

技術實施與護欄

Statewright 透過 Model Context Protocol (MCP) 或特定的插件鉤子與 Agent 整合。強制執行程度因 Agent 而異：

Hard Enforcement: 在像 Claude Code 這樣的 Agent 中，工具調用會在模型看到它們之前就在協定層被阻擋。
Advisory Enforcement: 在像 Cursor 這樣的 Agent 中，規則會被注入到上下文中，但架構不允許進行硬性的協定層門控。

關鍵護欄功能

定義自定義工作流

工作流是使用 JSON schema 定義的，這允許開發者創建迴圈、迭代的過程，而非簡單的有向無環圖 (DAGs)。這點至關重要，因為 Agent 的工作並非線性；它通常需要重試失敗的測試或在實施失敗後返回到規劃階段。

開發者可以手動編寫這些工作流，使用視覺化編輯器，或者甚至讓 Agent 透過 statewright_create_workflow 工具生成工作流定義。

權衡與考量

雖然 Statewright 提供了顯著的可靠性提升，但它並非沒有代價。該系統需要 MCP 支持（或特定的鉤子）才能運作。此外，如果工作流定義得過於嚴格，Agent 可能會卡住，因此需要使用 statewright_deactivate 逃生艙來返回到不受限制的狀態。

透過將焦點從模型大小轉移到結構性限制，Statewright 提供了一個框架，使 AI Agent 變得可預測、可驗證，且——最重要的是——足以可靠地處理自主軟體工程任務。