全部 · 2026-03-16

MIT Technology Review 这篇的核心事实很简单：OpenAI 与五角大楼达成涉密环境合作仅两周，文中已经能列出 3 类伊朗相关用途，但正文没有确认已部署，也没有披露涉密集成完成时间。我的判断是，OpenAI 现在卖的不是一个已经落地的军事能力，而是一个“默认会被接入作战链条”的预期。这个预期本身就很重，因为一旦军方、承包商、平台商都按这个前提排路线，后面再谈边界，基本都是补文档。 文章列的第一类是目标排序与打击建议。这里最刺眼的不是“AI 参与分析”，而是生成式模型开始往“建议先打谁”靠。美军早就有 Project Maven 这类系统做视频目标识别，这不新。我记得 Maven 从 2017 年后就一直是五角大楼 AI 军用叙事的样板，核心是从 ISR 数据里找物体、标注、告警。现在变的是接口层：不是只给你框框和标签，而是把文本、图像、视频、后勤位置一起喂进去，再吐一个排序建议。这个转变会把责任链搞得很滑。文章里那位防务官员说“人会手动复核”，但如果人真逐条复核，速度优势就很有限；如果不逐条复核，所谓 human-in-the-loop 就更像合规措辞。这个矛盾，正文点到了，但没展开。 我对 OpenAI 口径最不买账的地方也在这。Sam Altman 说不能用来造自主武器，可文中同时承认约束主要还是让军方遵守自己那套本来就偏宽松的规则。把模型放进目标优先级、威胁解释、行动建议这些环节，再说“不是自主武器”，法律上也许站得住，操作上已经很接近作战决策辅助。行业里这类切法我见太多了：先把模型描述成总结工具、检索工具、copilot，等它稳定接进工作流，组织自然会把它推向更高杠杆的位置。军事场景里，这个漂移速度只会更快。 第二类是 Anduril 反无人机。这里文章给了一个很关键的接口名：Lattice。Anduril 强在传感器融合、目标跟踪、指挥界面，这些年一直在做。OpenAI 真要嵌进去，最顺的位置不是替代底层感知模型，而是做自然语言查询、跨模态解释、规则调用、告警归因。说真的，这个组合并不科幻，工程上也顺手。问题在于，文章举了 3 月 1 日伊朗无人机袭击导致 6 名美军死亡的例子，却没给出 OpenAI 或 Anduril 系统在类似场景中的误报率、漏报率、响应延迟、交战规则约束。没有这些数字，所谓“帮助击落”就是叙事，不是能力说明。我还没查到双方后续公开更新，这个沉默本身也说明项目成熟度未必高。 第三类是 GenAI.mil 行政支持。很多人会把这块看成最温和，我反而觉得它最容易把边界洗平。合同、采购、后勤、知识库问答，表面离战场远，实际是最好的驻场入口。Google Gemini、xAI Grok 都已被点名接入，OpenAI 只要上这个平台，就会先以“安全办公助手”的名义进入军方日常。历史上企业软件进军政系统，常见路径就是 back office 先落地，mission workflow 后扩展。Palantir、Microsoft 都走过类似路子，节奏不同而已。到了那一步，再讨论“能不能靠近打击链条”，组织阻力会小很多，因为身份已经从外部供应商变成内部默认工具。 还有一层上下文，文章提到 Anthropic 因拒绝放开“任何合法用途”而被特朗普政府停用，并被五角大楼列为供应链风险。这个信号很重。它告诉所有模型公司，军方客户现在更偏好“可管控配合”，不是“价值观争论”。换句话说，模型安全边界正在从实验室政策，变成采购资格问题。OpenAI 此时转向，不只是逐利，也是在抢“默认合规供应商”位置。xAI 也在走同一路线。接下来谁能最早完成涉密环境集成，谁就先拿到工作流位置。技术能力重要，采购和认证节奏同样重要。 我对这篇还有个保留：它把伊朗冲突写成一个很近的落点，但正文没有任何部署确认。标题给出的是“可能出现在哪里”，不是“已经在哪里”。这个区分不能偷。现在能确认的，只有合作已签、用途想象已公开、边界解释很松。不能确认的，是 OpenAI 模型何时进入 classified stack、谁在做 red-teaming、谁对误击建议负责、出了事故责任如何分摊。文章没这些，OpenAI 也没这些。 所以我看这条，不会先问 OpenAI 会不会直接决定打谁。我会先问两个更硬的问题：第一，涉密集成到底几个月完成，还是只是公告先行；第二，军方是否把“建议排序”留档并做事后审计。如果这两项都没有，所谓人类复核很容易沦为签字动作。那时问题就不是模型能不能上战场，而是它已经在战场旁边，只差一个权限开关。

