一个Agent烧掉200美元，教会我的6件事

前两天看到一篇技术博客，作者是 @sairahul1。

他讲了一个真实故事。

一个AI Agent在服务器上跑了整整六个小时，不断调用OpenAI的API，完全没有停下来的意思。所有监控面板都显示一切正常。直到第二天早上，账单到了。

200美元。

不是因为系统崩了，是因为没有人给它设一个终止条件。

我觉得这个故事太真实了。

坦率的讲，大多数人在学AI工程的时候，方向是反的。装个库，跟个教程，调个API，跑通了，觉得嗯我在进步。然后有一天，东西崩了，崩得你一脸莫名其妙。你开始瞎改参数，改到它不崩为止。

这不是工程。这是在键盘上祈祷。

原作者在这篇文章里拆了6个核心概念。不是那种「带你入门AI」的泛泛之谈，而是你真正要把AI系统跑在生产环境里，绕不开的那几个硬骨头。

我花了点时间读完之后加了自己的理解，下面跟你聊聊。

一句话说清楚这整件事

不管一个AI系统看起来多复杂，它拆开了就是四样东西。

Memory (RAG) + Thinking (LLM + Tokens) + Actions (Agents) + Measurement (Evals)

记忆加思考加行动加度量。

记忆，RAG加向量，系统知道什么。

思考，大模型加Token加上下文窗口，系统怎么推理。

行动，Agent循环加工具，系统能做什么。

度量，Evals评测，你怎么知道它有没有在好好干活。

然后还有一个东西把这四样粘在一起。

上下文工程。

就这一句话，把整个领域框住了。下面每个概念，都是在拆这句话里面每个词到底什么意思。

Token和上下文窗口，所有翻车的根源

大模型不读字，它读Token。

Token就是把文字切成小块。engineering是一个Token，unbelievable是两个Token。空格和标点也算。

每个模型都有一个上下文窗口，一个硬上限。Claude 20万Token，GPT-5可以到40万。

你可以把它想象成会议室里的白板。模型能处理的，永远是白板上当前写着的那些东西。白板写满了，旧的东西被擦掉。模型没有变笨，它只是看不到之前的信息了。

为什么生产环境里这个最容易翻车。

Token要钱，每次API调用都按输入输出Token计费。长对话很快把窗口填满。窗口满了之后，最早放进去的那些指令，被悄悄从注意力里挤掉了。

作者举了个例子。一个团队做客服机器人，每次都把用户过去12个月的全部聊天记录塞进上下文。在测试环境里，5轮对话，完美。上线之后，50轮对话，机器人开始无视自己的系统指令。

指令还在。只是被8万Token的聊天记录活埋了。

解决方案不是换一个更好的模型。是把老对话定期摘要掉，腾出空间。

我觉得这里有一个特别扎心的真相。

大多数所谓的提示词工程失败，其实都是Token和上下文窗口的问题。工程师在骂提示词，但真正的原因是他那条关键指令埋在500行上下文的第三行，模型早就不看那里了。

说实话，我自己写prompt的时候也经常犯这个毛病。恨不得把所有要求都写进去，结果越写越长，模型反而抓不住重点。

向量检索，让相似的东西能在数学上找到

向量这个东西其实不玄。就是把一段文字的意思转成一串数字。意思越接近，数字越靠近。

它解决的问题很具体。你有五万个文档，用户问了一个问题，你需要找出最相关的三个。但是不可能每次都把五万个全读一遍。

关键词搜索在这里会翻车。

文档里写的是汽车，用户问的是车子，关键词搜不到。不是答案不存在，是字没对上。

向量检索的逻辑不一样。一个向量模型把文字转成向量，意思相近的文字，向量在数学空间里天然挨得近。汽车和车子，近。汽车和光合作用，远。

具体怎么做呢。每个文档先转成向量存起来。用户的问题也转成向量。系统找出离得最近的那几个向量。这些就是你要的相关文档。

这不是什么玄学，就是几何。相似度是可以算出来的数学量。

生产环境里这个东西用在哪些地方呢。文档系统的语义搜索、相似产品推荐、RAG的检索环节、Agent的记忆模块。

RAG，让模型知道你的数据，但不用重新训练它

