当我们谈论 AI 辅助编程时，大多数工具仍然停留在「文本输入、代码建议输出」的单向交互模式。然而 Block 团队开源的 Goose 项目提出了一个更具野心的愿景：打造一个能够安装、执行、编辑和测试的完整 AI Agent。这个定位不仅仅是功能扩展，更是从「建议者」到「执行者」的本质跃迁。截至 2026 年 1 月，Goose 已在 GitHub 获得超过 27,700 颗星标，体现了开发者社区对这一方向的认可。
三层架构模型：从交互到执行的核心分离
Goose 的架构设计遵循清晰的三层分离原则，将用户界面、核心推理引擎和外部能力扩展解耦，形成可独立演进且高度可组合的系统。
Interface 层承担着所有用户交互的入口职责。它同时支持桌面应用程序和命令行两种形态，这意味着开发者可以根据自己的 workflow 偏好选择交互方式。Interface 的核心职责是收集用户输入并渲染 Agent 的输出结果，但它并不参与任何任务规划或工具调用的决策逻辑。这种设计使得 Interface 可以专注于交互体验的优化，而无需承载复杂的 Agent 逻辑。
Agent 层是整个系统的决策中枢。它维护着与用户的多轮交互上下文，管理着任务分解与执行的循环流程，并在每个决策节点调用 LLM 进行推理。当 LLM 决定需要调用某个工具时，Agent 负责将调用请求路由到正确的 Extensions，并处理返回结果。整个交互循环 —— 感知、推理、行动、反馈 —— 都在 Agent 层内完成闭环。值得注意的是，Agent 本身是状态无感的，它通过 Interface 实例化并与 Extensions 建立连接。
Extensions 层是 Goose 与外部世界交互的能力边界。每个 Extension 都是一个独立的组件，暴露特定的功能集供 Agent 调用。这些功能通过统一的 Tool 接口暴露，Extension 可以维护自己的内部状态，实现从简单的文件操作到复杂的外部 API 调用任何能力。Goose 内置了多个基础 Extension，覆盖了命令执行、文件管理等核心开发场景，同时支持用户通过 MCP 协议接入自定义扩展。
MCP 互操作性层：统一工具描述与调用契约
Goose 选择 Model Context Protocol（MCP）作为其扩展互操作的标准协议，这一决策为整个生态系统带来了显著的可组合性优势。MCP 最初由 Anthropic 提出并开源，旨在解决 AI Agent 与外部工具之间的标准化通信问题。Goose 将 MCP 服务器概念化为自己的 Extensions，通过统一的工具描述格式实现能力发现与调用。
在 MCP 框架下，每个工具都有标准化的元数据描述，包括名称、功能说明、输入参数 Schema 和返回值格式。这种结构化的描述使得 Agent 能够在上下文中理解每个工具的能力边界，从而做出更准确的工具选择决策。工具参数的 JSON Schema 定义尤其重要 —— 它不仅约束了输入格式，还在 Agent 推理阶段提供了类型安全的基础。
MCP 的另一核心价值在于其传输层的抽象性。MCP 服务器可以运行在本地进程、Unix Socket 甚至远程 HTTP 端点上，Goose 的 Extension 框架对此透明。这种灵活性意味着同一个 MCP 服务器可以被多个 Agent 实例共享，也可以在不同环境间迁移而无需修改工具定义。
Code Execution 模式：从工具调用到程序化编排
在 v1.17.0 版本中，Goose 引入了名为「Code Execution」的新扩展，这一实现参考了 Cloudflare 和 Anthropic 提出的「Code Mode」设计理念。与传统的工具直接暴露模式不同，Code Execution 采用了一种间接但更高效的调用范式。
传统模式下，Agent 需要了解所有可用工具的完整定义，包括每个工具的描述、参数和返回值格式，这些信息会占用大量上下文窗口。更重要的是，当 Agent 需要组合多个工具时，它必须逐个发起调用，等待结果后再决定下一步操作，整个过程的 token 消耗和延迟都相当可观。
Code Execution 模式改变了这一范式。它不为 Agent 直接暴露工具列表，而是生成一个 JavaScript 接口层，将所有可用的 MCP 工具封装为可编程 API。Agent 获得的能力变为：搜索模块源码、读取工具实现、编写 JavaScript 代码调用这些 API。代码在嵌入式的 boa JavaScript 引擎中执行，整个过程在沙箱环境中进行。
这种设计带来了三个实际的工程收益。首先是上下文效率提升 ——Agent 不再需要一次性加载所有工具定义，而是按需探索和调用。其次是工具链组合能力的增强 ——Agent 可以将一个工具的输出直接作为另一个工具的输入，无需中间结果回流到 LLM。最后是安全性改进 —— 敏感数据不会在工具调用往返过程中暴露给 LLM，整个执行过程在沙箱内完成。
多模型配置与生产部署考量
Goose 的另一个差异化特性是其对多模型配置的开箱支持。开发者可以同时连接多个 LLM 提供商，在不同任务类型或成本敏感度下动态切换。这种设计在工程实践中很有价值：对于快速原型任务，可以使用响应更快但能力稍弱的模型；对于复杂的架构决策，则调用最强大的推理模型。
在实际部署时，Goose 的桌面应用和 CLI 共享相同的 Agent 核心，这意味着本地开发体验与 CI/CD 中的自动化任务可以保持一致。对于需要持久化上下文的场景，Goose 支持会话状态的序列化和恢复，这对于长时间运行的任务或在上下文窗口限制下需要分阶段执行的项目尤为重要。
资料来源：Block Goose GitHub 仓库（https://github.com/block/goose）、Goose 官方文档（https://block.github.io/goose/docs/goose-architecture/）