MCP agent stack 怎么搭：Goose、Mastra、Smithery 分别放哪

先别把 MCP 当成“装得越多越强”

最近很多人开始把 MCP 接进 AI 编程或 agent workflow，但第一轮最容易踩的坑，不是不会装，而是：

• 本地执行工具和远程 server 混在一起
• 编排层和执行层没有分清
• 每次多接一个能力，稳定性就往下掉一点

所以更稳的做法，不是先追“我能接多少个 server”，而是先把 3 个位置拆开。

这篇更适合谁

• 已经在用 Codex、Claude Code、OpenHands 或 Goose 一类工具
• 想把搜索、文档、浏览器、内部 API 接进 agent workflow
• 发现 MCP 越接越多，但流程越来越难控

先把 3 个位置分清

1. Goose 更像执行工作台

如果你想让 agent 真正在本地工程和终端里做事，Goose 更像主执行位。

它适合：

• 在本地仓库里改代码、跑命令、读文件
• 让 agent 带着 MCP 能力继续推进任务
• 需要保留开发者对执行过程的控制感

如果你现在卡的是“AI 能不能在真实工程里继续往前做”，先看 Goose。

2. Mastra 更像 workflow 和工程层

Mastra 适合解决另一个问题：不是“单次任务能不能跑”，而是“这个 agent workflow 能不能做成长期可维护的工程资产”。

它更适合：

• 把 agent、memory、evals 和 workflow 放进同一套 TypeScript 工程
• 让不同步骤有明确输入输出
• 后面还想接监控、调试和团队协作

如果你已经不是在玩 demo，而是准备把 AI 流程写进正式项目，Mastra 更值得先补。

3. Smithery 更像 MCP 基础设施层

Smithery 解决的不是 agent 本身，而是 MCP server 的发现、连接和分发问题。

它更适合：

• 你已经开始接不止一个 MCP server
• 团队里不只一个人要复用这些连接
• 你不想每次都手工维护一堆 server 配置

如果你现在的问题是“能力来源越来越多，管理越来越乱”，Smithery 更像该补的位置。

一个更稳的最小搭法

如果你今天就想开始，先按这个顺序搭：

• 先用 Goose 跑通一个真实任务
• 再用 Mastra 把任务拆成可复用 workflow
• 最后再用 Smithery 管理你准备长期复用的 MCP server

这个顺序的好处是，你先验证任务真的值得做，再决定哪些能力需要进入长期基础设施。

哪些情况先别急着上整套 stack

• 你现在还没有一个高频重复任务
• 你连主执行工具都没固定下来
• 你还在一边试工具，一边换模型，一边改流程

这时候先把主工作台定下来，比一口气接十几个 MCP server 更重要。

最后怎么判断自己该先补哪一层

• 如果你缺的是“让 agent 在本地继续做事”，先补 Goose。
• 如果你缺的是“把流程写成长期工程”，先补 Mastra。
• 如果你缺的是“统一管理和分发 MCP 能力”，先补 Smithery。

别先问哪个最强，先看你当前卡的是执行、编排，还是基础设施。