企业官网建设流程全解析

前两天给人演示某本地知识库助手，它对着一堆内部产品资料有问必答，连几十页的服务条款都能引用到具体章节。演示到一半，有人随口问了句“最近某品牌发布的新手机支持哪些功能”，屋里安静了三秒——它答得流畅，说的却是半年前旧旗舰的参数，还自信补了一句“以上信息以官方发布为准”。这问题其实不怪模型，本地知识库的检索源是有边界的。我花了两周给Agent接入了网络搜索，让它查内部文档之外也能上网冲浪。这篇把改造思路、代码骨架和踩过的坑完整记录下来，给同样在做AI应用开发、被“知识库答不上最新热点”困扰的朋友做个参考。

1. 本地知识库为什么总在“最新热点”上翻车：根子不在模型，在检索源

1.1 “过时”是三件事叠在一起

很多人以为知识库答不上新问题是因为模型不够聪明，换个更强的大模型就能解决。但实际拆开看，“过时”这件事至少叠了三层：

第一层是文档时间。你灌进知识库的资料是什么时候写的，回答的天花板就是什么时候。内部产品手册如果只更新到一年前，那问今年的产品线，它自然翻不到。第二层是索引快照。向量库和倒排索引是在构建那一刻固定的，构建完之后，就算源站出现了新文章，检索阶段也完全看不到这些内容。第三层是模型先验。即便知识库检索到了相关信息，模型本身的训练语料也有截止时间，超出截止时间的事实，它并不“知道”，只能靠相邻概念去推测。

做个简单的类比：本地知识库像一家只进过一批报纸的图书馆，管理员再聪明，也翻不到馆里没收进来的报纸。你问“今天发生了什么大事”，他只能把昨天的旧报纸念给你。这不是管理员笨，是馆藏有边界。

我最初也盯着RAG链路调了很久，尝试了不同分块策略、换过重排序模型，结果发现这些优化只能让旧书被“翻得更准”，翻不到的书还是翻不到。到这一步才意识到，要解决时效性问题，光优化存量检索没有用，必须给系统增加一条活的、能随时拉取外部信息的通道。

1.2 比“答不上”更危险的是“答得顺但全在编”

实测时我发现，“查不到”反而比较好处理，最要警惕的是模型在没有信息的情况下强行组织回答。它会从旧文档里抓几个语义相近的词，再靠模型先验脑补出一个“貌似合理”的答案。用户通常很难察觉这是幻觉，只会以为系统数据太旧。

更麻烦的是，这套编造经常被包装得很正式。知识库系统一般都有引用机制，模型有时能把一段完全不相关的旧文档ID附在幻觉答案后面，看起来特别严谨。如果你给业务方看的是这种效果，对方很容易误判成“系统数据没刷新”，而不是“系统在胡说”。

所以我在评估标准里定了一条硬规则：当用户问题里明显带有时效性诉求（“最新、最近、发布、官宣、进展”这类词），而知识库没有对应时间戳的新内容时，宁可告诉用户“当前资料未覆盖”，也不要让模型硬答。但这样只是止损，等于把问题又抛回给用户。要真正解决，还是得让Agent具备实时获取外部信息的能力，这也是后来接入网络搜索的根本原因。

2. 方向选择：与其每天手动灌新文档，不如给Agent加一只“实时触手”

2.1 三个备选路线的对比

动手之前我列过三个方案，各有各的代价：

增量入库虽然看起来最直白，但热点事件的优质文章从发布到被爬取、清洗、嵌入、入库，流程很长。等它进库，热点往往已经凉了一半。而且爬虫抓回来的内容质量参差不齐，一旦混进向量库，会被检索到不该出现的位置，反而把本来很干净的内部知识库弄脏。

持续联网微调成本更不用提，对话模型的训练和部署周期都是“天”起步，对分钟级热点来说完全不可控。

最终我选了第三条路：把网络搜索定义成模型可以主动调用的工具，模型判断当前问题需要最新信息时，自己决定搜索什么关键词、什么时候搜。

2.2 工具调用和RAG不是二选一，而是互补

