首页 › new-tools › Git为Agent重写：今天四个机器优先新工具

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 的成本：

oak mount（懒挂载）：不要 clone 整个仓库。Agent 只挂载"懒工作树"，用到哪块拉哪块。对动辄几十 G 的单仓库（monorepo），这意味着 Agent 启动时不用先吃掉几个 G 的磁盘和几分钟时间。
oak space new（多仓空间）：一个命令为整个组织建一个跨仓库的 Agent 空间，Agent 在多仓之间跳转不用反复 clone。
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，直到"它真的重要"才出来。

# 官方推荐的最小起步流程（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 这一代列式格式的布局缺陷。

它的两个杀手锏

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

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

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、输入法、隐私产品的开发者，这是可直接复制的路线图。

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

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 提效=重写模型脚下的工具

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

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

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

参考来源

Oak 官网与公开基准：https://oak.space （基准页 https://oak.space/oak/benchmarks）
Oak 源码（含 agent 动作契约实现）：https://oak.space/oak/oak
Caplets 官网与文档：https://caplets.dev ｜ https://docs.caplets.dev
F3 开源仓库与 ACM 论文信息：https://github.com/future-file-format/f3
FUTO Swipe 开源模型与百万滑动数据集：https://swipe.futo.tech
今日（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学通信知识星球海报-扫码加入