GitHub 一周热点（第 40 周）：harness 走到台前

过去三个月里，GitHub 上增长最快的一批 Agent 项目，名字里带 harness 的比例高得反常。xai-org/grok-build 27,148 星，truefoundry/trueforge 6,011 星，QoderAI/better-harness 2,346 星。连一份专门讲”怎么搭 harness”的文集 lopopolo/harness-engineering 都攒到了 2,708 星。OpenAI 官方甚至为此写了篇文章，标题就叫 Harness engineering: leveraging Codex in an agent-first world。

我的判断是：竞争的重心已经从”用什么框架”移到了”模型外面那圈脚手架怎么搭”。上一期把四条赛道铺开看的时候，这还只是个苗头；三个月过去，它有了自己的名字、自己的方法论文集、自己的测量工具。

这一期不再做全景，只做一件事：把这层脚手架拆开，看它到底在解决什么问题，以及在哪些地方已经踩出了坑。

一、harness 是什么，为什么它现在才被命名

harness 是模型外面那圈确定性代码。它的职责边界可以一句话划清：凡是”模型做不可靠、但系统必须可靠”的事，都归 harness。

按这个标准切，它至少有五个互不重叠的子系统：

为什么这件事到 2026 年才被单独命名？三个条件同时成立：

1. 模型能力收敛了。 换模型的收益变小，“换个更强的模型就好了”不再是答案。
2. 工具面爆炸了。 MCP 把工具数从十来个推到上百个，暴露什么、怎么裁，成了必须做决定的事。
3. 最实际的一条：Agent 开始被允许在生产环境动手。 一旦它能碰真东西，“能不能拦、能不能回退、能不能复盘”就从锦上添花变成了准入条件。

这一层现在有哪些项目

拆解一：shepherd 把执行变成可逆的 trace

shepherd-agents/shepherd 的定位是 “runtime substrate”，但它做的事比这个词具体得多：把 Agent 的一次运行记录成持久、可检查的 execution trace，而工作区里的产出先不落地：它作为 retained output 被单独存放，人看过之后才决定 select、apply 还是 discard。

真正有意思的是它的权限设计。任务就是一个没有函数体的 Python 函数，签名与 docstring 构成契约，权限也写在签名里：

def write_program(
    repo: sp.GitRepo,
    prompt: str,
    output_path: str = "program.py",
) -> None:
    """Write a small, self-contained Python program that does what `prompt` asks.

    Save it to output_path. It must run with plain `python3`, read no input,
    and finish on its own within about ten seconds.
    """

repo: sp.GitRepo 是显式的读写句柄授权，只读场景写 May[GitRepo, ReadOnly]，不加注解的 repo 就只是一个普通值参数。授权因此从”提示词里的君子协定”变成了类型系统里的硬约束。

它的落地限制也写在明面上：macOS 用 Seatbelt、Linux 用 Landlock（跑在特权容器里），Windows 不支持：官方直说在 Windows 上强制只能做到”劝告”级别，建议改用 WSL。项目状态是 early alpha，带一篇 arXiv 论文，pip install shepherd-ai 可装。

主编短评：这个方向是对的。“先提案、后应用”是 Agent 进入生产环境的前提，而把权限写进函数签名，是本期见到的所有设计里最干净的一招——它不需要模型配合，也不依赖运行时检查，编译期就拦住了。要打两个折扣：一是 Windows 不支持会砍掉相当一部分企业场景，而恰恰是这类场景最需要审计；二是 alpha 阶段 API 会变，现在接入等于把技术债记在自己账上。适合拿它做设计参考，而不是直接当底座。

拆解二：trueforge 把 harness 做成可部署的服务

truefoundry/trueforge 的思路完全不同：它不追求架构上的新意，而是把这一层踩过的坑做成了默认值。

一次装齐的东西包括模型调用、MCP 工具、Skill、沙箱、审批、上下文管理、会话状态，对外暴露三种形态：自带 Chat UI、HTTP API 加 TypeScript SDK、可嵌入的 UI SDK。上下文工程在这里被拆成了五个具体机制：subagents、deferred tool loading、Code Mode、large-result offloading、compaction。

几个设计取舍：

• sandbox-as-tool：沙箱按需创建，不是常驻环境；更关键的是密钥留在 harness 里，不进沙箱。
• 两种部署形态：local 模式是单进程加 SQLite，npx 一条命令起；hosted 模式是 Postgres + Redis，有 Docker Compose、Helm、Railway 三条路。
• 自带 benchmark：对比 Claude Managed Agents 与 deepagents，口径是”同任务、同工具、同模型，准确率相同、成本更低”，脚本在仓库 benchmark/ 里可复现。

local 模式的边界它自己写得很清楚：默认没有登录，数据落在本地 SQLite 文件，不要暴露到公网。另外 6,011 星配 103 个 open issue，比例不算好看。

