Naly 工程说明：Polymarket Gamma API 在预测市场文章中的接入

简要总结Naly 将 Polymarket 的 Gamma API 作为所有预测市场流程中确定性的发现与定价底层，取代临时性的新闻抓取并改为结构化市场实体。每个周期，它将实时事件和市场转换为可用于文章的信号，支撑错价汇总、KBO 预览、来源引注和后续结果核验，因此故事生成始终基于公开可观测的概率与市场结构，而非推断性观点。

摘要

Naly 将预测市场数据作为基础设施使用，而非附加层，因此编辑产物直接与可供后续审计的外部市场状态挂钩。Gamma API 为事件、市场、标签和价格提供可读取路径，无需钱包级密钥。设计挑战在于：保持接入层足够严格以确保可靠性，同时又足够灵活以适配需要快速发现主题的内容团队。

在 Naly 中的定位

Polymarket Gamma 接入位于原始市场原语与可发布编辑资产之间的上游边界，是更大流程的第一步：

输入层： 从 Gamma 获取事件、市场、标签和市场状态。
解释层： 将其标准化到 Naly 的内部 schema（event_id, market_id，token IDs、outcomes、probabilities、timestamps、active/closed 标记）。
叙事层： 将标准化输入供错价汇总和 KBO 预测草稿流程使用。
校验层： 保留已解决/已关闭的市场状态，用于后续文章真值核验和回顾评分卡。

截至 2026 年 6 月 10 日，这与当前需要可信且可引用预测证据的战术高度一致：预测校准可见性、可复现的内容来源，以及后续核验工作流。

技术机制

Polymarket 定义了三类 API，其中 Gamma 是事件/市场浏览和元数据的公共发现面板，而订单簿/交易式数据由 CLOB 提供，用户/持仓数据由 Data API 提供（文档）。Polymarket 文档表明 Gamma 与 Data 均为公共接口，而 CLOB 在进行订单操作时需要认证的私有交易表面。

Naly 可以仅使用公共端点实现一套稳健的日常流程：

发现活跃候选市场 通过 GET /events 与 active=true, closed=false, 分页（limit, offset）以及可选排序过滤器。
扩展到构成市场 使用事件级负载进行展开，因为事件会携带关联市场，这比单独查市场可减少 API 调用。
锁定精确实体 当已识别具体事件或市场时，使用基于 slug 的调用。
标准化定价 通过映射 outcomes 和 outcomePrices 数组逐项对应到命名概率。
持久化审计工件 以标准化行和原始快照两种形式保存，以便每篇文章都能追溯到每个来源数字。
下游生成前置门控 依赖新鲜度 + schema 校验；过期或不完整快照在使用前先标记为待刷新。

Gamma 文档精确描述了这种运行形态：可用于发现的公共端点包括 /events, /markets, /public-search, /tags, 以及 /series 。分页与过滤通过 limit/offset, tag_id等方式提供，并配套相关过滤条件。文档还直接给出三种检索模式：slug 查找、基于标签的发现以及事件枚举用于大范围扫描。对于 Naly 来说，事件优先模式在构建大规模日常候选时最具性价比，因为每个事件可带出多个市场记录。

实践中，Naly 的最小真值记录应包含：

事件和市场 ID
市场 question
clobTokenIds （用于需要时与 CLOB 进行下游价格对账）
outcomes 和 outcomePrices
enableOrderBook
active, closed、时间字段（start/end 时间戳）
抓取时间戳与来源 URL

尽管 Gamma 已可提供较强的概率基线，但第二条优化路径是可选的：当 Naly 需要更短间隔的盘中更新时，可在后续合并 CLOB 端点，如 /price, /prices或 /book 。

文献观点

预测市场研究支持这种数据优先的方法，但对解释行为提出了限制条件。

