Codex / Agent 的整体体系 cover image

Codex / Agent 的整体体系

/ 所有日志 / Codex / Agent 的整体体系
Ai Tech

Codex / Agent 的整体体系

2026-01-16

直觉版 → 技术本质 → Codex / Agent 的整体体系：

  • MCP（Model Context Protocol）

    👉“怎么把外部世界，安全、结构化地接到模型脑子里”

    是接口 / 协议 /基础设施层

  • Agent Skills

    👉“这个 Agent 会干哪些事、能用哪些工具”

    是能力清单 / 行为层

类比一下：

  • MCP = USB / Type-C 接口标准
  • Agent Skills = 插上去的键盘、鼠标、摄像头、U 盘

在没有 MCP 之前，Agent 想要用外部能力会很乱：

  • 每个工具都有自己的一套调用方式
  • 权限、认证、参数格式全不一样
  • 上下文注入靠 prompt 拼字符串，很脆弱
  • 安全边界不清晰（模型“看到了不该看的东西”）

MCP 的目标是标准化这件事：

“我给你一个标准协议，你按这个协议暴露能力；

模型按协议使用能力，而不是随便乱接。”

从本质上说，MCP 是一个“模型 ↔ 外部能力” 的协议层，定义了：

  • 能力如何被描述（schema）
  • 模型能看到哪些上下文
  • 模型可以调用哪些操作
  • 输入 / 输出的结构
  • 权限和边界在哪

重点：

MCP不是一个模型，也不是一个 Agent

它是让模型“可控地扩展能力”的标准方式

通过 MCP，可以把这些东西“接进来”：

  • 文件系统（读/写哪些文件）
  • 代码仓库（只读 / 可写）
  • 数据库
  • 内部系统（CI、工单、配置中心）
  • 外部 API
  • 私有知识库

而且是可声明、可审计、可限制的。

Agent 的核心不是“会说话”，而是：

  • 看上下文
  • 做决策
  • 调工具
  • 改世界状态

MCP 让这些事情：

  • 不靠 prompt hack
  • 不把敏感信息直接塞进模型上下文
  • 能规模化、工程化

一句话：

没有 MCP，Agent 很难进企业、进生产环境。

这是一个很容易混的点。

  • 模型能力：语言理解、推理、生成
  • Agent Skills：模型“被允许 + 被封装”的行动能力

Skill ≈

“在某个边界内，我可以做一类动作”

一个 Skill 一般包含：

  • 名字：比如run_tests
  • 能做什么：自然语言描述
  • 输入参数 schema
  • 输出 schema
  • 成功 / 失败条件
  • 权限范围

例如：

  • read_repo
  • modify_file
  • run_ci
  • open_pr
  • query_db
  • fetch_metrics

这是重点：

  • MCP：规定“工具怎么暴露”
  • Skill：基于 MCP 暴露出来的一组“可用动作”

可以理解为：

  • MCP 是底层协议
  • Skill 是协议之上的“能力封装”

把三者放在一起看会非常清楚： 

          你（自然语言任务）
                  ↓
        Codex / Agent（推理 + 规划）
                  ↓
           Agent Skills（能做什么）
                  ↓
           MCP（怎么安全调用）
                  ↓
        外部世界（代码 / 系统 / 数据）

举个真实场景：

你说：

“给这个项目加一个缓存层，并保证测试通过”

Agent 内部会做的事：

  1. 用模型能力理解任务
  2. 制定计划（先看代码 → 加逻辑 → 跑测试）
  3. 调用 Skill：
    • read_repo
    • edit_file
    • run_tests
  4. 每个 Skill 背后，都是通过 MCP 调用真实系统
  5. 根据结果继续迭代或收敛

因为行业正在从：

  • “AI 会不会写代码”
  • “AI 能不能聊天”

转向：

  • “AI 能不能稳定、可控地干活”
  • “能不能进生产、进公司内网、进复杂系统”