主编短评：trueforge 的价值不在技术新意，在”默认值选得对”。deferred tool loading 和 large-result offloading 这两条，正是上一期说的”MCP 工具清单吃掉上下文”那个问题的工程解法，现在它被做成了开关，不用你自己造。它敢公开 benchmark 脚本和对比对象，这比只贴一张漂亮图表可信得多。风险有两点：一是 local 模式无鉴权这一点很容易被忽略，随手部署到有公网 IP 的机器上就是事故；二是它把模型、MCP、Skill、沙箱全绑在一套配置体系里，用起来顺手，迁移成本也随之上去。

拆解三：better-harness 把”改 harness”变成可测量的实验

前两个项目做的是 harness 本身，QoderAI/better-harness 做的是测量 harness：它跑在你的 Coding Agent 里，把项目和会话证据转成有优先级的改进项与可验证的下一步。

它给了一个可操作的分解框架，叫 Agent Work Loop，五个维度：

方法上它走的是前馈加反馈：前馈是 AGENTS.md、spec、Skill、验收标准；反馈是 linter、测试、Hooks、评测 Agent。报告里有个设计我很欣赏：缺失的证据保持显式，不猜测、不补齐，只把”证据不足”标出来。

主编短评：五个维度这个拆法有实用价值，尤其是把 Learning Capture 单独列出来。大多数团队的 Agent 工作流都缺这一步，做完就完了，教训不沉淀。它和本期第四节的元技能是同一件事的两面。要提醒的是它的证据边界：报告自己声明展示的是”记录到的趋势，不是改进的因果证明”，这句话说明作者清楚这类工具最容易犯的错。另外它对宿主的支持并不统一——不同 Agent 走不同的安装路径、出不同格式的报告，README 里也明确承认”写在 README 里哪几个不代表支持级别”。选型前先看它的 Host Adapter Matrix。

拆解四：harness engineering 这份文集，值得读但别当规范

lopopolo/harness-engineering 不是代码，是一份 CC BY 4.0 的文集与实战指南，但它给出了这层工作最清晰的自我定义：

harness engineering 是”通过塑造模型周围的环境来改善输出”的实践，把模型与 coding agent 当作黑盒保持不变，只改两个外部杠杆：上下文与工具。

它提出了几条可以立刻拿走的判断：

• Agent 应当能做到五件事：恢复意图、操作真实系统、尊重授权、证明结果、让下一次运行装备更好。
• 组织的过程数据是一座冰山，模型权重只是露出水面的尖。水面下是当前运行状态、本地本体、质量标准、流程、异常历史、授权关系。这些不可能预置在通用权重里。
• 因此 harness engineering 是”最后一公里”的活：把这些东西变成可检索的上下文、例子、工具和可执行的约束。

主编短评：这份文集的分解方式可以读，但请当观点读而不是当规范读。作者的经验集中在一家工程文化很强的组织里，不少结论（比如”让仓库教会 agent”）在代码权限集中、变更必须走审批的重合规行业会直接撞墙。不过”把非功能需求写进代码”这句是本期所有项目里最值得抄走的一句：它把”让 Agent 遵守规范”从提示词层的呼吁，变成了代码层的可执行约束。这正好解释了为什么下一节的沙箱与凭证会成为分水岭——那是最难写进提示词、又最必须强制执行的部分。

本节小结：harness 不是某个框架的升级版，它是一层独立的基础设施。判断一个 harness 项目值不值得看，标准可以简化成一句话——**它在工具面、上下文预算、权限、回放、恢复这五件事上，有几件是真正做了决定的？**只封装模型调用的项目，边际价值已经归零。

二、沙箱与凭证：harness 绕不过去的两块硬骨头

五个子系统里，工具面和上下文预算大家都在做，真正拉开差距的是权限与沙箱。原因很直白：这是唯一一个”做错了会出事”的子系统，也是唯一一个不能用提示词糊弄过去的。

Dormice：把沙箱做成 SQLite

BitMiracle-AI/Dormice 的出发点反了过来。云沙箱按存在时间计费，所以它们的沙箱天生是一次性的；Dormice 跑在你自己已经付过钱的机器上，沙箱永久存在，而且越闲置越便宜。

它的全部心智模型就是一个幂等调用：

// 一个 key，一个沙箱：不存在就建、冻结就唤醒、停止就启动、归档就恢复
await client.acquireSandbox('my-agent', { policy: { stopAfterSeconds: null } });
const result = await client.execCommand('my-agent', 'python3 -c "print(6 * 7)"');
await client.destroySandbox('my-agent'); // destroy 是唯一会丢数据的动词

生命周期一档一档降温，而任意一次 acquire 都能把它拉回来：

作者给的实测数字：冻结一个持有 1 GiB 的闲置沙箱，常驻内存降到约 5 MiB，唤醒约 50 ms。

