构建可靠AI系统的六大核心概念

我目睹了一笔 200 美元的账单在一夜之间出现在一个 AWS 账户上。

不是系统崩溃了。

一个 Agent 运行了六个小时的循环，没有停止条件，每次迭代都调用 OpenAI API。

每个监控仪表板都显示它很健康。

直到早上账单出现，才有人注意到。

这就是你在不了解 AI 系统实际工作原理的情况下构建它们时会发生的事情。

大多数人是倒着学 AI 工程的。

安装一个库。跟着教程走。调用 API。让东西跑起来。感觉像是在进步。

然后，某件事以一种莫名其妙的方式崩溃了。

他们随机调整参数，直到它停止工作。

那不是工程学。那是带着键盘的希望。

以下是解决这个问题的 6 个概念。

一句话解释一切

每个 AI 系统，无论多复杂，都只是：

记忆 (RAG) + 思考 (LLM + Token) + 行动 (Agent) + 衡量 (Eval)

...通过上下文工程 (Context Engineering) 组装起来。

这就是整个领域。

以下所有内容只是具体解释每个部分到底意味着什么。

1. Token 与上下文窗口

LLM 不读取单词。它们读取称为 Token 的块。

"engineering" → 1 个 Token

"unbelievable" → 2 个 Token 空格和标点符号也算在内。

每个模型都有一个上下文窗口——它一次能容纳的 Token 数量的硬性限制。

→ Claude：200,000 个 Token

→ GPT-5：400,000 个 Token

把它想象成会议室里的一个白板。

模型只处理当前在白板上的内容。

当白板满了，旧的笔记就会被擦掉，腾出空间。

模型不会失去思考能力，只是失去了对早期信息的访问。

为什么这会让生产系统出问题：

→ Token 需要花钱——每次 API 调用都按输入和输出 Token 计费

→ 长聊天记录会迅速填满窗口

→ 当上下文满了，早期的指令会被悄无声息地丢弃

→ 什么进入上下文是一个工程决策，而不是默认行为

证明这一点的失败案例：

一个团队构建了一个客户支持 Agent，每次请求都带上完整的 12 个月聊天记录作为上下文。

在测试中，只有 5 次交互，效果很好。

在生产环境中，经过 50 次交互后，Agent 开始忽略它自己的系统提示。

指令仍然在那里。

但它们被埋在了 80,000 Token 的对话历史下面。

模型实际上已经停止关注它们了。

解决方法不是换一个更好的模型。

而是汇总较早的历史记录，让窗口保持专注。

令人不安的真相：

大多数 提示词工程失败 实际上是 Token 和上下文窗口失败的伪装。

工程师责怪提示词，而真正的问题是关键指令位于一个 500 行上下文的第 3 行，而模型已经停止对其加权。

2. 嵌入与向量搜索

嵌入将含义转化为数字，这样 相似性 就可以用数学方式计算。

它们解决的问题：

你有 50,000 份文档。用户问了一个问题。你需要最相关的 3 份——但不需要每次都阅读全部 50,000 份。

关键词搜索在这里会失败。

如果文档说的是 automobile，而用户问的是 cars，关键词搜索会错过它。

不是因为答案不在那里。而是因为词语不匹配。

嵌入用不同的方式解决这个问题。

嵌入模型将文本转换为一个向量——一个在数学空间中代表含义的数字列表。

语义相似的文本 → 数值上相似的向量。

"car" 和 "automobile" → 离得很近

"car" 和 "photosynthesis" → 离得很远

向量搜索实际如何工作：

每个文档都被转换为一个向量并存储

用户的提问也被转换为一个向量

系统找到离提问向量最近的已存储向量

这些就是最相关的文档

这不是近似的魔法。这是几何学。

相似性是一个你可以计算的实际数学属性。

这在生产环境中出现在哪里：

→ 任何文档系统中的语义搜索

→ 查找相似产品、文章、用户资料

→ RAG 中的检索步骤（下一个概念）

→ AI Agent 中的记忆

3. RAG（检索增强生成）

不是在你的数据上训练模型，而是在查询时检索相关数据，并将其作为上下文提供给模型。

RAG 解决的问题：

LLM 知道很多。但它们不知道你的数据。

你公司的内部文档。你的产品数据库。你的客户支持历史。

这些都不在训练集中。

