GPT-6 Astra 被交给端到端系统后，真正变贵的是“少看几眼”的决定
OpenAI 今天刊出的 Perplexity 案例，把 GPT-6 Astra 的使用描述为从生成文字和代码，走到为外部服务编写模拟响应、测试完整工作流、修改现实系统并监控生产软件。Perplexity 联合创始人 Johnny Ho 说，团队因此可以更少地回头检查。这不是新的 Astra 发布，也没有公布成功率、事故率或节省的人力；它是一份由 OpenAI 发布的客户叙述，不能替代独立测评。 但“检查得更少”恰好是值得谨慎对待的变化。把模型从建议者变成能连续调用工具、改变状态的执行者，收益不只来自写得更快，而来自人是否还需要盯住每一个中间步骤。对于任何准备扩大 agent 权限的团队，试点应先限定在可回放的端到端任务：保留工具调用、输入输出和状态差异，预设失败阈值与人工接管点，再比较人工逐步审看、抽样复核和自动阻断三种机制。能力提升可以降低复核频率，但不应取消复核证据。 OpenAI 的 Astra 发布页也把确认策略和对潜在未授权工具调用的自动审查列为企业控制项；这说明“能执行”与“被批准执行”仍是两层不同的产品能力。客户案例提供了一个值得验证的方向，而不是把生产信任外包给一段宣传语的理由。
大型代码迁移的分水岭不是让 agent 多跑几天，而是先把“对不对”拆成可检查的行为
Google 的开发者团队建议，评估 coding agent 时不要只盯着 Terminal-Bench 一类端到端分数：一次分数波动并不能告诉你模型是误解了模糊需求、忘记运行验证器，还是编造了命令行参数。它提出将这些中间行为写成快速、可确定运行的断言，例如面对不完整需求先澄清、改动构建文件后先跑本地校验。宏观基准仍有价值，但它回答的是终点；行为测试回答的是系统为什么还能信任。 Mistral 同日披露的一次 Fortran 77 到 C++ 迁移给了这个判断更硬的落点。项目先为旧系统导出状态快照，再让新实现加载检查点并比对最终和关键中间数值；40,000 行的第一轮迁移之所以可验证，不是因为 agent 一开始全自动就成功，而是因为团队先建了数值一致性的 parity harness。完全自主的一周一子程序虽然能运行，却只得到“换了 C++ 语法的 Fortran”；最终采用的是规划、实现、测试、审查分工，加上人类在卡住时介入。两份材料都是厂商自己的工程经验，不足以证明普遍效果，却都指向同一条可复制的顺序：先定义可观测的不变量，再扩大 agent 的行动空间。 实际落地时，最小的起步单元可以不是一套昂贵大评测，而是最近一次真实故障：把“没有跑测试就宣称完成”“权限不足仍尝试发布”或“改动接口却没有更新调用方”写成可追踪检查。只有当这些检查在模型、提示词和工具升级后仍稳定，才有资格把长任务交给更少的人类盯守。
Anthropic 提议把外部评估者嵌入公司，OpenAI 的响应让“谁能核验”成为下一项竞争条件
Anthropic CEO Dario Amodei 在 9 月的文章中提出，前沿实验室应向常驻第三方评估团队提供接近员工的持续访问，用以核验安全实践、报告事故，并审看不只是已完成模型而是训练流程和部署过程。他把这称为“pacing”的第一步：不是停止训练，而是让能力进展给对齐、运维和外部核验留下时间。文章的风险时间表和地缘政治判断属于作者的主张，不能视为已经达成的行业共识；但它把一个常被抽象讨论的问题落实成了权限、发布权和披露权的制度设计。 Sam Altman 随后公开表示赞同“员工级访问”的独立评估思路，并称 OpenAI 也会这样做，但尚未公布评估机构、访问范围、保密例外、发现事故后的披露规则或生效时间。两家公司此刻真正可被检验的不是“支持安全”这句口号，而是外部团队能否看到足以推翻内部结论的材料，以及能否不经厂商编辑地说明它看到或没看到什么。 这同样适用于使用方。采购或上线高权限 agent 时，可以把供应商的模型卡和承诺转为合同与运行要求：哪些日志可供独立审计、哪些动作必须留痕、谁能暂停部署、事故多久通报、外部评估者的结论如何处理。若答案仍只是“我们做过安全测试”，那就还没有形成可验证的信任边界。