企业官网建设流程全解析

如果你正在做企业级 AI 客服、Agent 或知识库类应用，一定遇到过这种尴尬：模型能力很强，却答不出“今天早上刚发布的新规则”；知识库很完整，却覆盖不了“用户突然抛出的长尾问题”；系统明明接了搜索引擎，却把营销软文当成官方答案。这些问题的共同根源，不是模型不够聪明，而是“知识时效性”没有解决好。

Decagon 接入 Perplexity 实时搜索服务，恰好提供了一个非常值得拆解的样本。Decagon 是面向企业的 AI 客户支持平台，它要解决的问题不是“陪用户聊天”，而是让 AI Agent 在真实客服场景中给出可靠、可追溯、符合企业规范的响应。Perplexity 则以对话式实时搜索见长，能把最新网页信息整理成带引用的回答。这两者结合，本质上是把实时搜索服务作为 Agent 的信息底座，用“检索增强生成”的方式补齐大模型的知识盲区。

这篇文章我会从四个层面展开：先讲清楚为什么要接入实时搜索服务，大客户场景下面临哪些时效性痛点；再拆解接入的核心架构和 API 集成方式；然后给出可以直接运行的示例代码和验证方法；最后总结接入过程中最容易被忽视的坑和工程建议。无论你是在做客服机器人、企业知识助手，还是通用 Agent 平台，这套思路都可以复用。

1. 这篇文章真正要解决的问题

很多团队在上线 AI 客服时，第一个月效果很好，第二个月开始被客户投诉，第三个月就发现问题集中在同一类场景：用户问的问题，知识库里确实没有，或者知识库里的内容已经过时了。

1.1 客服场景的信息时效性矛盾

企业客服场景的信息有一个鲜明特点：变化快、分散广、来源多。产品价格可能每周调整，物流时效会受天气和节假日影响，软件故障公告往往在几分钟内发布，金融产品的利率和活动规则更是按天更新。这些信息即使有专门的运营团队维护，也很难保证知识库的更新速度和线上商业节奏完全同步。

更麻烦的是长尾问题。用户不会只问“退货政策是什么”，还可能问“你们和某平台的联名卡现在还有活动吗”“这个版本为什么突然登不上去了”。这些问题如果知识库没录入，模型就会靠“想象力”回答，这是客服场景最不能接受的。

1.2 静态知识库与动态实况的差距

传统做法是把客服话术、产品文档、FAQ 整理成知识库，再做向量化检索，这就是大家常说的 RAG。RAG 能解决一部分问题，但它有一个先天短板：它只能检索“已经放入知识库的内容”。知识库更新需要经过内容审核、格式整理、向量化、发布上线，这个流程再快也需要小时级甚至天级。

实时搜索服务解决的不是“知识库够不够大”的问题，而是“模型能否获取最新事实”的问题。Perplexity 这类服务会实时抓取网页内容，把官方公告、新闻页面、论坛讨论等结构化信息返回给调用方。客服 Agent 拿到这些信息后，再结合自己的话术规范生成最终回复。

1.3 什么样的团队最需要这套方案

如果你的产品满足以下任一条件，就需要认真考虑接入实时搜索服务：

• 客服问题中超过 10% 需要查询“最新状态”或“正在发生的事件”。
• 产品价格、库存、政策、活动等信息变更频繁。
• 用户会直接询问官网、App 或社交渠道上刚发布的内容。
• 大客户对服务响应有 SLA 要求，不允许 AI 给出含糊或过期答案。
• 当前知识库维护成本高，新增问题常常跟不上业务节奏。

反过来说，如果你的问题域非常固定，比如内部 IT 帮助台、设备使用说明、历史政策查询，那么实时搜索未必是刚需，做好静态 RAG 反而性价比更高。这也是 Decagon 这类平台没有把所有客户都放到同一套实时搜索逻辑里的原因：越是服务大客户，越需要精细的信息路由和成本控制。

2. Decagon、Perplexity 与实时搜索服务的基础概念

在写代码之前，先把概念对齐。这样后续看示例时，不会把“搜索 API”和“聊天模型”混为一谈。

2.1 Decagon 在做什么

Decagon 是一款面向企业的 AI 客户支持平台，可以理解成一个“AI 客服团队”。它不只是接入一个大模型然后直接回复用户，而是把客服工作流拆成多个环节：意图识别、情绪判断、知识检索、政策查询、人工坐席转接等。它的核心价值是让 AI 在复杂的客服场景中承担责任，而不是简单做问答机器人。

