AI Harness 企业部署模式决策：每人独立 vs 集中部署
企业级如何抉择？你强大你就自研，但现实很骨感~
一、结论先行
推荐方案：控制平面集中 + 执行平面按人独立部署的混合架构。
┌─────────────────────────────────────────────────────────┐
│ 企业集中控制平面（唯一真相源） │
│ │
│ 身份注册 │ 策略引擎 │ 审计中心 │ MCP 目录 │
│ (SPIFFE) │ (OPA) │ (SIEM) │ (私有 Registry) │
└──────────┬──────────────┬──────────────┬────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────┐
│ 按人独立的执行平面 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 开发者 A │ │ 开发者 B │ │ 开发者 C │ │
│ │ Docker │ │ Docker │ │ Docker │ │
│ │ Sandbox │ │ Sandbox │ │ Sandbox │ │
│ │ + 个人凭证│ │ + 个人凭证│ │ + 个人凭证│ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ 隔离保证: 一人一沙箱，爆炸半径 = 1 人 │
│ 策略执行: 从集中控制平面拉取，本地强制执行 │
│ 审计上报: 全量日志推送集中 SIEM │
└─────────────────────────────────────────────────────────┘
一句话总结：安全策略的制定、审计、身份管理必须集中（否则一致性无从保证）；Agent 的执行必须在按人隔离的沙箱中（否则爆炸半径不可控）。两端缺一不可。
二、两种模式的本质对比
2.1 纯按人独立部署
每个开发者桌面 / 个人开发机
├── 独立的 Claude Code / OpenCode / Hermes 实例
├── 独立的 Docker Sandbox
├── 独立的凭证（个人 OAuth Token）
├── 独立的安全配置（可能各不相同）
└── 独立的审计日志（或根本没有）
2.2 纯集中部署
企业 AI 编码平台（共享服务）
├── 统一的 Harness 集群（多租户共享）
├── 统一的 Sandbox Pool（容器调度）
├── 共享凭证池（按需分配）
├── 统一安全策略（OPA/Gatekeeper）
└── 统一审计日志（SIEM）
2.3 关键维度对比
| 维度 | 每人独立部署 | 集中部署 | 混合架构 |
|---|---|---|---|
| 爆炸半径 | ⭐⭐⭐⭐⭐ 限于 1 人 | ⭐ 共享基础设施被攻破 = 全员沦陷 | ⭐⭐⭐⭐ 执行隔离 + 控制面有额外风险 |
| 安全策略一致性 | ⭐ 99% 开发者不改默认配置 | ⭐⭐⭐⭐⭐ 统一强制 | ⭐⭐⭐⭐ 策略集中下发 |
| 凭证安全 | ⭐⭐ 个人 Token 常驻本地 | ⭐⭐⭐ 统一轮换但共享池泄露风险 | ⭐⭐⭐⭐ 个人凭证 + 统一轮换策略 |
| 审计完备性 | ⭐ 取决于个人是否开启 | ⭐⭐⭐⭐⭐ 全量集中 | ⭐⭐⭐⭐⭐ 集中收集 |
| 合规达标 | ⭐ 无法证明一致性 | ⭐⭐⭐⭐ 可审计可证明 | ⭐⭐⭐⭐⭐ 兼顾隔离与合规 |
| 成本 | ⭐⭐⭐ 个人机器算力 | ⭐⭐ GPU 资源池昂贵 | ⭐⭐⭐ 控制面集中成本低，执行面利旧 |
| 运维复杂度 | ⭐⭐⭐⭐⭐ 零运维 | ⭐⭐ 需专职团队 | ⭐⭐⭐ 需小团队维护控制面 |
| 开发者体验 | ⭐⭐⭐⭐ 灵活自主 | ⭐⭐ 排队等资源/响应慢 | ⭐⭐⭐⭐ 本地执行，体验不受影响 |
| 离线/远程场景 | ⭐⭐⭐⭐ 本地即可工作 | ⭐ VPN 依赖 | ⭐⭐⭐ 执行面本地，控制面断线可降级 |
| 模型数据外泄风险 | ⭐⭐ 本地模型可用 | ⭐⭐⭐⭐ 集中在可信环境 | ⭐⭐⭐ 取决于执行面模型选择 |
三、为什么纯集中部署在企业 AI Harness 场景中是危险的
3.1 多租户 Agent 共享基础设施的不可接受风险
集中部署最致命的假设是：可以在同一个基础设施上安全地运行多个开发者的 AI Agent。2026 年的安全事件证明这个假设不成立。
集中部署场景下的攻击链：
步骤 1: 开发者 A 的 Agent 在处理恶意 Issue 时被 Prompt 注入
│
步骤 2: Agent 被诱导调用 MCP Server（共享基础设施上运行）
│
步骤 3: MCP Server 进程逃逸（利用 TrustFall 类漏洞）
│
步骤 4: 攻击者获得容器级别的访问
│
步骤 5: 通过共享卷/共享网络/共享凭证池横向移动
│
步骤 6: 开发者 B、C、D... 的 Agent 会话全部被挟持
│
结果: 一个 Prompt 注入 = 整个研发团队的 GitHub/CI/AWS 全部沦陷
这不是假设。Shai-Hulud 攻击证明了单个 Agent 被控可以导致全组织供应链污染；AWS Kiro 事件证明了单个 Agent 可以删除整个生产环境。在两个事件中，如果 Agent 部署是多租户共享的，爆炸半径将是指数级的。
3.2 Agent 不适用传统"多租户 SaaS"安全模型
传统多租户 SaaS 安全的基石是：
- 明确的 API 边界（请求/响应）
- 可预测的输入输出 schema
- 租户间数据隔离（数据库行级安全）
AI Agent 打破了这三个基石：
- Agent 调用的是 Shell、文件系统、Git、数据库客户端——不是 API
- Agent 的输出是动态生成的代码和命令——无法 schema 校验
- Agent 操作的是共享的 Build Cache、共享的 Docker Registry、共享的 Git 仓库——天然跨租户
3.3 纯集中模式何时可以采用
仅当满足以下全部条件时：
- [ ] 所有 Agent 运行在独立 VM 中（非容器共享内核）
- [ ] 每个 VM 有独立的网络命名空间和防火墙规则
- [ ] 所有 Agent 操作限定在 per-user 的 Git Fork 工作流内
- [ ] 有硬件的、不可绕过的网络隔离（物理 air-gap 或硬件防火墙）
- [ ] 有专职 7x24 安全运维团队
- [ ] 已通过 AIUC-1 合规认证
达到以上条件的成本通常远超"每人独立沙箱"方案。 这也是 Google、Meta 等公司在内部 AI 编码工具中采用每人独立实例而非共享平台的原因。
四、推荐架构：混合模式的详细设计
4.1 控制平面（集中）
┌─────────────────────────────────────────────────────────────┐
│ 集中控制平面 │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Agent 身份注册 │ │ 策略管理中心 │ │
│ │ │ │ │ │
│ │ - 开发者入职时 │ │ - 安全策略即代码 │ │
│ │ 自动创建 Agent │ │ - 版本化管理 │ │
│ │ 独立身份 │ │ - 下发到执行面 │ │
│ │ - SPIFFE SVID │ │ - 策略合规扫描 │ │
│ │ - 证书自动轮换 │ │ │ │
│ └────────┬────────┘ └────────┬─────────┘ │
│ │ │ │
│ ┌────────┴────────────────────┴─────────┐ │
│ │ 审计中心 (SIEM) │ │
│ │ │ │
│ │ - 全量工具调用日志 │ │
│ │ - Prompt 链溯源 │ │
│ │ - 跨 Agent 操作链分析 │ │
│ │ - 异常检测 (频率/时间/目标偏离基线) │ │
│ │ - 合规报告 (AIUC-1 / NIST AI RMF) │ │
│ └────────┬───────────────────────────────┘ │
│ │ │
│ ┌────────┴───────────────────────────────┐ │
│ │ MCP 私有 Registry │ │
│ │ │ │
│ │ - 签名的官方 MCP Server │ │
│ │ - 安全扫描通过的第三方 MCP │ │
│ │ - 禁止列表 (已知恶意 MCP) │ │
│ │ - 版本锁定 + 升级审批 │ │
│ └──────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ 全局 Kill Switch │ │
│ │ │ │
│ │ - 一键吊销所有 Agent 身份 │ │
│ │ - 按团队/项目/人粒度吊销 │ │
│ │ - 触发条件: 安全事件确认 / 离职 / 异常 │ │
│ └──────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
4.2 执行平面（按人独立）
每个开发者机器上的标准部署单元：
┌─────────────────────────────────────────────┐
│ 开发者: zhangjinglin │
│ Agent 身份: spiffe://enterprise.com/agent/ │
│ developer/zhangjinglin │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ Docker Sandbox │ │
│ │ │ │
│ │ ┌─────────────────────────────────┐ │ │
│ │ │ Harness (Claude Code / Hermes) │ │ │
│ │ │ │ │ │
│ │ │ - 从控制面拉取最新安全策略 │ │ │
│ │ │ - 使用个人 Agent 身份 (SVID) │ │ │
│ │ │ - 本地模型或远程 API (隔离网络) │ │ │
│ │ │ - 工具调用经本地 Gateway 拦截 │ │ │
│ │ │ │ │ │
│ │ └─────────────┬───────────────────┘ │ │
│ │ │ │ │
│ │ ┌─────────────┴───────────────────┐ │ │
│ │ │ 本地 Tool Gateway │ │ │
│ │ │ │ │ │
│ │ │ - 强制执行集中下发的策略 │ │ │
│ │ │ - 只允许 MCP Registry 签名的工具│ │ │
│ │ │ - 实时上报审计日志到 SIEM │ │ │
│ │ │ - 权限校验 + 熔断 │ │ │
│ │ └─────────────────────────────────┘ │ │
│ │ │ │
│ │ 挂载: │ │
│ │ - /workspace → ~/projects/{project} │ │
│ │ - /tokens → 短期凭证 (只读, tmpfs) │ │
│ │ - 禁止挂载: ~/.ssh, ~/.aws, ~/.kube │ │
│ └──────────────────────────────────────┘ │
│ │
│ 安全基线（标准镜像预置）: │
│ - Docker: privileged=false, cap_drop=ALL │
│ - seccomp: 禁止 mount/ptrace/reboot │
│ - AppArmor: 文件路径白名单 │
│ - 网络: 仅允许白名单域名 │
│ - 凭证: 最长生命周期 4h, 任务结束即回收 │
└─────────────────────────────────────────────┘
4.3 关键设计决策
决策 1: 策略如何从控制面下发到执行面
不采用: Agent 启动时从控制面实时查询策略（控制面宕机 = 全部 Agent 不可用）
采用: Agent 启动时从控制面拉取策略快照并本地缓存
- 策略快照签名校验（防篡改）
- 缓存有效期 24h（超时需重拉，重拉失败则降级为最严格策略）
- 策略变更通过 Webhook 推送更新通知
- 控制面宕机时 Agent 使用缓存策略继续工作（降级而非阻断）
决策 2: 审计日志上报的可靠性
不采用: 同步上报（影响 Agent 响应速度，网络波动即丢日志）
采用: 本地缓冲 + 异步批量上报
- 日志先写本地 SQLite 缓冲（加密存储）
- 每 30s 或积压 100 条触发批量上报
- 上报失败时本地保留，最多缓存 24h
- 本地缓冲轮转加密，防止攻击者篡改审计记录
决策 3: MCP Server 的获取方式
不采用: Agent 启动时从互联网动态拉取 MCP Server（供应链风险）
采用: 按人沙箱镜像预置经过安全扫描的 MCP Server
- MCP Server 版本在控制面 Registry 中锁定
- 新增/升级 MCP Server 需提交变更请求，经安全扫描后更新镜像
- 禁止 Agent 自行安装或更新 MCP Server
- 紧急 MCP 漏洞时控制面可推送黑名单，执行面即时禁用
4.4 部署架构总览
┌──────────────────────────┐
│ 企业 IdP │
│ (Okta / Azure AD) │
│ │
│ 人类身份 + Agent 身份 │
│ 统一管理，独立颁发 │
└────────────┬─────────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 控制平面 │ │ 审计中心 │ │ MCP Registry │
│ (集中) │ │ (集中) │ │ (集中) │
└────────┬────────┘ └────────┬────────┘ └────────┬────────┘
│ │ │
└──────────────────┼───────────────────┘
│
┌─────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 开发者 A │ │ 开发者 B │ │ 开发者 C │
│ │ │ │ │ │
│ Docker 沙箱 │ │ Docker 沙箱 │ │ Docker 沙箱 │
│ Agent 身份 A │ │ Agent 身份 B │ │ Agent 身份 C │
│ 个人凭证 │ │ 个人凭证 │ │ 个人凭证 │
│ 本地日志缓冲 │ │ 本地日志缓冲 │ │ 本地日志缓冲 │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
└────────────────────┼────────────────────┘
│
审计日志上报
策略拉取/更新
身份证书轮换
五、分场景部署模式推荐
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 10 人以下创业团队 | 每人独立 + 轻量控制面 | 集中控制面用 GitHub Actions + 开源工具即可，不需要专职运维 |
| 50-200 人研发团队 | 混合架构（本文方案） | 这是混合架构的甜蜜点——控制面值得投入，执行面隔离必要 |
| 500+ 人大型企业 | 混合 + 按团队分组 | 控制面做租户隔离（按业务线/部门），执行面保持按人隔离 |
| 合规强需求（金融/医疗） | 混合 + 强化审计 | 控制面增加合规报告自动化，执行面增加额外的数据脱敏层 |
| 完全云开发环境（无本地机器） | 每人独立 VM | 用 per-user VM 替代 per-user Docker，保持隔离级别不降级 |
| 外部承包商/外包团队 | 每人独立 + 网络隔离 | 额外限制外网访问 + 只读工作区 + 全量审批模式 |
六、成本估算参考
以 100 人研发团队为例：
| 项目 | 纯集中部署 | 混合架构 |
|---|---|---|
| 基础设施 | GPU 集群 (4×A100) ≈ $30K/月 | 利旧开发者机器 ≈ $0 |
| 控制面服务 | 包含在基础设施中 | 2×云服务器 + DB ≈ $500/月 |
| 带宽/网络 | 高（所有 Agent 流量经中心） | 低（本地执行，只上报日志） |
| 运维人力 | 2-3 人专职 ≈ $25K/月 | 0.5 人兼职 ≈ $5K/月 |
| 许可证/API | 集中采购可能有折扣 | 个人采购，但可统一谈判 |
| 安全合规审计 | 集中审计较简单 ≈ $3K/月 | 需验证执行面一致性 ≈ $5K/月 |
| 月总估算 | ~$58K | ~$10K |
| 爆炸半径（安全成本） | 全员凭证泄露风险（不可量化但致命） | 单人凭证泄露（可控） |
纯集中部署的"安全成本"虽然在表格里难以量化，但 AWS Kiro 事件 13 小时宕机的损失和 Shai-Hulud 供应链攻击的品牌影响，一次就足以覆盖混合架构多年的额外投入。
七、实施路线图
Phase 1: 个人沙箱标准化（2-3 周）
- [ ] 构建标准 Docker 沙箱镜像（包含安全基线：seccomp + AppArmor + cap_drop=ALL）
- [ ] 为每个开发者部署独立沙箱
- [ ] 配置 MCP 工具白名单（只开放必要的读操作）
- [ ] 启用本地工具审批（危险操作需确认）
Phase 2: 控制面 MVP（3-4 周）
- [ ] 部署 SPIFFE/SPIRE 作为 Agent 身份服务
- [ ] 为每个开发者创建 Agent 独立身份
- [ ] 部署策略引擎（OPA），定义读写权限分离策略
- [ ] 部署审计日志收集服务（本地缓冲 + 集中存储）
Phase 3: 策略与治理（2-3 周）
- [ ] 编写安全策略即代码（禁止访问 .env/credentials/prod 路径等）
- [ ] 部署 MCP 私有 Registry（签名的官方 MCP）
- [ ] 配置全局 Kill Switch
- [ ] 建立策略变更审批流程
Phase 4: 自动化与合规（持续）
- [ ] SIEM 集成 + 异常检测规则
- [ ] 合规报告自动生成（AIUC-1 / NIST AI RMF）
- [ ] 定期安全演练（Prompt 注入攻防、沙箱逃逸测试）
- [ ] 策略合规自动扫描（检测开发者是否绕过安全配置）
八、核心结论
纯集中部署在 AI Harness 场景下是危险的选择。AI Agent 的多租户隔离问题尚未解决，一个 Prompt 注入即可导致全团队沦陷。
纯按人独立部署在合规上是不可接受的。当每个开发者各自配置安全策略时，99% 的人不会修改默认配置（2026 年调查：98.9% 的
.claude/settings.json零 deny 规则）。混合架构是当前唯一正确的答案。控制平面集中（身份/策略/审计/Registry/Kill Switch），执行平面按人隔离（Docker Sandbox + 个人凭证 + 本地执行）。
控制平面的设计哲学是"降级而非阻断"。控制面宕机时，Agent 使用缓存策略继续工作，不能因为安全基础设施故障而瘫痪整个研发团队。
Agent 身份是整个架构的基石。每个开发者的 Agent 必须有独立的、可加密验证的、可随时吊销的身份。这是混合架构能够成立的前提。没有这一步，集中和独立的争论毫无意义——因为你根本无法区分谁的操作是谁的。
Sources: AIUC-1 Q2 2026 (A003.3/A003.4), Adversa AI TrustFall Research, Shai-Hulud SAP CAP Attack Post-Mortem, AWS Kiro Incident Analysis, Forbes Tech Council - Agentic Control Plane, Apono Agent Privilege Guard, OWASP ASI 2026, SPIFFE/SPIRE Documentation
前端·博客