安装
curl -fsSL https://raw.githubusercontent.com/curie-eng/curie/main/get-curie.sh | bash适合谁
- 适合想在自有基础设施里使用 AI 协作能力的开发团队：Curie 是开源、可自托管的平台，运行在你自己的基础设施里，把编码 agent 变成可分派任务、可验收产出的同事。
- 核心场景是「把 GitHub issue 委派出去，收回一个待评审的实现」：Curie 负责 issue 的实现与评审，返回一个等待团队接受的 pull request 或 merge request。
- 也适合 Kubernetes 运维协作：只读的 Kubernetes 检查可以立即执行，配置过的变更类操作会请求人工批准，适合把巡检、诊断这类低风险的例行动作交给它。
- 适合要求审批环节留在人手里的团队：配置过的变更操作要人工重新批准，哪些动作需要先批准可由你自己配置。
- 已经维护着自己编码 agent 的团队，可用官方的
curie init --adopt ./my-existing-agent收编现有 agent。 - 不适合的情况：机器跑不了 Docker，或拿不到 Anthropic 或 OpenRouter 的模型凭证——官方列出的运行前提缺一不可。
3 分钟完成第一次尝试
前提：一台 Docker 已在运行的机器，装好 kind、kubectl 与 Helm，并准备一个 Anthropic 或 OpenRouter 模型凭证。任何一项缺失都无法按官方说明启动。
在终端执行官方安装脚本：
curl -fsSL https://raw.githubusercontent.com/curie-eng/curie/main/get-curie.sh | bash
脚本来自 Curie 仓库的 main 分支；管道式命令会以你的用户权限直接执行远程脚本，介意可先下载审查内容再运行。
第一次尝试选低风险路径：挑一个描述清楚、影响范围小的仓库 issue，委派给 Curie 做实现与评审。它完成后会返回一个 pull request 或 merge request，等待你的团队接受。成功信号很明确：你在代码托管平台上收到它返回的 PR/MR，并能逐条查看其中的变更内容。
安装之后如何录入模型凭证、如何关联代码托管账号，官方说明未给出逐步指引，请以脚本输出提示和仓库文档为准。
使用案例
案例一：把 issue 变成待审 PR。场景：团队仓库里积压了一个边界清晰的实现类 issue，一直没人手及时处理。发起方式：把这个 issue 委派给 Curie，对应官方描述的「委派 issue 实现并评审」流程。过程与结果：它完成后交回 PR/MR，你在自己的托管平台上逐条评审变更；可确认的终点是拿到一个等待团队接受的 PR/MR。
案例二：Kubernetes 只读巡检。场景：需要了解集群当前状况，又不想为一次例行的状态检查走完整的变更审批。发起方式：向 Curie 提出只读的 Kubernetes 检查请求，用到的正是官方说明的只读 Kubernetes 工具。过程与结果：只读操作立即执行，不需要额外批准；如果接着要求执行配置过的变更类操作，它会先请求一次全新的人工批准再进行。首次巡检保持在只读范围内就不会遇到审批等待；想观察审批环节，再补一条变更类请求即可看到批准提示。具体提供哪些只读工具、如何调用，官方说明未逐一列出。
使用边界
- 环境前提：Docker 处于运行状态，kind、kubectl、Helm 齐备，并持有 Anthropic 或 OpenRouter 模型凭证；操作系统与硬件架构要求官方未说明。
- 副作用与确认点：只读 Kubernetes 工具立即执行；配置过的变更操作每次都会请求一次全新的人工批准；委派实现的产出为等待团队接受的 PR/MR。安装脚本会在你机器上创建什么、占用哪些目录，官方未逐一说明，执行前可先审查脚本内容。
- 运行位置：自托管平台，运行在你自己的基础设施中。
- 收编现有 agent：官方提供
curie init --adopt ./my-existing-agent命令；该命令会保留既有 agent 的哪些内容，摘录未说明。除此之外的初始化与配置流程，官方说明未展开。 - 行动前应到仓库核实的信息：安装后的凭证配置步骤、代码托管账号的接入方式、可用只读工具与可配置变更操作的完整清单、除这两家之外是否支持其他模型提供方，以及可对接编码 agent 的准确名单。动手前请逐项以仓库文档为准。