第一次在正式项目里做 Chatbot甲方的需求单写得很简单用户输入关键词机器人返回对应答案。可真正做起来才发现所谓 Chatbot 的核心其实是一个套了对话外壳的搜索框——关键词匹配、FAQ 命中、多轮意图识别本质上都是在帮用户把一句自然语言翻译成检索词。真正让我意识到这套路走不通的是有位用户问了一句帮我查一下明天北京到上海最早的高铁几点发车系统却返回了一堆包含高铁关键词的文档链接。也是从那时候起我开始把注意力从搜索框转向 Agent 形态的联网搜索方案。这篇文章想梳理的正是 Chatbot 从搜索框演进到Agent这条完整的技术路线每一阶段解决了什么问题、带来了什么新瓶颈、有哪些可落地的选型和踩坑经验。内容覆盖 RAG、联网搜索 API、Agent 工作循环、框架选型、并发与记忆设计最后附带一个我实际搭过的搜索型 Agent 项目拆解。适合正在做对话系统、RAG 应用或者 Agent 开发的工程师参考也适合想入行 AI 应用开发、被Agent这个词绕晕的人搞明白底层逻辑。1. 搜索框时代走到头的信号用户要的是答案不是链接1.1 传统搜索框型 Chatbot的底层逻辑早期 Chatbot 的骨架就是搜索引擎那套东西把用户输入拆成关键词在倒排索引里找匹配文档用 BM25 这类相关性算法排序再把得分最高的几条答案丢给用户。我在 2019 年做的第一个客服机器人就是这样后端挂了一个 FAQ 库前端套上网关用户问怎么退款系统匹配到退款就把退款流程文档置顶返回。这套逻辑在封闭域问答里其实很稳因为 FAQ 库是人工维护的问题形态有限检索命中率自然高。但它的天花板也非常低机器不认识意图它只认识词频。用户问钱什么时候能退回来和直接问退款在 BM25 眼里是两个 query。你只能靠维护大量同义词表、写意图识别规则去补做出来的东西越来越像一个脆弱的翻译器——用户说人话系统要先把人话翻译成关键词翻译错了就全错。1.2 自然语言被关键词化的代价把自然语言压成关键词丢掉的恰恰是提问里最值钱的信息。继续拿高铁订票举例明天北京到上海最早的高铁几点发车这句话里明天决定了搜索时间范围最早决定了排序偏好几点发车才是用户真正要的答案。传统搜索框把句子切碎成北京、上海、高铁、发车检索出来的结果基本就是城市介绍、购票指南这类文档跟用户的实际诉求隔了十万八千里。后来 NLU 方案火过一阵靠意图分类加槽位填充去理解这种句子比如定义intentquery_schedule、slotfrom_city: 北京, to_city: 上海, time: 明天。这套方案在小场景里确实能用但每接入一个新业务就要重新标注数据、重新训练模型成本完全不可持续。更麻烦的是用户的语言习惯千差万别稍微换个说法意图识别就漏了。那时候我就有个强烈感受对话系统真正的瓶颈不在会话管理而在理解世界——而理解世界的前提是系统能自己去获取实时信息。1.3 大模型打开的口子答案可以生成但不能凭空大模型出来之后很多人以为搜索框终于可以退休了结果发现问题只是换了形态。LLM 本质上是一个参数化的记忆体它的知识全部来自训练语料有明确的截止日期。用户问明天北京到上海的高铁模型确实能给出一个像模像样的回答但具体到明天到底有哪些车次、几点发车它就是一本正经地编因为训练数据里根本没有明天的实时时刻表。于是业界迅速形成了第一个共识LLM 需要外部信息源光靠生成是不够的。这个阶段催生了 RAG检索增强生成也把联网搜索正式推到了 Chatbot 技术栈的核心位置上。搜索框不再是用户的入口而是变成了模型获取信息的一只手。2. 联网搜索嵌入 ChatbotRAG 成熟之后的第二个支点2.1 RAG 先解决了私域知识但没解决开放世界RAG 的经典流程很多人已经写过文档切块、向量化、召回、重排、拼进 Prompt、让 LLM 基于上下文生成。它的价值是让 Chatbot 能回答我们公司报销制度是什么这类私有知识问题而且可以随时更新知识库不需要重新训练模型。但 RAG 有个先天局限——它检索的语料库是人喂的。你要让 Chatbot 回答今天收盘的沪深指数或者某个刚发布的产品新闻如果没有人预先把这些内容采集进知识库RAG 就是无米下锅。维护一个实时更新的全网知识库成本极高对绝大多数团队来说根本不现实。这时候联网搜索 API就成了一种按需取用的外部知识源用户问了才去搜搜完立刻用用完即走不需要维护庞大语料。2.2 联网搜索 API 怎么选免费额度与实测表现很多人一上来就问免费的联网搜索 API 有哪些这确实是最实际的问题。我前后对比过 Tavily、Brave Search、Serper、SearXNG 和 Bing Web Search实测结论如下API免费额度以实测时为准返回内容适合场景Tavily每月几百次到千次级别直接返回清洗后的网页正文片段LLM 优先省去自己抓取正文的功夫Brave Search免费层每月数千次返回网页元数据、摘要对结果质量要求高自己解析正文Serper新用户有少量体验额度返回类 Google SERP 数据需要看搜索排名结构、有 SEO 需求Bing Web SearchF0 层每月千次标准搜索结果列表已有 Azure 生态想走商用链路SearXNG完全免费自部署聚合多家搜索引擎结果无预算、愿意自己运维基础设施我现在的默认选择是 Tavily原因很朴素它是专门给 LLM 应用设计的返回结果里已经过滤了导航栏、广告、Cookie 弹窗这些噪音直接给一段干净的正文摘要省掉一整套网页清洗流程。Brave 我也在用主要在需要更大免费吞吐量、或者要拿原始网页数据做二次处理的时候。SearXNG 适合团队里有运维能力、想彻底摆脱供应商配额限制的情况但自建意味着要自己解决搜索源的稳定性和结果去重问题。2.3 搜索结果不是越多越好组装与裁剪把搜索 API 接到 Chatbot 里最大的误区是搜到啥都往 Prompt 里塞。一次搜索返回五条结果每条正文按三千字算直接灌进上下文就是一万五千 token一次对话还没开始成本已经爆炸。我给的这个时间线的经验是第一轮先用标题加摘要做粗筛让 LLM 只根据 snippet 判断哪些结果真正相关第二轮才对排前二的结果做正文抽取并且只截取与查询关键词相关度最高的段落。组装的时候要给每条结果打上编号例如[来源1]、[来源2]强制 LLM 在回答中带引用。这不仅是体验问题也直接影响答案可信度——带来源的回答用户敢点进去验证不带来源的回答用户只能被迫信任。还有一个小技巧是把查询改写前置用户问那个新发布的本子怎么样这种指代不明的句子先让 LLM 结合对话历史改写成某产品 评测 最新发布再拿去调搜索 API召回质量会明显提升。3. Agent 到底比 Chatbot 多了什么闭环行动与工具编排3.1 核心差异从回答问题到完成事务聊完联网搜索终于可以进入 Agent 的正题。很多文章喜欢把 Agent 描述得很玄说它是自主智能体但这反而把概念搞模糊了。我的理解很朴素Chatbot 的职责是回答问题Agent 的职责是完成事务。两者的差别不在于模型是否聪明而在于系统有没有形成感知-决策-行动-观察的闭环。拿高铁订票场景对比就非常清楚。Chatbot 版用户问车次它回答请去 12306 查询然后对话结束剩下的活儿用户自己干。Agent 版用户提出需求Agent 调搜索工具查时刻表、调票务工具查余票、生成一个推荐方案然后继续追问需要帮你锁定这张票吗如果用户确认它就接着调用下单工具。同样是联网搜索能力前者把搜索结果当作最终答案交给用户后者把搜索结果当作决策依据去驱动下一步动作——这就是工程范式的分水岭。3.2 一次完整的 Agent 思考循环把 Agent 的黑盒拆开内部其实就是一段不断重复的循环模型根据当前上下文决定下一步动作动作可以是回答、可以是调用工具然后把工具返回的结果再次放回上下文继续决策直到任务完成。核心要点是模型本身不执行工具它只负责做计划、出参数由 Harness 里的执行器真正去调 API。def run_agent(user_query, max_steps8): messages [{role: user, content: user_query}] for step in range(max_steps): response llm.chat(messages, toolsTOOL_SCHEMAS) if not response.tool_calls: return response.content for call in response.tool_calls: result execute_tool(call.name, call.arguments) messages.append({ role: tool, tool_call_id: call.id, content: json.dumps(result, ensure_asciiFalse) }) # 继续下一轮循环 return 已达最大步骤数返回当前结果这段伪代码写出来很简单但工程里要处理的细节多到让人头秃工具返回内容太长怎么截断、调用失败要不要重试、多工具并行还是串行、模型在同一个错误上反复打转怎么办。这些都属于 Harness 的范畴不是模型本身能解决的问题。3.3 Harness 是什么Agent 的上层建筑harness 和 agent 区别这个提问我最近看到很多说明大家已经开始被工程细节绊住了。Harness 直译是束具你可以把它理解成 Agent 的舞台和后台系统工具注册表、执行循环、上下文管理、权限控制、可观测性、失败恢复这些都在 Harness 层解决。Agent 只是完成任务的那套策略逻辑它依赖 Harness 提供的脚手架才能稳定工作。用一个类比Agent 是歌手Harness 是演唱会全流程体系。歌手负责唱核心决策但灯光、音响、伴奏、安保、应急预案是体系在支撑。早期很多人以为Agent 给 LLM 加个函数调用做出来的 demo 很惊艳一上生产就崩就是因为只有歌手没有体系。现在主流框架LangGraph、Dify、自研循环本质上都是在帮你搭 Harness只是抽象层级不同。4. Agent 开发框架选型LangChain、Dify、CrewAI 与自研之间怎么权衡4.1 主流框架实测对比被问得最多的问题就是LangChain、Dify、CrewAI 哪个好。我的回答是脱离场景谈好坏都是耍流氓。三个项目我都在真实项目里跑过定位差异非常大框架定位核心抽象学习成本短板LangChain / LangGraph开发框架链、图、工具、记忆偏高抽象层多调试链路长Dify可视化应用平台工作流、知识库、插件低深度定制受限核心逻辑被平台封装CrewAI多 Agent 协作角色、任务、流程中复杂生产环境稳定性需自行加固自研工具循环定制方案自己定义的循环和协议视能力而定没有生态一切从零开始如果你要做一个需要精细控制每一步的复杂 AgentLangGraph 的状态图模型很合适它能把网络搜索、内容清洗、记忆更新这些节点变成一张可观测的图中途任意节点出错都能定位。如果你主要目标是用最短时间把产品做出来给业务方用Dify 这类平台效率最高内置的 Agent 节点、知识库、发布管理都开箱即用。CrewAI 适合任务天然能拆给多个角色并行处理的情况比如一个 Agent 负责搜资料另一个负责写总结第三个负责查重协作配置非常直观。4.2 低代码平台的边界扣子这类产品能做什么提到可视化 Agent 平台绕不开扣子Coze这一类产品。优点是零代码就能搭出带联网搜索、知识库、插件的智能体业务人员自己都能玩对快速验证想法特别友好。我也见过非技术背景的运营同学用它搭了不少好用的内部 Bot这点必须承认。但它的边界同样明显平台封装的节点很多时候不满足复杂业务需求比如自定义鉴权方案、私有化部署、细粒度的工具错误处理、与已有监控链路打通这些能力低代码平台通常要打折扣。我的选型经验是原型验证用低代码平台一天出 Demo真正要上生产、要跟存量系统集成时转回可编程框架把命运握在自己手里。4.3 Python 之外Rust 与 JVM 生态的 Agent 实践聊框架如果不聊语言生态视角是不完整的。Python 依然是 Agent 开发的主力语言光是 LangChain 和 Dify 的插件生态就已经形成了成熟网络。但最近社区里冒出来的基于 Rust 的 AI Agent并不少底层逻辑也很简单Agent 系统本质是高并发 IO 密集应用工具调用、网络请求、重试队列非常密集Rust 在这类场景下内存占用低、并发表现好、部署产物轻量对延迟敏感的业务有明显优势。JVM 生态也在跟进Spring AI、ADK for Kotlin 这类项目让 Java/Kotlin 团队不必跨语言就能接入 Agent 开发。我的判断是Agent 的核心概念循环、工具、记忆并不绑定语言选型应当优先考虑团队熟悉度和现有技术栈Python 适合快速迭代Rust 适合高并发基础设施JVM 适合企业级存量系统融合。不用为了追热点硬换语言换来换去只会让项目死得更快。5. 实战搭一个能联网搜索并沉淀知识的搜索 Agent5.1 需求与分层架构理论讲再多不如直接上手。我最近做的一个内部工具型 Agent需求很明确用户用自然语言提问Agent 自动联网搜索、筛选信息、给出带来源的总结同时能把有价值的网页正文保存成 Markdown 文件沉淀到本地知识库供后续检索复用。架构分成四层交互层负责 Web 聊天界面和 API 网关Agent 核心层维护上下文、执行循环和记忆读写工具层包含搜索工具、网页转 Markdown 工具、知识库写入工具依赖层是 LLM API、Tavily 搜索 API、向量数据库。设计上最关键的决策是搜索行为不能是每次对话必经之路要在 Agent 决策之后再触发因为多数问题本地知识库就能回答没必要白白消耗搜索配额。5.2 搜索技能的代码实现工具层我首选 Tavily理由是返回内容天然适合 LLM 阅读。代码实现简单到出乎意料import requests def web_search(query, max_results5): resp requests.post( https://api.tavily.com/search, json{ api_key: TAVILY_API_KEY, query: query, max_results: max_results, search_depth: basic, }, timeout10, ) resp.raise_for_status() data resp.json() return [ { title: item.get(title), url: item.get(url), content: item.get(content, )[:800], } for item in data.get(results, []) ]真正的秘诀在调用之前。我在这里做了一步查询改写把用户原话交给 LLM让它生成一个适合搜索引擎的关键词组合比如最近的 AI 编程工具改写为AI programming tools 2025 review。这一步直接用一次小模型调用完成几乎是所有搜索 Agent 质量提升性价比最高的改进。另外网页正文转 Markdown 这个技能我强烈建议直接采用现成工具库如 trafilatura、readability先提取主体内容再转格式比自己写正则解析 HTML 靠谱得多。现在社区里很火的Agent Skill潮流本质就是把这类可复用能力打包成独立技能让 Agent 按需加载。5.3 记忆设计本地知识库与对话上下文的配合Agent 的记忆设计是最容易被低估的模块。我的方案分两层短期记忆就是当前会话的对话历史限制在最近十轮以内超出部分做摘要压缩长期记忆是向量数据库把每次保存的 Markdown 网页按内容切成块向量化存储下次搜索时先查本地命中率高的就不再启动联网搜索。这里有个工程细节值得注意保存网页时会遇到大量内容重复的问题比如同一新闻被多个网站转载。去重策略不能只看标题我用 URL 规范化加正文哈希做双重判断。还有一个 Token 管理习惯不要在把网页正文塞进长期记忆时保留全部内容每篇只抽取与查询最相关的几个段落否则知识库会迅速变成垃圾场召回质量直线下降。5.4 并发与稳定性搜索 Agent 怎么扛流量AI Agent 怎么扛并发这个问题其实是在问三件事状态怎么隔离、外部 API 配额怎么限流、工具失败怎么恢复。我当前项目的用户量不算大但设计原则是通用的问题解法原因会话状态隔离每个用户独立 Context 对象存 Redis避免上下文串扰支持横向扩容搜索 API 配额进程内信号量 全局速率限制防止超配额被供应商熔断工具超时每次工具调用强制 10s 超时超时返回特定错误结构避免 Agent 卡在等待上打转失败重试指数退避最多三次网络抖动场景最稳的策略我还踩过一个典型的坑Agent 循环没有设置最大步数结果模型在一个失败的工具调用上反复重试直到把整个会话拖死。后来我在 Harness 里加了全局护栏——到达最大步数直接中断并返回任务未完成以下是已获取的信息这样的中间结果至少不会让用户空等。每个工具的返回值也统一成{status: ok, data: ...}和{status: error, message: ...}的结构化格式LLM 才能根据错误信息调整策略而不是在一个错误上无限循环。6. 演进过程中反复踩的坑以及我现在的应对方式6.1 时效性陷阱缓存过期与最新焦虑联网搜索最反直觉的问题之一是搜索 API 本身也可能返回过时结果。搜索引擎有自己的索引周期一个大新闻刚发布十分钟很多 API 的索引里还没有。我遇到过用户问刚刚发布的某手机型号价格搜索返回的还是旧款信息LLM 却洋洋洒洒总结了一大段。现在的应对是双保险一是在 Agent 决策环节识别时间敏感词出现最新、今天、刚刚、本周这类词就强制联网且跳过本地知识库二是在给 LLM 的工具说明里写清楚搜索结果的时效性可能延迟若干小时若用户明确要求最新信息请提示用户自行确认。有时候坦诚比硬撑更重要LLM 能承认搜索结果可能滞后反而避免了很多一本正经的胡扯。6.2 Token 黑洞搜索结果的成本控制联网搜索引入后Token 消耗会肉眼可见地暴涨这是所有搜索 Agent 都要面对的成本问题。我的实践经验是三层压缩第一层搜索结果只保留标题、URL 和内容片段全文只针对排序第一的结果做抽取第二层正文抽取后做相关性截断只保留包含查询关键词和同义词的段落其余删掉第三层对已经保存进本地知识库的页面下次直接用知识库检索结果不再重复消耗搜索配额。我还养成了一个习惯在每次搜索工具执行后记录实际消耗 Token 数输出到监控日志里。这样才能知道哪些用户 query 是 Token 消耗大头针对性地优化改写策略。成本报表不是财务同事该看的是工程师每天都要盯的——这不是抠门是让 Agent 方案可持续跑下去的基本功。6.3 工具异常与 Agent 决策失效别让模型一根筋Agent execution terminated due to error这类错误日志做 Agent 后你一定会经常看到。最初我以为所有异常都是工具代码的问题排查多了发现很多是模型决策失效工具明明返回了一个结构化错误模型却绕来绕去不肯换方案或者错误地继续使用同一个参数重试。解决思路是给模型指路。除了统一的错误结构我在工具描述里明确写了失败后该怎么办比如搜索超时后建议改查本地知识库正文抓取失败后建议只回答摘要数据。相当于预先把异常处理经验写进 Prompt 工具说明模型在大多数情况下会沿着预设好的路径走。另外关键节点设置人工复核开关也很重要——涉及花钱、发消息这类高影响动作Agent 生成的参数必须先经过用户确认再执行这个原则任何时候都不能破。6.4 联网之后的边界与安全别让输入变成指令最后说一个很多人忽略但极其重要的环节当 Agent 开始联网搜索它读到的网页内容就不再只是数据也可能是指令。恶意网页完全可以在正文里藏一段提示词注入诱导 LLM 改变行为、输出错误信息。联网搜索能力的每一步都在放大模型的攻击面防护必须同步跟上。我的基本防护原则有三条一是给工具加白名单搜索域、URL 校验、下载大小限制这些都在工具层做二是对检索到的网页内容做净化凡是异常格式、超长文本、可疑脚本片段都过滤掉三是输出内容增加审核环节尤其对涉及实体操作的结果宁可牺牲一点流畅度也要保证安全边界。做 Agent 越深入越会发现模型的自由度是需要用工程的约束来换的。自己一路把项目从搜索框改造成 Agent最大的一点体会是这个演进没有终点每一种新能力都会带出一整片新的工程问题。搜索框时代我们解决的是怎么让用户听话地把需求翻译成关键词Agent 时代我们解决的是怎么让模型在一个受控的工程框架里安全地替用户把事情办了。如果你正准备开始做一个联网搜索 Chatbot我的建议是不要一上来就上 Agent——先把 RAG 和搜索 API 的链路跑通再逐步加入工具调用和规划循环每一步踩的坑都亲自记录下来这比追新框架有价值得多。