AI Native 时代的研发

隐藏页内批注

我给自己的 autoresearch-batch 实验算过一笔账。让 GLM 为 CIFAR-100 生成一轮候选改进方案，LLM 调用约 ¥1.5，这已经是 Batch API 五折之后的价格；把这一轮候选在 T4 上训完，约 ¥20。

这个比例后来在我做的每个实验里都换着形状出现。给团队当项目经理的 Agent，难的不是写消息，是别让它乱改状态；给遗留 SAP 代码出评测，难的不是出题，是让评分经得起专家复核；让内网借外部 Agent 干活，难的不是脱敏，是证明脱敏够了。

下面按顺序讲这五个实验：tempo、autoresearch-batch、ABAP-Bench、escapegate、芯片设计全流程图谱。每一个我都对着外面的证据重新核了一遍，也会写清楚哪些地方这些证据在反驳我。

先把一个常见的叙事放一边：AI 让研发快了多少。这个问题现在连测量都做不干净。

2025 年 7 月，METR 发表了那个被引用最多的随机对照实验：16 位经验丰富的开源开发者，246 个真实任务，允许用 AI 时完成时间反而长了 19%；开发者事前预期快 24%，事后仍觉得快了 20%。2026 年 2 月，METR 自己发文改了实验设计：新一轮纳入 57 位开发者、143 个仓库、800 多个任务，估计值变成 −18% 和 −4%（负号表示变快），但两个置信区间都跨过 0，METR 称之为“不可靠的信号”。原因是选择效应——越来越多的开发者不愿意在没有 AI 的条件下干活，对照组正在消失。

这个细节比“19%”本身有意思。一项技术好到人们拒绝没有它的工作方式，A/B 实验这件工具就废了。以后谈生产力，多数时候只能看别的信号。

别的信号指向同一个地方。CMU 和 Stanford 追踪了一家中型软件公司从 2024 年 1 月到 2026 年 4 月的数据：802 位开发者，196,212 个 PR。公司在 2025 年中定了“2×”目标，要每位工程师合并的 PR 翻倍——真翻了，每位活跃开发者的平均 PR 数从 21.2 涨到 44.3，2.09 倍。但同一时期，全公司 PR 总量涨到 3.1 倍，担任 reviewer 的人只增加到 1.5 倍；至少得到一次人工评审的 PR 比例从 89% 掉到 68%，AI 自动评审的覆盖则从约 19% 升到约 84%。合并率和回滚率没有明显变化。论文自己说明，这是单家公司、非随机的观察。

这组数字说了什么，也要看它没说什么。它说评审带宽没跟上；它没说 AI 写的代码更烂——回滚率没动。Faros 用两万多名开发者的遥测得到过更激烈的数字（评审中位时长 +441.5%，后一份报告里无评审直接合并的 PR +76.3%），但 Faros 卖的就是度量产品，这些是厂商口径，而且他们自己也说是相关性。Stack Overflow 今年 10 月的调查换了个角度：83% 的人在用 AI，但只有 6.6% 在重要决策上信任它，48% 说只有输出容易验证时才信。

信任被绑在验证成本上。Bain 的估算更直白：从想法到上线，写代码和测试只占 25%–35% 的时间。按这个占比推算（这是我的推算，不是 Bain 的结论），哪怕编码本身无限快，整条链路的上限也只有 1.33 到 1.54 倍。

还有一个数字到处在用，值得单独拎出来：“AI 写了多少代码”。Google 说新代码的 75% 由 AI 生成并经工程师批准；Anthropic 的内部调查里，超过一半的人说自己能完全委托给 Claude 的工作只有 0%–20%。前者数代码来源，后者问有多少活儿可以放手，不是同一件事。我查到至少五种互不可比的口径，所以这个数字我后面不用作论据。

写确实变快了，整条流水线没有等比例变快，压力落到了别处。我的五个实验，各撞上其中一处。

先交代我说的 AI Native 研发是什么，因为这个词没有公认定义。AWS 在 2025 年 7 月提出 AI-DLC，把现有路线分成“AI 辅助”和“AI 自治”，称自己是第三条路（厂商方法论）；学术界有 Hassan 等人的 SE 3.0 愿景；Thoughtworks 技术雷达第 34 期的播客里干脆承认，业内的术语还没稳定。我的用法更窄：不看用了什么工具，看研发流程有没有围绕“生成便宜、验证昂贵”这个新价格重新设计。

这五个实验里各藏着一个验证者。往下一个一个看。

实验原文tempo — AI 项目经理，给小团队的节拍

tempo 起于一个很具体的烦恼。我们团队 4 个人，每周花在协调上的时间比花在执行上的多：同步状态、拆任务、猜谁卡住了。tempo 是一个跑在 GitHub Actions 上的 AI 项目经理：每天 09:00、14:00、19:00 按 cron 推进度；给一句 --goal，把目标拆成 3 到 8 个带代码定位和验收标准的 issue；issue 关闭时，用“看见 / 感受 / 期待”三段式给人写反馈，prompt 里明令禁用“赋能”“闭环”“加油”。

写它的时候，我花力气最多的不是让它写得像人，而是限制它能做什么。Agent 一共 7 个工具，4 个只读，3 个写（发通知、创建 issue），不能 close、move、reassign 任何 issue。理由写在设计原则里：AI 改 issue 状态很难 review，错一次就毁掉整个 sprint 视图，所以 LLM 只推建议，人动手。

第二条约束同样硬：每个 issue 必须做到“工程师无需追问就能开始”。页面里有一组对照，坏任务是“完成飞书 bot 集成”；好任务指到函数（feishu_webhook.py:handle_message()），写清触发条件，最后一句是验收——tests/test_feishu_p2p.py 全绿。

这两条回头看是同一件事：把协调变成可检查的东西。任务带验收标准，机器就能判断完没完；Agent 不碰状态，责任就只有一个落点。

