goose 贡献者实战指南从 Issue 工作流到 Rust/Electron 双栈开发环境搭建【免费下载链接】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 仓库根目录的 CONTRIBUTING.md 完整展开梳理 goose 项目“以 Issue 为核心记录”的贡献工作流、从 Issue 到 Pull Request 的准入规则、Agent Loop 状态机迁移期的双路径开发要求以及 Hermit 管理下 Rust CLI 与 Electron GUI 的本地构建、调试与环境隔离实操。读完本文你可以独立完成 goose 的编译、运行、UI 调试与提交规范并理解当前仓库中最敏感的代码迁移区域GOOSE_STATE_MACHINE1背后的实现机制。Issue 工作流一个 Issue 就是一次贡献的完整记录goose 的核心理念是代码只是贡献的一种方式。报告问题、复现问题、分享领域知识、参与设计、实现方案、验证结果都属于有价值的贡献。所有工作都组织在公开的 Goose Issues 项目看板上Issue 是贡献的主记录从首次报告一直贯穿到设计、实现和验证。看板上每个 Issue 会经历以下七个阶段阶段含义InboxIssue 等待分诊triage。Needs info需要更多信息才能推进。Accepted / design团队决定解决该问题正在讨论设计、约束与验证方案。Ready方案已定可以开始实现。In progress实现进行中。Verification实现完成等待人工确认其确实有效。Done结果已验证Issue 关闭。值得注意的是团队不计划推进的 Issue 会直接关闭并附带解释不使用“拒绝”标签。功能请求应当描述一个具有广泛价值的问题而不是只描述一种偏好的实现方式——因为“加功能容易维护它是长期成本”复杂度增加但普适收益不足的请求可能被拒。Discord 和 GitHub Discussions 仍然适合非正式交流但任何影响实现的决定都必须落到 Issue 里。最佳贡献窗口Accepted / design 到 Ready 之间文档明确指出最好的贡献位置是Accepted / design与Ready之间的讨论。这里是“工程真正发生的地方”把一个有价值的问题转化为 Agent 可以落地实现的具体方案。参与者可以带来上下文与领域知识挑战既有假设、对比不同方案识别约束与权衡就“结果如何被验证”达成一致。贡献的计量单位是“把一个问题带到经过验证的解决方案”而不仅仅是写补丁。在任何阶段做出实质性贡献的人都可能获得共同作者co-author身份。从 Issue 到 Pull Request 的四条硬规则在 Issue 到达看板的Ready阶段之前不要开始实现或打开 Pull Request。每一个外部 PR 必须满足链接它所实现的 Ready Issue保持在 Issue 中约定好的设计与范围之内说明 Issue 的验证方案是如何执行的重大设计变更必须退回 Issue 继续讨论。不实现 Ready Issue 的 PR 会被关闭。自动依赖升级与发版 PR、紧急安全修复、以及核心团队明确指派的工作属于豁免情形。此外不要短时间连续提交多个 PR应按偏好顺序提交等前面的合入后再开新的。Agent Loop 迁移当前仓库最敏感的代码区域CONTRIBUTING.md 特别列出了一项进行中的架构迁移遗留的 agent loop 位于 crates/goose/src/agents/agent.rs正在被 crates/goose/src/agents/state_machine/ 下的状态机实现替换。迁移期的开发要求是对 agent loop 行为的任何改动都必须在两条路径上都实现并测试PR 中需说明如何验证了两条路径的等价性parity。从源码看状态机路径的开关实现非常直接。crates/goose/src/agents/state_machine/mod.rs 中的enabled()函数读取环境变量pub fn enabled() - bool { std::env::var(GOOSE_STATE_MACHINE) .map(|v| matches!(v.as_str(), 1 | true | TRUE | yes)) .unwrap_or(false) }即GOOSE_STATE_MACHINE取值为1、true、TRUE或yes时启用状态机路径否则默认走遗留路径。调用点包括 crates/goose/src/agents/agent.rs如agent.rs中对state_machine::enabled()的判断用于分流 bang shell 命令等入口逻辑以及 crates/goose/src/acp/server/load_session.rs会话恢复时判断是否走状态机恢复路径。状态机目录本身按“操作operation”拆分每个文件对应一类会话操作例如 crates/goose/src/agents/state_machine/ 下的ops_llm.rs推理、ops_toolcalling.rs工具执行、ops_compaction.rs上下文压缩、ops_steer.rssteer 队列、ops_retry.rs、ops_maxturns.rs等。mod.rs统一导出这些 Operation 类型。这种“一操作一文件”的结构意味着修改任何一类 agent 行为时都能在两侧找到对称的实现位置去比对。测试侧同样印证了双路径要求crates/goose/src/agents/state_machine/tests/agent_reply.rs 使用env_lock::lock_env在GOOSE_STATE_MACHINESome(1)与None之间切换来分别断言两条路径的行为crates/goose/tests/agent.rs 中也有显式锁定该环境变量的测试用例。贡献者在写测试时可以参考这一模式。AI 代码审查所有意见都必须被回应项目使用 codex 作为 AI 代码审查者。流程要求非常严格AI 提出的每一条意见都必须被处理——要么修改代码要么用一行回复说明“为什么这不是问题或不值得修”。如果不处理PR 可能被关闭并收到指向 CONTRIBUTING.md 该章节的回复处理完评论后可以随时重新打开 PR。负责任的 AI 使用守则文档对“用 AI 贡献”持明确态度不需要声明你用了 AI给一个 Agent 项目做贡献不用 AI 才奇怪但在机器人革命到来之前你对最终代码负责。提交 PR 前必须自己审查过代码明显跳过这一步的“vibe coded”提交会被关闭。文档给出的四条实操提示值得逐字记住先想再写Agent 倾向于直接跳到写代码。应基于自己对代码的理解先讲清目标架构或让 Agent 先探索代码再提出方案。第一次实现不理想就推倒重来把学到的东西用于下一次。发现偷懒LLM 会让自己的活变轻松——写毫无用处的测试、把类型放宽或加可选来绕过编译器、捕获异常只打日志而不处理错误、不管合适与否都照抄本地既有模式。要顶回去。发现不确定Agent 嘴上说“我现在完全看清问题了”但往往并没有。看到它反复摇摆时要指出来另一个信号是它开始罗列“我修复了 N 种情况”或者开始写过度防御性的代码。发现膨胀Agent 喜欢插入冗余注释尤其是注释“本次改动做了什么”而不是“这段代码是什么”创建大量实际什么都没测的测试或者测实现细节而非测试意图还倾向于“以防万一”到处打日志。开发环境搭建Hermit 管理依赖goose 由 Rust 二进制与 Electron 桌面应用组成。开发依赖Rust、Node、pnpm、just 等通过Hermit管理。进入项目后激活source bin/activate-hermit也可以配置 Hermit 的 shell hook 自动激活这样每次cd进项目时 Hermit 会自动生效推荐。标准命令则通过just提供快捷方式命令清单定义在仓库根目录的 Justfile 中just --list可查看全部任务。Windows Subsystem for LinuxWSLWSL 用户可能还需要安装build-essential与libxcb否则会遇到ccC 编译器链接错误sudo apt update # 刷新软件包列表尚未安装 sudo apt install build-essential # 安装全部核心编译工具 sudo apt install libxcb1-dev # X C Binding (XCB) 库的开发包Rust 侧开发编译、运行与四项检查首次编译并体验 goosecd goose source ./bin/activate-hermit cargo build完成后即可使用 debug 构建的产物包括 goose CLI./target/debug/goose --help首次使用需要先完成配置./target/debug/goose configure当某个 LLM provider 连接成功后就可以启动会话./target/debug/goose session日常迭代中可以用cargo run -p goose-cli一边重编译一边运行。修改 Rust 代码后应通过 CLI 实测或运行检查、测试与 lintercargo check # 确认改动可以编译 cargo test # 带着改动跑测试 cargo fmt # 格式化代码 cargo clippy --all-targets -- -D warnings # 运行 linter这四项也正是 Justfile 中check-everything配方对 Rust 侧做的事——它依次执行cargo fmt --all、cargo clippy --all-targets -- -D warnings再到ui/desktop下执行pnpm run lint:check相当于提交前的完整风格校验。Node/Electron 侧开发just run-ui 与常见白屏问题运行桌面应用just run-ui对照 Justfile 中该配方的实现run-ui会先调用release-binary即cargo build --release -p goose-cli --bin goose并把产物拷贝到ui/desktop/src/bin/再进入ui/desktop执行pnpm install pnpm run start-gui。因此它是以 release 方式构建 Rust等价于cargo build -r后启动 Electron 进程。应用会打开窗口并展示首次配置流程完成配置后即可使用。GUI 代码改动都在ui/desktop目录下进行。排障just run-ui出现白屏如果应用打开后是空白窗口日志中出现Cannot read properties of null (reading useRef)说明node_modules过期并加载了两份 React。删除后重装即可rm -rf ui/desktop/node_modules cd ui pnpm install调试外部 ACP 后端要调试外部 ACP 后端需要在 IDE 中运行它具体配置取决于所用 IDE。要运行的命令是export GOOSE_SERVER__SECRET_KEYtest cargo run --package goose-cli --bin goose -- serve --platform desktop --enable-scheduler --host 127.0.0.1 --port 3000debug-ui配方默认连接http://127.0.0.1:3000。如果后端使用其他端口启动 UI 时设置GOOSE_PORT或把GOOSE_EXTERNAL_BACKEND_URL设为后端的 HTTP 基础地址。后端跑起来之后执行just debug-uiUI 就会连接到 IDE 中启动的后端从而可以在与 UI 交互的同时打断点、单步执行后端代码。从 Justfile 看debug-ui配方实际设置了GOOSE_EXTERNAL_BACKENDtrue并将GOOSE_SERVER__SECRET_KEY默认设为test若未设置这与文档描述一致同文件中的run-server配方则是直接以GOOSE_SERVER__SECRET_KEY环境变量启动同一后端命令的等价入口。GOOSE_SERVER__SECRET_KEY在 CLI 侧的定义可见 crates/goose-cli/src/cli.rs其中serve子命令也提供了不强制要求该密钥的选项。创建与同步 Fork创建 Fork 的标准流程在项目仓库页面点击右上角 “Fork”在你的账号下生成your-username/goose。克隆你的 Fork而不是主仓库。本地拉取源码可以使用镜像地址git clone https://gitcode.com/GitHub_Trending/goose3/goose.git cd goose把主仓库加为 upstreamgit remote add upstream 主仓库地址为改动创建分支git checkout -b my-feature-branch同步主仓库到本地git fetch upstream git checkout main git merge upstream/main推送到自己的 Forkgit push origin my-feature-branch从 Fork 分支向主仓库的 main 分支发起 Pull Request。保持 Fork 最新为减少合并冲突、加快 PR 合入应保持分支与主仓库同步确认 upstream 已添加git remote add upstream 主仓库地址已设置可跳过git fetch upstream拉取最新变更git checkout your-branch-name切到你的开发分支git merge upstream/main合并主分支解决冲突并提交git push origin your-branch-name推回 Fork。提交 PR 前应完成上述同步确保改动与主仓库最新状态兼容从而简化评审。开发期环境变量切换 Provider 与隔离测试环境开发过程中频繁调整 provider 配置时可以用环境变量“热切换”无需重复配置。通过GOOSE_PROVIDER可以改变 goose 指向的 provider。如果 keychain 中已有该 provider 的凭据来自此前配置会直接复用。为了自动化或免官方设置地测试也可以直接设置对应 provider 的环境变量例如ANTHROPIC_API_KEY、OPENAI_API_KEY、DATABRICKS_HOST。仓库内的 环境变量指南 还补充了GOOSE_PROVIDER__TYPE、GOOSE_PROVIDER__HOST、GOOSE_PROVIDER__API_KEY等细化变量可用于覆盖 provider 的实现类型、自定义 API 端点与密钥方便指向本地或自建的兼容端点。用 GOOSE_PATH_ROOT 隔离测试环境在测试改动或同时运行多套 goose 配置时用GOOSE_PATH_ROOT隔离数据# 干净的测试环境 export GOOSE_PATH_ROOT/tmp/goose-test ./target/debug/goose session # 或者只对单条命令生效 GOOSE_PATH_ROOT/tmp/goose-dev cargo run -p goose-cli -- session该变量会在指定路径下创建相互隔离的config/、data/、state/目录避免测试会话污染主安装环境。同样的隔离思路在 Justfile 的run-ui-playwright配方中也有体现它把GOOSE_PATH_ROOT指向带时间戳的临时目录后再启动 UI实现每次 Playwright 调试运行互不干扰。接入本地 Langfuse 查看 Traces要启用基于本地自托管 Langfuse 的 trace 追踪按 Langfuse 官方自托管文档Docker Compose 方式在本地启动 Langfuse创建组织、项目与 API 凭据设置 goose 连接 Langfuse 所需的环境变量export LANGFUSE_INIT_PROJECT_PUBLIC_KEYpublickey-local export LANGFUSE_INIT_PROJECT_SECRET_KEYsecretkey-local之后即可在本地 Langfuse 的 Web 界面默认端口 3000中查看 trace。提交规范Conventional Commits项目遵循Conventional Commits规范来约束 PR 标题。这样做是为了让项目历史更易读并支撑版本管理与 changelog 生成的自动化。撰写提交信息时请遵循type(scope): description形式如fix(session): ...、chore(release): ...Justfile 中prepare-release流程的提交信息chore(release): release version {{ version }}就是该规范的直接体现。代码之外的其他贡献方式除了提交代码goose 欢迎多种形式的参与Star 项目如果 goose 对你有价值可以在仓库页面点亮 Star提问在社区渠道提问既帮助项目改进也帮助其他成员反馈发现功能需求或问题可以通过新建 Issue、发起 Discussion 或社区渠道反馈参与社区活动项目定期举办工作坊与头脑风暴等线上活动可通过订阅活动日历或关注社交账号跟进改进文档改善现有文档质量或补充新页面帮助其他成员回复社区帖子、为他人做 code review展示你的作品在社区“分享你的作品”频道晒出你基于 goose 的项目或文章推荐与传播在社区中为出色的项目或成员点赞并把 goose 分享给更多人。任何环节遇到问题都可以通过新建 Issue 联系维护者。【免费下载链接】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），仅供参考 goose 贡献者实战指南：从 Issue 工作流到 Rust/Electron 双栈开发环境搭建
goose 贡献者实战指南从 Issue 工作流到 Rust/Electron 双栈开发环境搭建【免费下载链接】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 仓库根目录的 CONTRIBUTING.md 完整展开梳理 goose 项目“以 Issue 为核心记录”的贡献工作流、从 Issue 到 Pull Request 的准入规则、Agent Loop 状态机迁移期的双路径开发要求以及 Hermit 管理下 Rust CLI 与 Electron GUI 的本地构建、调试与环境隔离实操。读完本文你可以独立完成 goose 的编译、运行、UI 调试与提交规范并理解当前仓库中最敏感的代码迁移区域GOOSE_STATE_MACHINE1背后的实现机制。Issue 工作流一个 Issue 就是一次贡献的完整记录goose 的核心理念是代码只是贡献的一种方式。报告问题、复现问题、分享领域知识、参与设计、实现方案、验证结果都属于有价值的贡献。所有工作都组织在公开的 Goose Issues 项目看板上Issue 是贡献的主记录从首次报告一直贯穿到设计、实现和验证。看板上每个 Issue 会经历以下七个阶段阶段含义InboxIssue 等待分诊triage。Needs info需要更多信息才能推进。Accepted / design团队决定解决该问题正在讨论设计、约束与验证方案。Ready方案已定可以开始实现。In progress实现进行中。Verification实现完成等待人工确认其确实有效。Done结果已验证Issue 关闭。值得注意的是团队不计划推进的 Issue 会直接关闭并附带解释不使用“拒绝”标签。功能请求应当描述一个具有广泛价值的问题而不是只描述一种偏好的实现方式——因为“加功能容易维护它是长期成本”复杂度增加但普适收益不足的请求可能被拒。Discord 和 GitHub Discussions 仍然适合非正式交流但任何影响实现的决定都必须落到 Issue 里。最佳贡献窗口Accepted / design 到 Ready 之间文档明确指出最好的贡献位置是Accepted / design与Ready之间的讨论。这里是“工程真正发生的地方”把一个有价值的问题转化为 Agent 可以落地实现的具体方案。参与者可以带来上下文与领域知识挑战既有假设、对比不同方案识别约束与权衡就“结果如何被验证”达成一致。贡献的计量单位是“把一个问题带到经过验证的解决方案”而不仅仅是写补丁。在任何阶段做出实质性贡献的人都可能获得共同作者co-author身份。从 Issue 到 Pull Request 的四条硬规则在 Issue 到达看板的Ready阶段之前不要开始实现或打开 Pull Request。每一个外部 PR 必须满足链接它所实现的 Ready Issue保持在 Issue 中约定好的设计与范围之内说明 Issue 的验证方案是如何执行的重大设计变更必须退回 Issue 继续讨论。不实现 Ready Issue 的 PR 会被关闭。自动依赖升级与发版 PR、紧急安全修复、以及核心团队明确指派的工作属于豁免情形。此外不要短时间连续提交多个 PR应按偏好顺序提交等前面的合入后再开新的。Agent Loop 迁移当前仓库最敏感的代码区域CONTRIBUTING.md 特别列出了一项进行中的架构迁移遗留的 agent loop 位于 crates/goose/src/agents/agent.rs正在被 crates/goose/src/agents/state_machine/ 下的状态机实现替换。迁移期的开发要求是对 agent loop 行为的任何改动都必须在两条路径上都实现并测试PR 中需说明如何验证了两条路径的等价性parity。从源码看状态机路径的开关实现非常直接。crates/goose/src/agents/state_machine/mod.rs 中的enabled()函数读取环境变量pub fn enabled() - bool { std::env::var(GOOSE_STATE_MACHINE) .map(|v| matches!(v.as_str(), 1 | true | TRUE | yes)) .unwrap_or(false) }即GOOSE_STATE_MACHINE取值为1、true、TRUE或yes时启用状态机路径否则默认走遗留路径。调用点包括 crates/goose/src/agents/agent.rs如agent.rs中对state_machine::enabled()的判断用于分流 bang shell 命令等入口逻辑以及 crates/goose/src/acp/server/load_session.rs会话恢复时判断是否走状态机恢复路径。状态机目录本身按“操作operation”拆分每个文件对应一类会话操作例如 crates/goose/src/agents/state_machine/ 下的ops_llm.rs推理、ops_toolcalling.rs工具执行、ops_compaction.rs上下文压缩、ops_steer.rssteer 队列、ops_retry.rs、ops_maxturns.rs等。mod.rs统一导出这些 Operation 类型。这种“一操作一文件”的结构意味着修改任何一类 agent 行为时都能在两侧找到对称的实现位置去比对。测试侧同样印证了双路径要求crates/goose/src/agents/state_machine/tests/agent_reply.rs 使用env_lock::lock_env在GOOSE_STATE_MACHINESome(1)与None之间切换来分别断言两条路径的行为crates/goose/tests/agent.rs 中也有显式锁定该环境变量的测试用例。贡献者在写测试时可以参考这一模式。AI 代码审查所有意见都必须被回应项目使用 codex 作为 AI 代码审查者。流程要求非常严格AI 提出的每一条意见都必须被处理——要么修改代码要么用一行回复说明“为什么这不是问题或不值得修”。如果不处理PR 可能被关闭并收到指向 CONTRIBUTING.md 该章节的回复处理完评论后可以随时重新打开 PR。负责任的 AI 使用守则文档对“用 AI 贡献”持明确态度不需要声明你用了 AI给一个 Agent 项目做贡献不用 AI 才奇怪但在机器人革命到来之前你对最终代码负责。提交 PR 前必须自己审查过代码明显跳过这一步的“vibe coded”提交会被关闭。文档给出的四条实操提示值得逐字记住先想再写Agent 倾向于直接跳到写代码。应基于自己对代码的理解先讲清目标架构或让 Agent 先探索代码再提出方案。第一次实现不理想就推倒重来把学到的东西用于下一次。发现偷懒LLM 会让自己的活变轻松——写毫无用处的测试、把类型放宽或加可选来绕过编译器、捕获异常只打日志而不处理错误、不管合适与否都照抄本地既有模式。要顶回去。发现不确定Agent 嘴上说“我现在完全看清问题了”但往往并没有。看到它反复摇摆时要指出来另一个信号是它开始罗列“我修复了 N 种情况”或者开始写过度防御性的代码。发现膨胀Agent 喜欢插入冗余注释尤其是注释“本次改动做了什么”而不是“这段代码是什么”创建大量实际什么都没测的测试或者测实现细节而非测试意图还倾向于“以防万一”到处打日志。开发环境搭建Hermit 管理依赖goose 由 Rust 二进制与 Electron 桌面应用组成。开发依赖Rust、Node、pnpm、just 等通过Hermit管理。进入项目后激活source bin/activate-hermit也可以配置 Hermit 的 shell hook 自动激活这样每次cd进项目时 Hermit 会自动生效推荐。标准命令则通过just提供快捷方式命令清单定义在仓库根目录的 Justfile 中just --list可查看全部任务。Windows Subsystem for LinuxWSLWSL 用户可能还需要安装build-essential与libxcb否则会遇到ccC 编译器链接错误sudo apt update # 刷新软件包列表尚未安装 sudo apt install build-essential # 安装全部核心编译工具 sudo apt install libxcb1-dev # X C Binding (XCB) 库的开发包Rust 侧开发编译、运行与四项检查首次编译并体验 goosecd goose source ./bin/activate-hermit cargo build完成后即可使用 debug 构建的产物包括 goose CLI./target/debug/goose --help首次使用需要先完成配置./target/debug/goose configure当某个 LLM provider 连接成功后就可以启动会话./target/debug/goose session日常迭代中可以用cargo run -p goose-cli一边重编译一边运行。修改 Rust 代码后应通过 CLI 实测或运行检查、测试与 lintercargo check # 确认改动可以编译 cargo test # 带着改动跑测试 cargo fmt # 格式化代码 cargo clippy --all-targets -- -D warnings # 运行 linter这四项也正是 Justfile 中check-everything配方对 Rust 侧做的事——它依次执行cargo fmt --all、cargo clippy --all-targets -- -D warnings再到ui/desktop下执行pnpm run lint:check相当于提交前的完整风格校验。Node/Electron 侧开发just run-ui 与常见白屏问题运行桌面应用just run-ui对照 Justfile 中该配方的实现run-ui会先调用release-binary即cargo build --release -p goose-cli --bin goose并把产物拷贝到ui/desktop/src/bin/再进入ui/desktop执行pnpm install pnpm run start-gui。因此它是以 release 方式构建 Rust等价于cargo build -r后启动 Electron 进程。应用会打开窗口并展示首次配置流程完成配置后即可使用。GUI 代码改动都在ui/desktop目录下进行。排障just run-ui出现白屏如果应用打开后是空白窗口日志中出现Cannot read properties of null (reading useRef)说明node_modules过期并加载了两份 React。删除后重装即可rm -rf ui/desktop/node_modules cd ui pnpm install调试外部 ACP 后端要调试外部 ACP 后端需要在 IDE 中运行它具体配置取决于所用 IDE。要运行的命令是export GOOSE_SERVER__SECRET_KEYtest cargo run --package goose-cli --bin goose -- serve --platform desktop --enable-scheduler --host 127.0.0.1 --port 3000debug-ui配方默认连接http://127.0.0.1:3000。如果后端使用其他端口启动 UI 时设置GOOSE_PORT或把GOOSE_EXTERNAL_BACKEND_URL设为后端的 HTTP 基础地址。后端跑起来之后执行just debug-uiUI 就会连接到 IDE 中启动的后端从而可以在与 UI 交互的同时打断点、单步执行后端代码。从 Justfile 看debug-ui配方实际设置了GOOSE_EXTERNAL_BACKENDtrue并将GOOSE_SERVER__SECRET_KEY默认设为test若未设置这与文档描述一致同文件中的run-server配方则是直接以GOOSE_SERVER__SECRET_KEY环境变量启动同一后端命令的等价入口。GOOSE_SERVER__SECRET_KEY在 CLI 侧的定义可见 crates/goose-cli/src/cli.rs其中serve子命令也提供了不强制要求该密钥的选项。创建与同步 Fork创建 Fork 的标准流程在项目仓库页面点击右上角 “Fork”在你的账号下生成your-username/goose。克隆你的 Fork而不是主仓库。本地拉取源码可以使用镜像地址git clone https://gitcode.com/GitHub_Trending/goose3/goose.git cd goose把主仓库加为 upstreamgit remote add upstream 主仓库地址为改动创建分支git checkout -b my-feature-branch同步主仓库到本地git fetch upstream git checkout main git merge upstream/main推送到自己的 Forkgit push origin my-feature-branch从 Fork 分支向主仓库的 main 分支发起 Pull Request。保持 Fork 最新为减少合并冲突、加快 PR 合入应保持分支与主仓库同步确认 upstream 已添加git remote add upstream 主仓库地址已设置可跳过git fetch upstream拉取最新变更git checkout your-branch-name切到你的开发分支git merge upstream/main合并主分支解决冲突并提交git push origin your-branch-name推回 Fork。提交 PR 前应完成上述同步确保改动与主仓库最新状态兼容从而简化评审。开发期环境变量切换 Provider 与隔离测试环境开发过程中频繁调整 provider 配置时可以用环境变量“热切换”无需重复配置。通过GOOSE_PROVIDER可以改变 goose 指向的 provider。如果 keychain 中已有该 provider 的凭据来自此前配置会直接复用。为了自动化或免官方设置地测试也可以直接设置对应 provider 的环境变量例如ANTHROPIC_API_KEY、OPENAI_API_KEY、DATABRICKS_HOST。仓库内的 环境变量指南 还补充了GOOSE_PROVIDER__TYPE、GOOSE_PROVIDER__HOST、GOOSE_PROVIDER__API_KEY等细化变量可用于覆盖 provider 的实现类型、自定义 API 端点与密钥方便指向本地或自建的兼容端点。用 GOOSE_PATH_ROOT 隔离测试环境在测试改动或同时运行多套 goose 配置时用GOOSE_PATH_ROOT隔离数据# 干净的测试环境 export GOOSE_PATH_ROOT/tmp/goose-test ./target/debug/goose session # 或者只对单条命令生效 GOOSE_PATH_ROOT/tmp/goose-dev cargo run -p goose-cli -- session该变量会在指定路径下创建相互隔离的config/、data/、state/目录避免测试会话污染主安装环境。同样的隔离思路在 Justfile 的run-ui-playwright配方中也有体现它把GOOSE_PATH_ROOT指向带时间戳的临时目录后再启动 UI实现每次 Playwright 调试运行互不干扰。接入本地 Langfuse 查看 Traces要启用基于本地自托管 Langfuse 的 trace 追踪按 Langfuse 官方自托管文档Docker Compose 方式在本地启动 Langfuse创建组织、项目与 API 凭据设置 goose 连接 Langfuse 所需的环境变量export LANGFUSE_INIT_PROJECT_PUBLIC_KEYpublickey-local export LANGFUSE_INIT_PROJECT_SECRET_KEYsecretkey-local之后即可在本地 Langfuse 的 Web 界面默认端口 3000中查看 trace。提交规范Conventional Commits项目遵循Conventional Commits规范来约束 PR 标题。这样做是为了让项目历史更易读并支撑版本管理与 changelog 生成的自动化。撰写提交信息时请遵循type(scope): description形式如fix(session): ...、chore(release): ...Justfile 中prepare-release流程的提交信息chore(release): release version {{ version }}就是该规范的直接体现。代码之外的其他贡献方式除了提交代码goose 欢迎多种形式的参与Star 项目如果 goose 对你有价值可以在仓库页面点亮 Star提问在社区渠道提问既帮助项目改进也帮助其他成员反馈发现功能需求或问题可以通过新建 Issue、发起 Discussion 或社区渠道反馈参与社区活动项目定期举办工作坊与头脑风暴等线上活动可通过订阅活动日历或关注社交账号跟进改进文档改善现有文档质量或补充新页面帮助其他成员回复社区帖子、为他人做 code review展示你的作品在社区“分享你的作品”频道晒出你基于 goose 的项目或文章推荐与传播在社区中为出色的项目或成员点赞并把 goose 分享给更多人。任何环节遇到问题都可以通过新建 Issue 联系维护者。【免费下载链接】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），仅供参考