Goose 与其他 AI 编程助手的不同之处@慕课网原创_慕课网

我刚刚完成了 Goose 的 Advent of AI 系列挑战，涵盖了从 CI 自动化到手势控制应用，再到带有 UI 的模型上下文协议（MCP）服务器等各种项目。

这些挑战几乎全部都是在 Goose 中完成的。初期主要使用 GUI 界面，随着熟练度提升逐渐转向 CLI 操作。虽然偶尔会切换到 Claude 完成某些任务，但 Goose 始终是我的主要开发环境。我的工作流程是：将挑战需求转化为产品需求文档（PRD），对于复杂项目还会补充评估标准，然后进行具体实现。

经过两周多的深度使用，我可以明确告诉你 Goose 的独特之处。但首先，让我们了解其基础能力。

基础功能特性

Goose 具备你对 AI 智能体的基本功能期待：提供带聊天界面的 GUI、CLI 工具，并且与其他同类工具一样，它支持多种模型（可与任何 LLM 提供商配合使用，包括本地模型）。

此外，它还提供对 MCP、聊天记录、命名会话、并行任务执行子代理、自定义上下文技能的完善支持。作为优秀开源软件的代表，Goose 采用开源模式开发。

这些功能大多并非独家。OpenCode（同样开源）、Cursor、Copilot、Claude Code 和 Windsurf 都具备类似能力。

如果 Goose 仅止步于此，就不值得专门撰文介绍了。

Goose 的真正差异化优势

Goose 并非要与 Cursor 的自动补全或 Copilot 的内联建议竞争，它属于完全不同的类别。你可以将其视为智能体行为的构建系统，而非简单的 IDE 集成工具。

经过深度使用，三个特点尤为突出。（据 Block 公司数据，60% 的员工每周使用 Goose，报告显示开发时间节省 50-75%，这说明我的体验并非个例。）

配方：可复用的 AI 工作流

大多数 AI 工具仅提供保存的提示词或模板，而 Goose 的配方是具备实际能力的结构化工作流定义。

在 Advent of AI 的第 9 天和第 15 天，我使用了配方和子配方构建项目。

配方具体提供以下能力：

工作流阶段参数传递 - 一次性定义 {{event_name}}，全局使用
子配方组合 - 从父配方调用多个子配方
环境扩展 - 自动获取全局配置的 MCP 服务器和内置扩展
显式扩展指定 - 为配方固定特定 MCP 服务器/工具（目前仅支持 YAML）
结构化输入 - 定义带类型、要求和描述的参数

以下是协调三个平台特定子配方的社交媒体活动配方（Advent of AI 第 15 天）示例：

完整 YAML 结构：

version: 1.0.0
title: Social Media Campaign Generator
description: Generate complete cross-platform social media campaign using sub-recipes
instructions: |
  You are a social media campaign coordinator creating a comprehensive multi-platform campaign.

  Generate a complete social media campaign for the following event:
  - event_name: {{event_name}}
  - event_date: {{event_date}}
  - event_description: {{event_description}}
  - target_audience: {{target_audience}}
  - call_to_action: {{call_to_action}}

  Campaign Strategy:
  Execute the following sub-recipes to create platform-specific content:

1. Instagram Content: Run the instagram-post.yaml recipe

2. Twitter/X Thread: Run the twitter-thread.yaml recipe

3. Facebook Event: Run the facebook-event.yaml recipe

  [Format and present complete campaign organized by platform]

prompt: Generate complete social media campaign for {{event_name}}

sub_recipes:
  - name: "instagram_content"
    path: "./instagram-post.yaml"
    values:
      event_name: "{{event_name}}"
      event_date: "{{event_date}}"
      event_description: "{{event_description}}"
      target_audience: "{{target_audience}}"
      call_to_action: "{{call_to_action}}"
  - name: "twitter_content"
    path: "./twitter-thread.yaml"
    values:
      event_name: "{{event_name}}"
      event_date: "{{event_date}}"
      event_description: "{{event_description}}"
      target_audience: "{{target_audience}}"
      call_to_action: "{{call_to_action}}"
  - name: "facebook_content"
    path: "./facebook-event.yaml"
    values:
      event_name: "{{event_name}}"
      event_date: "{{event_date}}"
      event_description: "{{event_description}}"
      target_audience: "{{target_audience}}"
      call_to_action: "{{call_to_action}}"

parameters:
  - key: event_name
    input_type: string
    requirement: required
    description: Name of the festival event
  - key: event_date
    input_type: string
    requirement: required
    description: When the event is happening
  - key: event_description
    input_type: string
    requirement: required
    description: What the event is about
  - key: target_audience
    input_type: string
    requirement: required
    description: Who should attend
  - key: call_to_action
    input_type: string
    requirement: required
    description: What you want people to do