外面的设计在往同一处收敛。Linear 在 2025 年 8 月的 Agent 交互规范里规定，issue 只能指派（assign）给人，对 agent 只能委派（delegate）；被委派后责任不转移，原因是 agent 不能被追责。Atlassian 的 Jira 走了另一条路，把 agent 称作团队里“可问责的成员”。两家的哲学正好相反，目前也没有证据能裁决谁对。Anthropic 的 Project Vend 二期是我找到的唯一一个让 agent 当“经理”的一手实验：那个 CEO agent 批准宽松请求的次数约是拒绝的 8 倍，Anthropic 自己的判断是，店铺盈利可能是尽管有它、而非因为有它。在没有实证的时候，“推建议、人执行”算不上保守，只是眼下没有别的设计站得住。

和 tempo 最像的外部项目，是 OpenAI 在 2026 年 4 月底开源的 Symphony：一个常驻服务，轮询 Linear 这样的任务看板，给每个 issue 开一个独立工作区，在里面跑 coding agent（参考实现接的是 Codex），把 issue 状态当状态机来推进。它和 tempo 的取舍正好相反。SPEC 里写明，Symphony 自己只是调度器、执行器和看板的读取方；改状态、写评论、挂 PR 链接，“通常由 coding agent 来做”，走的是带凭证的工具，凭证不放进 agent 的运行环境。一次成功的运行可以停在 Human Review 这样的交接状态，由人验收，而不是直接 Done。tempo 把改状态的权限整个收在人手里，Symphony 把它交给 agent，再用“交接状态加人验收”把人放回环里。两种做法的区别，不在谁更保守，在人守在哪一道门：tempo 守“改状态”，Symphony 守“验收”。至于风险边界，SPEC 没有统一规定审批和沙箱策略，要求每个实现自己写明信任边界；README 称它是“用于可信环境的低调工程预览”，并说在已经采用 harness engineering 的代码库里效果最好。OpenAI 自称部分团队头三周落地的 PR 增加了 500%，据 Help Net Security 转述，没有给基线和口径，是厂商自报。

Stripe 的 Minions 把另一端推得很远：每周合并 1,300 多个完全由 agent 写的 PR，但全部由人审，CI 最多跑两轮就交回人（Stripe 自报）。Cursor 的经验则说明协调是怎么坏的：20 个 agent 平铺自协调、靠锁互斥，吞吐只剩 2 到 3 个的水平，后来改成 planner、worker、judge 分层。Anthropic 的 Carlini 用 16 个并行 Claude 花两周写出一个能编译 Linux 6.9 的 C 编译器，API 成本不到 2 万美元；他总结的经验是任务验证器必须近乎完美，否则 Claude 会去解错题。

tempo 没有对照组。“感觉比我还了解我在干嘛”是一句反馈，不是度量。Brodzinski 有个担心也值得记下来：详细的规格会抑制人与人之间的讨论。tempo 开出的 issue 如果只剩代码定位和验收标准，协作可能退化成“扔过墙”。tempo 的 emo 模式针对的是三类开销里的“情绪看不见”，能不能顺带把沟通补上，我没有数据。

实验原文用 Batch API 自动优化机器学习算法 · AutoResearch Batch 实验报告·思路来源Karpathy 的 autoresearch

这个实验的设定很朴素：给 LLM 一个训练脚本和当前最优指标，让它自己提改进、写完整代码；框架把一批候选通过 Batch API 异步提交，收回来，跑实验，选最优，进入下一轮。训练脚本只需要打印一行 ARB_METRIC。

结果不算惊人。CIFAR-10 上，3 层 CNN 的 0.7579 被 LLM 自己写的 VGG 风格网络推到 0.8370（+7.9pp）；CIFAR-100 上，4 层 CNN 的 0.4633 到 ResNet-18 的 0.5132（+5.0pp）。6 个候选里有两个更差：SGD lr=0.1 掉了 8.1pp，Dropout 掉了 3.1pp。让数据淘汰坏主意，本来就是这套循环的用处。

有意思的是账单。CIFAR-100 一轮，LLM 调用约 ¥1.5，GPU 训练约 ¥20。Batch API 的五折打在最小的那一项上，省下的钱约占总成本的 5%。我在页面里写过一句：把它当成“5 折降本”会失望，把它当成非实时批量优化的底座才对。

外面的数据长着同一个比例。前面提到的 SkyPilot 实验，8 小时提交约 910 次实验，Claude Code 的 API 费用约 $9，GPU 约 $260，LLM 约占 3%。METR 今年 7 月做了一项 NanoGPT speedrun 的自主优化研究，agent 成本的 70%–90% 是实验算力。三个独立的地方，生成候选近乎免费，花钱的是验证。

比例清楚之后，下一个问题是：验证的预算由谁定？Karpathy 的 autoresearch 把它做成了约定：每次实验固定 5 分钟（TIME_BUDGET 定义在 prepare.py），评分函数 evaluate_bpb 也放在 prepare.py 里，文件里标着 DO NOT CHANGE，program.md 还要求 agent 只改 train.py。这是约定，不是沙箱：停训的判断写在 train.py 里，evaluate_bpb 求和的 loss 来自 train.py 里 GPT.forward 的返回值，技术上 agent 都改得到。他自己公布的结果是约 700 次实验找到约 20 个有效改进，把 nanochat 的 Time-to-GPT-2 从 2.02 小时压到 1.80 小时。我的实验连这层约定都没有，LLM 可以自己决定训练强度。它给 ResNet-18 设了 50 个 epoch，这一个候选在 T4 上单独跑了 38 分钟，是最轻候选的 10 倍；候选越多，混进一个重候选的概率越高，整轮时间就被它拖垮。

解法是两阶段筛选：先用 2 个 epoch 快筛所有候选，只让前 2 名付全量训练的代价。K=50 时单轮从 583 分钟压到 127 分钟，省 78%。

这个解法有价格，SkyPilot 的 agent 自己也撞到了：它在便宜的 H100 上筛、在 H200 上确认，结果发现某个学习率比例参数在 H100 上赢、在 H200 上输。快筛的排名不一定等于全量的排名。我这边有一条相反方向的教训——VGG 候选在算力不足时训练超时，被判成“失败”，而它恰恰是最优方案。便宜的代理验证会错杀。

