《程序员的 AI 工程入门》系列第 1 篇
本文定位：建立地图，不深入任何一个单独技术

如果你最近开始使用 ChatGPT、Codex、Claude Code 或 Cursor，可能会发现一个有意思的现象：

同样是 AI，有些产品只能陪你聊天、回答问题；有些产品却可以读取整个项目、搜索代码、修改文件、执行命令，甚至在遇到错误之后继续尝试，直到任务完成。

它们背后明明都可以使用大语言模型，为什么实际表现却完全不同？

问题的答案，不只是“模型更聪明”。

一个真正能够完成复杂任务的 AI 应用，通常还需要模型、上下文、工具、任务状态、权限控制、执行循环、错误恢复和运行环境。

这些概念分别叫作 LLM、Context、Tools、Agent、Agent Loop 和 AI Harness。

MCP 则负责解决另一个问题：AI 应用如何用一种更标准的方式连接外部工具和数据？

这篇文章不准备马上深入这些概念的技术细节。我们先站在程序员的角度，把它们放回同一张架构图里，看看现代 AI 应用到底是怎样组合起来的。

一、先看两个系统的区别

先把下面两个系统放在一起比较。

第一个系统是我们熟悉的聊天机器人：

用户问题
   ↓
  LLM
   ↓
文本回答

比如你问：

请解释一下 Java HashMap 的底层原理。

模型根据你输入的内容生成一段解释。整个过程可以很简单，甚至只需要调用一次模型接口。

第二个系统处理的是另一类任务：

用户：帮我修复这个项目的启动问题。

        ↓
读取项目文件
        ↓
搜索相关代码
        ↓
执行启动命令
        ↓
阅读错误日志
        ↓
修改配置或代码
        ↓
再次运行测试
        ↓
发现问题后继续处理

这已经不只是“回答一个问题”了，而是要在一个真实环境里连续完成一组动作。

第一个系统更像一个 ChatBot。第二个系统则更像一个 Coding Agent：它需要理解任务，查看环境，使用工具，根据结果决定下一步，并在必要时反复执行。

这说明：

一个能够完成任务的 AI 系统，不等于一个单独的大语言模型。

模型只是其中的一部分。真正让 AI 应用“工作起来”的，是模型、上下文、工具、循环和运行环境的组合。

二、现代 AI 应用的总架构

下面这张图就是本系列后续文章会反复使用的总架构图。

图 1：现代 AI 应用架构。图片中的三栏分别回答“模型看到了什么”“模型如何生成决策”“系统能够执行什么”。

这张图可以先只记住一条主线：

用户任务
   ↓
Context：准备本轮需要的信息
   ↓
LLM：生成回答或行动决策
   ↓
Tools：执行外部操作
   ↓
Result：得到执行结果
   ↓
回到 Context，继续下一轮

把这条主线放进系统里，就是：

                    AI Application
                           │
                           ▼
              ┌────────────────────────┐
              │ AI Harness / 运行层     │
              │                        │
              │ Context → LLM → Tools │
              │    ▲             │     │
              │    └── Result ───┘     │
              │                        │
              │ Agent Loop 负责持续推进 │
              └────────────────────────┘

接下来，我们逐个认识图中的模块。

三、LLM：模型到底是什么

LLM 是 Large Language Model 的缩写，中文通常翻译为“大语言模型”。GPT、Claude、Gemini、DeepSeek、Qwen 等，都是大语言模型产品或模型系列的名称。

站在应用开发者的角度，可以先把 LLM 理解成一个非常特殊的函数：

输入一组信息
      ↓
     LLM
      ↓
生成一个结果

例如：

输入：请解释一下 Java HashMap 的底层原理。

        ↓

       LLM

        ↓

输出：HashMap 底层主要由数组、链表和红黑树组成……

不过，LLM 和我们平时写的普通函数有一个重要区别。