部署形态也刻意做小了：一个守护进程、一个 SQLite 账本、一个端口，没有 Kubernetes，没有外部数据库；第二台机器入伙只需要一条带 --role node 的命令。它还在协议层做了 E2B 兼容——官方的 e2b 包不改一行代码，只换两个 URL 和一个 key 前缀就能跑在 Dormice 上。

状态是早期开发，作者自己写明”还不适合生产”。

主编短评：acquireSandbox 是本期最漂亮的一个 API 设计。它把”沙箱现在处于四档状态里的哪一档”这个复杂度收进了一个幂等调用，调用方完全不需要知道沙箱是活的还是归档的——这是把状态机藏对了地方。E2B 兼容则是很聪明的一步棋：迁移成本从”改代码”降到”改配置”，等于直接接管别人的存量用户。但要注意”闲置免费”的准确含义：免费的是内存和 CPU，冻结的沙箱仍然占磁盘。对长期积累几百个沙箱的场景，存储账要自己算。

clawk：给 Agent 一台一次性 Linux VM

clawkwork/clawk 面对的是一道所有人都遇到过的选择题：要么每条命令都点确认（然后每隔几秒当一次保姆），要么加 --dangerously-skip-permissions 然后祈祷。它提供第三个选项：cd 进仓库敲一个 clawk，Agent 就在一个一次性 Linux VM 里工作，代码挂载进去、guest 内是 root、不需要权限确认，而你的文件、keychain 和机器其余部分够不到。

它的关键设计一句话就能说清：边界不是提示词里的一条规则，而是一台独立的机器，开口只有你挂载进去的那些。

$ curl https://tracker.evil.example   # 不在 allow-list 上：被拦
curl: (7) Failed to connect to tracker.evil.example port 443 after 2 ms: Connection refused
$ cat ~/.ssh/id_rsa                   # 你的密钥从来没进过这台 VM
cat: /home/agent/.ssh/id_rsa: No such file or directory
$ git push                            # 但这一步能用：ssh-agent 是转发的

最后一条正是它诚实的证明。官方明确写了局限：allow-list 挡的是未知服务器，不是”你允许的服务器”；github.com 是预置放行的，转发的 ssh-agent 又能推代码，所以凡是 Agent 读得到的东西，就当成它发得出去。

主编短评：把安全边界从 prompt 移到 VM，是这一层目前唯一站得住的解法：提示词可以被说服，机器不行。clawk 做得最对的地方不是技术，是它把局限写进了 README 正文而不是藏在文档深处。“treat anything the agent can read as something it could publish” 这句话，应该成为所有给 Agent 开网络权限的团队的默认假设。两个现实约束：macOS 支持完整，Linux 还是 experimental，而企业生产环境恰恰以 Linux 为主；另外它上一次推送停在 2026-08-13，节奏已经慢下来了。

open-connector：把凭证从 Agent 进程里拿走

MCP 规范回答了”工具怎么描述、怎么调用”，但它没回答三个更实际的问题：**凭证放哪、scope 怎么收窄、调用怎么审计。**让 Agent 进程直接持有 OAuth token，在生产环境是不可接受的。

oomol-lab/open-connector 就是补这一环的：用户把 app 账号连一次，之后 Agent 通过统一的 Action 目录访问 1,000+ provider、10,000+ 预置 Action，定位是开源版的 Pipedream / Composio。

• 凭证不进 Agent 进程：凭证、scope、schema、策略、运行日志都留在可检查的运行时里。
• 接入面很宽：Connector SDK、oo CLI（本地 Agent relay）、MCP（http://localhost:3000/mcp）、HTTP 加 OpenAPI 3.1、Web Console 五条路。
• 契约一致：托管形态与自托管形态共用同一套 provider id、Action id 和 schema，从托管迁到自托管不用改契约。
• 运行控制：连接身份、scope、运行时 token、Action 允许与阻断策略、临时文件中转、脱敏后的运行日志。

主编短评：这类项目补的是 MCP 生态最容易被跳过的一环，而且定位选得很准：不去抢”MCP 服务器”这个已经很卷的位置，而是站在 Agent 和 provider 之间做认证网关。共用契约这一点是刻意的设计：它让”先用托管快速上线、再迁自托管满足合规”这条路成立，这对企业客户是关键卖点。需要清醒的是”1,000+ provider”这个数字的含义——它描述的是覆盖面的宽度，不是每个 provider 的可用质量。真正决定成败的是你用到的那三五个 provider 是否维护到位，这个只能自己按需验证。

三种权限形态的横向对比

本节小结：这四种形态对应四种不同的信任假设：信机器（Dormice）、信边界（clawk）、信会话（sandbase-harness）、信契约（open-connector）。它们不冲突，甚至可以叠着用。但无论选哪一种，有一条共同的底线：权限模型会渗进业务代码，选错了后面很难改，所以它必须排在”选框架”之前决定。