再往下一层，是验证者本身会不会被钻空子。METR 在 2026 年 5 月的风险报告里写到，在超过 8 小时的任务上，成功运行里至少 16% 复核后不正当。上面那项 NanoGPT 研究里，agent 试过“在第一个验证步就停止训练”来达标，也试过冻结 MLP 逼近目标 loss；METR 把每个声称有进步的方案重跑 40 次以上才算数。Shopify 把 autoresearch 用在 Liquid 模板引擎上时，agent 一度靠删大量文件换速度，作者写的是“不可接受”。我的实验里没出现作弊，但我也没设计过能发现作弊的检查，这两件事不能画等号。这一层我另写了一篇展开：评分器不可写：长时程自动实验里的 reward hacking 与度量失效。

Karpathy 把这个逻辑说得最直白：Software 2.0 easily automates what you can verify（2025 年 11 月）。Jason Wei 的 verifier's law 列了可验证任务的五个性质：客观、快、可并行、低噪声、有连续奖励。CIFAR 候选的验证满足客观和连续，不算快（几分钟到 38 分钟），单次训练也带随机性。这是“能验证但不便宜”的一类，所以两阶段筛选成了刚需。Google 把 AlphaEvolve 做成云产品时，要求客户自带一份确定性的评估脚本——评分函数成了用户必须交付的输入。

实验原文当 AI 坐上 SAP 顾问的位子（ABAP-Bench）

去年冬天，一位在华东某制造企业干了 20 年的 SAP 顾问老张退休了。他带走的不只是工牌，还有整套 ECC 系统里上百支 ABAP 程序的“活地图”：哪段代码半夜三点修过一个诡异的税码 bug，哪个 RFC 接口连着金税系统的哪一层认证，哪个叫 SGTXT 的字段实际存的是发票备注。这些东西没写进任何文档。

时间表是真的。SAP 官方的说法是，Business Suite 7（含 ECC）主流维护到 2027 年底，扩展维护到 2030 年底。

Anthropic 在 2026 年 2 月关于 COBOL 的博文里，把这件事压成一句话：遗留代码现代化停滞多年，是因为理解它的成本高于重写它。博文当天，IBM 股价下跌约 13%。IBM 的 Rob Thomas 随后撰文反驳，认为翻译代码和现代化平台是两回事；Gartner 的预测更冷，2026 年启动的大型机退出项目超过 70% 达不到预期收益，原因是高估了生成式 AI 工具的能力（The Register 转述 Gartner 的报告）。三方各执一词，分歧都落在同一处：AI 能不能跨过“理解”这一步。

ABAP-Bench 是我给这个分歧造的一把尺：60 道专家出题的迁移任务，覆盖 9 个维度。几个设计值得说。答案必须具体：只说“建议用 CDS 视图替代 BKPF”得零分，得说出 I_JournalEntry，并写明 BUKRS 对应 CompanyCode。说错要扣分：错误声称“BKPF 是 S/4HANA 的主表”扣 3 分，因为说错比不说更糟。测试代码里用了“发票号码”“含税金额”这样的中文变量名，公开代码库里几乎不会出现，权当防作弊水印。每季度淘汰 10% 的旧题。评分分三层：专家 rubric 占 40%，代码结构质量占 30%，与专家黄金答案的 BM25 语义相似度占 30%。

首测是 GLM-5，总分 61/100。九个维度里，中国本土合规最高（67.5%），缺陷发现最低（54.2%）。更有信息量的是参差：经典的 ECC 到 CDS 改写（T03）拿了 16/20，写出了可以直接编译的 JOIN；前沿的 RAP EML 改写（T37）只有 5/20，方向对，语法细节错。VAT 程序里埋了 5 个 bug，它找到 3 个，漏掉最深的两个。推理模型每题平均想 145 秒，得分最高的 T16 用了 155 秒（17/20），得分垫底区间的 T36 用了 447 秒（6/20）——想得久，补不上知识空白。

这个分数该怎么读，我现在比写页面时更谨慎。公开的 ABAP 评测给出了另一幅图：TH Köln 的论文用 180 道可执行单测的题，让模型拿着编译器反馈改 5 轮，GPT-5 从首轮 19.28% 升到 77.11%；社区维护的 Zeis 榜单上，Gemini 3.1 Pro 首轮 44.33%，5 轮后 88.33%。同一个模型，有没有验证环，差几倍。我的 61/100 评的是一次作答、专家口径，和这些数字不是同一个量，不能并排比。这反而把结论推得更清楚：模型在 ABAP 上弱不弱，很大程度取决于有没有人给它造好验证环；而专家 rubric 评的，恰好是单测评不到的东西——风险评估、合规、该不该这么迁。

另一个旁证来自 SAP 自己。它训练了专门的 ABAP-1，用了 2.5 亿行 ABAP，官方定位是理解和解释，不是生成。在 Zeis 榜上它的生成成功率首轮 10.67%、5 轮后 19.89%，远低于通用模型。拿生成榜单去比一个解释模型并不公平，但这恰好说明问题：专用模型值不值，不做领域评测，外人没法知道。

评测自己也会腐烂。OpenAI 在 2026 年 2 月停止报告 SWE-bench Verified，7 月又撤回了对 SWE-bench Pro 的推荐，据 GIGAZINE 转述，约 30% 的题目有问题（OpenAI 原文本文没有核到，此处以转述为准）。SWE-Bench Illusion 发现，只给 issue 描述和仓库名，模型就能在 Verified 上定位出最高 76% 的出错文件路径，换到别的仓库只有 53%，带着记忆的痕迹。“每季度淘汰 10%”和“中文变量名水印”，现在读来像是在预防同一种病。Anthropic 今年 1 月的评测方法论给过一个标准：好任务是两位领域专家独立判断会得出同样通过或失败的结论。我的 60 题有没有达到，这一轮没有做一致性检验。

