對於開發 AI 應用程式的工程師來說，最頭痛的往往不是如何呼叫 LLM，而是在將單純的聊天機器人轉化為能執行複雜任務的 Agent 時，如何處理對話狀態、長時任務以及安全性問題。Google 最近為其開源框架 Genkit 推出了 Agents API（預覽版），試圖透過一套統一的抽象層來解決這些工程實務上的挑戰。
這篇文章將為你解析 Genkit Agents API 的核心設計，以及它如何解決開發 AI Agent 時常見的幾個痛點。
統一的對話接口與擴展路徑
在許多框架中，開發一個簡單的問答機器人與開發一個複雜的多步驟工作流（Workflow）通常需要使用完全不同的元件。Genkit 的設計理念是提供單一的 chat 接口，讓開發者不需要在功能增長時更換底層原語（Primitives）。
無論你的 Agent 是在單一程序中執行，還是部署在 HTTP 端點後方，同樣的對象可以處理單次回覆答、多輪對話串流、需要人類審核的暫停狀態，甚至是長時間運行的異步任務。這種一致性降低了從原型開發到生產環境部署的心智負荷。
區分狀態與產出物
Genkit 在數據管理上做了一個重要的區分：將狀態（State）與產出物（Artifacts）分開。
狀態指的是驅動下一次對話的類型化應用數據，例如目前工作流的進度、待辦清單或已選擇的實體。而產出物則是 Agent 生成的結果，例如一份分析報告、一段程式碼補丁或一份旅行行程表。
這樣設計的重要性在於，產出物通常需要獨立地被用戶檢查、下載或進行版本管理，而不應該被混在對話歷史紀錄中。Genkit 允許工具（Tools）分別更新這兩種數據，並將變更即時串流給客戶端。
靈活的狀態持久化策略
AI Agent 的記憶（Memory）本質上就是狀態管理。Genkit 提供了兩種路徑來處理對話狀態：
伺服器端管理（Server-managed）：透過配置 Session Store（如 Firestore、記憶體或文件），伺服器會將訊息、狀態和產出物儲存為快照（Snapshots）。客戶端只需持有 Session ID 即可重新連接。這適合大多數生產環境，能確保狀態的一致性。
客戶端管理（Client-managed）：伺服器不儲存任何數據，而是將完整狀態回傳給客戶端，客戶端在每次對話時再將其傳回。這對於有嚴格數據駐留（Data Residency）法規要求，或需要臨時會話（Ephemeral Sessions）的應用至關重要，因為伺服器端不會留下任何用戶數據。缺點是隨著對話增加，網路傳輸的數據量會隨之成長。
突破連線限制的 Detached Turns
在實務中，許多 Agent 任務（如深度研究或複雜規劃）可能需要運行數分鐘甚至數小時。傳統的 HTTP 或 WebSocket 連線很容易因為逾時或網路不穩而中斷。
Genkit 引入了 Detached Turns（分離輪次）機制。開發者可以啟動一個任務後直接斷開連線，Agent 會在伺服器端繼續執行並持續更新快照。客戶端可以使用輪詢（Polling）方式檢查任務進度。這意味著開發者不再需要為了長時任務而額外搭建複雜的訊息隊列（Job Queue）或維護長連線。
人機協作與安全性：Interruptible Tools
當 Agent 擁有執行系統指令或修改數據的權限時，完全自動化是非常危險的。Genkit 提供了可中斷工具（Interruptible Tools），實現 Human-in-the-Loop（人機協作）。
當一個工具被標記為可中斷時，Agent 在執行到該步驟會自動暫停，將待執行動作回傳給用戶。只有在用戶核准（Approve）或拒絕（Reject）後，任務才會繼續。
更重要的是，Genkit 內建了防偽造保護（Anti-forgery protection）。執行環境會將恢復執行的請求與會話歷史紀錄進行驗證，防止惡意用戶透過偽造輸入來欺騙 Agent 執行未經授權的操作。
生態系定位與選擇
Genkit 採取模型不可知（Model-agnostic）的策略，透過插件支持 Gemini, Anthropic, OpenAI 和 Ollama。它與 LangChain 或 CrewAI 等框架的不同之處在於其全棧（Full-stack）定位：它不僅提供邏輯層，還提供了類型化的客戶端 SDK、內建串流協議，以及與 Firebase 和 Cloud Run 的深度整合。
對於工程師而言，選擇 Genkit 的核心理由在於它將 Agent 的上下文管理視為基礎設施問題，而非僅僅是提示詞（Prompt）問題，從而提供了更穩健的生產級開發路徑。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。