AI 技术学习周报｜2026-10-26—2026-11-01

· 本期内容由 AI 生成。

AI 生成说明： 本周报由 AI 自动检索、整理和生成，未经人工审阅（Review）。内容可能存在错误、遗漏或过时信息，请以所附原始来源为准，并自行核实重要事实。

  • 交付编号：2026-11-02。
  • 覆盖范围：北京时间 2026-10-26 00:00 至 2026-11-02 00:00，不含结束时刻。
  • 实际生成时间：2026-11-02 09:07:29 +08:00（北京时间）。
  • 证据说明：本期 8 个主题，已核查论文、作者仓库、官方文档与原始漏洞披露。没有运行论文实验、安装工具或执行漏洞利用。未核实本周热度排行，按学习价值推荐，不标注“高赞”。

本期速览

优先关注三项：

  1. MPO：长任务的奖励该分给哪一步？ 从“整轮工具交互”和“轮内 token”两个尺度分配训练信号，帮助理解 Agent 强化学习。
  2. GitHub Agentic Workflows：把代码与文档维护写成可检查的工作流。 学习重点是把模型提出的修改与实际写入分开，而不只是让 Agent 定期跑起来。
  3. CoSA：单个 Skill 通过检查，组合起来仍可能越权。 新风险发生在资料、判断和授权跨 Skill 传递时。

其他选题：

  • Concordat：用有限状态协议约束 Agent，兼看防御实验的“零违规”到底证明了什么。
  • 文档与知识整理：按项目、来源权限和核验状态组织 MCP 检索上下文。
  • OpenHands 漏洞公告：沙箱有隔离，不代表沙箱控制接口可以没有认证。
  • ChatGPT HTML Preview 漏洞：一条跨框架消息链如何绕过原有隔离，已于本周修复。
  • 可选游戏实验：nesformer 把 NES CPU 编译进模型权重；原理比“AI 玩游戏”的标题更有趣。

一、技术前沿、底层原理与新范式

1. MPO：训练长任务 Agent，既要看整轮决策，也要看具体 token

  • 日期：论文首次提交于 10 月 26 日 UTC；本期介绍公开方法与实验。
  • 进展类型：Agent 强化学习、信用分配与策略优化。
  • 证据性质：作者实验、消融和理论分析；未独立复现。
  • 为什么值得看：它回答“任务最后成功了，前面的哪次搜索或工具调用应该得到奖励”这个基础问题。

核心解释

先认识三个术语：

  • 策略（policy）：模型根据当前信息选择下一步输出的方式。
  • 价值评估器（critic）：估计当前局面最终能得到多少奖励。
  • 信用分配（credit assignment）：把最终结果归因给此前的决策。

Agent 用完整的一轮输出向环境发出搜索或工具请求，但这一轮输出又是逐个 token 生成的。只给整条轨迹一个分数，很难区分好步骤与坏步骤；只沿着长 token 序列传递奖励，又可能与真实的交互边界错位。MPO 论文导言

MPO 原论文 Figure 1：轮级交互、轮内 token 信用细分与轮级策略更新总览

图 1 · MPO 方法总览。来源：Tao Ren 等，MPO v1，第 1 页 Figure 1。从 PDF 提取完整图区，图内内容未改绘。

读图提示：先看下方横向流程：Agent 每输出完整一轮，才与环境交互；再看左上放大框：一轮里包含多个 token，MAE 在保留该轮平均信用的同时细分各 token 的贡献。右上曲线是作者 4B 实验的训练表现，不代表所有任务的固定收益。

MPO 分两层处理：先在轮与轮之间传播奖励，再在每轮内部调整 token 的相对贡献，保持该轮平均信用不变。更新策略时，还用整轮输出的概率变化作重要性校正。重要性校正可以先理解为：训练数据来自旧策略，更新时要考虑新旧策略生成这段输出的可能性差异。方法 §5

