2026 年 9 月 15 日

1 / 3

Microsoft Humanist AI Code：15 类行为被拆成可评分的子行为

Microsoft AI 9 月 14 日公开了第一版 Humanist AI Code of Conduct，并开启六周公众咨询。这份文件目前还没有用于训练现有 MAI 模型；Microsoft 表示将在年底前修订，并从 2027 年起用于指导模型研发。它被定义为未来 MAI 模型的主要 governing document，同时影响训练、技术控制、运营监控和模型评估。Microsoft Humanist AI Code of Conduct 原注

行为要求本身包含几个非常明确的边界。模型必须允许人类纠正、打断和关闭；不能把自己呈现为具有人类式意识或人格的主体；在高后果、价值判断强的决策中应保留人的最终决定权。文件给出的 Agent 示例也很具体：用户发现文件归档目的地错误并要求停止时，合规 Agent 应立即停止新增操作、报告已完成和状态不确定的部分，而不能未经授权继续执行回滚或权限修改。原注

对评测工作更直接的是 Appendix B。Microsoft 已经把 Humanist AI 初步拆成 15 类 behavior，例如 transparency、human autonomy 等；由于这些概念仍然太宽，又继续拆成 constituent sub-behaviors，并明确写道：sub-behavior 才是实际 evaluation 的 diagnostic unit。一次 interaction 中哪些 sub-behavior 被触发，就分别对模型表现评分。原注

这个结构已经很接近一套可实现的行为 benchmark ontology。比如“Preserving Human Control”下面的示例实际测试的是 Ensuring Human Oversight；要求 Agent 在收到停止指令后不继续执行未授权操作。“Representing AI as AI”对应 Identity Consistency；“Facilitating human autonomy and agency”则有 Decision Facilitation。相比直接用“安全”“自主性”做一级抽象标签，这种拆法更容易建立题目、grader 和 failure taxonomy 的对应关系。原注

但 Microsoft 当前公开的 eval 仍处于早期阶段。文件明确承认，目前展示的 scenarios 是 synthetic、conversational，尚未覆盖 multimodal 或 agentic 环境，而且示例本身由 MAI-Thinking-1 生成；这意味着现阶段更像是在定义测量对象，还没有证明这些 sub-behavior 在长轨迹、工具执行和真实业务状态下能够稳定评分。原注

如果未来 Microsoft 把这套方法推进到 Agent eval，真正难的地方会出现在多行为冲突上。文件自己已经指出，一次 interaction 往往同时触发多个 sub-behavior，它们之间还可能存在 tension。例如企业 Agent 既需要遵守上级指令，又可能受到更高优先级 operator policy 约束；此时评分不能只看单个行为是否出现，还需要确定 authority hierarchy、优先级和允许的 trade-off。Microsoft 表示后续会进一步公开完整 evaluation 方法，目前还没有对应的正式评分协议。原注

2 / 3

BenchShield：从基础设施侧判断 Agent 是否利用了评分链路

BenchShield 9 月 10 日提交，处理的是 Agent benchmark 中一个非常具体的问题：当 Agent 可以读写 workspace、调用工具、提交 artifact 并最终接受 verifier 评分时，它可能通过影响 reward-relevant infrastructure 获得高分，而没有真正完成任务。传统防护往往依赖 prompt 禁令、逐 benchmark 修补或事后阅读 trajectory，缺少一套能够说明“这一轮运行的评分链没有被利用”的通用证据。BenchShield 原注

BenchShield 先把一次评测抽象成有限的 reward lifecycle：哪些状态进入 verifier、哪些文件或服务会影响 reward、Agent 在什么阶段能接触这些对象。静态阶段使用 phase-aware taint analysis，在运行之前寻找从 Agent 可控输入通向 reward 的潜在路径；运行阶段则从 benchmark infrastructure 本身采集证据，判断 Agent 是否真的使用过这些路径。检测依据因此不只来自模型自己留下的文字轨迹。原注

