用 X API 和 LLM Agent 追踪模型发布：一套可核验的工作流

模型发布研究最容易出错的，往往是最开始的 5 分钟。一条帖子说“现已可用”，一张截图放着 benchmark，团队群里已经开始排期接入，结果没有人去找 release note。最后得到的是一份速度很快、排版很漂亮，却在关键字段上出错的发布简报。

我更愿意围绕这个失败模式设计追踪器，而不是先做一个会写摘要的 Agent。X 负责发出提醒，官方 changelog、model card 和 API 文档负责定案，LLM 放在中间做证据对照、找冲突和列出缺口，但不把帖子自动升级成事实。

先说结论

• 用 X 搜索和趋势发现候选发布，不要用它们确认发布事实。
• 在总结之前保留原帖 URL 和抓取时间。
• 可用性、价格、上下文长度和许可证，都要有对应的官方来源。
• 让 LLM 生成带有未知项的证据包，而不是直接生成发布公告。

工作流其实只有一句话

先收集少量帖子，把它们整理成证据记录；再沿着最强线索找到官方来源；最后让 LLM 对照两边内容，并把每个未解决字段标出来。

顺序很重要。如果先把一堆帖子丢给模型，它很容易把互相矛盾的说法压扁成一个顺滑故事。输入是带类型的记录和来源 URL 时，缺失信息会留在台面上。

X 是线索层，不是发布数据库

SandBase 提供独立的 Twitter 搜索、趋势、Tweet 详情和用户资料路由。搜索时间线模型页记录了 keyword、search_type 和 cursor；趋势模型则按国家限定发现范围。

图 1：搜索是有明确输入契约的 API 调用，不是一个“读 X”的魔法能力。

查询词应该直接对应任务：供应商、模型家族、“API available”、“model card”、“weights” 或 “pricing”。不要把所有词塞进一个大查询里。小查询更容易回答“这个候选为什么进入队列”。

趋势可以扩大范围，尤其适合模型还没有稳定名称的早期线索，但无关内容也会明显增加。把国家和抓取时间写进记录，绝不要把趋势标签当成可用性证明。

图 2：只有把趋势范围写进观察记录，它才是有上下文的线索。

证据记录应该朴素一点

最有用的 schema 往往很无聊：

{
  "candidate": "provider/model-name",
  "signal": {
    "source": "x",
    "url": "https://x.com/example/status/123",
    "author": "@example",
    "text": "...",
    "retrieved_at": "2026-08-25T09:30:00Z"
  },
  "primary_sources": [],
  "claims": {
    "availability": {"value": null, "source": null},
    "pricing": {"value": null, "source": null},
    "context_window": {"value": null, "source": null},
    "license": {"value": null, "source": null}
  },
  "status": "needs_verification"
}

提取字段后不要丢掉原文。分类出错时，它能帮助定位问题，也能让审核者看到究竟是什么触发了候选。若保留政策允许，可以存 hash 或不可变快照；X 内容可能被修改或删除。

官方来源核验必须是独立阶段

对于 OpenAI 相关候选，平台的 changelog 比转发帖更适合证明 API 变化。其他供应商则应使用 Anthropic release notes、Google 模型文档、provider model card 或带版本的仓库 release。来源必须支持你准备发布的那条具体说法。

图 3：官方来源应当绑定到它实际证明的字段，不能只贴一个供应商首页。

这里最容易越界。一页官方文档可能只确认“模型已存在”，并没有确认公共 API 已开放；model card 可能说明了评测条件，却没有生产价格。把这些字段拆开记录。

让 LLM 做对照，不要让它拍板

给 LLM 的输入应是一个小型证据包：候选记录、原帖，以及官方来源的 URL 或相关摘录。要求它输出四件事：

1. 哪些说法被直接支持？
2. 不同来源之间哪里冲突？
3. 哪些字段仍然未知？
4. 下一步最小核验动作是什么？

最终结果应该像审核队列，而不是营销文案：

状态：needs_verification
已支持：供应商在链接的发布页宣布了该模型。
未解决：公共 API、价格和许可证。
冲突：X 帖子称“开放权重”，model card 没有写明许可证。
下一步：检查供应商仓库和 API 目录。

我会把发帖、购买或修改生产路由放在这个 Agent 之外。读取是可回退的，外部副作用不是。如果后续要起草公开更新，先让人工审核证据包。

SandBase 在这里的边界

SandBase 提供 X 发现所需的 API，也可以在同一工作流里连接模型或搜索 API。它不会把一条 X 帖子变成官方声明，也不会替你跳过当前文档核验。这个边界反而是优势：采集、推理和发布保持可分离。

可以先从 Twitter API 目录开始，再把证据包接到研究任务需要的模型或搜索能力。更完整的 Agent 分层可以参考 2026 AI Agent 技术栈。

一份小型验收清单

• 每个候选都有规范的原帖 URL 和抓取时间。
• 每个要发布的指标、价格、日期或可用性结论都指向官方来源。
• “已宣布”“预览”“API 可用”和“开放权重”是不同状态。
• LLM 输出保留冲突和未知项。
• 任何外部副作用都需要人工审批。

这套流程只追踪可检查的公开证据，不覆盖私有发布计划，也不保证未来排名。超出能查到的来源范围，正确状态就是未知。

来源

• SandBase Twitter 搜索时间线
• SandBase Twitter 趋势
• SandBase Twitter API 目录
• OpenAI platform changelog