企业官网建设流程全解析

goose v1.25.0 版本深度解读：统一 Summon 扩展、Agentic CLI 增强、GUI 配方配置与构建供应链安全

【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose

goose v1.25.0 是该项目（一个开源、可扩展、可与任意 LLM 协作执行安装、运行、编辑与测试任务的 AI Agent）发布历程中一次重量级版本更新，其官方发布说明收录于仓库 documentation/blog/2026-02-23-goose-v1-25-0/index.md。本文以该发布说明为骨架，结合本仓库的源码实现、扩展文档与桌面端代码，逐项拆解 v1.25.0 的七大主线：macOS 沙箱化实验、统一 Summon 扩展、MCP Apps 富 UI 集成、GUI 中直接编辑 Recipe 的模型与提供商、Agentic CLI 提供商的全面升级、CLI 流式 Markdown 渲染，以及 SLSA 构建来源证明。读完你可以完整掌握这些能力的配置方式、使用姿势与底层实现依据，并能在后续版本中按图索骥。

🔒 macOS 沙箱化：曾经的实验性安全增强与当前的安全基线

发布说明将可选的 macOS 安全沙箱定义为 v1.25.0 的头号特性：当时 goose Desktop 引入了一个可选沙箱，通过GOOSE_SANDBOX=true开启，底层采用 seatbelt 技术（Apple 用于沙箱化自家应用的同一套机制），可提供的保护包括：

• 文件系统限制：限制 goose 可读写的目录，防止它修改自身配置或访问项目之外的敏感区域；
• 网络可见性：跟踪并限制 goose 访问的 URL；
• 零开销：复用 macOS 内置的sandbox-exec，没有性能损耗；
• 适用于任意工具：由于在操作系统层面做沙箱，无论使用哪个 MCP 扩展或工具都一视同仁。

需要特别说明的重要更正：该发布说明在文档内对该小节标注了danger: Outdated提示——上述 macOS seatbelt 沙箱属实验特性，已经被移除。当前gooseserver 进程（负责执行工具的部分）以与你的用户账户相同的权限运行，并未做操作系统层面的沙箱。因此，当前版本请勿再依赖GOOSE_SANDBOX，安全控制应交给 goose 自身的权限模式机制。

在如今的版本中，官方推荐的安全控制手段是GOOSE_MODE（取值如approve、smart_approve），用于限制哪些工具可以在不经过确认的情况下运行。相关变量统一整理在仓库的 环境变量指南（"Tool Configuration" 一节）。安全边界从“进程级 OS 沙箱”回退为“会话级工具权限审批”，意味着权限语义由运行代理的机器转移到 goose 自身的 permission/approval 流程，这在跨平台（Windows/Linux/macOS）部署上更容易保持一致行为。

🧩 Unified Summon 扩展：用 load / delegate 统一"技能加载"与"子代理委托"

v1.25.0 在架构层面的最大简化，是把此前两套相互重叠的机制（subagent 子代理、Skills 技能）合并为一个统一的 Summon 扩展：

• 旧subagents：用于创建独立运行、自带上下文的子任务；
• 旧Skills：用于把预定义能力加载进上下文。

两者在概念上交叉、难以理解。v1.25.0 用 Summon 扩展把两种能力统一为两个干净的工具：

• load：把 Skills/Recipes 等资源加载进 goose 的当前上下文，取代旧的 Skills 系统；
• delegate：把任务委托给一个独立上下文运行的子代理，取代旧的 subagent 系统，支持临时指令、预定义 subrecipe/recipe/agent，或两者组合。

官方给出的收益非常直白：只需理解一个扩展；子代理与 recipe/subrecipe 天然协作；旧的 skills 扩展若仍被配置会被优雅忽略（deprecated）。

扩展的实际形态与工具参数（源码视角）

Summon 扩展在本仓库中的实体实现位于 crates/goose/src/agents/platform_extensions/summon.rs，其注册名为"summon"（见EXTENSION_NAME，源码第 37 行），说明它与 apps、scheduler、todo 等一样，属于 goose 内置的平台扩展族（同目录下可见apps.rs、scheduler.rs、orchestrator.rs等）。该扩展通过create_load_tool（第 645 行起）与create_delegate_tool（第 684 行起）以标准 MCP Tool 的形式对外暴露。