有两种选择：在你的数据上训练一个模型（昂贵、缓慢、立即过时），或者在模型恰好需要的时候把你的数据给它。

RAG 是第二种选择，以系统化的方式实现。

三步流水线：

→ 检索：

问题变成向量 → 向量数据库找到最相似的已存储文档 → 检索到前 3-5 个块

→ 增强：

检索到的文档被添加到模型的上下文中 → 提示变成 "使用这个上下文，回答这个问题"

→ 生成：

模型根据你的实际数据给出答案——而不是幻觉

RAG 在哪崩溃：

→ 糟糕的检索 = 糟糕的答案。模型只能处理它收到的内容

→ 糟糕的分块把答案和上下文分开了

→ 如果检索没有找到有用的东西，模型仍然可能产生幻觉

一个真实的 RAG 失败案例：

一个团队为一本 500 页的技术手册构建了一个内部知识助手。

在演示中完美运行。在生产环境中，答案含糊不清，有时是错误的。

问题：块大小。

他们按原始字符数将手册分割成 1,000 个 Token 的块。

表格在行中间被分割。分步说明在步骤中间被分割。

检索找到了正确的总体区域——但错过了实际答案。

将块大小减半并添加重叠部分，一夜之间解决了 80% 的问题。

尖锐的观点：

当你的检索很差时，RAG 被高估了。

LLM 无法修复糟糕的检索。它只能围绕它产生幻觉。

如果你看到错误的答案，停止调整你的提示。

开始衡量你的检索精度。

答案就在那里。

4. Agent 循环

Agent 通过反复选择动作、执行动作、观察结果并决定下一步做什么来工作——直到任务完成。

一个常规的 LLM 调用是无状态的。你问，它答，结束。

一个 Agent 是有状态的。它行动、观察、决定、重复。

用通俗的话解释这个循环：

接收一个目标

决定下一个动作

执行它——搜索、编码、读取文件

观察结果

根据学到的东西决定下一个动作

重复直到目标完成

返回最终答案

工具是 Agent 力量的来源。

没有工具，LLM 只能回复文本。

有了工具，它可以搜索网络、读取文件、编写代码、调用 API、触发你定义的任何动作。

初学者总是搞错的三件事：

→ 没有停止条件的 Agent 会永远运行下去。你必须定义何时停止——步骤限制、时间限制或目标条件

→ 更多工具 ≠ 更好性能。太多工具会让模型混淆该用哪个

→ 工具错误需要显式处理。一个静默失败会让 Agent 自信地产生垃圾

那笔 200 美元的隔夜失败，详细经过：

该 Agent 没有最大步骤计数。它的目标：研究一个主题并生成总结。

它其中一个网络搜索工具返回了空结果。

Agent 不知道如何停止。

它不停地搜索、重试、生成中间总结——每一次都触发另一次搜索。

六小时后：847 次 LLM 调用。消耗了 210 万个 Token。一份看起来连贯但完全循环的总结。一张 200 美元的账单。

修复方法是三行代码：一个最大步骤计数器，一个针对空结果的显式处理器，一个在置信度低时的上报路径。

同样的 Agent 现在平均在 12 次调用内完成。

你需要听到的观点：

大多数 Agent 失败不是因为模型不好——而是因为工程师把这个循环当成是自我管理的。

它不是。

护栏、停止条件、错误处理器——从一开始就构建进去，而不是在第一次事故后添加。

5. 评估 (Eval)

Eval 是让你知道你的 AI 系统是否真的在工作——以及一个改动是让它变得更好还是更差的方法。

这是大多数教程跳过的概念，因为它不吸引人。

这也是区分构建演示的工程师和构建生产系统的工程师的东西。

没有 Eval 的问题：

你修改了提示词。更新了检索逻辑。换了一个更新的模型。

它变好了吗？

你不知道。你可以手动检查几个例子——但那是一种感觉，不是证据。

Eval 实际上是什么样子的：

→ 一个黄金数据集：25-50 个带有已知正确输出的真实输入，涵盖主要用例以及 5 个已知的棘手边缘情况

→ 尽可能使用二元指标：

— RAG 系统检索到了正确的文档吗？是/否

— Agent 完成时没有错误吗？是/否

— 响应是否包含了所需的信息？是/否

→ 随时间追踪的聚合分数：

— 检索准确率：89% → 做了改动 → 84%。发现回归。

