直接答案： 自托管提升了对基础设施的控制，但只有当模型路径、仓库访问、工作负载隔离、密钥、日志、备份、升级和运维归属都被明确设计时，它才既私密又可靠。
自托管一个 AI 开发平台，能让组织更好地控制代码、项目数据、模型访问和执行基础设施。它也把重要的运维责任转移到组织身上。
正确的问题不只是“我们能部署它吗？”，而是“我们能为工程团队可靠、安全、有用地运营它吗？”
在更大范围推广之前，用这份清单准备一个试点。
1. 明确自托管的理由
从你要解决的约束出发。常见理由包括：
- 源代码必须留在私有网络内；
- 开发任务需要访问内部服务；
- 组织希望集中管理模型提供商；
- 数据驻留或内部政策限制托管服务；
- 团队需要自定义镜像、算力或网络拓扑；
- 组织希望在运营上不依赖单一托管界面。
把理由写下来。它会驱动架构决策，避免自托管项目变成没有边界的基础设施工程。
2. 把控制平面与任务环境分开
一个 AI 开发平台通常有两种不同的基础设施角色。
控制平面管理用户、项目、需求、任务、模型配置和管理状态。开发环境主机运行代码、安装依赖、构建项目、执行测试并暴露预览。
分开这两种角色有助于隔离和容量规划。一阵构建高峰不应让管理控制台不可用。
MonkeyCode 当前的公开部署指引建议：
| 组件 | 起始最低配置 |
|---|---|
| MonkeyCode 控制台 | 2 核 CPU、4 GB 内存、40 GB 存储 |
| 开发环境主机 | 8 核 CPU、16 GB 内存、100 GB 存储 |
这些是起点，不是容量保证。实际容量取决于任务并发、仓库大小、构建负载、基础镜像和保留策略。
3. 先规划隔离，再谈并发
每个任务都可能执行不受信任的项目代码和模型生成的命令。把开发环境当作工作负载隔离边界。
确认：
- 任务文件系统如何分隔；
- 哪些网络目的地可达；
- 如何限制 CPU、内存、存储和执行时间；
- 凭据如何进出一个环境；
- 是否需要特权容器或宿主机挂载；
- 环境和产物何时删除；
- 开发者如何在不绕过控制的前提下检查运行中的任务。
从低并发开始。只有在观察到真实的 CPU、内存、磁盘和网络行为后，再提高并发。
4. 盘点源码控制和凭据
列出试点纳入的仓库，并使用范围狭窄的凭据。不要一开始就用组织级令牌。
对每个源码控制集成，记录：
- 仓库读写权限；
- 分支创建权限；
- pull 或 merge request 权限；
- webhook 端点和密钥；
- 令牌所有者和轮换流程；
- 审计日志可用性；
- 凭据过期时的行为。
AI agent 只应获得所选任务所需的访问权。平台的管理便利性不应扩大令牌的范围。
5. 决定如何访问模型
自托管平台并不自动意味着每个模型都在本地运行。一个部署可能调用外部模型 API、私有模型网关，或在同一网络内运行的模型。
从以下方面评估每条路径：
- 发送给提供商的代码和提示词数据；
- 提供商的保留和训练政策；
- 地区可用性和延迟；
- 认证和配额管理；
- 对你有代表性任务的模型质量；
- 提供商中断时的回退行为；
- 按团队或项目的成本可见性。
MonkeyCode 支持多个模型家族，包括 GLM、Kimi、MiniMax、Qwen 和 DeepSeek。试点应至少测试两类任务，而不是仅凭一个通用基准来选模型。
6. 构建一个批准的环境镜像
任务环境应包含项目所需的工具，而不沦为一堆不受控的凭据和软件包。
记录：
- 基础操作系统和更新计划；
- 语言运行时和包管理器；
- 构建工具、浏览器和系统库；
- 内部证书颁发机构和软件包镜像；
- 漏洞扫描和镜像签名；
- 谁能发布或选择镜像；
- 旧环境如何获得安全更新。
试点使用少量批准的镜像。过多的灵活性会让失败更难复现。
7. 把可观测性当作产品需求
运营者需要基础设施指标，开发者需要任务级证据。
至少收集：
- 控制平面的健康和错误率；
- 环境创建时间和失败率；
- 各主机的 CPU、内存、磁盘和网络使用；
- 任务时长和状态；
- 模型请求错误和限流；
- 构建和测试结果；
- 保留和清理事件。
判断哪些日志可能包含源码、提示词、模型响应或凭据，并据此施加访问和保留控制。
8. 准备备份和升级流程
识别哪些状态是持久的、哪些环境可以重建。备份持久状态，测试一次恢复，并记录归属。
升级前：
- 阅读当前项目的发布说明；
- 备份持久数据；
- 在预发布环境测试新版本；
- 运行有代表性的任务和集成；
- 定义回滚触发条件和流程；
- 沟通用户可见的变化。
开源让团队能够检查和改造系统，但并不免除日常的平台运维。
9. 设计一个小而可测的试点
选择少数几位开发者、有限的仓库集合，以及三到五种有代表性的任务类型。在第一个任务运行前先定义成功。
有用的度量包括：
- 环境启动成功率和时间；
- 达到可评审改动的任务比例；
- 构建和测试通过率；
- 人工评审时间；
- 每个完成任务的模型和基础设施成本；
- 访问或可靠性事件的数量与严重程度；
- 开发者对理解和纠正 agent 工作的信心。
试点应揭示工作流是否契合——而不只是软件能否安装。
10. 审查许可与组织政策
MonkeyCode 以 GNU Affero 通用公共许可证 v3.0 发布。与你的法务团队一起审查许可证、计划的修改和网络使用。同时，让部署与源码、密钥、第三方模型、软件供应链、日志和事件响应的既有政策保持一致。
在官方来源中核实部署路径
安装命令、配置和集成都具有时效性。安装前请阅读当前的 MonkeyCode 部署文档并检查开源仓库。
如果文档提供了远程安装脚本，请在以提升权限运行前审阅其内容，并在非生产环境中测试。记录试点所用的确切版本、配置、模型路径和回滚流程。