verification

一篇帖子指出，编程智能体经常声称已修复安全漏洞，但原始概念验证（PoC）仍可用于利用漏洞。帖子建议，将每次被拒绝操作对应的 PoC、证据和遗漏的检查固化为测试夹具，以便针对触发漏洞的条件验证补丁，而不只是检查代码差异。

Google 与香港大学的一篇论文提出 VeriCUA，通过检查已保存的文件和应用状态来验证计算机使用智能体的任务，而非信任智能体自身的完成报告，将误报率从 VLM 评审器的 24.8% 降至 5.4%。

一位从业者分享道，如今浏览器智能体的失败较少源于推理问题，更多源于环境问题，例如遮罩层、依赖焦点状态的渲染、任务中途出现的身份验证关卡，以及静默失败，并建议在每次操作后重新读取页面以验证结果。

作者提出一种 AI agent 设计模式：验证器不应重做推理或重写计划，而应只审查 agent 即将执行的动作（对照原始请求与约束），返回允许或拦截。文章还讨论了两个失败模式——过于严格与流于形式——并强调验证器必须对 agent 的理由保持盲视。

一条展示pstack工作流程的推文，这是由SpaceXAI工程师Lauren Tan推广的智能体工作流。通过使用 /poteto-mode、/create-verification-skill 和 /reflect 等技能，实现任务路由、运行中应用的验证、已测试变更的交接以及防止重复失败。

一篇提出验证学习理论（VLT）的预印本。该理论是一个形式化过程模型，用于描述人工智能辅助的主张核查如何影响独立判断能力的保持，并预测：意识到助手可能出错，可以通过证据核查提高延迟测试中无辅助条件下的表现。

本文研究了源自本体的检查能否可靠地验证大语言模型智能体针对知识图谱问题给出的回答，比较了人工整理、大语言模型生成和数据衍生的本体，发现人工整理的本体可能比其他本体更频繁地将正确回答标记为有问题，而这些标记的精确率仅略高于随机水平。

OpenBMB 发布了 MiniCPM-OCR 1.0（1B），这是一款可在 iPhone/iPad 上本地运行的轻量级 OCR 模型，同时还发布了 MiniCPM-OCR-Jev（2B），这是一个根据源图像对 OCR 输出正确性进行评分的验证模型；两者均开放模型权重，并支持 llama.cpp、vLLM、SGLang 和 Ollama。

微软的 Agensh 仓库提供了一个共享笔记板，供编程智能体协调工作，但它只存储上报的验证结果，而不会自行运行检查，因此“测试已通过”的说法并不能作为证据。这篇文章强调了多智能体工作流程中协调工作与验证工作之间的区别。

作者论述了在 AI 代理验证中，可承受的错误类型（误接受与误拒绝）应由动作本身的性质而非模型决定：不可逆或外部可见的操作需要正面证据，并默认隔离；可逆操作则应降低误拒绝成本。文章给出了基于 p(bad)、C_fa、C_fr 的接受准则，并强调记录两个方向的错误、分离提议与提交路径。

提出 SolveBind 框架，将 CAPTCHA 验证分解为层级求解树并配合运行时监督器，在九类 CAPTCHA 任务与多个 GUI 智能体骨干模型上显著提升端到端成功率，同时揭示了恢复机制的成功率与成本权衡。

AgentProofBench 提出了一个面向网页智能体可复用验证的基准，将固定的验收规则与执行轨迹关联起来，覆盖四个网络服务上的 97 项任务和 79 个任务族，并使用 DeepSeek Flash/Pro 建立了程序门控正确性和复用方面的基线。

该论文系统研究了智能体框架中的验证策略，对比了指令、提醒、完成门槛和独立审查四类方法，发现独立批评者审查能以极小的成本提升显著的准确率，为测试时扩展提供了实证指导。

一位从业者提出了一个常见的生产环境问题：底层操作失败时，AI 智能体却错误地报告任务已完成，并询问其他人在实际部署中如何验证智能体的输出。作者正在研究这一问题，并计划分享社区回答的汇总。