这里要澄清一个常见误解：接入网络搜索不代表要抛弃RAG。我这次改造后的系统，内部知识库依然负责“翻旧书”，网络搜索只负责“上网冲浪”。两类信息在最终被交给模型之前，会在同一轮请求里汇合。

这个设计最大的好处是保持知识库的原子性。不会因为爬虫抓回一堆低质网页，就把向量库里那条权威文档的排名挤下去；也不会因为模型具备联网能力，就让它对所有问题都先搜一遍网，那样既慢又贵。

而且当时我用的模型对函数调用（Function Calling / Tool Call）支持已经比较成熟，可以通过声明JSON Schema工具，让模型自己决定“何时该搜、搜什么”。这句话听起来简单，实际操作时包含很多细节，下面展开讲。

3. 给Agent写一个“能看懂的搜索按钮”：工具定义、触发判断与调用闭环

3.1 工具声明怎么写，直接影响模型是否愿意调用

在往请求里传tools参数时，工具描述写得是否清楚，对触发率影响非常大。我拿两个描述风格做过对照：

用“search the web”这种笼统写法，模型触发率不高，经常在明显该搜索的问题上选择“凭记忆回答”。改成详细中文描述，明确列出“何时使用、用什么字段”之后，触发率明显提升。

TOOLS = [ { "type": "function", "function": { "name": "network_search", "description": "当问题涉及最新热点、实时数据、新闻动态、发布会信息、时间敏感事件，且本地知识库没有时间更新的内容时，调用此工具从公开网络抓取最新线索。", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "搜索关键词，建议保留用户原话中的核心实体与事件词" }, "freshness": { "type": "string", "description": "时间范围，可选值：'day'、'week'、'month'、'year'，默认'week'" } }, "required": ["query"] } } } ]

这里有两个细节要说明。

一是freshness参数。很多搜索服务API支持时间范围限定，告诉排序系统“只返回最近几天的内容”。这比让模型自己在问题后面加“截至今天”这种话术有效得多，我默认给week，对于热点新闻够用，特殊场景再放宽到month。

二是query的描述为什么要强调“保留用户原话中的核心实体与事件词”。模型如果自作主张把问题改写得太“通顺”，专有名词很容易丢，搜索命中率会断崖式下跌。实测下来，直接用用户原话里的实体词组合，比让模型重新造句效果好得多。

3.2 触发判断：模型判断为主，关键词规则兜底

工具调用的触发我做了两层保险。第一层是模型自己的函数调用判断，在系统提示词里写明“先判断是否有时效性需求，没有则不需要调用工具”；第二层是极简的关键词路由，当用户问题里明显出现“最新、今天、官宣、进展、发布”这类词时，即使模型这轮没触发函数调用，业务代码也会主动把搜索结果塞进下一轮上下文。

NEED_FRESH_WORDS = ["最新", "新闻", "热点", "今天", "本周", "官宣", "进展", "发布", "截止", "实时"] def needs_network(query: str) -> bool: # 用当前年份做数字兜底，检测问题里是否包含“今年”“去年”这类年份数字 current_year = datetime.now().year if any(str(y) in query for y in range(current_year - 1, current_year + 1)): return True return any(w in query for w in NEED_FRESH_WORDS)

这套规则比较粗，不是用来做主要判断的，只是兜底。有时候模型在复杂多轮对话里会漏触发，有这条规则在，至少能保证时效性问题不会被完全漏掉。

3.3 一轮完整的“搜索→回填→再回答”闭环

核心调用逻辑其实不长，用兼容主流函数调用格式的通用写法即可：

import json def handle_user_query(user_query: str) -> str: messages = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_query}, ] # 第一轮：模型自行决定是否需要搜索 response = call_model(messages=messages, tools=TOOLS) message = response["choices"][0]["message"] # 模型没有发起工具调用，直接返回 if not message.get("tool_calls"): return message["content"] # 取出第一个工具调用并执行 call = message["tool_calls"][0] args = json.loads(call["function"]["arguments"]) search_result = network_search( query=args.get("query", user_query), freshness=args.get("freshness", "week"), ) # 把模型要求调用工具的意图与搜索结果都回填进历史记录 messages.append(message) messages.append({ "role": "tool", "tool_call_id": call["id"], "content": search_result, }) # 第二轮：模型结合历史和搜索结果产出最终回答 final = call_model(messages=messages, tools=TOOLS) return final["choices"][0]["message"]["content"]

我自己在项目里没有引入重量级编排框架，就是纯HTTP请求加一个几十行的小工具函数。这样做的好处是排查问题非常直观，哪里超时、哪轮请求没带上历史，一眼就能看到。等逻辑稳定了再考虑封装成独立模块也不迟。

3.4 搜索结果注入前的“压缩”规则

搜索服务返回的原始字段一般包括标题、链接、日期、摘要，有些还带正文片段。如果把这些内容全量塞给模型，上下文会迅速膨胀，同时把网页里的广告、导航这类噪音也带进去。

我的做法是写一个压缩函数，最多保留5条，标题截到80字，正文摘要取前300字，并强制带上发布时间和来源域名：

def pack_search_results(raw_items: list) -> str: lines = [] for item in raw_items[:5]: title = item.get("title", "")[:80] date = (item.get("date") or "")[:10] snippet = item.get("summary") or item.get("snippet") or "" snippet = snippet[:300] source = (item.get("source") or "").replace("https://", "") lines.append(f"[{date}] {title}\n{snippet}\n来源:{source}") return "\n\n".join(lines)

“来源”字段这行特别关键，它不只为回答末尾的出处展示服务，更重要的是让模型在下一次生成时能追踪到“这段话是从哪个网站来的”。这比把所有链接都塞进提示词要精简得多。实测下来，一次搜索注入的内容从原来的两千到三千字，压缩到一千五百字以内，回答延迟稳定在两秒上下。

4. 双通道编排：让“翻旧书”和“上网冲浪”在同一轮回答里协作

4.1 并行检索，别让搜索拖慢整体响应

如果用户问题同时命中知识库和网络搜索两条路，串行执行的延迟会很难看。我的做法是把两边做成并行：向量库做top_k检索，网络搜索API做摘要返回，用asyncio.gather等最慢的那条路回来。

import asyncio async def dual_channel(query: str): rag_task = asyncio.create_task(vector_search(query, top_k=4)) net_task = asyncio.create_task(network_search(query, freshness="week", max_results=5)) rag_hits, net_items = await asyncio.gather(rag_task, net_task) return format_rag_hits(rag_hits), pack_search_results(net_items)

两边通常都在几百毫秒到一秒内返回，整体体验基本可控。偶尔搜索服务不稳定，响应超过一秒半，那就需要走后面讲到的超时降级逻辑。

4.2 上下文编排：必须让模型分清哪些话来自哪本书

并行拿到内容后，把它们组织成一个新的上下文块，顺序上“内部资料在前，网络资讯在后”，并在系统提示词里给模型定三条优先级：

1. 内部文档存在明确答案时，优先引用文档。
2. 内部文档没有覆盖或已过期时，引用网络资讯并标注时间点。
3. 两边信息冲突时，明确指出冲突，不要硬合成一段。

我在提示词里写过这样一段话：

你将拿到两类材料：【内部资料】和【网络资讯】。请区分它们，不要混用。 如果内部资料能回答问题，优先用内部资料； 如果问题需要最新信息，请用网络资讯回答，并标注“根据最近检索到的资讯”。 若两者存在冲突，明确告诉用户存在差异。

这看起来只是几句“prompt工程”，但实际效果差异很大。没有这段约束时，模型经常把网络信息悄悄融进内部文档的表述里，用户根本分辨不出哪句话是官方资料，哪句话是临时搜索结果。有了约束，它至少会把两类信息的边界保持住。

4.3 一个值得参考的回答结构

接入后，模型面对“某产品最近发布了什么新功能”这类混合型问题时的回答，大致长这样：

根据内部资料，该产品在去年发布时包含A、B、C三个模块。 但根据最近检索到的公开资讯，官方在本月初发布了新版本， 新增了D功能与E优化，电池续航也有明显提升。 以上属于网络资讯，未经内部确认，建议以官方正式公告为准。

