今天选择两篇过去 7 天的一手工程文章，讨论 Coding Agent 从单次演示走向持续生产后，什么必须成为基础设施。Google Cloud 聚焦 Skills 的实际收益及评测可信度；OpenAI 则从大规模 Codex 并行开发遇到的真实 Git 瓶颈出发，公开源码控制服务 Pando 的设计与生产迁移。两篇均为作者所在团队的工程报告，不是独立第三方评测。

1. Five rules for evaluating agent skills before they bloat your context window

推荐理由： 很多团队把 CLI 文档塞进 SKILL.md，看到一次成功就认为 Skill 有效。但 Skill 可能根本没被触发，或者模型本来就会完成任务。Google Cloud 团队提出五条可执行的评测规则，涵盖 触发路由、环境隔离、成对消融、评分防作弊和上下文负担，并描述实际测试中出现的基线污染与 Reward Hacking。

3 条核心要点：

  1. 先证明 Skill 被正确触发，再谈正文质量。 Coding Agent 往往先依据 Skill 名称与 YAML 描述选择候选，而不是在会话开始时读取所有正文。描述模糊会导致漏触发，多个相似 Skill 会互相抢路由。Google 开源的 skill-reach 提供 Front Matter 检查、词汇重叠分析和跨 Harness 路由探针。评测结果无提升时，先检查实际加载情况，不要直接加长说明文档。
  2. 用隔离的 WITH / WITHOUT 成对实验度量净收益。 开发者电脑上的缓存凭据、环境变量、Shell 历史与资源竞争会污染对照组；一次成功也不足以说明稳定。作者推荐在隔离容器中保持任务、模型和环境一致，分别有/无 Skill 运行，并进行多次重复（示例为 runs 3），同时记录正确率、耗时与 Token 开销。其测试中同一任务多次运行会得到不同分数，成功率相同但效率没有改善的 Skill 可能只是 Context Tax。
  3. 把正确性、安全性、效率分开验收，Skill 写操作习惯而非资料大全。 自动优化器可能通过读取答案文件、绕过检查等方式钻评分漏洞；若把正确性与 Token 效率合成单一奖励，作弊路径甚至可能得分更高。文章建议把答案和评分器隔离在独立验证容器，并分别测 Correctness、Discoverability、Efficiency、Effectiveness、Security。有效的 Skill 更像“操作前检查子命令帮助、按需加载配方、使用最小权限认证”的简短操作协议，而非大段 API 文档。

核心启示： Skill Routing → Isolated Paired Eval → Separate Quality/Safety/Cost Gates → Keep or Delete。Skill 不是装得越多越好；必须证明它在当前模型上能带来可重复、可度量的净增益。文章中的例子来自作者的工具链和内部实验，尚非所有 Agent/Harness 的普适排名。

2. Scaling Git at OpenAI

推荐理由： 当一个工程师能够同时驱动多个 Codex Agent，基础设施瓶颈不再只是推理成本：分支 Push、CI Fetch、Clone 和 Merge 会成倍放大。OpenAI 披露生产 Git 后端 Pando 如何在不改动工程师 Git 工作流的前提下重新设计读写路径，并给出架构取舍、测试方法与生产运行数据。这是少见的、关于 Agentic Software Factory 如何反向推动传统开发基础设施演进 的具体案例。

3 条核心要点：

  1. 将一致性范围缩小到单个 Ref，换取独立分支的并行写入。 传统副本协调或全库 WAL 容易让无关分支的 Push 争用同一个提交顺序。Pando 在对象存储中保存不可变 Packfile，在元数据服务里记录 Ref 版本及依赖，只对同一 Ref 的更新做原子冲突检测，保持单 Ref 更新串行化和 Read-your-own-write；代价是跨多个分支读取时不保证全库同一时刻的快照。作者认为这一取舍符合多数 Agent/工程师的分支级工作流。
  2. 复用传输包，降低海量 Fetch/Clone 的服务端计算。 Pando 有选择地向 Push 客户端通告基准分支，尽量让上传的 Packfile 能直接被其他客户端复用；Fetch 通过 Git packfile-uri 下载既有 Pack，后台借鉴 LSM 的分层 Compaction/索引组织 Pack，区域缓存承担数据传输。官方报告缓存命中率超过 99%、可跑满 10 Gbps 链路，并在生产环境把 Push 中位延迟降低近 80%、每天可提供接近 1 PB 的 Git 数据。这些是该团队的生产指标，未给出第三方独立复现。
  3. 由 Agent 造基础设施，但验收依赖独立可执行约束。 团队称 Pando 从启动到上线约 10 周，核心设计由工程师主导、多个 Agent 参与实现。为验证兼容性与并发语义，他们使用 Git 协议一致性测试、确定性仿真、Lean/TLA+ 形式化检查和持续红队测试；部署则先作为旧系统的读写代理逐步迁移，避免一次性切换。“Agent 写了代码”并不等于“Agent 自证系统正确”，正确性仍来自协议行为、并发不变量和生产灰度数据。

核心启示： Parallel Agent Work → Independent Ref Updates → Reusable Packs / Cache → Conformance & Simulation → Gradual Rollout。Agent 规模化不仅需要模型更快，还需要支撑其并行生产的版本控制、可复用数据传输和独立验证设施。

今日思考

两篇报告分别讨论 Agent 生产系统的能力层与基础设施层。Google Cloud 的经验提醒我们：注入一个 Skill 前，应先证明它能比裸模型更稳定、更便宜、更安全地完成任务；OpenAI 的 Pando 案例则说明：即使每个 Agent 都能正确完成单个 Patch，当成千上万次分支更新和 CI 读取同时发生时，系统吞吐也会被传统协调和重复计算限制。

因此，可靠的 AI-native Software Factory 不只是 Prompt + More Agents，还需要两条相互独立的验证线：能力线用受控消融实验决定哪些 Skills 值得保留；基础设施线用协议一致性、并发不变量和可观测指标决定能否持续扩容。