load工具的入参（源码 schema，见 summon.rs）：

delegate工具的入参（源码 schema，见 summon.rs）：

三种 delegate 模式（来自create_delegate_tool的工具描述）：

1. Ad-hoc 临时模式：只提供instructions，执行一次性定制任务；
2. Source 模式：只提供source，运行一个 subrecipe、recipe 或 agent；
3. 组合模式：source+instructions结合（例如source: "deploy", instructions: "deploy to staging"）。

工具描述还给出高效的委托原则：子代理只知道"指令 + source 内容"，无法相互协调，因此同文件写操作会发生冲突；纯只读研究可以放心并行，写任务必须严格按文件分区，推荐的工作流是"拆解任务 → 发起多个async: true后台委托 → 逐个load(source: taskId)收结果 → 汇总"。这背后对应 summon.rs 中一整套后台任务管理设施（BackgroundTask/CompletedTask、CancellationToken、通知缓冲与转发等）。

启用 Summon 扩展

Summon 是内置平台扩展，v1.25.0+ 可用。启用方式以官方 Summon 扩展文档 为准：

• goose Desktop：在扩展设置中直接启用名为 "Summon" 的内置扩展；
• goose CLI：运行goose configure→ 选择Toggle Extensions→ 在扩展列表中用空格勾选summon→ 回车提交。

一个完整的用法示例（官方文档原例）

在.agents/recipes/下创建可复用 reciperelease-notes.yaml：

title: Release Notes description: Draft release notes from recent git changes instructions: | Review the recent git history and changed files. Write concise release notes with: - user-facing changes - fixes - migration notes, if any prompt: Draft release notes for the current branch.

然后在会话中让 goose 委托它：

Use summon to delegate the release-notes recipe for this branch.

对应的自然语言/直接工具调用形式包括（见 Summon 文档 的 "Common Summon Commands"）：

load() load(source: "release-notes") delegate(source: "release-notes") delegate(instructions: "Review these docs and report stale links") delegate(source: "release-notes", async: true) load(source: "20260219_1", peek: true) load(source: "20260219_1")

其中：load()无参调用会列出当前可用资源（subrecipes/recipes/agents，源码中按(类型, 名称)排序并做了 60 秒缓存与去重，见 summon.rs）；后台任务delegate(..., async: true)会返回任务 id（如20260219_1），随后用load(source: "<task_id>")阻塞等待结果、peek: true查询进度、cancel: true取消任务。

关于委托的资源类型，官方文档说明 Summon 可加载三类 source：Recipes（带提示词与参数的可复用任务定义）、Agents（存放在 agent 目录的可复用 agent 定义）、Subrecipes（当前 recipe 私有的子任务）；而 Skills 依然由独立的 Skills 平台扩展 负责加载，二者职责在文档层已被清晰地分离。

子代理资源上限的默认值与覆盖链路

如果你关心子代理的最大轮数：官方文档表格显示默认Max Turns 为 25（见 subagents 指南），覆盖优先级为 recipe 的settings.max_turns→ subagent 工具调用中的max_turns参数 →GOOSE_SUBAGENT_MAX_TURNS环境变量（见 环境变量指南 与 recipe 参考）。这正好印证了delegate参数表中max_turns"覆盖settings.max_turns和GOOSE_SUBAGENT_MAX_TURNS"的声明，形成"环境默认 → recipe 设定 → 单次调用覆盖"的完整链路。

🖼️ MCP Apps UI 集成：扩展在 goose Desktop 里渲染富交互界面

v1.25.0 把@mcp-ui/client的AppRenderer集成进 goose Desktop，MCP 扩展从此不再局限于纯文本输出，而是可以提供完整的 HTML/JavaScript 界面并内联渲染在对话流中。这意味着 MCP 扩展可以带来仪表盘、可视化、表单等一整类新交互体验。

围绕该能力的配套改进包括：