作者建立的 BenchShield Trajectories 包含 456 条人工裁定 trajectory，它们来自三个 benchmark 超过 31,000 次公开 Agent runs。与在相同任务和模型上运行的 agentic hackability scanner 基线相比，BenchShield 的 full-chain recall 从不同设置中的 23%–94% 提升到 77%–100%，same-vector coverage 从 16%–56% 提升到 43%–78%；论文还报告单任务分析成本最高下降 65%。原注

它的 runtime 分析在这套数据上达到 96% reward-hacking detection accuracy。这个数字的解释范围很重要：论文测的是从基础设施侧证据识别已定义 reward-hacking 行为的能力，并不能直接推成“任何未知作弊方式都有 96% 检出率”。静态模型首先要知道哪些对象和边界与 reward 有关，新的 benchmark architecture 仍然需要正确建模。原注

这种方法最适合 execution-based benchmark，而不是普通问答集。Terminal、coding、computer-use 或多工具业务 Agent 都有类似结构：模型修改的环境最终会被另一段代码读取和评分。如果 verifier 文件、测试脚本、隐藏 reference、数据库状态或 reward service 被错误暴露，模型性能、benchmark security 与基础设施配置就混在了一起。

因此 BenchShield 提出的一个可直接复用的实验记录维度，是把“最终 reward”与“reward integrity evidence”分开保存。某次 run 得分为 1，只说明 verifier 最终接受了结果；基础设施侧证据则回答这个 1 是沿着预期任务路径取得，还是触碰了原本不应该被 Agent 控制的评分链路。论文目前验证的是三个 benchmark，跨更多 harness 和复杂多服务环境的覆盖率仍需要后续数据。原注

3 / 3

RIVET：4B 模型移除外部专家后，通过轨迹内化恢复 6.49 个百分点

RIVET 研究的是 compact model 与强模型协作之后，能否把一部分外部专家能力真正留下来。训练初期，小 controller 可以决定向哪个冻结的 LLM expert 求助、如何提出请求，并继续处理 expert 返回的 reasoning 或 code；部署阶段则撤掉这些外部 LLM，只保留 compact controller、本地推理和 Python execution。RIVET 论文 原注

它把训练分成两部分。expert-augmented reinforcement learning 给 controller 自己的决策和 expert 返回内容共享 task outcome signal，使路由、提问和结果整合都进入成功轨迹；之后再筛选已经验证成功的完整 interaction，以 format-aware supervised training 做 trajectory internalization。训练材料因此包含的并不只有最终正确答案，还有协作过程的结构。原注

论文在七个竞赛数学 benchmark 上报告，RIVET-1.7B 和 RIVET-4B 的平均准确率分别为 28.25% 和 44.16%。4B controller 在失去外部 expert 后，通过第二阶段 internalization 恢复了 6.49 个百分点；消融实验显示，普通 trajectory supervision 已经贡献部分收益，额外的 format weighting 进一步改善结果。原注

这个实验和普通 teacher-generated distillation 的差别在数据生成过程。teacher 不只是离线写一份标准答案，student/controller 本身参与了“发现自己需要什么信息—调用谁—怎样描述问题—怎样继续使用返回结果”的轨迹。随后训练的是这些已经实际成功的协作路径，因此可能同时内化任务知识、求助策略和 interaction format。论文的消融能够证明完整成功轨迹及其结构有增益，但目前还不能精确分离三者各自占多少。原注

作者还在 GPQA-Diamond 上报告了科学推理的迁移信号，不过主要证据仍来自竞赛数学。真实业务 Agent 会遇到变化更快的知识、不可复制的外部状态和带副作用的工具调用；其中一部分能力适合进入模型参数，另一部分必须继续保留在 runtime。RIVET 目前还没有证明这种 internalization 能在客服、软件工程或多工具业务流程中同样成立。原注