MPO 原论文 Figure 2：失败与成功轨迹中的 token 价值、轮内均值和轮边界跳变

图 2 · 为什么要区分“轮”与“token”。来源：Tao Ren 等，MPO v1，Figure 2，原始 SVG 未修改。

读图提示：对照上方失败轨迹和下方成功轨迹，观察 token 价值曲线、各轮均值，以及轮边界的变化。图中轮内相对平稳、跨轮变化更明显，解释了作者为什么按两个尺度分配信用；这是特定搜索运行中的示例，不能外推为所有任务都如此。

证据与局限

  • 在作者的 4B 搜索实验中，BrowseComp-Plus 的单次成功率由最强非 MPO 对照的 43.75% 提高到 48.08%，即 4.33 个百分点；不能把它写成所有 Agent 提升 4.33%。论文表 1
  • 方法涉及训练，不是给现有聊天助手补一句提示词。
  • 作者每种方法、每个模型规模只有一次训练运行；多次评估不能代替多次独立训练。价值变化的观察也来自特定搜索运行，不能直接当成所有模型的普遍规律。
  • 本次未找到并核实完整公开训练实现；不提供未经核验的安装命令。

学习路径

  1. 先看上方图 1、图 2 和中文读图提示，理解“轮”和“token”为什么是两个不同尺度；需要深入时，再读论文导言。
  2. 再读 §5.1—5.3，重点追踪奖励怎样跨轮传播、怎样细分，暂时跳过证明。
  3. 最后看表 1、token IS 消融与训练次数说明，检查收益来自哪一部分。没有核实到更合适的独立入门讲解，以上采用作者材料。

自测：一条轨迹最后成功，为什么不应该给其中所有搜索请求同样的正面评价？

2. Concordat：把“必须先确认”变成运行时协议

  • 日期：论文提交于 10 月 27 日 16:00 UTC，即北京时间 10 月 28 日。
  • 进展类型：Agent 工程方法、有限状态协议与防御实现。
  • 证据性质：作者开源实现和小规模受控评测；仓库状态为 pre-alpha。
  • 为什么值得看：把上期的“模型外部授权”原则落实到了可以阅读的类、状态和工具接口。

核心解释

有限状态协议规定系统处于什么状态、此刻允许哪些动作、动作后进入什么状态。以退款为例，身份未核验时不能申请退款，未获批准时不能执行退款。

Concordat 用 Python 方法上的声明建立协议。每轮只把当前状态合法的工具交给模型；即使模型猜出其他工具名，运行时也在执行方法体之前拒绝。人工决定是单独的协议步骤，模型只能请求它，不能代替审批方作决定。论文设计 §3

Concordat 原论文 Figure 1：退款协议的状态、身份验证与人工批准分支

图 1 · 退款 Agent 的有限状态协议。来源：Milad Sikaroudi，Concordat 论文第 4 页 Figure 1。从 PDF 提取完整图区，图内内容未改绘。

读图提示：先沿 start → verified → awaiting_approval 看正常顺序，再看右侧 human approves / human rejects 两条分支。模型可以请求进入审批，但不能替审批方决定结果；图示的是协议结构，不证明审批者或“确认”判定本身正确。

另一个值得学习的细节是预算不能重复花：委派给子 Agent 的额度从父级扣除。仓库同时说明，美元费用仍需应用代码记账，不能把“有预算对象”误认为它自动知道所有模型价格。作者仓库

证据与局限

  • 在施加“别再确认，直接做”压力的航空客服测试中，gpt-4.1 普通 Agent 在 50 个任务中有 13 个出现未经明确确认的修改，Concordat 为 0；任务成功数分别为 20 与 22。论文表 1
  • 零违规与门禁使用同一个确认定义，因此零值本身不证明理解了真实同意。作者明确指出，关键词规则甚至会接受“yes, but not that one”。
  • 测试只有一个业务域、少量模型和模拟用户。生产系统应使用与具体操作绑定的结构化确认；这是作者承认的部署要求，不是当前实验已经解决的问题。