这类平台天然需要多个信息源。模型只负责“理解和表达”，具体事实必须来自可验证的数据源。因此，Decagon 这类平台选择接入 Perplexity 实时搜索服务，不是偶然，而是 Agent 工程架构的必要步骤。

2.2 Perplexity 的实时搜索服务是什么

Perplexity 早期以对话式搜索引擎为人所知，用户输入问题后，它会返回一段整理好的回答，并附上信息来源链接。相比传统搜索引擎给出一堆蓝色链接，这种方式更接近“直接给答案”。

Perplexity 对外提供的实时搜索服务，本质上是把搜索能力和大模型生成能力封装成了 API。开发者调用时，传入用户问题，服务端会实时检索网页、抽取相关内容、生成回答，并返回引用信息。对开发者的价值在于：不需要自己维护爬虫、网页解析、内容抽取、去重排序这些复杂环节，只需要处理 API 结果即可。

2.3 核心概念：RAG 与实时搜索增强

RAG 全称 Retrieval-Augmented Generation，中文叫“检索增强生成”。它的核心思路是：不把问题直接丢给大模型，而是先从外部系统检索相关文本，把文本拼到 Prompt 中，再让大模型基于这些文本生成答案。

传统的 RAG 检索源以内部知识库为主，比如 MySQL、向量数据库、文档系统。引入实时搜索服务后，检索源多了一条“外部网页”的通道。整个公式可以写成：

Agent = 大模型 + 内部知识库检索 + 外部实时搜索 + 任务规划 + 引用校验

Decagon 接入 Perplexity 这类服务，正是在“外部实时搜索”这一环上加强了能力。要注意，实时搜索不能替代内部知识库，因为企业很多政策、价格、内部流程并不在网上公开，必须依靠内部数据。正确做法是分层：内部知识库优先，实时搜索兜底。

2.4 与直接用搜索引擎爬虫的差异

有些团队会想：我能不能自己写爬虫抓网页，然后存到知识库？可以，但成本很高。你需要处理反爬、页面结构变化、正文提取、去重、更新频率、内容质量过滤、稳定性保障等一系列工程问题。尤其是大客户场景，网页内容可能出现故障公告、临时活动页、社交平台短内容，这类页面生命周期极短，自己维护一套爬虫体系非常不划算。

使用 Perplexity 这类实时搜索服务，相当于把“搜索基础设施”外包出去，团队只需要关注业务层：什么时候搜索、如何组织上下文、如何验证引用、如何降级。

3. 大客户场景为什么必须引入实时搜索服务

很多人觉得实时搜索只是“提高答案新鲜度”，但在大客户场景里，它的意义远不止于此。这里要区分两个概念：正确性和可信度。正确性是答案事实是否正确，可信度是客户团队是否敢让 AI 直接对外回复。实时搜索服务同时对这两者都有贡献。

3.1 典型业务场景拆解

以企业客服为例，我把常见的高时效性问题分为四类：

这些场景的共同特征是：信息发布时间和用户咨询时间几乎同步。如果知识库几个小时才同步一次，AI 客服就是在用昨天的信息回答今天的问题。

3.2 知识库不可能覆盖所有问题

大客户往往业务线多、产品矩阵复杂。要让知识库覆盖所有长尾问题，意味着运营团队需要持续不断录入新内容。现实中，很多客服团队连基础 FAQ 都维护不过来，更别提实时同步官网公告和第三方政策。

实时搜索服务提供了一条低成本补位路径。当内部知识库检索不到相关内容，或者检索置信度不够时，Agent 自动发起搜索，把搜索结果作为补充上下文，再结合已有话术生成最终回复。这样既不需要人工维护海量知识库，又能覆盖大量非结构化信息。

3.3 实时搜索服务的关键优势：引用与可追溯

大客户场景还有一个硬性要求：AI 说的每一句话，最好都能找到出处。如果 AI 客服告诉用户“明天会恢复发货”，但用户追问“您怎么知道”，系统需要能给出依据。Perplexity 这类实时搜索服务的输出中通常包含引用链接或引用文本，这让企业有机会对 AI 的回答做二次校验。