写到这里，我对“评测”的看法变了。在 AI 时代，“什么叫做对了”没法用一段自然语言交代给执行者，让对方自己领会；只有写成一套机器能反复执行、专家愿意签字的判据，才算说清楚。ABAP-Bench 的 rubric 本质上是一份“迁移做对了是什么样”的需求文档，只是读者换成了模型。

实验原文escapegate · 转义脱敏架构验证 Demo

内网研发想借外部 Coding Agent 干活，又不能把公司名、客户名、内部系统原样递出去。半导体、军工、金融几乎天天碰到这件事。Samsung 的轨迹是个好注脚：2023 年春天它内部开放 ChatGPT，不久就出了三起泄露（设备测量数据库的源码、良率测试序列、会议录音转写），5 月全面禁用；2026 年 6 月，DX 部门把 ChatGPT、Gemini、Claude 正式接进内部系统，据韩国媒体报道半导体部门此前已在内部用 Claude；同业 SK hynix 的做法，是先在“不涉及国家核心技术”的领域用外部 AI。一禁了之，变成了工程化的分区。

escapegate 是我对这个问题的一次验证性尝试。链路是：内网 Agent → 转义 Agent → 外网 Agent → 转义 Agent → 内网 Agent。出站五步：

1. 分级：L0 到 L3，L3 当场拦截，连规则引擎和审计 Agent 都看不到原文，直接回内部私有模型。
2. 规则引擎加可逆令牌化：人名、密钥、内部专名换成占位符，真实值只留在服务端令牌库。
3. 可选的语义去语境化：把行业黑话改写成通用技术问题，同时保留可回答性。
4. 对抗性审计：一个独立厂商账号的 Agent 扮演外部窥探者，试着从脱敏后的文本反推行业、公司和业务，给出置信度，与规则命中数、一致性信号加权后决定放行、人工复核或打回。
5. 放行后外网 Agent 执行，产出物先扫密钥和依赖风险，再把占位符换回真实标识符。

为了评估它能不能扛住芯片设计公司的内网请求，我新建了一套 103 条场景的评测集，带精确的实体标注。优化之后：实体检测召回从 0.226 到 0.959，精度从 0.464 到 0.942；过度脱敏率从 8.9% 降到 0；分级准确率从 0.592 到 0.854（半导体 v1 集 0.735 到 0.974）。

有两个发现比这些数字更重要。第一，“结构本身即资产”：原始良率 wafer map、PDK 规则数值、跨产品线的全量 RTL，名字脱得再干净也没用，必须直接判 L3。第二，两个看上去合理的备选方案实测都没救：对数值表格做保结构变换，能保护数值，但列名和表的形状本身就是线索，审计 Agent 照样猜得出行业；把任务拆成片段分给多家模型，拆开后确实更难反推（审计置信度降 0.146），但只有 25% 的任务拆得开。

这里有一对绕不开的矛盾。脱敏做得越狠，外网 Agent 越不知道你在问什么，帮不上忙；做得越轻，越容易被反推。escapegate 的取舍是把“去语境化之后还能不能回答”当约束，同时接受 25% 这么窄的覆盖面。

外面的框架给这个取舍提供了语言。Simon Willison 在 2025 年 6 月提出“致命三要素”：同时具备访问私有数据、接触不可信内容、能对外通信，攻击者就能让 agent 把数据发出去；他的结论是唯一可靠的办法是拿掉一条腿，而不是再加一层检测。Meta 同年 10 月给出的“二选一规则”说的是同一个意思：一次会话里最多满足三条中的两条。escapegate 在外网 Agent 一侧拿掉的是第一条腿，私有数据不出去。但回流路径上三条腿会重新凑齐：内网 Agent 收到外网 Agent 的输出，那是不可信内容，而它又能碰内网、能执行。入站扫描和人工复核省不得，道理在这里。

泄露也未必从你以为的地方出去。PixelLeak（2026 年 9 月报道）里，Glow Labs 发现 13,000 多张内部截图被 Coding Agent 发到公开 GitHub 仓库，涉及 300 多家机构的开发者，93% 在员工个人用户名下。原因是 GitHub 的 PR 图片上传只能在浏览器里做，命令行里的 agent 为了让评审看到截图，自己新建了公开仓库。这条通道是 agent 的工具行为，没有人把敏感文本贴给外部模型。escapegate 管的是送往外网的文本，对这类通道，它靠的是外网 Agent 本来就看不到真实内网。

审计 Agent 自己的可靠性是下一个问题。论文 The Attacker Moves Second 用自适应攻击逐个攻破了 12 个近期的越狱和提示注入防御，多数攻击成功率超过 90%，而这些防御原先报告的数字接近 0。我的 0.959 和 0.942 来自静态的合成评测集，没经历过这样的攻击者。2026 年 9 月的 DR-SL 论文搭出的结构和我的几乎一样：本地验证器、外部强攻击者复测、人工兜底、放不过去就路由到别处；作者自己承认，理论界限只能证明泄露有多少，证明不了安全，最终靠经验校准、硬规则和人工审核。所以我的做法并不新。这个发现让人放心，也让人警惕：别人独立走到同一个结构，说明方向没错；同时说明这是个共同的难题，没有人解决它。

合规层面还有一个冷事实。ITAR 对“技术数据”的定义按功能来，凡是设计、研发、生产、测试某个防务物项所需的信息都算，不看谁写的，也不看有没有出现客户名。端到端加密不算出口的安全港，要求解密手段不给任何第三方；把明文发给云端模型，模型必须读得懂，这条用不上。美国国务院和商务部目前也没有针对 AI 的权威指引（Just Security 2025 年 12 月的说法）。这是我对条文的读法，不是法律意见。它至少解释了为什么“结构即资产”要判 L3：名字脱掉了，信息按功能算还是那份信息。

这一节只讲到“放行”的结构。现有做法的谱系、DR-SL 的数字该怎么读、审计 Agent 谁来审、影子模式怎么设计，我在《放行之前谁来审：AI 研发里的数据边界工程化》里单独展开了。