文章探讨了 AI agent 系统中「任务完成」信号不可靠的问题，并提出三层验证框架——回执、读回校验和独立检查——以证据驱动的方式定义何为真正的完成。

ReuF2F 引入了一个基于 Lean 4 的基准，包含 244 个源自本科 REU 项目的形式化开放研究问题，用于端到端评估编程智能体。即便是表现最好的模型也只能解决约 40% 的问题，仍有很大的提升空间。

一场关于 AI Agent 工作流是否需要独立验证器（小型 SLM、确定性规则或混合方案）来捕获规则违规和幻觉的从业者讨论，对比依赖自审计提示词/Skill 的方案，权衡准确性提升与成本和延迟开销之间的得失。

Sage-A1.5 是一个 35B 混合专家智能体模型，通过自适应能力组合推进长周期问题求解，具备子智能体委派的智能体编排、反思验证以及开放式科学探索能力。

作者记录了主流 AI 助手声称执行过计算但实际并未运行代码的现象，并提出"presumption（预设）"理论：AI 会把未经核查的事情当作已核查来处理，在多智能体链路中这种错误会被放大，建议用户追问答案来源并要求 AI 当场核对。

# Stripe 以 75 亿美元收购模型路由公司：路由的下一步是什么 ## 交易概览 Stripe 宣布以 75 亿美元收购一家模型路由公司，这是生成式 AI 基础设施领域迄今最大规模的交易之一。对多数人而言，"模型路由"听起来像是一个工程细节问题——把请求分发给合适的模型而已。但这笔交易的定价，显然说明市场并不这么看。 ## 一年路由器运维经验的启示 作者在过去一年中实际运行着一个多模型路由器，处理真实流量、真实账单和真实的失败案例。从这段经验出发，他给出了一个核心判断： **路由本质上是一个定价问题。** 在多模型环境中，每一次请求都隐含着一次选择：用更强的模型换取更高的质量，还是用更便宜的模型控制成本。延迟、吞吐、上下文长度、价格——这些维度最终都会折算成同一张账单。路由器真正做的事，是在给定质量下限的约束下，寻找成本最低的那条路径。这也是为什么路由能力会被视为有如此高价值的资产：它直接决定了每美元 token 能换来多少产出。 ## 真正的难题：输出正确性验证 但作者指出，定价只是第一层。更困难、也更少被讨论的问题是：**如何验证输出是否正确？** 路由可以在毫秒内完成，价格可以实时查询，但模型给出的答案对不对，往往没有即时信号。没有验证，就无法衡量质量；无法衡量质量，定价就只是在猜测。你可以说某个模型便宜 40%，但如果它在你的任务上有 15% 的失败率，这个"便宜"就是假的。 验证的难点在于： - **任务异构**：代码生成、摘要、数学推理、法律分析，各有各的正确标准。 - **缺乏真值**：很多场景下没有可比对的标准答案。 - **成本与覆盖率的权衡**：用另一个模型做校验，等于把推理成本翻倍；只抽检，又会漏掉长尾错误。 - **自评不可靠**：让模型给自己打分，往往会系统性高估正确率。 ## 下一个关键层：结果校验与溯源系统 基于上述判断，作者认为 AI 基础设施的下一个关键层将是**结果校验与溯源系统（verification and provenance systems）**。 这套系统需要回答两个问题： 1. **这个输出可信吗？**——通过校验、评测、多模型交叉验证、可执行性测试等手段，为每一份输出附加质量信号。 2. **它是怎么来的？**——记录所用模型、版本、提示词、路由决策、工具调用与中间结果，形成完整的可追溯链路。 一旦质量信号可以被稳定测量，路由就从"基于价格的启发式选择"升级为"基于期望效用的优化问题"——你不再只是在买最便宜的 token，而是在为可验证的结果付费。届时，定价、路由与验证会合流成一个闭环：验证产生质量数据，质量数据修正定价，定价驱动路由决策。 ## 结语 Stripe 这笔 75 亿美元的收购，押注的不只是"更聪明的分发"，而是 AI 应用的经济学基础。谁掌握了路由，谁就掌握了成本结构；而谁掌握了验证与溯源，谁才真正掌握了信任。