给对话模型接上搜索，表面上是把一个搜索接口接到一个聊天接口，实际需要处理的是信息边界：什么时候应该搜索，搜索结果是否可信，模型能不能把答案和证据对上。搜索本身不等于知识，检索到的网页也不自动等于可以引用的结论。
先定义检索的任务
我会把请求分成几类。需要当前状态的事实，例如版本、价格或服务是否可用，才适合实时检索；概念解释可以使用稳定文档；带有个人经历和内部数据的问题，则不应该把搜索结果伪装成用户自己的记忆。分类做得越早，后面的提示词和缓存越简单。
查询词也不能只是把用户原话原样发出去。可以从问题里提取时间、地点、技术名称和限定条件，生成一到几条窄查询，再保存原始查询和结果 URL。这样出了问题时，能看出是检索词不够准确，还是模型误读了页面。
结果需要经过一层整理
搜索引擎返回的标题、摘要和正文可能互相矛盾，也可能已经过期。中间层至少要保存 URL、抓取时间、页面标题和一小段上下文，再做去重和长度限制。把整页 HTML 一股脑塞给模型，会让重要条件被噪声淹没，还会放大提示注入的风险。
网页内容是外部输入，不是系统指令。页面里出现“请忽略之前要求”之类的文字时，应该把它当成引用材料，不能让它改变工具的权限和任务范围。对需要登录、下载文件或触发副作用的页面，搜索流程只能停在只读层。
回答必须能回到证据
我更在意答案里的每个关键判断能否回到某个来源。可以要求模型为事实标注来源编号，并在生成后检查引用是否真的包含该事实。如果找不到对应段落，就把语气降为“搜索结果显示”或“暂时无法确认”，不要为了让句子完整而补一段看起来合理的解释。
缓存也要有明确的失效时间。新闻和版本信息不能缓存太久，稳定的官方概念文档可以长一些。错误结果同样需要短暂缓存，否则一个临时的 500 可能在用户面前停留很久。监控里应该区分检索失败、页面解析失败和模型生成失败，这三种问题的处理方式不同。
搜索不是替代思考的按钮
把搜索接到聊天框以后，回答变得顺滑了，核对过程却更容易被隐藏。我希望这个工具帮助我找到材料，而不是替我决定哪些材料值得相信。需要做判断的地方仍然要打开原文，尤其是版本兼容、许可、隐私和安全相关的结论。
如果以后再做类似功能，我会先画出数据流：问题从哪里进入，查询怎样生成，外部内容如何被隔离，引用怎样回写，失败如何被用户看见。把这条链画清楚以后，模型只是其中一个可替换的步骤，系统不会因为换了模型就失去边界。