我看到一张 $200 的账单在一夜之间出现在 AWS 账户上。
不是因为系统崩溃。
一个 Agent 在没有任何停止条件的情况下循环运行了六个小时，每次迭代都在调用 OpenAI API。
所有监控面板都显示它运行正常。
直到早上账单出现，才有人注意到。
这就是在你构建 AI 系统时，却并不理解它们实际工作原理时会发生的事。
大多数人学 AI 工程学的方式是反的。
安装一个库。跟着教程走。调用一个 API。让某个东西跑起来。感觉有进展了。
然后某个东西以毫无道理的方式出问题了。
他们随机改一些数字，直到问题消失。
那不是工程学。那只是带着键盘的希望。
以下是解决这个问题的 6 个概念。
一句话概括一切
每个 AI 系统，无论多复杂，都只是：
记忆 (RAG) + 思考 (LLM + Token) + 行动 (Agents) + 衡量 (Evals)
……通过 上下文工程 (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 行上下文中的第三行，而模型已经不再对它加权了。
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. 评估 (Evals)
评估是你如何知道你的 AI 系统是否实际有效——以及一个改动是让它变好了还是变坏了。
这是大多数教程跳过的概念，因为它不够光鲜。
但它也是区分构建演示的工程师和构建生产系统的工程师的分水岭。
没有评估的问题：
你改了你的提示词。更新了你的检索逻辑。切换到了更新的模型。
它变好了吗？
你不知道。你可以手动检查几个例子——但那是一种感觉，而不是证据。
评估实际是什么样的：
→ 一个黄金数据集：25-50 个真实输入，带有已知的正确输出，覆盖主要用例加上 5 个已知的棘手边界情况
→ 尽可能使用二进制指标：
— RAG 系统是否检索到了正确的文档？是/否
— Agent 是否没有错误地完成？是/否
— 回复是否包含了所需信息？是/否
→ 随时间追踪的聚合分数：
— 检索准确率：89% → 做了改动 → 84%。回归被发现。
— 任务完成率：76% → 新 Agent 版本 → 81%。改进得到确认。
评估周期：
部署 → 用评估衡量 → 发现失败 → 将失败加入黄金数据集 → 修复 → 再次运行评估 → 比较分数 → 只有数字改善时才发布
实话实说：
“有用度：3.7/5” 告诉你的信息毫无可操作性。
“正确检索到文档的比例：84%” 精确地告诉了你问题在哪里以及修复改进了多少。
一个没有评估的 AI 系统不是一个产品。
它是一个你无法自信地改动的演示。
6. 上下文工程
这是一门学科，决定究竟什么信息进入模型的上下文窗口、如何结构化、以及什么被排除在外。
这里有一个让人不舒服的观点：
上下文工程比提示词工程更重要。
在精心策划的上下文中，一个平庸的提示词，每次都能击败一个埋藏在噪音中的绝妙提示词——每一次。
大多数团队将 80% 的优化精力花在提示词上，而几乎不花在上下文上。
结果反映了这一点。
天真的方法会失败：
包括一切。所有历史。所有检索到的文档。每一个工具描述。系统提示。用户消息。全部。
这种失败有一个一致的原因：模型对什么最重要感到困惑。
有一个被记录在案的现象叫“迷失在中间”——深埋在长上下文中的信息不太可能被使用。
上下文工程实际涉及什么：
→ 选择：这个特定决策需要哪些文档、事实或历史？
→ 压缩：对话中较早的部分能否被总结以节省 token？
→ 排序：关键的指令应放在开头和结尾——而不是中间
→ 修剪：什么可以被移除而不影响输出质量？
→ 结构：标题、分隔符、标记的部分会影响模型可靠地使用信息的方式
一个实际例子：
一个 Agent 已经运行了 45 分钟。它累积了 80,000 个 token 的对话历史。它的窗口是 128,000。
你不想丢失最初的目标和约束，即使历史填充了窗口。
上下文工程：压缩较早的工具输出，总结较早的推理，在对话过程中保持任务定义的突出地位。
提示词工程是写出好的指令。
上下文工程是构建一个让这些指令真正被遵循的环境。
这 6 个概念如何形成一个系统
记忆 → RAG + 嵌入 (系统知道什么)
思考 → LLM + Token + 上下文窗口 (系统如何利用所知进行推理)
行动 → Agent 循环 + 工具 (系统能在世界中做什么)
衡量 → 评估 (你如何知道它在正常工作)
黏合剂 → 上下文工程 (决定上述所有部分之间流动什么)
一个简单的聊天机器人只有思考。
一个客户支持 Agent 是记忆 + 思考 + 行动。
一个可靠的生产系统会加入衡量。
复杂性在于这些部分连接得有多好。
任意单个请求的流程：
用户问题
→ 上下文工程决定包含什么
→ 嵌入检索相关的记忆 (RAG)
→ Token 决定多少信息能放进窗口
→ LLM 对组装好的上下文进行推理
→ Agent 循环决定是否需要更多信息
→ 评估衡量输出是否实际正确
从哪里开始
你不需要一下子掌握所有六个。
→ 从 token 和上下文窗口开始——它们影响你构建的一切 → 当需要语义搜索或记忆时，加入嵌入
→ 当需要将模型基于你自己的数据时，学习 RAG
→ 当需要自动化时，学习 Agent 循环
→ 在将任何东西部署到生产之前，加入评估
→ 当其他一切变得直观时，应用上下文工程
这个顺序不是随意的。
每个概念让下一个概念变得可学。
最后的真心话
大多数在生产中与 AI 苦苦挣扎的团队，并不是因为用错了模型或用错了库。
他们挣扎是因为跳过了这六个概念中的某一个。
Agent 永远循环，因为没有考虑停止条件。
RAG 答案错误，因为没有衡量检索。
提示词在长期会话中失效，因为没有人理解上下文窗口是如何填满的。
这些不是复杂的问题。
它们是基本问题，只是用技术词汇包装了起来。
工具每六个月变一次。
这六个概念是工具的工作原理。
学会这些概念，你就再也不会被新工具搞糊涂了。
更重要的是——你再也不会花 $200 看着一个 Agent 整夜循环，却不知道哪里出了问题。
如果这篇文章有用：
→ 转发，分享给你认识的每一位 AI 工程师
→ 关注 @sairahul1 获取更多这样的系统解析
→ 收藏它——下次生产环境出问题时你会回来参考的
我写关于 AI、产品构建以及在你睡觉时依然运转的系统的文章。