这也是我强调“不要盲目相信实时搜索返回答案”的原因。实时搜索提供的引用，只能说明“网上有这段话”，不保证“这段话说的是事实”。企业级系统需要设置引用白名单规则，比如优先信任官网、政府网站、权威新闻源，对个人博客、论坛内容降权处理。

3.4 成本与收益判断

接入实时搜索服务不是免费的，成本包括 API 调用费用、响应耗时、上下文 token 消耗、以及结果校验的人力成本。因此，大客户场景通常不会让所有问题都走实时搜索，而是采用分级策略：

• 第一级：内部知识库命中时，直接回答。
• 第二级：内部知识库未命中，但问题属于“低风险通用问答”时，可以用实时搜索结果兜底。
• 第三级：涉及资金、法律、医疗、安全等领域时，强制转人工坐席，或者要求人工审核 AI 回复后再发送。

这种分级的本质，是将实时搜索服务当成“可选的实时信息源”，而不是“所有问题的最终答案”。

4. 实时搜索服务的接入模式与整体架构

理解了为什么接入之后，再看怎么接入。这里以 Decagon 这类企业级 AI 客服平台为背景，给出一个通用的实时搜索增强架构。

4.1 完整链路

一次带实时搜索的客服请求，链路可以拆成下面这些环节：

1. 用户输入问题，网关层做鉴权、限流、日志记录。
2. Agent 会话管理模块加载历史对话和用户档案。
3. 意图分类模块判断问题是否属于“高时效性问题”。
4. 本地知识库检索，得到候选文档和相关性分数。
5. 如果本地检索置信度不足，则调用实时搜索 API。
6. 对搜索结果做清洗、去重、引用提取和安全过滤。
7. 将内部检索结果和实时搜索结果拼入 Prompt。
8. 大模型生成最终回答。
9. 系统对回答做引用校验和合规检查。
10. 返回给用户，同时记录指标和审计日志。

这个链路里，实时搜索服务不是入口，而是中间件。它可以被缓存、被降级、被替换，不会影响主流程的完整性。

4.2 三种可选的接入模式

根据业务不同，有三种常见的接入模式：

在实际项目里，我更推荐“兜底搜索模式”。底层是内部知识库，它保证了对企业私有知识的准确回答；上层是实时搜索，它只解决内部知识库覆盖不到的问题。Decagon 这类平台对大客户一般也会采用类似策略，因为大客户对成本、合规、可解释性的要求远高于中小客户。

4.3 接入时需要考虑的架构组件

无论选用哪种模式，实时搜索服务接入后，系统里最好包含以下几个组件：

• 查询改写模块：把用户口语问题改写成适合搜索的短句。
• 缓存模块：对相同或相似查询做短时间缓存，降低 API 成本。
• 超时与重试模块：第三方服务不可用时要快速失败并降级。
• 引用校验模块：检查返回链接域名、状态码、内容相关性。
• 安全过滤模块：屏蔽恶意 URL、非法内容和越权信息。
• 审计日志模块：记录哪些问题触发了搜索、返回了什么、最终回答了什么。

这些组件不会一次性做完，但架构上要预留位置。否则等流量上来，你会发现第三方 API 的每一个不稳定因素都会被无限放大。

5. 环境准备与基础配置

接下来进入实操环节。我会给出一个最小可运行示例，用 Python 演示：如何接入实时搜索服务、如何把结果拼入 Prompt、如何暴露成 HTTP 接口。

5.1 环境依赖

建议使用 Python 3.10 及以上版本。本文示例依赖以下 Python 包：

• requests：调用实时搜索 API。
• openai：调用大模型生成最终回答。
• fastapi + uvicorn：把 Agent 逻辑封装成 HTTP 服务。
• cachetools：做简单的 TTL 缓存。
• python-dotenv：加载环境变量。

安装命令如下：

pip install requests openai fastapi uvicorn cachetools python-dotenv

版本请以实际项目为准，本文重点演示通用思路，不依赖特定版本的 API。

5.2 配置环境变量

为了方便管理密钥，建议把配置写入.env文件，并且确保.env不会被提交到 Git 仓库。

PERPLEXITY_API_KEY=your_perplexity_api_key PERPLEXITY_MODEL=your_model_name OPENAI_API_KEY=your_openai_api_key OPENAI_MODEL=gpt-4o-mini AGENT_CACHE_TTL=300 SEARCH_TIMEOUT=15