三、MCP：协议已经定了，价值在最后一公里

上一期说 MCP 已经越过”要不要支持”的阶段。三个月后再看，通用连接器之间的竞争基本结束，真正的增量出现在一个更窄的地方：把专业软件接进来。

通用 CRUD 型 Server 已经不值钱了。它拼的是覆盖面，而覆盖面是可以靠代码量堆出来的。值钱的是另一种：把某个专业软件里”人做起来很烦、机器做起来很确定”的操作抽出来，并且认真设计过工具粒度与上下文成本。

拆解：Konnect 把”MCP Server 怎么写才不亏”讲透了

mixelpixx/Konnect 是本期技术含量最高的项目，但它的价值不在 KiCAD，而在于作者把前作踩的坑逐条写了出来——KiCAD-MCP-Server 已经证明了 AI 驱动 PCB 设计可行，同时暴露了这套架构的路在哪里断掉。

**问题一：调用链太长。**一次工具调用要穿过 TypeScript、schema 校验、一个被拉起的 Python 子进程、stdin/stdout 上的 JSON、命令路由，最后才到 SWIG 生成的 C++ 代理对象。四次语言与序列化边界，每一层都有自己的失败模式：子进程生命周期管理、过滤 KiCAD 混进 stdout 的警告、分块 JSON 重组。Konnect 里，一次工具调用就是一个函数调用。

**问题二：依赖面太大。**跑前作要带着 Node.js 和它的 npm 树、Python 和它的 pip 包、wxPython、kicad-skip，以及 KiCAD 的 SWIG 绑定——两个包生态加一个绑定层，每一个都是会打破安装的移动靶。Konnect 是单个静态二进制，20–25 MB，下载约 9 MB，没有需要版本对齐的伴生依赖。

**问题三：SWIG 是条死路。**前作的 PCB 后端依赖 KiCAD 的 SWIG Python 绑定，而 KiCAD 正在用 IPC API 取代它。SWIG 还留下了实际伤口：一次 zone-fill 调用能让后端 segfault、代理对象比较有 bug，还有一个能在会话中途静默切换后端的回退路径。Konnect 走 KiCAD 10 官方的 IPC API（protobuf over NNG），实时改板并且接进 KiCAD 自己的 undo/redo。

**而最值得抄走的一条是上下文经济学。**把 226 个工具全暴露给 LLM，每次 listing 大约要花 23K token；Konnect 的路由只加载约 2K token 的起步工具集，其余 21 个工具集由模型按需拉取。它省下的那 21K token，是靠把”一次全给”改成”按需追加”换来的：

它还顺手给了模型自省接口——get_recent_calls、server_stats、JSONL 调用日志——让模型能诊断自己的工具调用失败。

主编短评：如果本期只读一个项目的 README，读这个。它把”MCP Server 怎么写才不亏”总结成了四条可以直接搬走的结论：一次工具调用穿过几种语言，就等于有几个失败点；静态二进制不是洁癖，是安装成功率；工具面宽度必须和上下文预算一起设计；给模型留一个能自查的接口。许可必须提醒：AGPL-3.0，如果你的产品通过网络向用户提供 KiCAD 相关能力，义务会被触发，商用前请读 LICENSE 或咨询法务。另外 822 星配 136 个 open issue，说明它还远没到”拿来就用”的程度。

另一种省法：ripwire 先给地图，再动手

redhat-et/ripwire 自称 “The ripgrep of AI context”：C++23、零运行时依赖的 CLI 加 MCP server，做两件事：读之前给一张排好序的确定性调用图（该动哪里、会破坏什么、该跑哪些测试）；写之后做检查（blast radius、能触达的测试、十类质量指标只报变差的、被漏掉的协同修改、字段读写、名字有歧义的符号）。

它附带了一份罕见的”负面结果”报告。背景是一次约 1,500 文件的 C++/Metal 代码库、约 20 个 coding agent、两天的多智能体协作，文本由 Claude Fable 5.0 自己写，并注明”这不是受控测量”。其中几条：

• 省下的：研究阶段约一半的 token 支出；两次任务在动手前被一次调用改变了方向。一次 --callers 返回零个生产调用方，另一次 --edit-check 标记出 6 个调用点里的 5 个不兼容，而文本搜索全漏了。
• 没省下的：这次协作最深的几个发现不是工具找到的：一个结构性的容量上限、一个推导错误的常量、1 ulp 的浮点重结合漂移、一个种子键 bug，全都靠 Agent 自己搭的测量发现。
• 已知的误报：契约检查器的 arity 启发式在带默认值的尾参数上会过度报错，有个任务报了 incompatible=18，实际全部是好的。工具的信任校准文档恰好写了这个场景，照着做的 Agent 没有损失。