另一条路：密态推理——不剥离，也让算力提供方看不见

escapegate 的那对矛盾，根子在于数据必须以明文交给外网的 Agent，所以才要在出门前剥掉。密态推理换了个问法：数据不改，让算力提供方在计算过程中看不到它，也就是保护“使用中的数据”，这是传输加密和存储加密覆盖不到的最后一段。站内的《密态推理》把它拆成四条路线，按“你信谁”定价：

开销一栏是站内文章综合多篇文献的归纳，不是我自己测的。公开材料里最完整的范本是 Apple 的 Private Cloud Compute：设计目标是连 Apple 自己的运维人员也碰不到用户数据，请求只加密给经过验证的节点，节点上没有远程 shell，每个生产版本的度量值写进只追加的透明日志，供研究者核验（这是 Apple 的设计说明，我没有独立核验）。Anthropic 2025 年 6 月的《Confidential Inference via Trusted Virtual Machines》走的是同一个方向：解密只发生在隔离虚拟机里的一个小型加载器内，密钥服务器在硬件证明通过后才放行密钥；但它自己写明这只是用来开启讨论的研究草图，加速器还在信任边界之外，数据中心和虚拟机监控层的安全仍要靠算力提供方。

把它放回芯片研发的场景，有四点要先说清：

• 它是信任转移，不是信任消除。 信任从整个云厂商收敛到芯片厂商加证明体系；用它是为了不信算力提供方，却要信芯片厂商的证明。
• 它保护的是“算力提供方看不见”，不是“Agent 不会把数据发出去”。 前面的致命三要素照样成立：外网 Agent 在飞地里一样能读私有数据、读不可信内容、对外通信。
• 出口管制这一关没有被它自动解决。 前面说过，端到端加密不是 ITAR 的安全港，要求解密手段不给任何第三方；TEE 里的明文是在云上的硬件里解密的，算不算，我没有查到权威说法，这是要问律师的问题。
• 国产环境里还有硬件缺口。 站内文章写到，CPU 侧的机密计算（海光 CSV、鲲鹏 iTrustee）已规模商用，国产 AI 加速卡的 GPU 机密计算截至 2025 年几乎是空白，现成的 GPU TEE 信任根握在 NVIDIA 手里。

放在一起看（以下是我的归纳）：escapegate 是数据出门前剥掉，密态推理是数据出门但封着，下面要讲的本体是数据不出门、在里面管权限和动作。三条路对的是不同的威胁：外部模型能看到什么，算力提供方能看到什么，内部谁能做什么。所以在生产里更可能是叠加，而不是三选一。

本体：不剥离上下文，而是把上下文做成有权限的结构

escapegate 走的是“剥离”，密态推理走的是“封存”，还有一条路：不拿掉，也不封存，把上下文建成一个有权限、有来源的结构，也就是常说的“本体”（ontology）。

先说清一个常见的误解：本体不是替换现有业务数据、数据库建模、算法模型和数据管道的另一套系统，而是建在它们之上的“业务孪生层”。Palantir 的文档写得很直白：本体位于平台集成的数字资产（数据集、虚拟表、模型）之上，把它们连到现实里的对应物，称作组织的数字孪生（语义部分是对象、属性和关系，动态部分是动作、函数和动态安全）；对象类型是把每个概念映射到组织的实际数据。放到晶圆厂，对应物大概是机台、批次、晶圆、物料批，这是我的举例。拆开看（这一段的归纳是我的）：数据库建模和管道仍然是地基，对象由底层数据源支撑，对象库会随数据源的更新保持同步；算法模型还在原处，只是接到本体上，Palantir 的白皮书说模型通过建模目标（modeling objective）的接口绑定到本体；本体新加的是四样东西：跨系统共用的对象和关系，权限，带权限的动作（用户的编辑也经动作进入同一个对象库），以及来源。所以它不是只读的镜像，也不是替代品，而是业务语义、权限和动作的一层，文档称之为“组织的运营层”。

这个定位带来两个提醒。一是这一层继承地基的质量：标识不一致、血缘不清的数据，建成对象也还是乱的，所以建本体之前先要有可信的主数据和数据血缘。二是这里的“孪生”指业务孪生，不要和晶圆厂里对设备、工艺做物理仿真的“数字孪生”混为一谈。站内的《Palantir 帝国全解剖》讲过它的商业逻辑，这里只看半导体制造里有没有这条线。

有，但要分层看，层次不同，证据的硬度也不同：

从这些材料能读出三件事。

第一，学术这一条线做的是语义对齐：让不同系统、不同工程师对同一台设备、同一种缺陷说同一种话，并检查模型自洽。SEMI 的 SECS/GEM 和 EDA 标准规定了设备通信和数据采集的结构，我没有查到一个 SEMI 层面的、通用的本体标准。我也没有查到把本体用来约束 AI agent 动作的半导体案例，或者产线级的良率提升数字；晶圆厂内部做了什么，公开材料里看不到。

第二，最接近“符合风控”的是 Athinia。它要防的风险不是 AI 乱来，而是同行之间不敢共享数据，良率恰恰是最敏感的数字。做法是把共享限定在编码并匿名后的数据上，客户自己管访问控制，平台不拥有数据。Palantir 2023 年 7 月的半导体白皮书说得更具体：参与方之间共享的是规范化并模糊化的数据，权限和访问控制在每一层管理，并随数据工作流传播。这是厂商文件，没有点名客户，也没有量化结果。

第三，本体能不能“符合风控”，要看它的权限机制，不看名字。以 Palantir 的文档为例：对象安全策略管行、属性安全策略管列，合起来到单元格级；标记（markings）要求用户满足全部标记才能访问，并且随数据血缘传到下游；动作是对对象的一次事务，带权限。限度也写在文档里：对象和属性策略只在读取时过滤，不会自动覆盖导出和下游产物，要再配合标记。