— 任务完成率：76% → 新 Agent 版本 → 81%。确认改进。

Eval 周期：

部署 → 用 Eval 衡量 → 发现失败 → 将失败案例加入黄金数据集 → 修复 → 再次运行 Eval → 比较分数 → 仅在数字改进后才发布

实话实说：

"帮助度：3.7/5" 告诉你没有可操作的信息。

"正确文档的检索率：84% 的时间" 准确告诉你问题在哪里，以及修复改进了多少。

一个没有 Eval 的 AI 系统不是一个产品。

它是一个你无法自信修改的演示。

6. 上下文工程

这是一门决定什么信息进入模型上下文窗口、如何组织、以及什么被排除在外的学科。

以下是让人不舒服的观点：

上下文工程比提示词工程更重要。

一个在精心策划的上下文中的平庸提示，其表现总是优于一个埋没在噪音中的出色提示——每次都是。

大多数团队把 80% 的优化努力花在提示词上，而几乎不花在上下文上。

结果反映了这一点。

天真的方法会失败：

包括所有东西。所有历史。所有检索到的文档。所有工具描述。系统提示。用户消息。全部包括。

这种方法因为一个一致的原因而失败：模型对什么最重要感到困惑。

有一个被记录在案的现象叫做 "迷失在中间"——深埋在长上下文中的信息不太可能被使用。

上下文工程实际涉及的内容：

→ 选择：这个特定决策需要哪些文档、事实或历史？

→ 压缩：能否总结对话的较旧部分以节省 Token？

→ 排序：关键指令应该放在开头和结尾——而不是中间

→ 剪枝：哪些内容可以在不影响输出质量的情况下移除？

→ 结构化：标题、分隔符、带标签的章节会影响模型可靠地使用信息的方式

一个实际例子：

一个 Agent 已经运行了 45 分钟。它积累了 80,000 个 Token 的对话历史。它的窗口是 128,000 个 Token。

你不想失去最初的目标和约束，即使历史记录填满了窗口。

上下文工程：压缩较早的工具输出，总结较早的推理，在整个会话过程中保持任务定义的突出地位。

提示词工程是编写好的指令。

上下文工程是构建一个环境，使这些指令被实际遵循。

这 6 个概念如何形成一个系统

记忆 → RAG + 嵌入 (系统知道什么)

思考 → LLM + Token + 上下文窗口 (系统如何用它知道的东西推理)

行动 → Agent 循环 + 工具 (系统能在世界中做什么)

衡量 → Eval (你如何知道它在工作)

粘合剂 → 上下文工程 (决定上述所有组件之间流动什么)

一个简单的聊天机器人只是 思考。

一个客户支持 Agent 是 记忆 + 思考 + 行动。

一个可靠的生产系统增加了 衡量。

复杂性在于这些部分连接得有多好。

任何单个请求的流程：

用户提问

→ 上下文工程决定包含什么

→ 嵌入检索相关的记忆 (RAG)

→ Token 决定多少能放进窗口

→ LLM 对组装好的上下文进行推理

→ Agent 循环决定是否需要更多信息

→ Eval 衡量输出是否正确

从哪里开始

你不需要一次性掌握所有六个概念。

→ 从 Token 和上下文窗口开始——它们影响你构建的一切 → 当需要语义搜索或记忆时，添加嵌入

→ 当需要让模型扎根于你自己的数据时，学习 RAG

→ 当需要自动化时，学习 Agent 循环

→ 在将任何东西发布到生产环境之前，添加 Eval

→ 当其他一切都变得直观时，应用上下文工程

这个顺序不是随意的。

每个概念都让下一个概念变得可学。

诚实的最终结论

大多数在生产环境中与 AI 作斗争的团队，问题不在于错误的模型或错误的库。

他们挣扎是因为跳过了这六个概念中的一个。

Agent 永远循环，因为没人考虑停止条件。

RAG 答案是错的，因为没人衡量检索。

提示词在长时间会话中失效，因为没人理解上下文窗口是如何填满的。

这些不是复杂的问题。

它们是基本问题，只是用技术词汇包装了起来。

工具每六个月变一次。

这六个概念是工具的工作原理。

学会了这些概念，你就再也不会被一个新工具弄糊涂了。

更重要的是——你再也不会花 200 美元看着一个 Agent 整夜循环，想知道哪里出了问题。

• 原文链接： x.com/sairahul1/status/2...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～