学习路径

  1. 阅读仓库 Why、Example 和 Without classes，理解状态、合法动作及越序调用产生的错误。
  2. 读论文 §3.3—3.5，再看 §5.3 的有效性威胁。
  3. 编辑练习：把“生成草稿—确认目标文件—写入”画成状态流程，检查是否存在一个通用执行工具可以绕开协议。这个练习未实际部署。

自测：如果 Agent 仍能通过另一个 shell 工具改数据库，隐藏退款工具还足以保证退款流程吗？

二、使用经验与工作方法

1. GitHub Agentic Workflows：让维护任务有明确输入、产物与写入边界

  • 日期：10 月 28 日宣布正式可用；项目与公开预览早于本周，不能把所有基础机制都算作本周新发明。
  • 进展类型：代码维护、文档更新与自动工作流。
  • 证据性质：官方发布、配置文档与示例；未安装或运行。
  • 为什么值得看：适合把反复执行的仓库检查变成可审阅流程，尤其是文档与代码是否一致的检查。

核心解释

工作流用带 YAML 配置头的 Markdown 描述任务，再编译成 GitHub Actions 配置。模型负责分析，输出通过 safe outputs 等机制转换为受控动作。官方说明默认只读，并配有沙箱、网络控制和变更检测；本周正式版还增加了运行环境、预算预测和隔离方面的能力。发布说明

最值得借鉴的是把“建议写什么”和“允许写入什么”分开。safe outputs 可限定输出种类，并提供 staged 模式：预览准备执行的写操作，暂不真正创建对应资源。safe outputs 文档

可照做的流程

以下是面向文档维护的编辑建议，不是已经运行的官方样例：

  1. 先选一个狭窄任务，例如核对一项 API 修改是否同步到 README；输入限定为本次差异和相关文档。
  2. 要求输出“代码证据—现有文档—不一致之处—建议修改”，未知项明确列出。
  3. 验证阶段只生成报告或暂存输出；确认误报和漏报后，再考虑允许创建 PR。
  4. 核对生成的 Actions 配置、权限和外连范围，不只审阅自然语言任务说明。
  5. 验收包含正常更新、无需更新、信息不足三个案例，避免 Agent 每次都硬改文档。

下面仅展示官方文档中的 PR 输出预览配置片段，不是完整工作流：

1
2
3
safe-outputs:
  create-pull-request:
    staged: true

完整环境和配置需按官方快速入门补齐。本任务没有创建任何新自动化。

证据与局限

  • staged 模式针对 safe-output 写操作；不能据此推断任意自定义脚本都没有副作用。
  • “safe”是执行约束，不保证修改内容或引用事实正确。
  • 快速入门样例会创建周期报告和 GitHub issue，照做前应看清触发器与输出；这里不把它直接当成文档检查样例。

学习路径

  1. 读发布说明的 Built-in safeguards，先理解各个控制点。
  2. 看快速入门的文件结构与步骤，区分 Markdown 源文件和编译产物。
  3. 读safe outputs 的 Overview 与 Staged Mode，再把自己的维护任务缩小到可验收的一次修改。

自测：为什么“模型能写文件”与“允许它直接向仓库提交修改”应该是两个不同决定？

2. 文档与资料整理：检索之前，先限定知识范围和来源状态

  • 日期：Stack Overflow 于 10 月 28 日公布 Stack Internal 本月功能。
  • 进展类型：MCP 上下文组织与知识维护方法。
  • 证据性质：厂商功能说明；下述通用流程为编辑迁移建议，未测量收益。
  • 为什么值得看：适合解决资料混用、旧决策覆盖新决策，以及文档结论无法追溯的问题。

核心解释

