Arcee 開源 nac：讓 AI Agent 長時間工作不忘目標，多模型服務同步上線
Arcee 開源 nac，讓 AI Agent 透過 threads、episodes 與平行 worker 接續長任務。本文整理架構、模型費用、安裝與現階段風險。
AI Agent 做短任務時，讀幾個檔案、修改程式再跑測試，通常能在一次對話內完成。任務拉長到數小時甚至數天後，問題就不只是模型夠不夠聰明，而是它還記不記得最初目標、哪些工作已經完成，以及前面做過哪些重要決定。
Arcee AI 在 2026 年 8 月 13 日開源 nac。它是一套給長任務使用的 Agent harness，也就是包在 AI 模型外面，負責拆解工作、分派執行、保存進度與控制工具的執行框架。Arcee 同日也推出擴充版 Open Models API beta。API 是讓程式用固定格式呼叫模型服務的介面，因此 nac 能透過它使用多款開放權重模型。
先說結論：nac 值得有複雜工程任務的開發團隊測試，但它不是讓所有 AI 工作自動變好的捷徑。單一、明確、一次能做完的任務，直接使用 Codex 或 Claude Code 通常更快；只有工作能拆成多條長期工作流時，nac 增加的管理層才開始有價值。
Arcee nac 是什麼？它不是新模型
AI 模型負責理解指令、推理與產生下一步，nac 負責決定模型何時工作、能使用哪些工具，以及哪些狀態應該留下來。兩者的關係比較像「工作者」與「專案管理系統」，所以換上 nac 不代表底層模型本身變得更聰明。
Arcee 官方技術文章把 nac 定位為長任務的開源 Agent harness，內部用於實驗、模型訓練監督、基礎設施與快速原型。原始碼採 Apache 2.0 License，開發者可在符合授權條件下修改與商用。
這裡也要分清楚「開源」與「免費」。nac 的程式碼可以自行取得，但只要它呼叫雲端模型 API，仍會產生模型費用。若任務會派出多個 worker 平行處理，模型呼叫量也可能比單一 Agent 更高。
為什麼長任務容易讓 AI Agent 偏離原始需求？
一般 Agent 常把使用者需求、讀檔結果、指令輸出、失敗紀錄與修改過程都堆在同一段對話。內容愈來愈長後，系統可能需要壓縮早期紀錄，模型也更難從大量細節中找到真正重要的限制。
nac 的核心做法，是把「完成眼前動作需要的暫時內容」與「下次繼續工作需要的持久狀態」分開。執行過程中的套件安裝重試或無關輸出可以捨棄，完成了什麼、產生哪些檔案、下一步要注意什麼，則被整理成可延續的紀錄。
這個方向合理，因為長任務真正缺的通常不是更大的對話框，而是更清楚的狀態管理。不過整理內容仍由模型產生，重要細節是否真的被保留下來，依舊需要驗收機制，而不是只相信系統有「記憶」。
nac 如何運作？先理解 Orchestrator、Thread 與 Episode
nac 把長任務拆成三個主要角色。Orchestrator 是中央協調者，只負責理解目標、規劃與分派工作，不能直接執行指令或修改檔案。真正操作環境的是 worker，而 thread 與 episode 則負責保存可延續的工作狀態。
| 元件 | 白話功能 | 對長任務的作用 |
|---|---|---|
| Orchestrator | 專案協調者 | 拆解任務、安排順序與決定下一步，但不直接改檔 |
| Worker | 執行者 | 在新的模型上下文中讀檔、執行指令與完成一項明確工作 |
| Thread | 一條持續工作線 | 保存同一類工作的 episode 歷史，例如前端、測試或效能分析 |
| Episode | 一次工作交接摘要 | 記錄完成內容、結果、檔案與後續注意事項 |
每次 Orchestrator 分派工作時，nac 會啟動新的 worker。Worker 完成後，詳細執行上下文會被捨棄，只留下對環境的修改與一份 episode。下次要繼續同一條 thread，新的 worker 會讀取過去 episodes，再接著工作。
Arcee 展示 nac 用於製作發布影片動態圖像的部分長任務 Session。 影片來源：Arcee AI 官方部落格。
這種設計的取捨很清楚。優點是新 worker 不必背著所有舊工具輸出，能把模型注意力留給目前任務。風險則是 episode 如果漏掉關鍵決定，後續 worker 不會自動看到已被捨棄的完整過程。因此，原始需求、權限限制與完成條件最好另外寫進專案規格，而不是只存在某次對話裡。
Thread weaving 與平行執行有什麼用？
nac 可以把其他 thread 最新的 episode 提供給新的 worker，官方稱為 thread weaving。假設一條 thread 已完成 API 規格，另一條正在開發前端，Orchestrator 可以把 API 的最新交接內容送進前端 worker，不必複製整段後端執行紀錄。
同一批工作也能建立依賴關係。沒有互相依賴的 worker 可以同時執行，需要前置結果的工作則會等待來源 thread 完成。nac 會先檢查依賴圖是否形成循環，再開始執行。
對大型重構、研究重現或多模組開發來說，這能縮短等待時間，也讓每條工作線保有自己的歷史。反過來說，如果任務只有改一個按鈕或修一個函式，還要經過 Orchestrator 分派，反而增加模型呼叫與溝通成本。Arcee 官方也明確指出，能在單次 Coding Agent 工作中完成的任務，直接處理通常更簡單。
nac 可以接哪些模型與工具？
nac GitHub目前提供三類登入方式：Arcee 裝置登入、ChatGPT 帳號的 Codex OAuth，以及 OpenAI、Anthropic、DeepSeek、Together 等供應商的 API key。API key 是讓程式獲准呼叫外部模型服務的驗證字串。
nac 也能讀取專案中的 AGENTS.md 與 Skills。AGENTS.md 用來保存專案規則，Skills 則是可重複使用的工作流程與指令。Orchestrator 可以在分派 worker 時預先載入特定 Skill，讓不同工作使用各自需要的規範。
若要限制工具執行範圍，nac 支援透過 Podman 建立 Sandbox。Sandbox 是把 Agent 指令隔離在受控環境中的做法，可降低誤改主機其他檔案的風險。它不是自動安全保證，因為掛載目錄、網路、憑證與 worker 權限仍要由使用者設定。
Arcee 官方 nac 發布影片，說明長任務、多工作流與模型選擇的產品定位。 影片來源：Arcee AI 官方部落格。
Arcee Open Models API beta 有哪些模型？價格多少？
Arcee 與 nac 同日推出擴充版 Open Models API beta。它不再只提供 Trinity 系列，也加入 DeepSeek、GLM、Kimi 與 Thinking Machines 的模型。
以下是官方頁面在 2026 年 8 月 14 日顯示的價格，單位為每 100 萬 tokens 的美元價格。Token 是模型計算文字用量的基本單位，輸入與輸出會分開計費。
| 模型 | 輸入價格 | 輸出價格 |
|---|---|---|
| DeepSeek V4 Flash Latest | US$0.14 | US$0.28 |
| Trinity Large Thinking | US$0.25 | US$0.80 |
| Inkling Small | US$0.50 | US$1.20 |
| DeepSeek V4 Pro Preview | US$1.74 | US$3.48 |
| GLM 5.2 | US$1.40 | US$4.40 |
| Kimi K3 | US$3.00 | US$15.00 |
模型選擇變多的實際好處，是團隊能依任務調整成本與能力，不必所有工作都使用最貴的模型。只是「模型更多」不等於系統會自動選到最佳方案。官方尚未在這次公告中公布 nac 搭配各模型的長任務成功率、成本比較或獨立 Benchmark，因此目前比較適合自行用固定任務做 A／B 測試。
nac 怎麼安裝？
官方提供一行安裝指令：
curl -fsSL https://raw.githubusercontent.com/arcee-ai/nac/main/scripts/install.sh | sh
安裝程式會把 nac-web 放進 $HOME/.local/bin。接著在專案目錄執行：
nac-web
預設介面會開在 http://127.0.0.1:3210。開始 Session 前，還要選擇 Arcee 登入、Codex OAuth 或模型供應商 API key。
這種把遠端腳本直接交給 shell 執行的方式很快，但也代表腳本會取得目前帳號的執行權限。較穩妥的做法，是先下載並閱讀腳本，再於可還原的測試專案安裝。官方在發布當天已從 v0.1.0 更新到修正安裝程式的 v0.1.1，也說明目前仍是很早期的版本。
現階段使用 nac，要注意哪些風險？
第一個風險是狀態可能不一致。官方說明 worker 失敗不是交易式操作，也就是 worker 如果已經修改環境，卻在產生 episode 前中斷，檔案可能已改變，持久紀錄卻還停在舊狀態。正式流程需要搭配 Git、測試與變更檢查，不能把 episode 當成唯一真相。
第二個風險是遠端存取。nac HTTP API 文件明確指出，API 本身沒有用戶端驗證。預設綁在本機 127.0.0.1 較安全；若開到區域網路或遠端環境，應放在具有身分驗證與加密的代理或私人網路後方，不能直接綁定所有網路介面。
第三個風險是成本與權限會一起放大。平行 worker 能加快工作，卻也可能同時消耗更多 tokens、呼叫外部服務與修改檔案。任務說明應先寫清楚預算、可用工具、禁止操作與驗收條件，並把正式資料與密鑰移出 Agent 不需要接觸的範圍。
這些限制讓我的判斷維持在中性偏多。nac 的架構確實對準長任務的狀態問題，但首版剛發布，還缺少足夠的正式環境案例。把它當成可研究的新型 Agent runtime 很合理，把它當成已驗證的全自動工程團隊則太早。
哪些人適合使用 nac？
nac 較適合可以拆解、會持續多輪，而且有明確完成條件的工作，例如大型程式庫移植、研究論文重現、跨模組功能開發、平行 Code Review，以及需要反覆訓練與評估的實驗。
如果只是一次性的內容整理、小型 Bug 修正或明確的單檔修改，直接交給一個 Coding Agent 通常更省時間。對沒有命令列、Git 與 API 成本管理經驗的一般使用者，nac 目前也不是「裝好就能放心放著跑」的工具。
最實際的導入方式，是先挑一個可還原、結果容易驗證的內部任務做 POC。記錄單一 Agent 與 nac 各自花費的時間、tokens、人工介入次數與最終測試結果，再決定這層 Orchestrator 是否真的降低管理成本。
FAQ
nac 是 AI 模型嗎？
不是。nac 是管理 AI 模型、工具、worker 與工作狀態的 Agent harness。實際推理仍由 Trinity、DeepSeek、OpenAI、Anthropic 或其他接入的模型完成。
nac 是免費的嗎？
nac 原始碼採 Apache 2.0 License，可以自行下載與修改。呼叫外部模型 API、使用雲端運算或其他付費工具時，仍會依供應商規則產生費用。
nac 能取代 Codex 或 Claude Code 嗎？
兩者解決的層級不同。Codex 或 Claude Code 可以成為實際執行工作的 Agent，nac 則偏向把多次、長時間的 Agent 工作組織成持續工作流。短任務不一定需要 nac。
nac 適合直接用在正式環境嗎？
目前更適合 POC。它在 2026 年 8 月 13 日才發布 v0.1.x，官方文件也揭露 worker 失敗可能留下未記錄的環境變更，遠端 HTTP API 本身沒有用戶端驗證。正式採用前應補上隔離、版本控制、驗收與存取保護。
結論：nac 的重點不是更多 Agent，而是讓工作能被接續
nac 最值得注意的地方，不是一次叫出多少 worker，而是把長任務改寫成多條能保存狀態、互相交換結果的工作流。這能降低單一對話愈跑愈長的壓力，也讓平行工作有更明確的同步點。
現階段我會把 nac 放進開發團隊的實驗清單，不會直接放進正式流程。若後續能證明它在相同預算下，提高長任務成功率、減少人工重新說明需求的次數，這套 thread-and-episode 架構才算從合理設計走到實際生產力。