普通函数通常由程序员明确写出处理规则。同样的输入，在相同条件下往往会得到确定的结果。LLM 则是根据训练得到的模型参数和当前输入，生成一个概率性的结果。

如果站在程序员使用 AI 的角度，可以先给它一个简单定义：

LLM 是一种经过大规模数据训练得到的模型，它能够根据输入的信息理解上下文、进行一定程度的推理，并生成后续内容。

四、Context：模型这一次到底看到了什么

Context 的中文是“上下文”。在本系列中，我们把它定义为：

LLM 在本轮推理时能够看到的所有有效信息。

这里的“所有信息”远远不只是前面几句聊天。一个 Coding Agent 在处理任务时，可能需要把下面这些内容一起交给模型：

Context
├── System / 系统级规则
├── Developer / 开发者指令
├── User Prompt / 用户请求
├── Conversation History / 对话历史
├── Project Files / 项目文件
├── Memory / 应用记忆
├── RAG Results / 检索结果
└── Tool Results / 工具执行结果

比如用户说：

帮我修复 UserService.java 的空指针问题。

真正送入模型的内容可能还包括：

项目规则
+
用户需求
+
UserService.java
+
UserController.java
+
相关 Entity
+
之前的对话
+
刚刚执行测试得到的错误日志

这些信息组合在一起，才构成模型真正能够利用的 Context。

因此，很多 AI 应用的效果问题，并不一定是“模型不够聪明”，也可能是：

• 关键文件没有被放入 Context。
• 传入了太多无关内容。
• 工具结果没有正确返回。
• 历史对话与当前任务混在了一起。
• 项目规则没有被明确提供。

理解 Context，是理解现代 AI 工程的第一个关键转折点。

五、Prompt 只是 Context 的一部分

在本系列中，我们先给它一个工程化定义：

Prompt 是为了引导 LLM 完成某个目标，而提供给模型的指令性输入。

Prompt 是大家最早接触到的 AI 概念之一。比如：

请帮我写一个 Java 单例模式。

这就是一个 Prompt。

在本系列的入门语境中，可以先采用下面这个关系：

Prompt ⊂ Context

也就是说，Prompt 主要描述“我们希望模型做什么”，而 Context 描述“为了完成这件事，模型能够看到什么”。

可以把它们理解成两个不同的问题：

Prompt Engineering：这句话应该怎么问？

Context Engineering：为了完成任务，模型到底应该看到哪些信息？

例如，同样是下面这句话：

帮我修复这个 Bug。

如果模型只看到这一句话，它几乎无法完成任务；如果 Context 里还包含错误日志、相关代码、项目规范和测试命令，模型才有机会做出可靠判断。

所以 Prompt 很重要，但在复杂 AI 应用中，Prompt 并不是全部。

好的 Prompt 说明目标，好的 Context 提供完成目标所需要的材料。

这里还要特别说明：有些模型 API 或技术文章会把完整输入也统称为 Prompt。为了避免混乱，本系列在解释架构时，会使用更宽的 Context 表示模型本轮能够看到的整体信息，把具体指令称为 Prompt。

六、Token、Context Window 和 Memory：能看到不等于能一直记住

接下来是三个经常被放在一起、但含义完全不同的词：Token、Context Window 和 Memory。

1. Token 是信息计量单位

模型处理文本时，并不是按照人类理解的“字数”来计算，而是把输入和输出拆分成许多 Token。一个 Token 可能对应一个汉字、一个英文单词的一部分、一个标点，也可能对应代码中的一小段字符。

因此，Token 不是字符数，也不是字数的绝对等价物。它更像是模型处理信息时使用的基本计量单位。

2. Context Window 是容量上限

Context Window 可以翻译成“上下文窗口”。它表示：

一个模型在一次处理过程中，最多能够容纳多少 Token 的上下文。

可以用程序员熟悉的方式类比：

List<Message> context = ...; // 实际装进去的内容

而：

maxContextTokens = 128K

更像是这个容器的容量上限。

所以：

