发布摘要：为什么很多 AI 客服演示时很聪明，上线后却会忘事、乱调工具、越聊越笨？GitHub 开源项目《深入理解 AI Agent》用 10 章和 88 个配套实验给出了一套工程答案：Agent 不是“更会聊天的大模型”，而是 LLM、上下文、工具和验证机制共同组成的执行系统。

你花了两个月做出一个 AI 客服。

演示时，它回答流畅、态度礼貌，老板当场拍板上线。可真实用户一进来，问题马上暴露：有人只说“把三天前买的耳机退了”，它不知道先查订单；有人换个说法，它忘了刚才确认过的信息；知识库明明写着退款规则，它却搜到一段旧政策；更危险的是，它有时还会在没有确认的情况下直接调用退款接口。

团队的第一反应往往是：换个更强的模型。

但换完模型，问题可能只是从“经常出错”变成“偶尔出错”。真正缺的不是一个更聪明的聊天框，而是一套让模型看得见、记得住、做得到、能验证的工程系统。

这正是 GitHub 开源项目 bojieli/ai-agent-book 最有价值的地方。截至 2026 年 7 月 21 日，项目约有 1.33 万 Star，提供 10 章正文、88 个配套项目，其中 70 多个可独立运行，并已有 5 种语言版本。全书用一个公式贯穿始终：

Agent = LLM + 上下文 + 工具。

这不是概念包装，而是一张很实用的故障排查图。

LLM 是大脑，负责理解、规划和判断；上下文是眼睛，决定它此刻能看到什么；工具是手脚，决定它到底能做什么。模型再强，如果看不到订单状态，就只能猜；知识再全，如果没有退款接口，就只能说；工具再多，如果权限和反馈没设计好，就可能乱做。

第一坑：把所有问题都归咎于模型，其实 Agent 根本“没看见”

很多团队把业务规则、历史对话、知识库结果、几十个工具说明，一股脑塞进提示词。开始几轮还能工作，聊久以后却越来越不稳定。

项目把这种现象叫作“上下文腐化”：窗口还没满，但有效信息已经被噪声淹没。就像把员工丢进一间堆满文件的仓库，资料都在，却找不到真正需要的那一页。

书中给出一个很直观的实验结论：如果没有工具定义，Agent 不知道自己能做什么；如果没有工具执行结果，它看不到上一步发生了什么，可能反复调用同一个工具；如果没有历史消息，它会“失忆”，重新执行已经完成的步骤。

解决办法不是无限加长上下文，而是提高信息密度：

第一，稳定不变的岗位规则放在前面；第二，只按需加载当前任务需要的 Skill 和知识；第三，把大段网页、日志和搜索结果留在文件或子任务里，主 Agent 只接收结论；第四，当上下文接近阈值时，按当前任务做结构化压缩，明确“已经知道什么、还缺什么、下一步做什么”。

项目第二章的一组研究任务中，“无压缩”方案仅几次搜索就超过 128K 窗口而失败；面向当前任务的上下文压缩，则把一次约 14.8 万字符的材料压到约 1963 字符，同时保留关键事实。重点不是压得多狠，而是只保留对下一步决策有价值的信息。

第二坑：以为接上知识库就不会胡说，结果只是“搜到哪段答哪段”

传统 RAG 的流程通常是：用户提问、检索一次、把结果塞给模型、生成回答。简单问题够用，复杂问题很容易翻车。

例如用户问：“醉酒过失致人重伤，而且有盗窃前科，通常如何量刑？”这不是一次关键词搜索能解决的。它至少涉及过失致人重伤、醉酒刑事责任、前科是否构成累犯，以及不同罪名之间的关系。

项目第三章提出“智能体化 RAG”：把知识库检索变成 Agent 可以反复调用的工具。Agent 先拆问题，分别查关键事实；看到结果后判断还缺什么；再做第二轮更精准的检索；最后交叉验证并给出带依据的答案。

这就像普通搜索与专业研究员的差别。前者搜一次就交卷，后者会不断追问：“信息够了吗？有没有冲突？这条结论来自哪里？”

同样的思路也适用于用户记忆。真正有用的记忆不是保存全部聊天记录，而是提炼长期偏好、有效状态和时间关系。用户说过“我坐飞机喜欢靠窗、吃素、会员号是 12345678”，系统应该保存对未来有用的事实，而不是连当时搜索出三趟航班这种临时信息一起永久记住。

更关键的是处理冲突：旧地址和新地址谁有效？三次修改后的转账指令以哪次为准？“记得多”不是目标，能更新、能溯源、能判断时效才是目标。

第三坑：给了 Agent 一堆工具，却没有给它边界

