<!-- title: Git为Agent重写：今天四个机器优先新工具 -->
<!-- domain: new-tools -->

# Git为Agent重写：今天四个机器优先新工具

> **一句话信息差**：当国内同行还在争论"哪个 AI 编程助手更香"时，海外黑客本周干了一件更狠的事——他们不再让 AI 去迁就人类工具，而是**把 Git、MCP、文件格式这些底层基建，直接为 AI Agent 从零重写了一遍**。这篇文章拆解今天（2026-06-23）刷屏 HN 的四个"机器优先"新物种，每个都附带可验证的实测数据。

## 导语：信息差不在模型，在它脚下的那层

你大概率已经知道 GLM-5.2、Claude Fable、Gemini 3.5 这些模型榜。但你可能没注意到一个更隐蔽的趋势：**2026 年 6 月，海外开始集体嫌弃"给人用的工具"。**

理由很实在——AI Agent 每跑一次任务，要先 `git clone` 几个 G 的仓库、把几十个 MCP 工具的全套 schema 塞进 prompt、再把 Parquet 文件整个读进上下文。**人用着没毛病的工具，对 Agent 全是成本黑洞。** 于是有人干脆不优化模型了，转头去重写工具本身。

下面四个工具，都是今天还在 HN 首页热榜上的真家伙。我抓了它们的官方页面和 GitHub README，数据你都能自己复现。

---

## 一、Oak：把 Git 推倒，给 Agent 重新造一个版本控制器

- **官网**：https://oak.space （源码：https://oak.space/oak/oak）
- **HN 热度**：210+ points（Show HN，发布数小时即冲榜）
- **定位**：自封 **"the agentic substrate"（Agent 的基座）**
- **价格**：免费，自托管 CLI，`curl -fsSL oak.space/install | sh` 一行装好

Oak 的开场白很挑衅："你觉得 Git 真的是 Agent 最高效的工作方式吗？"——言下之意，Git 是 2005 年为人设计的，Agent 用它纯属将就。

### 它到底改了什么

Oak 不是 Git 的皮肤，是**重写的版本控制系统**，核心三条改动直接砍 Agent 的成本：

1. **`oak mount`（懒挂载）**：不要 `clone` 整个仓库。Agent 只挂载"懒工作树"，用到哪块拉哪块。对动辄几十 G 的单仓库（monorepo），这意味着 Agent 启动时不用先吃掉几个 G 的磁盘和几分钟时间。
2. **`oak space new`（多仓空间）**：一个命令为整个组织建一个跨仓库的 Agent 空间，Agent 在多仓之间跳转不用反复 clone。
3. **Agent 原生的"动作契约"**：分支审查（branch review）、分诊（triage）等操作全部是 **JSON-first** 的机器可读输出，带 `recommended_action` 闭枚举、`n10/n100` 规模门控。也就是说，Oak 把"代码审查"这件事，从给人看的 diff，改成了给 Agent 看的结构化指令。

### 可验证的实测数据（这是这篇情报最值钱的部分）

Oak 官方放了一个公开基准（oak.space/oak/benchmarks），并且**鼓励你自己跑**。同一套 benchmark harness、同样的仓库，对比结果：

| 场景（p50 中位延迟） | Git 耗时 | Oak 耗时 | 差值 |
|---|---|---|---|
| 5 万个小文件 · 首次快照 | 29,723 ms | 1,412 ms | **−95%** |
| 多个 G 大文件 · 任务快照 | 5,218 ms | 321 ms | **−94%** |
| 多个 G 大文件 · 全量 diff | 3,945 ms | 271 ms | **−93%** |
| 超宽 dirty 树 · 首次快照 | 849 ms | 50.9 ms | **−94%** |
| 多个 G 大文件 · dirty 状态 | 1,343 ms | 128 ms | **−90%** |

这是什么概念？**一个 30 秒的快照操作，Agent 现在只要 1.4 秒。** 等待 Agent 跑测试、回滚、分支切换时，每一次 git 操作都在烧 token 和烧 wall-clock 时间。Oak 把这层延迟整体压掉 90%+，它官网原话就是："Fewer tokens. Less time."（更少 token，更少时间。）

### 为什么值得中国开发者关注

国内几乎所有团队都在用 Git/Gitee/GitCode，且 monorepo 越来越大。**没人怀疑过 git 本身是 Agent 的瓶颈。** Oak 给了一个新选项：不用换模型、不用换 IDE、不用换 harness——"Just tell your agents to use Oak."（让你的 Agent 改用 Oak 就行。）

**适用人群**：重度用 Claude Code / Codex / Cursor 跑 monorepo 的工程团队；做 Agent 基建的平台工程师。

---

## 二、Caplets：MCP 工具墙太多了？给 Agent 发"能力卡"而不是"工具菜单"

