Codex 企业级落地（下）：4 个生产场景的真实落地 | Leslie Zhang

Codex 企业级落地（下）：4 个生产场景的真实落地

本系列三篇：

• 21《把 AI 关进笼子里：Codex Sandbox 全景拆解》单机 sandbox 五层防御
• 22《Codex 企业级落地（上）：从单机 sandbox 到 K8s 生产架构》K8s 生产架构
• 23（本篇）4 个生产场景的真实落地

引言：从架构到产品的最后一公里

上一篇我们讲了怎么把 Codex 装进 K8s：架构很优雅，gVisor + OPA + Cilium + Falco 一应俱全，但你可能心里有个挥之不去的疑问：

这玩意搭起来给谁用？

公司里跑了一个企业级 AI agent 平台，不是用来当摆设的。它得有具体场景、具体用户、具体能解决的问题，最好能直接换算成钱（省的或赚的）。否则就是一个 SRE 团队自嗨的玩具，半年后被砍掉。

这一篇讲 4 个我认为最值得起步的企业级场景，每个都满足三个判定标准：

1. 痛点真实 —— 用户不是被 AI 噱头吸引，而是有一个具体的工作日常被解决
2. 风险可控 —— Codex sandbox 哲学能直接覆盖，不需要额外的安全设计
3. 价值可量化 —— 能算出每月省多少工时 / 多少 incident / 多少美元

四个场景：

场景	用户	解决的问题	落地难度
1. 内部 Copilot 替代	全公司工程师	GitHub Copilot 数据出海合规问题 + 接不上内部系统	中
2. CI/CD AI 修复机器人	平台 / DevOps 团队	PR 提交后红的测试人工修复成本	中-高
3. 数据科学 / 内部查询平台	业务 / 产品 / 运营	不会 SQL 的人天天找数据团队，数据团队被烦疯	高
4. 多 Agent 并发	复杂工程任务	单 agent 解不了的多步骤任务	高（前沿）

每个场景都给完整的架构、关键代码、上线路径、踩坑经验。读完你能直接拿去和老板、安全部门、数据团队过方案。

---

场景 1：内部 Copilot 替代

痛点：Copilot 用不了的 5 个理由

GitHub Copilot 是好东西，但很多公司用不了：

1. 合规过不了：代码片段会发到微软的服务器，敏感行业（金融、医疗、政府）法务直接否
2. 接不上内网：Copilot 不知道公司内部 SDK、内部 API、内部 RPC 协议，写出来的代码全是开源风
3. 不能用内部知识库：你公司 Confluence 上沉淀了几千页架构文档，Copilot 看不到
4. 跨服务理解弱：跨 repo / 跨语言 / 跨服务的重构，Copilot 给不出方案
5. 预算分摊难：Copilot 按人头收钱，但谁该掏钱、不同团队怎么算账，IT 部门一头包

Codex 在 K8s 上跑一个内部 Copilot 替代品，能干净地解决这 5 个问题。

架构：把”AI 写代码”做成一个内部 SaaS

核心组件 6 个：

组件	作用	选型
VS Code 插件 / Web IDE	用户接入端，提供 inline 补全、chat、agent 模式	自研，参考 Continue.dev
Codex Backend（K8s）	真正的 AI agent 进程，跑在 sandbox pod 里	上一篇的 K8s 架构
公司 LLM Gateway	统一接 GPT / Claude / 内部模型，做配额、审计、路由	自研或用 LiteLLM / Portkey
GitLab MCP Server	让 AI 能查代码、看 PR、发 issue	基于 MCP 协议自研
Confluence MCP Server	让 AI 能查内部架构文档、API 规范	同上
Embedding 服务	公司代码 / 文档的向量化检索（RAG）	bge-m3 / 公司自研

关键设计 1：MCP Server 的最小权限设计

Codex 通过 MCP（Model Context Protocol，Anthropic 提出，目前事实上的 LLM-工具通信标准）协议调用工具。每个内部服务都包装成一个 MCP server，AI 看到的是一组工具，不是直接看到 GitLab API。