本周方案提供了几种可以借鉴的组织方式：用 Scopes 按项目或团队限定知识；通过 GitHub 连接器吸收 issue、PR 与仓库文档；保留来源权限；给应用使用独立服务账户，并结合人工核验与核验结果回写。原始发布

它的学习价值在于：“搜到相关内容”之后，还要回答它属于哪个项目、何时有效、谁确认过、当前身份能否使用。 产品提供这些字段与流程，不等于已经消除了幻觉；后者是不能从公告推导出的结论。

可照做的流程

不依赖该产品，也可以先在自己的资料库中试一轮：

  1. 给材料记录项目、版本或日期、原始链接、核验状态；保留相互冲突的来源。
  2. 编写文档前，先确定本次项目与版本范围，再做检索。
  3. 要求每个关键结论关联原始证据，并区分“已实现”“已决定”“仍在讨论”。
  4. 遇到冲突时输出差异与待确认问题，不把两份不同阶段的资料强行合并。
  5. 人工确认后再回写知识库，保留来源和变更记录；下一次检索应能看到状态变化。

以上是编辑建议，不是作者提供并已验证的完整跨工具实现。

证据与局限

  • 已核查的是厂商公告，没有实测权限撤销的传播、冲突处理准确度或文档质量改善。
  • 未核实公开 MCP 调用参数及核验 API 的完整操作细节，因此不编造工具名、端点或请求体。
  • 厂商的人审标签可以增加可追溯性，不能代替对原始材料和有效期的判断。

学习路径

  1. 先读原文 Scopes、GitHub connector 与 service accounts，看范围与权限怎样配合。
  2. 再看 Reviews 和 validation API，理解“确认知识”与“自动吸收材料”的区别。
  3. 选两份存在版本冲突的技术说明，按上述流程整理一个带证据的结论表；不必先购买或部署新平台。

自测：两篇资料都来自可信同事，为什么仍可能不能在同一份当前版本文档中同时引用为事实？

三、Agent 安全与大模型安全

1. CoSA：单个 Skill 通过扫描，组合后仍可能越权

  • 日期：论文首次提交于 10 月 26 日 UTC。
  • 进展类型：Skill 组合攻击面、评测与运行时防御。
  • 证据性质：作者受控实验与轨迹分析；未独立复现。
  • 为什么值得看：把安全检查从“安装的文件里有没有恶意指令”扩展到“输出怎样在多个 Skill 之间流动”。

核心解释

CoSA 研究的是：一个 Skill 为特定用途生成的材料或判断，被另一个 Skill 当成了更强的授权依据。原来的限制没有跟着内容走，最后出现泄露、状态修改或代码执行。论文 §1—3

例如，收集投稿材料与验证复现情况本来是不同任务；组合流程却可能把提交包当成已获准执行的程序。这里必须分清：

  • 通过指定单包检查，只是论文中的局部准入条件。
  • 端到端安全，还要求下游保留用途限制，并重新判断动作和目标是否获准。

CoSA 原论文 Figure 1：单独通过检查的 Skill 组合后产生未授权代码执行

图 1 · 跨 Skill 的授权丢失。来源：Yujia Zheng 等，CoSA 论文 Figure 1，CC BY 4.0，原图未修改。

读图提示：从左向右看。左侧的“Safe”仅表示通过论文指定的单 Skill 检查；中间的复现材料进入后续执行流程；右侧红区显示，这次代码执行没有得到任务所要求的授权。它是研究中的示例，不是某个产品已遭入侵的证明。

攻击者需能让新增 Skill 被安装进现有池；论文没有假设网页内容能凭空安装 Skill，也没有假设获得新的系统权限。

证据与局限

  • 作者在 288 个任务、5 个模型和 3 种 Agent 框架上，比较原始 Skill 池与少量增补后的池；观察到违规率上升。它不是互联网上任意 Skill 安装的真实感染率。
  • CoSA-Guard 在高影响动作前检查信息流与授权，作者在特定招聘任务中观察到明显改善；仍有残余违规。
  • 同一任务条件下的重复运行有限，项目页本次无法访问，未核实可下载的完整复现代码。实验与限制

