什么是输入上下文、MCP、Agent、Skills？—— 四个让你用不好 AI 的概念，一次讲清楚

先说一个场景。

你让 AI 帮你改一个 Bug。它看了你的代码，给了方案。改到一半，它突然忘了前面你告诉它的"不要改配置文件"。你提醒它------它道歉，继续改。改到后面，它又忘了。第 4 次提醒的时候，你崩溃了："这 AI 是不是故意的？"

不是故意的。是它的上下文窗口爆了。

你生成了一个 800 行的代码、它帮你改了 800 行、中间来回对话 30 轮------所有这些东西都塞在一个叫"上下文"的容器里。这个容器有容量上限。装满了之后，AI 开始"忘记"最早的内容------包括你反复提醒的"不要改配置文件"。

这不是 AI 在敷衍你------是你跟它的对话已经超出了它的"工作记忆"容量。就像你跟一个人聊天聊了 6 个小时，他记不住你第一小时说的那个细节------不是他不尊重你，是他脑子里的草稿纸面积有限。

这篇文章把四个最常被问但最少被说明白的概念拆开：输入上下文、MCP、Agent、Skills。不是论文式的定义------是让你下次用 AI 的时候知道"为什么它突然忘了"、"为什么它有时候能用外部工具"、"Agent 和普通对话有什么区别"。

一、输入上下文：AI 的"工作记忆"

它是什么

上下文（Context）是 AI 模型在生成每一个字时，能"看到"的所有信息的总和。包括：

系统指令（"你是一个 SRE 工程师"）
你跟它的所有对话历史
它读取的文件内容
它之前写的代码
工具调用的结果

所有这些信息拼成一个很长的文本，喂给模型。模型的"眼睛"只能看到这个文本窗口内的东西------窗口外面的，它完全不知道。

为什么它有限制

因为每多处理 1 个字（token），需要的计算量和显存就多一点。GPT-4 的上下文是 128K tokens（约等于 10 万中文字、或 300 页书的内容）。Claude 可以到达 200K（约等于 15 万中文、或 500 页书）。

这个容量听起来很大------但你跟 AI 对话 50 轮、它帮你生成了几千行代码之后------容量就用得差不多了。

容量满了之后会发生什么

AI 系统会自动做"压缩"------把最早的内容总结成几段摘要，丢掉细节。所以：

arduino 复制代码

对话第 1 轮：你："不要改配置文件"  →  AI 记住了
对话第 30 轮：上下文满了
对话第 31 轮：AI 开始"压缩"------丢掉早期的对话细节
对话第 32 轮：AI 改了配置文件  →  你爆炸

这就是为什么你跟 AI 对话很久之后，它突然"不听话"的原因------不是它叛逆，是它记不住。

你该怎么处理

重要约束别只说一次。 在对话变长之后，重要信息在关键节点再重复一遍。就像你给人类开会------重要的结论在会议结束时再说一遍是一样的道理。
开新对话处理新任务。 别在一个对话里把"修 Bug"、"写单元测试"、"写 PR 描述"、"重构架构"全做完。一件事开一个新对话------上下文干净、AI 聚焦。
把"规则"写到项目的 CLAUDE.md 文件。 AI 在每次对话开始时自动读取这个文件。文件里的规则不需要你每次重复------它在上下文的"开头"位置、不会被短期内"压缩"影响。

二、MCP：AI 的"USB-C 接口"

它是什么

MCP（Model Context Protocol）是 Anthropic 在 2024 年底发布的一个开源协议。它的作用是：让 AI 模型通过一个标准接口连接外部数据和工具------数据库、API、文件系统、GitHub、Slack 等。

用一句话解释：MCP 之于 AI，就像 USB-C 之于硬件。 在 USB-C 出现之前，手机、笔记本、显示器各有各的充电线。MCP 出现之前，每个 AI 工具要集成 GitHub、要查数据库、要读 Confluence------开发者为每个数据源写一套自定义适配器。有了 MCP------一个标准协议走天下。

它是怎么工作的

arduino 复制代码

AI 模型
    │
    ▼
MCP Client（内嵌在 AI 应用里）
    │
    ▼
MCP Server（你写的小程序，实现了 MCP 协议）
    │
    ▼
外部数据源（数据库、文件、API、GitHub Issues...）

MCP Server 是一个轻量级程序------你可以用 Python、Node.js、Go 写。它暴露"我有哪些工具"和"我有哪些数据"两个接口。AI 通过 MCP Client 跟它通信------Client 和 Server 之间是标准格式的 JSON-RPC。

MCP Server 示例（Python，10 行代码）：

python 复制代码

from mcp.server import Server