RAG的核心理念很简单。不用把模型焊在你的数据上重新训练，而是在它需要回答问题的那个时刻，把你相关的数据取出来，喂给它当参考。

大模型知道很多事，但它不知道你的东西。你公司内部的文档、产品数据库、客服记录，这些都没在它的训练集里。

两条路。要么把模型在你的数据上重新训练一遍，贵、慢，而且训完当天就过时了。要么在它要用的时候，把数据递到它面前。RAG走的是第二条路。

分三步走。

检索，用户问题转成向量，去向量数据库里找到最相似的几个文档，取Top 3到5个。

增强，把取出来的内容塞到模型的上下文里，提示词变成了「用这些资料，回答这个问题」。

生成，模型基于你的真实数据回答，而不是凭空编。

RAG在哪容易翻车呢。

检索质量差，答案必然差。文档切块切得太粗暴，把答案跟它的上下文切开了。检索什么都没找到，模型还是得硬着头皮编。

作者讲了一个很典型的翻车案例。一个团队给一本500页的技术手册做内部知识助手。演示的时候完美，上线之后回答含糊，有时候干脆是错的。

问题出在切块大小。他们按原始字数把手册切成1000个Token一块。表格被切在半行，分步操作被切在半步。检索能找到大概的区域，但找不到真正的答案。

把块缩小一半，加上重叠，百分之八十的问题一夜之间修好了。

我读到这的时候，想起自己之前折腾RAG的那些坑。每次答不对我就去改提示词，越改越长，效果也没好多少。真正该改的是检索那一步。模型不是神，你喂它什么它就只能基于什么回答。

Agent循环，在烧钱之前你该知道的东西

普通的大模型调用是无状态的。你问，它答，结束。

Agent是有状态的。它不停地在做一个循环。收到目标，决定下一步做什么，执行，看到结果，基于结果再决定下一步，直到目标完成。

工具就是Agent的手。没有工具的LLM只能回你一段话。有了工具的Agent，能搜网页、读文件、写代码、调API，任何你定义的动作它都能触发。

三个新手最容易栽的坑。

第一，不加终止条件，Agent会一直跑下去。步数上限、时间限制、目标判断，三样至少得有一。

第二，工具不是越多越好。太多了模型反而不知道该用哪个。

第三，工具执行出错必须有处理逻辑。一个静默失败，Agent会自信地给你产一堆垃圾。

回到开头那个200美元的故事。那个Agent没有最大步数限制。它的目标是研究一个话题然后出总结。其中一个搜索工具返回了空结果。Agent不知道该怎么办，继续搜，继续生成中间总结，每一次中间总结又触发新的搜索。六个小时，847次LLM调用，210万Token。最后产出一个看起来像模像样但其实在原地转圈的总结。还有一张200美元的账单。

修好它就加了三行代码。一个最大步数计数器，一个空结果的处理逻辑，一个低置信度时的上报路径。现在同一个Agent平均12次调用以内就完事了。

我觉得这里有一个挺重要的判断。

大部分Agent出问题，不是因为模型不行，而是因为工程师把循环当成了一个能自我管理的东西。

它不是的。

护栏、终止条件、错误处理，不是出了第一次事故之后才加，是从第一天就该焊进去的。

Evals评测，你唯一知道改好了还是改坏了的方法

Evals这个东西，大多数教程都不讲，因为它不酷。

但它恰恰是把做Demo的和做生产系统的人分开的那条线。

没有Evals的时候，你改了一版提示词，换了检索逻辑，切到了新模型。效果变好了吗。你不知道。你可以手动测几个例子，但那只是感觉，不是证据。

Evals长什么样呢。

一份金标准数据集，25到50个真实的输入和它们对应的正确输出，覆盖主要使用场景，再加5个已知的刁钻边界情况。

能用是或否回答的指标就尽量用。RAG检索到了正确的文档吗，是或否。Agent无错误完成任务了吗，是或否。回答里包含了必要信息吗，是或否。

然后追踪聚合分数的变化。检索准确率89%，改完之后84%，退步了，找到问题。任务完成率76%，新版Agent到了81%，进步确认。

作者说的一个点我特别认同。

「回复质量3.7分」这种打分，没办法告诉你接下来该干什么。