- **官网**：https://caplets.dev （文档：https://docs.caplets.dev）
- **安装**：`npm install -g caplets`（需 Node 24+）
- **价格**：免费开源，支持本地 stdio 或远程服务器两种模式
- **支持客户端**：Codex、Claude、OpenCode、Pi，以及任何能起本地 stdio server 的 MCP 客户端

这一条直击当下最热的痛点。国内 MCP（Model Context Protocol）今年彻底爆发，各种 MCP 市场铺天盖地。但 Caplets 官网一上来就戳破一个 90% 用户没意识到的问题：

> **"Direct MCP flattens provider APIs into the prompt."**（直连 MCP 会把所有 provider 的 API 全部摊进 prompt。）

换句话说，你给 Agent 接了 5 个 MCP server、上百个工具后，**它还没开始干活，就先花一大堆 context 去读工具名、巨型 schema 和配置假设。** 工具越多，Agent 越"瞎"。

### Caplets 的解法：能力优先，按需展开

它的核心理念是 **"Give your agent capabilities, not a tool wall"**（给 Agent 能力，而不是一堵工具墙）。具体做法是 **Code Mode**：

- 每个 MCP server / API / 命令，被包装成一个**类型化的 `caplets.<id>` 句柄**。
- Agent 第一步只看到**一张"能力卡"**（一个命名的能力入口）。
- 只有当 Agent 真的需要时，才通过 `inspect` / `search` / `get_tool` / `call_tool` **逐级展开**精确的操作路径。
- 巨型 schema **始终藏在背后**，不上 prompt，直到"它真的重要"才出来。

```bash
# 官方推荐的最小起步流程（OSV 漏洞库，免鉴权，最快验证）
npx caplets setup
npx caplets install spiritledsoftware/caplets osv
npx caplets doctor   # 检查配置路径和集成健康度
```

跑通后，先接 OSV（公开、免鉴权），再把 GitHub、Sourcegraph 等需要 OAuth 的能力逐步加进来。

### 为什么这是信息差

国内 MCP 生态现在的主流玩法是**"堆"**——堆工具数量、堆市场。但**几乎没有人在做"能力抽象层"**，去解决"工具太多反而让 Agent 变蠢"的反直觉问题。Caplets 提供了一个反向思路：**少即是多**，Agent 不需要一次性看到所有工具。

**适用人群**：接了 3 个以上 MCP server 发现 Agent 变慢/变笨的开发者；做 Agent 编排的工程师；想给企业内部 API 做统一 Agent 接入的团队。

---

## 三、F3：给下一代数据分析和 AI 训练管线造的"未来文件格式"

- **GitHub**：https://github.com/future-file-format/f3
- **HN 热度**：582+ points（今日 HN 首页最高分之一）
- **价格**：MIT 许可证，完全免费
- **背景**：CMU（卡内基梅隆）数据库组，作者阵容豪华——**Andrew Pavlo、Huanchen Zhang、Wes McKinney（pandas 之父）、Jignesh M. Patel**，2025 年 ACM 论文。

F3 的定位是 **"下一代开源数据文件格式"**，明确要修复 Parquet、ORC 这一代列式格式的布局缺陷。

### 它的两个杀手锏

1. **内嵌 Wasm 解码器（embedded Wasm decoders）**：这是最关键的"未来证明"设计。文件里自带一段 WebAssembly 解码代码，读文件的程序不用预装特定编解码器，直接跑嵌入的 Wasm 就能解析。这意味着**格式可以无限扩展，永远向后兼容**——这正是 Parquet 最让人头疼的地方。
2. **修正布局短板**：针对现代分析型工作负载和向量检索重新设计的列式布局。

### 重要提醒（信息差里最容易踩的坑）

GitHub README 第一句就用 ⚠️ 标注：**"This project is a research prototype... You should not use it in production."**（这是研究原型，别上生产。）

所以 F3 现在的价值不是"今天就用"，而是**"提前知道数据格式的下一站在哪"**。对做数据基建、训练数据管线、向量存储的团队，F3 指出了 Parquet 之后的方向：**自描述、可执行、零升级成本**。

**适用人群**：数据工程师、ML 平台工程师、做 RAG/向量库基建的架构师。国内数据团队目前几乎 100% 绑死 Parquet/Iceberg，**F3 是一张"提前 1-2 年看到未来"的牌。**

---

## 四、彩蛋：FUTO Swipe——把闭源滑动输入 AI 模型，开源到你手机本地

- **官网**：https://swipe.futo.tech
- **HN 热度**：172+ points
- **价格**：模型开源（FUTO 许可证，要求可见署名）；配套的 FUTO Keyboard（v0.1.29）完全离线、Android 上可装

这个虽偏消费端，但信息差一样精彩。**好的滑动输入法（比如 Gboard 的滑行打字），长期被两类东西锁死**：要么是侵犯隐私的云端键盘 App，要么是不开源的私有库。FUTO 的解法是——**把滑动输入做成一套开源模型，跑在本地设备上，零延迟、零上传。**