这里的PERPLEXITY_MODEL要填当前你在 Perplexity 控制台开通的模型名。不同时间、不同账号，模型标识可能不一样，建议以官方文档为准。不要照抄网上的旧模型名。

5.3 为什么需要独立封装搜索客户端

实时搜索服务和大模型聊天 API 在接口形式上可能很像，但在职责上完全不同。搜索服务负责“找信息”，大模型负责“写回答”。我建议把搜索逻辑封装成独立客户端，不要直接在业务代码里写requests.post。封装的最大好处是：后续切换服务商、调整超时、增加缓存时，只需要改动一个文件。

6. 核心流程拆解与示例代码

下面开始写代码。这个示例会实现一个最小可用的“客服 Agent”，它支持先查本地知识库，未命中时调用实时搜索服务，再把搜索结果交给大模型生成带引用的回答。

6.1 封装实时搜索客户端

先建一个search_client.py文件，负责调用实时搜索服务。

# 文件路径：search_client.py import os import requests from dotenv import load_dotenv load_dotenv() class RealtimeSearchClient: def __init__(self, timeout: int = 15): self.api_url = "https://api.perplexity.ai/chat/completions" self.api_key = os.getenv("PERPLEXITY_API_KEY") self.model = os.getenv("PERPLEXITY_MODEL", "your_model_name") self.timeout = timeout def search(self, query: str, system_prompt: str = "") -> dict: """ 调用实时搜索服务，返回 answer 和 citations。 """ if not self.api_key: raise ValueError("PERPLEXITY_API_KEY is not set.") headers = { "Authorization": f"Bearer {self.api_key}", "Content-Type": "application/json", } system_content = system_prompt or ( "你是一个实时搜索助手。请基于搜索结果，" "用简洁准确的语言回答问题，并返回信息来源。" ) payload = { "model": self.model, "messages": [ {"role": "system", "content": system_content}, {"role": "user", "content": query}, ], "temperature": 0.2, "max_tokens": 800, "return_citations": True, } resp = requests.post( self.api_url, headers=headers, json=payload, timeout=self.timeout, ) resp.raise_for_status() data = resp.json() return { "answer": data["choices"][0]["message"]["content"], "citations": data.get("citations", []), }

这段代码的关键点有三个：

第一，通过环境变量读取 API Key，避免硬编码在代码里。第二，把return_citations打开，因为引用信息对大客户场景非常关键。第三，设置了超时时间，避免第三方接口长时间挂起拖垮业务线程。

6.2 实现带缓存与降级的搜索逻辑

实时搜索服务有成本，不能每次都直接请求。这里用一个 TTLCache 做内存缓存，同时加入简单的降级逻辑。

# 文件路径：agent_service.py import os from cachetools import TTLCache from search_client import RealtimeSearchClient client = RealtimeSearchClient() cache_ttl = int(os.getenv("AGENT_CACHE_TTL", "300")) search_cache = TTLCache(maxsize=1024, ttl=cache_ttl) def search_with_cache(query: str) -> dict: """带缓存和降级的搜索调用。""" normalized = query.strip().lower() if normalized in search_cache: print(f"[cache] hit: {normalized}") return search_cache[normalized] try: print(f"[search] miss: {normalized}") result = client.search(query) search_cache[normalized] = result return result except Exception as exc: print(f"[search] error: {exc}") # 降级：返回空结果，让上层走本地知识库或人工兜底 return {"answer": "", "citations": []}

这里的缓存 key 我用的是归一化后的纯文本。实际项目中建议用 embedding 相似度缓存，否则用户换一种说法，缓存就很难命中。降级处理也很重要：搜索失败时不要让整个 Agent 崩溃，而是返回空结果，让上层逻辑决定继续用本地知识库还是转人工。

6.3 用 FastAPI 暴露客服 Agent 接口

接下来，把流程串起来。用户请求到达后，先查本地知识库，如果本地没有足够信息，再调用实时搜索服务，最后用大模型生成回答。

