Codex / Agent 的整体体系

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

一、一句话直觉版

• MCP（Model Context Protocol） 👉 “怎么把外部世界，安全、结构化地接到模型脑子里” 是 接口 / 协议 /基础设施层

• Agent Skills 👉 “这个 Agent 会干哪些事、能用哪些工具” 是 能力清单 / 行为层

类比一下：

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

二、MCP 是什么（重点讲清楚）

1. MCP 解决的核心问题

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

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

“我给你一个标准协议，你按这个协议暴露能力； 模型按协议使用能力，而不是随便乱接。”

2. MCP 到底是什么

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

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

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

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

3. MCP 通常连接什么

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

• 文件系统（读/写哪些文件）
• 代码仓库（只读 / 可写）
• 数据库
• 内部系统（CI、工单、配置中心）
• 外部 API
• 私有知识库 而且是 可声明、可审计、可限制的 。

4. 为什么 MCP 对 Agent 很关键

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

• 看上下文

• 做决策

• 调工具

• 改世界状态 MCP 让这些事情：

• 不靠 prompt hack

• 不把敏感信息直接塞进模型上下文

• 能规模化、工程化 一句话：

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

三、Agent Skills 是什么

1. Agent Skills 不是“模型能力”

这是一个很容易混的点。

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

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

2. Skill 通常长什么样

一个 Skill 一般包含：

• 名字：比如 run_tests

• 能做什么：自然语言描述

• 输入参数 schema

• 输出 schema

• 成功 / 失败条件

• 权限范围 例如：

• read_repo

• modify_file

• run_ci

• open_pr

• query_db

• fetch_metrics

3. Skills 和 MCP 的关系

这是重点：

• MCP：规定“工具怎么暴露”

• Skill：基于 MCP 暴露出来的一组“可用动作” 可以理解为：

• MCP 是底层协议

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

四、放到 Codex / Agent 体系里看

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

          你（自然语言任务）
                  ↓
        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 改变世界

七、企业内部 Agent 架构图+拆解线路

1) 企业内部 Agent 架构图（方案/路线图友好）

1.1 总览（从需求到执行）

业务用户 / 工程师 / 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（可观测与反馈闭环）

• 成功率、回滚率、耗时、成本

• 失败原因归因（权限/工具/代码/测试/环境）

• 质量评估（静态分析、覆盖率、风险评分）

1.2 分层职责（写方案最常用）

• Agent Orchestrator：把“对话”变成“可执行计划”，并控制每一步
• Policy & Safety：把“能做”变成“允许做”，是企业落地的生命线
• Context Layer：把“泛泛回答”变成“贴合公司现状的行动”
• Skills Registry：把能力产品化（可复用、可治理、可灰度）
• MCP Layer：把工具接入标准化（工程效率 + 安全边界）
• Execution Sandbox：把执行和主环境隔离（安全、可控、可复现实验）
• Change Delivery：把“改了代码”变成“按公司流程上线”
• Observability：让 Agent 变得可运营、可迭代

2) 真实企业开发场景拆解（MCP + Skills → 具体组件）

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

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

2.1 场景输入（用户给 Agent 的一句话）

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

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

这句话里其实包含了：

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

2.2 你会实现哪些 Skills（行为层）

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

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 失败返回什么）

2.3 MCP 负责把“工具系统”标准接进来（连接器层）

每个 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”

2.4 完整执行流程（一步一步，落地可照抄）

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

3) 写路线图时的“建设清单”

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

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