举例：GitLab MCP Server 暴露的工具集要刻意收窄。给 AI 的不该是 “你有 GitLab 全部 API”，而是”你能干这 6 件事”：

# gitlab-mcp-server config
tools:
  - name: search_code
    description: 在公司 GitLab 仓库里搜代码
    permissions: [read]
  - name: read_file
    description: 读某个 repo 的某个文件
    permissions: [read]
  - name: list_merge_requests
    description: 列某个 repo 的 MR
    permissions: [read]
  - name: get_merge_request_diff
    description: 看 MR diff
    permissions: [read]
  - name: comment_on_merge_request
    description: 在 MR 上加评论
    permissions: [write]      # ← 写权限：限制到只能加评论
  - name: create_branch
    description: 创建分支
    permissions: [write]
  # 没有 delete_branch / force_push / delete_repo

核心原则：MCP server 是 AI 看世界的窗口，窗口大小由你定。你给 AI 越窄的工具集，可控性越强。AI 不需要的权限绝不暴露——即使将来想加，加之前再说。

关键设计 2：Embedding + RAG，让 AI 真的”懂”你公司代码

光接 GitLab API 不够。AI 想理解”我们公司的支付系统怎么设计”，单看几个文件名不行，得能在几十万行代码、几千页文档里语义检索。

┌──────────────────────────────────┐
│   公司代码 (GitLab) + 文档 (Confluence)
└────────────────┬─────────────────┘
                 │ webhook on push/edit
                 ▼
┌──────────────────────────────────┐
│   Indexing Pipeline               │
│   - 切片（按函数 / 按段落）       │
│   - Embedding (bge-m3 / OpenAI)   │
│   - 存向量库 (Qdrant / Milvus)    │
└────────────────┬─────────────────┘
                 │
┌────────────────▼─────────────────┐
│   Codex Sandbox Pod               │
│   ↓ AI 提问 "支付鉴权怎么做"      │
│   ↓ MCP 调 search_knowledge_base  │
│   ↓ MCP server 查向量库 → top-K   │
│   ↓ 注入 prompt，AI 用 context 回答 │
└──────────────────────────────────┘

生产建议：embedding 一定要走增量索引（webhook on push/edit），不要 nightly 全量。代码改了 30 秒后向量库要更新，用户体验才会接近 ChatGPT。

关键设计 3：LLM Gateway 的三大职责

Codex sandbox pod 不直接调外部 LLM API，永远走公司 LLM Gateway。这一层做三件事：

Codex Pod ──HTTP─→ LLM Gateway ──HTTP─→ OpenAI / Anthropic / 内部模型
                       │
                       ├── 1. 鉴权 + 配额
                       │     检查 namespace 当日 token 预算
                       │     超了就 429
                       │
                       ├── 2. 路由 + Failover
                       │     主用 GPT-4o，挂了切 Claude Sonnet
                       │     便宜任务用 Haiku，复杂任务用 Opus
                       │
                       └── 3. 审计 + 脱敏
                             记录每次调用：用户 / 模型 / 输入输出 / 成本
                             敏感字段（手机号、身份证）出门前正则脱敏

不接 LLM Gateway，直接让每个 Codex pod 拿着 API key 自己出门，等于把 300 个工程师的 token 配额、failover、审计、脱敏全部分散管理——这是不可维护的。LLM Gateway 是企业级 AI 的 control plane，必须从第一天就有。

上线路径与价值估算

阶段	周期	用户	月成本（300 工程师）	月省工时（保守估计）
MVP	2 周	5 内测	$200	50h
Beta	1 月	30 早期	$1,500	300h
生产	3 月	全公司 300	$15,000	4500h

ROI 估算（保守版）：假设每位活跃工程师每月省 15 小时（约一周 4 小时左右），按公司全成本 $50/h 计算，300 人月省 22.5 万美元，对应月成本 $15K 的 ROI 约 15x。即使把”每人每月省 15 小时”砍半到 7.5 小时，ROI 仍有 7.5x。这套数字老板很难拒。

