从前，向开源项目提交你的第一个 PR 相当费事。即便说明写得很清楚，把项目构建起来、让应用跑起来、让测试通过，都需要实打实的工作。就算你清楚要修哪个 bug，也得大致理解项目架构，并对要改的代码有更细致的了解。

编程智能体改变了这一切。问题不在代码质量。网上到处都是对 AI 注水代码的抱怨，但智能体写出的代码，往往比第一次贡献者交上来的更好。问题在于，智能体改变了开源的经济账。

PR 曾经是一份并不完美、但能说明有人做了功课的证据。如果没有理由相信维护者会想要这个功能，谁会费劲把它实现出来？修一个 bug 所需的工作，也会迫使你理解周围的代码。这并不能保证判断正确，但摩擦力会筛选出真正投入的人，并迫使贡献者在写代码之前先获得上下文。

今天，做出一份看起来像样的功能实现或 bug 修复已经很便宜。昂贵的是判断这项改动是否属于这个项目，以及正确的方案长什么样。一个 PR 到达时，这些问题看起来好像已经有了答案，但智能体往往只是做了一系列看似合理的选择。维护者必须把这些选择挖出来，判断哪些是对的，并说明其余的该怎么改。贡献者的智能体会迅速修改代码，但判断是维护者提供的。到了这一步，维护者何不干脆运行自己的智能体？

把这个逻辑推到底，开源项目会剩下公开的代码，却没有有意义的公众参与：项目由一个小核心团队及其智能体开发，其他人则变成被动用户或工单提交者。但开源的价值从来不只是外人写下的代码。外人带来新的眼光、新的想法、意料之外的使用场景和领域知识。他们会遇到核心团队从未见过的问题，并质疑核心团队已经不再注意的假设。

要保住这份价值，我们得放下把 PR 当作主要贡献机制的做法，把外部贡献前移。有价值的贡献地点，主要不再是写代码，而是提交好的 issue，更重要的是参与讨论，把这些 issue 变成经过慎重考虑的方案。

我们正在用一个公开的 goose Issues 看板 把 goose 迁到这个模式。和以前一样，如果你发现 bug 或想要新功能，就提交一个 GitHub issue。新 issue 进入 Inbox。分流时我们可能会要求补充信息，或在说明原因后关闭 issue。我们想解决的问题会进入 Accepted / design，贡献者和核心团队在这里敲定预期设计、架构约束，以及如何验证结果。

讨论定下来之后，issue 进入 Ready。此时智能体就可以写代码。实现进行中时，issue 进入 In progress；结果准备好让人确认是否有效时，进入 Verification。只有到那时才是 Done。没有实现已就绪 issue 的 PR 会被关闭，反馈未处理的 PR 也会被关闭。

这也改变了谁应该获得署名。报告问题、复现问题、贡献领域知识、塑造设计、实现方案和验证结果，都可以是有意义的工作。每个阶段有实质贡献的人，都应当被承认为共同作者。开源贡献的单位不再是补丁，而是把一个问题一路带到经过验证的解决方案。如今，大部分贡献发生在 issue 里。

古德哈特定律是跑基准的人的诅咒：当一项度量变成目标，它就不再是好的度量。编程智能体基准几乎就是为触发它而设计的。任务是公开的，结果是一个数字，排行榜不可避免地挤满了那些往往并非有意、却对基准过拟合的运行框架。

这并没有让事实上的标准 Terminal-bench 变得无用，但确实改变了 goose 团队使用它的方式。排行榜是对通用智能体能力的嘈杂度量。真正的信号是失败的模式：goose 反复卡住的地方，或者 goose 失败而另一个运行框架成功的地方。

这也是我们通常用 Sonnet 而不是最强模型来跑基准的原因。我们并不是要拿到尽可能大的数字。我们希望桌上还留着足够多的失败，好看出智能体缺了什么支持。

自我改进的智能体很热门，但我们目前信任的版本仍然需要人。这个循环是：跑基准，让 goose 比较同一任务上一个运行框架成功、另一个失败的情况，并要求它用具体说法解释差异。然后人看几处这样的失败，判断普遍的教训是什么，再让 goose 去实现这项更广泛的改进。

人这一步让循环不会塌缩成针对基准的小技巧。没有它，自我改进的智能体可能会选择为每个任务只写一个 Skill；智能体和人一样懒。有了它，我们才有希望把一次任务上的失败，变成对尚未见过的任务也该有帮助的能力。

相关工具在 goose 仓库的 evals/harbor。主要入口是 ./evals/harbor/cmd.py，一个带有 run、list、show、task、compare 和 pull 子命令的小型 Python 命令。它把 Harbor 包在特定的 goose 二进制、模型和一组扩展之外，然后留下一个装满按任务划分的 JSON 和日志的目录。

这是 Python 特别合适的地方。cmd.py 是一个 PEP 723 的 uv 脚本，所以依赖就写在文件顶部。没有打包仪式，没有新仓库，也不用记住哪个虚拟环境被“加持”过。你让智能体加一个子命令、埋一个观测值，或者让输出表格不那么难看，它就去做。脚本既是控制面，也是实验的文档。这正是 vibe coding 发光的地方：小型工具表达需要做什么，而它们是否写得优雅其实并不重要。

真正的基准运行发生在一台远程 Linux 机器上，因为完整跑一遍又慢、又并行、又重度依赖 Docker。但分析不必留在那里。cmd.py pull tbench@...:/path/to/goose 用 rsync 把运行目录拉回来，然后本地工具就可以列出运行、检查单个任务，或比较两个任务。这比听起来更重要。如果每个问题都要 SSH 进基准机器、手工在日志里摸索，你问的问题就会更少。

PR #9637 里的比较配方实现了 goose 查看结果的那一步。它们读取同一任务的两次运行、智能体轨迹、验证器输出和参考解。有用的输出会解释机制：“A 注意到了那张图，B 从未打开它”，或者“A 在正确文件已经存在后就停了，B 一直重写，直到把它写坏”。

最近的工作里有两个发现。第一，goose 有时在已经有足够信息可以收尾时还继续探索。它已经接近答案，却不做出结论，而是继续戳来戳去，最终用完回合，基准失败。普通对话里也会发生同样的事：如果 goose 不知道这次交流进行到了哪一步，它就没有真正的理由停止探索、转向解决方案。PR #9636 给 MoIM 加上了回合数感知。MoIM 是 goose 注入的上下文，用来让模型保持方位感。于是现在 goose 知道什么时候该收工了。

第二，goose 失去了从磁盘读取图片的能力。最初，当你把一张图片拖进 goose 对话时，我们会插入那张图片的路径，并给模型一个读取它的工具。那样很别扭，所以我们把它换成了在对话里正确加载图片。在这个过程中，我们不小心也删掉了磁盘图片工具。在基准里，这表现为 goose 用 PIL 去检查图片，而不是使用模型的视觉能力。比较配方让这次失败变得明显，因为成功的那次运行看了图片，失败的那次则绕开了它。

多亏这个循环，我们发现了 goose 的两个真实弱点并修好了它们。基准变好了，这很好；更重要的是，这两处修复应该让 goose 在日常使用中也更好：该收尾时更不容易漂走，并且又能查看磁盘上的图片文件。

基准有用的时候，就是它不再是排行榜，而开始成为缺陷报告的时候。

goose 现在支持生命周期钩子。把一个插件放进磁盘上的目录，会话中有事情发生时 goose 就会运行你的 shell 脚本：工具即将触发、工具刚刚结束、用户提交了提示、会话开始、会话结束。

如果你用过 Claude Code 的 hooks 或 git hooks，这是同一个想法。如果你没用过：智能体循环现在可以从外部脚本化，不必写任何 Rust，也不必写任何 MCP 服务器。

它如何工作​

goose 遵循 Open Plugins hooks 规范。~/.agents/plugins/<name>/（用户范围）或 <project>/.agents/plugins/<name>/（项目范围）下任何包含 hooks/hooks.json 文件的插件目录，都会在启动时被自动发现。

一份最小的 hook 配置看起来是这样：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "developer__shell|developer__text_editor",
        "hooks": [
          { "type": "command", "command": "${PLUGIN_ROOT}/scripts/log.sh" }
        ]
      }
    ]
  }
}

事件触发时，goose 运行命令，在环境里设置 PLUGIN_ROOT，并把一份 JSON 载荷通过 stdin 传给脚本：

{
  "event": "PostToolUse",
  "session_id": "abc-123",
  "tool_name": "developer__shell",
  "tool_input": { "command": "rg TODO" },
  "working_dir": "/Users/you/project"
}

支持的事件是：

• SessionStart、SessionEnd、Stop
• UserPromptSubmit
• PreToolUse、PostToolUse、PostToolUseFailure
• BeforeReadFile、AfterFileEdit
• BeforeShellExecution、AfterShellExecution

matcher 字段是一个正则，针对该事件最相关的字符串进行测试（工具名、文件路径或 shell 命令）。不写它，hook 就会对该类型的每一个事件触发。失败或超时的 hook 会被记录，但不会让宿主工具崩溃，所以你的脚本可以随你想多粗糙。

可以试试的几件事​

1. 让 goose 在真正需要你时跟你说话​

挑出少数意味着“现在人类的注意力会有用”的事件——工具失败了、会话结束了、一条长时间运行的命令完成了——并让 goose 在其中一个触发时说出一句话：

{
  "hooks": {
    "PostToolUseFailure": [{ "hooks": [{ "type": "command", "command": "${PLUGIN_ROOT}/scripts/notify.sh" }] }],
    "SessionEnd":         [{ "hooks": [{ "type": "command", "command": "${PLUGIN_ROOT}/scripts/notify.sh" }] }],
    "AfterShellExecution": [
      {
        "matcher": "^(cargo (test|build|clippy)|pnpm (test|build)|just )",
        "hooks": [{ "type": "command", "command": "${PLUGIN_ROOT}/scripts/notify.sh" }]
      }
    ]
  }
}

然后 notify.sh 根据载荷分支，并选一句话：

#!/usr/bin/env bash
payload="$(cat)"
event="$(printf '%s' "$payload" | jq -r .event)"

case "$event" in
  PostToolUseFailure)  echo "That didn't work. Need a hand?" | say -v Daniel ;;
  SessionEnd)          echo "Done. Come check this out."     | say -v Daniel ;;
  AfterShellExecution) echo "Long command finished."         | say -v Daniel ;;
esac

把 matcher 正则调成你世界里算“长时间运行”的东西——测试套件、构建、部署、terraform apply。

2. “goose 正在做事”的台灯 🪿💡​

如果你有带 HTTP API 的智能灯泡（Hue、LIFX、Home Assistant 等），在 goose 开始工具调用时打开它，结束时关掉：

{
  "hooks": {
    "PreToolUse":  [{ "hooks": [{ "type": "command", "command": "curl -s -X POST http://hue.local/light/on"  }] }],
    "PostToolUse": [{ "hooks": [{ "type": "command", "command": "curl -s -X POST http://hue.local/light/off" }] }]
  }
}

现在你的台灯是智能体的状态指示灯。走开，再瞥一眼，如果它亮着，goose 还在工作。

3. 自动格式化 goose 编辑的每一个文件​

挂上 AfterFileEdit，自己运行格式化工具，这样智能体就不必记住：

{
  "hooks": {
    "AfterFileEdit": [
      {
        "matcher": "\\.(ts|tsx|js|jsx|json|md)$",
        "hooks": [{ "type": "command", "command": "${PLUGIN_ROOT}/scripts/format.sh" }]
      },
      {
        "matcher": "\\.rs$",
        "hooks": [{ "type": "command", "command": "cargo fmt" }]
      }
    ]
  }
}

