Agent Framework Selection
Agent Framework Selection 指自建 agent 時，先決定要從「全套 Deep Agent」改起，還是從基礎元件自己組裝。AIHAO 駕馭工程第 9 篇用六項 Deep Agent 能力作為對照：Plan & Todos、Filesystem & Bash、Sub-Agent、Memory、Skills、以及 MCP / Browser / Computer Use 等工具，判斷框架已內建多少能力、哪些必須自己接。
兩條路線
全套 Deep Agent 路線適合先跑起來再客製：Codex SDK / App Server、GitHub Copilot SDK、Claude Agent SDK、LangChain deepagents 這類工具通常內建規劃、檔案操作、子代理、skills 或 MCP，並附帶原廠調校過的 system / developer prompt 與 agent loop。優點是少寫很多 harness；代價是要接受其預設行為、授權與核心可見度限制。
基礎構建路線適合需要完整控制流、企業整合或特殊任務分布：Strands Agents、Google ADK、Microsoft Agent Framework、OpenAI Agents SDK、Pydantic AI、LangGraph、Vercel AI SDK 等工具多半提供 agent、tool、handoff、workflow、session、graph、typed output 或 UI streaming 元件，但不會自動幫你完成全部 Deep Agent 行為。優點是可控；代價是要自己設計 harness-engineering-for-ai-coding 的 loop、prompt、memory 與驗收。
選型判斷
這篇文章把選型重點從「哪個框架最熱門」改成四個問題：
- 任務需要多少 Deep Agent 能力？ 如果只是工具調用或單一流程，從基礎框架開始；如果需要規劃、檔案、子代理、skills 與長任務迭代，Deep Agent 起手較省。
- 核心 loop 是否要可讀可改？ Codex 與 LangChain deepagents 的核心較可見；Claude Agent SDK、GitHub Copilot SDK 則是外層套件開源、核心 agent runtime 閉源。
- 部署、授權與資料流是否卡住？ 帳號登入、API key、商業條款、雲端綁定、語言支援與模型輸出是否可進入內部訓練資料，都會直接影響 production 可用性。
- 任務分布是否穩定？ 若任務還沒被 eval 定義清楚，先用最少元件跑通；只有當 model-harness-fit 或框架限制反覆出現，再升級到更完整的 Deep Agent 或 orchestration stack。
對 AI Ark 的用法
對 loop-engineering 來說，這篇補上一條 Ponytail 式停損線：不要因為市場上有很多 agent framework，就先建抽象層。先固定來源、queue、raw capture、derived page 與 verify gate；當實際 watch / ingest / verify 任務反覆需要多代理、長期記憶、parallel workflow 或跨語言 SDK，再選框架。
對 model-harness-fit 來說，framework selection 是 workflow 層的決策，而不是模型能力排名。原廠 Deep Agent 可能贏在內層 tool loop 和 post-training 貼合；自建基礎框架可能贏在任務分布、企業系統與驗收流程。選型應以任務級 eval 和 trace 觀察為準，而不是只看宣傳清單。
BusinessNext 對 Meta 禁用 Claude Code / Codex 的報導補上一條企業紅線：若外部 coding agent 的輸出會被複製進程式庫、文件或合成資料，再回流到自家模型訓練，framework selection 就同時是模型蒸餾、IP 與資料污染決策。這類高風險團隊可先用內部模型／內部工具或隔離區處理敏感 repo，再把外部 agent 限定在低敏感、不可回訓的任務。
Sakana Fugu 補上第三條路線：把 orchestration 當成 model provider 的能力購買。這種 model-interface 路線讓既有 OpenAI-compatible client 直接取得 multi-agent / multi-model 協調能力，不必自建 roles、handoff 或 workflow graph；代價是底層 routing 不透明，trace 與 intermediate artifacts 較難審計。若任務需要內部工具、嚴格 sandbox、可重播驗收或資料不能進入外部模型池，仍應維持自建 harness / framework。
AIHAO 對 Marc Andreessen 訪談的整理補上第四條、更懶的路線：Unix-style agent architecture。如果任務可以用 LLM、shell、檔案系統、Markdown 與 cron 組成，就先把狀態寫進可讀檔案、讓 CLI 成為工具介面，再用 agent-trace-observability 與 eval 判斷是否真的需要 MCP server、multi-agent framework 或 provider orchestration。這條路線的限制是權限、金流、敏感資料與高併發場景仍要補 agent-sandbox-architecture 與審計。