数据政策关键变化、Ox Alpha 揭晓、定制模型超越微调
各位朋友，
AI 工程领域的一项核心技能，就是驾驭 coding agent。无论是让它写代码，还是完成非编码任务（如分析数据、管理运维），你的掌控力直接决定了产出上限。
Coding agent 的迭代极快，这项技能本身也在飞速进化——比其他 AI 工程核心技能更快。闭源 agent（如 Claude Code、Codex、Cursor）和开源 agent（如 OpenCode、Pi）在框架与模型两个维度上都在大步前进。因此，跟上 coding agent 的最佳实践，本质上是一个持续实验、构建、学习的过程。
我们访谈了数十位顶尖 AI 工程师，并结合团队自身的使用经验，发现了一套高度一致的高层工作流，用于借助 agent 构建软件。关键步骤如下：
- 规划。包括：(i) 头脑风暴——可能涉及调研、实验、理解现有代码库（若有）；(ii) 编写规格文档，涵盖需求、技术设计与架构，再生成执行计划。你还可以审查计划，检验关键假设，排查安全隐患、过度设计等问题。
- 执行。构建、测试、验证，在 agent 自主性与人工监督之间取得平衡。具体包括：(i) 让 agent 构建软件，给予适度自主权；(ii) 通过自动化和/或人工检查来验证输出。
- 部署与监控。(i) 部署上线，可结合 CI/CD 流水线或额外的人工审核关卡；(ii) 用 agent 监控日志、发现异常、提出并执行改进。
这套高层工作流与 coding agent 出现之前的软件开发流程大同小异。区别在于，我们如今的重心从写代码转移到了：决定做什么、设计架构、编写规格、验证输出。
各步骤的耗时在不同项目间差异很大，而且可以省略某些步骤。例如，一个从零搭建的 greenfield 原型，其 spec 可能只用一段草草写成的 prompt 来粗略描述；而一个已有大量用户的 brownfield 存量项目，其 spec 在撰写和验证上可能需要投入多得多的精力。此外，整个流程高度迭代，熟练的开发者清楚何时需要根据后续步骤的反馈回退到更早的阶段。比如，验证未通过时，他们知道如何引导 Agent 重新构建并修复错误；监控暴露问题时，他们也知道如何让 Agent 更新系统并重新部署。
要在这种工作流中高效使用编码 Agent，核心技能包括：
- 把控工作流
- 赋予 Agent 自主性
- 审查产出
- 定制 Agent 及其环境
- 编码 Agent 基础
把控工作流。你清楚如何驾驭上述工作流中的每个环节，包括决定在每个步骤上分配多少人工与多少 Agent 的工作量，以及何时回退到更早的步骤进行迭代。这需要你对速度、成本、技术风险和人工投入之间的权衡有深入理解，从而决定前期需要多少调研和规划、哪些关键工作保留人工主导、如何选择架构、在规划文档（如 spec）中写入多少细节、以及如何将工作拆解为可验证的步骤。
赋予 agent 自主性。在把 coding agent 引入工作流的各个步骤时，你需要选择它的自主程度：是全程盯着它互动式地来回调整，还是把一大块工作整体交托给它？什么时候该设定明确目标，让它自主循环直到成功？此外，你还必须谨慎管理 agent 的上下文。随着构建进入不同阶段，你要把握时机，确保关键经验、用户反馈和各种假设——包括构建中途发生变化的假设——都被记录下来，供 agent 在后续环节使用。另外，你还要决定何时把任务拆解后交给多个 agent 并行运行——由人类或一个更高层的 agent 来统筹这些 agent——以及如何在多个并发的 agent 会话之间合理分配人的注意力。你还得懂得如何安全地运行 agent：合理设置权限、对操作设置门控，让开发快速推进的同时，把泄露、数据丢失等风险控制在可接受范围内。
审查工作成果。Coding agent 的产出是不确定的。我们事先无法知道它会想出哪些好点子，又会写出哪些 bug。审查和验证输出是确保拿到预期结果的关键步骤，结果不对时还能及时纠正 agent 的方向。你需要设计与任务相匹配的测试和验证方案，按需结合行为层面和功能层面的验证。你也可以测试用户流程，比如让 agent 提供截图作为成功或失败的证据。对于定性或行为层面的评估，可以使用 eval 集，必要时结合 LLM-as-a-judge。
你还需要决定这些测试中有多大比例应该自动化。有些工作流会把全部测试和验证都自动化，让 agent 能自查工作、判断任务是否完成。你必须评估这些测试是否与你的目标相符，不符时持续迭代。此外，你还会使用 agentic code review，并运行 AI 驱动的安全和架构审计。当 AI 审查不够可靠时，你会审慎地插入人工审查环节（主要审查代码行为，偶尔审查代码本身），同时探索如何进一步将这类审查自动化。最后，你还要验证部署结果，并可以用 agent 来落地监控和事件管理。
定制 agent 及其工作环境。你能同时更新 agent 本身和它运行的环境，使 agent 高效获取所需上下文、调用工具，并以正确且高效的方式构建代码。你熟悉如何集成 agent 技能、插件和 MCP server，也会在它们不再需要时定期清理（比如新模型让旧技能变得多余）。你可以用 hooks 自动化开发流程中可重复的环节，如触发自动代码审查或 CI/CD 流水线。你还能维护 agent 的工作环境：更新常驻上下文（如 AGENTS.md 或 CLAUDE.md），补充代码库信息、关键架构假设、代码风格和数据处理模式。你知道如何跨多个会话、跨并行 agent 保持状态一致，并随时间积累 agent 的经验——比如运行结束后做复盘，记录哪些做法有效、哪些没有。你也会建立统一的约定和结构，让 agent 能顺畅导航代码库，并定期清理 agent 产生的技术债务。团队协作时，你会考虑如何让不同开发者的 agent 之间协调上下文。
Coding agent 基础认知。最后，要做好全程决策，你需要理解 coding agent 的内部机制：它如何做代码库搜索/检索、如何管理上下文窗口、不同操作（如添加工具调用、MCP server 等）如何影响上下文、agent 与 subagent 如何交互，以及 agent 如何通过在 LLM 外包裹一个 harness 构建而成。这让 agent 不再是黑箱，也帮你识别各类失败模式：简单问题被过度设计、agent 缺乏显式验证流程导致严谨性不足、未达成目标就提前停止、agent 操作可能破坏文件或生产数据等。同时，它帮你判断 agent 的当前状态，通过给出正确的指令或上下文来引导它。在监控运行过程时，这种理解让你更能及时发现 agent 偏离轨道、需要人工介入的时刻。
我发现社交媒体上对 coding agent 用法的描述往往过于简化。比如，让 agent 自主运行数小时、消耗数百万甚至数千万 token 确实有其价值。但目前，超长任务的实际效用——尤其是相对于其成本而言——被过度夸大了。实际上，最高效的 coding agent 使用方式是一个复杂且高度迭代的过程，而能够以高水准的判断力适时介入，才能取得显著更好的效果。
你驾驭 coding agent 的能力会让你成为一个高效的构建者，也让你有资格把控整体开发方向。这封信的下一期我会进一步展开这个话题。
继续构建！
Andrew
来自 DEEPLEARNING.AI 的讯息
关于 coding agent 的建议大多止步于"给它更好的上下文"。在基于 JetBrains 构建的 Spec-Driven Development 课程中，Paul Everitt 系统讲解了这套方法论：项目宪法、每次变更对应的功能规格说明，以及"规划—实现—验证"循环。免费加入学习
新闻动态
对比 OpenAI 与 Anthropic 的数据留存策略
任何将私有数据交给 AI 模型或服务的用户，都有权获得三个问题的明确答案：(i) 数据存储在哪里？(ii) 保留多久？(iii) 拿到数据后会怎么处理（例如用于模型训练、展示给人类等）？本周，两家头部企业的商业客户各收到了一份回应：一份先遭泄露随后被官方确认，另一份则属于预览性质。两家在技术细节上的披露都相当有限。
Anthropic 的新动态：从六月起，使用 Claude Fable 5 的企业客户必须允许 Anthropic 将其对话记录保留 30 天。现在 Anthropic 将放宽这一规定，推出一项名为 Enterprise Frontier Safeguards（EFS）的新计划：采用零数据保留（ZDR）政策的企业可以把数据保存在自己的服务器或指定云服务商的服务器上。在今年秋季 EFS 正式上线之前，符合条件的企业客户使用 Fable 5 和 Fable 5.1 时，Anthropic 将不会保留任何数据。
OpenAI 也没闲着：就在彭博社报道 Anthropic 消息的前一天，OpenAI 发文承诺，面向商业客户，其最强模型将提供 ZDR 服务，也就是说 OpenAI 不会记录企业的提问和回复。这项服务面向把模型接入自有软件的已审核企业开放。文章还预告了 Private Safety Processing（PSP）系统，旨在不读取用户提问的前提下，识别分散在大量请求中的滥用行为。
具体原理：两家公司描述的方法如出一辙：由软件持续监测请求并标记可疑模式，无需人工审核。但双方都没说明的一点是：“我们的员工看不到数据”并不等于“我们的系统看不到数据”。要扫描数据，公司编写的软件就必须解锁并读取数据，无论它存储在哪里。Anthropic 技术团队成员 Sholto Douglas 在 X 上解释称，这种监测是“通过我们提供给你们的自动化系统完成的”。以下是两家公司的具体情况。
- 当前已生效的规定：根据 Anthropic 的帮助中心说明，该公司在所有平台上保留 Fable 5 和 Mythos 5 的对话记录，期限为 30 天。此外，Anthropic 可依据自主制定的流程标记特定内容，依据其通用政策，被标记的内容最长可保留两年，且经 Anthropic 批准的审核人员可通过留有日志的流程查阅这些内容。OpenAI 则声称，其员工无法查看 ZDR 客户的对话记录，联邦法律要求除外。
- 已承诺但尚未落地：Anthropic 表示数据保留期限仍为 30 天，但数据将存储在客户指定的服务器上——无论是客户自建服务器，还是通过 Google Cloud、Microsoft Foundry、Amazon Web Services 等第三方服务商托管。（利益声明：Andrew Ng 是 Amazon 董事会成员。）30 天保留要求不变，区别在于数据放在客户的服务器上而非 Anthropic 的服务器上，客户还可以自行管理加密密钥、审计日志及其他安全数据。OpenAI 的 Private Safety Processing（PSP）将扫描存放在客户服务器上的数据，或扫描在 OpenAI 服务器上以密钥加密的数据——OpenAI 称其员工无法接触这些密钥——扫描结果仅返回活动类型的标签，不返回具体内容。
- 两家公司的官方理由：EFS 和 PSP 主要针对的威胁是网络攻击。某些攻击仅在大量请求中才会显现。Anthropic 帮助中心列举了政府间谍活动和"best-of-N"越狱攻击——即攻击者将一条被拦截的请求改写数百次，直到某个版本成功突破。
- 尚未公开的信息：目前仍不清楚两家公司的软件如何读取它们声称"看不到"的数据。OpenAI 承诺九月份发布 PSP 的技术论文；Anthropic 已为其六月数据保留政策发布了技术文档，但关于 EFS 的具体工作机制几乎没有披露细节。两家公司均未公开判定某项内容属于"网络攻击"或"不安全"的具体标准。
新闻背后： Anthropic 六月的新规打破了部分企业客户已有的 ZDR 合同，这些客户必须开启数据保留功能才能使用新模型。因此，大量企业拒绝使用 Fable 5。正如我们六月报道的，ARC Prize 基金会也拒绝运行对 Fable 5 的验证测试，不愿暴露其私有测试题目。Anthropic 此后已承认这一代价；在八月的风险报告中，它写道，该规则"将令习惯了零数据保留的客户不满"，若竞争对手不跟进，可能损害其业务。OpenAI 并未如此；其公告重申了零保留立场。
为何重要： 企业如今只能根据新闻稿来决定是否将这些模型用于敏感数据。对律所、医院、银行等受监管行业而言，"我们不会用你的数据训练"和"我们根本没有你的数据"是截然不同的承诺。企业也不清楚 Anthropic 何时可能改变其对"不安全行为"的定义，从而让员工读取用户的 prompt——其中往往包含极其敏感的数据。此外，服务器上的任何数据都可能被攻击者窃取或被法院调取。去年在 The New York Times 的版权诉讼中，法院命令 OpenAI 保留本应删除的聊天记录，包括用户已清除的记录。OpenAI 称 ZDR 客户不受影响，因为它从未持有这些客户的数据。客户服务器上的日志是否会在针对 AI 公司的诉讼中被调取，两家都没有正面回应，也均未发布针对其架构设计的独立审计报告。
我们的看法：2024 年，我们曾提出云 AI 隐私的四个等级，其中最高一级——服务提供商完全无法访问你的数据——对敏感工作最为关键。尤其考虑到目前存在漏洞，让前沿实验室可以自行决定用什么标准来定义什么是"安全"，这一点就更重要了。相比之下，许多超大规模云厂商的隐私政策要简单得多，规则也更清晰：除非有传票、法院命令或其他更可预期的法律程序要求，我们默认他们不会查看我们的数据。如今这两家公司都声称，自己能在保护用户隐私的同时，跨多个请求发现滥用行为。但谁也没有展示怎么做到的。在双方公开设计细节之前，这只是一份路线图，而不是承诺。
Ox Alpha 现身：GLM-5.3-Flash
一个多星期以来，OpenRouter 上使用量最大的模型叫什么名字、出自谁手一直是个谜。上周，官方公布它是 GLM 系列的新模型——更让很多人意外的是，该公司表示这个免费、高流量的预览版完全由国产芯片提供算力。现在，任何人都可以下载它的权重了。
最新动态：Z.ai 发布了 GLM-5.3-Flash，就是此前以"Ox Alpha"之名预览的视觉语言模型。这是该公司自 4 月的 GLM-5V-Turbo 以来首个视觉模型，也是 GLM-5 家族中第一个从一开始就内置视觉能力（而非在语言模型上后期加装）的模型。
- 输入/输出：支持文本、图像和视频输入（最高 1,048,576 tokens），文本输出（最高 128,000 tokens，每秒 44.6 tokens）
- 架构：混合专家 Transformer，结合线性注意力与稀疏注意力，总参数量 3200 亿，每个 token 激活 180 亿
- 特性：可调节推理等级（low、high 和默认的 max），推理无法关闭，支持流式输出、工具调用和上下文缓存
- 性能：在 Artificial Analysis 的 Intelligence Index 上取得 57 分，在全部模型中排名第三；在开放权重模型中表现最佳（GDPval-AA v2，评估真实知识型工作任务）
- 获取方式与价格：通过 GLM Coding Plan 订阅，月费 $18 至 $168；API 按每百万 input / cached / output token 分别计费 $0.15 / $0.03 / $0.50
- 权重与许可：基于 MIT 许可证免费下载，允许商用
- 未披露：知识截止日期、预训练数据来源
工作原理：Z.ai 从一开始就用文本、图像和视频联合训练 GLM-5.3-Flash，而非事后将视觉与文本 Transformer 拼接在一起。与更大参数的 GLM-5.3 不同，Z.ai 从零开始预训练该模型，并重新设计了注意力层，使其更高效地处理长输入。
- GLM 系列首次引入双注意力混合机制：线性注意力（Linear Attention）是一种内存高效的变体，计算开销与输入长度成正比，负责关注局部上下文；稀疏注意力（Sparse Attention）则覆盖全部上下文。官方称这一组合将注意力计算量压缩到 GLM-5.3 的约三分之一，低于 DeepSeek-V4-Flash 和 Kimi K3。
- 一个名为 IndexPool 的机制将模型每四个查找向量平均合并为一个，在上下文接近 100 万 token 时降低内存占用。配合混合注意力机制，GLM-5.3-Flash 的 key-value cache 被压缩到 GLM-5.3 的四分之一以下，但仍高于 DeepSeek 和 Kimi 的最优水平。
- 该模型在 30 万亿 token 的多模态语料库上预训练，并采用了 DeepSeek 提出的 Manifold-Constrained Hyper-Connections 技术——该方法将传统逐层连接拆分为多条并行连接，在合并时保持各路径稳定。官方称这有助于模型高效扩展。
- 在生成训练数据方面，Z.ai 让模型在能渲染前端页面、游戏或 3D 场景的环境中自主操作，观察结果后再修改，然后用这些尝试数据回训模型。在前端任务中，Z.ai 采用了强化学习，以渲染页面的最终呈现效果作为评分标准。
- 推理时，模型将每个 token 路由给 288 个专家中的 8 个，网络层数为 45 层，约为 GLM-4.5（92 层）的一半。多 token 预测层会预先起草若干 token 供主模型校验，从而加快生成速度。
性能： 独立评测显示，GLM-5.3-Flash 紧随顶级开源权重模型之后，但单任务成本仅为上方模型的约八分之一；而领先闭源模型的单任务成本则是其 10 至 35 倍。在一项面向真实场景的评测中，GLM-5.3-Flash 在所有被测开源权重模型中排名第一；其完成长时编码任务的表现几乎追平体量更大的 GLM-5.3，而后者单任务成本高出 16 倍。
- GLM-5.3-Flash 在 Artificial Analysis 智能指数上取得 57 分，该指数由九项经济实用任务评测综合而成，平均单任务成本仅 $0.09。以远低于竞品的价格，它已接近开源权重领域的领先者 Kimi K3 和 GLM-5.3（两者均开启最大推理，并列 60 分，单任务成本分别为 $0.84 和 $0.68）。它与开启最大推理的 Claude Opus 4.8（$2.03/任务）打平，并超越了 Gemini 3.7 Flash（56 分，$0.40/任务）。
- GLM-5.3-Flash（1,765 Elo）在 Artificial Analysis 的 GDPval-AA v2 排名中位列第三。该排名基于经济实用领域任务的模型对决，其落后于开启最大推理的 Claude Opus 5（1,824 Elo）或 xhigh 推理模式（1,797 Elo），但领先于开启最大推理的 Grok GLM-5.3（1,758 Elo）和开启 xhigh 推理的 Grok 4.6（1,755 Elo）。
- GLM-5.3-Flash 一次性解决了 DeepSWE v.1.1 中 63% 的题目。该测试考察软件工程能力，编码任务均为原创编写而非取自公开代码仓库。在此基准上，它单任务成本为 $0.24；相比之下，GLM-5.3 以 $3.99 的成本做到 69%，开启最大推理的 Claude Opus 5 以 $11.84 的成本做到 74%。同为该量级的 DeepSeek V4 Flash 以两倍成本仅解决 53%。
- 该模型输出冗长且速度偏慢，尤其对于其体量而言。完成 Artificial Analysis 智能指数时，它消耗了 1.5 亿 token，超过中位数（1.1 亿）。在多家硬件供应商上，其平均生成速度为 45 token/秒，显著慢于 GLM-5.3（78 token/秒）以及 Artificial Analysis 测试中的典型模型（69 token/秒）。
新闻背景：发布前一周，Z.ai 以匿名方式推出了 GLM-5.3-Flash 预览版，免费且仅限在编程工具 OpenCode 和模型平台 OpenRouter 上使用。借此，公司得以在开发者不知道模型来源的情况下收集反馈。该公司称，Ox Alpha 在那一周成为这两个平台上最受欢迎的模型。几天内，用户就根据 tokenizer 的输出猜测这个神秘模型属于 GLM 家族。8 月 26 日，Z.ai 确认了该模型，并以标准 MIT 许可证开放权重。两天后，公司又以类似 MIT 的许可证开放了旗舰模型 GLM-5.3 的权重，但附加条款要求年收入超过 100 亿美元的企业在商用前必须通过 Z.ai 的安全审查。
为什么重要：虽然在文本基准测试中 GLM-5.3 仍领先 GLM-5.3 Flash（以及几乎所有开源模型），但目前 Z.ai 的这款廉价模型反而更先进、更全能。GLM-5.3 只是一次高水平微调，而 Flash 则采用了全新的基础模型、架构和视觉能力。该公司表示，下一代旗舰模型将继承这种多模态混合注意力架构，同时用更多数据训练、具备更强能力。几个月前，GLM-5V-Turbo 在视觉语言任务上已超越 Claude Opus 4.6；下一代 GLM 系列模型或许同样能挑战顶级专有多模态模型。
我们的看法：Ox Alpha 的匿名预览既制造了话题和悬念，也让用户得以就其真实水平（包括优缺点）作出评判。最令人意外的事实或许是其依赖中国厂商的芯片。这表明，只要内存优化方法得当，公司就能在经济型硬件上大规模提供高性价比、高性能的模型——只是模型规模和速度略低于我们对尖端产品的预期。
面向法律、新闻和金融的定制模型
Thomson Reuters 推出了自研大语言模型系列 Thomson。该模型基于 Qwen 构建，搭配自研数据工程与再训练流水线，旨在法律、金融等领域提供比通用 LLM 更准确、更完整的回答。
最新动态： Thomson Reuters 将 Thomson 打造为领域专用模型，专注法律、商业、税务、金融、新闻及相关知识工作场景。Thomson 将率先部署在 Thomson Reuters 现有产品 CoCounsel Legal（一款面向研究、分析与文书起草的工具）中，后续也将扩展至旗下其他产品，具体时间未定。
- 输入/输出： 文本输入（最长 262,000 tokens），文本输出
- 架构：Mixture-of-experts Transformer，总参数 3970 亿，每 token 激活 170 亿
- 性能：Thomson-1.0-Large 在税务、法律和新闻内容的完整性与事实准确性上均略微领先 GPT-5.4 和 Claude Sonnet 5；在开放式网络内容的事实准确性上领先两者约 15 分。Thomson-1.0-Small 的表现同样超越了 Gemma4-31B 和 Claude Haiku 4.5。
- 可用性：仅面向企业客户。
- 权重/许可：Thomson-1.0-Large 为专有模型，但 350 亿参数版本的 Thomson-1.0-Small 将以开放权重形式在 Hugging Face 发布，供学术及非商业用途使用。
- 未披露：定价。
工作原理： Thomson Reuters 在 Qwen3.5-397B-A17B（一个指令微调的开放权重模型）基础上构建了 Thomson-1.0-Large。研究团队采用了所谓持续学习（Continual Learning）方法，将全权重中期训练与微调相结合，在公司精选的大规模语料库上进行训练。公司在新闻稿中透露，三个月内总训练投入为 4000 万美元。
- 作者将 Qwen 重新对齐，使其更好地体现公司风格与价值观，包括新闻客观性。他们使用 direct preference optimization（DPO）将模型对齐到一部"宪法"上，该宪法已开源，可供类似项目适配或修订。
- 在领域专业能力方面，Thomson Reuters 及其合作伙伴 DatologyAI 从 19 万亿 token 的候选池中提取了 2000 亿 token 的中期训练数据集。训练数据大致由三部分等量组成：精选的专有文档（新闻、监管文件、判例、合同）、成功专业任务的合成数据对，以及精选的通用能力材料。
- 作者用 DPO 对模型进行了最终一轮对齐微调，以提升 agentic deep research 的准确性和效率。同时引入 group sequence policy optimization（GSPO）来管理上下文压缩和文档缓存，避免撑爆上下文窗口或触发冗余的 API 调用。
- Thomson-Small-1 采用相同方式训练，基座为 Qwen3.6-35B。
- 公司强调其数据驱动管线，融合了 alignment、mid-training 和 post-training 多种方法。公司表示，Thomson 未来版本可能会换用其他基座模型（例如 Inkling Large），训练数据规模也将超过 Thomson Reuters 语料库的 10%。
新闻背景：Thomson Reuters 长期以来已在面向法律、金融从业者和政府机构的产品中应用 AI，而这款最新 AI 产品是其推出的首个 LLM。公司正面临双重压力：一边是 Harvey、Legora 等 AI 原生法律公司，另一边是 OpenAI、Anthropic、Google 等提供的通用 LLM 和 agent，这些产品已能替代 Thomson Reuters 的诸多功能。
- Thomson 的定位比 Harvey 新推出的法律模型 Tenet 更宽泛，数据语料库也更庞大，涵盖新闻、商业、税务和财务领域。Thomson Reuters 同时表示，Thomson 不会像 Harvey 那样刻意针对特定 benchmark（包括 Harvey 主推的 BigLawBench 和 LAB（Legal Agent Benchmark））进行优化。
为什么重要：Thomson 论文的作者认为，他们的领域专用 LLM 方法是主权 AI（sovereign AI）的一个特例，只不过发生在企业层面而非国家层面。与其把数据交给更大的 AI 公司、受制于对方的基础设施和数据留存政策，Thomson Reuters 选择向企业授权模型，让它们在自己的硬件上运行，从而确保敏感数据不出企业内部。此外，企业还可以借助 Thomson 的 midtraining 方法，用私有数据对模型做进一步训练，既不用承担预训练的高昂成本，也不会像 LoRA 这类廉价的微调方法那样效果有限。
我们的看法：模型定制对众多 AI 应用来说依然前景诱人，开放权重模型的日益普及也为团队提供了重要的试验基础。不过，鉴于性能提升相对有限，Thomson Reuters 这样的公司还得向客户证明其产品物有所值。
更简单的模型监控方法
在生成过程中介入的 LLM 安全监控器通常需要分析一系列安全评分，才能捕捉错误或有害的输出。研究人员发现，只分析单一安全评分就能达到几乎相同的性能。
新动态：阿姆斯特丹大学、威斯康星大学麦迪逊分校和约翰·霍普金斯大学的 Mona Schirmer、Metod Jazbec 等人提出了一套简洁的监控系统 CRC Monitor（CRC 即 conformal risk control，保形风险控制）。它通过将单条安全评分与针对当前任务精心校准的阈值进行比较，来评估输出的安全性。
核心洞察：像 e-valuator 这类系统会在 LLM 每一步推理、每轮对话或每次工具调用后对输出打分，并分析分数历史来决定是否停止。更简单的做法是：一旦最新一步的分数低于阈值就立即停止。难点在于如何可靠地选定这个阈值——在有限验证集上测得的误报率，仅凭运气就可能低于新数据上的真实误报率，因此阈值必须定得更保守。
工作原理：作者针对两类"模型生成出问题时应当停止"的任务校准了 CRC Monitor 的阈值：数学推理错误和有害内容。对每个数据集，他们使用一个独立的验证器模型对每一步输出文本打分。最终选定的阈值需同时满足两个标准：(i) 尽可能多地捕获不安全输出；(ii) 将误报次数控制在用户设定的上限之内。
- 数学推理方面，作者构建了一个校准数据集。他们先用 Anthropic Claude Haiku 4.5 和 Mistral-7B-Instruct 对 MATH 数据集生成解题过程，再由验证器（Alibaba Qwen2.5-Math-PRM-7B）估算每步推理是否仍朝着正确解答推进并给出分数。最后用 OpenAI o3-mini 验证每个解答的正确性，生成校准标签。
- 有害内容方面，他们在 Anthropic Red Teaming 数据集（包含旨在诱导 LLM 产生有害回复的对话）和 FineHarm（包含多轮标注有害程度的对话）上进行评估。验证器分别采用 Llama Guard（对应 Anthropic Red Teaming）和一个在 FineHarm 上微调的 Qwen2.5-1.5B 模型（用于检测有害性）。
结果：CRC Monitor 比 e-valuator 更早标记不安全响应，同时保持用户要求的误报率，多数实验中性能与 e-valuator 持平。
- MATH 数据集，用户设定误报率 20%：系统捕获了 Mistral-7B-Instruct 约 80% 的错误解法，与 e-valuator 的 80% 持平；平均在推理进行到约 35% 时即触发警报，e-valuator 则为 40%。
- 搭配数学能力更强的 Claude Haiku 4.5：CRC Monitor 捕获约 75% 的错误解法，接近 e-valuator 的 76%；平均在推理约 40% 处告警，e-valuator 为 49%。
- FineHarm 数据集，用户设定误报率 20%：CRC Monitor 捕获近 99.5% 的有害输出，平均在对话约 14% 处告警，两项指标均与 e-valuator 一致。
- Anthropic Red Teaming：CRC Monitor 捕获的有害对话较少（32% 对 e-valuator 的 54%），但告警显著更早——平均在对话约 26% 处，而 e-valuator 为 55%。
为什么重要：阻止 LLM 生成不良输出，其实可以用更简单、更省钱的方式实现。一个能在生成过程中及时拦截不良输出的有效监控器，只需要三样东西：针对最新生成内容的安全评分、一个经过校准的阈值，以及预设的容错标准。与竞争方法相比，这种方案能更早发现问题，减少用户接触到错误或不当输出的机会（还能省下一些推理成本）。作者提出，这种方法适合构建分层监控架构：持续生成廉价信号，依据校准规则停止生成，只有当廉价信号显示输出有问题时，才切换到更昂贵的验证器。
我们的看法：既然简单的安全检测方法就能和复杂方法一样有效，那么改进其背后的验证器，可能比设计更复杂的结果加权方式带来更大的性能提升。