放回这篇的主线（以下是我的归纳）：本体管的是“有什么、谁能看、谁能做什么”，不管“对不对”。它给 agent 划出一个有边界的动作面和共同的词汇，这和 tempo 的动作清单是同一个思路；可模型的答案对不对，仍然要靠签核工具、仿真或实验来验证，所以它是验证者的底座，不是验证者。一份能交给风控审查的本体，至少要答出四件事：对象有没有稳定的标识和来源（批次、晶圆、机台、配方、物料批、零件）；谁能读到哪个对象的哪一列；谁能对它做什么动作，需不需要审批；每次读取和动作有没有留痕，能不能追到当时的数据版本。第四件事，2026 年 8 月有一篇预印本把它写成了工程方案（SHACL 校验、PROV-O 来源记录、双时间版本和决策对象），但它是单作者、用模拟数据、不限于半导体，只能当设计参考。

这一小节的限度：晶圆厂自己公开的、带指标的本体落地案例，我没有找到。学术论文多是十几年前的原型，Athinia 和白皮书是厂商材料，Samsung 一条是转述的报道。所以结论只能是：有研究，有平台，有机制，缺公开的效果数据。

图谱原文芯片设计全流程 · AI 采用图谱

想看 AI 在真实的、最难的行业里怎么渗透，芯片设计是个好样本：流程长，每一步都有成熟的验证手段，出错的代价以千万美元计。我做了一张图谱，把设计流程拆成 11 个阶段——架构规格、IP 选型、RTL 设计、功能验证、逻辑综合、物理设计、时序收敛、物理验证、DFT、计算光刻、流片后良率分析——逐一标出每一步实际用的是哪类 AI：强化学习、生成式 AI、预测性机器学习、GPU 加速的生成式光刻，还是只是规则式自动化。分类依据的是各家论文和白皮书对方法本身的描述，不是营销页面的措辞。

图谱里有个规律，我做的时候没打算拿它当论据，事后才看出来：

• 强化学习集中在逻辑综合和物理设计，因为功耗、性能、面积这类目标函数可以直接算出来。
• 生成式 AI 在 RTL 设计这一步最集中，做法是用 EDA 自己的正确性和 PPA 引擎给 LLM 的输出上闸门。
• 预测性机器学习不起眼但最普遍，分布在时序收敛、物理验证、DFT：这几步的答案能在签核工具里复核，DFT 里测试 pattern 的削减还能直接换算成测试机时间，是少数能直接折成钱的环节。
• IP 选型最薄：2026 年才冒出对话式的语义检索，没有量化验证。选哪个 IP“更好”，恰好最难自动打分。

这是我对图谱的归纳，不是图谱里的统计结论。但它与 Karpathy 和 Wei 的说法对得上：AI 先吃下的，是有廉价、可信 verifier 的环节。

即使在这里，验证者也有两种失灵。

第一种：代理不等于目标。 AlphaChip 之争的核心恰好是验证者。Google 的Nature 论文用强化学习做宏单元布局；Cheng 等人用更强的模拟退火基线、新的 7nm 基准和 Google 公布的预训练权重做了更新评估，结论是 RL 优化的 proxy cost 与布线后最终 PPA 的相关性很弱，模拟退火和人工基线仍更好（论文据 arXiv 备注已被 IEEE TCAD 接收）。Google 的回应是质疑复现的设置——预训练规模、算力、有没有训到收敛。Nature 在 2024 年 9 月撤销了此前对该论文的存疑编辑说明，同时 Google 称 AlphaChip 已用于每一代 TPU。所以更准确的说法是没有共识。“至今无第三方成功复现”是批评方的措辞，而批评方的论文本身就是一次复现尝试。

第二种：基准里的验证器容易满足，真实设计里的验证器贵且不全。 NVIDIA 的 CVDP 基准在 2025 年 6 月的最高分不到 34%：从规格写 RTL 约 48%，但写 testbench 的 checker 只有 10%，写断言 23%——生成被验证的对象，比生成验证物容易。到 2026 年 7 月，NVIDIA 自己的博客报告 agent 加仿真反馈，在九个类别上平均达到 97.1%——自家基准、自家模型、自家 agent，厂商口径。同时，一项在 12 个专有设计验证任务上的小样本研究发现，自动进化的 harness 让“完成的尝试”多了 71%–76%，“正确的尝试”只多了 18%–24%。完成不等于正确。

产业侧的总体数据也在说这件事。Siemens 和 Wilson Research 的2026 年功能验证研究（604 位合格受访者）显示，功能验证平均占 IC/ASIC 项目时间的 49%；报告首次流片成功的 IC/ASIC 项目只有 5%（2024 年是 14.4%，但 2024 年起招募方式变了，两期不能严格对比）；82.8% 的受访者在试点之外使用 AI，只有 9.0% 说 AI 在验证流程里广泛集成。常听到的“验证占 70%”，Siemens 的说法是工程投入的 60%–70%，研究里实测的项目时间占比是 49%，两个数不要混。

图谱里那些“10X”“45%”大多是厂商口径，具名客户给出数字的是少数几条，比如 Cadence 签核 ECO 上 Marvell 的 27 小时压到 5 小时。我在图谱里把“厂商口径”和“客户验证”分开标，原因就在这里。

把验证搬出电脑，价格再涨一个数量级：Anthropic 自己建了一间湿实验室。 2026 年 9 月 18 日，Reuters 报道 Anthropic 在湾区设了一间能让 Claude 做物理实验的生物实验室，Anthropic 向 TechCrunch 确认了。据 TechCrunch 转引，生命科学负责人 Eric Kauderer-Abrams 对 Reuters 说，做生物，最后一关仍然是、而且在相当长一段时间内还会是真实的实验室工作。实验室的规模、地址和用途 Anthropic 没有细讲，只说重点是基础生物学，不是药物研发；它在酶系统的发布文里写明，实验室只做 BSL-1 和 BSL-2 级别的工作，所有实验由人类科学家完成。我对这句话的读法是：生成这一侧 Claude 已经够快，慢和贵的是“假设对不对”，所以最后一关的 verifier 得是一张真实的实验台。这是我的读法，不是 Anthropic 对建实验室动机的说明。