关键假设：(1) 工程师真活跃使用而非偶尔点开（这一点需要内推 + champion 来保障）；(2) “省的工时”按公司全成本而非工资计算（标准 BizCase 算法）；(3) 不计入 AI 写错代码的隐性成本（所以叫”保守版”）。

实战坑

坑 1：embedding 不更新 = 用户立刻流失。代码改了 AI 不知道，用户用一周就不再信任。webhook 增量索引必须在 MVP 阶段就有。

坑 2：LLM Gateway 的 token 计费要按 namespace 而非按用户。按用户算账户操作复杂、用户跨团队时数据混乱；按 namespace 一目了然，CFO 看着舒服。

坑 3：不要让 AI 直接发 MR。AI 在 sandbox 里生成 patch、人工审核后再走正常 MR 流程。直接发会让 GitLab Activity 被 AI 噪音淹没，也容易出大事。

---

场景 2：CI/CD AI 修复机器人

痛点：每个工程师每周浪费在 CI 红灯上的 5 小时

工程师典型的一天：

提了个 PR → CI 跑了 8 分钟 → 测试红了 → 一看是个跨服务的依赖更新引起的 → 改完 push → CI 又跑 8 分钟 → 又红，因为另一个服务的 mock 也要更新 → 改完 push → CI 跑 8 分钟 → 终于绿了 → 已经过去 1 小时了

CI 红灯修复的特征：

• 大部分是机械性的（lint 错、import 缺、mock 没更新、版本号没改）
• 修复路径单一（看 CI log → 改某个文件 → push）
• 占用工程师高质量时间（思维被打断比修复本身更贵）

这个工作流完全适合 AI 替代。AI 在 sandbox 里跑一遍测试、看错误、改代码、再跑一遍，完全不需要人参与。

架构：从 GitLab webhook 到自动 MR

完整工作流：

1. 用户 push 代码到 feature 分支
        │
        ▼
2. GitLab CI 跑测试 → 失败 → webhook 触发
        │
        ▼
3. AI Bot 接收 webhook，创建一个 K8s Job：
   - kind: AgentSession
   - mode: ci-fix
   - inputs: { repo, branch, failing_job_id }
        │
        ▼
4. K8s 创建一个 Sandbox Pod (gVisor + restricted)：
   - git clone 用户的 PR 分支
   - 拉 CI 失败的 log
   - 跑 codex exec 让 AI 分析 + 修复
   - codex 在 sandbox 里跑 npm test / cargo test 验证
   - 通过后生成 patch
        │
        ▼
5. AI Bot 把 patch 提成新 MR：
   - 标题: "AI fix: {original PR title}"
   - 描述: 引用 CI log + AI 推理过程
   - reviewer: 原 PR author
        │
        ▼
6. 原作者人工审核 → merge

关键设计 1：CI 失败的”AI 可解性”分类

不是所有 CI 失败都该让 AI 来修。第一步要做的是分类器，区分哪些适合 AI、哪些不适合。

CI 失败类别	AI 可解性	例子
Lint / 格式错误	⭐⭐⭐⭐⭐ 极高	eslint / black / clippy 报错
Type 错误	⭐⭐⭐⭐ 高	mypy / tsc 报错，缺 type annotation
Mock / 依赖未更新	⭐⭐⭐⭐ 高	API schema 变了，mock 没改
Import / module not found	⭐⭐⭐⭐⭐ 极高	重构后的 import 路径错
单元测试断言失败	⭐⭐⭐ 中	业务逻辑改了但测试没跟
集成测试失败	⭐ 低	跨服务、依赖外部状态
环境 / 资源问题	⛔ 不可解	OOM、外部服务挂了

只对前 4-5 类自动触发 AI fix。后两类直接通知人。

实现是一个简单的 webhook handler：

# ci-bot/classifier.py
def classify_failure(ci_log: str) -> str:
    if "ESLint" in ci_log or "black" in ci_log or "clippy" in ci_log:
        return "lint"
    if "TS2304" in ci_log or "mypy" in ci_log:
        return "type"
    if "ModuleNotFoundError" in ci_log or "Cannot find module" in ci_log:
        return "import"
    if "ConnectionError" in ci_log or "OOMKilled" in ci_log:
        return "env"
    return "unknown"

AI_FIXABLE = {"lint", "type", "import", "mock"}

关键设计 2：让 AI 在 sandbox 里”实跑”

AI 改完代码不能直接相信，必须在 sandbox 里真的跑一遍测试。这是 CI fix bot 区别于普通 LLM 写代码的核心 —— 反馈循环（feedback loop）在 sandbox 内闭环。

# Codex 启动参数（CI fix mode）
codex exec --mode ci-fix \
  --repo /workspace \
  --max-iterations 5 \
  --tool-timeout 300s \
  --instruction "$(cat <<EOF
请修复下面的 CI 失败：

CI Log:
$(cat /workspace/ci.log)

Failed Test:
$(cat /workspace/failing_test.txt)

策略：
1. 分析根因
2. 改代码
3. 在 sandbox 里跑 \`npm test\` (或 \`cargo test\`) 验证
4. 如果还失败，回到第 1 步，最多 5 轮
EOF
)"

--max-iterations 5 是上限。超过 5 轮还修不好，说明问题超出 AI 能力范围，bot 通知人接手。这个数字不要太大——AI 死循环烧 token 是 CI fix bot 最常见的事故。

关键设计 3：永远是新分支 + 新 MR，不直接改用户分支

这条是铁律：

❌ 不要：AI 直接 commit 到用户的 feature 分支
✅ 要：AI 在新分支（如 ai-fix/{original-branch}）上 commit，提一个新 MR 让用户合

理由：

• AI 改错了，用户能直接 close MR，原分支不受影响
• 用户能 review AI 改了什么再决定是否合
• AI 行为有完整审计（每个 MR 一个审计单元）

上线路径

阶段	周期	范围	月修复 PR 数
MVP	2 周	1 个 repo + lint 类	50
Beta	1 月	5 个 repo + lint/import/type	500
生产	3 月	全公司 + 全 AI 可解类	5000+

ROI 估算：每个被 AI 修掉的 PR 平均替工程师省 30 分钟（修复 + 等 CI 重跑 2 个 round），月修复 5000 个 PR 等于节约 2500 工时，按 $50/h 算约 12.5 万美元/月。

这是上限值，实际要打 6 折左右（AI 修错的成本、人工 review 时间、CI 重跑的 runner 费用）。即使打折后仍有约 7.5 万/月，相对于 bot 本身月成本几千美元仍然非常划算 —— 关键是要控制好”AI 修不对就立刻停下让人接手”，否则 token 成本会反过来吃掉所有节约。

实战坑

坑 1：webhook 噪音控制。GitLab 一个仓库每天可能几百个 CI 事件，全送给 AI 会瞬间烧爆 token 预算。在 webhook 这一层就要去重 + 限频，每个 PR 最多触发 3 次 AI fix。

坑 2：AI 改不动但坚持改。AI 改 5 轮还失败，bot 必须停下并发通知，不能”再试一次”。Token 预算就是这么爆的。

坑 3：AI 改了无关代码。约束 AI 只能改 CI log 里提到的文件 + import 它们的文件，不要让它顺手”清理”其他代码。这是 prompt 工程的硬约束。

---

场景 3：数据科学 / 内部查询平台

痛点：业务同事问数据，数据团队加班加点回不完

每个互联网公司都有这个图景：

• 业务方（产品、运营、市场）：每天有几十个”帮我看一下 XXX”的需求 —— 退款率、留存、转化漏斗、AB 实验结果
• 数据团队：3 个人维护 200 张表，被业务的需求淹没，写 SQL 写到深夜
• 结果：业务等数据等三天，数据团队被烦得想离职，老板觉得数据团队效率低

让业务自己写 SQL？大部分人不会，会的也写得乱七八糟。让 AI 写？数据是公司核心资产，绝不能流到第三方 AI 服务。

Codex 在 K8s 上跑一个内部数据查询平台，让业务用自然语言问问题，AI 在 sandbox 里写 SQL/Python、跑、出结果，全过程数据不出公司。

架构：业务自然语言 → AI → Sandbox 内执行 → 结果

### 关键设计 1：数据库账号最小权限 + 行级权限

Sandbox pod 拿的数据库账号**只能 SELECT，不能 DELETE/UPDATE/INSERT/DROP**。再叠一层行级权限（**RLS**，Row Level Security，按用户身份过滤行）。下面用 PostgreSQL 举例（语义最标准、最容易理解；ClickHouse / MySQL 8.0+ 有等价机制）：

```sql
-- 1. 启用表的 RLS
ALTER TABLE salary_records ENABLE ROW LEVEL SECURITY;

-- 2. 定义策略：codex_sandbox_role 只能看到 app.user_department 设的部门
CREATE POLICY hr_data_filter ON salary_records
FOR SELECT
TO codex_sandbox_role
USING (
  department = current_setting('app.user_department', true)::text
);

-- 3. Sandbox pod 在每次连接 DB 后，按当前用户身份注入 session 变量
--    这一步由 Codex 编排层做，AI 看不到也改不了
SET app.user_department = 'sales';

效果：销售部门的同事问”我们部门的销售数据”，AI 写出来的 SQL 即使想查全公司，数据库本身在执行时只返回 department=’sales’ 的行。AI 是否守规矩根本不影响结果。安全策略落到数据库层，不依赖 AI 自律。

关键设计 2：Schema 召回 + Few-shot Examples

不要把 200 张表的 schema 全塞 prompt（token 爆炸）。用RAG召回：

1. 离线把每张表的 schema + 业务描述 + 历史好的 SQL 例子都做 embedding
2. 用户提问时，先用问题的 embedding 检索 top-5 最相关的表
3. 只把这 5 张表的 schema 塞进 prompt

# 表元数据示例
{
  "table": "orders",
  "description": "电商订单主表，按天分区",
  "columns": [
    {"name": "order_id", "type": "string", "desc": "订单号"},
    {"name": "user_id", "type": "string", "desc": "用户 ID"},
    {"name": "amount", "type": "decimal", "desc": "订单金额（元）"},
    {"name": "region", "type": "string", "desc": "地区代码：huanan/huabei/..."},
    {"name": "status", "type": "string", "desc": "状态：paid/refunded/cancelled"},
    {"name": "ds", "type": "string", "desc": "分区日期 YYYY-MM-DD"}
  ],
  "good_examples": [
    {
      "question": "上周华南订单总额",
      "sql": "SELECT SUM(amount) FROM orders WHERE region='huanan' AND ds BETWEEN '2026-04-28' AND '2026-05-04'"
    }
  ]
}

good_examples 是 few-shot learning 的关键 —— AI 看到一个好例子，下次问类似问题时模仿，准确率立刻上一个档次。第一年最好的投资就是积累这些好例子。

关键设计 3：可解释性优先于自动化

Sandbox 跑出结果后，给用户看的不是只有数字 / 图，而是完整的执行轨迹：

┌─ 你的问题 ──────────────────────────────────────┐
│ 上周华南区订单退款率同比变化怎么样？            │
├─ 我理解为 ──────────────────────────────────────┤
│ 对比 [2026-04-28 到 2026-05-04] 和              │
│ [2025-04-28 到 2025-05-04] 两段时间             │
│ 华南地区的退款率（refunded 数 / 总订单数）       │
├─ 数据源 ────────────────────────────────────────┤
│ orders 表（ClickHouse / data-warehouse）        │
├─ 我写的 SQL ────────────────────────────────────┤
│ WITH this_year AS (                             │
│   SELECT COUNT(*) FILTER (WHERE status='refund')│
│          / COUNT(*) AS rate                     │
│   FROM orders ...                               │
│ ), last_year AS (...)                           │
│ SELECT ...                                       │
├─ 结果 ──────────────────────────────────────────┤
│ 本期: 3.2%  同期: 2.8%  环比: +14%              │
│ [折线图]                                         │
├─ 我的解读 ──────────────────────────────────────┤
│ 退款率上升 14%，主要发生在 4-30 到 5-2 三天，   │
│ 可能与 [活动 X] 的退货政策变化有关。            │
└─────────────────────────────────────────────────┘