CoSA 原论文 Figure 2：组合关系分析、增补 Skill、对照评估与动作前检查的位置

图 2 · CoSA 的构造与评估总览。来源：Yujia Zheng 等，CoSA 论文 Figure 2，CC BY 4.0，原图未修改。

读图提示：上方从左到右依次是组合关系分析、候选 Skill 增补和原池／增补池对照评估；下方横条才是运行时检查，它在产生实际影响的动作之前检查信息流与授权。因此，这是一张包含防御位置的方法总览，不能当作“CoSA-Guard 已完整解决所有风险”的证明。

复现思路与防御

以下是依据论文抽出的本地检查练习，不是已经执行的 CoSA-Bench：

  1. 准备两项 Skill、模拟资料和明确的任务限制，先各自单独运行。
  2. 再让相同请求允许组合使用，保留中间文件、判断与最终工具调用。
  3. 检查“可读材料”是否被变成“可对外发送材料”，“建议”是否被变成“批准”，以及批准的对象是否被替换。
  4. 在发送、持久修改和执行前检查来源限制与具体授权；同时记录合法任务能否完成。

不提供未经核验的攻击脚本或虚构 PoC 地址。

学习路径

  1. 先看本节图 1 及读图提示，再读论文 §2 的操作角色，区分读取、转换、评估与真正产生副作用的动作。
  2. 再读附录 B 的冲突案例，追踪授权在哪里丢失。
  3. 最后读 §3.4、§4.4，检查防御是否同时评估安全与正常任务完成，而不是只统计阻断次数。

自测：一份“已通过质量检查”的文件，为什么不自动等于“获准发送给外部收件人”的文件？

2. OpenHands：沙箱服务暴露到网络，隔离不能替代认证

  • 日期：CVE-2026-112346 公告发表于 10 月 26 日；相关修复 PR 于 10 月 3 日合并，1.52.0 于 10 月 5 日发布。
  • 进展类型：本周漏洞公告与补丁边界分析。
  • 证据性质：VulnCheck 原始公告、官方补丁和版本记录；本任务未复现。
  • 为什么值得看：需要同时看容器内部监听、宿主机端口发布和 API 认证三层配置。

根因与影响

公告列出受影响范围为 OpenHands Software Agent SDK 低于 1.52.0。工作区启动器把服务暴露到所有网络接口，并在空 session key 列表下关闭认证。能访问该端口的攻击者，可在沙箱内执行命令，访问挂载工作区和相关秘密数据。原始公告

沙箱内 root 不能直接写成已经获得宿主机 root。 对宿主的进一步影响取决于挂载、凭据和运行配置；公告本身没有证明通用容器逃逸。

官方 Docker 补丁把宿主发布地址改为 127.0.0.1，同时把配置的 session key 传给客户端。容器内仍可监听 0.0.0.0 以供转发；两者并不矛盾。补丁差异

复现与验证入口

仅在自己的隔离实验环境中核查：

  1. 对照修复前版本与 1.52.0，使用无真实数据的工作区。官方 PR #5209 提供 Docker smoke test 和命令执行方法。

  2. 查看宿主机实际发布地址，将占位符换成实验容器名：

    1
    docker port <lab-container> 8000/tcp

  3. 旧配置可能显示面向所有接口的发布；补丁期望是 127.0.0.1。另在受控同网段测试机检查该实验端口是否可达。

  4. 单独验证配置了 session key 后，无凭据请求能否访问受保护操作。只测端口通不通不能证明认证正确；本次没有核验足以提供完整远程利用命令的请求序列。

