详细讲述搜索工具参数设计，目的为规范模型检索内容并自行检验真实性

接着说，好问题。搜索工具的参数设计，本质上是把「搜什么、搜回来怎么信」这两个决定权，从模型手里部分接管过来，用 schema 结构和返回格式替它把关。我从目的反推给你拆。 一、先想清楚你的两个目标 一是规范模型检索内容：模型生成 query 的质量直接决定检索质量，不能靠祈祷，要把约束做成参数和描述。二是让模型能自行检验真实性：模型检验靠的不是自觉，而是上下文里有可核对、可引用的证据。两个目标一个管输入侧，一个管输出侧。 二、规范「搜什么」：把约束写进参数而不是靠模型自觉 裸的一个 query 框是偷懒设计，至少要加这几层约束： 第一，单查询约束。query 参数的 description 里写明「一次只接受一个明确查询，子问题拆成多次调用」。模型最容易犯的错是一次 query 里塞三个问题，搜索引擎返回四不像。配套把 num_results 限小（3 到 5 条），逼模型聚焦，顺带防上下文爆炸。 第二，时间维度。加 time_range 或 date 参数（day/week/month 或起止日期），新闻和时效性问题必须显式带时间窗，否则模型会搜到三年前的旧文当新闻讲，这是翻车重灾区。 第三，范围约束。region、language 参数定向地域和语言；search_type 用 enum 锁死，web、news、scholar 只能选一个，比让模型自由发挥稳得多。 第四，可信源约束。site_filter 或 allow_domains 白名单，只放官方文档和权威站点进来，从源头掐掉一大半假信息和 SEO 垃圾站。 注意一个反直觉的点：参数越多越容易用错，所以能 enum 的 enum，能默认值的默认值，required 只留真正必要的，其余都给兜底默认。通常裸 query 加三四个受控参数，比一张巨大自由的 schema 表现更好。 三、让模型能「检验真实性」：返回结构比参数更讲究 模型检验真伪，靠的是上下文里有可核对的证据链。所以工具返回值至少要带这些： 第一，完整元数据。每条结果必须带标题、URL、发布时间、来源站点、摘要。没有 URL 和发布时间的搜索结果，模型根本无法核对，更没法引用，回答就只能裸奔。 第二，相关性信号。很多搜索 API 会带 relevance 分数或排序位次，把它原样传回上下文，模型能据此判断哪条是主证据、哪些只是沾边。 第三，空结果如实返回。「未找到任何结果」本身是重要信息，它告诉模型这个 claim 查无实据，该说查不到，而不是顺着用户的话头编一个。 第四，清洗但不能断证据链。返回前去掉广告、去重、截断到模型能读的长度，但保留关键句和 URL，别把证据链洗断。 四、查证要设计成循环而不是单次 单次搜索不叫检验。完整链路是：模型先基于已有知识提取关键 claim 或给出候选答案，然后调搜索工具找证据，对比多条来源——看发布时间、看站点可信度、看结果之间是否互相矛盾，发现矛盾就改写 query 再搜一轮，最后输出时强制挂上引用 URL，并把「证据不足」或「来源互相矛盾」如实说出来，不许硬圆。 工程上还可以把查证拆成独立工具：搜索工具保持简单负责找，另做一个 verify(claim) 专门负责搜证比对，职责分离后两个工具各自好调优、好测。 最后补一条最容易被忽略的：搜索结果本身不是事实，只是网页上的断言，而且网页里可能藏 prompt injection，写着「忽略之前的指令」诱导模型改口。所以参数和 prompt 都只是软约束，真正让模型「检验真实性」可信的底线在代码层：注入内容跟系统指令隔离、危险操作要确认。参数设计得再好，也只是让模型不容易犯错，不是让模型不会犯错。