这种透明度的好处：

• 业务方学到了 SQL（半年后他们自己会写）
• 数据团队能 review（错的 SQL 能被发现并反馈到 few-shot 库）
• 建立信任（用户知道数字是怎么来的，不是 AI 瞎编）

上线路径

阶段	周期	范围	月查询次数
MVP	1 月	1 个数据域 + 数据团队内测	100
Beta	2 月	3 个数据域 + 50 业务用户	1,000
生产	6 月	全公司 / 全数据域	10,000+

把数据团队从”SQL 翻译机”解放出来，他们能去做模型 / 平台 / 分析的高价值工作。这是文化层面的胜利，不是单纯的工时节约。

实战坑

坑 1：第一版准确率会很差。表的命名不规范、业务描述模糊、schema 文档过时，AI 根本写不对 SQL。MVP 阶段最大的工作量在数据治理（梳理 schema 描述），不在 AI 工程。

坑 2：用户问的问题千奇百怪。”我老板让我看一下昨天那个事情” 这种问题 AI 解不了。需要在前端引导用户问得具体——给问题模板、给历史问题示例、不让用户自由发挥。

坑 3：Sandbox 资源管理。SQL 跑超时怎么办？把 sandbox pod 设 5 分钟硬超时，超时杀掉，告诉用户”这个查询太重了，请联系数据团队”。绝不要让 AI 死跑慢查询拖垮数据仓库。

---

场景 4：多 Agent 并发

痛点：单 agent 解不了的复杂工程任务

前面 3 个场景都是单 agent 模式 —— 一个 AI 进程负责一件事。但有些任务需要多个 agent 协作：

• “给这个新功能写完整需求文档 + 设计文档 + 代码 + 单测 + 集成测 + PR 描述”
• “调研 5 个开源方案 + 各做一个 POC + 出对比报告”
• “重构这个微服务，分别处理 4 个依赖它的下游服务的兼容性”

单个 agent 处理这种任务会出现：

• 上下文溢出（一个 task 的所有信息塞不进 200K context）
• 角色混乱（写代码时还要兼顾文档风格、PM 视角、测试 case）
• 没法并行（5 个 POC 串行做要 5 倍时间）

多 agent 模式就是把任务拆成多个子任务，每个交给一个独立的 sandbox pod 跑，agent 之间通过消息或共享存储通信。

架构：Agent 拓扑设计

典型的”开发一个新功能”任务的 agent 拓扑：

              ┌─────────────────────┐
              │   PM Agent          │
              │   - 拆需求          │
              │   - 画 spec         │
              │   - 创建 sub-tasks  │
              └──────────┬──────────┘
                         │ 创建多个子任务
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  Backend    │  │  Frontend   │  │  Database   │
│  Dev Agent  │  │  Dev Agent  │  │  Migration  │
│             │  │             │  │  Agent      │
└──────┬──────┘  └──────┬──────┘  └──────┬──────┘
       │                │                │
       └────────────────┼────────────────┘
                        ▼
              ┌─────────────────────┐
              │   Test Agent        │
              │   - 跑所有测试      │
              │   - 集成验证        │
              └──────────┬──────────┘
                         │
                         ▼
              ┌─────────────────────┐
              │   Reviewer Agent    │
              │   - 代码 review     │
              │   - 写 PR 描述      │
              └─────────────────────┘

每个 agent 都跑在独立的 sandbox pod 里：

• PM agent：能调 Jira / Confluence MCP，写权限
• Dev agents：能读全部代码，只能写自己负责的 service 目录
• Test agent：能跑测试，不能改代码
• Reviewer agent：只读 + 评论权限

关键设计 1：Agent 间通信：共享 PVC + 事件总线

K8s 里两种 agent 通信方式：

方式	适合	实现
共享 PVC	文件类产物（代码、文档、测试报告）	ReadWriteMany PVC，挂到所有 agent pod 的 /workspace
消息总线	事件 / 状态变更 / 任务调度	NATS / Redis Streams / Kafka

示例消息流：

PM Agent → publish: {topic: "task.created", task_id: T1, type: "backend", spec: ...}
Backend Dev Agent → subscribe → 拉取 → 在 PVC 写代码 → 完成 → publish: {topic: "task.completed", task_id: T1}
Test Agent → subscribe "task.completed" → 跑相关测试 → publish: {topic: "test.passed", task_id: T1}
Reviewer Agent → subscribe "test.passed" → 写 review → publish: {topic: "review.done", task_id: T1}
PM Agent → subscribe "review.done" → 标记任务完成

这种事件驱动比 polling 高效得多，agent 之间松耦合（一个挂了不影响其他）。

关键设计 2：每个 agent 一份独立 PermissionProfile

回到 Codex 的核心 —— execpolicy。多 agent 场景下，每个 agent 有不同的 PermissionProfile，用 Codex 的 Starlark 语法写规则文件：

# pm-agent.codexpolicy
prefix_rule(pattern = ["jira"],       decision = "allow",
    justification = "PM agent 操作 Jira")
prefix_rule(pattern = ["confluence"], decision = "allow")
prefix_rule(pattern = ["codex", "create-task"], decision = "allow")
prefix_rule(pattern = ["git"],        decision = "forbidden",
    justification = "PM 不能动 git，代码归 dev agent 管")
prefix_rule(pattern = ["kubectl"],    decision = "forbidden")

# backend-dev-agent.codexpolicy
prefix_rule(pattern = ["cargo", ["build", "test", "fmt", "clippy"]], decision = "allow")
prefix_rule(pattern = ["git", "checkout", "-b"], decision = "allow")
prefix_rule(pattern = ["git", "commit"], decision = "allow")
prefix_rule(pattern = ["git", "push", "origin"], decision = "prompt",
    justification = "push 前人工确认；push 到 main 走下一条规则")
prefix_rule(pattern = ["git", "push", "--force"], decision = "forbidden")
prefix_rule(pattern = ["git", "push", "origin", "main"], decision = "forbidden",
    justification = "禁止直接 push main，必须走 MR")
prefix_rule(pattern = ["rm", "-rf"], decision = "forbidden")
prefix_rule(pattern = ["kubectl"],   decision = "forbidden")

执行时把 profile 通过环境变量注入 sandbox pod，Codex 启动时按 profile 加载 execpolicy。规则文件本身能进 git，PR 改规则要安全团队 review —— 这就把”AI 能干什么”做成了 GitOps 化、可审计的资产。

关键设计 3：人工 Approval Gate（防止 AI 跑飞）

多 agent 系统的最大风险是级联错误：PM agent 拆错任务 → 4 个 dev agent 都按错的方向写代码 → 浪费几小时几十美元 token。

在关键节点强制人工 approval：

节点	谁审批	审批什么
PM agent 出 spec 后	真人 PM	spec 是否合理
Dev agent 完成代码后	真人 senior dev	代码方向对不对
Test agent 全过后	真人 reviewer	测试覆盖够不够
Reviewer agent 出 PR 后	真人 PR reviewer	最终 merge 前看一眼

实现：每个 approval node 都是一个 K8s AgentSession 资源里的 phase，K8s controller 监听到 phase = awaiting_approval 就推消息到 Slack / Web UI，等待用户点 ✓。

# K8s CRD 状态机示例
apiVersion: codex.company.io/v1
kind: AgentSession
metadata:
  name: feature-payment-v2
spec:
  topology: "feature-development"
  task: "为支付系统新增 Apple Pay 支持"
status:
  phase: "awaiting_approval"  # ← 卡在这里等人
  current_step: "PM agent draft spec"
  approvers: ["alice@company.com"]
  approval_url: "https://codex.company.io/approve/sess-abc"

上线路径

多 agent 是前沿场景，落地难度高，建议作为”高级用户内测”项目，不要全公司推：

阶段	周期	范围	用户
实验室	2 月	内部 1-2 个团队、固定 topology	5 人
Beta	4 月	5-6 种 topology、可配置	30 人
生产	12 月+	topology 市场（用户自定义）	全公司