MCP + Agent Skills 是让 Agent 工程化的两块基石。

  • MCP：让模型“接世界”的标准协议
  • Agent Skills：模型“能动手做什么”的能力清单
  • Codex / Agent：用模型推理，调 Skills，通过 MCP 改变世界

业务用户 / 工程师 / PM

↓（自然语言需求、约束、验收标准）

Agent 入口层（Chat UI / Slack Bot / IDE 插件 / 工单入口）

↓

Agent Orchestrator（编排与治理）

  • 任务分解 / 计划生成
  • 工具选择（Skills 路由）
  • 状态机（Plan → Act → Observe → Refine）
  • 预算/配额（调用次数、token、运行时长）

    ↓

    Policy & Safety（策略与安全总控）

  • RBAC/ABAC 权限校验（谁能做什么）
  • 数据分级与脱敏（PII/密钥/商业机密）
  • 变更控制（写操作需审批/双人复核/仅 PR）
  • 审计日志（可追溯）

    ↓

    Context Layer（上下文聚合）

  • 知识检索：内部文档/规范/Runbook（RAG）
  • 代码上下文：仓库结构、关键文件、历史 PR
  • 运行上下文：CI 状态、监控指标、告警、工单
  • 会话记忆：任务历史、偏好、约束

    ↓

    Skills Registry（技能注册与发现）

  • 每个 Skill：描述 + 输入输出 schema + 权限范围 + 失败语义
  • 版本管理、灰度、A/B

    ↓

    MCP Layer（协议/连接器层）

  • 标准化工具暴露（schema、调用、权限边界）
  • 连接器：Git/CI/Issue/DB/Logs/Deploy/Secrets…

    ↓

    Execution Sandbox（执行环境）

  • 代码 checkout、编译、单测、lint
  • 网络隔离、文件隔离、资源限制
  • 产出物：diff、测试报告、构建产物

    ↓

    Change Delivery（交付与上线）

  • 生成 PR / 变更单
  • 触发 CI
  • 审批合并
  • 发布/回滚（可选自动化）

    ↓

    Observability（可观测与反馈闭环）

  • 成功率、回滚率、耗时、成本
  • 失败原因归因（权限/工具/代码/测试/环境）
  • 质量评估（静态分析、覆盖率、风险评分）
  • Agent Orchestrator：把“对话”变成“可执行计划”，并控制每一步
  • Policy & Safety：把“能做”变成“允许做”，是企业落地的生命线
  • Context Layer：把“泛泛回答”变成“贴合公司现状的行动”
  • Skills Registry：把能力产品化（可复用、可治理、可灰度）
  • MCP Layer：把工具接入标准化（工程效率 + 安全边界）
  • Execution Sandbox：把执行和主环境隔离（安全、可控、可复现实验）
  • Change Delivery：把“改了代码”变成“按公司流程上线”
  • Observability：让 Agent 变得可运营、可迭代

我用一个非常典型、且能覆盖“读/改/测/发/查”的场景：

“线上接口延迟升高 + 需要快速修复并走 PR 流程”

“支付服务POST /charge延迟从 80ms 升到 300ms。

请定位原因，给出修复 PR，确保单测通过，并提供回滚方案。”

这句话里其实包含了：

  • 目标：降延迟
  • 约束：必须走 PR + 测试通过
  • 风险：需要回滚方案
  • 上下文：支付服务、特定接口

把“能干的活”拆成清晰技能（可治理、可审计）：

A. 观察/诊断类 Skills（只读）

  • fetch_metrics(service, timeframe, metrics)

    取 p50/p95/p99、QPS、错误率

  • query_logs(service, query, timeframe)

    查慢请求、错误栈、traceId

  • fetch_traces(service, endpoint, timeframe)

    看链路耗时分布（DB/缓存/下游）

  • read_runbook(topic)

    读内部排障手册（非常关键）

B. 代码类 Skills（读/写受控）

  • open_repo(repo)/read_file(path)/search_code(query)
  • apply_patch(diff)（写操作，默认只在分支/工作区）
  • run_tests(target)/run_lint()
  • build_artifact()（可选）