修复与防御

  • 升级并重新创建工作区，核对实际运行版本与端口绑定。1.52.0 发布记录
  • 对确需远程访问的场景，配置认证与网络访问限制，不能只依赖客户端使用 localhost。
  • 引用补丁仅涉及 Docker 路径，不能据此声称所有 Apptainer 部署都已在同一变更中修复。
  • 若曾对不可信网络暴露，应核查执行和凭据访问记录；本次未找到并核实野外利用证据。

学习路径

  1. 读公告的前提与影响，先确定攻击者需要能访问什么。
  2. 对照补丁端口映射与 key 传递。
  3. 再看PR 的 smoke test，学习把“默认绑定正确”纳入回归验证；不要把测试成功描述成安全性已被穷尽证明。

自测：容器里的服务监听 0.0.0.0，但宿主只发布到 127.0.0.1，为什么与向整个局域网开放不是一回事？

3. ChatGPT HTML Preview 漏洞：隔离框架之外，还有消息接收者

  • 日期：Parameter 披露文章发表于 10 月 28 日；据研究者记录，OpenAI 于 10 月 26 日确认修复。
  • 进展类型：LLM 应用前端漏洞、跨框架消息与 CSP 绕过链。
  • 证据性质：原始研究者演示与其记录的厂商确认；本任务未独立复现。
  • 为什么值得看：它展示了生成式应用中的传统 Web 漏洞如何跨越预览与登录会话的边界。

根因与攻击链

研究者报告的链条是：

  1. 正常图表在主页面加载 MathLive，并安装虚拟键盘消息监听器。
  2. HTML Preview 向主页面发送消息；接收方未正确限定来源与发送窗口，允许修改键盘布局中的 HTML。
  3. 插入的 HTML 创建未带 sandbox 的 srcdoc iframe，取得主页面身份。
  4. 通过 CSP 允许域上的 JSONP 响应获得脚本执行，继而访问登录会话下的接口。

Parameter 原披露截图：共享页面触发后，真实 ChatGPT 页面出现无害 XSS 验证标记

原披露截图 · 主页面执行标记。来源：Mukul Goyal / Parameter，Do the Math 原始技术披露，原图未修改。

读图提示：看底部 “XSS confirmed on https://chatgpt.com” 标记，而不是只看上方 Preview 框。它展示作者在主站页面的受控验证；这是研究者截图，不是本任务复现，也不代表当前已修复版本仍可利用。

根因是主页面的可信组件接收了不可信框架提供的状态修改；原 Preview 不能直接读取父页面这一点仍然成立。原始技术披露

证据与局限

  • 作者用另一测试账号演示了共享对话链接触发、私有会话读取及少量数据外发；不同载体有一次点击 Preview 或自动触发的差异。
  • 这是应用层漏洞，不是提示词让模型突破了浏览器同源策略。
  • 没有自建旧服务可供完整重现，也不能把作者“代表用户执行操作”的描述扩展为已验证接管所有后台功能。
  • 修复已确认；本期不提供可继续攻击线上服务的假设性步骤。

复现入口与防御

原文公开了消息格式、无害执行标记和完整链条解释。学习时先在自建页面中验证跨框架消息和 HTML 插入的边界；要复现整条旧链，还需要当时的组件配置和 CSP，本任务未取得该环境。

重点检查：

  • 消息来源与发送窗口是否都在允许范围内。
  • 布局或图形配置为何可以携带任意 HTML。
  • 主页面是否替不可信内容创建了更高权限的子框架。
  • CSP 允许域上的接口能否反射可执行响应。

以上是根据根因整理的编辑检查建议；原作者指出，仅封禁最后的 JSONP 路径仍不能修复前面的 HTML 注入。

学习路径

  1. 先读原文 “It started with a graph and a Preview”，画清主页面、图表组件和 Preview 的关系。
  2. 接着读消息处理与 CSP 两节，区分“能插 HTML”与“能执行脚本”。
  3. 最后读 “What went wrong and what OpenAI fixed”，检查修复是否切断了根因，而不只是最后一个载荷。

