微信扫码
添加专属顾问
我要投稿
Goose项目为何能入选AAIF首批项目?这个低调的工程化Agent项目揭示了Agentic Runtime的未来方向。核心内容: 1. Goose项目的独特定位与解决的关键工程问题 2. Block公司工程驱动文化对Goose设计的影响 3. Goose入选AAIF对Agentic Runtime发展的启示
欢迎关注「几米宋」的个人微信公众号,我主要关注 AI Native 基础设施方向,研究和实践 Agentic Runtime、Kubernetes 调度与 AI 推理系统的工程化问题。
📄 文章摘要
从 Block 的 Goose 项目出发,解析它为何成为 Agentic AI Foundation(AAIF)的首批项目之一,以及这背后所代表的 Agentic Runtime 与 AI-Native 基础设施演进方向。
在这一轮 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 很容易被误解成两类东西之一:
• 一个“多模型 AI 桌面客户端”
• 或者一个“能跑命令的智能编程助手”
但在 Block 内部,它从一开始就不是按“工具”来设计的。
Goose 的诞生背景,和 Block 自身的工程环境关系很大。
Block(原 Square)是一家典型的工程驱动型公司:系统复杂、自动化需求高、内部工具多,而且真实生产环境中的执行成本非常高。在近两年的 AI 转型中,Block 并没有把重点放在“选哪个模型”或“引入哪个 AI 工具”上,而是直接盯住了工程执行层本身。
Goose 正是在这样的背景下诞生的。
它的目标不是“让人写得更快”,而是让模型能够稳定、可控地动手做事:跑测试、改代码、驱动 UI、调用内部系统,并且能在真实工程环境中长期运行。
如果用一句话概括:
Goose 更像一个可执行的 Agent Runtime,而不是一个以对话为中心的产品。
理解 Goose,还绕不开 Block 的一次组织层面的转向。
在 Block CTO 的访谈中,有一个信号非常明确:AI 转型的起点,并不是买工具或堆模型,而是组织结构本身。
Block 从偏业务线的 GM 制,转向更偏工程职能的 Functional 制,让工程和设计重新成为公司的核心调度单元。这本质上是一次 Conway’s Law 的主动应对。
如果组织结构本身不允许技术能力被统一调度,那么 Agent 最终只会停留在“个人助手”或“工程玩具”的层面。
从这个角度看,Goose 并不仅仅是一个工具,而是一种文化信号:
每个员工,都可以用 AI 去构建和执行真实的系统行为。
这也解释了一个很多人忽略的事实: Goose 并没有被包装成 SaaS,也没有急着商业化,而是被直接开源,并迅速标准化。
因为它在 Block 内部承担的角色,更接近“执行模型的操作系统”,而不是一个可以单独售卖的产品。
这是外界最困惑的一点。
如果只看炫技能力、模型支持或社区热度,Goose 并不占优势。但 AAIF 选择它,关注的并不是“能力上限”,而是位置是否正确。
从 AAIF 首批项目的组合来看,其实已经形成了一条很清晰的链路:
• MCP(Anthropic):定义模型如何安全、标准化地调用工具
• AGENTS.md(OpenAI):定义 Agent 在代码仓库中的行为约定
• Goose(Block):一个真实可运行的、开源的 Agent 执行框架
Goose 的角色并不是制定新协议,而是作为这些协议的落地承载体和参考实现。
它证明了一件事:
• MCP 不是纸面标准
• Agent 不是研究概念
• 在真实企业环境中,它们是可以跑起来的
从这个角度看,Goose 的“普通”,反而是一种优势。
它没有绑定 Block 的商业护城河,也没有不可替代的私有 API;它可以被 fork、被替换、被审计,足够“无聊”,也足够中立。
而这,正是公共基础设施最重要的特质。
如果站在更长时间尺度上看,Goose 的价值会更清楚。
我们正在经历的,很像容器早期的阶段: 现在的 Agent 项目,大多是 Demo、IDE 插件、Workflow 封装,而真正缺失的是一个可持续运行、可调度、可观测的执行层。
Goose 已经踩在这个方向上了。
Block 衡量 Goose 成功与否的指标也很直接:
• 每周节省了多少人类工时
• 非技术团队减少了多少对工程团队的依赖
这背后对应的是一个我越来越确信的判断:
企业真正需要的,不是“更聪明的模型”,而是“更便宜的执行”。
Agent 的长期价值,并不在生成质量,而在执行替代率。
就像 CNCF 之于云原生一样,AAIF 并不保证一定成功。
但它至少标志着一个变化: Agent 不再只是应用层的创新,而开始进入基础设施层的协同阶段。
Goose 作为其中的参考实现,很可能会长期存在于这个坐标系中——哪怕未来它被替代、被重写、被演化。
如果你把 Goose 当成一个“产品”,它确实不耀眼。
但如果把它放进 Agentic AI 的长期演化路径中,它的意义就会变得清晰:
它不是终点,但它是一个必要的中间态。
对我而言,Goose 的出现,反而进一步确认了一件事:
Agentic Runtime 不是一个概念问题,而是一个工程问题,也是一个组织问题。
而这,正是接下来几年最值得投入精力的方向之一。
更多精彩内容
🌐 个人网站:jimmysong.io
🎥 Bilibili:space.bilibili.com/31004924
如果这篇文章对你有帮助,欢迎点赞、分享给更多朋友!
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2025-12-15
字节AI神操作:AI生成接口自动化测试用例,效率拉满
2025-12-15
Palantir的“本体论”:数字世界的底层革命
2025-12-15
Claude Skills|将 Agent 变为领域专家
2025-12-15
OpenAI Code Interpreter ("Coworker") 架构审计与安全取证分析
2025-12-14
Claude Skill深度分析:拖拉拽已死,Skill 当立
2025-12-14
PostHog关于Agent的8个核心经验
2025-12-14
AI原生数据库的思考
2025-12-14
Anthropic:别再构建智能体,开始构建技能
2025-09-19
2025-10-26
2025-10-02
2025-09-17
2025-09-29
2025-10-07
2025-09-30
2025-11-19
2025-10-20
2025-11-13
2025-12-14
2025-12-12
2025-12-12
2025-12-11
2025-12-09
2025-12-08
2025-12-08
2025-12-03