AI 产品经理面试简报 04：验证器、推理档位、本地路由
从验证器、推理强度和本地路由三个层面，把本周 AI 更新转成可验证、可直接用于面试的产品判断。
先看结论
本期三条更新落在同一个产品问题上：模型能力越来越强之后，AI 产品经理怎样把能力变成稳定、可计量的任务结果。
Anthropic 的费马大定理项目说明，长周期 Agent 任务需要显式依赖图、可恢复的任务节点和机器验证器。Gemini 3.8 Flash 把推理强度做成
low、medium、high 三档，产品团队可以按任务分配延迟与 token 预算。NVIDIA PAIR 则把局域网里的多台设备放到一个请求入口后面，用请求级路由缓解并发排队。三条更新分别对应三个问题：任务怎样才算完成、单次任务值得投入多少推理、并发任务应该落到哪台机器。
| 更新与日期 | 发生了什么 | 产品经理要看什么 | 用户价值 | 行动窗口 | 证据边界 |
|---|---|---|---|---|---|
| Anthropic 形式化费马大定理，9 月 4 日 | 多个 Claude Agent 在 11 天内完成端到端 Lean 形式化证明1 | 依赖图、节点复用、失败恢复、最终验证 | 长任务可以并行推进，结果可以由程序复核 | 先选一类拥有明确验证器的复杂任务做试验 | 时间、代码量和 token 为 Anthropic 口径；Kevin Buzzard 完成了编译与 comparator 复核2 |
| Gemini 3.8 Flash，9 月 2 日 | Google 发布通用 Flash 模型，并开放三档推理强度3 | 每档的质量增量、延迟和单位成功成本 | 简单任务更快，复杂任务可以获得更多推理预算 | 现在建立分档回放集；首发价有效到 12 月 31 日 | 公开基准属于厂商评测，业务价值要用真实任务回放验证 |
| NVIDIA PAIR，9 月 4 日 | beta 版路由器把独立推理请求分配给局域网内的可用设备4 | 排队时间、节点利用率、模型命中和掉线恢复 | 多 Agent 并发时可以利用闲置设备，主机也能留给交互工作 | 适合已有多台兼容设备、且并发请求明显的团队试跑 | PAIR 按请求调度；单次推理容量维持每台设备原有上限5 |
01 Anthropic：长任务先有依赖图，再谈更多 Agent
发生了什么
Anthropic 在 9 月 4 日公布了一项形式化数学成果：多个 Claude Agent 在 11 天内，把费马大定理的一条既有证明路线完整写成 Lean 代码。Lean 是一种证明助手，软件会检查每一步推导是否符合形式规则。
项目总计证明了约 30,300 个定理，最终证明使用其中约 29,500 个；整个代码库约有 1300 万行。Anthropic 表示，系统消耗了约 60 亿输出 token。项目使用的是内部通用研究模型，Anthropic 将其能力描述为大致相当于 Claude Fable 5.1。1
这项成果改变的主要是自动形式化的工程尺度。Xena Project 负责人 Kevin Buzzard 编译了代码库并运行
comparator，确认结果通过检查。Buzzard 指出，数学结论仍来自早期文献；他更看重另一点：一套 AI 协作系统在 11 天内把数千页文献转成了端到端形式化证明。2产品机制
Anthropic 最初直接让多个 Agent 协作。原有多 Agent 编排很快丢失项目状态，Agent 之间也停止有效配合。Anthropic 把成功的转折归因于改用 Prove2Me；后续机制解释了这套平台具体改变了什么。1
Prove2Me 是一个面向数学形式化的开放协作平台。6 平台把任务组织成定理陈述的有向无环图，也就是一张只向前连接的依赖图。每个 Agent 可以看到哪些前置定理已经完成，再领取下一个可证明节点。平台还把定理陈述与证明代码分开保存，以缩短 Lean 编译时间；每个定理配一段自然语言描述，方便其他 Agent 搜索和复用。1
验证链也分成多层。
FinalCheck.lean 限定最终证明只使用 Lean 的三个标准公理。仓库从头构建了 60,475 个模块；comparator 核对最终命题、引用常量和公理；独立的 Rust 内核 nanoda 又检查了 1,052,234 个声明。7用户价值
产品团队可以先把这种任务结构用于大型代码迁移：模块依赖决定执行顺序，编译与测试负责验收。合规审查也能复用依赖图，把法规要求、证据和整改项连起来；法规语义与证据充分性仍交给领域专家复核。两类场景都能显示已完成部分、阻塞点和剩余路径，系统重启后也能从最后一个已验收节点继续。
多个 Agent 只是并行执行者。依赖图减少重复领取，状态存储支持中断后接续，验证器只把校验通过的节点送入下游。三层各自处理一种故障。
产品经理如何落地
第一步是选一个拥有客观验收条件的任务。代码编译、测试用例、结构化规则检查和数据库一致性约束都比“写得好不好”更容易起步。
第二步是把任务节点设计成可单独重试的最小单元。每个节点都要保存输入、依赖、产物、验证结果和失败原因。Agent 领取任务时只读取必要上下文，系统另行维护全局状态。
第三步是给验证器分级。机器规则先拦截格式和确定性错误，模型评审处理语义问题，人类只接手高损失或多次失败的节点。分级之后，团队才能同时控制质量和人工成本。
可验证指标
- 任务结果：最终验证通过率、端到端完成时间、一次通过率。
- 协作效率：依赖图可执行节点占比、重复劳动率、阻塞时长、失败重试次数。
- 人工负担：人工升级率、每个任务的人工审阅分钟数、人工改写占比。
- 单位经济：每个已验证结论的 token、计算时长和总成本。
风险边界
完整复现仍然昂贵。Anthropic 仓库记录的一次 96 并行任务构建耗时 5 小时 32 分，峰值内存 153GB；
comparator 运行约 14 小时 46 分，峰值内存 230GB。机器可检查和低成本复现是两个独立指标。7形式验证覆盖的是“命题与推导是否符合形式系统”。中间定理的名称是否准确表达数学含义，业务规则是否被正确翻成形式命题，仍然需要领域专家判断。产品团队要把“形式通过率”和“语义正确率”分开统计。
面试可直接说
这次成果给我的启发是，长周期 Agent 的核心产品能力是可恢复的任务系统。产品需要用依赖图拆任务，用持久状态支持接续，再用机器验证器定义完成。评估时我会优先看最终通过率、重复劳动率、人工升级率和每个已验证结果的成本，模型单次回答质量只占其中一项。
可能追问
- 业务缺少 Lean 这样的强验证器时，你会怎样设计验收？
- 任务节点拆得太细会增加多少调度和上下文成本？
- 一个节点连续失败时，系统何时换模型、改计划或升级给人？
02 Gemini 3.8 Flash：推理强度成为产品路由变量
发生了什么
Google 在 9 月 2 日发布 Gemini 3.8 Flash。Gemini API 文档把该模型标为正式可用，提供 100 万 token 上下文和 6.4 万 token 最大输出。开发者可以用
thinking_level 选择 low、medium 或 high，默认值是 medium。8Google 给出的首发价是每百万输入 token 0.75 美元、每百万输出 token 3.75 美元，推理 token 计入用量。首发价到 2026 年 12 月 31 日结束；2027 年 1 月 1 日起，标准价变为 1.50 美元和 7.50 美元。3
Google 还公布了 HLE-Verified 54.9% 等评测结果。HLE 是高难度知识与推理基准，这个分数只能说明模型在该评测设置下的表现。支付核对、客服闭环或代码修复等真实任务仍需各自的回放集。3
产品机制
推理档位控制模型愿意为一个请求投入多少计算。Google 的说明把
low 用于实时聊天、事件响应和快速分析，把 medium 用于复杂代码与一般 Agent 任务，把 high 用于数学、深度推理和困难的多步任务。Google 表示，模型处理复杂任务时会增加推理步骤，并可能反复调用应用已经开放的工具。模型卡同时提示，较高档位可能增加 token、延迟与超时。89产品团队由此多了一个路由变量。系统可以先按任务风险、复杂度、可验证性和历史失败率选档，再根据运行中的信号升档。例如，FAQ 改写可以从
low 开始；涉及金额、权限或多工具写操作的任务可以直接进入 medium；模型连续两次验证失败后，系统再升到 high 或转人工。同日发布的 Gemini 3.8 Flash Cyber 采用另一层分发控制。Google 通过 Fairwind Program 向政府、关键基础设施和核心软件维护者等可信防御团队开放，并要求参与组织把访问限制在内部安全、事件响应或渗透测试团队。Fairwind 管的是谁能使用 Cyber 版本，
thinking_level 管的是获准使用某个模型后投入多少推理预算。产品团队需要分别设计权限策略与成本策略。10用户价值
用户在不同任务上需要不同服务水平。实时交互更在意首 token 延迟，复杂分析更在意最终答案能否通过业务验收，高损失任务还要增加验证和人工审批。统一使用最高档会让简单任务承担多余成本；统一使用最低档会让复杂任务积累重试和人工接管。
推理档位让产品团队在同一个模型上定义多种服务等级。用户看到的是响应时间和结果可靠性，系统内部则按任务分配推理预算。
产品经理如何落地
团队可以先把真实请求按三项打标：错误损失、任务复杂度、结果可验证性。团队随后为每类任务设默认档位和升降档条件。
路由策略要在离线回放后进入小流量灰度。产品经理需要同时比较质量、延迟和成本，找到每一档的边际收益。某类任务从
medium 升到 high 后，若成功率增加 0.5 个百分点、单位成功成本增加 40%，团队还要结合错误损失、任务价值和样本置信区间决定是否升档。这组假设数字只展示计算方法。迁移也要单独验收。Google 要求迁移到 3.8 Flash 的应用移除
temperature、top_p 和 top_k，并把 thinking_budget 改成 thinking_level；该模型的最低档从 low 开始。参数兼容问题会直接影响线上行为。8可验证指标
- 任务结果：按档位统计终态成功率、验证通过率和人工接管率。
- 体验：首 token 延迟、p50/p95 完成时间、超时率。
- 过程：工具调用次数、重试次数、升档率和降档率。
- 单位经济：每个成功任务的输入/输出 token、模型费用，以及升一档带来的增量质量与增量成本。
风险边界
Google 模型卡记录了幻觉、偶发缓慢和超时等基础模型限制。模型卡还披露，多语言安全自动评测相较 3.7 Flash 回退 5.4 个百分点。Google 对评测中被标记的样本做了人工复核，认为绝大多数属于误报或情节轻微。产品团队仍需用目标语言和目标风险场景重测。9
价格也会改变路由结论。2027 年标准输入、输出价格都是首发价的两倍。当前可以接受的
high 档单位成本，到明年可能需要重新计算。面试可直接说
Gemini 3.8 Flash 把推理强度从模型内部参数变成了产品可控的预算档位。我会按错误损失、复杂度和可验证性给任务设默认档，再用失败、超时和工具调用信号动态升档。核心指标是每个成功任务的成本和升档带来的质量增量，统一基准分数只作为能力参考。
可能追问
- 你会让用户自己选择推理档位，还是由系统自动路由？
- 哪些信号适合触发升档，哪些信号容易造成成本失控？
- 模型价格翻倍后，你会先调整档位、提示词、缓存，还是供应商组合？
03 NVIDIA PAIR：本地扩容先解决并发队列
发生了什么
NVIDIA 在 9 月 4 日公布 Personal AI Router，简称 PAIR。该项目以开源 beta 形式提供，在 Windows、macOS 和 Linux 上运行，并代理 Ollama、LM Studio 的现有接口。Agent 应用可以继续请求同一个本地端点，PAIR 在后台选择局域网里的执行节点。411
支持范围包括 GeForce RTX 20 系列及后续 GeForce RTX 设备、RTX PRO、DGX Spark，以及搭载 Apple M4 或后续芯片的设备。模型下载完成后，PAIR 的推理请求与节点通信可以只经过本地网络；下载模型时仍需联网。11
产品机制
PAIR 先用 mDNS 在局域网发现设备，用户再通过 PIN 批准配对。节点之间使用自动生成的证书和 mTLS 加密通信。调度器会检查节点是否在线、推理引擎是否就绪、目标模型是否存在，以及当前任务负载和 GPU 利用率，再为请求选择一台符合条件的设备。5
PAIR 的调度单位是一次独立请求。调度器为请求选定一台节点，该节点从开始到结束执行整个请求；其他 Agent 的请求可以同时落到别的节点。每台机器继续独立使用自己的显存，一个模型也完整驻留在一台节点。5
因此，PAIR 更适合多 Agent、多工具并发。NVIDIA 展示的五个子 Agent 工作负载，在一台 RTX Spark 上耗时 18 分钟，加入 DGX Spark 与 RTX 5090 后耗时 8 分 48 秒。这个演示只对应厂商选定的设备、模型和任务，适合作为并发路由的机制示例。5
用户价值
本地 Agent 常见的瓶颈是排队：一个子 Agent 占用推理引擎时，其他请求只能等待。PAIR 把多个独立请求分散到已有设备，可以缩短队列，也能让主力电脑继续承担设计、游戏或其他交互工作。
团队还可以保留 Ollama、LM Studio 的现有客户端接口。应用层少一次 API 改造，试验成本更低。拥有几台兼容工作站、同时又有数据本地处理要求的小团队，可以先用现有设备验证并发收益，再决定是否建设集中式 GPU 服务。
产品经理如何落地
团队要先看负载形态。监控数据若显示多个请求经常同时排队，PAIR 才有明确优化空间。若总耗时主要来自一个超长模型调用，团队应该优先缩短上下文、换模型或改任务拆分。
第二步是管理模型版本。产品经理需要定义每个节点允许加载的模型、量化版本、上下文上限和更新时间，并在路由日志里记录实际执行节点。否则，同一个请求可能因为落到不同节点而出现速度与输出漂移。
第三步是设计掉线和重试。系统要识别节点失联、引擎准备状态和目标模型库存，把仍在队列中的请求重新排队；已经执行一半的请求则需要幂等策略，确保工具操作只提交一次。
可验证指标
- 完成效率：端到端完成时间、排队等待时间、并发吞吐。
- 资源利用：各节点 GPU 利用率、空闲率、模型命中率和冷启动时间。
- 可靠性：路由失败率、重试率、掉线恢复时间、重复执行率。
- 一致性与成本：跨节点输出通过率、每个成功任务的电耗、维护成本和云端替代成本。
风险边界
NVIDIA 的 GitHub README 披露，当前调度策略主要使用排队任务与平滑后的粗粒度 GPU 利用率。GPU 型号、可用显存、模型热度和请求成本需要业务层另行处理。高度异构的设备组更容易出现慢节点拖尾，团队要按设备类型分池，或在业务层增加超时与降级。12
“本地”只描述主要推理路径。模型从哪里下载、客户端是否发送遥测、Agent 调用了哪些外部工具，仍然需要逐项审计。PIN 和 mTLS 解决设备配对与传输保护，共享或由多方管理的局域网还需要额外的网络隔离与权限控制。
面试可直接说
我会把 PAIR 定义为请求级本地路由，显存池属于另一类基础设施。PAIR 能把多个独立请求分给不同设备，所以核心收益是减少排队、提高设备利用率；单个长请求的容量仍由一台设备决定。我会先确认并发负载，再测排队时间、模型命中、掉线恢复和每个成功任务的电耗。
可能追问
- 异构设备放在同一个池里，怎样避免慢节点拖累 p95？
- 多台机器的模型版本和量化方式怎样保持一致？
- 本地推理产品要怎样证明数据路径符合企业要求？
把三条串起来：模型之外，还有三层系统变量
Anthropic 的项目把复杂任务拆成依赖节点，并用验证器判定完成。Gemini 3.8 Flash 让产品按任务分配推理预算。NVIDIA PAIR 则把并发请求放到合适的本地节点上。
三条更新来自不同产品，三种机制也可以各自采用。产品经理可以用同一张检查表看它们：验证器定义结果，推理档位控制单次投入，请求路由管理并发资源。这张检查表把评估对象从模型回答质量，扩展到任务状态、失败恢复、人工接管、延迟和单位成功成本。
本期引用的证明规模、基准成绩、性能演示和安全评估均来自厂商、项目方或合作方口径。面试里可以用这些数字解释机制，产品决策则要回到自己的任务回放、灰度实验和真实账单。
References
- 1Formalizing Fermat's Last Theorem
anthropic.com
- 2FLT: Anthropic has beaten me to it
xenaproject.wordpress.com
- 3
- 4Sparks Fly: NVIDIA Accelerates Local AI at IFA 2026
blogs.nvidia.com
- 5
- 6
- 7anthropics/fermats-last-theorem
github.com
- 8Gemini 3.8 Flash developer guide
ai.google.dev
- 9Gemini 3.8 Flash Model Card
deepmind.google
- 10
- 11NVIDIA Personal AI Router
nvidia.com
- 12NVIDIA/Personal-AI-Router
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.