让我们从一个实际场景开始说起。

你让 AI 帮忙修复一个 Bug。它查看了你的代码，给出了一个解决方案。但改到一半，它突然忘记了之前你反复强调的“不要修改配置文件”。你提醒它，它道歉，继续修改。然而，改到后面，它又忘记了。当你第四次提醒时，你的心态彻底崩溃了：“这 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 系统会自动进行“压缩”——把最早的内容总结成几段摘要，并丢弃细节。因此：

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

这就是为什么当你与 AI 长时间对话后，它突然“不听话”的原因——不是它叛逆，而是它记不住了。

你该怎么处理

1. 重要约束不要只重复一次。 当对话变长后，在关键节点再次强调重要信息。就像你给人类开会——重要的结论在会议结束时再重申一遍，道理是一样的。
2. 为新任务开启新对话。 不要在一个对话里把“修 Bug”、“写单元测试”、“写 PR 描述”、“重构架构”全部做完。一件事开启一个新对话——上下文干净，AI 也更聚焦。
3. 把“规则”写入项目的 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——一个标准协议就能走遍天下。

它是怎么工作的

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 行代码）：

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

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

它能做什么

MCP 的本质是把“你给 AI 发文件、发截图、发日志”这个手工操作过程——变成 AI 自己主动读取、自行检索。你不是在“帮 AI 做功课”——而是在给 AI 配备一个能自己找资料的工具箱。

三、Agent：能“自己动手”的 AI

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

普通 AI 对话（Chat）：

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

Agent 模式：

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

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

Agent 的四个核心能力

1. 规划（Planning）：拿到一个复杂任务后，Agent 会自己将其拆解成步骤——“先查数据库 → 再改 API 接口 → 再更新前端 → 最后跑测试”。无需你逐步下达指令。

2. 工具使用（Tool Use）：Agent 不仅能“说话”——它还能调用外部函数。读文件、写文件、执行 Shell 命令、搜索代码库——所有你编程时能做的事，Agent 都能通过工具调用来完成。

3. 记忆（Memory）：Agent 在任务过程中会记住“我已经读过了哪些文件、改过了哪些地方”——不会重复工作，也不会前后矛盾。这个记忆可以跨越多轮对话，贯穿整个任务。

4. 错误恢复（Error Recovery）：Agent 执行命令失败后 → 它会读取错误输出 → 分析原因 → 调整方案 → 重试。不是“报错了就停下等你来修”——而是“自己尝试自己修复”。

Agent 不是魔法——它是一个“循环”

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

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：

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

有了 Debugging Skill 之后：

Skill 自动加载 → AI 读到："修 Bug 时按这个步骤：1. 复现 Bug 并记录错误信息2. 用 git bisect 找引入 Bug 的 commit3. 分析 diff，推断根因4. 写修复代码5. 写测试证实修复有效6. 跑全量测试确保没引入回归7. 生成修复报告"AI 严格按七步执行 → 每次结果一致、可预期

Skills 的价值

Skills 是一份文本，不是代码

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

---name: k8s-debugdescription: Kubernetes 故障排查标准流程---# Kubernetes 排障 Checklist按以下顺序排查，每一步确认通过再进入下一步：1. kubectl describe pod → 看 Events 和 Conditions2. kubectl logs -p → 看上一次容器崩溃的日志3. 检查资源限制：requests/limits 是否合理4. 检查健康检查：readiness/liveness probe 是否过激5. 检查 Node 状态：磁盘、内存、PID 压力6. 每步输出结果后暂停，确认无误再继续

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

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

┌──────────────────────────────────────────────┐│你（用户）│││││"帮我修好这个生产 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 都只是一个复读机。