ApeCloud 本地 Agent Goose Fork PoC

[earayu]

这个 Issue 是做什么的

基于 Goose fork 做第一版 ApeCloud 本地 Agent PoC。

目标不是重写 Goose，而是验证：我们能不能用很小、很干净、方便跟随上游的改动，做出一个 ApeCloud 品牌的本地 Agent 发行版。

仓库协作规则：后续本仓库的 Issue 和 PR 标题/正文默认使用中文；必要的代码标识、命令、英文错误信息可以保留原文。

为什么要做

我们需要一个本地 Agent 形态，让工具执行可以发生在用户自己的机器上，而不是全部压在 Web 后端里。这样可以解决几类问题：

• 减少服务器资源消耗
• 降低缺少沙箱时的安全风险
• 能访问用户本地文件系统和本地工具
• 保持 Web 端 Agent 不变，同时补一个本地执行选择

改动边界

为了后续持续跟踪 Goose 上游，第一版只做下面五类改动：

1. 文案修改
2. Logo / 图标 / 视觉资产修改
3. 默认配置修改
4. UI 上隐藏不需要的功能
5. ApeCloud 自己的打包和分发

不要修改 Goose 核心 Agent Loop、Provider 接入、MCP Runtime 内部逻辑，或者大范围 Rust 代码。除非遇到明确 blocker，并且先单独说明原因、获得确认。

第一版 PoC 范围

• 把用户可见的产品身份改成 ApeCloud 品牌的本地 Agent 项目。
• ApeMind MCP 作为默认/预置集成之一，而不是把项目身份强绑定到 ApeMind。
• 预置 streamable HTTP MCP 配置，支持通过环境变量或配置传入 MCP URL 和鉴权 token。
• 先通过默认配置或 UI 隐藏关闭不需要/高风险功能，不删除上游核心代码。
• 尽量跑通 CLI、Docker、Desktop 打包路径，并记录每类产物大小。
• 保留 GitHub fork 关系，保证后续可以从上游干净 rebase / merge。

怎么验收

• 品牌检查：用户可见的 ApeCloud 发行版界面里不残留不该出现的 Goose 产品身份；上游 license / copyright 保留。
• MCP 配置检查：默认配置可以指向 ApeCloud / ApeMind MCP endpoint，并支持鉴权。
• CLI 体积检查：CLI 二进制可以用上游现有 feature/profile 构建到约 50MB。
• 产物大小记录：Desktop 和 Docker 产物单独记录大小，不和 CLI 50MB 目标混用。
• 安全默认值：高风险本地工具默认不启用。
• 核心逻辑不改：PR diff 不修改 Goose 核心 Agent Loop，除非单独批准。
• 上游跟踪：本仓库保持 fork 关系，本地 repo 同时保留 upstream remote，能正常 fetch/rebase 上游。
• 构建可复现：记录本地 CLI / Desktop / Docker smoke 的具体命令和结果。

已有研究结论

前期本地研究已确认：

• Goose 是 Apache-2.0 license，适合做 branded distribution，但要保留 license / notice，不暗示上游官方背书。
• Goose 仓库包含完整 CLI / Server / Desktop / Docker / Release pipeline。
• 本地构建需要 Rust 1.91.1+；本地可通过 Hermit 环境构建。
• CLI 可以用现有上游 feature/profile 达到约 50MB，不需要修改核心代码：

source ./bin/activate-hermit >/tmp/hermit.log 2>&1
CARGO_PROFILE_RELEASE_LTO=true \
CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1 \
CARGO_PROFILE_RELEASE_OPT_LEVEL=z \
CARGO_PROFILE_RELEASE_STRIP=true \
  cargo build --release --package goose-cli --bin goose \
  --no-default-features --features rustls-tls

后续协作

• 本仓库后续 Issue / PR 使用中文描述。
• 涉及上游代码改动时，优先解释为什么属于五类允许改动之一。
• 如果不得不越过五类边界，先开 Issue 说明 blocker 和替代方案，不直接在 PR 里扩大范围。