AI News｜2026-10-07

今日目录

• gdp-ts：把授权检查变成编译期可验证的 proof
• Evals 不是 QA 步骤，是产品规格本身
• 企业 agent 的真正瓶颈是真实环境的测试与调优
• local hands：Claude 跑在云上但能碰本地文件
• lab harness 倾向烧 token，startup harness 有真实空间
• 用 plan 代替裸 HTML，token 效率更高

今日判断

我今天最在意的是 Guillermo Rauch 发的 gdp-ts。这件事表面是个 TypeScript 库，但真正变化的是约束的来源。以前 proof 类设计进不了主流，因为人要写要审，认知成本太高；现在 agent 写代码的速度超过人的 review 速度，硬约束反而成了 agent 的朋友，它在 tight loop 里能稳定收敛。我的判断是，接下来 API 安全边界会越来越多地写进类型系统和 lint，而不是靠人盯人复审。

第二块是 eval。Madhu Guru 说 evals are your product spec，Aaron Levie 说 agent 落地的瓶颈是能不能在真实工作环境里测试和调优，这两条其实是同一件事的两面。我认同他们说的痛点，但更具体地看，问题不是没有 eval 工具，而是没有可复现的环境：文件、CRM、邮箱这些 agent 要碰的东西，每家都得自己搭一遍。谁能把 simulated environment 做成通用能力，谁就吃下 enterprise agent 的基础设施层。

Coding 工具这边，Thariq 提的 local hands 和 token 效率都值得记：Claude 跑在云上但能碰本地文件，以及用 plan 代替裸 HTML，本质都是把 agent 的上下文和动作收窄。Garry Tan 那条关于 lab harness 和 startup harness 激励不一致的话，我暂时不当作定论，但它指出的方向是对的——token 消耗和可重复的确定性代码之间，存在真实的产品取舍。

快讯

1. gdp-ts：把授权检查变成编译期可验证的 proof

查看原文 · 来源：Guillermo Rauch (@rauchg)

Guillermo Rauch 发布 gdp-ts，把 Ghosts of Departed Proofs 模式带进 TypeScript：敏感函数需要调用方提供已执行授权检查的 proof，由类型检查器在编译期验证。他明说这类设计过去在 Haskell 生态小众，原因是人审成本高、语法负担重；现在 agent 写的代码超过人能 review 的量，而 agent 恰恰擅长在硬约束的 tight loop 里工作。README 用 Vercel 真实 API 约束做示例，比如改密码这类操作。我的判断是，这会推着 API 设计把安全边界前移到类型和 lint 层，人不再逐行兜底，而是设计约束让 agent 无法绕过。

2. Evals 不是 QA 步骤，是产品规格本身

查看原文 · 来源：Madhu Guru (@realmadhuguru)

Madhu Guru 指出团队最常见的错误，是把 eval 当成 agent 建好之后追加的 QA 环节。他认为 AI 产品不一样，eval 就是产品规格。这句话背后是可操作的机制差异：传统软件先写规格再写代码再测，agent 行为空间太大，规格只能由 eval 集合来定义，改 eval 等于改产品。我的判断是，这要求 eval 的 owner 从测试团队挪到产品和工程的核心位置，并且 eval 集的版本管理要和代码同等级别。做不到这一点的团队，通常会在模型或提示词升级后第一次大范围回退时才意识到问题。

3. 企业 agent 的真正瓶颈是真实环境的测试与调优

查看原文 · 来源：Aaron Levie (@levie)

Aaron Levie 说 agent 部署的瓶颈之一，是能不能在真实工作环境里测试、调优和优化：agent 要访问的文件、CRM、邮箱等。如果不理解 agent 在自家 eval 上执行得如何，以及换模型或升级工作流后会怎样，就不可能知道它的实际表现。现在每家企业都得一对一手搭，慢且重复。他的判断是，未来每家企业都会有专人管理 eval、跑 eval 的基础设施和模拟环境。我的判断是，这条比单纯说 eval 重要更进一层，它指出评测的难点在环境复现，而不是指标本身，谁把 simulated environment 产品化，谁就卡住 enterprise agent 的入口。

4. local hands：Claude 跑在云上但能碰本地文件

查看原文 · 来源：Thariq (@trq212)

Thariq 把他喜欢的模式命名为 local hands：Claude 在云端运行，但可以访问你本地的文件，并说这个能力也会进入 cowork。这条虽然短，但点出了一个实际的架构选择——模型算力和上下文留在云上，文件系统访问留在本地，用一条通道把两边接起来。我的判断是，这是 coding agent 从演示走向日常使用的关键一步，因为大量真实工作依赖本地仓库、未提交改动和私有文件，纯云端 agent 拿不到这些上下文。同时它也带来新的安全问题：agent 能读本地文件后，权限边界和 proof 类约束会变得更重要。

5. lab harness 倾向烧 token，startup harness 有真实空间

查看原文 · 来源：Garry Tan (@garrytan)

Garry Tan 提出一个激励视角：lab 出品的 harness 有动机多烧 token，所以 startup 做的 harness 有真实效用。他举的例子是 Grep 可以观察 agent 使用方式，自动把重复的 token 消耗换成确定性的、可重复的、经过测试的代码。这句话我保留态度，因为 lab 未必只有烧 token 一个目标，但它指出的机制是成立的：token 消耗和确定性代码之间存在真实取舍，而 agent 的重复行为正是可以被观察并固化成代码的信号。我的判断是，围绕这个取舍会冒出专门的优化层产品，前提是它能拿到足够的 agent 运行数据。

6. 用 plan 代替裸 HTML，token 效率更高

查看原文 · 来源：Thariq (@trq212)

Thariq 说这种规划方式的一大优势是比裸 HTML token 效率高得多：模型不需要为了状态机、图表、代码片段这些常见东西反复重建组件和逻辑。这说的其实是一个抽象层级的选择问题：让模型先输出结构化的 plan，再由确定性渲染层把它转成组件，模型每次只维护意图而不是重复生成实现细节。我的判断是，这类做法会越来越多地出现在 coding agent 的中间表示层，尤其是 UI 和文档生成场景，因为重复生成组件既贵又不稳定，把它们交给确定性代码更划算。