AI Agent烧钱200美元：6个血泪教训
几天前读到一篇技术博客，作者讲了一个真实的实践教训：一个AI Agent在服务器上连续运行了整整六个小时，不停地在调用OpenAI API，完全没有停下来的迹象。所有监控面板都显示一切正常。直到第二天早上，账单到了——200美元。不是系统崩溃了，而是因为没人给它设定一个终止条件。
这个案例非常贴合实际。老实说，大多数人在学习AI工程时，方向搞反了：装个库、跟着教程跑、调通API，跑通了就觉得自己在进步。然后有一天，系统彻底崩了，让你完全摸不着头脑。接下来就是胡乱调整参数，改到它不崩为止。这不是工程，这是在键盘前祈祷。
那篇博客解析了6个核心概念，不是那种“带你入门AI”的空泛内容，而是真正把AI系统部署到生产环境时必须啃下的硬核知识。下面梳理一下我的理解。
一句话讲透整个框架
无论一个AI系统看起来多复杂，拆解下来就是四样组件：记忆、思考、行动、度量。具体来说，记忆是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美元。