Context        = 这一次实际放进去的内容
Context Window = 模型一次最多能装多少内容
Token          = 衡量内容大小的单位

3. Memory 是应用层的持久化信息

Memory 通常翻译成“记忆”，但它不一定意味着模型把信息永久记住了。

在实际 AI 应用中，Memory 往往由应用程序保存到数据库、文件或其他存储系统里。下一次用户提出问题时，应用先检索相关记忆，再把结果放回新的 Context 中。

因此，Memory 更接近：

保存历史信息
      ↓
需要时检索
      ↓
重新放入 Context
      ↓
交给 LLM 使用

三者的关系可以总结为：

Token 组成信息
   ↓
信息被组织成 Context
   ↓
Context 受到 Context Window 限制
   ↓
Memory 通过存储与检索，为新的 Context 提供历史信息

这里有几个容易出现的误解：

• Context Window 不是模型的永久记忆。
• 聊天记录不一定会完整保留，也不一定会在每一轮全部发送。
• Memory 通常不是直接写进模型参数，而是由应用系统保存和检索。
• Context 越多不一定越好，无关信息会增加噪声和成本。

这一部分后面会用专门的文章展开。现在只需要记住：Context 是本轮可见信息，Context Window 是容量，Memory 是可以被检索回来的历史信息。

七、RAG：把外部知识放进 Context

如果 LLM 本身不知道你的公司制度、项目文档或内部知识库，应该怎么办？

一种常见方法是 RAG，全称是 Retrieval-Augmented Generation，中文通常翻译为“检索增强生成”。

它的基本思路不是重新训练模型，而是：

1. 先从外部资料中检索与问题相关的内容。
2. 对检索结果进行筛选和整理。
3. 把整理后的资料放入本轮 Context。
4. 让 LLM 根据这些资料生成回答。

流程可以表示为：

用户问题
   ↓
检索相关资料
   ↓
筛选与整理结果
   ↓
放入 Context
   ↓
LLM 生成回答

比如你问：

公司的报销标准中，出差住宿费应该如何申请？

普通 LLM 不一定知道你公司的最新制度。RAG 系统可以先从公司制度文档中找到相关段落，再把它们作为 Context 提供给模型。

这里需要注意：RAG 不是数据库本身，也不是模型的永久记忆。它更像一条“检索资料 → 加入 Context → 生成回答”的处理链路。

这也解释了为什么 RAG 的效果不只取决于模型，还取决于：

• 文档是否完整。
• 文档切分是否合理。
• 检索是否找到真正相关的内容。
• 结果是否经过排序和过滤。
• 最终 Context 是否足够清晰。

所以，在架构图里，RAG 应该被放在 Context 的来源一侧，而不是被画成一个与 LLM 平行的“另一个大脑”。

八、Tools：让 AI 不只是生成文字

LLM 擅长生成内容，但真实任务经常要求系统执行动作：

读取文件
查询数据库
搜索网页
调用接口
修改代码
执行命令
发送消息

这些可以被 AI 应用调用的外部能力，统称为 Tools，也就是“工具”。

一个 Coding Agent 可能拥有下面这些工具：

Tools
├── Read File
├── Write File
├── Search Code
├── Run Terminal
├── Git
├── Browser
└── Business API

但需要区分一件重要的事情：

模型通常不是直接执行工具，而是提出一个结构化的调用请求；真正执行工具的是宿主程序或 Agent Runtime。

例如，用户说：

帮我查询订单 123 的状态。

一个简化的 Tool Calling 流程是：

用户请求
   ↓
LLM 判断需要调用工具
   ↓
生成结构化请求：getOrder(123)
   ↓
宿主程序检查参数和权限
   ↓
真正访问订单服务
   ↓
返回 Tool Result
   ↓
LLM 根据结果生成最终回答

这里的 Function Calling，通常是以函数形式表达 Tool Calling 的叫法。Tool Calling 是更宽的概念，因为工具不一定只是一个本地函数，也可能是浏览器、文件系统、远程 API 或 MCP 服务。