加州 AB 316 已于 2026 年 1 月 1 日生效，企业不能再拿“AI 自己干的”当挡箭牌。我的判断很直接：agent 这波问题，先炸的不会是模型能力边界，而是企业内部控制。文章提到权限漂移、孤儿 agent、长时 token、单次会话最高 10 万美元风险，这几个词放一起看，指向的不是抽象“治理”，而是标准的 IAM、变更管理、成本配额、资产退役。很多公司还在把 agent 当聊天机器人加插件，这个理解已经落后了。 我认同文里一句话：human out of the loop 之后，治理必须写进 workflow。原因很现实。过去一年的企业落地，大多数 copilot 类产品就算出错，伤害多半停留在“建议错了”；agent 接 CRM、ERP、工单、代码库、支付系统以后，错误会直接变成状态变更。权限模型如果还是沿用“员工本人能看什么，agent 就继承什么”，基本等于给 service account 套了自然语言外壳。文章举 OpenClaw 这个开源个人代理当例子，方向没错，但正文没给出它的具体渗透路径、默认权限设计、或真实事故数据，这块信息不够，我不会替它补故事。 外部参照其实已经很多了。2024 年到 2025 年，Microsoft Copilot Studio、Salesforce Agentforce、OpenAI 的 Operators/Responses 一路把“可调用工具”做成主流接口，几家大厂嘴上都在讲 agent governance，但落地上最先成熟的反而是 spend controls、approval gates、audit logs，不是对齐新理论。因为企业最先能量化的损失就是钱和权限，不是哲学层面的自主性。文章里那组 IDC 由 Data Robot 赞助的调查，96% 的生成式 AI 部署者、92% 的 agentic AI 部署者成本高于预期，这个数字我会先打个问号：赞助调查天然有口径偏差，正文也没给样本量、行业分布、什么叫“高于预期”。但就算把水分挤掉，方向我信。只要把 agent 放进长链路任务，token、工具调用、人工兜底、失败重试、云上常驻资源，成本结构就不再像 seat license 那样平滑。 我对这篇还有一个保留：它把 no-code 和 OpenClaw 放在“agent 进入 toddler stage”的触发点上，这个比喻能写文章，不够解释现实。agent 爆量的核心推手不是某一个开源项目，而是门槛同时下降了三层：模型函数调用更稳定了，SaaS API 更标准了，业务部门自己能拼工作流了。也就是说，风险不是某个明星代理带来的，而是创建速度第一次超过了 IT 盘点速度。文里说企业内部会出现成千上万个员工自建 agent，我觉得这个判断靠谱；问题是它没继续往下写：谁来做 CMDB 映射，谁拥有 agent 的生命周期，员工离职后哪些凭证自动吊销，失败任务是否有强制回滚。标题给了方向，正文没把机制讲透。 “zombie project” 那段我反而最买账。GPU 云实例忘关，几个月烧掉几十万美金，这事一点都不稀奇；2024 年很多企业做 RAG 试点时就吃过同样的亏，只是规模还没到 agent 这么夸张。agent 一旦常驻、带记忆、带定时器、带外部工具，就不再是一次性推理开销，而是长期运行资产。资产就要有 owner、有预算上限、有停机条件、有退役流程。说真的，这套东西听起来像老派 ITIL，不性感，但比再写一篇“agent 将改变工作方式”有用得多。 所以我对这条的结论是：别先问 agent 多聪明，先问它拿了哪些凭证、谁给它付钱、谁在它出错时签字。文章已经给出法律责任和成本失控两个锚点，剩下最关键的几项——样本口径、10 万美元会话的构成、OpenClaw 具体事故——正文都没披露。没有这些细节，我不会把它当风险量化报告；我会把它当一个方向正确、证据还偏薄的企业治理提醒。

