在 AI Agent 框架领域，Block（原 Square）于 2025 年开源的 Goose 提供了独特的工程视角。与传统 Agent 框架强调对话能力不同，Goose 将核心设计聚焦于「连接 LLM 与真实操作」这一工程挑战。本文将解析其可扩展运行时架构的核心设计，探讨工具集成、权限约束与上下文管理的工程实践。
三层组件架构与职责边界
Goose 的架构设计遵循清晰的职责分离原则，由三个核心组件构成。接口层（Interface）负责与用户交互，支持桌面应用与 CLI 两种形态，既收集用户输入也呈现执行结果。代理层（Agent）是运行时核心，负责管理交互循环、解析模型输出并调度工具执行。扩展层（Extensions）则以 MCP（Model Context Protocol）协议为基础，提供具体的工具能力封装。
在典型的会话流程中，接口层启动 Agent 实例，Agent 同时连接多个扩展以获取可用工具集。这种设计使得单个 Agent 能够并发访问文件系统、Shell 命令、版本控制等多种能力源。值得注意的是，接口层可以创建多个并行 Agent 实例处理不同任务，这对于复杂工作流的编排尤为重要。扩展与交互循环的解耦设计，使得工具能力的增删不需要修改 Agent 核心逻辑。
MCP 协议与工具接口设计
Goose 采用 Model Context Protocol 作为扩展互操作的标准，这与其定位为「连接 LLM 与操作」的框架高度一致。MCP 服务器在 Goose 语境下被称为扩展（Extensions），通过暴露工具（Tools）来提供功能。每个工具包含名称、描述、参数定义与具体实现四个要素，Agent 通过 JSON 格式的工具调用请求与扩展交互。
从代码层面看，扩展需要实现统一的 Extension Trait。该 Trait 定义了 name、description、instructions 三个元数据方法，以及 tools、status、call_tool 三个核心方法。tools 方法返回当前扩展暴露的所有工具定义，status 方法提供运行时的健康状态信息，call_tool 则是工具调用的实际执行入口。这种 Trait 约束确保了任何 MCP 兼容的扩展都能以一致方式接入 Goose 运行时。
工具定义的规范同样关键。官方建议使用动作导向的命名（如 create_user 而非 user），每个参数都应附带清晰描述以便模型理解。更重要的是，工具实现应当返回具体的错误信息而非泛化的异常，这些错误数据会被回传给模型作为「提示」，帮助其调整后续调用策略。
细粒度权限控制与安全边界
Agent 能够执行任意工具是一把双刃剑。Goose 提供了三层权限模型来解决这个问题：Always Allow（始终允许）、Ask Before（执行前询问）、Never Allow（永不执行）。这种设计将安全控制粒度从「能否使用扩展」细化到了「能否使用特定工具」。
在工程实践中，Always Allow 适用于只读操作如文件读取、目录列表和信息查询。Ask Before 则是状态变更操作的默认选择，包括文件编辑、命令执行和资源创建。Never Allow 专门用于敏感操作，如凭证访问、系统关键文件修改和资源删除。这种分级策略使得用户可以在不同任务场景下灵活调整权限配置。
性能优化也是权限设计的重要考量。官方文档建议将启用的工具总数控制在 25 个以内，过多的工具会导致模型出现「决策瘫痪」，即在众多可用工具中难以做出最优选择。此外，每个扩展的工具权限可以通过 CLI 的 goose configure 命令进行配置，也可以通过环境变量在会话级别进行动态调整。
上下文管理与防失控机制
长会话的上下文膨胀是 Agent 系统面临的普遍挑战。Goose 采用了双层策略来处理这个问题：自动压缩（Auto-Compaction）作为主动防御，上下文策略（Context Strategies）作为兜底方案。
自动压缩在会话达到令牌用量 80% 时自动触发，默认使用更小、更快的模型对历史对话进行摘要。触发阈值可以通过 GOOSE_AUTO_COMPACT_THRESHOLD 环境变量调整，设为 0.0 则禁用该功能。压缩完成后，系统会显示确认消息，用户可以继续会话，而只有摘要版本会保留在活跃上下文中。
当自动压缩无法满足需求时，Goose 提供了四种上下文策略：Summarization（摘要，保留最多上下文）、Truncation（截断，丢弃最旧消息）、Clear（清空，开始新会话）、Prompt（提示用户选择）。CLI 模式下还支持 /summarize 命令手动触发摘要，这在预期即将超出上下文限制时非常有用。
防止 Agent 失控同样重要。Max Turns 限制设定了 Agent 连续执行的最大轮数（默认 1000 轮），达到限制后 Agent 会主动停下来请求用户确认。这个设计可以有效防止无限循环和资源耗尽，尤其在自动化任务场景下意义重大。不同任务复杂度需要不同的配置：探索性任务适合 5-10 轮，中等复杂度任务适合 25-50 轮，高度自动化的任务可以设置为 100 轮以上。
工程实践参数参考
基于上述分析，以下是 Goose 运行时调优的关键参数建议。在工具配置方面，启用工具总数建议控制在 20 个以内，每个扩展的工具应该按任务需求选择性启用。在压缩策略方面，GOOSE_AUTO_COMPACT_THRESHOLD 推荐设置为 0.6 到 0.8 之间，GOOSE_CONTEXT_STRATEGY 建议设为 summarize 以自动处理上下文溢出。在会话安全方面，GOOSE_MAX_TURNS 对于高风险操作建议设置为较低值（如 20-30 轮），并通过 GOOSE_CLI_SHOW_COST 开启成本监控以控制 API 开支。
Goose 的设计体现了 Block 在支付系统领域积累的工程思维：将复杂系统分解为可组合的组件，通过清晰的协议约束和细粒度的控制机制来保证可靠性。这种务实的设计理念对于构建生产级 AI Agent 系统具有重要参考价值。
资料来源：Block Goose 官方文档（https://block.github.io/goose/docs/goose-architecture/）