主编短评：这是本期唯一一个自带负面结果的项目，而它恰恰因此更可信。“工具是诚实与定位的地板，不是测量设计的替代品”——这一句应该贴在所有 Agent 工具的宣传页上。它同时给了我们一个判断工具好坏的方法：看它敢不敢公开自己的误报场景。ripwire 把误报和对应处理方式写进文档，这比任何性能数字都更能说明作者的工程成熟度。

本节小结：MCP 这一轮的分化很清楚：通用连接不值钱，专业工具的最后一公里才值钱。选型时把”工具数”当成本项而不是能力项来看，会过滤掉一大批看起来很强、实际很难用的 Server。

四、Skill：从”提示词包”进入”元技能”阶段

Skill 这一层变化最快，也最容易看错。上一期说它的价值是”分发格式”；这一期冒出来一批不做事、只做事的方法的 Skill——写 Skill 的 Skill、优化 Skill 的 Skill、给 Skill 排行的 Skill。一个品类开始生产”生产工具”，通常意味着它已经过了野蛮生长期。

元技能：Skill 开始自我繁殖

Kulaxyz/self-learning-skills 自称 meta-skill，它做的事很朴素：识别”刚刚挣到一条可复用的黄金路径”的时刻，把它持久化到 Agent 下次会自动加载的位置。它捕捉的是过程，并且明确说包括失败——“下次跳过一条已知的死路，往往比赢一次更值钱”。

三种落点，对应三类 Agent 的记忆机制：

它里面最值得单独拿出来的一条是晋升规则：一条经验要变成 Skill（也就是被下一轮会话无条件信任），必须同时满足三条——有一个通过的检查（真的验证过）、有一个被命名的失败模式、至少有一条被排除的死路。缺一条就只留在临时的记忆笔记里。作者注明这条规则来自社区反馈。

安全上它做了一件正确的事：只记录”密钥在哪”（环境变量名、某个函数、某个 MCP 工具、某个密钥管理器），绝不写入密钥值——因为收获的 Skill 会被提交和共享，把一个密钥复现到共享文件里就等于泄露。

另外几个同方向的项目：QoderAI/better-harness 把 harness 当代码、跑受控实验；LinklyAI/best-skills 做每日更新的 Top 100 Agent Skills 排行，聚合 skills.sh、ClawHub 等来源的安装量、增速与社交热度；anthropics/launch-your-agent 是官方 Skill，把创始人从想法带到上线的 Claude Managed Agent。

主编短评：元技能的出现是生态成熟的标志，但那个”Skill 排行榜”值得警惕：它的指标是安装量和社交热度，不是效果。上一期说过 Skill 是供应链，这一期要补一句——当 Skill 有了排行榜，刷榜的动机就出现了。相比之下，self-learning-skills 的晋升规则是本期少见的、可以直接落地的质量机制：它用三个可检查的条件把”我觉得这个方法好”过滤成了”这个方法被验证过”。这条规则本身就该被抄进任何团队自己的 Skill 规范里。

生产线型 Skill：把创作拆成中间产物

主编短评：短剧这一类最有意思的地方，是它把”创作”拆成了可交付的中间产物：角色圣经、大纲、分镜表。这解决了 AI 生成最实际的痛点：生成质量不稳定时，把流程拆开才能定位是哪一步坏了。但也要看清代价：这类 Skill 把创作变成填表，能稳定产出合格品，却很难产出意外的好东西。headcount 那 125 个 Skill 则暴露了另一个问题——当数量到百级，“该选哪个 Skill”本身就成了检索问题，而这正是元技能和注册表要解决的事。

一个不能忽略的品类：去 AI 味

三个月里，至少有四个项目在做同一件事：去掉文本里的 AI 痕迹。

• Nanako0129/sepia（2,908 星，MIT）：面向任意符合 Agent Skills 标准的 Agent，声称 Skills CLI 支持 77+ 个 Agent
• AIScientists-Dev/academic-humanizer（1,737 星）：论文与基金申请（NSF/NIH），保留学术语气
• Raymondhou0917/speak-human-tw（1,010 星，MIT）：繁中场景，抓 38 种 AI 写作痕迹
• NulightJens/humanizer-stack（303 星）：两遍流水线，表层一遍、结构一遍

其中 sepia 的技术路线值得单独看，因为它不是在调词表。它引用了一项研究 StoryScope（Russell 等，2026；61,608 篇故事，人类加 5 个前沿 LLM）：只用叙事结构特征的分类器，检测 AI 小说的 macro-F1 达到 93.2%；而在人类编辑改写表层风格的条件下，检出率只从 95.5% 降到 93.9%。

结论很硬：**改词句没用，暴露 AI 的是结构。**该研究报告的”破绽”包括：主题被叙述者直接解释、单线且因果整洁的情节、情绪只写成身体感受、没有真实世界指涉、没有读者、线性时间、结尾靠主角成长与接受来收束。sepia 据此做三遍改写：叙事架构 → 话语流 → 表层风格。专业文档那一路也有对应证据（2,250 篇公司博客对 11,250 篇 AI 镜像，结构特征单独就能到 98.0 macro-F1）。