运行此配方时，Goose 会用相同参数执行每个子配方，各子配方处理特定平台细节，父配方负责整体协调。

你还可以为配方固定特定的 MCP 扩展，这虽然目前仅支持 YAML 配置，但对确保工作流可重现至关重要。

典型的工程工作流示例是通过查询 Linear、GitHub 和 Notion 生成周报，具体配方可参考这个代码片段。

配方还可以配置为斜杠命令使用：

配置完成后，只需在 GUI 或 REPL 中输入 /weekly-status 即可获取包含问题链接、拉取请求等信息的格式化报告。

架构意义：

没有配方时，你需要在步骤间复制粘贴提示词并手动传值。而配方提供了版本控制（Git 中的 YAML 可进行差异比较和错误回退）、团队协作（统一工作流而非零散提示词）、组合能力（通过简单组件构建复杂工作流）和调试支持（子配方独立运行）。

这超越了简单的"保存提示词"，而是真正的工作流基础设施。

与规则文件的区别：

大多数 AI 编程工具都支持某种形式的规则。Cursor 有 .cursor/rules，Cline 有 .clinerules，还有跨工具的 AGENTS.md 标准。这些都是项目特定的提示指导，用于优化智能体对代码库的理解。

本质区别在于：规则文件告诉智能体"在此项目中编写代码时遵循这些模式"，而配方要求"按特定顺序执行这些步骤并传递参数"。前者优化提示效果，后者实现工作流编排。

简而言之：规则改变智能体的行为方式，配方改变智能体的执行内容。

规则文件无法组合使用、传递参数或作为独立工作流运行，它们只是优化提示的上下文信息。

配方与子代理的并行工作流

结合子代理功能，配方提供了有效编排并行任务的基础设施。以下是一个生成 4 个并行子代理的视频处理配方：

version: 1.0.0
title: Video Tools
description: A set of tools for processing videos
instructions: |
  You are a video processing assistant

  Process {{video_file}} with real-time progress updates.

  STEP 1 - Immediate acknowledgment:
  Run: echo "🎬 Processing video: {{video_file}}" | tee /dev/tty
  STEP 2 - Check dependencies (ffmpeg, ffprobe)
  STEP 3 - Analyze video (duration, resolution, codec, audio presence)
  STEP 4 - Launch parallel subagents:

  === SUBAGENT 1: Smart Compression ===
  - Analyze video type (screencast vs camera footage)
  - Choose optimal CRF value (18-28 range) based on content
  - Adjust resolution if beneficial (4K→1080p for screencasts)
  - Compress with ffmpeg: -c:v libx264 -crf [chosen] -preset medium
  - Output: {{video_file}}_compressed.mp4
  - Report before/after sizes and compression ratio

  === SUBAGENT 2: Intelligent Thumbnails ===
  - Detect video content type
  - For screencasts: extract at 20%, 40%, 60%, 80%, 100% intervals
  - For camera footage: use ffmpeg scene detection for key frames
  - Generate 5 thumbnails at 320px width
  - Output: {{video_file}}_thumb_1.jpg through _thumb_5.jpg

  === SUBAGENT 3: Audio Extraction (ONLY IF AUDIO DETECTED) ===
  - Extract audio using ffmpeg: -c:a libmp3lame -q:a 2
  - Output: {{video_file}}_audio.mp3
  - Report audio file size and bitrate

  === SUBAGENT 4: Transcription & Analysis (ONLY IF AUDIO DETECTED) ===
  - Run: uv run --with openai-whisper whisper {{video_file}} --model base
  - Output: .txt, .srt, .vtt, .tsv, .json caption files
  - Analyze transcript: word count, speaking pace, content type
  - Brief content summary

  STEP 5 - Monitor subagents and report completions immediately
  STEP 6 - Final summary with all generated files

prompt: process {{video_file}}

parameters:
  - key: video_file
    input_type: string
    requirement: required
    description: The video file to optimize

每个子代理在独立会话中运行，通过 echo | tee /dev/tty 提供实时进度更新。配方负责协调任务、优雅处理故障（如压缩失败仍可生成缩略图）并提供统一摘要。

没有配方时，你需要手动编辑保存的提示词中的文件名，并希望没有遗漏。分享工作流意味着发送整个对话记录。

使用配方后，一行命令 /video-tools any-file.mp4 即可处理视频，还可以通过 goose://recipe?config=... 格式的 URL 深度链接分享配方。

团队协作价值：

配方不仅提升个人效率，更是将智能体工作流转化为团队制度性知识的重要工具。