工具让 Agent 从“会说”变成“会做”，也把风险从答错一句话放大为真实世界的错误操作。

一个客服退款 Agent 的正确闭环应该是：理解用户意图，查询订单，核对政策，必要时请求确认，执行退款，再检查返回结果并通知用户。

这里有三个容易被忽略的细节。

一是工具描述要写“什么时候用”和“什么时候不能用”，而不只是“它能做什么”。比如文件名搜索工具必须明确“不能搜索文件内容”，否则模型会把能力边界想当然。

二是工具要返回可验证结果。退款接口不能只回一个“success”，而应返回退款编号、金额、状态和预计到账时间。Agent 必须基于真实返回值回答，不能自己补全。

三是高风险操作必须分层授权。查询订单可以自动执行；发起退款要满足政策条件；超过金额阈值、修改收款账户、删除数据、对外发信等操作，应增加人工确认或独立审核。项目还特别提醒，网页、邮件、PDF 和知识库内容都可能藏有提示注入，外部资料只能作为“数据”，不能直接升级为“命令”。

所以，通用工具并不等于无限权限。读、写、审批要分开；执行环境要隔离；每次关键操作要留痕；失败后要能停止，而不是让 Agent 在错误方向上连续重试。

第四坑：上线后只看“用户觉得不错”，无法证明系统真的变好了

Agent 的输出带有随机性。同一个任务跑两次，可能走出不同路径。如果团队只靠几次演示和主观感受迭代，很容易陷入“改了提示词，感觉好像更聪明”的循环。

项目第六章用一个退款案例说明了评估方法。用户要求退掉 3 天前、金额 299 元的订单，公司规则是 7 天内可全额退款。评估不能只看最后一句话是否礼貌，而要拆成至少四项：订单号和金额是否正确、是否符合政策、是否告知到账时间和退款编号、是否编造了工具没有返回的信息。其中“幻觉”应当是直接否决项，因为一段流畅但虚假的回复，比简短却准确的回复更危险。

真正可用的评估集，还必须包含边界场景：15 天前的订单能否正确拒绝？用户声称“客服已经批准”，系统会不会轻信？工具超时后是否重复扣款？知识库出现新旧政策冲突时采用哪一版？

最后把线上失败案例脱敏后沉淀成回归测试。今天踩过的坑，明天必须自动拦住。这才是“观察、假设、实验、验证”的持续改进闭环。

普通团队怎么开始？先别做“万能助理”

如果你正在给公司上 Agent，最稳妥的路径不是一开始接入 100 个工具，而是挑一个高频、规则相对清晰、结果可验证的闭环场景。

仍以退款客服为例，可以先只做 7 天内标准退款：限定订单类型和金额范围，只开放订单查询与退款两个工具；要求退款前完成政策检查，执行后必须拿到退款编号；准备 30 到 50 个真实测试用例，覆盖正常、超期、重复退款、信息不全、接口失败和恶意提示注入；连续通过后，再逐步扩展换货、补发、优惠补偿等能力。

这套做法看起来比“接上最强模型立即全自动”慢，但它解决的是企业真正的痛点：结果是否可靠、错误是否可控、过程是否可追溯、投入是否能衡量。

《深入理解 AI Agent》最重要的启发也正在这里：模型能力会持续提升，但决定产品能否落地的，往往是模型之外的 Harness 工程——你给它什么上下文，开放什么工具，如何设置权限，怎样验证结果，又怎样从失败中积累经验。

未来真正拉开差距的，不是谁最先接入一个新模型，而是谁先把 AI 从“看起来聪明”，做成“长期可靠地把事情办完”。

---

项目信息

• 项目：bojieli/ai-agent-book《深入理解 AI Agent：设计原理与工程实践》
• 地址：https://github.com/bojieli/ai-agent-book
• 开源协议：Apache-2.0
• 核对时间：2026 年 7 月 21 日
• 项目数据会随仓库更新而变化，文中 Star 数和实验规模以核对当日项目主页为准

备选标题

1. AI Agent 为什么一上线就翻车？这个 1.3 万星项目讲透了 4 个根因
2. 从“会聊天”到“能办事”：普通团队落地 AI Agent，先过这四关
3. 10 章、88 个实验：这本开源书把 AI Agent 的工程真相讲明白了

头条推荐摘要

AI 客服演示时很聪明，上线后为什么会忘事、乱调工具、越聊越笨？一个 1.3 万星开源项目给出答案：模型只是大脑，上下文是眼睛，工具是手脚，评估才是质量闭环。本文用退款客服场景，拆解企业落地 AI Agent 最常见的四个坑。