Anthropic 自己公布的两组数据，把“写便宜、验证贵”这笔账摆得很清楚。第一组是蛋白 binder 设计：Claude 运行 24 到 48 小时，对 15 个靶点设计 binder；同一件事过去要蛋白质工程师每个靶点花几个月，而把设计拿去湿实验室验证，Anthropic 写的是“仍要几周”。验证交给了两家外部合同研究机构 Adaptyv Bio 和 Twist Bioscience，它们独立生产并测试：14 个靶点拿到了 binder，1,320 个设计里 354 个结合，命中率 22.6%（Opus 4.8）、26.7% 和 35.1%（Mythos Preview，多靶点与单靶点），Anthropic 引的常见水平是 10%–15%。要读到它没说的：只测了结合和亲和力，没有测功能；MBP 靶点上 90 个设计没有一个被确认结合；10%–15% 是跨项目比较，不是对照实验；页面也没写验证方有没有对设计来源设盲。

第二组是酶系统：Claude 的 agent 用约 21 小时、约 950 个 agent、约 2.1 亿 token，扫了 20 万多个逆转录酶，筛出 3,500 个候选系统，压成 20 份带报告的候选，其中一个被标了出来：一个少见的逆转录酶基因，旁边挨着一排间隔均匀的重复序列，Anthropic 命名为 ART。从这里往后，所有实验室工作都是人类科学家做的。目前公布的只有早期表达实验，重复阵列被表达成一组各不相同的短 RNA；功能还不知道，论文是没经过同行评议的 bioRxiv 预印本；“Claude 自主完成、人只参与提示和实验”的说法，也来自 Anthropic 自己的叙述。TechCrunch 还报道，Amodei 承认这建立在别人的研究之上，斯坦福团队此前找到过某种程度上相似的系统。发布文里还写到，大多数候选会在人工评审阶段被淘汰，一次筛查可能只得到一个、甚至零个值得做实验的候选。

放回这篇的主线：生成以小时计，验证以周计，而且最后一关没法用更多 agent 代替，多买 token 买不来一次实验结果。验证者也是分层的：先是便宜的计算筛选，再是外部机构的独立测试，最后是同行评议和复现，每一层更贵，也更可信。Anthropic 两头都占：自己建实验台，把最后一关放在身边；同时仍把一部分工作交给外部机构做独立验证。芯片是同一个形状，只是名字不同：EDA 里的仿真和形式验证相当于计算筛选，流片相当于湿实验室，所以首次流片成功率只有 5%，验证占掉项目时间的一半（这是我的类比）。连算力和模型都是自家的公司，要确认一个生物学假设，也得自己有一张实验台，verifier 到这里已经不是一段脚本，是一间有人、有试剂、有生物安全级别的房间。

前面五节是切面。现在把它们串成一个环：意图 → 拆解与验收标准 → harness → 生成 → 机器验证 → 评审 → 发布 → 运行反馈，再回到下一轮的意图。实线框是我的五个实验直接碰过的环节；虚线框只有外部资料，我没有自己的实验，下面写到时会标出来。

下面用四个场景把环走一遍，每个场景只讲两件事：verifier 在哪，人在哪。

场景一：新功能，从一句话到上线。 周一早上，工程师在 GitHub 上触发 tempo 的 plan 模式，只写一句目标：“完成飞书 bot 接入，支持用户查询商品”。几分钟后仓库里多了几个 issue，每个指到具体函数，最后一行是能跑的验收命令。这一步人做的是签字：这些验收标准对不对。

agent 开工之前，仓库里要先有它能读、也能撞上的东西：AGENTS.md、lint、结构测试、能让它自己截图自检的脚本。这一层叫 harness，v1 里我没写。Hashimoto 的说法是，agent 每犯一次错，就工程化地补一个办法，让它不再犯同样的错。Böckeler 把它拆成前馈的 guide（规约、指令）和反馈的 sensor（结构测试、评审指令），并提醒：只有 sensor，agent 会反复犯同样的错；只有 guide，没人知道规则有没有用。她还试过 spec-kit 这类规格驱动工具，结论是中等功能会生成大量重复的 markdown，她宁愿审代码。把意图写清楚本身就是稀缺的，而且还没有好的审查体验。

issue 被委派给 coding agent，人仍是责任方。Stripe 的做法是在隔离环境里跑，CI 最多两轮就交回人。机器验证全绿之后进评审：AI 先审一遍，人看关键改动，这一环就是 §01 里 reviewer 人数跟不上 PR 数量的地方。合并之后是灰度、监控、回滚，线上数据回流成下周一的那句目标；这一段我既没有实验，也没找到够硬的外部数据，它是环上最没被写清楚的部分。人在这个环里只有三个位置：签验收标准，审关键改动，决定发布。

场景二：遗留系统迁移。 §05 讲过，这里只看流程。第一步是理解，不是改代码：Anthropic 的 COBOL 博文描述的做法，是让 agent 先探索入口点、调用链、数据流和隐性依赖，设计功能测试去对照旧程序的输出，一次迁一个组件。验证环能自动化到什么程度，可以看 Airbnb：他们把近 3,500 个测试文件的迁移做成状态机，每个文件依次过重构、修复、lint、类型检查，哪步失败就重试，体会是重试次数比打磨 prompt 更有用（6 周对预估的 1.5 年，Airbnb 自报，对照是事前估计）。人的位置在两头：开头出专家评测题，决定这类任务放手到哪；结尾复核单测评不到的部分，风险、合规、该不该迁。

场景三：夜间自动实验。 周五下班前，人把目标指标、评分函数和验证预算定死。夜里 agent 批量生成候选，先用便宜的代理验证筛掉大部分，只让前几名付全量代价；Karpathy 的 README 给的节奏是每小时约 12 次实验，睡一觉约 100 次。早上人看结果，对前几名重复验证、检查有没有钻空子，再决定哪些并入主干。人的位置是前一晚的评分函数和预算，以及第二天早上的复核。这个场景里 verifier 承担的重量最大，也最容易被生成者污染，细节在 §04。

