让 agent 直接问第一作者。
给 agent 用的一手出处。agent 遇到某个领域的问题，来这里拿原文：那篇论文、那条法规、那份判决。按需分层阅读，回答带上你能打开的引用。
老循环你很熟：五万 token，外加一堆不敢信的引用。
网页搜索是为了给人十个链接设计的。把它交给 agent，它只能照人的做法来——做得差、花得多，而且引用没法核。
搜网页，再读文档
- 调一个网页搜索 API。回来十个链接——几个摘要页，剩下是营销号。
- 打开三个。从摘要猜哪篇有那个数字、哪部有那一条。
- 拉 PDF 或网页，解析，看着表格——或者条款编号——碎成一地。
- 整篇塞进上下文，指望注意力能找到那一行。
- 每个 baseline、每部法规、每个判例都重来一遍。
- 手工拼装。凭记忆标出处。祈祷 ID 不是编的。
直接问语料一个问题
- →它自己选工具。 在一个领域的全文上做混合检索，然后只读需要的章节——或者需要的那几条。
- →引用能解析。 [arXiv:2512.15176] 和 [刑法 第266条] 都对应真实文档。找不到就说"没有相关结果"，不会编一个。
- →流式输出。 首 token p50 3.5s——回答走 stdout，来源和进度走 stderr。
- →每个垂域同一形态。 一种请求体、一套 NDJSON 事件协议、一个配额池。加垂域，不用加新集成。
一次一个领域，挖到底
Exa 搜整个网。1stAuthor 一次只挖一个领域，把一手出处挖全——然后再挖下一个。正在扩展到各种专业领域。
分层读，别一次全读
agent 判断一份文档值不值得读，不该为整份文档付费。每一层是独立调用，便宜到可以在整个候选集上跑一遍。以下是真实数字。
2409.05591判断这篇论文值不值得读，花 300 token 而不是 23,311——少 78 倍。
（2022）湘0902刑初12号法条也一样：retrieve → brief → article → context → raw。刑法第 266 条本身只有约 250 字。
接进 agent 之前，先知道这三件事
只给 agent 一个光秃秃的 ask(query) 工具，它会用得很糟。这三条区别应该写进你的 tool description。
引用是真的
从不编造 arXiv ID、条号或案号——找不到就说没有相关结果。告诉你的 agent 在向上汇报时保留这些引用。
来源 ≠ 引用
检索十篇往往只支撑一条引用。sources 是检索集——按回答里出现的 ID 过滤，否则 agent 会把无关文档当证据摆出来。
截断会标出来，不会藏
碰到 max_answer_tokens，API 会置 answer_truncated。把它暴露出去，否则 agent 会把半截回答当完整的来总结。
法律垂域每个响应都带 coverage 块：中国民事判决目前只覆盖约 12%，且不是随机样本。把这句也写进 tool description。
一手出处，解析过，持续更新
不是摘要页的爬取。全文、分节、向量化、定期同步。
| 来源 | 规模 | 深度 | 新鲜度 |
|---|---|---|---|
| arXiv | 3,166,878 篇 | 全文、分节、混合索引 | T+0 — 公布当天 |
| PubMed Central | 约 750 万篇 | 结构化解析，按节访问 | 每日 |
| bioRxiv / medRxiv | 预印本 | 按节访问，同一套阅读动词 | 每日 |
| 法规 · 26 国 | 33,103 部 · 1,537,422 条 | 原文 + 中/英译文 + 条级抽取 | 建设中 |
| 中国裁判文书 | 4,510,354 → 1770 万 | 结构化 brief + 说理 / 判项分节 | 建设中 |
有语料？我们把它做成一个垂域。
Papers 和 Law 背后的流水线——解析、分节、抽取、向量化、交叉关联、暴露成阅读动词——并不只适用于论文和法律。两条路：
社区共建
贡献一份公开语料，我们把它索引成共享垂域，署名致谢，数据集在 seed.ac.cn 发布。
私有部署
把私有数据交给我们——内部文档、申报材料、手册、档案——得到一个私有的 1stAuthor：同样的分层、同样的引用、同样的 MCP 工具，只有你的 key 能用。