研究代理可靠性协议

要解决的失效模式

多步研究任务有一个共同的失败画像：fetch 返回 404，代理静默跳过并继续；某个 URL 超时，没有任何记录；两个来源互相矛盾，报告却给出确定语气；结论引用了一个实际从未成功取回的页面。更麻烦的是推理不透明——你看不到代理"为什么这么选来源""为什么放弃这条线索"，只能靠输出结果倒推，而倒推常常来不及。

核心能力与关键步骤

这个规范不给代理加新工具，而是约束它如何做已有的事。核心是三条协议：来源验证、错误恢复、思考透明。

• 读前来源评估：拿到搜索结果先排序（相关性、可信度、时效性、权威性），再深读。思考块里写明"为什么选这几个"，而不是拿到 URL 就抓。
• 结构化思考块：每次思考必须包含四要素——从来源学到了什么、如何连接研究目标、识别到的矛盾/缺口、战略决策。避免"现在我去找 X"这类只有下一步的空话。
• 强制错误确认：任何工具失败，下一段思考必须显式说明失败类型（404 / 超时 / 无效 URL）、恢复策略（重试 / 换源 / 记录缺口）。禁止静默继续。
• 来源追踪表：维护一张表记录哪些 URL 成功、哪些失败、哪些被引用于哪些结论。绝不引用未成功取回的来源。
• 跨源验证：显式比较一致、矛盾、未证实之处，给出置信度，关键结论尽量跨 ≥2 源核验。
• 完成前校验清单：用具体覆盖总结替代"信息已充分"的空话；文件写入后用 read_file 验证实际内容，而非 list_directory（后者可能因缓存误报）。

输出固定为 ResearchReport 工件：问题、来源追踪表、综合结论、跨源一致/矛盾/未证实项、置信度、缺口、局限性，外加一段避坑提醒，列出本次命中的反模式。

适用边界与注意点

适合包含 search、read_url、fetch 等网络研究操作、且工具交互 ≥3 次的任务，尤其适合对完整性和可验证性有硬要求的场景。

不适合：文件级溢出策略交给 filesystem-context，评测框架交给 evaluation，调试优化交给 reasoning-trace-optimizer——本规范不负责这些层的问题。