值得读 Agent 系统 / AI 编程 / 评测与基准
追踪记录 ↗
Dan Jones、Alexandra Godoi、Grant Bourzikas · Cloudflare Blog 基础设施 本期补读 · 单仓技能与内部框架分别说明
技术 Multi-Agent Coverage Tracking Adversarial Validation SQLite
Cloudflare 公布了一套从单仓库审计技能扩展而来的漏洞发现流程。这里的 harness 是围绕模型的执行框架：它保存任务、调用工具、安排验证，并在中断后接着运行。最初的技能让不同 Agent 负责了解架构、寻找攻击路径和尝试推翻发现；扩展到多个仓库后，真正增加的是状态保存、覆盖记录、去重与依赖追踪。
团队把每阶段写入 SQLite，以运行、仓库和阶段识别任务，发现一项便保存一项。覆盖账本记录代码区域与攻击类别，薄弱处产生新任务；如果一个可疑路径超出当前范围，就另建明确任务继续调查。缺少构建环境或虚拟机时，系统记录所需条件，等条件齐备再重跑，而不是让不完整的结果混进已验证队列。
验证分两层：固定程序检查文件、路径及报告结构，新的 Agent 再尝试推翻漏洞假设。团队要求已确认发现的复现测试针对未改动的原代码，随后由另一套系统去重、判断生产环境能否到达该路径，再准备修补。开源 security-audit-skill 是单仓库起点，并不等于公开了这套完整内部系统。
原文累计流程图显示，20799 条初始候选中约12057条通过第一轮验证；它们与另一套工具的输入汇合后，再经去重与适用性判断，留下7245条交给团队处理。不同节点的分母不同，不能据此计算真实漏洞召回率。作者明确没有全部真实漏洞的标签集，也说明这些数字来自隔离研究环境；图中数量不能解释为线上仍有同样多未修复漏洞。
查看大图 ↗ 图片暂不可用，请查看来源。
Cloudflare 自报的候选筛选流程。左侧通过验证的12057条与另一工具的1784条合并，形成右侧13841条输入，之后留下7245条交给工程团队；这是累计研究流程数量，不是线上未修复漏洞数或召回率。Cloudflare Blog，原文流程图；为评论其筛选口径引用单张图。 · 原文图表 · 图片出处 ↗ Cloudflare 作者团队 · 原帖 / 原文 语境：从单仓技能发展为内部跨仓扫描系统的工程复盘。 · 读取时间：2026-10-25T00:10:29.401042+00:00
逐句忠实转述（非原文） 团队认为，应先让提示词在一个仓库里产生真实结果，再按瓶颈添加编排层。持久化应早于大规模并发：一次连接错误不应该抹掉数小时工作。作者没有声称知道漏掉了多少真实漏洞，而是观察重复扫描是否仍有新增发现。
编辑评读
这套实践值得借鉴的是把“未完成”保留成可继续的对象。缺一个环境、只检查了某个入口、找到了可能同源的缺陷，都有不同后续动作。若只保存最终报告，下一次运行很容易从头猜测，或把上次没有查完当成已经覆盖。持久化因此不仅是防崩溃，也决定哪些证据能跨轮次积累。
“独立验证”仍要按具体含义理解。更换 Agent 可以隔开上下文，更换模型可以增加不同搜索路径，但并不保证错误在统计上独立。更强的约束来自原代码上的可重放结果，以及生产配置能否让攻击者走到该路径。开源技能的三种状态也有意义：已确认、待验证、已否定各自保留，不用一个严重性分数掩盖未解的问题。
对小团队，可迁移的起点是任务表、原始证据与一个不能自行提交新发现的验证角色；跨仓依赖追踪则要等实际需求出现。本文没有运行整套框架，不能给出本地漏报率或费用收益。应当把“报告格式可校验”和“安全判断成立”作为两项不同的验收。
依据 1 · 依据 2
值得读 系统与效率
追踪记录 ↗
Zagitta · GitHub 项目与用户问题记录 基础设施 v1.0.0 · 用户记录10月22—24日
技术 BF16 Tensor Cores Prefill GPU Kernel
GPU-unlock 是面向部分 NVIDIA RTX 30 系显卡的 Linux 内核模块。它试图提高半精度浮点计算的指令发射速率，也就是单位时间能送入计算单元的运算数量。它在官方驱动接管显卡之前设置速率选择器并重置设备，随后仍使用未修改的 NVIDIA 驱动；作者强调，封装这段启动过程可以减少每次驱动更新后重新打补丁的麻烦。
项目给出 RTX 3090 Ti 在 450 W、8192³ 稠密矩阵乘法、FP32 累加条件下的五次测试中位数：BF16 从 87.50 增至 157.41 TFLOPS。这是矩阵计算吞吐，不是聊天模型的输出速度。语言模型先处理整段输入的 prefill 阶段，较容易受益于矩阵算力；随后逐个生成 token 的 decode 阶段，还可能主要受显存带宽限制。
用户报告把差别具体化了。robertoetcheverryr 的 RTX 3090 在 16K 输入上，处理速度从 2594 增至 3009 token/s，首 token 等待从 6.35 秒降至 5.48 秒；4K 输入处理与短输出生成基本不变。另一位用户的 GA102-250／RTX 3080 Ti 20 GB OEM 卡则在选择器写入成功后仍保持半速。型号、功率与工作负载都需要保留，不能把“解锁”这个日志状态当成收益。
语境：作者在项目的 HN 讨论中解释工程取舍。 · 读取时间：2026-10-25T00:10:29.401042+00:00
逐句忠实转述（非原文） 作者说明，底层利用办法并非由他提出；他的工作是把已有方法包装成较少折腾的启动模块。他也厌倦不断修改驱动，希望后续把其他系列纳入同样的路径。
robertoetcheverryr · 原帖 / 原文 语境：Debian 13、Zotac RTX 3090、350 W 上限的个人兼容性报告；不是统一实验室复测。 · 读取时间：2026-10-25T00:10:29.401042+00:00
逐句忠实转述（非原文） 他先报告安装与驱动加载正常，再给出矩阵吞吐和 Strata 的不同长度测试。收益主要出现在16K输入处理，4K输入处理和短输出没有同等变化；这些细项比单个峰值更接近他的实际使用。
语境：GA102-250 OEM 卡未获得 BF16 提速的排查记录。 · 读取时间：2026-10-25T00:10:29.401042+00:00
逐句忠实转述（非原文） 他确认选择器没有被驱动恢复，又在约203 W的固定频率条件下检查，结果仍符合半速计算。因而他追问，这个芯片是否还有另一条限制路径，或应该明确列为不受支持的型号。虽然没有获得提速，他仍肯定工具和其他报告使问题更容易诊断。
编辑评读
最有用的新能力，是让一部分已有显卡的计算资源更充分地参与工作；但选型时应该先识别自己的等待发生在哪一段。如果长文档进入模型前的处理占大头，prefill 的改善可能直接缩短等待；如果主要时间花在很长的输出，矩阵测试的大幅上涨就未必改变体验。把两段时间分开，能避免为了一个不占主要时间的环节承担额外维护工作。
失败报告尤其有价值：写入值在驱动加载后仍存在，说明“驱动把设置改回去”不足以解释这块卡没有变快。用户还用较低固定频率排查功率限制，留下了更具体的硬件适配问题。这不是对所有卡无效的反证，而是提醒验证需要走到目标运算本身。下一步值得比较同一台机器、同一软件栈的前后运行，并保留输出一致性和长时间状态；本刊没有安装模块或执行这些实验。
依据 1 · 依据 2 · 依据 3
