Cube Sandbox 贡献指南构建环境、社区文档频道与 Pull Request 全流程【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandboxCube Sandbox 是一个面向 AI Agent 的即时、高并发、安全且轻量的沙箱平台底层由 Go 与 Rust 双语言技术栈、KVM MicroVM 与 eBPF 网络隔离共同支撑。本文以官方《为 Cube Sandbox 贡献》指南为骨架结合仓库内的 Makefile、builder 镜像、社区文档模板与真实示例文章系统梳理从环境准备、代码构建到提交 PR 与维护社区文档的完整流程帮助你第一次贡献就符合项目的工具链约定、提交规范与 DCO 要求。贡献方式概览Cube Sandbox 对社区开放的贡献途径共有四类覆盖从用户反馈到核心开发的完整链路报告 Bug— 在项目 Issue 区提交问题并附上可复现步骤便于维护者快速定位。建议新功能— 在 Issue 中描述你的使用场景和建议方案说明要解决的真实问题。改善文档— 修复错别字、优化表述或补充示例文档质量同样是有效贡献。提交代码— 修复 Bug、实现新功能或改进性能这是深度参与项目演进的主要方式。社区文档三大频道让经验沉淀为可检索的知识除常规文档修缮外项目在docs/guide/下维护了三个面向社区的文档频道鼓励把部署运维经验、真实业务案例与生态集成方案沉淀下来故障排障Troubleshooting— 部署与运维经验总结存放于 docs/guide/troubleshooting/index.md 和 docs/zh/guide/troubleshooting/index.md。该频道明确要求双语 PR每篇投稿必须同时提供英文与中文两个版本只更新单一语言的 PR 不会被合并。应用案例Use Cases— 真实业务或生产环境的使用案例存放于 docs/guide/usecases/index.md 和 docs/zh/guide/usecases/index.md。生态集成Integrations— 各框架或 Agent 的集成指南每个框架一篇存放于 docs/guide/integrations/index.md 和 docs/zh/guide/integrations/index.md。仓库中已有该机制落地的真实样例。例如故障排障频道收录了《沙箱网段和局域网冲突导致创建模板超时》——它记录了cubemastercli run fail: template tpl-xx creation failed: context deadline exceeded的报错现象、触发条件、根因与解决方案《Host Mounts Fail with Permission Denied》则展示了如何在沙箱内以Permission denied为起点还原宿主机挂载权限问题。这些文章都遵循了统一的问题现象 → 环境 → 根因 → 解决方案 → 参考叙事结构。社区文档 PR 要求向这些频道投稿需要遵守以下硬性规则选择一种语言— 每篇新增或更新的文章须提供docs/guide/频道/slug.md或docs/zh/guide/频道/slug.md其中的一个版本其中故障排障与应用案例频道要求中英双语同时提交。如需提供中英两种语言使用相同文件名— 文件名统一采用英文 kebab-case 格式例如langchain.md或e2b-api-401-timeout.md保证两个语言版本的 URL 对齐保持 frontmatter 一致— 两个语言版本应使用相同的 frontmatter 字段title、author、date、tags、lang。从提供的模板开始— 每个频道均包含一个_template.md模板文件以及列有当前文章列表和使用说明的索引页请以此为起点进行编写。各频道的模板文件设计各有侧重写作时应严格对齐其章节骨架故障排障模板 _template.md 要求依次给出Symptom用户可见的失败现象/报错、Environment版本、部署模式、宿主机 OS/内核、相关组件、Root Cause触发条件与原因、Resolution可复制粘贴的命令与配置、References生态集成模板 _template.md 要求覆盖Integration Target and Version被测版本范围、Prerequisites、Integration Steps逐步可验证的集成流程、Key Code Snippets最小可用代码或配置、Caveats限流、兼容性约束与运维提示、References应用案例模板 _template.md 要求按Business Context、Key Challenges、Solution with Cube Sandbox、Results and Benefits、References组织一篇完整的落地故事。环境要求开始贡献前需要准备什么贡献代码前请先确认本机满足以下环境要求支持 KVM 的 Linux 系统x86_64——沙箱运行依赖 KVM 虚拟化能力Docker——用于运行统一的构建镜像Go 1.21——编译 CubeMaster、Cubelet、CubeProxy 等 Go 组件Rust 1.75需包含x86_64-unknown-linux-musltarget——编译 CubeAPI、CubeShim、agent、hypervisor 等 Rust 组件protocProtocol Buffers 编译器——生成 Cubelet 等组件依赖的 gRPC/protobuf 代码。构建环境基于 Docker 的统一构建流水线Cube Sandbox 提供了基于 Docker 的构建镜像以确保所有贡献者在完全一致的构建环境中编译避免在我机器上能跑的工具链漂移问题。构建镜像与常用命令# 构建构建镜像 make builder-image # 中国大陆用户可通过镜像源获取 apt 软件包 make builder-image MIRRORcn # 进入构建容器的交互式 Shell make builder-shell # 构建所有 Go 组件CubeMaster、Cubelet、… make all # 构建单个组件 make cubemaster make cubelet make agent make shim # 清理本地 Go/Rust 编译产物不清全局缓存 make clean完整的构建目标列表请参见 Makefile。构建镜像的工程细节从 Makefile 可以看到构建镜像相关的几个关键变量BUILDER_IMAGE ? cube-sandbox-builder:ubuntu2004— 默认构建镜像名BUILDER_DOCKERFILE ? docker/Dockerfile.builder— 镜像构建文件位于 docker/Dockerfile.builderBUILDER_HOME ? $(HOME)/.cache/cube-sandbox-builder— 宿主机上持久化的构建缓存目录容器退出后 Go mod、Cargo registry 等缓存仍被保留避免重复下载BUILDER_USER ? $(UID):$(GID)— 构建容器默认以宿主用户身份运行这样通过 bind mount 产出的二进制在宿主机上可直接读写。builder-image目标还内置了增量构建判断Makefile只有当镜像缺失、或镜像内嵌的 s3lvol SPDK/AWS 依赖 stamp 与当前仓库引脚不一致时才会重新构建否则直接复用已有镜像如需强制重建可设置BUILDER_FORCE_REBUILD1。make builder-shell启动交互式容器Makefile把整个仓库挂载到/workspace同时挂载持久化的BUILDER_HOME并将CARGO_HOME、RUSTUP_HOME、GOPATH指向容器内目录保证 Go 与 Rust 的依赖缓存都能跨会话复用。若宿主机的~/.git-credentials存在还会被带入容器方便在容器内直接拉取私有依赖。MIRRORcn 的作用MIRRORcn会向 Docker 构建传入一组镜像源参数MakefileAPT_MIRROR_BASE默认指向http://mirrors.tencent.comarm64 架构自动走ubuntu-portsLLVM_MIRROR_BASE默认指向https://mirrors.zju.edu.cn/llvm-apt用于获取 clang-14 等 LLVM 软件包GPG 密钥已内置在 docker/llvm-snapshot.gpg.key构建过程不从外部下载RUSTUP_DIST_SERVER/RUSTUP_UPDATE_ROOT默认指向https://rsproxy.cn。值得注意的是这个构建期的MIRRORcn与deploy/one-click运行时使用的MIRRORcn是两套独立机制前者只影响构建镜像内的软件源。Builder 镜像内置的工具链docker/Dockerfile.builder 基于ubuntu:20.04封装了全量工具链其版本可以从 Dockerfile 的 ARG 中直接确认Go 1.25.7、protoc 28.3、libseccomp 2.5.5Rust 则按组件需求安装多个工具链版本默认 1.89hypervisor 使用 1.77.2E2B API 使用 1.85agent 使用 1.89并预装clang-14、musl-tools、protoc-gen-go、protoc-gen-go-grpc以及 CubeS3lvol 构建所需的 SPDK/DPDK Python 依赖。这意味着即使本机只有最低要求的 Go 1.21 / Rust 1.75容器内也始终使用项目验证过的固定版本。项目结构多语言组件全景速览贡献代码前先了解各模块的职责与语言有助于把改动放到正确的位置目录语言说明CubeAPI/Rust兼容 E2B 的 REST API 网关CubeMaster/Go调度器与集群管理Cubelet/Go节点级沙箱生命周期管理 AgentCubeProxy/Go沙箱请求路由的反向代理CubeShim/Rust连接 containerd 与 KVM MicroVM 的 Shimagent/Rust运行在每个沙箱内部的 Guest Daemonhypervisor/Rust基于 KVM 的 MicroVM 管理器Cloud Hypervisor 分支CubeNet/GoCubeVS 基于 eBPF 的网络隔离deploy/Shell部署脚本与 Guest 镜像工具examples/PythonSDK 示例与端到端使用场景docs/MarkdownVitePress 文档站中英双语从 Makefile 的BINARIES列表可以看出make all会产出agent、cube-init、cube-volume-s3、cubeapi、cubelet、cubemaster、cubeops、cubevsmapdump、shim等全部默认二进制统一输出到_output/bin目录。所有带版本信息的二进制都会消费统一的CUBE_VERSION/CUBE_COMMIT/CUBE_BUILD_TIME三元组Makefile保证--version输出在本地构建与一键发布两条路径上保持一致。提交 Pull Request从分支到合入的完整流程标准操作步骤Fork仓库并从master分支创建功能分支。修改代码— 保持每个提交专注且原子化。测试— 确保现有测试和 Lint 检查均能通过。添加测试— 行为变更时请补充针对性的测试覆盖。更新文档— 若改动影响用户可见的行为请同步更新相关文档。发起 PR— 描述改动的动机和内容并关联相关 Issue。提交组织规范提交应保持逻辑清晰、相互独立这直接关系到维护者能否高效审查每次提交只涉及一个组件— 若改动跨越多个组件如同时涉及CubeAPI和Cubelet请拆分为多个独立提交每个组件单独提交。保持提交原子性— 每个提交应代表一个单一、完整的改动能够被独立理解和审查。重构与行为改动分开— 不要将代码清理或重构与功能性改动混在同一提交中。按逻辑顺序排列提交— 当 PR 包含多个提交时应使每个提交都基于前一个例如先提交基础设施改动再提交依赖它的功能改动。提交信息规范编写清晰的提交信息说明改动的原因而不仅仅是改了什么component: 改动的简短描述 更详细的说明阐述改动的动机、权衡或背景。 Closes #123 Signed-off-by: Your Name your.emailexample.com摘要部分需以组件名称作为前缀例如cubeapi:、cubelet:、docs:、shim:。这样在浏览git log时可以按组件维度快速过滤历史。开发者来源证书DCO所有提交必须包含Signed-off-by行以证明你已阅读并同意开发者来源证书DCO。这表明你有权在本项目许可证下提交该贡献。在提交时使用-s参数自动添加git commit -s -m component: 你的提交信息或在提交信息末尾手动追加以下内容Signed-off-by: Your Name your.emailexample.com不包含有效Signed-off-by行的提交将不会被接受。代码风格Go— 遵循标准gofmt格式化规范及项目约定。仓库顶层make fmt会递归对所有组件执行格式化Makefile涉及 agent、guest-init、CubeAPI、Cubelet、CubeMaster、CubeShim、CubeOps、hypervisor、sdk/go 等十余个模块非容器路径会自动路由进 builder 容器执行以避免宿主机工具链差异。Rust— 遵循rustfmt和clippy的建议二者均在 builder 镜像内为各工具链预装了对应组件。文档— 使用清晰简洁的语言中英文文档应保持同步。Issue / PR 关闭规则避免无效沟通的约定了解维护者对 Issue 与 PR 的处置标准可以避免你的劳动成果因信息不全而过期关闭need-info超时未回复维护者要求补充信息或修改后作者超过两周未回应将被作为过期项关闭。待补充所需信息或完成修改后可重新打开。已解决或被取代问题已修复、功能已实现或已被其他 PR/方案取代。不在项目范围内 / 不予处理关闭时会说明原因。重复提交关闭并附上原始 Issue/PR 链接。报告安全问题如果你发现安全漏洞请通过 GitHub Security Advisories 进行负责任的披露而不是在公开 Issue 中提交。漏洞的私下报告流程能避免在修复前将攻击面暴露给公众。许可证向 Cube Sandbox 贡献代码即表示你同意你的贡献将以 Apache License 2.0 进行许可。这意味着你的代码将与整个项目以相同的开源许可协议向社区开放。AI 生成代码政策人类与 AI 的分工边界随着 AI 辅助编程成为常态项目对 AI 生成代码的署名规则有明确规定AI Agent不得添加Signed-off-by标签。只有人类才能合法地证明开发者来源证书DCO因为 DCO 要求签名人对自己提交的内容承担法律责任。人类提交者有责任审查所有 AI 生成的代码确保符合许可证要求添加自己的Signed-off-by标签以证明 DCO对贡献内容承担全部责任。仓库根目录的 AGENTS.md 进一步细化了该政策当人类提交者借助 AI Agent 完成工作时提交信息或 PR 描述必须附加Assisted-by: AGENT_NAME:MODEL_VERSION标签当提交/PR 完全由 AI Agent 自主完成无人类创作时则改用Autonomously-by: AGENT_NAME:MODEL_VERSION标签其中AGENT_NAME是所使用的 AI 工具或框架名称MODEL_VERSION是具体模型版本。这套标签体系确保 AI 贡献在项目历史中始终可见、可追溯。总结对 Cube Sandbox 的一次成功贡献通常需要同时满足三层要求工具链层面通过make builder-image与make builder-shell进入统一构建环境避免本机 Go/Rust 版本漂移流程层面遵循一组件一提交、提交原子化、Signed-off-by必填、行为变更同步补测试与文档的约定内容层面社区文档投稿需从各频道_template.md起步遵守 kebab-case 命名与 frontmatter 一致性中英双语保持对齐。沿着本文梳理的路径你可以从第一份 Issue 或文档 PR 开始逐步深入这个多语言、多组件协同的沙箱平台。【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cube Sandbox 贡献指南：构建环境、社区文档频道与 Pull Request 全流程
Cube Sandbox 贡献指南构建环境、社区文档频道与 Pull Request 全流程【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandboxCube Sandbox 是一个面向 AI Agent 的即时、高并发、安全且轻量的沙箱平台底层由 Go 与 Rust 双语言技术栈、KVM MicroVM 与 eBPF 网络隔离共同支撑。本文以官方《为 Cube Sandbox 贡献》指南为骨架结合仓库内的 Makefile、builder 镜像、社区文档模板与真实示例文章系统梳理从环境准备、代码构建到提交 PR 与维护社区文档的完整流程帮助你第一次贡献就符合项目的工具链约定、提交规范与 DCO 要求。贡献方式概览Cube Sandbox 对社区开放的贡献途径共有四类覆盖从用户反馈到核心开发的完整链路报告 Bug— 在项目 Issue 区提交问题并附上可复现步骤便于维护者快速定位。建议新功能— 在 Issue 中描述你的使用场景和建议方案说明要解决的真实问题。改善文档— 修复错别字、优化表述或补充示例文档质量同样是有效贡献。提交代码— 修复 Bug、实现新功能或改进性能这是深度参与项目演进的主要方式。社区文档三大频道让经验沉淀为可检索的知识除常规文档修缮外项目在docs/guide/下维护了三个面向社区的文档频道鼓励把部署运维经验、真实业务案例与生态集成方案沉淀下来故障排障Troubleshooting— 部署与运维经验总结存放于 docs/guide/troubleshooting/index.md 和 docs/zh/guide/troubleshooting/index.md。该频道明确要求双语 PR每篇投稿必须同时提供英文与中文两个版本只更新单一语言的 PR 不会被合并。应用案例Use Cases— 真实业务或生产环境的使用案例存放于 docs/guide/usecases/index.md 和 docs/zh/guide/usecases/index.md。生态集成Integrations— 各框架或 Agent 的集成指南每个框架一篇存放于 docs/guide/integrations/index.md 和 docs/zh/guide/integrations/index.md。仓库中已有该机制落地的真实样例。例如故障排障频道收录了《沙箱网段和局域网冲突导致创建模板超时》——它记录了cubemastercli run fail: template tpl-xx creation failed: context deadline exceeded的报错现象、触发条件、根因与解决方案《Host Mounts Fail with Permission Denied》则展示了如何在沙箱内以Permission denied为起点还原宿主机挂载权限问题。这些文章都遵循了统一的问题现象 → 环境 → 根因 → 解决方案 → 参考叙事结构。社区文档 PR 要求向这些频道投稿需要遵守以下硬性规则选择一种语言— 每篇新增或更新的文章须提供docs/guide/频道/slug.md或docs/zh/guide/频道/slug.md其中的一个版本其中故障排障与应用案例频道要求中英双语同时提交。如需提供中英两种语言使用相同文件名— 文件名统一采用英文 kebab-case 格式例如langchain.md或e2b-api-401-timeout.md保证两个语言版本的 URL 对齐保持 frontmatter 一致— 两个语言版本应使用相同的 frontmatter 字段title、author、date、tags、lang。从提供的模板开始— 每个频道均包含一个_template.md模板文件以及列有当前文章列表和使用说明的索引页请以此为起点进行编写。各频道的模板文件设计各有侧重写作时应严格对齐其章节骨架故障排障模板 _template.md 要求依次给出Symptom用户可见的失败现象/报错、Environment版本、部署模式、宿主机 OS/内核、相关组件、Root Cause触发条件与原因、Resolution可复制粘贴的命令与配置、References生态集成模板 _template.md 要求覆盖Integration Target and Version被测版本范围、Prerequisites、Integration Steps逐步可验证的集成流程、Key Code Snippets最小可用代码或配置、Caveats限流、兼容性约束与运维提示、References应用案例模板 _template.md 要求按Business Context、Key Challenges、Solution with Cube Sandbox、Results and Benefits、References组织一篇完整的落地故事。环境要求开始贡献前需要准备什么贡献代码前请先确认本机满足以下环境要求支持 KVM 的 Linux 系统x86_64——沙箱运行依赖 KVM 虚拟化能力Docker——用于运行统一的构建镜像Go 1.21——编译 CubeMaster、Cubelet、CubeProxy 等 Go 组件Rust 1.75需包含x86_64-unknown-linux-musltarget——编译 CubeAPI、CubeShim、agent、hypervisor 等 Rust 组件protocProtocol Buffers 编译器——生成 Cubelet 等组件依赖的 gRPC/protobuf 代码。构建环境基于 Docker 的统一构建流水线Cube Sandbox 提供了基于 Docker 的构建镜像以确保所有贡献者在完全一致的构建环境中编译避免在我机器上能跑的工具链漂移问题。构建镜像与常用命令# 构建构建镜像 make builder-image # 中国大陆用户可通过镜像源获取 apt 软件包 make builder-image MIRRORcn # 进入构建容器的交互式 Shell make builder-shell # 构建所有 Go 组件CubeMaster、Cubelet、… make all # 构建单个组件 make cubemaster make cubelet make agent make shim # 清理本地 Go/Rust 编译产物不清全局缓存 make clean完整的构建目标列表请参见 Makefile。构建镜像的工程细节从 Makefile 可以看到构建镜像相关的几个关键变量BUILDER_IMAGE ? cube-sandbox-builder:ubuntu2004— 默认构建镜像名BUILDER_DOCKERFILE ? docker/Dockerfile.builder— 镜像构建文件位于 docker/Dockerfile.builderBUILDER_HOME ? $(HOME)/.cache/cube-sandbox-builder— 宿主机上持久化的构建缓存目录容器退出后 Go mod、Cargo registry 等缓存仍被保留避免重复下载BUILDER_USER ? $(UID):$(GID)— 构建容器默认以宿主用户身份运行这样通过 bind mount 产出的二进制在宿主机上可直接读写。builder-image目标还内置了增量构建判断Makefile只有当镜像缺失、或镜像内嵌的 s3lvol SPDK/AWS 依赖 stamp 与当前仓库引脚不一致时才会重新构建否则直接复用已有镜像如需强制重建可设置BUILDER_FORCE_REBUILD1。make builder-shell启动交互式容器Makefile把整个仓库挂载到/workspace同时挂载持久化的BUILDER_HOME并将CARGO_HOME、RUSTUP_HOME、GOPATH指向容器内目录保证 Go 与 Rust 的依赖缓存都能跨会话复用。若宿主机的~/.git-credentials存在还会被带入容器方便在容器内直接拉取私有依赖。MIRRORcn 的作用MIRRORcn会向 Docker 构建传入一组镜像源参数MakefileAPT_MIRROR_BASE默认指向http://mirrors.tencent.comarm64 架构自动走ubuntu-portsLLVM_MIRROR_BASE默认指向https://mirrors.zju.edu.cn/llvm-apt用于获取 clang-14 等 LLVM 软件包GPG 密钥已内置在 docker/llvm-snapshot.gpg.key构建过程不从外部下载RUSTUP_DIST_SERVER/RUSTUP_UPDATE_ROOT默认指向https://rsproxy.cn。值得注意的是这个构建期的MIRRORcn与deploy/one-click运行时使用的MIRRORcn是两套独立机制前者只影响构建镜像内的软件源。Builder 镜像内置的工具链docker/Dockerfile.builder 基于ubuntu:20.04封装了全量工具链其版本可以从 Dockerfile 的 ARG 中直接确认Go 1.25.7、protoc 28.3、libseccomp 2.5.5Rust 则按组件需求安装多个工具链版本默认 1.89hypervisor 使用 1.77.2E2B API 使用 1.85agent 使用 1.89并预装clang-14、musl-tools、protoc-gen-go、protoc-gen-go-grpc以及 CubeS3lvol 构建所需的 SPDK/DPDK Python 依赖。这意味着即使本机只有最低要求的 Go 1.21 / Rust 1.75容器内也始终使用项目验证过的固定版本。项目结构多语言组件全景速览贡献代码前先了解各模块的职责与语言有助于把改动放到正确的位置目录语言说明CubeAPI/Rust兼容 E2B 的 REST API 网关CubeMaster/Go调度器与集群管理Cubelet/Go节点级沙箱生命周期管理 AgentCubeProxy/Go沙箱请求路由的反向代理CubeShim/Rust连接 containerd 与 KVM MicroVM 的 Shimagent/Rust运行在每个沙箱内部的 Guest Daemonhypervisor/Rust基于 KVM 的 MicroVM 管理器Cloud Hypervisor 分支CubeNet/GoCubeVS 基于 eBPF 的网络隔离deploy/Shell部署脚本与 Guest 镜像工具examples/PythonSDK 示例与端到端使用场景docs/MarkdownVitePress 文档站中英双语从 Makefile 的BINARIES列表可以看出make all会产出agent、cube-init、cube-volume-s3、cubeapi、cubelet、cubemaster、cubeops、cubevsmapdump、shim等全部默认二进制统一输出到_output/bin目录。所有带版本信息的二进制都会消费统一的CUBE_VERSION/CUBE_COMMIT/CUBE_BUILD_TIME三元组Makefile保证--version输出在本地构建与一键发布两条路径上保持一致。提交 Pull Request从分支到合入的完整流程标准操作步骤Fork仓库并从master分支创建功能分支。修改代码— 保持每个提交专注且原子化。测试— 确保现有测试和 Lint 检查均能通过。添加测试— 行为变更时请补充针对性的测试覆盖。更新文档— 若改动影响用户可见的行为请同步更新相关文档。发起 PR— 描述改动的动机和内容并关联相关 Issue。提交组织规范提交应保持逻辑清晰、相互独立这直接关系到维护者能否高效审查每次提交只涉及一个组件— 若改动跨越多个组件如同时涉及CubeAPI和Cubelet请拆分为多个独立提交每个组件单独提交。保持提交原子性— 每个提交应代表一个单一、完整的改动能够被独立理解和审查。重构与行为改动分开— 不要将代码清理或重构与功能性改动混在同一提交中。按逻辑顺序排列提交— 当 PR 包含多个提交时应使每个提交都基于前一个例如先提交基础设施改动再提交依赖它的功能改动。提交信息规范编写清晰的提交信息说明改动的原因而不仅仅是改了什么component: 改动的简短描述 更详细的说明阐述改动的动机、权衡或背景。 Closes #123 Signed-off-by: Your Name your.emailexample.com摘要部分需以组件名称作为前缀例如cubeapi:、cubelet:、docs:、shim:。这样在浏览git log时可以按组件维度快速过滤历史。开发者来源证书DCO所有提交必须包含Signed-off-by行以证明你已阅读并同意开发者来源证书DCO。这表明你有权在本项目许可证下提交该贡献。在提交时使用-s参数自动添加git commit -s -m component: 你的提交信息或在提交信息末尾手动追加以下内容Signed-off-by: Your Name your.emailexample.com不包含有效Signed-off-by行的提交将不会被接受。代码风格Go— 遵循标准gofmt格式化规范及项目约定。仓库顶层make fmt会递归对所有组件执行格式化Makefile涉及 agent、guest-init、CubeAPI、Cubelet、CubeMaster、CubeShim、CubeOps、hypervisor、sdk/go 等十余个模块非容器路径会自动路由进 builder 容器执行以避免宿主机工具链差异。Rust— 遵循rustfmt和clippy的建议二者均在 builder 镜像内为各工具链预装了对应组件。文档— 使用清晰简洁的语言中英文文档应保持同步。Issue / PR 关闭规则避免无效沟通的约定了解维护者对 Issue 与 PR 的处置标准可以避免你的劳动成果因信息不全而过期关闭need-info超时未回复维护者要求补充信息或修改后作者超过两周未回应将被作为过期项关闭。待补充所需信息或完成修改后可重新打开。已解决或被取代问题已修复、功能已实现或已被其他 PR/方案取代。不在项目范围内 / 不予处理关闭时会说明原因。重复提交关闭并附上原始 Issue/PR 链接。报告安全问题如果你发现安全漏洞请通过 GitHub Security Advisories 进行负责任的披露而不是在公开 Issue 中提交。漏洞的私下报告流程能避免在修复前将攻击面暴露给公众。许可证向 Cube Sandbox 贡献代码即表示你同意你的贡献将以 Apache License 2.0 进行许可。这意味着你的代码将与整个项目以相同的开源许可协议向社区开放。AI 生成代码政策人类与 AI 的分工边界随着 AI 辅助编程成为常态项目对 AI 生成代码的署名规则有明确规定AI Agent不得添加Signed-off-by标签。只有人类才能合法地证明开发者来源证书DCO因为 DCO 要求签名人对自己提交的内容承担法律责任。人类提交者有责任审查所有 AI 生成的代码确保符合许可证要求添加自己的Signed-off-by标签以证明 DCO对贡献内容承担全部责任。仓库根目录的 AGENTS.md 进一步细化了该政策当人类提交者借助 AI Agent 完成工作时提交信息或 PR 描述必须附加Assisted-by: AGENT_NAME:MODEL_VERSION标签当提交/PR 完全由 AI Agent 自主完成无人类创作时则改用Autonomously-by: AGENT_NAME:MODEL_VERSION标签其中AGENT_NAME是所使用的 AI 工具或框架名称MODEL_VERSION是具体模型版本。这套标签体系确保 AI 贡献在项目历史中始终可见、可追溯。总结对 Cube Sandbox 的一次成功贡献通常需要同时满足三层要求工具链层面通过make builder-image与make builder-shell进入统一构建环境避免本机 Go/Rust 版本漂移流程层面遵循一组件一提交、提交原子化、Signed-off-by必填、行为变更同步补测试与文档的约定内容层面社区文档投稿需从各频道_template.md起步遵守 kebab-case 命名与 frontmatter 一致性中英双语保持对齐。沿着本文梳理的路径你可以从第一份 Issue 或文档 PR 开始逐步深入这个多语言、多组件协同的沙箱平台。【免费下载链接】CubeSandboxInstant, Concurrent, Secure Lightweight Sandbox for AI Agents.项目地址: https://gitcode.com/GitHub_Trending/cu/CubeSandbox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考