我刚刚完成了 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
共同学习,写下你的评论
评论加载中...
作者其他优质文章