注意：多 agent 不是越多越好。我见过的最成功的多 agent 系统都是 2-4 个 agent，超过 5 个就开始难以管理（消息混乱、调试困难、token 爆炸）。

实战坑

坑 1：消息总线选型踩坑。早期不要用 Kafka（运维太重）。NATS / Redis Streams 起步够了，等规模真的上来再迁。

坑 2：Agent 死循环烧钱。两个 agent 互相 ping 等对方完成，谁也不完成，几小时内烧光预算。每个 agent 都要有 max_iterations 和 budget。

坑 3：可观测性是生死线。多 agent 必须有全链路追踪（OTel + traceId），出事时能立刻看到”哪个 agent 在哪一步出了什么”。没追踪的多 agent 系统等于黑箱，运维心态会崩。

---

总结：4 个场景的共性架构

把 4 个场景放在一起看，能抽出 5 条共性架构原则：

1. Codex Sandbox Pod 是统一的执行单元。无论是 Copilot 后端、CI fix bot worker、SQL runner、还是多 agent 中的 dev agent —— 底层都是同一个 sandbox pod 抽象。这种统一带来的复用价值巨大：你只用维护一套 K8s 部署、一套监控、一套审计，所有场景共享。

2. MCP 是 AI 看世界的统一接口。GitLab / Jira / Confluence / 数据库 / 内部 SDK —— 全部 MCP 化。MCP server 是权限边界，AI 看到的工具集就是它能做的全部。这种设计让你能渐进地扩展能力，每加一个 MCP server 等于给 AI 新增一项可控能力。

3. LLM Gateway 是 control plane。所有 AI 调用走统一 gateway，gateway 上做配额、路由、failover、审计。这一层是企业级 AI 的”电网”——少了它，你只是把 ChatGPT 重新发明一遍，没法治理。

4. 人工 approval 留在关键节点。完全自动化是诱人的，也是危险的。每个场景都要有”出问题时 AI 必须停下来等人”的节点：CI fix 的 max iterations、数据查询的可解释结果、多 agent 的 phase approval。好的 AI 系统不是消除人，而是把人放在最关键的决策节点。

5. 全链路追踪 + 完整审计。每一次 AI 行为都要能追溯：用户 → 模型选择 → token 消耗 → execpolicy 决策 → sandbox syscall。这不是为了复盘事故，而是为了建立用户信任。用户能查到 AI 干了什么，才敢让 AI 干更多。

---

你的下一步

如果你公司刚开始考虑做企业级 AI agent，从这 4 个场景里挑：

你的情况	推荐起步场景
有 100+ 工程师、被 Copilot 合规挡了	场景 1（内部 Copilot）—— 价值立竿见影
有完善 CI/CD、PR 红灯多	场景 2（CI fix bot）—— ROI 最快
数据团队是瓶颈、业务方天天催	场景 3（数据查询平台）—— 价值最大但最难
想做技术领先、招聘吸引力	场景 4（多 agent）—— 前沿但慎重

不要一上来想做全部 4 个。选一个，做深，做好，再推下一个。每个场景至少需要 3-6 个月才能从 MVP 走到生产，急不得。

整套系统跑起来后，你公司就拥有了一个AI-native 工程文化。这不再是”我们用了某个 AI 工具”，而是”我们用 AI 重新发明了开发流程”。这种差距，在未来 3 年会决定哪些公司能继续拿到顶级工程师，哪些只能做老旧业务。

---

本系列结束。三篇连起来读，你会有一个完整的从 sandbox 设计哲学（21）→ K8s 生产架构（22）→ 真实业务场景（23）的路线图。

接下来真正要做的事情，不在文章里，在你公司里。

参考资料

• Model Context Protocol 规范 - Anthropic 开放协议
• LiteLLM - 开源 LLM Gateway
• Continue.dev - 开源 VS Code AI 助手参考实现
• Qdrant / Milvus - 开源向量数据库
• bge-m3 - 中文优秀的 embedding 模型
• NATS - 轻量级消息总线，多 agent 通信首选
• LangGraph - 多 agent 编排框架参考