# 文件路径：main.py import os from typing import List from fastapi import FastAPI, HTTPException from pydantic import BaseModel from openai import OpenAI from agent_service import search_with_cache app = FastAPI(title="Realtime Customer Agent") oaiclient = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) openai_model = os.getenv("OPENAI_MODEL", "gpt-4o-mini") class QueryRequest(BaseModel): user_id: str query: str session_id: str = "" def retrieve_local_docs(query: str) -> List[dict]: """模拟本地知识库检索，实际项目可替换为向量数据库查询。""" local_docs = [] # 这里只做演示，实际逻辑通常是：embedding -> vector db -> topk return local_docs def need_realtime(query: str, local_docs: List[dict]) -> bool: """判断是否需要实时搜索。""" if not local_docs: return True # 如果本地文档包含“最新”“现在”“今天”等高时效词，也可以触发搜索 keyword_markers = ["最新", "现在", "今天", "目前", "刚发布", "延迟", "故障"] return any(kw in query for kw in keyword_markers) def build_prompt(query: str, local_docs: List[dict], search_result: dict) -> str: local_text = "\n".join(d.get("content", "") for d in local_docs) search_answer = search_result.get("answer", "") citations = search_result.get("citations", []) citation_text = "" if citations: citation_text = "参考资料：\n" + "\n".join(citations) return f"""你是企业客服助手。请基于以下资料回答用户问题。 如果资料不足，请明确说明“需要人工核实”。 【内部知识库】： {local_text} 【实时搜索结果】： {search_answer} {citation_text} 【用户问题】： {query} """ @app.post("/api/agent") def agent_endpoint(req: QueryRequest): # 1. 本地检索 local_docs = retrieve_local_docs(req.query) # 2. 判断是否触发实时搜索 search_result = {"answer": "", "citations": []} if need_realtime(req.query, local_docs): search_result = search_with_cache(req.query) # 3. 拼接最终 Prompt prompt = build_prompt(req.query, local_docs, search_result) # 4. 调用大模型生成回答 resp = oaiclient.chat.completions.create( model=openai_model, messages=[ {"role": "system", "content": "你是一名严谨的企业客服助手。"}, {"role": "user", "content": prompt}, ], temperature=0.3, ) answer = resp.choices[0].message.content return { "answer": answer, "use_realtime_search": bool(search_result.get("citations")), "citations": search_result.get("citations", []), }

这段代码把链路串起来了，但也只是“最小可用版”。实际项目里，retrieve_local_docs不会返回空列表，而是从向量数据库查询 top-k 文档；need_realtime不会只看几个关键词，而是由单独的分类模型决定；build_prompt还会包含企业话术规范、敏感词过滤规则等。

6.4 运行方式

启动服务前，先确认.env里的 API Key 和模型名都正确。

uvicorn main:app --host 0.0.0.0 --port 8000

用 curl 或浏览器访问接口验证：

curl -X POST http://localhost:8000/api/agent \ -H "Content-Type: application/json" \ -d '{"user_id": "u_1001", "query": "你们的退货政策现在有变化吗？"}'

如果配置正确，接口会返回 JSON，其中use_realtime_search为 true，citations里有信息来源链接。

7. 运行结果与效果验证

接入实时搜索服务之后，不能只看“能跑通”，还要建立一套可量化的验证方式。以下是我推荐的验证方法。

7.1 预期返回结果

正常一次请求，响应结构大致如下：

{ "answer": "根据官网最新公告，自本月15日起，退货时效从7天延长至15天。", "use_realtime_search": true, "citations": [ "https://example.com/company/return-policy" ] }

你需要确认两件事：第一，answer是否回答了用户问题；第二，citations中的链接是否可以正常访问，并且内容确实支撑答案。

7.2 离线评测集

建议准备 30 至 50 个“高时效性问题”作为离线评测集，把接入前后的回答保存下来，逐条对比。评测维度可以包括：

不要只看正确率。引用可访问率是很多团队忽略的坑：实时搜索返回的链接，可能因为网页更新、反爬或临时跳转而失效。如果引用打不开，用户会对 AI 的信任度大幅下降。

7.3 线上灰度策略

建议先只对内部员工开放，再用 5% 到 10% 的真实流量灰度。灰度期间重点观察两个指标：转人工率是否下降，以及用户是否会对回答中的引用链接进行点击。如果转人工率没有变化，说明实时搜索并没有真正解决用户问题，需要回到查询改写和上下文构建环节排查。

7.4 判断接入是否成功的三个标准

• 时效性问题占比下降：用户不再频繁追问“你确定吗”。
• 知识库维护成本下降：运营团队不需要紧急录入每一个临时公告。
• 回答引用可核验：用户或客服主管能通过引用链接快速确认信息来源。

这些标准比单次 Demo 演示更有价值。大客户场景下，效果评估不是“能不能回答”，而是“能不能稳定、安全、可解释地回答”。