• Fallback request handler 支持：App 可以向 MCP server 发起回程请求以获取动态数据；
• rmcp 升级：goose 现在向服务器通告 MCP Apps UI 扩展能力。发布说明中记录升级到 rmcp 0.15.0；在本仓库当前代码中，rmcp 是 workspace 级依赖，根 Cargo.toml 声明rmcp = { version = "3.0.0", ... }，可以看到该依赖随版本持续演进；
• 独立 goose Apps 过滤：Apps 页面现在只展示独立的 goose Apps，让发现更干净。

从源码侧看，goose 把 "Apps" 本身实现为一个平台扩展（见 crates/goose/src/agents/platform_extensions/apps.rs），与 summon、scheduler 等并列；而负责 UI 侧行为的逻辑集中在桌面端 ui/desktop/src 的组件树中。MCP 服务端通告能力、客户端渲染 HTML/JS 的职责划分，使得同一套 MCP Apps 既能在桌面端获得富交互，也可在无 UI 的 CLI 场景下退化为普通文本结果——这正是"UI 增强不破坏协议兼容"的落地方式。

📝 在 GUI 中编辑 Recipe 的模型、提供商与扩展

Recipes（配方）本身用于定义可复用工作流（含特定指令、扩展与配置）。在 v1.25.0 之前，切换某个 recipe 所用的模型或提供商需要打开底层 YAML 手工找到对应字段；v1.25.0 之后，goose Desktop 允许以可视化方式按 recipe 进行配置：

• 修改 recipe 使用的 model 与 provider；
• 添加或移除扩展；
• 保存后立即运行更新后的 recipe。

同时，recipe 详情视图修正了一个体验问题：此前详情页展示的是全局默认 provider/model，现在正确显示 recipe 自身配置里声明的 provider 与 model。例如一个"代码评审 recipe"固定跑在 Claude Sonnet 上，那么无论你的全局默认提供商是什么，UI 都会如实展示 Claude Sonnet。

上图即发布说明附带的真实截图：编辑窗口 "View/edit recipe" 提供三个可选配置区——Provider（示例选 Databricks）、Model（示例选 gpt-5-nano）、Extensions（列表内 Developer 已启用、Airtable 未启用），全部为下拉/开关式操作，无需触碰 YAML。

桌面端对应实现位于 ui/desktop/src/components/recipes 组件目录（其中 shared/RecipeFormFields.tsx 负责表单字段、shared/SubRecipeEditor.tsx 负责子配方编辑）。如果你想了解 recipe 的 YAML 全字段语义（含settings、参数、max_turns等），可对照 recipe 参考文档 与仓库中的示例 recipes 阅读。

🤖 Agentic CLI Providers 全面升级

goose 的 agentic CLI providers（把任务委托给 Claude Code、Codex、Gemini CLI 等其他 AI 编码代理）在本版本获得批量增强：

MCP 扩展现在可用于 Agentic Providers

此前 MCP 扩展只对标准 API provider 生效；v1.25.0 起，Claude Code、Codex、Gemini CLI 都能使用 MCP 扩展。goose 在底层把扩展配置转换为各 CLI 的原生格式，从而实现"同一套 MCP 扩展在所有 provider 间复用"。

源码证据非常直接：

• 对Claude Code：provider 实现 crates/goose/src/providers/claude_code.rs 在构造命令时追加--mcp-config <文件>与--strict-mcp-config，把 goose 的扩展配置以 JSON 文件交给 Claude Code 加载；
• 对Codex：provider 实现 crates/goose/src/providers/codex.rs 逐项拼装mcp_servers.<key>.url/http_headers/command/args/env形式的 TOML override 字符串，随后的单元测试（同文件约第 795–858 行）直接断言了诸如mcp_servers.lookup.command="node"、mcp_servers.mcp_kiwi_com.url="https://mcp.kiwi.com"等生成结果，验证了转换逻辑的正确性。

Claude Code 流式输出与动态模型切换

• 流式输出：Claude Code provider 使用stream-json输入/输出格式构建命令（见 claude_code.rs 的build_stream_json_command），响应不再等到全部完成才返回，而是边工作边把结果推送给用户，长任务观感显著变好；
• 动态切换模型：现在可以在使用 Claude Code 的会话中中途列出可用模型并切换（例如从 Sonnet 切到 Haiku 处理简单任务），无需重启会话。对应源码包括send_set_model（约第 188 行）、fetch_supported_models（约第 685 行）与extract_model_aliases（约第 526 行）——先拉取模型列表、解析别名，再向运行中的 CLI 发送--model切换指令。