工具系统还必须处理很多普通软件工程问题：

• 参数是否有效。
• 当前用户是否有权限。
• 操作是否需要人工确认。
• 请求是否超时。
• 失败后是否可以重试。
• 重试会不会造成重复写入。
• 工具结果是否可信、完整、可审计。

因此，“模型可以调用工具”不等于“模型拥有无限权限”。工具的注册、校验和执行，都属于运行系统的职责。

九、MCP：工具与外部世界的标准连接方式

当 AI 应用只有一个工具时，直接写一个函数或 API 适配层就可以了。但如果要连接很多不同的系统，问题很快会变复杂：

GitHub
MySQL
Figma
Jira
文件系统
浏览器
内部业务平台

如果每一个 AI 应用都为这些系统单独设计一套连接方式，工具生态会越来越难维护。

这就是 MCP 被放进架构图的原因。

MCP 是 Model Context Protocol 的缩写。入门阶段可以先把它理解为：

一种让 AI 应用以标准化方式发现和连接外部工具、数据与能力的协议。

它通常涉及：

Agent / Harness
       ↓
   MCP Client
       ↓
   MCP Server
       ↓
外部工具、数据和业务系统

MCP 不是 LLM，也不是 Agent。它更接近 AI 应用与外部能力之间的连接层。

可以用下面的方式区分几个概念：

概念	主要解决的问题
API	一个业务系统如何提供服务调用接口
Tool Calling	模型如何提出一次结构化工具调用请求
MCP	AI 应用如何标准化地连接和发现外部能力
Agent	系统如何围绕目标组合模型、上下文、工具和循环

它们并不是互相排斥的关系。一个 Agent 可以通过 Tool Calling 调用工具，而这个工具又可能是通过 MCP 接入的远程能力。

十、Agent：从回答问题到完成任务

到这里，我们已经认识了：

LLM
+
Context
+
Tools

但把这三个东西放在一起，还不能自动得到一个能够持续完成任务的 Agent。

Agent 中文通常翻译为“智能体”。为了避免把它说得过于神秘，可以先采用一个工程化定义：

Agent 是一个围绕目标，使用模型、Context 和 Tools，并能够连续推进任务的 AI 系统。

可以把它粗略表示为：

Agent ≈ Goal + LLM + Context + Tools + Loop + Policy

其中：

• Goal 是任务目标。
• LLM 提供理解、生成和决策能力。
• Context 提供本轮需要的信息。
• Tools 提供与外部世界交互的能力。
• Loop 让系统可以继续下一步。
• Policy 负责限制哪些动作可以执行。

普通 ChatBot 通常是：

用户问题 → LLM → 文本回答

Agent 更像：

用户目标
   ↓
观察当前状态
   ↓
决定下一步
   ↓
调用工具执行
   ↓
获得执行结果
   ↓
再次观察和决策
   ↓
直到完成或需要人工介入

所以，Agent 的核心不在于“它像一个人”，而在于它能够围绕目标持续进行状态转换和行动。

十一、Agent Loop：为什么 AI 可以连续工作

Agent 与普通 ChatBot 的关键差异，还在于它不是只做一次“输入 → 输出”。它需要在任务过程中反复观察、决策、行动，再根据结果决定下一步。

这个循环通常叫作 Agent Loop，也就是 Agent 循环。

可以把它简化成：

Observe：观察当前状态
      ↓
Decide：决定下一步
      ↓
Act：执行一个动作
      ↓
Result：获得执行结果
      ↓
更新 Context 和任务状态
      ↓
回到 Observe

还是以“修复项目启动问题”为例，Agent 可能经历这样的过程：

Observe：查看项目目录和启动命令
      ↓
Decide：先读取 application.yml
      ↓
Act：调用 Read File 工具
      ↓
Result：发现数据库地址配置异常
      ↓
Observe：检查当前配置与运行环境
      ↓
Decide：修改配置后重新启动
      ↓
Act：调用 Write File 和 Terminal 工具
      ↓
Result：项目启动，但测试仍然失败
      ↓
继续下一轮分析

这里的“决定”可以由模型生成，也可以由预先写好的工作流或规则参与控制。重点不在于模型是不是每次都完全自主，而在于系统具备了连续推进任务的机制。

一个可靠的 Agent Loop 还需要考虑：

• 什么时候应该停止。
• 失败后是否应该重试。
• 哪些操作必须请求人工确认。
• 如何防止重复修改或重复提交。
• 工具连续失败时如何退出。
• 如何保存任务状态，方便恢复和审计。

因此，Agent Loop 不是“让模型无限思考”，而是一个由运行时管理的任务循环。

十二、AI Harness：让 Agent 真正能够工作

到这里，我们已经有了模型、Context、Tools 和 Agent Loop。但如果把它们直接拼在一起，仍然不一定能得到一个稳定的 AI 应用。

还需要有一套运行和控制这些能力的基础设施，这就是本系列所说的 AI Harness，也可以叫作 Agent Harness。

Harness 原本有“马具、挽具”的意思。在 AI 工程语境中，可以先采用下面这个工作定义：

AI Harness 是围绕模型、上下文、工具和 Agent Loop 搭建起来的运行与控制层，让 AI 系统能够在约束条件下持续完成任务。

它可能负责：

AI Harness
├── Context Management / 上下文管理
├── Agent Loop / 任务循环
├── Tool Management / 工具管理
├── Task State / 任务状态
├── Permission / 权限控制
├── Sandbox / 沙箱环境
├── Retry / 重试与恢复
├── Logging / 日志与追踪
└── Human Approval / 人工确认

可以用一个不完全严谨、但便于理解的比喻：

LLM     = 大脑或推理能力
Agent   = 围绕目标行动的执行者
Harness = 工作环境、工具箱、工作流程和安全护栏

这三个概念不是同义词。

概念	更关注什么
LLM	如何根据输入生成内容或决策
Agent	如何围绕目标连续推进任务
Harness	如何提供工具、状态、权限和运行控制

为什么同一个模型放到不同产品里，体验可能完全不同？原因往往不只是模型差异，还包括：

• Context 是怎样组织的。
• 工具是否足够可靠。
• 工具权限是否合理。
• 失败后是否会恢复。
• 是否能保留任务状态。
• 上下文过长时如何处理。
• 结果是否经过测试和验证。

所以，AI Harness 并不是“另一个更大的模型”，也不一定是某一个固定的 SDK。它更像是把模型能力转化为可执行软件能力的一整套运行层。

十三、把一次 Coding Agent 任务完整串起来

现在把前面所有概念放回到一个真实场景中。

假设用户对 Coding Agent 说：

帮我解决这个 Spring Boot 项目启动失败的问题，并运行测试验证。

一个简化的执行过程可能是：

第一步：接收任务

用户的请求进入 AI Application。应用首先记录任务目标，并根据当前项目和用户权限建立运行环境。

这部分属于 Harness 的职责，而不是 LLM 自己完成的。

第二步：准备 Context

系统读取项目目录、项目规则、构建配置和相关错误信息，整理成模型本轮需要看到的 Context。

Context
├── 用户需求
├── 项目规则
├── 目录结构
├── 相关源代码
├── 配置文件
└── 当前错误日志

第三步：交给 LLM 分析

LLM 根据当前 Context 判断问题可能出在哪里，并生成下一步行动决策。

例如，它可能决定先读取数据库配置，或者先运行一次启动命令获取完整错误日志。

这一步产生的不是最终答案，而可能是一个 Tool Call。

第四步：调用工具

Harness 检查这个 Tool Call 是否符合参数规则和权限策略，然后执行相应工具：

读取文件
搜索代码
执行 Terminal
修改配置
运行测试

模型并没有直接获得操作系统权限。它只是提出请求，Harness 决定这个请求是否可以执行，以及如何执行。

