自托管 AI 编程代理 — 完整指南

只有不止桌面界面运行在你的硬件上时，AI 编程代理才是真正的自托管。要让代码留在你的环境中，应用程序、模型推理、嵌入、日志、工具和仓库都必须留在你的边界之内。安全部署应从隔离的测试仓库、非管理员沙箱、受限的出站连接、大小合适的本地模型，以及对每次重要写入的人为批准开始。

人们称为“自托管”的四种部署状态

1. 搭配托管模型的本地应用程序

代理界面和工具在你的计算机上运行，但选定的代码和提示会传输给 API 提供商。这是本地执行，而不是完全本地推理。

2. 带有私有端点的自托管应用程序

你的团队运营应用程序，并将其连接到 VPC、私有云或本地部署网关中的模型端点。数据路径可以受到严格控制，但它仍取决于端点的托管和日志设计。

3. 完全本地推理

应用程序、模型权重、嵌入、日志和工具均保留在自有硬件上。只有此状态才足以声称“代码不会离开环境”，而且还必须检查遥测、崩溃报告、包管理器、连接器和更新服务。

4. 气隙部署

不存在网络路径。镜像、软件包、模型、漏洞数据和更新均通过经批准的离线流程进入。具有活动网络连接的本地模型并非气隙部署。

参考架构

Developer
   ↓
Eigent / coding-agent harness
   ↓
Policy and approval gate
   ↓
Sandboxed repository tools ── Git, tests, linters, scanners
   ↓
Private model endpoint ── local logs and evaluation store

Eigent 的应用程序仓库采用 Apache-2.0 许可证。其源代码快速入门可能连接到 Eigent cloud，而仓库将独立用户引向另一条 Local Deployment 路径（Eigent 仓库）。如果目标是数据隔离，请使用并验证独立路径。

其他框架可能更适合不同工作流。OpenHands 提供采用 MIT 许可证的核心，支持 Docker、VM、本地和云端后端（OpenHands 仓库）。Cline 提供采用 Apache-2.0 许可证且具有批准机制的 IDE/CLI 代理（Cline 仓库）。Aider 提供采用 Apache-2.0 许可证、以 Git 为原生的终端循环（Aider 仓库）。

开源 AI 编程代理比较按界面、维护状态、部署模式和批准设计区分这些框架。

选择 AI 编程代理框架

不要仅凭界面选择。请验证工具如何限定文件范围、执行命令、存储提示、发送遥测、管理密钥和记录工具调用。

根据工作负载确定硬件规模，而不是相信虚假的最低配置

不存在诚实通用的“8 GB 足够”规则。硬件取决于模型工件、量化、上下文长度、并发代理、仓库索引和所需延迟。

Ollama 支持 NVIDIA GPU、Apple Metal 和实验性的 Vulkan 路径。其调度器会检查可用 VRAM，进程视图会显示模型位于 GPU、CPU 还是分割配置上（Ollama GPU 文档、Ollama 常见问题）。面向团队服务时，vLLM 是生产导向的选项，但加速器和镜像支持会改变；请使用最新的 vLLM 安装文档。

开放权重并不保证可在笔记本电脑上部署。Kimi K2 的官方模型卡列出了一万亿总参数，说明可下载模型仍可能需要大量基础设施（Kimi K2 模型卡）。

沙箱优先的部署程序

1. 安装前先做威胁建模

对源代码、密钥、客户数据、构建工件和日志进行分类。列出谁可以启动任务、代理可以采取哪些操作，以及哪些失败不可接受。

NIST SP 800-218A 扩展了面向生成式 AI 的安全软件开发指导，其对象是 AI 系统的生产者和采购者（NIST）。将其用作治理参考，而不是把它当作工具或部署“符合 NIST”的证明。

2. 创建隔离的运行环境

在容器或 VM 中，以专用的非管理员身份运行代理。拒绝其访问主目录、SSH 密钥、云凭据、浏览器配置文件、密码管理器和生产挂载点。

OpenHands 明确警告，无沙箱的本地代理拥有完整的文件系统访问权（OpenHands 仓库）。从概念上说，这一风险适用于任何拥有 shell 权限的编程代理。

3. 克隆合成测试仓库

