解析 Goose：为什么它会进入 AAIF，以及这对 Agentic Runtime 意味着什么

推荐语

Goose项目为何能入选AAIF首批项目？这个低调的工程化Agent项目揭示了Agentic Runtime的未来方向。

核心内容：
1. Goose项目的独特定位与解决的关键工程问题
2. Block公司工程驱动文化对Goose设计的影响
3. Goose入选AAIF对Agentic Runtime发展的启示

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

在这一轮 Agent 浪潮里，Goose 并不是一个“第一眼就让人兴奋”的项目。

Goose  App UI

它没有炫技式的 Demo，也没有铺天盖地的多模态展示，更不像一个面向 C 端用户的 AI 产品。但就是这样一个看起来“朴素”的项目，却成为了 Agentic AI Foundation（AAIF）的首批捐赠项目之一，与 Anthropic 的 MCP、OpenAI 的 AGENTS.md 并列。

Block（原 Square）成立于 2009 年，由 Jack Dorsey 联合创立，拥有超过一万名员工和数千名工程师。尽管常被归类为金融科技公司，但 Block 内部长期以工程与系统能力驱动业务，技术栈复杂、自动化需求极高。

在近两年的 AI 转型中，Block 将重点放在 工程执行层的自动化，而非单点工具引入。Goose 正是这一背景下的内部工程产物，用于连接大模型与真实系统（代码、测试、UI、内部工具），并在大规模工程组织中实际运行。这种“源自生产环境”的属性，是 Goose 能成为 AAIF 首批项目的重要原因。

这件事本身，就很值得拆一拆。

这篇文章并不是想证明 Goose 有多强，而是想回答三个更现实的问题：

• Goose 到底解决了什么容易被忽略、但长期关键的问题？

• 为什么是 Goose，而不是其他 Agent 框架，进入了 AAIF？

• 这件事对我所关注的 Agentic Runtime 和 AI-Native 基础设施意味着什么？

Goose 的真实定位：它不是 IDE，也不是聊天机器人

如果只看表面功能，Goose 很容易被误解成两类东西之一：

• 一个“多模型 AI 桌面客户端”

• 或者一个“能跑命令的智能编程助手”

但在 Block 内部，它从一开始就不是按“工具”来设计的。

Goose 的诞生背景，和 Block 自身的工程环境关系很大。

Block（原 Square）是一家典型的工程驱动型公司：系统复杂、自动化需求高、内部工具多，而且真实生产环境中的执行成本非常高。在近两年的 AI 转型中，Block 并没有把重点放在“选哪个模型”或“引入哪个 AI 工具”上，而是直接盯住了工程执行层本身。

Goose 正是在这样的背景下诞生的。

它的目标不是“让人写得更快”，而是让模型能够稳定、可控地动手做事：跑测试、改代码、驱动 UI、调用内部系统，并且能在真实工程环境中长期运行。

如果用一句话概括：

Goose 更像一个可执行的 Agent Runtime，而不是一个以对话为中心的产品。

Block 做 AI 转型，起点不是工具，而是组织结构

理解 Goose，还绕不开 Block 的一次组织层面的转向。

在 Block CTO 的访谈中，有一个信号非常明确：AI 转型的起点，并不是买工具或堆模型，而是组织结构本身。

Block 从偏业务线的 GM 制，转向更偏工程职能的 Functional 制，让工程和设计重新成为公司的核心调度单元。这本质上是一次 Conway’s Law 的主动应对。

如果组织结构本身不允许技术能力被统一调度，那么 Agent 最终只会停留在“个人助手”或“工程玩具”的层面。

从这个角度看，Goose 并不仅仅是一个工具，而是一种文化信号：

每个员工，都可以用 AI 去构建和执行真实的系统行为。

这也解释了一个很多人忽略的事实：  Goose 并没有被包装成 SaaS，也没有急着商业化，而是被直接开源，并迅速标准化。

因为它在 Block 内部承担的角色，更接近“执行模型的操作系统”，而不是一个可以单独售卖的产品。

为什么 Goose 能进入 AAIF？不是因为“技术最强”

这是外界最困惑的一点。

如果只看炫技能力、模型支持或社区热度，Goose 并不占优势。但 AAIF 选择它，关注的并不是“能力上限”，而是位置是否正确。

从 AAIF 首批项目的组合来看，其实已经形成了一条很清晰的链路：

• MCP（Anthropic）：定义模型如何安全、标准化地调用工具

• AGENTS.md（OpenAI）：定义 Agent 在代码仓库中的行为约定

• Goose（Block）：一个真实可运行的、开源的 Agent 执行框架

Goose 的角色并不是制定新协议，而是作为这些协议的落地承载体和参考实现。

它证明了一件事：

• MCP 不是纸面标准

• Agent 不是研究概念

• 在真实企业环境中，它们是可以跑起来的

从这个角度看，Goose 的“普通”，反而是一种优势。

它没有绑定 Block 的商业护城河，也没有不可替代的私有 API；它可以被 fork、被替换、被审计，足够“无聊”，也足够中立。

而这，正是公共基础设施最重要的特质。

Goose 的意义，不在今天，而在 2–3 年后

如果站在更长时间尺度上看，Goose 的价值会更清楚。

我们正在经历的，很像容器早期的阶段：  现在的 Agent 项目，大多是 Demo、IDE 插件、Workflow 封装，而真正缺失的是一个可持续运行、可调度、可观测的执行层。

Goose 已经踩在这个方向上了。

Block 衡量 Goose 成功与否的指标也很直接：

• 每周节省了多少人类工时

• 非技术团队减少了多少对工程团队的依赖

这背后对应的是一个我越来越确信的判断：

企业真正需要的，不是“更聪明的模型”，而是“更便宜的执行”。

Agent 的长期价值，并不在生成质量，而在执行替代率。

AAIF 是一次基础设施层面的共识尝试

就像 CNCF 之于云原生一样，AAIF 并不保证一定成功。

但它至少标志着一个变化：  Agent 不再只是应用层的创新，而开始进入基础设施层的协同阶段。

Goose 作为其中的参考实现，很可能会长期存在于这个坐标系中——哪怕未来它被替代、被重写、被演化。