OpenAI 这篇文把 Codex Security 的边界画得很清楚：它不吃 SAST 报告作为起点，而是直接读仓库，再去验证自己的发现。这个决策我基本买账，因为多数高价值漏洞确实死在“检查存在”与“安全成立”之间，不死在 source-to-sink 这一步。文中给的例子也够典型：正则先校验，后做 URL decode，表面有防线，实际约束已经在变换链里失效。像 Express 的 open redirect 这类问题，老派 SAST 很容易把“调用了校验函数”当成加分项，最后给出一堆看着合理、修起来没优先级的结果。 我一直觉得，代码安全里最贵的不是发现 bug，而是别把安全工程师的时间浪费在假阳性上。Semgrep、CodeQL、Coverity 这一套工具过去十几年都在跟同一个问题打架：规则越广，噪声越高；规则越窄，漏报越多。OpenAI 现在等于公开站队另一条路：先从系统行为、信任边界、约束传播入手，再回头找证据。这个方向和传统 SAST 不冲突，甚至更像把资深审计员的工作流产品化。先形成 exploit hypothesis，再验证，不先继承扫描器的告警列表，这点是有想法的。 我对文章的保留意见也很直接：它把方法论讲明白了，却没给最关键的评估数字。正文没有 precision、recall、TP/FP 比例，没有仓库规模，没有语言覆盖，也没有“比先跑 SAST 再让 agent triage”到底好多少。没有这些，外界只能判断它的叙事是否合理，不能判断它的系统是否过关。安全产品最怕这个：demo 里像高级研究员，进企业代码库后变成另一层高成本 review queue。OpenAI 说它会 validate findings，我想看的是怎么验证。是跑 PoC、写单测、做 symbolic execution，还是只做跨文件语义核对？正文没披露。 还有一点我不太完全认同。文章把 SAST 的短板讲得很准，但容易让人误读成“别从 SAST 开始”天然优于“结合 SAST”。现实里的 AppSec 流程不是二选一。很多成熟团队本来就是 CodeQL 找已知模式，人工审计抓语义漏洞，动态测试补执行路径。Codex Security 如果彻底绕开 SAST，代价是你要自己重建一部分廉价、稳定、可批量运行的规则能力。那部分其实不 glamorous，但企业每天都要它。我还没查到 Codex Security 在 CI/CD 里的触发方式、延迟、成本模型，这些会直接决定它是顾问式工具，还是能进主流程。 说真的，这篇文里最有信息量的，不是“OpenAI 反对 SAST”，而是它在押注一种更接近攻防推理的代码审计形态。去年到今年，大家都在做 AI for code review，但不少产品还停在总结 diff、解释告警、帮写修复建议。OpenAI 这里想卖的东西更像“我先理解你的系统怎样才算安全，再判断这段代码有没有把这个性质守住”。这个目标比静态规则引擎难得多，也贵得多。一旦做成，价值会很高；做不成，噪声会比传统 SAST 更难排，因为它生成的是貌似聪明的长篇推理。 所以我的结论不复杂：方向是对的，宣传也克制，证据还不够。标题给了“为何不含 SAST 报告”，正文给了方法论和一个 CVE 类型例子；但企业最关心的命中率、验证机制、成本边界，正文都没披露。没有这些，我会把它先当成一个很像样的高级审计代理原型，不会急着把它当成下一代 AppSec 标配。