用户一眼就能看出哪些是可信内部材料，哪些是临时抓取的最新说法，不会被误导。这就是双通道编排的核心目标——让模型既会翻旧书，也会上网冲浪，还能把两条路的信息说清楚。

5. 实测与调优：我踩过的四个坑

5.1 坑一：把整页网页正文塞进提示词，回答反而更差

第一次接入时，搜索服务返回了正文片段，我图省事直接拼进提示词。结果模型回答的准确率反而下降，经常被页面里的导航、广告、相关推荐这些噪音干扰，而且上下文从两千字直接涨到六千字，延迟翻倍。

原因是网页正文的结构性噪音太大，并不是每一段都和当前问题相关。对策很简单：只用标题和摘要字段，删除正文；只有在摘要相似度明显不够时，才从正文里做一次“关键句抽取”补一条。

5.2 坑二：模型被营销软文带偏

某个热点问题的搜索结果里，前三名全是营销号文章。模型完全不判断信源质量，一字不差地把标题党的结论复述给了用户，看起来像官方口径，实际上出处是推广软文。这类问题比“搜不到”更难防。

我做了三件事补救：一是在提示词里写明“优先参考权威或官方信源，营销、自媒体内容需谨慎引用”；二是在结果排序阶段给已知的可信域名加了权重；三是在回答模板里强制要求，当不确定来源时明确写出“信息来自网络，未经官方证实”。第三点最重要，它把不确定性透明化了。

5.3 坑三：工具调用陷入重复搜索循环

有一次模型没搜到理想结果，于是调用network_search，返回不满意，又调用，连续检索了四五次。用户在那等了三秒多没看到任何输出，token消费也翻了好几倍。

原因是工具调用机制天然允许模型连续调用，但我的代码没有设置全局轮次上限。修复方案是：在单次会话里维护一个搜索次数计数器，默认最多搜2次；对完全相同的query做去重，重复query直接复用上一次的搜索结果；允许第二次搜索，但必须基于改写后的新关键词，禁止原地重试同一句话。这个改动上线后，重复调用问题基本绝迹。

5.4 坑四：搜索超时拖垮整体响应

网络搜索API偶尔会有超过两秒的响应，用户能明显感到卡顿。我做了三件事：给搜索请求加1.2秒超时；命中缓存的query直接从本地取；超时或失败时走降级逻辑，只返回RAG结果，并在最终回答前追加一句“网络检索暂不可用，当前答案基于内部资料”。上线后还会把超时率记进日志，方便定位到底是哪个搜索参数导致的慢查询。

如果你刚做完第一版，我建议优先处理5.2和5.3。前者决定回答质量，后者决定你的token账单。

6. 效果评估与继续扩展的方向

6.1 20条问题的小范围回归测试

我搭了一个极简的回归测试集，一共20条问题，分成三类：时效性事件10条、私有知识6条、混合型问题4条。每类挑几个问题，在接入前和接入后各问一遍，人工看回答是否命中。

这个对比让我最意外的不是时效性问题解决了，而是混合型问题的表现。单纯加一个网络搜索工具，不仅没让私有问答变差，反而不需要靠“猜”来补最新进展，幻觉明显变少了。这是这次改造最值的部分。

6.2 剩下还能做的几件事

目前的版本还能继续优化，我列了四个方向，有的已经在推进：

第一，热点结果缓存。同一个query在10到30分钟内复用搜索结果，热点新闻短时间内变化不大，能省不少外部请求。

第二，搜索词改写。长问题直接丢给搜索服务效果通常不好，可以先用模型把问题改写为两到三个搜索词组合，命中率会有明显提升。

第三，多路信源聚合。同时拉“官方公告、新闻网站、社区讨论”三路结果，再做去重和简单投票，回答的引用会更可靠。

第四，搜索后反思。第一轮结果不满意时，让模型重新生成更精准的关键词再搜一次，这比单纯重试相同的query有用得多。

折腾完这一轮，我个人的体会是：本地知识库Agent的核心价值不在于“什么都能答”，而在于知道什么问题该翻旧书、什么问题该上网冲浪，并且在回答里把两类信息的边界分得清清楚楚。这个判断能力和编排能力，比单纯接入一个搜索API要值钱得多。