怎样让 Web Research MCP 的结论有据可查
从搜索结果到可以复核的结论，中间还需要保存来源、关联引用、展示冲突和记录版本，而不只是给 Agent 一个浏览器工具。
给 Agent 一个搜索工具很容易，让它产出可以复核的研究结果却难得多。搜索只回答“可能去哪里看”，研究还要回答“依据是什么、不同来源是否冲突、过几天还能不能重新得到同样的结果”。
GroundedSeek 的出发点，是把引用材料当作系统里的核心数据，而不是放在答案末尾充当装饰。
从链接列表到引用记录
一个 URL 不足以支撑结论。页面可能更新，摘要可能断章取义，同一页面也可能同时包含支持与反对某个判断的信息。
因此，每条引用记录会保存：
{
"sourceUrl": "https://example.com/document",
"title": "Document title",
"retrievedAt": "2026-07-14T10:00:00Z",
"excerpt": "The relevant passage...",
"claimIds": ["claim-12"],
"contentHash": "sha256:..."
}retrievedAt 记录抓取时间，contentHash 帮助判断来源后来有没有变化，claimIds 则把引用和具体结论关联起来。最终答案中的每个重要判断都能找到对应依据。
MCP 工具应该小而明确
把一个通用浏览器直接交给 Agent，会产生很大的操作空间，也难以约束。GroundedSeek 的 MCP 接口更接近实际研究步骤：创建项目、搜索、采集来源、登记引用、生成综合报告和导出研究档案。
例如，登记证据的输入可以被约束为：
type AddEvidenceInput = {
projectId: string;
sourceUrl: string;
excerpt: string;
supports: string[];
contradicts?: string[];
};相比接受任意脚本的工具，这种输入更容易检查，日志也能更清楚地说明 Agent 做过什么。
搜索、浏览与综合需要分层
研究流水线至少包含三个不同阶段：
- 发现：用多组查询覆盖主题，形成候选来源集合。
- 验证：打开原始来源，记录发布日期、作者、上下文和关键片段。
- 综合：比较证据，标记一致、冲突与未知，而后形成结论。
如果搜索摘要直接进入最后的整理阶段，系统就会把搜索引擎截断过的文字当成原始资料。多分几步会增加一些状态，但能明显减少这种错误。
冲突不是异常
真实研究经常遇到来源不一致。系统不应该为了让答案读起来更顺而自动抹掉冲突，而要保留双方材料，并说明差异可能来自统计口径、时间或利益关系。
在数据模型中，结论可以拥有状态：
supported：存在充分且相互独立的支持；contested：可靠来源给出相互冲突的信息；insufficient：信息不足，暂时不能下结论。
“不知道”是研究系统必须能够稳定表达的结果。
版本记录让研究可以继续
一次研究往往不是终点。新版本发布、法规变化或新的原始资料都可能改变结论。GroundedSeek 把查询、来源、引用和报告保存在同一个项目中，记录每次改动，并支持导出 Markdown 与 JSON。
Markdown 适合人阅读和进入知识库，JSON 适合后续程序处理。两者来自同一份结构化状态，避免分别维护后产生偏差。
Local-first 的实际意义
本地优先不仅是隐私偏好，也让研究资料的生命周期不依赖某个在线聊天窗口。使用者可以备份数据库、用自己的工具搜索导出文件，并决定何时删除敏感项目。
这并不意味着拒绝网络服务，而是让网络承担获取信息的角色，让研究资产的控制权留在本地。
最后还要靠自动检查兜底
Agent 可以归纳证据，但外部代码应检查一些硬约束：引用的证据是否存在、URL 是否有效、报告中的 claim 是否都有来源、导出是否符合 schema。这些检查不判断观点，却能阻止结构性错误悄悄进入成品。
一套可靠的 Research MCP，本质上需要明确的状态变化和数据格式。浏览能力当然重要，但只有把来源、结论和版本连起来，模型生成的研究才有可能被复核、更新和信任。