可审计性：Goose 会话可导出为包含完整元数据的 JSON，包括令牌使用量、模型配置、工作目录和时间戳，便于精确追踪工作流成本和执行情况。

会话导出示例：

{
  "id": "20251228_72",
  "working_dir": "/Users/nicktaylor/dev/oss/wishlist-mcp",
  "name": "Nike Sales Bar Chart",
  "created_at": "2025-12-28T19:53:24Z",
  "total_tokens": 10297,
  "input_tokens": 10034,
  "output_tokens": 263,
  "provider_name": "anthropic",
  "model_config": {
    "model_name": "claude-opus-4-5-20251101",
    "context_limit": 200000
  },
  "conversation": [...]
}

与云模型的批量数据导出相比，Goose 的逐会话导出支持更精细的成本追踪和环境复现。

标准化支持：Goose 是 Linux 基金会 AI 智能体互操作性基金会 (AAIF) 的早期贡献者，配方和 MCP 集成确保与新兴标准兼容。

MCP-UI 渲染支持

大多数 MCP 客户端仅以文本形式显示工具响应，而 Goose 的 GUI 能够将 MCP-UI 组件渲染为实际可交互的控件。

在 Advent of AI 第 17 天，我构建了返回 UI 组件的愿望清单 MCP 服务器。

在 Goose 中，这些组件显示为交互式控件，而在不支持 MCP-UI 的客户端中只会显示为文本。

自动可视化扩展也利用此功能，提供可交互的数据可视化而非纯文本输出。

目前仅有三款客户端完整支持 MCP-UI：Goose、ChatGPT（通过 Apps SDK）和 LibreChat，其他客户端仍停留在文本响应阶段。

终端集成架构

Goose 提供两种模式：完整的 REPL（交互式聊天）和终端集成（@goose "执行任务"）。

终端集成实现了无感知的智能辅助。你在常规终端中工作，按需调用 Goose 执行特定任务，完成后继续原有工作流。

第 13 天示例：

❯ @goose "继续 PRD 开发，上次停留在数据组织阶段"

Goose 会读取 PRD、检查项目进度并告知下一步行动，全部通过单条命令完成，无需会话管理。

这种架构还支持权限分离：

❯ @goose "全局安装此包"
# Goose: "需要执行: sudo npm install -g whatever"
❯ sudo npm install -g whatever  # 用户自行执行权限操作
❯ @goose "继续"  # Goose 检测到操作完成，继续任务

无需切换终端执行权限操作，保持工作流连续性。

终端集成还支持跨终端会话持久化：

eval "$(goose term init zsh --session my-project)"

关闭终端后重新打开，执行相同命令即可恢复之前的对话上下文。

这是将 AI 辅助无缝集成到现有工作流的基础设施，而非替代原有流程。

适用场景与局限性

GUI 界面更适合需要多次交互的复杂任务，终端集成则适用于快速操作或连续性工作。

如前所述，Goose 支持并行执行的子代理，每个子代理在独立会话中运行，单个失败不会影响其他任务执行。

子代理基础设施整体稳定，但在使用 GPT-4.1 时遇到无法生成子代理的问题（令牌不足时切换至此模型），具体原因不明。Anthropic 的 Sonnet 4.x 和 Opus 模型与子代理功能配合良好。

配方 YAML 验证机制有待改进。在第 9 天要求模型生成配方时，多次出现格式错误，即使提供了 https://block.github.io/goose/llms.txt 作为参考。

技术选型建议

不同工具解决不同问题场景：

最佳内联补全：Cursor 或 VS Code 中的 GitHub Copilot
深度 VS Code 集成：GitHub Copilot（原生扩展深度集成）
优质终端体验：Claude Code 或 OpenCode
可复现工作流基础设施：Goose

Goose 特别适用于以下场景：

重复构建同类项目（配方避免重复提示）
希望不离终端获得 AI 辅助（环境模式）
团队需要可复现工作流（Git 管理的 YAML）
需要交互式 UI 的工具开发（MCP-UI 渲染）

技术实践参考

理解 Goose 的最佳方式是尝试 Advent of AI 挑战，虽然本年度的活动已结束，但仍是了解其功能的优质学习资源。

建议从自动化单个重复性任务开始，将其转化为配方，待熟悉后再考虑迁移现有工作流。

可参考我的 Advent of AI 2025 代码仓库查看具体实现。

扩展阅读资源：

RPI 模式（研究→规划→实施）
安全检测工作流（真实团队用例）
代码执行模式（实验性高效 MCP）
Steve Yegge 在 Latent Space 播客关于氛围编码与智能体编排的讨论

封面图片由 Paolo Gregotti 拍摄，来源 Unsplash