scripts/format.sh 从 stdin 读取文件路径，并对它运行 prettier --write。

4. 每日会话日记​

挂上 SessionEnd，把一行摘要追加到一个 markdown 文件：

#!/usr/bin/env bash
payload="$(cat)"
session_id="$(printf '%s' "$payload" | jq -r .session_id)"
date_str="$(date '+%Y-%m-%d %H:%M')"
echo "- $date_str — session $session_id ended" >> ~/notes/goose-journal.md

也捕捉 UserPromptSubmit 载荷，你就有了今天问智能体的每一个问题的日志。

5. 让 goose 听起来像一艘潜艇​

因为你可以：

{
  "hooks": {
    "PreToolUse": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Submarine.aiff"
          }
        ]
      }
    ],
    "SessionEnd": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "say 'Captain, the session has ended.'"
          }
        ]
      }
    ]
  }
}

当 goose 在另一个窗口做长时间任务时这很有用。音频提示告诉你它确实在做事，而不是坐在那里等你。

试试示例​

仓库里有一个可工作的示例，在 examples/plugins/hello-hooks——一个插件，接上 SessionStart、UserPromptSubmit、PreToolUse 和 PostToolUse，并为每一个向 stderr 打印一个友好的 emoji。把它复制到 ~/.agents/plugins/，开始一个会话，看着事件飞过：

mkdir -p ~/.agents/plugins
cp -R examples/plugins/hello-hooks ~/.agents/plugins/hello-hooks
chmod +x ~/.agents/plugins/hello-hooks/scripts/announce.sh

goose session
# 🚀 [hello-hooks] SessionStart
# 💬 [hello-hooks] UserPromptSubmit
# ⚡ [hello-hooks] PreToolUse tool=developer__shell
# ✅ [hello-hooks] PostToolUse tool=developer__shell

每一个事件也会被追加到 ~/.agents/plugins/hello-hooks/last-event.log，这样你可以看到脚本收到的确切 JSON。触发一些事件，tail 日志，从那里开始构建。

为什么这重要​

MCP 服务器给 goose 新工具。Hooks 走另一个方向：它们给你一种方式，用你已经知道的任何语言，实时对 goose 正在做的事做出反应。Bash、Python、一个 Go 二进制、一行 curl。它不过是 stdin 上的一条命令。

插件模型有意做得很小：一个文件夹、一个 JSON 文件、一个脚本。没有注册步骤，没有守护进程，没有重新构建。放进去，启动 goose，它就工作。拿出来，goose 也不会注意到它没了。

如果你做出了有趣的东西，分享它。examples/plugins/ 目录是社区插件的好去处，而 Open Plugins 规范 意味着你在这里构建的任何东西，都能与采用它的其他智能体一起工作。

钩子愉快。🪝

很多人一次只给智能体一个任务——“做这个，现在做那个，现在做下一件”。这能用，但很慢。很多人也希望智能体同时做很多事：边写代码边研究，边测试边审阅，边重构边写文档。

这就是编排给你的东西。你不必一次喂给 goose 一个任务然后等待，而可以让它协调多个并行工作的智能体——每个专注拼图的一块，由 goose 让一切保持在轨道上。

什么是编排？​

如果你用过子智能体，你已经知道如何把工作委托给独立的 AI 实例。编排是那之上的一层——决定谁在什么时候做什么的部分。编排让你不必让一个 goose 会话按顺序做所有事，而是可以：

• 拆解一个复杂任务为独立的子任务
• 委托每个子任务给一个单独的智能体（子智能体、ACP 提供商，或另一个 goose 实例）
• 协调结果——等待依赖、处理失败、合并输出

把它想成独立开发者和管理团队的技术负责人之间的差别。

自己试试​

下面是你现在就可以运行、看到编排实际效果的东西。问 goose：

I need to understand this codebase. In parallel:
- Summarize the project structure and key dependencies
- Identify the main entry points and how data flows through them
- Find any TODO comments or known issues in the code

goose 会同时拉起三个子智能体——每个负责一项研究任务。你会在会话里看到它们同时工作，三份摘要大致一起回来，而不是一个接一个。原本三次顺序等待变成一次。

它如何建立在已有的东西之上​

编排不取代子智能体或子配方——它建立在它们之上：

如果子智能体是你的队友，编排就是告诉他们做什么、何时做的项目计划。

分阶段工作流：研究 → 构建 → 验证​

并非一切都能并行。有些工作流有自然的阶段，后面的步骤依赖前面的结果。你可以自然地向 goose 描述这一点：

Build a REST API for the inventory system:
1. First, research the existing data models in src/models/ and the API patterns in src/routes/ (do both at the same time)
2. Then implement the inventory API routes following those patterns
3. Finally, write integration tests and do a security review (both at the same time)

goose 理解这里的依赖结构。阶段 1 并行运行两项研究任务。阶段 2 等那些结果出来再构建。阶段 3 并行启动两项独立的验证任务。

关键洞察：读取可以并行，写入应当顺序进行（尤其是它们碰到同一批文件时）。

编排 + ACP：混用智能体​

这里事情变得真正有趣。编排与 ACP 提供商 一起工作，这意味着你可以把工作委托给完全不同的编程智能体——不只是 goose 子智能体。

要使用它们，你只要在提示里说出来，例如：

Refactor the auth module for clarity using Claude Code,
then write tests for it, and use Codex to generate the API docs.

goose 理解你想让不同的智能体处理工作流的不同部分。它把每个任务委托给合适的智能体，等待结果，并把一切带到一起。无论你在 CLI 还是桌面应用上，这都一样——你用自然语言提出即可。

唯一的前提是，为你想使用的智能体配置好提供商。

最佳实践​

开始编排时，重要的是用概念上分开、不太可能在共享文件上产生编辑冲突的任务来做。下面是一些提示：

把读取并行化​

研究任务可以安全地并行运行。多个智能体可以同时阅读同一个代码库、文档或 API，而不会互相踩脚。

指令要明确​

被委托者只知道你告诉它们的东西。它们彼此之间、以及与父会话之间不共享上下文。如果被委托者需要前一阶段的信息，就在指令里明确传过去。

从简单开始​

你不需要编排一切。对直接的任务，单个子智能体就够了。当你有真正独立的工作流，或需要对同一问题的多个视角时，编排才会发光。

开始使用​

如果你已经在用 goose，今天就可以开始编排。最简单的方式就是提出：

Do these three things in parallel: [task A], [task B], [task C]

其余的由 goose 处理——拉起被委托者，并发运行它们，并把结果带到一起。

对于可复用的工作流，查看并行子配方教程，构建可以和团队分享的配方。如果你想引入外部智能体，ACP 提供商指南 会帮你配好 Claude Code、Codex 或 Amp。

所链文章中的要点：

• 在 Databricks 的 OfficeQA 基准上，使用 goose 搭配 MiniMax M2.5，我们看到的结果正以约三十分之一的成本接近前沿模型性能。
• 闭源模型在准确率上领先（约 80% 对约 70%），但 MiniMax M2.5 每次运行平均花费 1.74 美元，而 Opus 4.5 为 56.53 美元。大约便宜 30 倍。
• 换成 @goose_oss 这套运行框架后，准确率比其他方案高出约 10%，并且比次优选项便宜 8 倍。我们决定用独立测试进一步探究。在 Terminal Bench 2.0 上，情况类似：goose 的 token 效率（以及成本）比 OpenHands 高 20 倍，比 OpenCode 便宜 40 倍以上。

完整帖子和结果见这里：

https://x.com/SentientAGI/status/2046967422004154739

大多数 AI 智能体住在终端里。它们能读文件、跑命令、写代码——但如果你让它们在网页应用里点一个按钮或填一张表单，它们就卡住了。它们看不见屏幕上有什么，当然也不能与之交互。

在 v1.26，goose 冲出了终端。Computer Controller 扩展用 Peekaboo 从头重建。Peekaboo 是一个用于屏幕捕获和 GUI 自动化的 macOS CLI 工具。这给了 goose 桌面上的眼睛和手——它能看见带标注的截图，识别 UI 元素，点击按钮，输入文字，滚动，拖拽，并在 Mac 上的任何应用里导航菜单。

看见 → 点击 → 输入的循环​

核心工作流简单得要命，而且出奇地可靠：

1. 看见 — goose 对一个应用拍一张带标注的截图。每个可点击元素得到一个标签 ID，比如 B1、B2、T1。
2. 点击 — goose 按 ID 点击一个元素。没有脆弱的像素坐标。
3. 输入 — goose 输入文字、按键，或使用键盘快捷键。

因为元素 ID 绑定的是实际 UI 组件（不是屏幕位置），这种方法能适应不同的窗口大小和位置。goose 不需要知道按钮在屏幕上哪里——只需要知道它是什么。

实践中是这样：

goose: Let me see what's on screen...
→ see --app Safari --annotate

goose: I can see the form. Clicking on the email field...
→ click --on T3
→ type "hello@example.com" --return

see 命令既返回一张带标注的截图（临时存在内存里），也返回带有元素 ID、标签和类型的结构化 JSON 数据。视觉和结构的这种组合，让交互变得可靠。

goose 实际能用它做什么？​

一旦 goose 能看见并与你的屏幕交互，它能处理的任务范围就急剧扩大。下面是一些真实例子：

填写表单​

“去 HR 门户，提交我下周五的请假申请”

goose 打开浏览器，导航到页面，识别表单字段，填进去，并点击提交——全部通过看见 UI 并一步步与之交互来完成。

导航复杂 UI​

“打开 Figma，找到叫 ‘Homepage Redesign’ 的设计，并导出为 PNG”

跨没有 API 的应用的多步工作流成为可能。goose 可以点过菜单，在应用内搜索，并跟随多屏流程。

控制系统设置​

“打开勿扰模式，并把显示器亮度设为 50%”

系统偏好、菜单栏项目和 macOS 设置都可以通过 Peekaboo 的 menu、menubar 和 dialog 命令访问。

自动化重复的 GUI 任务​

“对我 Downloads 文件夹里的每个 PDF，在 Preview 里打开并打印”

goose 可以把已有的文件系统和 shell 能力与 GUI 自动化结合起来——读取目录列表，然后以视觉方式打开并与每个文件交互。

完整的命令工具箱​

Peekaboo 给 goose 一套全面的命令，用于在视觉、交互和系统控制各方面与 macOS 交互。完整列表见 Peekaboo 文档。一些要点：

• see — 捕获带标注的截图并获得结构化 UI 数据
• click — 按 ID 点击一个元素
• type — 输入文字或按键
• scroll — 在一个元素内滚动
• drag — 从一个元素点击并拖到另一个
• menu — 与菜单栏项目交互
• dialog — 与系统对话框和通知交互

获得最佳结果的提示​

大量使用 Computer Controller 之后，下面几件事有帮助：

• goose 工作时不要动鼠标。 goose 根据它看见的东西截图和点击。如果你在任务中途挪东西，它会困惑。
• 提示要具体。 “点击表单底部那个蓝色的提交按钮”比“提交它”给 goose 的信息多得多。
• 让 goose 先看。 goose 会自然地先用 see 命令理解当前 UI 状态，然后再行动。如果你在调试一次交互，让 goose 重新拍一张截图。
• 长文本走粘贴。 为了可靠，输入较长内容时 goose 用 paste 而不是 type。这避免特殊字符和打字速度的问题。

当前限制​

Computer Controller 很强，但值得知道边界：

• 目前仅 macOS — Peekaboo 建立在 macOS 辅助功能 API 上。在 Windows 和 Linux 上，Computer Controller 回退到基于 shell 的自动化（Windows 上的 PowerShell 脚本，Linux 上的 xdotool/wmctrl）。
• 变化很快的 UI 会棘手 — 视频、动画和快速更新的内容会让 goose 看到过时的状态。静态或变化慢的 UI 效果最好。
• 标准 UI 元素效果最好 — 自定义渲染的画布（比如某些游戏 UI 或重度定制的网页应用）可能不暴露 Peekaboo 能识别的辅助功能标签。
• 一次一个屏幕 — goose 每次 see 命令处理一张截图，不过在多显示器设置里你可以用 --screen-index 指定特定屏幕。

试试看​

Computer Controller 扩展内置于 goose——只要在扩展里启用它，并开始让 goose 做视觉任务。如果你在 macOS 上，其余的由 Peekaboo 处理。

在 goose Desktop 里，前往 Extensions，打开 Computer Controller。在 CLI 里：

goose configure
# → Toggle Extensions → enable computercontroller

然后试一件简单的事：

Take a screenshot of my current screen and describe what you see.

或者更有野心一点：

Open System Settings, go to Displays, and set the resolution to "More Space."

其余的 goose 会弄清楚——看见 UI，识别正确的元素，并点过去把它做完。

你现在可以直接在自己的机器上用 goose 运行本地模型。没有 Ollama，没有 Docker，没有外部服务器——完全在 goose 内部。我们发布了由 llama.cpp 驱动的内置本地推理，今天已经可以在桌面应用里使用。

这是使用 goose 的完全免费、零依赖路径。你的代码永远不会离开你的机器，没有要管理的 API 密钥，而且可以离线工作。下面是这种体验长什么样、该选哪些模型，以及粗糙之处还在哪里。

它如何工作​

goose 现在把 llama.cpp 直接嵌入运行时。当你选择 Local 提供商时，goose 会从 HuggingFace 下载一个量化的 GGUF 模型，把它加载到 GPU（或 CPU）内存，并在进程内运行推理。

没有单独的服务器要启动，没有端口要配置，没有后台守护进程。

在桌面应用上这样做：

1. 打开 Settings → Local Inference
2. 在 Hugging Face 上搜索兼容的模型。
3. 点击下载——模型文件会落到共享的 Hugging Face 缓存里。
4. 开始构建。就这样。

细节由 goose 处理：GPU 卸载、内存管理、上下文窗口大小，以及在模型之间切换时自动卸载模型。

这和 Ollama 有什么不同​

你可能已经熟悉通过 Ollama 提供商 使用 goose。两条路径都在本地运行模型，但架构不同：

内置路径是为想要尽可能简单的本地体验的人设计的——一个应用，一次下载，完成。如果你想要更多控制、更广的模型选择，或者已经在用它服务其他工具，Ollama 仍然很好。

可以期待什么​

选择本地模型会带来一些代价，其中最大的是性能，取决于你的硬件能力。与云端模型相比：

它更慢。 第一次请求需要 30–120 秒，因为模型要加载进内存。之后，在 Apple Silicon（尤其是 M2/M3/M4）上 token 生成很快，但在只有 CPU 的机器上会明显更慢。

上下文窗口更小。 大多数本地模型使用 4K–8K token 的上下文，而 Claude 或 GPT 是 128K+。goose 会根据可用内存设置 num_ctx，但在长会话里你会更快碰到上限。Code Mode 在这里有帮助——它减少 token 用量和上下文腐烂。

工具调用是差距所在。 用 Gemma 4 时，它确实不错。用模拟模型时，它仅限于 shell 命令。这是与云端体验最大的单一差别。

它完全私密。 没有任何东西离开你的机器。没有遥测，没有 API 调用，没有数据共享。处理专有代码、凭证或敏感数据时，这很重要。

它不花钱。 初次下载模型之后，每次会话都是免费的。没有 token 要计，没有账单要担心。

充分利用它的提示​

从小开始。 选择一个能舒适放进 goose 可用内存的量化模型。如果它对你的任务效果好，需要更强能力时再升级到更大的模型。

使用 Code Mode。 认真的。它就是为这种场景设计的——在更小的上下文窗口里保持会话有产出。

使用推荐。 goose 会把你 Hugging Face 缓存里已有的模型，和当前可用于推理的内存进行比较。

不要和模拟模式较劲。 如果你用的模型没有原生工具调用，就顺着 shell 命令工作流走。让 goose 一步一步做事。它对“运行这个命令，检查输出，做下一件事”这种模式效果很好。

为不同任务切换模型。 你可以下载多个模型。用小而快的模型做快速 shell 任务，用更大的模型做复杂推理。goose 会自动卸载上一个模型。

它使用与本地模式相同的 llama.cpp 基础设施来运行模型，但多了一个变化。

什么是 Mesh LLM？​

Mesh LLM 是我们正在尝试的一个关联项目，让人们可以把自己的算力（可能只是一台笔记本）点对点连起来，从而访问他们原本可能无法自行托管的模型。

有一个公开演示用的 “mesh”，里面随时会有一些算力；你也可以建立自己的私有网络，把算力汇集起来。mesh 会尽量找出运行模型的最佳位置（按需下载模型），甚至可以用多种方式拆分计算。

这是一个相当早期的项目，我们非常希望听到任何反馈。

请查看项目文档和实时公共 mesh。

goose 从终端起步。最早的版本是一个 Python CLI，在进程内运行智能体——你输入一条消息，模型回应，工具执行，一切都发生在单个循环里。那种简单是一种优势：任何有终端的人都可以立刻开始使用 goose，不用安装应用，也不用运行服务器。

随着 goose 成长，人们想使用它的方式也在增加。我们发布了 Electron 桌面应用，突然就有了两个客户端、两条完全不同的集成路径。Rust CLI 在进程内直接与智能体对话，而桌面应用则经过 goosed，一个自定义的 REST + SSE 服务器。每一项新功能——会话管理、扩展加载、流式传输——都必须在两个地方接上。

第三方开发者一直无法轻松构建自己的客户端，因为他们根本没有标准的连接方式。

我们需要一个单一协议，让任何客户端都能用它到达同一个智能体核心。为此，我们选择了 ACP，即 Agent Client Protocol，作为 goose 新的默认接口。

底层：ACP​

在幕后，我们正在通过 ACP（Agent Client Protocol） 统一每个客户端如何连接到 goose。ACP 给我们一个协议、一个 goose 服务器，服务每一个客户端——终端、桌面、IDE 插件，以及你想构建的任何东西。这将使不同 goose 客户端的生态成为可能。我们也有一份关于 ACP 新 HTTP/WS 传输的 RFD，欢迎对设计提出反馈。

目前的进展：

工作跟踪在 #6642。

新的 goose TUI​

有了这个基础，我们现在正在发布建立在它之上的第一批官方客户端：一个今天就可以试用的全新 TypeScript TUI，以及一个将取代 Electron 桌面应用的基于 Tauri 的桌面应用。对你来说，这意味着终端和桌面上都有更快、更轻的体验——社区也有一条清晰的路径，可以构建新的客户端和集成，而不必反向工程内部实现。

下面是正在发生的事，以及如何开始。

现在就试用新 TUI​

新的基于 TypeScript 的 TUI 处于 beta。它已经支持消息、工具调用、语法高亮的代码和渲染后的 markdown。来试试：

npx @aaif/goose

就这样——一条命令，无需安装。它会拉取最新 beta 并开始一个交互会话。

TUI 接下来会有什么​

• 提供商和模型管理
• 会话列表、恢复和导出
• MCP 功能和 skills 管理的 UI

我们很想听到你的反馈——试试看，告诉我们什么好用、什么不好用。

桌面正在迁到 Tauri​

我们也在把桌面应用从 Electron 重写为 Tauri。Tauri 重写带来更好的性能和焕然一新的 UI，新应用会与 ACP 对话，这样两个官方客户端将共享同一协议和服务器。

桌面准备好进行 beta 测试时，我们会再发一篇跟进文章。

参与进来​

这一切都在公开进行。跟随进展，或直接加入：

• 跟踪 issue： #6642
• 试用 TUI： npx @aaif/goose
• Discord： 在 #goose-2-dev 跟随进展并给出反馈。
• 有反馈？ 开一个 issue，或在 #6642 上留言——我们很想听到你的声音。

过去一年开发者工具最大的转变，不是智能体的兴起，而是智能体订阅的兴起。我们不再挑选 LLM 平台、计算 token。我们开始选择一个智能体 CLI，并支付固定的月费。

这能用，直到你意识到每个智能体都隐含一个特定的前端。Cursor 是它自己的编辑器（VS Code 的一个分支）。Claude Code 起步时只是终端工具。许多智能体只在某一个特定环境里好用。即便像 Copilot 这样有广泛 IDE 支持的智能体，也会把更深的功能绑在自己的生态里。如果你想在喜欢的编辑器里用另一个智能体，往往没办法。

Agent Client Protocol（ACP） 是由 Zed Industries 牵头的社区规范，把智能体和编辑器解耦。goose 在两个方向上实现了 ACP：编辑器可以接入 goose，goose 也可以接入其他智能体。这篇文章走过今天在实践中那是什么样子。

集成问题​

存在几十个智能体。存在几十个编辑器。每一种组合都需要一套自定义集成，并且必须在两边发布更新时跟上。goose 是吃过苦头才明白的。多位社区维护者做了 VS Code 扩展，甚至一个 IntelliJ 插件，但没有一个能跟上 goose 的发布节奏。goose 的每一次改动都意味着更新每一个插件，而插件落在了后面。

ACP 绕开了这一点。和 MCP 一样，ACP 定义了基于 stdio 的 JSON-RPC 协议，但用于智能体与编辑器的通信。编辑器实现客户端接口，智能体实现服务器。模型选择、斜杠命令、文件 I/O 和终端执行这类能力都在 ACP 协议里，不再需要为每个智能体写自定义代码。

用任何编辑器配合 goose​

goose 列在 ACP Agent Registry 里，所以 Zed 和 JetBrains 可以自动发现并安装它。对于还不会读取注册表的编辑器，比如带 avante.nvim 的 Neovim，配置很直接：

acp_providers = {
  ["goose"] = {
    command = "goose",
    args = { "acp", "--with-builtin", "developer" },
  },
},

流过 ACP 的不只是提示。编辑器可以委托文件读取（包括你还没保存的文件）、运行终端命令，并以原生方式呈现权限对话框。你在编辑器里配置的任何 MCP 服务器，都会自动作为该 goose 会话的扩展加入，所以你不必在两个地方配置它们。

更多内容见 ACP 客户端指南。

用任何智能体配合 goose​

goose 也作为客户端说 ACP。它可以把其他智能体编排为 ACP 提供商。你保留 goose 的 UI 和扩展，但底层的 LLM 和 MCP 调用经过另一个智能体。今天这包括 Claude Code、Codex、Copilot、Gemini、Amp 和 Pi。

有些智能体如 Gemini 和 Copilot 原生说 ACP。另一些如 Claude 需要先安装一个小适配器：

npm install -g @agentclientprotocol/claude-agent-acp  # one-time adapter install
GOOSE_PROVIDER=claude-acp GOOSE_MODEL=current goose

把模型设为 current 的意思是“使用底层智能体里配置的任何模型”。

完整列表和设置说明见 ACP 提供商指南。

ACP 今天停在哪里​

ACP 还在 1.0 之前。有些事情已经很好用，有些还没有：

• 权限对话框的渲染因编辑器而异。在 Zed 里看起来原生的东西，在 Neovim 里可能渲染得不同。
• 并非每个智能体都会尊重客户端传来的 MCP 服务器配置。覆盖范围取决于智能体。
• 模型和模式切换的支持各不相同。有些智能体暴露完整的模型列表，有些只暴露别名。
• 协议仍在稳定。随着实现成熟，功能会在稳定性层级之间移动。

这些是真实的边界。协议还年轻。方向是对的。

接下来去哪里​

goose 目前为桌面应用、CLI 和 ACP 服务器各有独立的代码路径。这正在收敛。goose 守护进程正在把 ACP 作为它的协议来过渡，于是每个前端都变成一个薄的 ACP 客户端，与同一个后端对话。提供商选择和配置变更通过 ACP 自定义请求发生，而不是每个前端各写一套逻辑。

在提供商一侧，今天要给 goose 加一个新的 ACP 智能体，意味着写一个 Rust 文件。声明式 ACP 提供商会用 JSON 配置取代这些文件，从而可以在不重新编译 goose 的情况下添加智能体。再加上对 ACP Agent Registry 的原生支持，goose 可以在新智能体出现在注册表时发现并提供它们，不需要一次发布。

试试看​

goose 最近被捐赠给了 Linux 基金会内的智能体 AI 基金会（AAIF）。互操作性是论点：goose 不该把你锁进一个智能体或一个编辑器。

我会在 AI Native DevCon 走过这套架构，每一张幻灯片都链到背后的 PR 或 GitHub 讨论。

选你喜欢的 UI。选你喜欢的智能体。它们不必是同一件事。

• ACP 客户端指南
• ACP 提供商指南
• GitHub 上的 goose
• Discord 社区

Block 已将 goose 捐赠给 Linux 基金会下的智能体 AI 基金会（AAIF），与 Anthropic 的模型上下文协议（MCP）以及 OpenAI 的 AGENTS.md 并列。你可以在这里阅读完整公告。

goose 对使命和社区的投入没有变化，发生变化的是这些：

新的文档站点​

文档已迁至新站点：https://goose-docs.ai/，用上了漂亮的 .ai 顶级域名！旧文档链接会重定向，请把书签更新到新站点。

更新后的 GitHub 仓库​

GitHub 仓库及相关项目已从 block/goose 迁到一个新组织：

https://github.com/aaif-goose/goose

这也包括 aaif-goose 组织中的相关仓库。

其余一切——项目、社区、使命——都保持不变。goose 仍然开源，仍然在积极开发，仍然是你所熟悉的那个智能体。

更新你的远程地址​

如果你有本地克隆，请更新 git remote：

git remote set-url origin git@github.com:aaif-goose/goose.git

迁移仍在进行​

我们仍在处理一些迁移问题（失效链接、重定向、CI 等）。如果你遇到任何看起来不对的地方，请在 Discord 上告诉我们。

了解更多​

访问 aaif.io 了解基金会及其使命。

goose 的愿望之一（至少对我们中的一些人来说）是避免不停地请求权限，把所有决定都推给最终用户，以此来保证智能体执行工具时的安全。有时这会变得非常吵、非常烦，而当你懒得再读、再批准时，结果反而不那么安全。

你当然可以按自己的需要调整设置，但值得想想：怎样才能在不假设可以不断打断用户来请求权限的前提下把事情做安全，尤其是那些他们此刻脑子里可能并没有上下文的事情。

goose 里有多层你可以开启的东西，但我们也想思考更通用的办法。我们观察到各类智能体都非常乐于帮忙，而副作用是会意外造成伤害。于是有了“对抗模式”。想法是：为什么不用另一个智能体来以火攻火。智能体想要帮忙，可以被定向为帮助用户；另一个则可以被定向为防范智能体“帮助”用户，让事情保持在策略之内，并且安全。

什么是对抗模式？​

对抗模式增加一个沉默、独立的审查者，在需要时于每次敏感调用执行之前进行评估。把它想成一位有安全意识的同事，在智能体身后看着——它知道你最初要求的是什么，并能发现什么时候事情对不上。它使用与主智能体同一档次的模型（理想情况下）或更好的模型，并且自己作为一个小型智能体运行（上下文更小，所以更快、更便宜，因为它必须经常被调用，我们不想把成本直接翻倍！）。

也有基于模式的提示注入检测，但当你启用对抗模式时，审查者理解上下文。它看到你的原始任务、最近的消息和工具调用细节，然后做出判断：ALLOW 或 BLOCK。

配置很简单（就是普通语言，智能体或人都可以认同，因为评估它的是一个智能体）。

它如何工作​

1. 在每次工具调用之前，对抗者检查你的原始任务、最近的对话，以及拟议的工具调用
2. 它对照你的规则评估，并返回 ALLOW 或 BLOCK
3. 被阻止的调用会被拒绝——主智能体看到拒绝，并且不能重试
4. 如果审查者因任何原因失败，调用会被放行（失败即开放）

对抗者使用 goose 已经配置好的同一模型和提供商。不需要额外的 API 密钥或设置。

打开它​

在 ~/.config/goose/adversary.md 创建一个文件，写入你的规则：

BLOCK if the tool call:
- Exfiltrates data (posting to unknown URLs, piping secrets to external services)
- Is destructive beyond the project scope (deleting system files, wiping directories)
- Installs malware or runs obfuscated code
- Downloads and executes untrusted remote scripts

ALLOW normal development operations like editing files, running tests,
installing packages, using git, etc.

就这样。文件存在 → 对抗模式开启。删除文件 → 关闭。空文件使用合理的默认值。

为什么不只用模式匹配？​

基于模式的检测很适合抓住已知的攻击特征，goose 也支持这一点。对抗审查者能分辨 curl 是在下载依赖，还是在把你的 SSH 密钥外传——因为它知道你实际要求的是什么。它甚至能察觉智能体是否在创造性地、分段地写脚本，把数据送到一个公开 URL（再次强调，是为了帮忙！），而这不会被模式、规则或过滤器明显抓住。

两种方法是互补的。两个都用。把所有层都用上！

下一步​

我们把对抗模式看作更广泛安全故事中的一层。要了解背后更深的思考，请看我们关于把 CORS 模型应用到智能体安全的文章。

完整配置细节——包括如何扩大哪些工具会被审查——见对抗模式文档。

Gemini 现在通过 OAuth 工作——用你的 Google 账号登录即可。在撰写本文时，claude 只需要安装一个小工具，而且只需安装一次。

为什么用订阅？​

因为你可以用已经在付费的东西。这很明显！会话等等仍然在 goose 里。 ACP 提供了比把 CLI 当作提供商更深的连接。在这个世界里，你可以把它想成一层智能体栈： goose 通过 ACP 接入 gemini（以及其他东西，客户端也可以接入 goose！），但 gemini（以及 claude code）本身也在一定程度上充当智能体循环。 使用 ACP 时，你用的是底层智能体里（大部分）已有的工具。而 Codex 是完整能力的 LLM API，所以对它你可以在 goose 里原生使用扩展。

Claude Code — 通过 ACP​

如果你有 Claude Code 订阅，可以通过 Agent Client Protocol（ACP） 在 goose 里使用它。这需要安装一个小型适配器包：

npm install -g @agentclientprotocol/claude-agent-acp

然后通过 claude acp 扩展配置 goose 来使用它（CLI 或 GUI）

或者通过环境变量设置：

export GOOSE_PROVIDER=claude-acp
goose

goose 会通过 ACP 把你的 MCP 扩展传给 Claude，所以你在 goose 里配置的任何自定义 MCP 服务器，智能体都可以使用。

ChatGPT — 用你的账号登录​

如果你有 ChatGPT Plus 或 Pro，chatgpt_codex 提供商让你用现有账号使用 goose。首次设置 goose 应用时（或切换到该提供商时），选择 ChatGPT 即可。

第一次运行时，goose 会打开浏览器窗口，让你用 ChatGPT 账号登录。之后，会话会缓存在本地。

推荐模型是 gpt-5.3-codex，它也是默认模型。你也可以在模型选择器里选择 gpt-5.4（OpenAI 最新的 omni 模型）或 gpt-5.2-codex。

Gemini — 通过 OAuth​

如果你的 Google 账号可以访问 Gemini，Gemini（gemini_oauth）提供商让你用现有账号使用 goose。首次设置 goose 时（或更换提供商时），选择 Gemini 即可。

第一次运行时，goose 会打开浏览器窗口，让你用 Google 账号登录。之后，会话会缓存在本地。

旧的 CLI 提供商呢？​

goose 以前支持把 claude-code、codex 和 gemini-cli 当作“透传”CLI 提供商。它们很快会被移除，因为 ACP 才是未来！

速查​

选一个和你已经在付费的服务匹配的，就可以开始了。

如果你以为 WebMCP 只是一个 MCP 服务器，请举手。我认罪。我也这么以为。事实证明它是一项 W3C 标准，使用与 MCP 相似的概念。下面是它实际是什么。

什么是 WebMCP？​

WebMCP 是网站定义动作、让 AI 智能体可以直接调用的一种方式。

通常，当智能体与网站交互时，它必须解释界面。它看着页面，试图找到输入框，点击按钮，并希望自己在与正确的元素交互。这个过程能用，但它是间接的，而且常常脆弱。

有了 WebMCP，网站去掉了那一层猜测。站点不再迫使智能体弄清 UI，而是暴露代表它支持的动作的函数。

所以智能体不必模拟用户流程，比如在输入框里打字再点按钮，而是可以调用类似这样的东西：

set_background_color({ color: "coral" })

在这种情况下，智能体不是在试图理解页面布局或一步步导航。它在调用网站明确定义的函数，这让交互更直接、更可靠。

WebMCP 不是 MCP​

这是最重要的部分。MCP 和 WebMCP 解决相似的问题，但它们在完全不同的地方做这件事。

用 MCP 时，你运行一个暴露工具的服务器。你的智能体连接到那个服务器并调用那些工具。你负责构建它、托管它、处理认证，并随时间维护它。用 WebMCP 时，一切发生在浏览器里。网站自己定义工具，智能体通过访问页面发现它们。这次交互没有单独的服务器要部署。

另一种看法是：MCP 是你围绕想访问的系统构建的东西，而 WebMCP 是网站构建进自身的东西。

为什么存在 WebMCP​

当你看到人们在规模上使用 MCP 时撞上的限制，WebMCP 背后的理由就更说得通。当团队试图构建大型 MCP 服务器时，他们往往最终得到太多工具，模型无法有效推理。除此之外，认证变得复杂，因为每个服务都有自己的要求，把这一切放在一个地方管理很困难。

浏览器已经解决了其中很多问题。当你登录一个网站时，你的会话、cookie 和认证状态已经就位。那套系统存在了多年，并且可靠地工作。WebMCP 建立在这个想法上，让网站在那个已认证的上下文里暴露自己的动作，而不要求一个单独的服务器来管理一切。

WebMCP 不是 Playwright MCP 服务器​

我直播了自己第一次探索 WebMCP，一个常见问题是：“这和 Chrome DevTools MCP 服务器或 Playwright MCP 服务器是一回事吗？”它们不是一回事。

这些 MCP 服务器启用浏览器自动化。浏览器自动化允许智能体通过与界面交互来控制浏览器。智能体可以截图、读取 DOM、点击元素、在输入框里打字并导航页面。这在任何网站上都能用，但智能体必须解释它看见的东西并决定如何行动。

WebMCP 采取不同做法。它只在实现了它的网站上工作，但当网站实现了它，智能体完全不需要解释 UI。网站提供结构化动作，智能体直接调用它们。

实践中，这个差别改变了交互模型。用浏览器自动化时，智能体跟随一串近似用户会做的步骤。用 WebMCP 时，智能体跳过那个过程，直接调用底层动作。

如果你在用 goose，Chrome DevTools MCP 仍然有用，因为它把 goose 连到浏览器。它充当桥梁。智能体与站点交互方式的改进来自 WebMCP 本身。

实践中的 WebMCP​

为了更具体，想想从餐厅网站订餐。没有 WebMCP 时，你需要构建能理解那个站点如何工作的东西。这包括画出下单流程、处理登录、解析菜单和提交订单。每当站点变化，你也需要维护那套逻辑。如果你想支持多家餐厅，你得为每一家重复这个过程。

有了 WebMCP，餐厅定义一个像 place_order 这样的工具。站点已经知道自己的菜单结构、修改选项和结账流程。它也已经处理认证。智能体不必在外部重建这一切，只需调用站点提供的工具。

为什么它重要​

这种做法突出有几个原因。网站已经比任何外部系统更理解自己的结构和逻辑。WebMCP 允许它们把那份知识编码一次，并提供给任何智能体。认证已经在浏览器内处理，这去掉了 MCP 服务器否则需要管理的大量复杂度。维护也转移到正确的地方。当网站变化时，拥有它的人更新他们的工具。你不再负责维护你不控制的系统的集成。

构建一个 WebMCP 站点​

为了更好地理解这一点，我做了一个简单的取色器演示，暴露一个动作：改变页面的背景色。

结构看起来是这样：

my-webmcp-site/
├── index.html
├── style.css
└── webmcp.js

HTML 是一个基本页面：

<!DOCTYPE html>
<html>
<head>
  <title>WebMCP Color Picker</title>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <div class="container">
    <h1>🎨 Color Picker</h1>
    <p>Ask an AI to change my background!</p>
    <p>Current color: <span id="colorName">#6366f1</span></p>
  </div>
  <script src="webmcp.js"></script>
</body>
</html>

WebMCP 功能来自注册一个工具：

if (window.navigator.modelContext) {
  window.navigator.modelContext.registerTool({
    name: "set_background_color",
    description: "Change the background color of the page",
    inputSchema: {
      type: "object",
      properties: {
        color: { type: "string" }
      },
      required: ["color"]
    },
    execute: ({ color }) => {
      document.body.style.backgroundColor = color;
      document.getElementById("colorName").textContent = color;

      return {
        content: [{
          type: "text",
          text: `Background color changed to ${color}`
        }]
      };
    }
  });
}

一旦注册，智能体访问页面时就可以发现并调用这个工具。让我印象深刻的一个细节是描述有多重要。模型用那个描述来决定何时调用工具、提供什么输入，所以具体会有差别。

定义工具的两种方式​

你可以在 JavaScript 里定义工具，这对动态行为以及需要更多控制的应用很合适。还有一个更简单的选项，用表单属性直接在 HTML 里定义工具：

<form 
  toolname="subscribe_newsletter"
  tooldescription="Subscribe an email address"
>
  <input 
    type="email" 
    name="email" 
    required
  />
  <button type="submit">Subscribe</button>
</form>

在这种情况下，浏览器自动把表单变成一个工具。这种方法适合你不需要自定义逻辑的简单用例。

把 goose 连到 WebMCP​

因为 WebMCP 跑在浏览器里，你需要一种方式让 goose 与它交互。这就是 Chrome DevTools MCP 进来的地方。它充当 goose 和浏览器之间的桥梁，允许智能体访问 WebMCP 工具。

我测试时注意到的一件事是，单靠提示并不总是足以让智能体使用 WebMCP。我必须提供提示，解释如何发现和执行工具：

const tools = await navigator.modelContextTesting.listTools();
const result = await navigator.modelContextTesting.executeTool("toolName", JSON.stringify({}));

没有那份指引，智能体会默认走浏览器自动化，因为那是当前模型更熟悉的。随着 WebMCP 变得更常见，这可能会变得不那么必要，但现在它有助于引导行为。

目前，WebMCP 只在选择实现它的站点上工作，这限制了它能被多广泛地使用。与此同时，方向很重要。网站可以定义自己的能力，让智能体以结构化方式与它们交互，而不是让智能体试图解释界面。这次转变减少猜测，简化集成，并把责任移到已经最理解自己的系统上。它仍然早期，但这个模型比试图自动化网上每一个界面更说得通。

资源​

• WebMCP 取色器演示
• WebMCP 航班演示
• WebMCP 披萨演示
• 逐步教程
• WebMCP 早期预览文档
• Chrome DevTools MCP
• WebMCP GitHub

如果你和我一样，决定午餐吃什么比它该有的难度更大。再加上饮食限制（我有乳糜泻，所以必须吃无麸质），突然找一家餐厅就变成一整项研究。搜索菜单，交叉核对评论，检查那一份三明治到底有没有麸质……这很累。

如果你的 AI 智能体能替你处理这一切呢？

有了 goose 里的 Neighborhood 扩展，事情正是这样。你告诉 goose 你在哪里、你需要什么，它就找到附近的餐厅，给你看带照片的交互式菜单，把菜加进购物车，并一路把你带到结账，全程不离开聊天。你走出 goose 的唯一时刻，是点一下“支付”。

让我带你走过它如何工作。

设置 Neighborhood 扩展​

首先：你需要安装这个扩展。在 goose Desktop 里，点击 Extensions，然后 Browse Extensions，搜索 “Neighborhood”。

你会马上看到它：发现附近的餐厅，浏览菜单，并通过自然对话下外卖订单。 卖家目前位于美国，但即使你在美国以外，也值得试一试，只为看看这种体验。

安装之后，确保扩展在当前聊天会话里已启用。你可以点击聊天里的扩展图标，打开 Neighborhood 来检查。

找到真正适合你的餐厅​

有趣的地方在这里。你不必打开外卖应用、在几百个选项里滚动，只要告诉 goose 你需要什么：

I'm looking to get lunch today. I'm at 375 West Broadway, New York. I'm gluten-free and I'm playing sport later, so looking for something light. Use the neighborhood extension to find options for me.

就这样。一条提示。goose 拿走你的位置、饮食需求，甚至你稍后要运动这件事，并用这一切找到合适的餐厅。

在幕后，goose 用你的地址和最大距离调用 Neighborhood MCP 服务器的 get-restaurants-nearby 工具，作为回报得到一份 JSON 格式的餐厅列表。但你看到的比原始 JSON 好看得多。

交互式餐厅卡片直接出现在聊天里，成为一个可以用箭头滚动的轮播，展示 Square Restaurant、Kat's Gelateria、Steam & Sip 等等，每一家都有类别、地址和一个 View menu 按钮。没有浏览器标签。没有切换应用。全都在那里。

goose 不只是列出餐厅。它会考虑你的处境。鉴于我的无麸质和清淡餐需求，goose 突出了几个显眼的地方：Kale & Things 作为清淡健康午餐的完美选择，Ba'al Falafel 因为炸豆丸饼常常对无麸质友好，以及 Pantry New York 的更清淡选项。它甚至问我是否想拉出菜单，这样我们可以在比赛前找到无麸质又清淡的东西。这种上下文推理，正是它和普通外卖应用感觉如此不同的地方。

就在聊天里浏览带图片的菜单​

这是真正让我震惊的部分。

当你让 goose 打开一家餐厅的菜单，或点击查看菜单按钮时，它给你的不只是一份文本列表。得益于 MCP Apps，你得到一份直接在聊天里渲染的完整交互菜单，带有分类标签、食物照片、价格和描述。

I'd like to view the Ba'al Falafel menu.

三明治。沙拉。套餐和米饭。汤。糕点和甜点。配菜。饮料。自制饮料。冰沙。餐饮。全都在，而且都可以浏览。你可以点过分类标签，滚动菜品，并在下单前确切看到你在点什么。

我可以点击 Salads 看 Couscous Salad、Red Cabbage Salad 和 Beets Apple Salad，再翻到 Homemade drinks 看 Mint Lemonade、Ginger Lemonade 和 Watermelon Basil，全程不离开聊天窗口。

这不是一份被剥光的文本菜单。这是由在 goose 内部渲染的 MCP App 驱动的真实、视觉、交互体验。

与此同时，goose 也在帮我做决定。它提醒我，对于无麸质、清淡的午餐，沙拉（Tzatziki、Shepherd、Beets Apple、Red Cabbage、Grilled Zucchini）和鹰嘴豆泥、烤花椰菜、baba ghanoush 这类配菜是最好的选择。它甚至警告我避开任何带皮塔饼、库斯库斯、布格麦或菲洛酥皮的东西。有帮助，也诚实。

组建订单​

浏览完菜单并做出选择后，我只要告诉 goose 我想要什么：

Let's add the Beets Apple Salad, Lentil Soup, and a Ginger Lemonade.

goose 把一切加进购物车，并在聊天里把它渲染成另一个交互式 MCP App：

就是它，我的 Beets Apple Salad（8.00 美元）、Lentil Soup（5.50 美元）和 Ginger Lemonade（3.50 美元）。小计：17.00 美元。还有一个大大的 Check out 按钮准备好了。

goose 甚至确认：“你的购物车准备好了！🎉 一份清淡、无麸质的午餐，为你的比赛补充能量。”

如果我想改，加一道菜、去掉一样、换一杯饮料，我只要用自然语言问 goose，它就会更新购物车。不必摆弄加减按钮。

结账，你离开 goose 的唯一时刻​

当你点击 Check out 时，你会被带到由 Cash App 驱动的支付页面。这是发生在 goose 之外的一步，而且理由充分：支付需要安全，并被直接处理。

从那里你可以看到取餐时间，输入电话号码，用 Google Pay 或信用卡支付，加小费，兑换优惠券，甚至留一句备注（比如“请确保无麸质！”）。然后你下单，去取午餐。

整个流程，从“我饿了”到“订单已下”，始于一条提示。

为什么这重要​

这不只是一个酷演示。它是 AI 智能体如何改变日常任务的一瞥。

想想这里发生了什么：

• 一条提示取代了打开应用、搜索餐厅、按饮食需求过滤、读评论、浏览菜单和加入购物车
• 感知上下文的推荐意味着 goose 把我的无麸质饮食和晚上的运动计划都考虑进去，而不必我去搜“我位置附近的无麸质运动前餐”
• 交互式 MCP Apps直接在聊天里渲染带照片的丰富视觉菜单，不需要浏览器

Neighborhood 扩展是 MCP 服务器超越文本时能做什么的完美例子。通过把工具调用和用于丰富 UI 的 MCP Apps 结合起来，体验更不像在和聊天机器人说话，而更像有一个真正了解这个街区的个人助理。

自己试试​

准备好用 goose 订午餐了吗？开始方法如下：

1. 安装 Neighborhood 扩展，goose Desktop 的一键安装，或在 CLI 里通过 goose configure 添加
2. 告诉 goose 你在哪里、你想吃什么，包括饮食需求、你稍后要做什么，或任何其他上下文
3. 浏览菜单，点过交互式餐厅卡片和菜单标签
4. 组建订单，用白话告诉 goose 你想要什么
5. 结账，点击按钮并完成支付

更多细节见 Neighborhood 扩展文档，并试着把它和日历等其他 goose 扩展组合，得到更强的工作流。

观看完整演示​

看整个流程的实际效果：

我们推出了 goose 资助计划，为构建智能体 AI 未来的开发者提供 10 万美元资助。我们在寻找有雄心、把 goose 推进到新领域的开源项目。今天，我们很高兴介绍其中一位获奖者：goose In A Pond。这个项目把 goose 从桌面带进你的家。

什么是 goose In A Pond？​

goose In A Pond 是建立在 goose 之上的完全本地、隐私优先的智能家居助手。把它想成智能音箱应该成为的样子：一个真正跑在你硬件上的 AI 助手，离线理解你的声音，控制你的设备，并且从不把数据送到云端。

项目由 Jarida 构建，这是一支位于肯尼亚内罗毕的五人开发团队，由 Jerry Ochieng 带领。他们把 goose 的开源智能体框架部署到边缘硬件上，具体是 NVIDIA Jetson Orin Nano，来创建一个模块化的、智能体式的家庭中枢，由你完全拥有和控制。

市面上的智能助手并不少，但它们大多有同一个问题：依赖供应商和云，并把你的数据当成属于别人的东西。goose In A Pond 把这一点完全反过来。

让它突出的是这些：

一切都在本地运行​

所有计算——语音识别、语言建模、记忆、设备控制——都发生在设备上。没有云。没有外部服务器。没有数据离开你的家。团队选择 Jetson Orin Nano 作为主要平台，它可以以每秒 40–70 个 token 运行量化的 1–7B 参数语言模型。这足够快，可以在不需要互联网连接的情况下进行自然的对话式交互。

真正能用的离线语音​

这个项目最酷的部分之一，是完全离线的语音流水线。以 goose 实验性的 Perception 扩展 为基础，系统监听唤醒词（自然是 “goose” 🪿），然后切换到更高质量的转写模式来捕捉你说的话。唤醒词检测、语音识别和文本转语音都使用 Whisper、Vosk 和 Coqui TTS 等开源模型在本地运行。

他们在 Raspberry Pi 5 上的早期基准显示，响应时间可用，只有几秒延迟，在低连通性环境中与商业云助手相当（有时更好）。

智能设备控制​

对于有标准 API 的设备（智能灯泡、开关等），goose In A Pond 通过 zigbee2mqtt 和 HTTP/MQTT 等协议集成。但那些没有开放 API 的设备呢？

团队对此也有答案：

• 红外发射，用连接到 GPIO 的红外 LED 控制电视和空调等老设备
• Android 沙箱，通过 ADB 和 UIAutomator 自动化不暴露 API 的专有应用
• 蓝牙和 USB 控制，与传感器和外设直接通信

他们实质上是在把 goose 建成你整个家的万能遥控器——开放还是封闭生态，都没关系。

会自我改进的助手​

goose In A Pond 不只是一个静态工具。通过 goose 的记忆扩展和反馈回路系统，它学习你的偏好，调整自己的行为，并随时间打磨自己的提示。团队也在探索自我精炼技术，让系统分析自己的会话日志来优化自动化行为。这是那种你用得越多就越好的智能体。

移动伴侣​

项目还包括一个叫 goose On The Go 的移动伴侣应用。想法是从手机控制你的家庭助手，无论你在沙发上还是出门在外。实时仪表盘、语音和文本输入、推送通知和远程命令执行，全部连回你的本地 goose 实例。

他们正在构建的 MCP​

这个项目对更广泛的 goose 社区如此有价值，部分原因是 Jarida 团队计划开源的一组 MCP 服务器和扩展：

• Moonbeam MCP — 一个 Android UI 自动化服务器（可以想成给 Android 用的 Playwright），通过应用控制智能设备
• Local Vision Event Detection MCP — 在本地处理摄像头画面，用于运动检测、宠物检测、包裹到达等
• Offline ASR / Voice Command MCP — 完全本地的语音处理，带唤醒词检测和命令解析
• Sensor Data Aggregator MCP — 从本地传感器（温度、湿度、运动、电表）收集数据，并通过 MCP 暴露
• Local Routine / Scheduler MCP — 用自然语言定义自动化，比如“早上 7 点，打开灯和咖啡机”
• Privacy Audit / Logs MCP — 监控 goose 在做什么，跟踪设备活动，并标记潜在的隐私问题
• Inter-Agent Coordination MCP — 让多个 goose 智能体协调任务并共享上下文

这些扩展不只会驱动 goose In A Pond，也会提供给 goose 社区里的任何人使用和在其上构建。

认识 Jarida 团队​

Jarida 团队是东非天主教大学的五位毕业生，他们围绕一个共同信念聚到一起：开源不只是构建软件的好方式，它是正确的方式。他们年轻、饥渴，并全身心投入这个项目。

• Jerry Ochieng — 团队负责人与设备端智能负责人。后端工程师、AI 爱好者，也是训练了肯尼亚手语到英语的设备端模型的人。
• Liz Wangui — 产品与开发者关系负责人。带来 Red Bull Kenya 的市场经验，以及后端工程的技术能力。
• Emmanuel Charles — 后端与安全负责人。持有 ISC² 认证，有网络云运维背景，确保一切保持私密和安全。
• Africia Kerubo — UI/UX 与 AI 负责人。把以人为本的设计与 AI 融合，做出感觉自然的界面。
• Purity Wanjiru — 移动、QA 与自动化负责人。持有 Cisco 道德黑客认证，负责 goose On The Go 的移动设计。

他们也由 Google 高级 UX 研究员 Obinna Anya 和 Google 肯尼亚 Android 增长负责人 Harold Nyikal 指导。

接下来​

团队有一份为期一年、分成四个季度的路线图：

1. 第一季度 — 让 goose 在 Jetson 硬件上本地运行，具备语音输入和离线 LLM 响应，处理基本任务
2. 第二季度 — 通过原生和沙箱方法控制智能设备，加上移动伴侣应用
3. 第三季度 — 自我改进的智能体能力、家庭安防摄像头集成，以及记忆精炼
4. 第四季度 — 完整开源发布，带安装文档、开发套件、起步模板、演示视频和社区反馈系统

到结束时，goose In A Pond 应该是任何人都可以安装、定制和贡献的东西。

goose 资助计划的存在，是为了支持那些把 goose 推进到我们尚未想象之处的项目。goose In A Pond 正是如此。它把 goose 从你笔记本上的开发者工具，变成跑在边缘硬件上的完整家庭助手——完全本地，完全开放，完全属于你。

我们迫不及待想看到 Jarida 团队做出什么。如果你想跟随进展，加入 goose 社区，并留意项目推进时的更新。

如果你自己对 goose 能做什么有一个大胆的想法？goose 资助计划 也许适合你 🪿

goose v1.25.0 来了，这是我们迄今最重要的发布之一。这个版本带来用于增强安全的 macOS 沙箱、统一 summon 扩展带来的重大架构简化、MCP 应用的丰富 UI 渲染，以及一波对智能体 CLI 提供商的改进。无论你跑的是 goose Desktop 还是 CLI，这次发布里都有给你的东西。

让我们拆开有什么新内容。

🔒 macOS 沙箱​

v1.25.0 的头条功能，是 goose Desktop 在 macOS 上可选的安全沙箱。

goose Desktop 增加了一个可选的 macOS 沙箱（通过 GOOSE_SANDBOX=true 启用），由 seatbelt 驱动，这是 Apple 用来沙箱化自己应用的同一底层技术。

它当时提供的是：

• 文件系统限制： 可以限制 goose 读写哪些目录，防止它修改自己的配置，或访问项目之外的敏感区域。
• 网络可见性： 你可以跟踪并限制 goose 访问哪些 URL。
• 零开销： 沙箱使用 macOS 内置的 sandbox-exec 设施，所以没有性能惩罚。
• 适用于任何工具： 因为沙箱发生在操作系统层面，无论 goose 使用哪些 MCP 扩展或工具，它都适用。

🧩 统一的 Summon 扩展​

我们用一个统一的 “Summon” 扩展 取代了两套独立系统（子智能体和 Skills）。

以前，goose 有两种不同的委托工作机制：子智能体（用于拉起独立的子任务）和 Skills（用于加载预定义能力）。它们以令人困惑的方式重叠，让系统更难理解。

新的 Summon 扩展把两个概念统一成两个干净的工具：

• load：把 Skills 和配方加载进 goose 的上下文，取代旧的 Skills 系统。
• delegate：把任务委托给一个独立运行、有自己上下文的子智能体，取代旧的子智能体系统。支持临时指令、预定义的子配方，或两者结合。

这种简化意味着：

• 要理解的是一个扩展，而不是两个
• goose 如何处理委托的心智模型更干净
• 子配方和 skills 自然地一起工作
• 旧的 skills 扩展现已弃用，如果仍然配置着，会被优雅地忽略

🖼️ MCP Apps UI 集成​

MCP 扩展现在可以直接在 goose Desktop 内部渲染丰富的交互式 UI。

这次发布集成了 @mcp-ui/client SDK 的 AppRenderer，大幅升级了 MCP 应用 如何显示内容。MCP 扩展不再限于文本输出，现在可以提供完整的 HTML/JavaScript 界面，在聊天里内联渲染。

关键改进包括：

• 回退请求处理器支持。 应用可以向 MCP 服务器发回请求以获取动态数据。
• 把 rmcp 升级到 0.15.0。 goose 现在向服务器宣告 MCP Apps UI 扩展能力。
• 独立 goose Apps 过滤。 Apps 页面现在过滤为只显示独立的 goose Apps，让发现更干净。

这打开了全新一类 MCP 扩展，它们可以就在你的 goose 会话里提供仪表盘、可视化、表单和其他交互体验。

📝 从 GUI 编辑配方的模型和提供商​

你现在可以直接在 goose Desktop 里编辑配方的模型、提供商和扩展。不需要编辑 YAML。

配方已经让你用特定指令、扩展和配置定义可复用的工作流，而且你一直可以编辑底层 YAML 文件。但为配方切换模型或提供商，意味着在配置文件里寻找正确的字段。

有了 v1.25.0，桌面应用让你按配方可视化配置这些设置：

• 更改配方使用的模型和提供商
• 添加或移除扩展
• 立即保存并运行更新后的配方

与此同时，配方详情视图现在会正确显示配方自身配置里指定的提供商和模型，而不是显示你的全局默认值。这意味着如果你有一个代码审查配方被设为始终在 Claude Sonnet 上运行，UI 会准确反映这一点，而不管你的默认提供商设置是什么。

🤖 智能体 CLI 提供商升级​

Claude Code、Codex 和 Gemini CLI 在这次发布中都得到了重大升级。

goose 的智能体 CLI 提供商把工作委托给其他 AI 编程智能体，这次得到一批改进，让它们明显更有能力：

MCP 扩展现在能与智能体提供商一起工作​

这是一件大事。以前，MCP 扩展只与基于标准 API 的提供商一起工作。现在，Claude Code、Codex 和 Gemini CLI 都可以使用 MCP 扩展。

在底层，goose 把你的扩展配置转换成每个 CLI 期望的原生格式：

• Claude Code 得到 --mcp-config JSON
• Codex 得到 -c mcp_servers.* TOML 覆盖

这意味着无论你用哪个提供商，都可以使用同样的 MCP 扩展。

Claude Code 流式输出​

Claude Code 现在实时流式输出，而不是等待完整回复。你会在 Claude Code 工作时看到结果出现，让长时间运行的任务感觉响应快得多。

Claude Code 动态模型切换​

使用 Claude Code 时，你现在可以列出可用模型，并在会话中途切换模型。不必只因为想为一个更简单的任务从 Sonnet 换到 Haiku 就重启会话。

Gemini CLI 的 Stream-JSON 和会话复用​

Gemini CLI 提供商现在使用 stream-json 输出以获得更好的实时反馈，并复用会话，以提高多次交互的效率。

✨ CLI 中的流式 Markdown​

CLI 中的 Markdown 渲染现在智能地流式进行，而不是渲染不完整、破损的输出。

如果你曾经在 goose 流式回复时，看见半个粗体标签或一个破掉的代码块在屏幕上闪过，这个修复就是给你的。新的 MarkdownBuffer 引入一个状态机解析器，跟踪未闭合的 markdown 结构（粗体、代码块、链接等），并且只在结构完整时才把内容刷新到终端。

结果是：平滑、格式正确的 markdown，逐步渲染，没有视觉故障。

🛡️ SLSA 构建来源证明​

每一个 goose 发布产物现在都带有签名的来源证明。

供应链安全很重要。从 v1.25.0 开始，每一个 CLI 二进制、桌面捆绑包、Linux 包和 Docker 镜像都通过 Sigstore 获得一份 SLSA（软件产物的供应链级别）构建来源证明。

这意味着你可以用密码学验证任何 goose 产物都是由官方 CI 流水线从官方仓库构建的：

gh attestation verify <artifact> --repo aaif-goose/goose

实现覆盖所有发布工作流，包括稳定版、金丝雀构建、夜间构建和 Docker 镜像，并且正确固定了 action、划定了权限范围。

开始使用​

准备好试用 v1.25.0 了吗？前往我们的更新 goose指南，获取 Desktop 或 CLI 最新版本的逐步说明。

完整变更列表见完整的发行说明，并在 GitHub Discussions 加入讨论。

goose 是开源的。在 GitHub 上给我们加星，如果你用 goose 做出了很酷的东西，我们很想听到。

2026 年元旦，当许多人还在从前一晚恢复时，另一种宿醉抓住了每一个被 AI 浸透、长期在线的软件工程师。Steve Yegge 发表了一篇新博客：《欢迎来到 Gas Town》。有些人离开时受到激励，终于要最优地使用他们的智能体；另一些人则纯粹困惑。如果你像我一样，你会两者都有一点。

Yegge 那篇 34 分钟的文章是一幅铺开的愿景，充满未来想法、好玩的角色，以及足够让你头晕的旁支。但传说之下是一次巨大的架构转变。我想退一步，为所有人简化这个“大想法”：Gas Town 是一种哲学，也是一个概念验证，帮助人们协调多个一起工作的智能体。

智能体工程的范式转变​

大多数人按顺序使用 AI 智能体。工作流可以是这样：

• 下午 1:00： 你：“goose，构建 API 端点。”
• [等 10 分钟，再回来看。]
• 下午 1:10： 你：“现在构建前端。”
• [等 10 分钟，再回来看。]
• 下午 1:20： 你：“现在写测试。”
• [等 10 分钟，再回来看。]
• 下午 1:30： 项目完成。

你在 30 分钟内建好了一个项目，这很快，但那段时间的大部分你只是在看进度条。有些工程师开始意识到，如果我们在跑一个智能体，就可以同时再跑五个。

例如，智能体 A 构建 API，智能体 B 可以开始前端，智能体 C 可以写测试，智能体 D 可以调查你一直在回避的那个遗留代码库里的 bug。

人们就是这样把时间买回来的。他们通过跑并行线程，在一小时内完成整个冲刺。（只是别告诉你的老板，因为完成工作的奖励永远是更多工作。）

然而，由于智能体彼此不通信，这种方法带来新问题：

• 合并冲突：两个智能体改了同一文件的同一行，把一切弄坏。
• 丢失上下文：会话崩溃，或者智能体因为说得太久开始幻觉，突然一小时的“工作”消失了。
• 人的瓶颈：你最终在周末派对上或床上不停看手机，确认智能体是否仍在轨道上，让你变成智能体的保姆。

解释 Gas Town​

Gas Town 被设计来停止保姆工作。它在并行智能体之间分配任务，这样你就不必自己做。系统使用：

• Worktrees：这些自动把每个智能体放进它自己独立的工作区，这样它们不会互相踩脚。
• Beads：它用 beads 跟踪进度。如果会话崩溃，下一个智能体会话可以从上一个智能体停下的地方精确接上。
• 通信：每个智能体大声报告它在做什么或观察到什么，这样其他智能体获得必要的上下文。

这个系统也引入一组角色：

• The Mayor：你的主要智能体界面，协调所有其他智能体
• The Polecat(s)：这些是工人智能体。它们在独立的 work tree 上工作，并接受 Mayor 的指令。
• The Witness：观察工人智能体，在它们卡住时推一把，并升级问题以保持系统运行

我不会在这里列出每一个角色（它很深），但要点是：Gas Town 建立一条指挥链，并有共享的通信方式。

介绍 Goosetown​

这正是我们在 goose 正在构建的那种未来思考。所以 goose 团队，具体是 Tyler Longwell，做了我们自己的版本，叫 Goosetown。

Goosetown 是建立在 goose 之上的多智能体编排层。和 Gas Town 一样，它协调并行智能体。和 Gas Town 不同，它有意保持最小，并为研究优先的并行工作而构建。

当你给 Goosetown 一个任务时，主智能体充当 Orchestrator，把工作拆成阶段：研究、构建和审阅。然后它生成并行的被委托者来完成。每个被委托者通过共享的 Town Wall 通信，那是一份只追加的日志，每个智能体在上面发布自己在做什么、发现了什么。

下面是一次会话里真实的 Town Wall 片段，并行的研究者很快在一次转向上看齐：

• [10:14] researcher-api-auth - 🚨 潜在的拦路石：服务调用方的 capabilities 是空的。计划中的认证路径会静默拒绝每一个请求。这需要改代码，不只是改配置。
• [10:14] researcher-endpoints - 💡 发现：原生端点已经存在，依赖极少。替代路径可行。
• [10:15] researcher-source - ✅ 完成。已确认：原生路径不需要任何新依赖。建议转向。

Goosetown 在 4 个组件上运作：skills、子智能体、beads 和 gtwall。

Skills​

Skills 是描述如何做某事的 Markdown 文件，比如“如何部署到生产”。Goosetown 用这些来告诉每个 Delegate 如何做它的具体工作。当一个 Delegate 生成时，它被“预加载”了其角色的 skill（Orchestrator、Researcher、Writer、Reviewer）。

子智能体​

Goosetown 不用一次最终会撞上“上下文悬崖”的长对话做所有事，而是使用子智能体，即临时的智能体实例。它们由 summon 扩展 触发，用 delegate() 把工作交给一个全新的智能体实例。它们在自己干净的上下文里干活，并返回一份摘要，让你的主会话保持快速和聚焦。

Beads​

Goosetown 使用 Beads 跟踪进度，让工作在崩溃后仍能存活。它是基于 Git 的本地 issue 跟踪器。Orchestrator 创建 issue，被委托者更新它们，如果会话失败，下一个智能体捡起这颗 “bead” 并继续工作。

gtwall​

gtwall 是一份只追加的日志，被委托者用它来通信和协调。所有被委托者都会发布并阅读活动。

来自创造者的一句话​

Goosetown 起初是一个有趣的实验，想把我正在为 goose 做的子智能体升级推到极限。我花了一些时间用 Gas Town，觉得一个远没那么铺张的变体，会是一种俏皮的方式，来展示后台子智能体，以及现代 goose 在非常高的层次上编排和管理项目有多好。当我开始把 Goosetown 当作日常主力时，它工作得有多好完全出乎我的意料。

看着子智能体彼此闲聊，每一个都被编排者赋予个性和任务，令人大开眼界。而且好笑。它们像我和同事那样自言自语、来回讨论。即便只是让一个模型以不同上下文的不同智能体的形式，自动把自己的想法弹来弹去，也会让输出更好。

跑一群（蜂群）智能体显然很贵，但工作的整体质量更高，而且要把事情做对我需要的时间少得多。这里肯定有取舍。goose 在这方面有帮助：你可以事先把默认子智能体模型设成更便宜的一个，也可以让主智能体明确、临时地选择它想用于子智能体的模型。

goose 一直在加入新的、令人兴奋的功能。重构和打磨。对 Goosetown，我会继续让它的产物（记忆）系统更稳健，让 Goosetown 内部的通信更顺畅，并让它保持一点点傻气。

— Tyler

开始使用​

准备好自己试试并行的智能体工程了吗？Goosetown 是开源的，可在 GitHub 上获得。克隆仓库，按 README 里的设置说明操作，你很快就能编排多个智能体。如果你对这种工作流还陌生，先看下面的视频，是在深入之前了解真实会话长什么样的好办法。

我参加了一次提示的葬礼。

没有眼泪。只有一屋子开发者，安静地假装他们前一晚没有在喝。因为说实话，大家都看见这事要来，并且它结束了再高兴不过。

说“一次提示已死”并不革命。它只是赶上构建者几个月来一直在经历的事。

那篇比燕麦奶过期更快的博客​

去年，我写了一篇关于如何把提示写得更好的文章。我分享了技巧、措辞建议，甚至说加上几个“请”和“谢谢”，你的 AI 智能体就会把世界给你。当时感觉很前沿，因为它确实是。有整场直播和会议演讲专门讲如何把提示写得更好。

不到一年后，它感觉……过时了。不是因为提示不再重要，而是因为提示不再是主角。

对话从：

“我如何把模型教练得更好？”

变成

“我把这个模型放进了什么样的环境？”

那是一个完全不同的问题，现在它有了名字。上下文工程。

破裂的抽象​

一次提示在智能体还是派对把戏时是有效的。你精心写一条提示，得到一个聪明的答案，而我说的“聪明答案”是指一个完全“能跑”的应用，于是大家都鼓掌。但一旦我们要求智能体规划、记忆、调用工具，并跨多个步骤运作，“有效”的定义就散了。

单条提示不再是解决方案，而变成了瓶颈。现在重要的不是你打的那句话。而是围绕它的系统。提示没有消失，但它们被降级为更大流水线里的一步，这条流水线被设计来保持状态、提前规划并执行护栏。

正如我最近看到的一个帖子里有人说的：

“上下文很差的最好模型，会输给上下文很好的普通模型。”

这句话解释了转变。上下文现在是优势。

这不是理论。你可以在严肃的智能体系统如何被构建中看到它。像 OpenClaw 和 Ralph Wiggum loop 这样的项目不是在追逐聪明措辞。它们在设计环境，让上下文持续存在，决定不断累积，智能体可以跨时间运作，而不必每个会话都重置。

围绕这些系统的兴奋也不只是炒作。它是解脱。构建者一直渴望真正能随时间可预测地运作的工作示例。

这就引到唯一重要的问题……

我实际上怎么做？​

当我开始构建我们的 skills 市场时，单靠一次提示不够用。我平常的工作流是在一个地方研究，在另一个地方实现，每次切换工具我都得重新解释同样的决定。上下文不活在系统里。它活在我脑子里。智能体会忘记，我会记住，整个会话变成补水练习，而不是进展。

实践中那个循环是这样的：

就连这个演示也由持久上下文驱动。

那是我试验 RPI 的时刻。不是因为它时髦，而是因为替代方案已经变得乏味。

你不必明天就采用 RPI 或任何新模式，也能从中受益。你可以在下一次会话里，用开始方式上的一个小改变来模拟这次转变。

在执行任何事之前，把智能体放在仅聊天模式，并运行这次交接。

第 1 步：对齐终点线

确切告诉智能体什么算完成。

“我们要交付的是：___ 成功看起来像：___”

如果终点线对你来说是模糊的，这就是和智能体把它写清楚的时候，否则你的会话会漂走。

第 2 步：锁死不可协商的东西

定义什么没有讨论余地。

“约束：___ 我们承诺的架构：___ ”

这防止经典的智能体螺旋：它不断试图过度设计项目，而不是去构建它。