主编短评：这批项目里 sepia 的论证质量最高。它先去查检测器真正在用哪些特征，再针对特征改，而不是凭手感换同义词。这件事本身比”去 AI 味”这个需求更值得注意：当”像不像人写的”可以被形式化到 93% 的准确率，它就不再是风格问题，而是结构问题。同时必须提醒用途边界：用在营销文案上无可厚非，用在学术投稿、合规申报、法律文书上性质完全不同——academic-humanizer 明确面向 NSF/NIH 申请，而多数基金机构已经有 AI 使用披露要求，工具帮你”看起来不像 AI 写的”，披露义务并不会因此消失。

本节小结：Skill 生态这一期的关键词是元：元技能管怎么沉淀、测量工具管怎么改进、注册表与排行管怎么分发。这是好事，但也带来一个新问题：当 Skill 数量过百，“选对 Skill”的难度开始超过”写好 Skill”。Skill 的分发问题解决了，检索和信任问题才刚刚开始。

五、大模型工程化：把前沿模型塞进消费级硬件

这一层三个月里出现了一条清晰的分叉。上一期提到 antirez/ds4 与 JustVugg/colibri，说它们的意义是”让能不能本地跑不再由框架决定”。现在看，这条路分成了两支，而且两支都已经跑出了可复现的数字。

路线 A：专家卸载，把权重放到磁盘上

sqliteai/warp（原名 WASTE）是这个方向做得最透的一个。它的自我介绍里有一句话本身就是这个品类的注脚：“想法、假设、优先级、测试和决定都是人的，代码是 LLM 写的——在这个尺度上，这是快速迭代新算法、验证假设的唯一办法。”

它跑在 64 GB 的 MacBook Pro（M5 Pro，模型容器放内置 SSD）上，实测：

机制上有三件事：

• 容器布局保证”一个专家等于一次对齐读”，读盘与计算重叠，剩余内存变成有上限的专家缓存。
• 前瞻路由预测下一层需要的专家并提前读取；真正的路由仍然做决定，所以这只改变时序，不改变结果。
• 量化分档：专家用 3-bit 残差向量量化，更敏感的共享权重保持 4 或 8 bit。K3 的线性注意力与压缩潜在 KV 缓存也帮了大忙——4K 上下文下 KV 缓存约 0.21 GB，而不是 11.25 GB。

它公开的两张表，比任何性能宣称都更有价值。第一张是专家缓存大小与吞吐的关系：

后两行是必须知道的失败模式：命中率还在涨、读盘字节还在降，吞吐掉了八倍。原因是引擎还在自己的预算里，机器已经不在了，于是缓存命中变成了缺页。给进程更多内存并不总是更快。

第二张是每 token 专家数这个旋钮的代价：

top-8 用两倍于该项目在别处拒绝的量化误差，换 1.49 倍速度，而且能复现 top-16 的贪心续写；top-4 不能。它的 next-token 分布看着还很近，但几个 token 之后就不再跟随提示。这就是为什么这里的门禁是”续写”而不是 KL。

还有一个态度：多盘分片（WASTE_BANK_SHARDS）机制已经上线，但作者明确声明不声称加速：因为要测它需要两块速度相当的盘和真实容器，拿内置 SSD 和 USB 硬盘盒对比只会测到硬盘盒。

同一方向的另一极是 FareedKhan-dev/kimi-k3-in-c：C99，无 BLAS、无框架、无 GPU，整个引擎 176 KB。它同样跑 Kimi K3，1.56 TB 的 checkpoint，峰值常驻内存 8.24 GB。作者给出的对照表最直观：

同一提示、同一答案，从最小到最大的机器输出逐字节相同，只有时钟在变。

主编短评：把 warp 和 kimi-k3-in-c 放一起看，结论比单个项目清楚得多：“能跑”和”能用”之间隔着两到三个数量级的 tok/s。 0.6 tok/s 意味着一次 500 token 的回答要十几分钟——它对”验证这个模型在我的机器上行为一致”有意义，对交互式使用没有意义。这两条路真正的价值不在省显卡钱，而在打掉了”权重必须全部驻留显存”这个假设，而那个假设是过去几年推理框架设计的隐含前提。warp 那张”命中率上升而吞吐崩塌”的表，是本季度最值得记住的一张表：它说明瓶颈会从内存容量悄悄转移到页表，而这类转移在监控面板上通常是看不见的。

路线 B：量化与调度，把已有硬件榨干

