AgentField：把 AI Agent 當作 API 來建、當作微服務來跑的控制平面

它解決的問題：agent 不是程式，是服務

多數 agent 框架把重點放在單一 agent 的推理迴圈，例如怎麼呼叫模型、怎麼處理工具。但當你開始跑十個、一百個 agent，問題就變成：誰來路由請求？誰來排隊？誰在 agent 掛掉時重試？誰把每次 fan-out 的軌跡記錄下來？AgentField 的切入點是，把 agent 當作 API 端點來設計，而不是當作獨立程式。README 開宗明義說「Build agents like APIs. Run ten thousand of them like microservices.」這句話點出它的核心假設：agent 的呼叫模式與一般後端服務沒有本質差異，只是邏輯更複雜、執行更耗時。因此它提供一個控制平面，宣稱能處理 fan-out、佇列、重試與追蹤，讓開發者專注寫 agent 的決策邏輯。這套設計的目標使用者很明確：已經在生產環境跑多 agent 系統，卻被基礎設施細節困擾的工程團隊。它不是給只想在 notebook 裡實驗 prompt 的人用的。

運作機制：從一個 reasoner 到一個 REST 端點

AgentField 的程式模型很直接：你寫一個繼承 Agent 的物件，用裝飾器（例如 @app.reasoner）標記某個 async 函式為 agent 的入口，然後呼叫 app.run()。README 給的例子是 researcher，它接受 question 與 depth 兩個參數，當 depth 小於 3 時，它會呼叫 app.ai 請模型拆出子問題，再用 asyncio.gather 搭配 app.call 對同一個 agent 做遞迴 fan-out。depth 上限確保 fan-out 不會無限膨脹。關鍵在於 app.call 不是直接呼叫 Python 函式，而是把請求送到控制平面，由控制平面負責排隊與重試。因此 agent 之間的溝通不是程序內呼叫，而是透過控制平面的網路請求。這解釋了為什麼 README 強調「No broker, no queue setup, no timeout.」：佇列與重試是控制平面的內建行為，不需要開發者另外接 RabbitMQ 或 Redis。從 repository 的語言分佈來看，控制平面以 Go 實作，而 SDK 支援 Python、Go 與 TypeScript，這表示 agent 邏輯可以跨語言撰寫，但都得透過 REST API 與控制平面溝通。

從一行 spec 到 Docker Compose：安裝與快速上手

安裝方式是一條 curl 指令：curl -fsSL https://agentfield.ai/install.sh | bash。這個 installer 會把 af 命令列工具放到 ~/.agentfield/bin，同時也會安裝一個名為 aforge 的 coding harness，後者用來支援 Claude Code、Codex、Gemini CLI 等工具。如果你不需要 harness，可以用 --no-aforge 跳過。在 macOS 上，installer 還會把控制平面註冊成 launchd 服務，並在選單列加入圖示，這代表安裝後控制平面會常駐背景。README 特別警告：不要用 plain kill 停止服務，因為這會被視為 crash 而自動重啟，正確做法是 af service stop。這是一個值得注意的行為差異，如果你習慣用 kill 或 systemctl 管理程序，需要先適應。安裝完成後，你可以在任何支援的 coding agent 中貼上 /agentfield 開頭的 spec，例如「Build a claims processor with risk scoring...」。AgentField 會產生一個 Docker Compose stack，包含 agent、控制平面與 REST API 端點。換句話說，從安裝到有一個可以 curl 的端點，中間不需要手動寫 YAML 或接佇列。但這也表示你的開發流程會依賴 installer 與 aforge 這兩個工具，而不是單純的 pip install。

版本狀態與維護成本：還在 RC 階段的控制平面

從 release 頁面來看，最新版本是 v0.1.138-rc.16，發布日期為 2026-09-09，而且同一天連續發布了 rc.14、rc.15、rc.16 三個版本。這種發布頻率暗示專案仍處於快速迭代階段，API 可能尚未穩定。對一個要當作生產基礎設施的控制平面來說，這是一個需要警惕的訊號。README 提到的功能，例如 canary deploy、A/B testing、blue-green rollouts，都寫在 version 參數的註解裡，但沒有文件說明這些機制如何設定或驗證。維護成本方面，採用 AgentField 意味著你要追蹤 rc 版本的更新，因為 bug fix 可能藏在這些頻繁的 release 中。此外，installer 的行為（例如 launchd 註冊、menu-bar 圖示）在 macOS 上會改變系統狀態，移除時需要確認 af service stop 是否完整清除這些設定。授權是 Apache-2.0，這對商業使用相對友善，但 Apache-2.0 不包含商標授權，如果你要使用 AgentField 名稱或 logo，仍需另外確認。整體來說，這個專案的功能宣稱很吸引人，但它的成熟度證據只來自 README 與 release 時間戳，沒有提供任何第三方審計或大規模部署案例。

真正的限制：不是萬能的 agent 平台

AgentField 的文件與程式範例都圍繞著「reasoner」這個概念，也就是把問題拆解後遞迴 fan-out。但這只是 agent 的一種型態。如果你的 agent 需要長時間執行的工具呼叫、需要與外部系統保持雙向串流，或者需要人類在流程中多次介入（例如 README 提到的 claims processor 需要 human approval），AgentField 的 request-response 模型可能就不夠用。README 的範例中，human approval 只被描述為 spec 的一部分，但沒有展示 AgentField 如何暫停一個 workflow 等待人為決策。這是文件上的空白，不代表它做不到，但至少沒有證據支援。另一個限制是 vendor locking：你的 agent 邏輯必須寫成 Agent 物件的方法，並使用 app.ai 與 app.call 這兩個 SDK 函式。這不是標準 Python 或 TypeScript，換句話說，如果你之後想搬到另一個框架，你需要改寫所有 agent 程式碼。最後，AgentField 依賴 Docker Compose 來部署，這代表你的執行環境必須支援 Docker。如果你的生產環境是裸機或受限的容器平台，這個前提可能不成立。

替代方案：LangGraph 與 Temporal 的取捨

如果要找功能重疊的開源專案，LangGraph 是常見的比較對象。LangGraph 以圖為核心，開發者明確定義節點與邊，狀態透過 checkpoint 管理，適合需要精細控制流程的場景。AgentField 則反其道而行，它刻意隱藏圖的結構，讓你用遞迴函式自然表達 fan-out。差異在於：LangGraph 給你顯式的控制權，但你必須自己設計圖；AgentField 給你隱式的便利，但你對執行順序的掌控較弱。另一個值得考慮的是 Temporal，它是一個通用的工作流程引擎，不是專門為 agent 設計，但它提供久經考驗的佇列、重試與追蹤機制。如果你已經在使用 Temporal，你可以直接用它來編排 agent 呼叫，不需要引入 AgentField 的控制平面。差別在於 Temporal 需要你自行定義 activity 與 workflow，而 AgentField 把這層抽象內建在 SDK 中。換句話說，AgentField 的價值主張是「少寫基礎設施程式碼」，但這也代表你對基礎設施行為的能見度較低。如果你的團隊重視可除錯性與流程可視化，LangGraph 或 Temporal 可能更合適。

結論：誰該用、誰不該用、先驗證什麼

AgentField 的定位清楚：它要解決的是 agent 規模化之後的基礎設施問題，而不是 agent 本身的智慧。如果你的專案只有三五個 agent，而且彼此獨立，那麼引入一個控制平面只是增加複雜度，直接用 Python async 或簡單的佇列就夠了。但如果你預期單一請求會 fan-out 到數百或數千個子 agent，而且你需要內建的重試與追蹤，AgentField 的模型就值得認真考慮。它最吸引人的地方是開發體驗：從 spec 到可 curl 的 REST 端點，中間的基礎設施程式碼幾乎為零。但這個便利建立在一個尚未穩定的 rc 版本上，而且 installer 的行為（例如 launchd 註冊）需要你花時間理解。採用前，先做一個小規模的概念驗證：用 /agentfield 產生一個簡單的 agent，確認 af service stop 能正確停止控制平面，然後用 af service status 檢查健康狀態。接著測試一個會 fan-out 的遞迴 agent，看看控制平面在佇列與重試上的表現是否符合 README 的描述。最後，檢查你使用的 model provider（例如 anthropic/claude-sonnet-4-20250514）是否支援，因為 AI config 直接指定 model 字串，如果 provider 不相容，整個流程會卡在第一步。AgentField 不是一個可以「裝了就忘」的工具，它需要你把它當作基礎設施來維運，而這正是它想取代的工作。

編輯結論

AgentField 適合已經用 Claude Code、Codex 或 Gemini CLI 等工具開發 agent，卻卡在部署與擴充的團隊。它把 agent 變成 REST 端點，由控制平面處理 fan-out、佇列與重試，省去自己接 broker 的功夫。但這套抽象有代價：你必須接受 agent 邏輯綁在它的 SDK 與呼叫模式上，而且目前版本仍停留在 release candidate（v0.1.138-rc.16），README 也明確警告「plain kill」會被視為 crash 而自動重啟，這代表服務管理行為需要額外理解。不建議以下團隊採用：需要完全控制底層佇列與基礎設施的團隊、agent 數量小且不需要 fan-out 的團隊，或者不能接受將 agent 邏輯寫成平台特定函式的團隊。採用前應先驗證三件事：第一，用 /agentfield 產生的 Docker Compose stack 是否能在你的網路環境下正常啟動；第二，Python 或 Go SDK 是否支援你目前使用的 model provider，例如 Anthropic 或 OpenAI；第三，控制平面的 launchd 註冊與 menu-bar 圖示在無頭伺服器上是否會造成干擾。AgentField 的價值在於把 agent 從「程式」提升到「服務」，但這也意味著你必須把它當作基礎設施來維護，而不是一支可以隨便丟掉的腳本。

官方來源

1. Agent-Field/agentfield on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases