Goose：原生支持 MCP、在你机器上运行、能与任何带服务器的服务对话的 AI 代理

👁️ — 次浏览

Goose 是一款采用 Apache-2.0 许可的通用型 AI 代理（CLI、桌面、API），在你自己的机器上运行。新能力来自 Model Context Protocol 扩展，而非封闭的插件商店；其治理权现已归属于 Linux 基金会。

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

它是什么

Goose 是一款通用型、在本机运行的 AI 代理，以 CLI、原生桌面应用，以及可嵌入的 API 三种形态提供。它不只是自动完成或一个聊天框：它会运行 shell 命令、编辑文件、执行代码，并朝着你用自然语言给定的目标串起多步骤工作流程。其仓库上的一行标语是：「your native open source AI agent — desktop app, CLI, and API — for code, workflows, and everything in between.」

本项目以 Apache-2.0 许可开源，主要以 Rust 编写。它始于 Block（Square／Cash App 的母公司），代号为「goose」，但在一项值得注意的治理动作中，它后来已迁移至 Linux 基金会旗下的 Agentic AI Foundation（AAIF） —— 正式仓库现位于 aaif-goose/goose。撰文当下，该 GitHub 仓库约有 48,100 颗星，而最新版本 v1.37.0 的日期为 2026 年 6 月 3 日 —— 就在我查看的前几天，所以这是一个活跃、快速演进中的项目。它连接广泛的模型供应商（Anthropic、OpenAI、Google、Ollama、OpenRouter、Bedrock 等），而不会把你绑死在单一厂商。

这套架构为何有趣

它最关键的押注是：能力应该来自一个开放协议，而非专有的插件目录。Goose 是 Model Context Protocol（MCP）—— 用来把工具与数据暴露给代理的开放标准 —— 最早期、也最深入的采用者之一。其仓库宣称可通过 MCP 连接 70 多个扩展，而其后果影响甚大：任何提供 MCP 服务器的服务 —— GitHub、Jira、Slack、一个数据库、一个监控仪表盘 —— 都能被 Goose 使用，而维护者无须为每一个分别编写量身打造的集成。代理触及的范围会随着生态系成长而成长，而非受限于某一家公司的路线图。

第二个结构性选择是治理。把项目移交给一个中立的基金会，意味着它的方向不再受制于单一厂商的商业优先级 —— 如果你打算把基础设施押注在某个代理上，这是一个实在的考量。比较这两种姿态：

诚实的解读：让 Goose 强大的那份开放性，同时也扩大了它的波及范围。一个会运行 shell 命令、并连接任意第三方 MCP 服务器的代理，能触及的东西相当多，这正是为何信任边界值得深思。

安装与运行

项目自己的网站与 README 上所列的安装命令，是一段把 CLI 通过 curl 引导安装的 bash：

# install the goose CLI (verbatim from goose-docs.ai / the repo README)
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# then configure a provider + model and start a session
goose configure
goose session

一如所有的 curl | bash 安装器，若你有任何不确定，在把它导入 shell 之前先读一读脚本 —— 它是从项目的 GitHub releases 抓取的，但这个习惯值得保持。

实务笔记

我实际上会这么做：先用一组刻意精简的 MCP 扩展把 Goose 架起来，而不是一口气装上整个目录。让人忍不住在第一天就把所有东西都接上去 —— GitHub、Slack、你的数据库、你的云端。我反而会先在一个可抛弃的分支上，从内置的 developer（shell + 文件编辑）扩展开始，观察代理如何规划与行动，唯有等我搞懂某个远程 MCP 服务器需要哪些凭证与权限范围后，才把它加进来。你每启用一个扩展，就是新增一片攻击面，以及一组新的密钥放进你的环境；对待「加一个 MCP 服务器」要像对待新增一个依赖包一样谨慎。可中断的会话在此有帮助 —— 前几次运行时请把手放在方向盘上，而不是让它对任何要紧的东西放任自跑。

我会特别在一项任务横跨多个工具、而不只是文件时，动用这类代理：复现一次 CI 失败、查询一个真实的数据存储、开出 PR、在某个频道发个通知。这种跨工具的触及范围，正是 MCP 模型胜过纯编辑代码代理之处。

被忽略的角度

标题是「开放的代理」，但更安静、影响也更深远的转变在于：锁定效应被搬到了哪里。借由把代理与任何单一模型厂商、以及任何单一插件商店解耦，Goose 与其说消除了依赖风险，不如说把它重新安置到了 MCP 生态系本身 —— 那些服务器、它们的验证模型，以及它们的维护健康度。一个把工作流程构建在十几个第三方 MCP 服务器之上的团队，是用厂商锁定换来了一种弥散的供应链依赖：每个服务器都是别人发布的代码，有自己的更新节奏、安全态势，以及沦为无人维护的概率。这可说是一个更好的处境 —— 开放标准胜过封闭标准 —— 但这并非毫无依赖。在 Goose 上胜出的团队，会把已启用的 MCP 服务器当成生产环境依赖来对待：把它们锁定版本、加以审查，并清楚知道哪些是自己离不开的。由基金会治理，解决的是代理本身的中立性；它对你拴在它上面那条长尾扩展的存续性，只字未提。