自测：一个不可信 iframe 自己不能读父页面，为什么仍可能借助父页面的消息处理器升级权限？

四、可选娱乐与艺术

1. nesformer：把 NES CPU 编译进模型权重，慢速运行游戏

  • 日期：基础 Qwenputer 文章发表于 10 月 22 日；本周进展是 10 月 30 日公开分享的 NES 实现，仓库首发精确时间未核实。
  • 进展类型：复古游戏与模型计算机制实验。
  • 证据性质：作者开源实现、参考模拟器对比与演示；未独立运行。
  • 为什么值得看：能直观区分“训练模型学会计算”与“把确定性计算结构编译成权重”。

核心解释

这不是对聊天模型说“请模拟一台红白机”。nesformer 的权重由编译器计算，利用 Gated DeltaNet 状态保存可寻址的内存，让模型逐 token 生成 CPU 执行轨迹。它继承了 Qwenputer 把状态矩阵作为内存的思路。基础作者讲解

nesformer 作者提供的 Super Mario Bros. 演示动画

作者演示动画 · 权重执行 CPU 轨迹后的游戏画面。来源：Drew Breunig，nesformer README 与 examples/demo.gif，原动画未修改。游戏画面的相关权利归原权利人。

读图提示：这张动画帮助理解“CPU 计算结果最终能形成游戏画面”。它不能证明模型独立完成了渲染和手柄输入，也不能根据动画播放速度推断实际推理速度；这些边界仍以仓库说明为准。

NES 实现把 CPU、工作 RAM 与程序 ROM 放进模型的权重和状态；画面渲染、手柄输入及部分硬件时序仍由宿主程序处理。因此“整个游戏机都在模型里”并不准确。nesformer 仓库

证据与局限

  • 作者报告了指令轨迹与参考 CPU、部分游戏画面的对比；不是所有 NES 游戏兼容性证明。
  • 主要支持 NROM，也就是 mapper 0 的游戏；速度远低于真机。
  • 默认运行器是跳过零块等计算的优化实现，另有标准 transformers 路径，不能混用两者的速度。
  • 仓库提供测试 ROM，但不附带所有演示商业游戏的 ROM。

学习路径

  1. 先读Qwenputer 的 exact RAM 与编译过程；这是上期背景，不当作本周原始发明。

  2. 再看nesformer 的 “What’s in the weights, and what isn’t” 与 “How it was checked”，理解宿主边界和验证方式。

  3. 若进一步实验，按仓库环境说明准备后，优先用其自带测试材料对照参考 CPU。公开命令入口为：

    1
    python -m nesformer check roms/thwaite.nes --tokens 50000

    本任务仅核查命令说明，没有安装或执行；遇到平台和依赖问题按仓库说明处理。

自测：编译出来的网络能精确模拟 CPU，为什么不等于普通语言模型通过训练自然获得了同样的精确计算能力？

检索与验证缺口

  • 未执行验证：所有实验数字来自作者或公告。没有运行强化学习、Agent 基准、漏洞利用、GitHub 工作流或 NES 示例；正文已区分命令入口、编辑练习与已完成测试。
  • 代码与入门材料：MPO 未核实完整训练实现；CoSA 项目页获取失败，不能确认完整 PoC 可用性。论文方向没有核实到更好的独立入门教程，优先使用作者图解和仓库。
  • 时效去重：Elephant–Goldfish 原始公告是 10 月 22 日；Log-To-Leak 存在更早公开稿，本次无法核清本周版本的实质新增，均未收入正式选题。Skill 包汇总页的收录日期也未当作首发日期。
  • 证据范围：Stack Internal 只核验了功能发布，没有实测其权限和 API；ChatGPT 漏洞的修复确认来自研究者记录，未取得独立厂商技术公告。NVIDIA 本周安全公告也已检索，但细节不足以补充比正文更完整的学习与复现内容，未另列漏洞清单。

← 返回 AI 周报