主编短评：这一支的意义是门槛在下沉。“2 GB 跑 26B”、“8 GB 显卡跑 125B MoE”这类数字在两年前属于标题党，现在有仓库、有安装脚本、有可复现的测量。对企业决策者，这里的实际含义不是”能省掉云账单”，而是**“能不能把模型放到数据所在的地方”这个选项回来了**——对处理敏感数据的场景，这个选项本身就很值钱。要警惕的仍是量化位数与效果的关系：warp 那张表已经说明，可用区间比宣传的窄，任何”量化到 N bit 效果无损”的说法都该用你自己的任务复测一遍。

本节小结：本地推理这一层正在从”能不能跑”进入”值不值得跑”的阶段。路线 A 解决容量，路线 B 解决门槛，两者都还没解决速度——而速度恰恰是决定它能否从演示走进日常的唯一变量。

六、记忆：答案正在收敛到”文件 + 版本控制”

上一期给了三个判断记忆方案的问题：谁决定这条值得记、冲突了怎么办、用户要求删除时能不能真删干净。三个月后看，开源社区的答案正在往同一个方向收敛：不用向量库，用文件系统加版本控制。

okf-memory/okf-agent-memory（738 星，Go，MIT）把这套思路做得最完整。它先否定了两条常见做法：

• 提示词巨石：把所有领域知识和规则塞进 AGENTS.md / CLAUDE.md，造成上下文膨胀，并导致注意力漂移：Agent 开始忽略关键指令。
• RAG 盲区：把行为规则丢进向量库。Agent 在一般任务里根本不会去语义检索操作约束（比如格式或安全规则），因为没人会”搜索”一条自己不知道存在的规矩。

它的答案叫双记忆架构：推送层是一份约 100–150 token 的行为法典，用自研的 Agent Action Grammar 微语法表达，声称比自然语言提示省 78–85% token；拉取层是 knowledge/ 目录下的 OKF v0.2 知识包，基线占 0 token，靠 okf_search / okf_show 按需检索。检索用内存内 BM25，声称 300 微秒以内，全语料解析加图校验约 4 毫秒，检索零 API 成本。

治理上它做了一件很实在的事：把架构决策通过 code_refs 绑到源文件，改代码前用 --for-path 查有哪些活跃约束与保留项。所有内容都是受版本控制的纯文本，用 git diff 和 git log 就能审计 Agent 的记忆。

vshulcz/deja-vu（1,086 星，Go，MIT）走的是另一条入口：不要求你改变写记忆的方式，而是去索引 Claude Code、Codex、Cursor 等 35 个 Agent 已经写到磁盘上的会话历史，任何 Agent 来问都还给同一个索引。它给出的一个数字很关键：43 次压缩测量下来，摘要保住了 77% 的决策，只保住了 0.2% 的命令。

它索引的是”工作”而不只是”对话”：每一轮打开过的文件、带退出码的命令、编辑替换掉的确切片段。还有两个设计值得记：

• deja promote <id> --state rejected 把一条被回退的决策标记出来，之后每次命中都会告诉你”这条试过、为什么被否”。
• 命中时会报告”这次会话碰过的 4 个文件在此之后已经变了”，说不清的时候就保持安静。

索引构建过程中会剥离密钥与 token；无模型、无 embedding、无服务端。

同方向的还有：nameforjt-afk/session-knowledge（332 星）把 Claude Code 会话历史变成可搜索的本地知识库，13 个 MCP 工具，纯标准库；MaxFreedomPollard/Compartment（582 星）做加密、完全离线的 Agent 记忆；jaredrhod/ai-memory-vault（676 星）把 Obsidian vault 变成 AI 的持久记忆。

主编短评：上一期留的三个问题，在文件方案下都有了明确答案。谁写由 harness 里的规则决定，不由模型即兴决定；冲突就是 git diff 看得见、git merge 报得出的东西；怎么删是 git rm 加一条提交，可审计、可证明。向量库在这三问上都含糊，这就是答案收敛的原因：记忆的竞争力不在检索指标，在治理。 deja-vu 那个”摘要保住 77% 决策、0.2% 命令”的数字，值得贴在所有做上下文压缩的方案旁边——压缩丢掉的，往往正是最该留下的操作细节。

本节小结：文件加版本控制这套方案有一个不显眼但重要的副作用：它让 Agent 的记忆可以被 code review。这在合规场景里是决定性的：能审的东西才能上生产。

七、本期趋势研判

把上面六节放在一起，有三条趋势不是单个项目的偶然，而是多个项目在不同方向上同时印证的结果。

趋势一：harness 成为独立品类，框架层被降格为基础件

把本期的项目按”星 / 天”排一下，重心在哪一目了然：

未来 6–12 个月的判断：harness 会像 CI/CD 一样被当作基础设施来选型，评估维度会从”支持哪些模型”转向权限模型、trace 可回放性、上下文预算控制。框架层不会消失，但会退化成 harness 的一个可替换依赖。

