goose 2.0 beta 新架构解读:以 Agent Client Protocol(ACP)统一终端、桌面与第三方客户端
goose 2.0 beta 新架构解读以 Agent Client ProtocolACP统一终端、桌面与第三方客户端【免费下载链接】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/goosegoose 正在从“一个进程内跑 Agent 的单体 CLI”演进为“一个 Agent 核心、多个官方客户端、无数社区客户端”的开放架构。本文以 goose 官方的 2.0 beta 架构公告为核心骨架结合当前仓库中crates/goose/src/acp的服务端实现、goose serve/goose acp的命令参数、goose-sdk 的客户端构建方式与相关测试完整还原这次架构统一的技术方案。读完你将理解为什么 goose 选择 ACP 作为默认接入协议、四条实施阶段的真实进度、如何用一条npx命令体验新版 TypeScript TUI以及如何在源码层面构建一个属于自己的 ACP 客户端。演进背景从“单进程 CLI”到“双客户端、双协议”goose 最初诞生在终端里。最早期的版本是一个 Python CLIAgent 直接跑在进程内——你输入一条消息模型响应工具执行所有事情都在同一个事件循环里完成。这种简单性是它早期最大的优势只要有终端就能立刻用上 goose不需要安装任何 App也不需要启动任何服务端。随着 goose 逐渐成长用户的使用方式开始分化。官方随后发布了基于 Electron 的桌面 App问题也随之而来项目里出现了两条客户端、两条完全不同的接入路径——Rust CLI 在进程内直接与 Agent 通信桌面 App 则绕道goosed一个自定义的 REST SSE 服务端。于是每一次新增功能——会话管理、扩展加载、流式输出——都必须在两套代码里各实现一遍维护成本成倍放大。更关键的是第三方开发者始终没有一种标准方式接入 goose很难构建自己的客户端。这正是 goose 2.0 架构改造要解决的根源问题需要一个任何客户端都能“说”的统一协议去访问同一个 Agent 核心。官方为此选定了 ACPAgent Client ProtocolAgent 客户端协议并将其设为 goose 的默认接入接口。原始公告见 documentation/blog/2026-04-08-goose-acp-and-new-tui/index.md。核心决策ACP 成为 goose 的统一接入协议ACP 的设计目标是让终端、桌面、IDE 插件以及任何你想构建的客户端都通过同一个协议 同一个 goose 服务端与 Agent 核心对话。协议本身与具体 UI 无关只定义客户端与服务端之间的会话、消息、工具调用、权限、扩展加载等交互语义。这意味着未来可能生长出一个繁荣的 goose 客户端生态——社区不必再反向工程内部实现只要实现 ACP 就能接入。官方公告中给出的实施路线分四个阶段阶段内容状态1 — 稳定 ACP 服务端生产可用的服务端具备会话持久化、扩展加载、流式输出已完成2 — TypeScript TUI beta基于 ACP 客户端的终端 UI功能趋近完整进行中3 — 桌面端重写为 Tauri用基于 ACP 的 Tauri 桌面客户端替换 Electron 应用进行中4 — 整合收敛移除goosed与旧的 Rust CLI收敛为单一统一架构规划中以上工作全部在官方跟踪 issue编号 #6642下公开推进。仓库中的 ACP 服务端实现速览从当前仓库源码看阶段一稳定 ACP 服务端已经扎实落地服务端核心代码集中在 crates/goose/src/acp/并对外暴露于 crates/goose/src/lib.rs 的pub mod acp。该目录按职责分为三层服务端入口与工厂server.rs、server_factory.rs、server/子目录。AcpServerFactoryConfig见 server_factory.rs聚合了builtins内置扩展选择、data_dir/config_dir、goose_platform、可选的session_cwd供 roam 场景下宿主控制工作目录以及enable_scheduler等配置AcpServer通过create_agent()为每个连接创建 Agent并托管一个全局的活跃 run 注册表。协议处理逻辑server/子目录按 ACP 语义拆分为多个 handler从文件名即可看出覆盖面——new_session.rs、load_session.rs、list_sessions.rs、fork_session.rs、manage_sessions.rs构成完整的会话生命周期管理extensions.rs处理扩展加载tools.rs与tool_call_notifier.rs负责工具调用与调用通知elicitation.rs处理澄清追问onboarding.rs、providers.rs、config.rs处理引导、Provider 与配置选项。会话的落盘由SessionManager支撑见 session/这对应公告中“会话持久化”能力。响应与能力协商response_builder.rs负责把内部状态翻译成 ACP 协议消息例如构建config options、provider options、mode state、session info以及 session setup 通知等provider.rs定义了AcpProvider与AcpProviderConfig并导出ACP_CURRENT_MODEL实现从 goose 侧反向以 ACP 连接第三方 Agent 的能力。整体而言客户端只感知 ACP不知道也不关心背后是哪个 Agent 实现——这正是“任何客户端都能接到同一个 Agent 核心”的架构基础。两种服务端形态goose serveHTTP/WebSocket与 stdio 进程内服务公告中同时提到官方正在为 ACP 设计新的 HTTP/WS 传输层。在仓库里这一能力已经以内置命令的形式存在goose-cli同时提供两种跑 ACP 服务端的方式。HTTP WebSocket 服务goose servecrates/goose-cli/src/cli.rs 中定义了serve子命令帮助文本明确写着“Start ACP server over HTTP and WebSocket”。核心参数如下# 默认绑定 127.0.0.1:3284仅供本机回环地址访问 goose serve \ --with-builtin developer,github \ # 按名加载内置扩展可逗号分隔多次指定 --allowed-origin http://localhost:5173 \ # 显式允许的 CORS Origin可重复指定 --enable-scheduler # 启用定时 Recipe 调度执行关键参数的默认值与语义均可从 CLI 定义核实参数默认值说明--host127.0.0.1监听地址回环地址有利于安全--port3284监听端口--tls/--tls-cert-path/--tls-key-path关闭启用 ACP over TLS--platformcli服务端平台类型--with-builtin—追加内置扩展名如developer、github--dangerously-unauthenticated关闭不带此参数时服务端默认要求环境变量GOOSE_SERVER__SECRET_KEY做鉴权--allowed-origin回环 Origin精确放行的 CORS Origin可多次指定并替换默认值--enable-scheduler关闭开启后无头goose serve也会执行定时任务服务端路由由 crates/goose/src/acp/transport/mod.rs 构建ACP 端点挂在/acp路径上支持 POST/GET/DELETE并透传acp-connection-id、acp-session-id等协议头CORS 策略由AcpOriginPolicy控制鉴权中间件check_acp_token会校验令牌auth.rsTLS 证书加载则位于 tls.rs。进程内 stdio 服务goose acp在 crates/goose-cli/src/cli.rs 的派发逻辑中Command::Acp分支直接调用goose::acp::server::run(...)——这是 ACP 服务端的主流程入口见 crates/goose/src/acp/server.rs配合SessionManager加载与持久化会话。这种形态让宿主应用可以像启动子进程一样把内置的goose二进制作为本地 ACP 服务端拉起来再通过 stdio 与之通信。值得一提的是这套接入模式并非停留在设计层面当前桌面端工程 ui/desktop/README.md 明确记载“桌面 App 启动打包进来的 goose CLI 二进制并与其 ACP 服务端通信”——也就是说即便桌面 App 本体尚未切换到 Tauri其与后端交互的路径也已经统一到 ACP 之上。亲手体验新的 TypeScript TUIbeta在上述服务端基础之上goose 发布了第一批官方客户端一个全新的 TypeScript TUI今天就能试用和将取代 Electron 应用的 Tauri 桌面 App。新版 TUI 处于 beta 阶段已经支持消息对话、工具调用、代码语法高亮与 Markdown 渲染。启动它只需要一条命令无需本地安装npx aaif/goose它会拉取最新 beta 版本并直接开启一个交互式会话。下图即新版 TUI 的真实运行画面——深色界面中Agent 的每一步思考与工具动作搜索符号定义、查看server.rs指定行、执行编辑并同步更新测试都被结构化地呈现出来配合代码高亮与渲染后的 Markdown 输出TUI 后续规划beta 版本之后官方为 TUI 列出的下一批能力包括Provider 与模型管理会话列表、恢复与导出MCP 功能与技能skills管理的 UI。从源码视角看这些规划都能在服务端找到对应支撑Provider 清单与模型选项由 acp/server/providers.rs 及response_builder.rs的build_provider_options提供会话列表/恢复/分支fork分别由list_sessions.rs、load_session.rs、fork_session.rs实现MCP 扩展加载与技能则落在extensions.rs及相关会话扩展状态上——TUI 侧的工作更多是“把服务端已暴露的 ACP 能力接进界面”。桌面端从 Electron 迁移到 Tauri桌面端重写的目标是性能更好、UI 焕新并且新应用同样通过 ACP 与后端通信让两个官方客户端共享同一套协议与服务端。迁移动机很直接Electron 体积与内存开销大而 Tauri 依托系统 WebView能显著降低资源占用同时统一走 ACP 后桌面端不再需要维护任何私有接入层。对照仓库现状可以更精确地理解“进行中”意味着什么目前 ui/desktop 目录中的工程仍是 Electron React 结构Electron Forge Vite见 package.json并且源码中仍存在gooseServe.ts等与旧goosed服务端相关的模块——这印证了阶段四“移除goosed与旧 Rust CLI”仍属规划中事项。桌面端虽然还是 Electron 外壳但如上文所述其后端接入早已切换到内置 goose 二进制的 ACP 服务端为 Tauri 重写铺好了协议层的地基。官方将在桌面端准备好 beta 测试时发布后续公告。面向开发者如何构建你自己的 ACP 客户端对第三方开发者而言这次架构改造最大的价值是接入成本从“反向工程”降为“实现一个协议”。仓库提供了两条上手路径官方 GDK 文档与示例documentation/docs/gdk/acp/index.md 是构建 ACP 客户端的官方指引更早的 documentation/blog/2025-10-24-intro-to-agent-client-protocol-acp/index.md 则介绍了 ACP 协议本身的入门概念。goose-sdk 的协议类型与示例客户端goose-sdk即 GDK 的 Rust 实现见 crates/goose-sdk/src/lib.rs在默认特性下重新导出goose-sdk-types的共享 wire 类型专门用于构建“通过 stdio 与goose通信的 ACP 客户端”配套的可运行示例在 crates/goose-sdk/examples/acp_client.rs。若开启uniffi特性还会以动态库形式向 Python/Kotlin 暴露进程内 API。此外goose包自带机器可读的协议描述 crates/goose/acp-schema.json及acp-meta.json便于生成类型与校验消息。仓库测试目录里还能看到一套完整的服务端行为验证例如 acp_server_test.rs、acp_transport_auth_test.rs、acp_fork_session_test.rs、acp_secret_cache_invalidation_test.rs它们覆盖了鉴权、会话分支、密钥缓存失效等关键交互是自研客户端时理解协议语义的绝佳参考。路线图小结回到公告中的四阶段路线可以这样总结 goose 2.0 的收敛方向服务端先行生产级 ACP 服务端已完成会话持久化、扩展与流式能力全部就绪源码证据集中在 crates/goose/src/acp/并同时提供goose serveHTTP/WS默认127.0.0.1:3284与 stdio 两种形态TUI 打样TypeScript TUI beta 正在冲刺功能完整性一条npx aaif/goose即可体验桌面跟进Tauri 桌面客户端在协议层已与 CLI 汇合外壳迁移仍在推进收敛旧栈goosed与旧 Rust CLI 的退役被明确列入规划最终收敛为“一个 Agent 核心 统一 ACP 接入”。整个演进都在公开仓库中逐步落地相关讨论与反馈集中在官方跟踪 issue #6642。如果你恰好需要为自家 IDE、网页或移动端接入一个真正的 Agent 后端现在正是以 ACP 为界、关注crates/goose/src/acp各 handler 与crates/goose-sdk类型定义的最佳时机。【免费下载链接】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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
