Agno 於 2026 年 10 月 29 日發布 v3.1.12，GitHub 累積 4.3 萬星、6,213 次分叉與 621 位貢獻者。專案定位為自駕代理平台，把代理從一次性腳本推進到可長期運行的服務層，內建 API、MCP、持久執行、人工審批與排程。
Agno 是什麼？
它是開源的代理平台，負責代理外圍的編排與服務層。AgentOS 提供 API、MCP、持久執行、人工審批與排程，資料留在自家雲端。
專案倉庫建立於 2022 年 5 月，PyPI 上的 agno 套件首個版本於 2024 年 12 月 24 日上線，至今累計 277 個版本。目前的版本線由 8 月 24 日的 v3.0.0 起步，10 月 29 日的 v3.1.12 為最新發布。
README 把能力切成三層。第一層是建置，開發者可用 Agno、Claude Agent 或 Codex 三種 SDK 描述代理，再組合成團隊與工作流。第二層是運行，AgentOS 接管認證、角色權限、續跑與重播、人工審批、排程與持久執行。第三層是營運，Company OS 讓代理擁有職責，把工作拆成產品、專案、任務與週期性常規。
Agno 3.0 的架構改動帶來什麼影響？
v3.0.0 於 8 月 24 日發布，屬破壞性更新，升級前必須先完成資料庫遷移。運行改為獨立資料列，會話寫入放大由 O(N²) 降至 O(N)。
舊架構把整段會話存成單一文件，每次追加訊息都要重寫全部內容。會話越長，寫入成本越接近平方增長，雲端資料庫的單項大小上限亦成為硬天花板。v3.0 把運行拆成獨立資料列，欄位包含 session_id、run_type、agent_id、status 與 parent_run_id。
相容性由讀取層吸收。官方說明 session.get_messages()、get_chat_history()、db.get_session() 與 AgentOS 的會話路由簽名不變，運行資料在讀取時重新掛回。開發者亦可直接用 db.get_run()、db.get_runs() 與 db.delete_runs() 等新介面操作單次運行。
同一個版本還加入工具結果外置。當工具回傳超過 16,000 字元，內容寫入 AgentFS，訊息中只留預覽、大小與 result_id，代理需要時再以 read_result 或 search_result 取回。較大的圖片與檔案可改存 S3 或 GCS，一則 113 KB 的 JPEG 由約 151,000 字元降至 2,897 字元。
AgentOS 如何把代理變成可長期運行的服務？
它以持久佇列保存背景任務，重啟後可接回原本執行點並追蹤狀態。平台同時提供認證、角色權限、逐使用者資料隔離與排程。
持久執行是分水嶺。一般框架在行程結束時失去執行中的任務，AgentOS 把背景任務寫入資料庫，並在重啟後接回原本的執行點，狀態可查。這讓代理能處理跨越數分鐘甚至數小時的工作，例如批次分析、長流程審批與定期維運。
存取邊界由平台統一處理。README 列出的安全能力包含認證、角色為基礎的存取控制，以及每位使用者的資料隔離。代理對外只暴露兩條通道：產品端走 REST API，Claude 與 ChatGPT 端走 MCP，Slack 等聊天應用則透過 Agno Interfaces 接入。
營運結構由 Company OS 承擔。開發者可替代理定義職責，把工作組織成產品、專案、任務與週期性常規，人員負責設定方向與覆核結果。v3.1.12 新增 Routine(enabled=False)，讓範本預先附帶未啟用的常規，由使用者在介面上自行開啟。
為什麼 Claude 與 Codex 的權限請求要交給 AgentOS 處理？
v3.1.12 把 Claude 與 Codex 自身的權限請求接入 AgentOS 審批介面，代理被攔下時寫成一筆暫停運行，核准後從同一執行點續跑，不重播提示詞。
過去的做法是在框架層另設一套審批。問題在於權限判斷發生在代理執行環境內部，框架看不到它為何停頓，只能整段重跑。v3.1.12 改為讓兩個代理執行環境的原生請求直接落到 AgentOS，審批決策再送回原本的執行。
設計上有幾處值得注意。決策會對照實際請求的動作逐項驗證，支援同步與非同步續跑、取消、逾時與儲存失敗的處理。沙箱中的代理在 Docker 與 AgentCore 之間移動時仍保留這條審批鏈，包括能力協商、決策傳遞、持久化與 API 工作行程遺失後的重接。
預設行為亦隨之改變。沒有設定審批參數的 CodexAgent 現在走原生 on-request 政策，先前無人處理的請求會轉為暫停，並由 hitl_timeout 在預設 900 秒後收束。
4.3 萬星背後的成長路徑是什麼？
專案自 2022 年建立，套件於 2024 年 12 月上線，累積 277 個版本。最新三版間隔二至四日，10 月 31 日仍有提交，屬長期維護型專案。
發版節奏是這個專案最明顯的特徵。最新三個版本分別落在 10 月 23 日、10 月 27 日與 10 月 29 日，間隔二至四日。每次發布都附帶完整變更說明，逐項對應合併請求編號與貢獻者。
貢獻者規模達 621 人。v3.1.12 的變更清單同時出現核心維護者與首次提交者，包含知識庫分塊選項隔離、評估器預設模型替換與圖表標題數值等修正，屬於長期維護型專案的典型樣貌。
題材熱度亦有外部支撐。代理框架在 2026 年成為企業導入生成式人工智慧的主要形式，主流選擇集中在 LangGraph、CrewAI、AutoGen 與 OpenAI Agents SDK。Agno 的差異在於把服務層一併交付，而不只提供編排語法。
開發者如何快速開始？
安裝只需執行 pip install agno，需求 Python 3.9 以上。官方建議由範本起步，複製 agentos-railway 後依技能指引啟動平台與首個代理。
官方把入門流程改寫成給編碼代理的提示詞。開發者把一段指令交給 Claude 或 Codex，代理便會複製範本倉庫、執行安裝技能，並在本機跑起 API 伺服器、MCP 伺服器與 PostgreSQL 儲存。
部署範本覆蓋九種環境，包含 Docker、Railway、AWS、GCP、Azure、Fly.io、Render、Modal 與 Helm。這種做法把環境差異留在範本層，核心套件不需為每朵雲各自分叉。
設定頁與營運介面集中在 os.agno.com。平台啟動後連接該站，即可檢視對話、追蹤、知識庫與代理活動，並以無程式碼介面或與 OS Manager 對話的方式調整代理。
專案的關鍵數據有哪些？
截至 2026 年 10 月 31 日，專案累積 42,987 星、6,213 次分叉、621 位貢獻者，主要語言為 Python，採 Apache 2.0 授權，共 277 個版本。
以下數據取自 2026 年 10 月 31 日的倉庫狀態與 v3.1.12 發布說明，供評估參考。
議題數量偏高，反映使用面廣泛而非單純積壓。1,959 個開啟議題中，相當比例屬功能請求與整合問題，與 621 位貢獻者的提交節奏並存。
同類框架有何分別？
LangGraph 偏重狀態圖編排，CrewAI 偏重角色分工，OpenAI Agents SDK 貼近單一供應商。Agno 把編排與服務層一起交付，代價是概念數量較多。
選擇框架時，真正的差異通常在代理寫成之後。若團隊只需要在工作流中串接幾次模型呼叫，輕量編排層更合適；若代理要成為產品的一部分，需要認證、審批、續跑與稽核，平台層的價值才會顯現。
多供應商支援是另一個分野。Agno 的模型層同時接受多家供應商與本地端點，v3.1.12 的修正清單即包含把評估器預設判官由已於 10 月 23 日下線的 o4-mini 換成 gpt-5.6-terra 這類供應商退役連動。
程式碼組織方式亦有取捨。v3.0 引入的 CodeMode 把寬廣的工具結構換成一個可持續的 Python 核心，模型以程式碼組合工具呼叫，減少逐次往返。這種做法降低上下文消耗，但要求模型具備穩定的程式碼生成能力。
有哪些實際限制與風險？
v3.0 屬破壞性更新，升級須先跑資料庫遷移，舊版無法直接回退。每個代理預設送出一筆遙測事件，可設 AGNO_TELEMETRY=false 關閉。
遷移是第一道門檻。官方在 v3.0.0 說明中明言需要先讀遷移指南再上線，運行資料表結構改變意味著舊版無法直接回退。對已進入生產的團隊，這件事需要排入維護窗口。
遙測屬第二項需要留意的設定。每個代理實例會送出一筆事件，用於判斷供應商優先順序，官方說明提示詞、訊息與輸出不會傳送。在意資料流向的環境應在部署階段即關閉。
架構複雜度是第三項。API、MCP、持久佇列、Company OS 與九種部署範本構成完整平台，同時也把學習曲線拉高。小團隊若只取其中一層，容易覺得負擔過重。
常見問題有哪些？
平台可自架於自家雲端，資料不出環境；支援多家模型與 MCP，並提供 REST API 與 Slack 介面。Apache 2.0 授權允許商用。
問：Agno 是否必須使用官方託管服務？
不需要。平台可部署在自己的雲端，官方提供 Docker、Railway、AWS、GCP、Azure、Fly.io、Render、Modal 與 Helm 九種範本。os.agno.com 屬營運介面，連接自架平台後即可使用。
問：既有代理程式碼需要改寫嗎？
需要部分調整。v3.0 的資料表結構與部分參數簽名改變，官方提供遷移指南與 v3 變更清單。以 v2 建立的會話資料在遷移後可繼續讀取，運行資料則改由新表承載。
問：代理可以接哪一些模型？
模型層支援多家供應商與本地端點，README 的教學與 cookbook 目錄涵蓋 OpenAI、Anthropic、Google 與開源模型路線。若要指定思考強度或工具呼叫格式，各供應商的設定仍在模型類別中處理。
問：如何把代理接進既有產品？
三條路徑並存。產品端以 REST API 呼叫，Claude 與 ChatGPT 端以 MCP 伺服器接入，Slack 等聊天應用透過 Agno Interfaces。三者共用同一套認證與權限模型。
問：團隊規模多大才值得採用？
若代理只是內部試作，輕量框架已足夠。當代理需要跨重啟續跑、需要人工審批高風險動作，或需要逐使用者的資料隔離與稽核紀錄，平台層帶來的節省通常大於學習成本。
總結：Agno 適合什麼團隊？
需要把代理長期運行、且有審批與稽核要求的團隊值得評估。純研究或一次性腳本未必需要平台層，v3.0 的資料表改動亦要求持續跟版。
這個專案回答的是一個被多數框架略過的問題：代理寫好之後，誰負責它在半夜三點的狀態。AgentOS 把續跑、審批、排程與權限收進平台，代理因此可以像一般服務一樣被部署與維運。
代價是相依範圍擴大。資料庫結構、部署範本、審批政策與版本升級都成為日常維護的一部分，團隊需要有人持續跟進每兩日一輪的發布。對於把代理視為產品核心的團隊，這筆成本換來的是可預期的運行行為。
若只是驗證想法，先以輕量框架跑通流程更實際。等到代理需要面對真實使用者、需要留下審批紀錄、需要在重啟後接回工作，平台層的價值才會具體顯現。
出處連結有哪些？
主要來源為 GitHub 倉庫與 v3.1.12 發布說明，數據截至 2026 年 10 月 31 日。官方文件站 docs.agno.com 提供完整指南。
- 專案倉庫：agno-agi/agno
- 官方文件：docs.agno.com
- 版本說明：Agno v3.1.12
- 遷移指南：v3 Migration Guide