C. 交付类 Skills（强治理）

  • create_branch(name)
  • create_pull_request(title, description, reviewers)
  • trigger_ci(pr_id)/get_ci_result(pr_id)
  • request_approval(pr_id, approvers)（若需要）

D. 变更风险 Skills（强约束）

  • generate_rollback_plan(change_summary)
  • risk_assessment(diff, touched_components)
  • check_secrets_leak(diff)（防止密钥误提交）

你会发现：

Skills 的设计重点不在“功能多”，而在：

  • 输入输出结构化（schema）
  • 权限可控（谁能调用写操作）
  • 失败语义明确（例如 CI 失败返回什么）

每个 Skill 背后可能需要不同系统支持，而 MCP 做统一接口层：

  • Git MCP Server（GitHub/GitLab）
    • 仓库读取、分支、PR、diff、reviewers
  • CI MCP Server（Jenkins/GitHub Actions/Buildkite）
    • 触发构建、获取测试结果、拉取日志
  • Observability MCP Server（Datadog/Prometheus/Grafana/New Relic）
    • 指标查询、仪表盘链接、告警
  • Logs/Tracing MCP Server（ELK/Splunk/Jaeger/Tempo）
    • 日志检索、trace 查询
  • Issue MCP Server（Jira/Linear）
    • 关联工单、更新状态、生成变更记录
  • Secrets/Config MCP Server（Vault/Config service）
    • 读取“允许暴露的配置”（严格白名单）
  • Deploy MCP Server（ArgoCD/Spinnaker）
    • 仅在审批后允许灰度/回滚（通常强限制）

重点：

MCP 让这些连接器都长得像“同一种工具”：

  • 可发现、可描述、可校验、可审计
  • Agent 不需要为每个系统写一套“特殊 prompt”
  1. 任务理解与计划（Orchestrator）
  • 生成执行计划：先看指标 → 查链路 → 查日志 → 对照 runbook → 出候选原因 → 定位代码 → 修 → 测 → PR
  1. 只读诊断（调用 Skills）
  • fetch_metrics(payment-service, last_2h, [latency_p95,error_rate,qps])
  • fetch_traces(payment-service, /charge, last_2h)
  • query_logs(payment-service, "timeout OR slow", last_2h)
  • read_runbook("payment latency")
  1. 提出可验证假设（模型推理，但必须“可验证”）

    例：

  • DB 查询退化（缺索引 / N+1）
  • 缓存穿透导致下游被打爆
  • 新版本引入同步调用
  1. 定位到代码点（代码类 Skills）
  • open_repo(payments)
  • search_code("POST /charge")
  • read_file("charge_handler.go")
  • read_file("db/query_charge.sql")
  1. 受控修改（写操作）
  • create_branch("fix/charge-latency-cache")
  • apply_patch(diff)

    例如：加缓存、减少重复查询、加超时/批量查询（这里具体改法按项目情况）

  1. 验证（执行环境）
  • run_tests("...")
  • run_lint()
  • 如失败：Agent 再迭代修复直至通过（或输出“无法通过”的最小复现和原因）
  1. 交付（PR 流程）
  • create_pull_request(...)

    PR 描述里包含：根因、改动点、验证结果、风险、回滚方案

  • trigger_ci(pr)
  • get_ci_result(pr)
  1. 回滚与风险（必须产出）
  • generate_rollback_plan(...)
  • risk_assessment(...)
  1. 闭环（可观测）
  • 合并后，持续监控 p95 是否回落
  • 若未回落，自动开 follow-up issue

把这套东西变成一份落地计划，最常见拆法是三期：

  • Phase 1（只读 Agent）：指标/日志/文档检索 + 诊断报告（低风险、快速见效）
  • Phase 2（PR Agent）：允许受控写代码 + 跑测试 + 提 PR（引入审批与审计）
  • Phase 3（发布/回滚 Agent）：灰度、发布、自动回滚（强策略、强观测）

💡
ai、设计、本银河星区空间站，是由 Tia 打造，主要分享日志、ai、设计、效率工具和在银河系生活的所思所想，欢迎分享文章