Gemini CLI 的 stream-json 与会话复用

Gemini CLI provider 同样改为 stream-json 输出以获得更好的实时反馈，并跨多次交互复用会话以提升效率（官方发布说明所述；如需核对该 provider 的当前实现，可查看 crates/goose/src/providers 目录下的对应模块）。

✨ CLI 流式 Markdown 渲染：让半截语法不再闪屏

长期困扰 CLI 用户的一个观感问题是：goose 流式输出时，偶发的半个加粗标记或断裂的代码块会瞬间闪现。v1.25.0 通过引入新的MarkdownBuffer修复了这一现象。

模块级文档（见 crates/goose-cli/src/session/streaming_buffer.rs）清楚说明了设计：MarkdownBuffer是一个为"安全增量渲染"服务的缓冲器，用一个状态机解析器跟踪仍未闭合的 markdown 构造（代码块、加粗、链接、行内代码等），只在构造完整时才把内容 flush 给终端：

let mut buf = MarkdownBuffer::new(); // 加粗只写了一半：缓冲，直到闭合 assert_eq!(buf.push("Hello **wor"), Some("Hello ".to_string())); assert_eq!(buf.push("ld**!"), Some("**world**!".to_string())); // 流结束时 flush 剩余内容 let remaining = buf.flush();

MarkdownBuffer结构体定义与push/flush入口可分别在 streaming_buffer.rs 与 streaming_buffer.rs 找到；文件内自带大量行为测试（如 "unclosed code block flushes at end"、"unclosed bold flushes"、"unclosed inline code flushes" 等，约第 663–815 行），直接验证了"未闭合构造在流结束时统一 flush、不产生半截语法"的核心保证。

该模块还顺带提供了可配置的超长代码块截断：默认超过 50 行（DEFAULT_MAX_CODE_BLOCK_LINES）的代码块会被折叠，只保留前 20 行（DEFAULT_TRUNCATED_SHOW_LINES），并可通过GOOSE_MAX_CODE_BLOCK_LINES、GOOSE_TRUNCATED_SHOW_LINES调整，或用GOOSE_NO_CODE_TRUNCATION=1/true彻底关闭截断（见 streaming_buffer.rs）。最终效果是：markdown 渐进式渲染且格式始终完整，不再有视觉毛刺。

🛡️ SLSA 构建来源证明：可加密验证每一份发布产物

供应链安全层面，从 v1.25.0 起，每份 goose 发布产物都附带签名 provenance attestation——覆盖 CLI 二进制、桌面安装包、Linux 包与 Docker 镜像，通过 Sigstore 签署 SLSA（Supply Chain Levels for Software Artifacts）构建来源证明。这样你可以加密学地验证任意产物确实由官方仓库、官方 CI 流水线构建：

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

官方说明指出该实现覆盖全部发布工作流（stable 稳定版、canary、nightly 以及 Docker 镜像），并做到 action 版本固定与权限范围正确收缩。若想了解该仓库整体的发版流程与核对清单，可进一步查看根目录下的 RELEASE.md 与 RELEASE_CHECKLIST.md。

小结与升级指引

综合来看，v1.25.0 的主题可以概括为：更统一（Summon 合并两套委托体系）、更直观（Desktop 可渲染富 UI、可图形化改 Recipe）、更强（Agentic CLI 支持 MCP 扩展/流式/动态换模型、CLI markdown 渲染质量提升）、更可信（SLSA 来源证明）；而 macOS seatbelt 沙箱作为实验特性推出后已按文档标注移除，当前安全能力以GOOSE_MODE工具审批机制为准。

要体验或跟进该版本的功能，请以仓库根目录 README.md 中描述的安装/更新方式为准（Desktop 与 CLI 的安装路径会随版本持续更新）；功能细节上，Summon 扩展文档、环境变量指南、subagents 指南 与 recipe 参考 是继续深入的最短路径，相关实现均可回查本仓库源码。

【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose