Mastra 值得看的原因很簡單：它把 AI agent 從「一段會呼叫工具的程式」拉回 TypeScript 工程師熟悉的應用框架語境。官方定位是 TypeScript AI framework，核心能力包含 agents、workflows、memory、RAG、tools、evals、observability，底層也能接 Vercel AI SDK 的 provider 生態。它不是只負責包 prompt 的小工具，而是想當 AI 應用後端骨架。

但採用前，先別被「batteries included」迷惑。它真正解的是工程組織問題：agent 放哪裡、工具怎麼定義、工作流如何串、記憶和追蹤怎麼留、品質評估怎麼接進開發流程。如果團隊本來就是 Next.js、Hono、Express、Fastify 或 NestJS 這類 TypeScript stack，Mastra 的吸引力會很高。

適合導入的第一種場景，是產品已經確定需要多步驟 AI 流程。例如客服分流、內部知識助理、內容審稿、銷售研究，這些任務通常不是單次 completion，而是查資料、判斷、呼叫工具、保留狀態、產生可追蹤輸出。這時候用 Mastra 統一 agent、workflow 和 observability，比在各處散落 SDK 呼叫更容易維護。

第二種適合，是想把 evals 早點變成日常的人。很多 AI 專案失敗不是模型太爛，而是團隊不知道「這版比上一版好在哪」。Mastra 把 evals 放進框架敘事裡，提醒你別再每次靠 PM 或工程師肉眼試聊。

不適合的情況也明確。第一，如果你只有簡單聊天框、摘要功能或分類 API，直接用 provider SDK 或 Vercel AI SDK 就好。Mastra 會帶來框架心智負擔，太早導入反而讓需求驗證變慢。第二，如果核心在資料管線、批次任務或嚴格狀態機，Temporal、queue、cron、後端 service 可能比 agent framework 更對題。第三，如果團隊還沒想清楚工具權限、資料邊界與失敗補救，上 Mastra 也只是把風險包裝得比較像系統。

我的判斷是：Mastra 是 TypeScript 團隊把 AI 功能產品化時值得試點的框架，不是每個 AI demo 的預設起手式。採用時不要問「它能不能做 agent」，而要問「我們是不是已經需要一個可部署、可觀測、可評估的 AI 應用骨架」。答案是肯定時，從一條高價值 workflow 切入；答案是否，就先保持小而直。