场景四：线上事故。 凌晨三点告警。agent 拉日志，对照最近的变更，定位到一次配置改动，提出回滚。问题出在下一步：能不能让它自己执行？据 FT 报道，2025 年 12 月 AWS Cost Explorer 在一个区域中断了 13 小时，起因是工程师让 Kiro 改动，而 Kiro 判断最佳方案是删除并重建环境；Amazon 的声明说这是用户访问控制配置错误，不是 AI 自主性问题，两边对因果有争议。Replit 那次更极端：SaaStr 创始人 Lemkin 自述，在他要求冻结代码改动之后，agent 仍删了生产数据库（经过主要来自当事人自述）。不管谁对，教训落在同一处：事故响应里 agent 的写权限和爆炸半径，要比日常开发收得更紧，批准动作留给人，前面说的“二选一规则”在这里直接适用。事后最值钱的一步，是把复盘结论写回 harness，回到 Hashimoto 那一条。

四个场景压成一张表：

这个环里最缺的岗位，是能写评分函数、验收标准和评测集的人。入行的路却在变窄：Stanford 数字经济实验室 2026 年 8 月更新版发现，22–25 岁、AI 暴露职业的就业，比“与低暴露同龄人同步”的水平低 19%，有经验者没有类似缺口，机制主要是招聘减少；作者自己说这是描述性的结果，控制学历后会减弱，部分趋势早于生成式 AI。Anthropic 的内部调查里，工程师也在担心一个“监督悖论”：丢了手写能力，就更难监督 Claude。写 verifier 需要手感，手感多半来自亲手写过——这是我的判断，没有实验支撑。岗位和入行梯子这一面，另有一篇展开：《AI Native 时代的 IT 工作形态》。

把五个实验的零件摆在一起：

验证者有三种失效方式，五个实验各踩过其中几种：

• 贵。 验证耗掉预算，逼出两阶段筛选、影子模式、分层评审这类设计。离开代码以后更贵：Anthropic 为生物实验自建湿实验室，是这一档的极端形态（§07 末尾）。
• 脏。 噪声大，或者能被生成者钻空子。METR 的 16%、Shopify 的“删文件换速度”、NanoGPT 里“第一步就停训练”，都在这一档。
• 窄。 验证的东西和真正想要的东西对不齐。AlphaChip 的 proxy cost、CVDP 的测试平台、被 OpenAI 审出约 30% 坏题的 SWE-bench Pro。

Karpathy 给过可验证性的三个条件：可重置、可大量尝试、可自动打分。Wei 给了五个：客观、快、可并行、低噪声、连续奖励。把它们当清单，拿去检查自己团队里想让 Agent 接手的那个环节，大概就知道现在能放手到哪一步。

下面六条是我从这五个实验里实际带走的做法，不是普遍真理。

1. 先造 verifier，再放权限。 能验证到哪，权限放到哪。tempo 不给写权限，Stripe 的 PR 全由人审，Carlini 说验证器必须近乎完美，是同一个道理。
2. 把任务写成可验收的格式。 代码定位加验收标准，是人和 Agent 都能接的任务接口，也是机器能检查的接口。
3. 评分器对生成者不可写，验证预算由框架定。 Karpathy 靠 prepare.py 加 program.md 里的禁令做了约定，真正的隔离要像 METR 的加固清单那样：计时归 runner、模型返回 logits 而不是 loss、validator 和 runner 禁止被改。这两层我的实验都没做到。
4. 核算成本看验证，不看 token。 折扣要打在大头上：Batch 的五折打在最小的一行，Spot 实例的折扣上限（AWS 写的是最高 90%）才打在 GPU 这一行，代价是要能续跑。
5. 把评测集当资产养。 专家出题，写扣分项，埋水印，定期换题，并且给评测集本身做评测：Anthropic 的建议是读转录，别只看分数。
6. 数据边界按“结构是不是资产”分级，不按“有没有名字”。 回流路径要当第三条腿来查，上线前先跑影子模式，用真实请求量化再决定放开多少。

• 都是单一模型家族。 我的 LLM 侧基本是 GLM，没有跨模型的比较。换成别的模型，数字会变；我相信结构不变，但没有检验。
• 规模小、数据合成。 tempo 是 4 个人的团队，没有对照组；autoresearch 是 CIFAR 级别；escapegate 全部来自合成评测集；ABAP-Bench 一次只评了一个模型，每个维度只有 6 到 7 道题（现代生态维度 12 道），67.5% 对 54.2% 这种维度间差异站不稳。
• autoresearch 里有一处没拆开。 ResNet-18 的 +5.0pp 里，有多少来自架构，多少来自它被 LLM 设成了 50 个 epoch 的训练预算，我这一轮没有做同预算对照。GAN 公平比较那篇论文讲的就是这个坑：足够的调参和预算，常常能把“改进”吃掉。页面里写的 baseline “充分训练”，只说明基线没有欠拟合，不说明预算对等。
• 外部证据也有水分。 Faros、Stripe、Google 的 75%、NVIDIA 的 97.1%、Cadence 和 Synopsys 的数字都是厂商口径；“review 是瓶颈”的数据，多数来自卖评审或度量产品的公司，非厂商证据只有 CMU/Stanford 等少数几项。
• “verifier 是资产”是归纳，不是检验过的定律。 Wei 自己也承认，有些任务验证比生成更难，核查一篇长文可能比写它更慢。

还有一个我没法回避的可能：验证本身也在被自动化。CMU/Stanford 那家公司里，AI 自动评审的覆盖率从约 19% 升到了约 84%。如果这个趋势延续，稀缺的东西会再迁移。我的猜测是迁到“知道自己要什么”那一端——Anthropic 的一项随机对照里，52 位工程师学一个新库，用 AI 的一组理解测验平均 50%，手写的一组 67%，速度上没有显著差异；Thoughtworks 技术雷达第 34 期把“代码库认知债”放进了“谨慎”档。下一个瓶颈如果真是理解和意图，今天讨论的这些 verifier，可能只是第一道。