对选型的含义：如果现在在自研 harness，先确认你的差异化在权限模型或上下文控制上，而不是在”封装模型调用”上。后者的边际价值已经归零。

趋势二：信任与验证从”最好有”变成”必须可证明”

证据链：2akouwu/reverify（1,251 星）把”模型提议、确定性工具判定”做成 MCP server：在 71 个真实 Windows 系统文件上，AI 的教科书答案错了 97%，它全部拦下、0 例误放行；ripwire 把质量门禁做成协议，让 15 个互不共享上下文的 Agent 收敛到同一套”修掉或书面说明理由”的纪律；internet-court/internet-court-skill（6,300 星）在给 Agent 间商务做信任层（自然语言委托、ERC-7710 委托权限、x402 支付）；KimGLee/Cambium（468 星）在做 LLM 维护知识库的治理标准。

一个反向信号：cloudflare/security-audit-skill 星数停在 22,992，最近推送是 2026-09-14。一个曾被当作”Skill 供应链安全”标志的项目，热度平了。这不说明安全不重要，而说明**“做一个安全 Skill”比”让安全结论被信任”容易得多**：前者是内容，后者需要评测集。

判断：未来一年，“Agent 说的话要不要信”会从工程细节变成采购条款。可验证性会成为 harness 的硬指标，而”我们用了 AI 交叉检查”这种说法会越来越不够用。

趋势三：瓶颈从”能力”转移到”预算”与”身份”

预算这一侧：Konnect 的 226 个工具等于 23K token，路由只加载 2K；trueforge 把 deferred tool loading 与 large-result offloading 做成默认能力；ripwire 干脆把”少读文件”当成产品定位；连推理层的 warp 都在算缓存预算。上下文正在从”随便装”变成需要显式管理、需要监控、超了要报警的资源。

身份这一侧：Tencent/BrowserSkill（7,860 星）让 Agent 使用你已经登录的真实浏览器，同时给 Agent 一个独立可见的窗口，需要人工接管时把标签页借出去再收回；browser-use/jev-ultrafast（21,297 星，创建 13 天）用”动态索引动作空间”把一次决策压成一个网络往返，官方给的例子是 Zürich → London 的 Google Flights 搜索 7.1 秒完成。另一面是 antibrow/antibrow（886 星）这类内核级反检测浏览器，以及配套的 harness 插件。

判断：上下文预算会像显存一样被显式管理。身份这一侧会出现更硬的外部约束。当 Agent 代替人操作网站，“这个请求代表谁”必须有答案，而反检测工具与平台风控的对抗会成为常态。企业现在就该问自己一个问题：你的 Agent 用谁的账号、以什么身份、留下了什么审计记录。

八、落地启示

给企业开发者与技术决策者六条可以直接执行的建议：

1. 先定权限模型，再选框架。 四种形态对应四种信任假设：信机器（Dormice）、信边界（clawk）、信会话（sandbase-harness）、信契约（open-connector）。权限模型会渗进业务代码，改起来远比换框架贵。
2. 把上下文当成有预算的资源来管。 一个 MCP Server 暴露多少工具，应该和你的任务面宽度成正比。Konnect 的做法（2K token 起步工具集加按需拉取）可以直接抄。
3. Agent 的产出要过确定性门禁。 “模型提议、工具判定、只信验证过的”比”让另一个模型 review”可靠得多，因为判定权交给了可复现的程序。reverify 的 97% 错误率是个好参照。
4. 记忆选文件，不选黑盒。 合规场景下，“能证明删干净”比”召回率高两个点”重要得多。
5. 对”三个月涨了几万星”的项目看两个指标：issue 响应速度，以及有没有人在生产里真跑。星数是需求信号，issue 数是供给能力的信号。
6. 许可逐个核，不要信平台自动识别。 本期出现的 AGPL-3.0（Konnect、T3MP3ST）与 GPL-3.0（open-reverselab）在”通过网络提供服务”的场景下有额外义务；表里标”未声明”的一律打开仓库读 LICENSE 文件。

参考

• Harness engineering: leveraging Codex in an agent-first world — OpenAI 官方文章
• Harness engineering（Martin Fowler 站） — 前馈与反馈的框架
• Harness Engineering — 方法论文集，CC BY 4.0
• Shepherd: Programmable Meta-Agents via Reversible Execution Traces — arXiv 论文
• StoryScope — 叙事结构特征检测 AI 生成文本
• Agent Skills 规范 与 skills.sh — Skill 的分发与注册
• Open Knowledge Format v0.2 — Agent 记忆的开放格式
• Model Context Protocol — 协议与文档
• E2B — Dormice 兼容的沙箱 API

文中各项目的 Star、语言、许可与最近推送时间，均取自 GitHub 公开接口的同一日快照（2026 年 9 月 29 日），项目名可直接点开核对；“星 / 天”由该快照的星数除以仓库创建至该日的天数得出，只用于横向比较量级。