8. 常见问题与排查思路

实时搜索接入过程中，有几个问题是团队最常遇到的。这里整理成排查清单，方便直接对照使用。

第一类问题是纯工程问题，通过超时、重试、缓存基本能解决。第二、第三类问题需要业务规则介入，比如建立可信域名库、对搜索结果做相关性打分。最后一类问题是最容易被忽略的，也是最需要提前设计的，因为用户对话里可能包含订单号、手机号、地址等敏感信息，把这些内容发送给第三方搜索服务前，必须做脱敏或明确拒绝。

9. 最佳实践与工程建议

如果要在生产环境长期稳定运行实时搜索服务，下面这些建议值得认真参考。

9.1 把实时搜索当成“信息源”，而不是“答案源”

实时搜索服务返回的 answer 可以作为参考，但不要直接拼给用户。更稳妥的方式是把搜索结果作为 Prompt 上下文，让主模型基于上下文生成回答。原因很简单：搜索服务更擅长找信息，但可能不了解你的客服话术、语气规范、敏感词限制。

9.2 引用必须保留且可核验

引用是实时搜索服务最值钱的部分。在面向用户展示时，如果产品形态支持，尽量把引用链接展示出来。如果不支持展示链接，也要在内部审计日志里保留引用信息，方便后续追溯。永远不要为了美观而丢弃引用。

9.3 本地知识库和实时搜索要分层

优先查本地知识库，本地没有或置信度低时再触发搜索。这样可以控制成本，也能减少不可控的外部内容进入问答链路。大客户场景通常对回答来源有明确要求，内部知识库的可信度永远高于外部网页。

9.4 做好缓存与限流

缓存能显著降低成本，但 TTL 不能一概而论。针对价格、库存、故障公告等高时效类问题，缓存 TTL 建议控制在 60 至 300 秒。针对一般政策类问题，可以延长到 15 分钟到 1 小时。同时，要限制单个用户或单个 IP 的搜索触发频率，防止恶意刷量导致成本失控。

9.5 搜索失败时必须有降级方案

实时搜索服务一旦不可用，Agent 不能直接报错。降级方案至少有三种：

• 返回本地知识库结果，并提醒用户“信息可能不是最新”。
• 直接转人工坐席，由人工介入回答。
• 给用户返回一个可点击的官网链接，让用户自行查询最新信息。

降级方案不是“临时补救”，而是产品设计的一部分。越是大客户，越能接受“AI 说不知道并转人工”，越不能接受“AI 编造一个答案”。

9.6 数据安全与合规

在使用外部搜索服务时，要建立敏感信息过滤机制。可以在进入搜索模块之前，用正则或 NER 模型识别手机号、身份证号、订单号、银行卡号等敏感信息，并做掩码处理。如果客户有数据驻留要求，还要确认第三方服务商的数据处理协议是否满足合规要求。

9.7 建立可观测性

从接入第一天就记录日志和指标。建议至少埋点以下信息：

• 查询内容（脱敏后）。
• 是否触发实时搜索。
• 搜索 API 响应耗时和状态。
• 返回引用数量。
• 最终回答选择哪条引用。
• 用户是否对回答点击“有帮助”。

这些数据积累到一定量后，会让后续的搜索触发规则、缓存策略、成本优化都有据可依。

10. 总结与后续学习方向

Decagon 接入 Perplexity 实时搜索服务这个案例，表面看是两个公司的商业合作，本质上是 AI 客服工程演进的一个缩影：模型能力不再是唯一决定因素，“能不能拿到正确、及时、可验证的信息”反而成为工程重点。

如果你正准备在自己系统里接入实时搜索服务，我建议从最小闭环开始：先封装搜索客户端，再做本地知识库加搜索兜底的简单链路，最后逐步加入缓存、限流、引用校验、安全过滤和降级策略。不要一上来就做复杂架构，先把“信息能否流通起来”验证清楚，再谈优化。

下一步可以继续深入的方向有三个：一是搜索触发策略，怎么判断哪些问题值得触发实时搜索；二是引用质量评估，怎么自动判断返回网页是否可信；三是多 Agent 协作，让检索、总结、校验分别由不同模块负责，提高整体可靠性。

记住一个原则：实时搜索服务让 AI 客服“看到”了最新的世界，但最终是否敢把回答发出去，依然取决于你的工程控制能力。