第五步：把结果放回 Context

工具执行完成后，结果会重新进入 Context：

原有 Context
      +
刚刚执行命令得到的日志
      +
测试结果
      ↓
新的 Context

LLM 再根据新的 Context 判断下一步。

第六步：进入 Agent Loop

如果问题还没有解决，系统继续执行：

观察
 ↓
决策
 ↓
行动
 ↓
获得结果
 ↓
更新 Context
 ↓
再次观察

直到测试通过、任务达到停止条件，或者系统发现需要用户进行人工决策。

这就是一个 Coding Agent 与普通文本聊天的本质区别：它不只是在生成一段回答，而是在运行环境中连续推进任务。

十四、几个容易混淆的关系

1. LLM 不等于完整的 AI 应用

LLM 是模型层。一个完整的 AI 应用还需要用户界面、Context 组装、工具系统、权限、状态和错误处理。

2. Context 不等于 Memory

Context 是模型本轮看到的内容；Memory 是应用系统保存、并可能在之后检索回来的历史信息。

Memory
   ↓ 检索
Context
   ↓ 输入模型
LLM

3. Context Window 不等于永久记忆

Context Window 只是一次能够容纳多少信息的容量限制。它不能说明模型会永久记住这些信息。

4. Tool Calling 不等于工具已经执行

模型生成调用请求之后，还需要宿主程序进行参数校验、权限判断和实际执行。

5. MCP 不等于 Agent

MCP 主要解决外部能力如何以标准方式接入；Agent 解决的是系统如何围绕目标连续完成任务。

6. Agent 不等于无限自主

Agent 仍然需要受到工具范围、权限策略、任务状态、停止条件和人工审批的约束。

十五、重新看一次整张图

现在再回头看本文开头的架构图，就可以用下面这句话解释它：

LLM 负责推理与生成，Context 决定模型当前能看到什么，Tools 决定系统能够做什么，Agent Loop 让任务可以持续推进，而 AI Harness 负责把这些能力组织成一个可运行、可控制、可恢复的系统。

而 MCP 处在 Tools 与外部世界之间，是连接外部工具和数据能力的一种标准化方式。

这也是为什么“顶尖 AI 系统不用 LLM 了”这种说法容易造成误解。更准确的说法是：

复杂 AI 系统已经不再只是一次 LLM 调用，但模型仍然是系统中的核心能力层；真正复杂的地方，在于模型之外的 Context、Tools、Loop、State 和 Harness 如何协同工作。

十六、这个系列接下来会讲什么

第一篇只负责建立地图，后续文章会沿着同一套术语继续拆解：

1. 程序员学 AI（一）：一张图看懂 LLM、Context、Agent、MCP 和 Harness
2. 程序员学 AI（二）：LLM 到底是什么？应该知道的大模型基础概念
3. 程序员学 AI（三）：Prompt 和 Context：模型这一次到底看到了什么
4. 程序员学 AI（四）：Token、Context Window 和 Memory：AI 到底能看到什么、记住什么
5. 程序员学 AI（五）：RAG 是什么？为什么知识库不能直接塞给大模型
6. 程序员学 AI（六）：Tools 与 Tool Calling——AI 为什么可以调用外部能力
7. MCP：工具与外部世界如何标准化连接
8. AI Agent：从回答问题到完成任务
9. Agent Loop：AI 如何连续推进任务
10. AI Harness：如何把 Agent 变成可靠系统
11. Coding Agent：Codex、Claude Code、Cursor Agent 在做什么

下一篇，我们先从最底层开始：

《LLM 到底是什么？程序员应该知道的大模型基础概念》

不急着讲复杂数学，而是先回答一个更基础的问题：

大语言模型到底是什么？它和我们以前写的普通程序有什么不同？

到这里，你只需要记住整篇文章最重要的一句话：

模型提供能力，上下文提供信息，工具连接世界，循环推动任务，Harness 负责组织和控制。