第 3 步：捕捉持久上下文

写下必须在会话之后仍然存活的事实。

“必须持续存在的上下文： – ___ – ___ – ___”

这是研究、假设、领域知识、边界情况、术语，任何你的智能体需要用来从它停下的地方精确接上的东西。

现在把它存到一个可访问的地方：

• 项目里的一个文件
• 一个上下文文件（goosehints、Cursor rules 等）
• 一个记忆扩展

任何比聊天窗口活得更久的东西。

规则很简单。上下文应该活在系统里，而不是你的脑子里。

这对思考超越代码的人是好消息​

有趣的是，这次转变不只是技术上的。里面藏着一个安静的职业含义。AI 没有在取代工程师。它在取代停在“我的代码能跑，所以我做完了”的工作流。上下文工程奖励一种不同的心态：拿起所有这些不同模式并加以利用的能力，思考决定如何在系统中传播，什么会持续，以及随时间看下游效应是什么样。

那也是我正在积极锻炼的一块肌肉。我越往里靠，方向就越清楚。

真正的技能是编排​

我们参加了它的葬礼，但如你所见，提示并没有真的消失。它只是不再是工作流。

一次提示对演示和探索仍然很好。但当目标是构建比单次会话活得更久的系统时，优势转向你把模型周围的环境设计得有多好。

在这个时代如鱼得水的人，不会是措辞最聪明的人。他们会是知道如何编排上下文，让智能累积而不是重置的人。

老实说，那是进步。

智能体从根本上改变了我们编程的方式。它们让开发者通过去掉传统开发工作流的中间环节而更快前进。这意味着在专门工具之间切换的时间更少，对其他团队的依赖也更少。既然智能体能执行复杂任务，开发者面临一个新挑战：在长会话中有效地使用它们。

最大的挑战是上下文腐烂。因为智能体的记忆有限，跑得太久的会话会让它们“忘记”更早的指令。这导致不可靠的输出、挫败感，以及代码库里微妙但严重的错误。一个有希望的解决方案是 Code Mode。

Code Mode 不向 LLM 描述几十个独立工具，而是允许智能体编写以编程方式调用这些工具的代码，减少模型必须一次持有的上下文量。虽然许多开发者第一次听说 Code Mode 是通过 Cloudflare 的博客，但更少的人理解它在实践中如何工作。

我已经用了几个月 Code Mode，最近做了一个小实验。我让 goose 修它自己的一个 bug：Gemini 模型在 CLI 里处理不了图片，但在桌面应用里可以，然后开一个 PR。修复涉及分析模型配置、追踪图片输入在流水线中的处理，并在重复运行中验证行为。我把同一任务跑了两次：一次启用 Code Mode，一次不用。

下面是我从日常使用和实验中学到的。

1. Code Mode 不是 MCP 杀手​

事实上，它在底层使用 MCP。MCP 是让 AI 智能体连接到外部工具和数据源的标准。当你在智能体里安装一个 MCP 服务器时，那个 MCP 服务器把它的能力暴露为 MCP 工具。例如，goose 的主要 MCP 服务器，叫 developer 扩展，暴露 shell 这样的工具，让 goose 能运行命令，以及 text_editor，让 goose 能查看和编辑文件。

Code Mode 把你的 MCP 工具包装成 JavaScript 模块，允许智能体把多次工具调用组合成一步。Code Mode 是智能体如何更高效地与 MCP 工具交互的一种模式。

2. goose 支持 Code Mode​

Code Mode 支持在 2025 年 12 月随 goose v1.17.0 落地。它作为一个叫 “Code Mode” 的平台扩展发布，你可以在桌面应用或 CLI 里启用。

启用方法：

• 桌面应用： 点击扩展图标，打开 “Code Mode”
• CLI： 运行 goose configure 并启用 Code Mode 扩展

自最初实现以来，我们加了这么多改进！

3. Code Mode 让你的上下文窗口保持干净​

每次你安装一个 MCP 服务器（在 goose 生态里叫“扩展”），它都会给智能体的记忆增加大量数据。每个工具都带一份工具定义，描述工具做什么、接受哪些参数、返回什么。这帮助智能体理解如何使用工具。

这些定义消耗智能体上下文窗口里的空间。例如，如果单个定义占 500 个 token，一个扩展有五个工具，那就是还没开始就没了 2,500 个 token。如果你用多个扩展，你很容易把这个数字翻倍，甚至变成十倍。

没有 Code Mode 时，你的上下文窗口可能是这样：

[System prompt: ~1,000 tokens]
[Tool: developer__shell - 500 tokens]
[Tool: developer__text_editor - 600 tokens]
[Tool: developer__analyze - 400 tokens]
[Tool: slack__send_message - 450 tokens]
[Tool: slack__list_channels - 400 tokens]
[Tool: googledrive__search - 500 tokens]
[Tool: googledrive__download - 450 tokens]
... and so on for every tool in every extension

随着会话推进，有用的上下文被你甚至没用的工具定义挤出去：你正在讨论的代码、你正在解决的问题，或你之前给的指令。这导致性能下降和记忆丧失。虽然我过去建议禁用不用的 MCP 服务器，Code Mode 提供了更好的修复。它使用三个工具，帮助智能体按需发现需要什么工具，而不是预先加载每一个工具定义：

1. search_modules - 找到可用的扩展
2. read_module - 了解一个扩展提供哪些工具
3. execute_code - 运行使用这些工具的 JavaScript

我想看看这有多真实，所以做了一个实验：我让 goose 解决一个用户的 bug 并提交 PR，分别有和没有 code mode。对同一任务，Code Mode 少用了 30% 的 token。

4. Code Mode 把操作批进一次工具调用​

token 节省不只来自预先加载更少的工具定义。Code Mode 也通过一种叫批处理的方法处理对话的“活动”一侧。

当你让智能体做某事时，它通常把你的请求拆成单独的步骤，每一步需要一次单独的工具调用。你可以在聊天里看到这些调用，随着智能体执行任务而出现。例如，如果你让 goose “检查当前分支，给我看 diff，并运行测试”，它可能会运行四条单独的命令：

▶ developer__shell → git branch --show-current

▶ developer__shell → git status

▶ developer__shell → git diff

▶ developer__shell → cargo test

每一次调用都给 goose 必须跟踪的对话历史加一层。批处理把这些合成一次执行。当你打开 Code Mode 并给出同样的提示时，你只会看到一次工具调用：

▶ Code Execution: Execute Code
  generating...

在那一次执行里，它把所有命令批进一段脚本：

import { shell } from "developer";

const branch = shell({ command: "git branch --show-current" });
const status = shell({ command: "git status" });
const diff = shell({ command: "git diff" });
const tests = shell({ command: "cargo test" });

作为用户，你看到同样的结果，但智能体只需要记住一次交互，而不是四次。通过减少这些往返，Code Mode 让对话历史保持简洁，这样智能体可以保持对手头任务的专注。

5. Code Mode 做出更聪明的工具选择​

当智能体能访问几十个工具时，它有时会做出对你的环境在技术上错误的“合乎逻辑”的选择。这是因为在标准设置里，智能体根据简短的文字描述从一份扁平列表里挑工具。当智能体挑了一个听起来对、但缺少必要上下文的工具时，这会浪费大量时间和 token。

我在实验中亲眼看到了这一点。我启用了一个叫 agent-task-queue 的扩展，它被设计来带超时地运行后台任务。

当我让 goose 为我的 PR 跑测试时，它看了可用工具，看见了 agent-task-queue。LLM 推理说测试套件是“长时间运行的任务”，所以那个扩展完美匹配。它选择了专门工具，而不是通用的 shell。

然而，工具调用立刻失败了：

FAILED exit=127 0.0s
/bin/sh: cargo: command not found

我的环境没有被配置成用那个特定扩展来跑我的工具链。goose 基于描述做了一个合理的选择，但对我的实际设置来说是错误的工具。

在 Code Mode 会话里，这个错误从未发生。Code Mode 通过要求明确的 import 语句，改变智能体与其能力交互的方式。

goose 不是浏览一份名字菜单，而必须有意地选择它在用哪个模块。它选择从 developer 模块导入：

import { shell } from "developer";

const test = shell({ command: "cargo test -p goose --lib formats::google" });

通过明确导入 developer，Code Mode 确保测试在我实际的 shell 环境里运行。

6. Code Mode 可以跨编辑器移植​

goose 不只是一个智能体；它也是一个 ACP（Agent Client Protocol） 服务器。这意味着你可以把它连到任何支持 ACP 的编辑器，比如 Zed 或 Neovim。而且，你在 goose 里用的任何 MCP 服务器在那里也能用。

我想自己试试，所以我设置 Neovim 连接到 启用了 Code Mode 的 goose。下面是我用的配置：

{
  "yetone/avante.nvim",
  build = "make",
  event = "VeryLazy",
  opts = {
    provider = "goose",
    acp_providers = {
      ["goose"] = {
        command = "goose",
        args = { "acp", "--with-builtin", "code_execution,developer" },
      },
    },
  },
  dependencies = {
    "nvim-lua/plenary.nvim",
    "MunifTanjim/nui.nvim",
  },
}

关键的一行是我在编辑器配置里直接启用 Code Mode 的那一行：

args = { "acp", "--with-builtin", "code_execution,developer" },

为了测试，我让 goose 列出我的 Rust 文件并统计代码行数。我没有在 Neovim 缓冲区里看到一长串单独的 shell 命令，而是看到一次单独的工具调用：Code Execution。它的工作方式和在桌面应用里完全一样。这种可移植性意味着你可以构建一个强大、高效的智能体工作流，并把它带到你最舒服的任何环境。

7. Code Mode 在不同 LLM 上表现不同​

我用 Claude Opus 4.5 跑实验。结果可能因你使用的模型而异。

Code Mode 要求 LLM 做并非所有模型都同样擅长的事：

• 写出有效的 JavaScript - 模型必须生成语法正确的代码。代码生成能力更强的模型会产生更少错误。
• 遵循导入模式 - Code Mode 期望 LLM 从模块导入工具，比如 import { shell } from "developer"。有些模型可能会不导入就直接调用工具，那会失败。
• 使用发现工具 - 写代码之前，LLM 应该调用 search_modules 和 read_module 来了解有哪些工具。有些模型跳过这一步去猜，导致幻觉出的工具名。
• 优雅地处理错误 - 当代码执行失败时，模型需要读错误、理解哪里错了，并再试一次。有些模型比其他模型更擅长这个反馈回路。

如果 Code Mode 对你效果不好，试试换模型。擅长代码生成和遵循指令的模型，通常会比为其他任务优化的模型在 Code Mode 上表现更好。

8. Code Mode 不是给每个任务的​

Code Mode 增加开销。在执行任何事之前，LLM 必须：

1. 调用 search_modules 找到可用扩展
2. 调用 read_module 了解一个扩展提供哪些工具
3. 写 JavaScript 代码
4. 调用 execute_code 来运行它

对简单的单工具任务，这个开销不值得。如果你只需要运行一条 shell 命令或查看一个文件，常规工具调用更快。

根据我的实验，下面是 Code Mode 说得通的时候：

试试看​

如果你想试验 Code Mode，这里有一些资源：

文档：

• ACP 客户端设置
• 扩展指南

先前的文章：

• Alex Hancock 的 goose 中的 Code Mode MCP
• 我写的 Code Mode 不会取代 MCP

社区：

• 加入我们的 Discord 分享你学到的东西
• 如果有什么不如预期，在 GitHub 上提交 issue

跑你自己的实验，并告诉我们你发现了什么。