使用不含客户数据或密钥的代码。仅挂载该目录。在挂载范围外添加金丝雀文件，并验证代理无法读取它们。

4. 部署独立应用程序路径

遵循其官方仓库所引用的当前 Eigent Local Deployment 文档，而不是可连接云端的快速入门（Eigent 仓库）。记录所用的确切提交、镜像、依赖项和配置。

5. 连接一个本地模型

选择适合实测硬件和任务的模型。确认进程部署、延迟、上下文处理和输出质量。将托管端点视为非本地的质量基线，并明确标注。

6. 限制网络出站连接

阻止出站流量，然后观察哪些功能失败。检查 DNS、更新检查、遥测、崩溃报告、包管理器、浏览器工具、MCP 服务器和模型下载。记录每个例外。

7. 创建范围受限的工具

从仓库读／写权限以及构建、测试、lint 和格式化命令的允许列表开始。拒绝部署、身份更改、云管理、任意软件包安装和外部消息传递。

8. 添加批准关卡

文件写入、命令执行、依赖项、网络使用以及仓库外的任何操作都应要求批准。即使模型强行要求，确定性策略也应阻止被禁止的操作。

9. 运行评估集

对每个模型和框架使用相同任务：修复错误、多文件重构、创建测试、更新依赖项、解释代码，以及拒绝修改范围外文件。评估正确性、测试通过率、审查时间、尝试违反边界的次数、延迟和成本。

10. 通过代理引入密钥

只有在合成评估通过后，代理才应获得范围狭窄、期限短的凭据。将密钥置于提示和日志之外。优先使用只授予一次操作而非可重复使用管理员令牌的代理。

代理式编程特有的安全风险

一份 2026 年安全分析强调了间接提示注入、混淆代理人行为，以及长时间运行的代理系统中的级联故障，并建议对高后果操作采取沙箱和确定性控制（研究论文）。编程代理通过议题、README 文件、注释、依赖项元数据、网页和工具输出暴露于这些风险。

控制措施应包括：

• 为仓库和网页文本添加不可信内容标签；
• 严格分离读取指令和授予权限；
• 查询、行、时间和输出限制；
• 允许列表式软件包注册表和依赖项审查；
• 提示、工具调用、差异和批准的不可变日志；
• 合并、发布或部署前的人工审查；
• 通过 Git 和可复现环境回滚。

自托管减少了一个外部数据边界，但让你的团队负责修补、运行时安全、密钥管理、监控和事件响应。

将部署扩展至气隙环境

气隙代理需要的不止本地推理复选框。

1. 镜像经过批准的容器镜像、软件包、模型工件和漏洞数据。
2. 离线导入前验证哈希和签名。
3. 维护清单和软件物料清单。
4. 禁用自动更新、遥测以及假定互联网可用的连接器。
5. 提供离线软件包和模型注册表。
6. 为补丁和报告定义经签名的导出路径。
7. 安排离线安全更新和紧急撤销程序。
8. 测试环境无法通过 DNS、代理、管理接口或模型工具形成任何路由。

气隙会增加更新和运营负担。它们不会消除内部人员风险、恶意依赖项、不安全的导入文档或模型错误。

合规与证据

没有任何自托管编程代理能让团队自动符合 GDPR、HIPAA、SOC 2、ISO 27001、出口管制或合同保密义务。合规取决于部署、人员、政策、合同和证据。

记录模型和数据集许可证、SBOM、访问策略、批准矩阵、日志保留、备份、灾难恢复、漏洞响应和回滚。将提示和工具日志视为可能敏感，因为它们可能含有源代码片段和密钥。

何时托管编程代理更好

当团队无法运营模型基础设施、需要成熟的远程环境、重视供应商支持，或者可以合法地向提供商发送所需上下文时，请使用托管代理。治理良好的托管服务可能比被忽视的自托管部署更安全。

当数据边界、源代码检查、模型选择、离线运行或自定义策略足以证明工程和安全所有权的合理性时，请选择自托管。

管理 AI 编程代理边界，而不仅是模型

Eigent 可以为私有编程工作流提供可检查的编排层，但沙箱、模型运行时、权限、日志和更新流程决定其是否真正自托管。先在合成仓库中理解大型代码库，只有在控制措施可靠后才扩大范围。下载 Eigent以开始隔离评估。