server = Server("my-db")

@server.tool()
def query_database(sql: str) -> str:
    """执行 SQL 查询，返回结果"""
    import sqlite3
    conn = sqlite3.connect("data.db")
    return str(conn.execute(sql).fetchall())

写完这段代码，AI 就能直接"查询你的数据库"------不需要你在对话里手动粘贴查询结果。

它能做什么

集成类型	举例
数据库	AI 直接查生产库的表结构，不用你复制粘贴
GitHub	AI 读 Issue、创建 PR、看 CI 日志
文件系统	AI 读整个项目目录、而不是你一个个文件发过去
Jira / Linear	AI 查 Bug 描述、更新工单状态
Slack	AI 搜聊天记录找之前的讨论
Docker / K8s	AI 看 Pod 日志、exec 进容器排查
浏览器	AI 打开网页截图、自动填写表单

MCP 的本质是把"你给 AI 发文件、发截图、发日志"这个手工过程------变成 AI 自己读取、自己检索。你不是在"帮 AI 做功课"------你是在给 AI 配一个能自己找资料的工具箱。

三、Agent：能"自己动手"的 AI

它跟普通 AI 对话有什么区别

普通 AI 对话（Chat）：

arduino 复制代码

你："这个问题怎么解决？"
AI："你可以：1. xxx 2. xxx 3. xxx"
你照着做，遇到不会的再问。

Agent 模式：

arduino 复制代码

你："帮我把这个 Bug 修好。"
Agent 自己：读代码 → 定位问题 → 改文件 → 跑测试 → 构建验证 → 提交 PR → 回来说"弄完了"。

普通对话是"大脑"------给你建议但不自己执行。Agent 是"大脑 + 手"------它自己调用工具（读文件、改代码、跑命令行、搜索网页）完成一个完整的任务链。

Agent 的四个核心能力

规划（Planning）：拿到一个复杂任务后，Agent 自己拆成步骤------"先查数据库 → 再改 API 接口 → 再更新前端 → 最后跑测试"。不需要你一步步下达指令。
工具使用（Tool Use）：Agent 不止能"说话"------它能调用外部函数。读文件、写文件、执行 Shell 命令、搜索代码库------所有你编程时能做的事，Agent 都能通过工具调用完成。
记忆（Memory）：Agent 在任务过程中会记住"我已经读过了哪些文件、改过了哪些地方"------不会重复工作、不会前后矛盾。这个记忆跨越多轮对话、贯穿整个任务。
错误恢复（Error Recovery）：Agent 执行命令失败了 → 它读错误输出 → 分析原因 → 调整方案 → 重试。不是"报错了就停下等你来修"------是"自己试着自己修"。

Agent 不是魔法------它是一个"循环"

Agent 的内部运行逻辑其实非常简单------就是一个 while 循环：

markdown 复制代码

while 任务未完成:
    1. 看当前的状态（文件内容、错误输出、已完成的步骤）
    2. 想下一步做什么（调用哪个工具、传什么参数）
    3. 执行工具调用
    4. 看工具返回的结果
    5. 判断：完成任务了？需要再试？还是告诉用户"我卡住了"？

这个循环的本质：Agent 不是"更聪明的 AI"------是"被允许反复尝试、不断自我纠正的 AI"。同一个模型，你让它只回答一次 vs 允许它循环调用工具、读结果、调整------这就是"普通对话"和"Agent 工作流"的全部差异。

Agent 不是万能的

Agent 也是受上下文窗口限制的。任务太复杂、步骤太多 → 上下文满了 → Agent 开始"忘记"前面的步骤。这就是为什么长任务的 Agent 需要在中间穿插"检查点"和"摘要"。
Agent 会犯错------而且错了会继续错。因为它相信自己每一步的判断，容易在错误路径上越走越远。这叫做"幻觉级联"（Hallucination Cascade）。好的 Agent 设计需要在关键步骤设"人工确认点"------让你在它炸之前叫停。

四、Skills：AI 的"专业技能包"

它是什么

Skills（技能）是一套预定义的、可复用的指令集------告诉 AI：当你遇到某个特定任务时，按这个步骤做、用这些工具、这样检查结果。

跟 Agent 的区别：Agent 是"能动手的 AI"，Skills 是"动手时的标准操作规程（SOP）"。

举个例子

没有一个 Skill 的时候，你每次让 AI 修 Bug：

arduino 复制代码

你："修 Bug"
AI：（自己想怎么修）→ 可能查漏了日志 → 可能没写测试 → 每次结果不可控

有 Debugging Skill 之后：

markdown 复制代码