- **数据集**：100 万条滑动轨迹，MIT 许可证，已发布在 HuggingFace。
- **模型架构（三件套）**：
  - **Encoder（编码器）**：与布局、语言无关，通用预测，覆盖大多数情况。
  - **ContextLM（上下文语言模型）**：每语言一个超小语言模型，用前文消除无意义词，只需文本即可训练。
  - **Decoder（解码器）**：与具体语言、具体键盘布局绑定，学布局特征。

**国内对比**：搜狗、讯飞、百度输入法的滑动功能**全部闭源、大量走云端**。FUTO 证明了"端侧开源小模型"足以打平体验，而且**一个百万级小数据集 + 三个微模型**就能搞定。对做端侧 AI、输入法、隐私产品的开发者，这是可直接复制的路线图。

---

## 全景图：人用工具 → 机器优先工具，这层迁移正在发生

```mermaid
flowchart LR
    subgraph HUMAN["👥 人优先时代（现状）"]
        A1[Git / Gitee<br/>人手动 commit]
        A2[MCP 工具墙<br/>全塞进 prompt]
        A3[Parquet/ORC<br/>格式升级靠迁移]
        A4[闭源云端输入法<br/>滑行轨迹上传]
    end
    subgraph MACHINE["🤖 机器优先时代（2026 重写）"]
        B1["Oak<br/>懒挂载+JSON动作契约<br/>延迟 -90~95%"]
        B2["Caplets<br/>能力卡按需展开<br/>schema 藏背后"]
        B3["F3<br/>内嵌Wasm解码器<br/>自描述零升级"]
        B4["FUTO Swipe<br/>端侧开源模型<br/>1M数据MIT公开"]
    end
    A1 -->|为Agent重写| B1
    A2 -->|为Agent重写| B2
    A3 -->|为机器重写| B3
    A4 -->|为隐私重写| B4
    style HUMAN fill:#fff3f3,stroke:#d33
    style MACHINE fill:#f0f7ff,stroke:#36c
```

这张图就是这篇情报的核心论点：**左边的工具我们用了十年，右边的是 2026 年 6 月才冒出来的新地基。** 谁先站在右边，谁的 Agent 就跑得更快、更便宜、更聪明。

---

## 信息差总结：你知道的 vs 别人不知道的

| 维度 | 国内多数人知道的 | 海外本周已在玩的信息差 |
|---|---|---|
| 版本控制 | Git 是终极方案，Agent 用 git 没问题 | **Git 对 Agent 是瓶颈**；Oak 把快照延迟砍掉 95% |
| 工具接入 | MCP 接得越多越强 | **工具墙让 Agent 变笨**；Caplets 用"能力卡"按需展开 |
| 数据格式 | Parquet 是终点，Iceberg 是未来 | **Parquet 之后是 F3**，内嵌 Wasm 解码器自描述 |
| 输入法 AI | 滑动输入必须靠云端、闭源 | **端侧 3 个小模型 + 百万数据**就能开源打平 |
| 核心认知 | AI 提效=换更强的模型 | **AI 提效=重写模型脚下的工具** |

---

## 行动指南：你现在就能做的三件事

1. **今天（30 分钟）**：把 Oak 装上跑一遍基准。`curl -fsSL oak.space/install | sh`，然后访问 oak.space/oak/benchmarks 自己复现那张 −95% 的表。拿数据去和团队 leader 谈"Agent 基建"这件事。
2. **本周（2 小时）**：盘点你给 Agent 接的 MCP server 数量。**超过 3 个就考虑上 Caplets**。先用免鉴权的 OSV 跑通 `caplets doctor`，观察 prompt 里 schema 占的 token 是不是肉眼可见地降了。
3. **本月（观望 + 收藏）**：把 F3 的 GitHub 仓库 star 起来，读一遍 README 和 ACM 论文摘要。**不用上生产**，但要建立一个认知锚点——下次你设计数据管线时，问自己一句"这格式到 F3 时代还好不好迁移"。

**一条判断标准送给你**：判断一个新工具是不是真"机器优先"，就看它有没有把**延迟、token、schema 大小**当成一等公民去优化。Oak、Caplets、F3 都是——这才是 2026 年值得跟的方向。

---

## 参考来源

1. Oak 官网与公开基准：https://oak.space （基准页 https://oak.space/oak/benchmarks）
2. Oak 源码（含 agent 动作契约实现）：https://oak.space/oak/oak
3. Caplets 官网与文档：https://caplets.dev ｜ https://docs.caplets.dev
4. F3 开源仓库与 ACM 论文信息：https://github.com/future-file-format/f3
5. FUTO Swipe 开源模型与百万滑动数据集：https://swipe.futo.tech
6. 今日（2026-06-23）HN 首页榜单（Oak、F3、FUTO Swipe 等热帖来源）：https://news.ycombinator.com

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护。
> 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