预测市场中的市场数据模型只有在经过校准且正确解读时才有价值；没有上下文时，价格不是通用概率。一项 2026 年关于 Polymarket 和 Kalshi 的研究发现系统性校准模式会因领域与时间跨度而不同，包括在特定领域中可观测到低置信偏差。
另一项聚焦生命周期的 2026 年研究强调，进行有意义的市场分析需要同步的多层数据工程：市场元数据、交易事件与结算信号必须显式关联并进行周期性一致性检查，而非孤立拉取。
早期关于市场微观结构的研究表明，在连续拍卖式流程下市场价格会传递交易者信息，这也是 Naly 可以将市场价格作为群体预测信号的原因，同时仍需随时间验证结果。
将市场价格与其他方法（如基于问卷的预测）进行比较的预测文献显示，预测市场在保留结果核验和模型纪律时可具备强预测性。

对 Naly 的实际含义很直接：所有数据都要带来源溯源入库，永远不要把单一价格快照当作最终真相，并将 readiness （数据新鲜度 + 完整性） story quality 与

（编辑叙事）。

设计权衡

Naly 在接入上有意优先可靠性而非速度。 Gamma-only 与 Gamma+CLOB：
Gamma 能快速提供稳定的发现与公开上下文；补充 CLOB 可提升微观结构丰富度，但会增加认证与端点复杂度。 每日快照与持续流式：
确定性的定时拉取比持续流更容易审计和复现，但会错过亚分钟级的状态变化。 事件优先拉取与市场优先拉取：
事件优先可减少重复调用并提高上下文覆盖；市场优先在窄任务中可获得略低的负载。 宽 schema 与严格 schema：
宽泛的 JSON-first schema 加速集成，但提高 schema 漂移风险；严格标准化可更早发现漂移，但会增加迁移开销。 通用字段与领域特定字段：

使用共享字段有利于文章复用；添加领域特定扩展（如体育特定置信区间）可提高当前精度，但可能使长期维护碎片化。

考虑到 Naly 的用户信任与留存目标，严格的可复现性和引用质量应优先于即时延迟优化。

故障模式

最大的问题是运营故障而非算法故障。 分页错误导致的数据缺失： limit 如果 offset 和
在两次轮询之间变化，就会出现重复或缺口。缓解方式：对分页游标打点并强制幂等 upsert。 closed=false 默认值 丢失历史上下文： closed=true 公开市场拉取会省略已解决项，除非
被明确请求。缓解方式：为核验任务增加专门的历史回填路径。 Slug 不稳定：
产品 URL 和可读 slug 可能漂移。缓解方式：在内部优先使用主 ID，并将 slug 保留为次级键。 outcomes/outcomePrices 语义字段漂移：如果 schema 顺序假设错误，解释会崩溃。缓解方式：在接入时断言数组对齐和长度检查。
API 短时不可用或被限流： 公开端点可能失败或返回部分负载。缓解方式：指数退避重试、在重复失败时进入异常队列，并保留历史快照。
晚期结算与陈旧叙事： 核验文章可能在结算尚未清晰落定前就发布。缓解方式：将结算状态作为发布状态的一部分，并通过不可变更正日志进行事后更新。

基于 Naly 的信任优先策略，流水线应当 fail closed：与其用无法核验的市场状态发布文章，不如延后发布。

实施说明

按现有运行栈，实际实现仍然很直接：

使用 Next.js 服务端处理器（next@16.0.7）托管接入端点和定时任务。
在 Neon 中持久化标准化行时，使用 drizzle-orm@^0.44.7 并通过 @neondatabase/serverless@^1.0.2 对市场标识符设置显式唯一约束。
将原始载荷快照存储到 Vercel Blob（@vercel/blob@^2.0.0）用于可审计性和事后差异比对。
将 markdown 源生成和文章拼装放在接入核心之外；使用 marked@^17.0.1 实现安全转换，并结合 ai@6.0.0-beta.105 只在数据完整性检查通过后才执行。 @anthropic-ai/claude-agent-sdk@^0.2.15 并结合
用于回填历史窗口时的可复现一次性重放。 tsx@^4.21.0对历史窗口进行可复现的一次性重放。typescript@^5.9.3 /

于 2026 年 6 月 10 日，该架构应优先交付三项硬约束产物：原始快照不可变性、到内部 schema 的确定性投影，以及从源 API URL 到最终文章引注的核验导向审计链路。