Skill 自动加载 → AI 读到："修 Bug 时按这个步骤：
  1. 复现 Bug 并记录错误信息
  2. 用 git bisect 找引入 Bug 的 commit
  3. 分析 diff，推断根因
  4. 写修复代码
  5. 写测试证实修复有效
  6. 跑全量测试确保没引入回归
  7. 生成修复报告"

AI 严格按七步执行 → 每次结果一致、可预期

Skills 的价值

没有 Skill	有 Skill
每次修 Bug 的方式取决于 AI 临场发挥	每次都按同一套 SOP 执行
可能遗漏关键步骤（如忘记写测试）	检查清单式执行，不漏步骤
新人用 AI 无法复制老手的流程	资深工程师把经验写成 Skill → 全团队复用
跨项目经验无法迁移	写一次 Skill，用在所有项目里

Skills 是一份文本，不是代码

一个 Skill 就是一个 Markdown 文件------里面写着"做什么、怎么做、检查什么"。没有编程门槛------你能写一份运维 Checklist，就能写一个 Skill。例如一个 Kubernetes 排障 Skill：

markdown 复制代码

---
name: k8s-debug
description: Kubernetes 故障排查标准流程
---

# Kubernetes 排障 Checklist

按以下顺序排查，每一步确认通过再进入下一步：

1. kubectl describe pod → 看 Events 和 Conditions
2. kubectl logs -p → 看上一次容器崩溃的日志
3. 检查资源限制：requests/limits 是否合理
4. 检查健康检查：readiness/liveness probe 是否过激
5. 检查 Node 状态：磁盘、内存、PID 压力
6. 每步输出结果后暂停，确认无误再继续

这个文件放在项目里，AI 每次被问"我的 Pod 为什么起不来"的时候自动加载------它就会按这份 Checklist 逐一排查，而不是跳过步骤、直接猜答案。

五、四者的关系------一张图

bash 复制代码

┌──────────────────────────────────────────────┐
│                  你（用户）                    │
│                      │                        │
│          "帮我修好这个生产 Bug"                  │
└──────────────────────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────┐
│              Agent 大脑（循环决策）              │
│                                               │
│  "我应该先看什么？ → 看 Pod 日志"               │
│  "日志报什么错？ → OOMKilled"                   │
│  "应该查内存监控 → 我用 MCP 查 Prometheus"      │
│  "找到原因了 → 修复代码 → 跑测试 → 提 PR"       │
└──────────────────────────────────────────────┘
          │                    │
          ▼                    ▼
┌──────────────────┐  ┌──────────────────────┐
│  Skills (SOP)     │  │  MCP (外部连接)        │
│                   │  │                      │
│  • 排障 Checklist  │  │  • kubectl exec       │
│  • 回滚流程       │  │  • Prometheus API     │
│  • PR 规范        │  │  • GitHub API        │
│  • 测试清单       │  │  • Slack 通知         │
└──────────────────┘  └──────────────────────┘
          │                    │
          └────────┬───────────┘
                   ▼
┌──────────────────────────────────────────────┐
│           上下文窗口（工作记忆）                   │
│                                               │
│  容量：128K-200K tokens                        │
│  装的东西：                                   │
│    • 你的指令                                 │
│    • Skills 内容                              │
│    • MCP 工具返回的结果                        │
│    • Agent 已执行的步骤记录                     │
│    • 所有对话历史                              │
│                                               │
│  满了 → 最早的记忆被"压缩"或丢弃                 │
└──────────────────────────────────────────────┘

用一个类比总结：

上下文是 AI 的工作记忆------容量有限，满了就忘
MCP 是 AI 的感官------让它能"看见"和"操作"外部世界（数据库、API、文件系统）
Agent 是 AI 的自主模式------它能自己决定什么时候用什么工具、怎么组合
Skills 是 AI 的 SOP------确保每次执行任务的质量和一致性

理解这四个概念之后，你就能回答几个实际的问题：

为什么 AI 对话长了就"不听话"？ → 上下文窗口满了，早期指令被丢弃。

为什么同样是 AI，Agent 能做完整任务而普通对话不行？ → Agent 有工具调用循环，能自己在试错中调整，普通对话只有一次回复机会。

为什么 AI 有时候能查我的数据库，有时候不行？ → 有 MCP Server 连接数据库时就能查，没有 MCP 就只能靠你粘贴结果。

为什么有些团队的 AI 工作流非常稳定，每次输出一致？ → 他们写了 Skills------把资深工程师的经验固化为了可复用的 SOP。

这四个东西不是独立的"AI 黑话"------它们是让 AI 从"一个能聊天的模型"变成"一个能独立完成任务的工程师"的四个维度。少了任何一个，你用的 AI 都只是一个复读机。