「检索到正确文档的概率是84%，」这个数字能精确告诉你哪里出了问题，一个改动提了多少。

一个没有Evals的AI系统不是产品，是一个你不敢放心改的Demo。

说实话，我自己之前也是Demo心态，调完觉得差不多就扔那了。现在回头看，那些我觉得「差不多」的系统，其实差得挺多的。

上下文工程，比提示词工程更重要的那件事

上下文工程，就是决定什么东西进模型的上下文窗口、怎么排、什么东西扔掉的这门手艺。

这里有一个让很多人不舒服的判断。

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

一个中等质量的提示词，放在精心整理的上下文里，性能超过一个精雕细琢的提示词被埋在噪音里。每次都这样。

但大多数团队的精力分配是反的。八成时间花在提示词上，上下文几乎不管。

天真做法是这样的。什么都塞进去。所有历史记录，所有检索到的文档，每个工具的描述，系统提示词，用户消息，来者不拒。然后模型搞不清楚到底什么东西最重要。

学术上这叫「lost in the middle」，埋在长上下文中间的信息，被模型用到的概率大幅下降。

上下文工程实际上是五件事。

筛选，这个具体决策需要哪些文档、哪些事实、哪些历史。

压缩，更早的对话能不能做摘要，省出Token。

排序，关键指令放在开头和结尾，不是中间。

剪枝，什么东西删掉不影响输出质量。

结构，标题、分隔符、标注段落，这些影响模型引用信息的可靠程度。

一个实际的场景。一个Agent跑了45分钟，积累了8万Token的对话历史，窗口总量是12.8万。你不想让它跑到后面把最初的指令和目标忘了。

上下文工程做的事就是，把更早的工具输出压缩，把之前的推理摘要一下，让任务定义在整个会话里始终保持显眼。

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

上下文工程是造一个环境，让这些指令真的被遵守。

这6个概念怎么拼成一个系统

记忆，RAG加向量，系统知道什么。

思考，大模型加Token加上下文窗口，系统怎么用这些知识推理。

行动，Agent循环加工具，系统能做什么。

度量，Evals，你怎么知道它在工作。

黏合剂，上下文工程，决定上面四个环节之间什么信息流过去、什么被截住。

一个简单的聊天机器人，只需要思考。

一个客服Agent，需要记忆加思考加行动。

一个真正能上线的生产系统，必须加上度量。

一个请求走一遍完整流程是这样的。用户提问，上下文工程先决定哪些东西该进窗口。向量检索取出相关记忆。Token决定了窗口里能装多少。大模型基于这些信息做推理。Agent循环判断还需不需要更多的信息。Evals衡量最终的输出到底对不对。

从哪开始

你不用一口气把六个都啃完。

先从Token和上下文窗口开始，它影响你构建的每一样东西。

需要语义搜索和记忆的时候，加向量检索。

需要把模型接在你自己的数据上，学RAG。

需要自动化的时候，学Agent循环。

准备上线之前，把Evals焊进去。

其他东西都顺手了之后，上下文工程会自然变成你的直觉。

这个顺序不是随便排的。每一个概念都是学下一个的垫脚石。

最后想说的

大部分在生产环境里翻车的团队，翻的不是模型不行，也不是库选错了。

翻的是这六个概念里跳了某一个。

Agent无限循环，因为没人想过要加终止条件。

RAG答案乱编，因为没人去量过检索到底准不准。

提示词在长会话里失效，因为没人理解上下文窗口是怎么被填满的。

这些问题拆开看，一点都不高大上。

就是基本功，裹了一层技术黑话的外衣。

工具每半年换一茬，但这六个概念是工具底层不变的东西。搞清楚它们，下一个新工具出来的时候，你不会懵。

更重要的是，你再也不会一觉醒来，发现账单上多了200美元。

---

以上，觉得有收获，点个赞、在看、转发支持一下；想不错过更新，记得星标⭐。下次见。
搜索公众号:"知悟之旅"关注我看更多

本文翻译并改编自 @sairahul1 的 「6 AI Concepts You Must Master to Build Production-Ready AI Systems」，加入个人理解和中文语境下的解读。原文写得很好，推荐有条件的读者去看原版。