本文是对 @Av1dlive（显示名 Avid）一篇 X Article《How to Build Agentic Harness using Jev (Builder’s Guide)》的摘要与评论。读帖时约 126.7 万曝光、约 1062 赞、3635 收藏、127 转发、60 回复；帖文钩子是「everything you need to start building with jev, in one article」。Article 自称约 3500+ 词，并反复指向应用仓库 codejunkie99/keel。起草时 GitHub API 显示该仓库约 ★355、forks 47；主语言 Rust；许可证 MIT；仓库描述为 local-first 的 macOS coding workspace，带本地 Laya 与可选托管 Jev 决策选型。文中讨论的构建版本是 keel 0.2.0（文末注明链接锚在对应源码快照；main 可能仍保留更早原型）。本稿只做摘要与读法整理，不是全文转载，也不是安装手册。

站内已有 Awesome Jev 目录解读：那篇讲的是「谁在用类型化决策、证据在哪」的生态导航。本稿讲的是同一条 Jev 叙事落进一个真实 coding harness 时，边界怎么画——两者互补，不是重复发同一仓库。

这篇在说什么

先讲场景。很多人说「coding agent」时，脑子里是一次调用：提示词进、补丁出。真实工作更像一串分叉：这次该用哪个模型？要不要先读文件再改？现在允许哪些工具？仓库在决策飞行途中变了怎么办？该重试、弃权，还是问人？改动编译过了吗、焦点测试过了吗、还符合用户原意吗？每一叉的成本不同——小重命名上跑最慢模型是浪费；大迁移上跑过快模型可能换来更多重试。

作者想要的不只是「agent 更聪明」，还想说得清变聪明时到底变了什么。于是他把 Jev engineering 放进 harness（套在模型外面、让 agent 真能干活的那层软件）：系统仍要选模型、限制工具、核对选择、评判结果；关键是给出可检查的选项，并留下足够证据，好判断这次选择有没有帮上忙。

全文主线可以压成一句：模型可以建议下一步，但 host（宿主应用代码）必须拥有这一步；「自我改进」在这里首先是可回放的决策收据，而不是应用自己静默改策略。

文章结构大致四块：① 怎样把 Jev 当成决策层；② 为什么放进 coding harness；③ Keel 0.2.0 实际建成了什么；④ 「self-improving」应该意味着什么、还不意味着什么。

1. 决策层合同：host 备菜单，selector 只点菜

Host 在文中特指围在模型周围的应用代码。它在 Jev / Laya 开口之前，先决定有哪些选项可见；selector 返回类型化结果（固定格式，代码可校验）——含义只有两类：选这个，或 我选不了（abstain）。作者用车间调度员打比方：调度员可以决定哪张工位接活，但不能偷偷改锯子的安全规则。

两个真正交给 selector 的位置，听起来像，发生在不同时刻：

决策	何时	Selector 看见什么	Host 事后做什么
新任务路由	新鲜任务、尚未钉死 provider / model	主机筛过的合格候选路由	再验资格与是否过期；不行就 fallback
DeepSeek 内嵌环的下一步焦点	环内要选当前工作重心	inspect / implement / verify / answer 等 focus id	把 id 映射成工具包，再对照当前工具定义校验

「answer 表示没有工具」是文中很干净的例子：若 selector 说 answer，系统不会再塞一个 shell「指望它老实」——允许的工具包就是空的，因为这就是 answer 在这里的定义。

还有几条硬边界，值得单独记：

• 钉死的路由、正在跑或恢复中的会话，不走自动选型；这不是脚注，是产品规则。
• 经 ACP（Agent Client Protocol，一种让宿主挂接外部 coding agent 的客户端协议）接入的 Claude Code / Codex / Cursor 等，各自保留自己的工具环；本构建里 Jev / Laya 不接管那些内部步骤。能力清单上写着 slash command，也不等于 host 有可调用的 API——有时只是变成塞给 provider 的提示文本。
• 选择 ≠ 授权。 Jev 可以选候选，但不能批准危险动作；需要权限的工具仍走原有许可与用户确认。高置信度也不发执照。
• 计算机使用（computer-use decide） 同样只选 host 备好的低风险动作 id 或弃权，命令本身不执行桌面点击；执行与选择拆开。

执行前还要再验一遍状态：provider 列表变了、路由过期了，就拒绝并走 fallback；DeepSeek 环里工具 schema 变了，也要在派发前再查一次命名工具。作者原话大意是：无聊的检查，正是安全检查该有的样子。弃权必须是合法结果，而且要先写好 fallback，并记录何时用了 fallback，免得把兜底当成 selector 的功劳。

解读： 这一节的价值，是把「让模型管一切」收成可调试的窄接口。站内 Awesome Jev 文强调「类型化答案给 if/switch 吃」；这里进一步说：连菜单本身都不能由模型发明。

2. 为什么非得放进 harness

独立 demo 可以展示模型在三个标签里挑一个；它告诉不了你这个选择当时能不能用。放进 coding harness 之后，host 才能回答一串工程问题：选项当时是否真的可用？任务是新的、钉死的，还是已在跑？选中的工具执行时还在不在？权限层允不允许？工具回了什么？校验有没有发现回归？

作者的观点很直白：给我看选项、选择和结果；没有这些，「agent 进步了」多半是氛围。

三种模式也写清了：

模式	跑在哪	需要什么	做什么
Laya（默认）	本机 Core ML（苹果本地模型运行时）	Worker 与钉死的 checkpoint	从 host 备好的候选里选，或弃权
Jev（显式开启）	TypeSafe 托管	机器上已有的受保护凭证（文称无单独输密钥屏）	发出有界决策请求
Normal	不调 selector	你的 coding provider 配置	走普通 harness 路由

每次决策只跑一个后端。文中反复提醒：本地 selector ≠ 编码工人也在本地跑——ACP 工人仍可能打托管模型；要按跳追踪，再谈「本地 / 隐私」。

额外选型调用必须「赚回票价」：若选工人比干活还久，就只是精致的等候室。作者明确说本文没有用 coding benchmark 证明这笔额外调用一定划算；selector 也挑不出 host 忘了放进菜单的好选项。

解读： 这里最值得带走的不是「又一个路由产品」，而是评价标准——总任务成本（选型耗时 + 工人耗时 + 重试 + 人工审阅），以及「决策层可替换、调用方不依赖散文」。

3. Keel 0.2.0：从能跑的工作区长出来

交付物是 keel 0.2.0：local-first 的 Mac 编程应用；基底是 Avid 衍生的 coding workspace；语言 Rust；界面框架 GPUI；平台要求 Apple Silicon + macOS 15+。作者特意拆开两类工作：应用本身（会话、provider、工具、本地决策模式）与 Jev engineering 的研究/评测材料——相关，但不是同一交付物。

设计过程被压成可执行的五步：找出 selector 能做、host 仍能检查的边界；把选项显式化；保住用户意图（钉死 / 在跑不偷偷改道）；先做日常路径（Laya 默认、Jev 可选、Normal 仍在）；给失败赋形（格式坏了、id 非法、状态过期、弃权，各自有结果）。路线选择的白话流程是：新鲜未钉死任务 → host 读可用 provider/model → 构造有限候选 → Laya 或 Jev（若启用）返回 id 或弃权 → host 再验 → 开跑或 fallback → 写下决策记录。

README 侧还补充了产品能力轴（以仓库现状为准）：会话与变更视图、经 ACP 挂 Claude Code / Codex / Cursor / Grok 等、进程内 DeepSeek 环与 host 强制的工具焦点、决策收据导出与报表、keel headless / daemon 等。仓库写明目前不提供可下载的应用发行包，需按文档从源码构建——解读文读到「可自学架构」即可，不要把它写成「一键安装商店应用」。

解读： 「Jev-first」野心被收成「代码管得到的边界」。在架构图上再画一支箭，不会自动长出 API——这句话适合贴在任何 Agent 架构评审墙上。

4. 「自我改进」：收据可回放，应用不自训

标题容易让人期待科幻式自进化。作者画的线很清楚：

• 已发布应用记录 selector 活动与结果，以支持评测；
• 不会从聊天历史自动训练 Laya；
• 不会在失败后静默改写自己的策略；
• 本发布不证明科幻意义上的自我改进 agent。

它提供的是反馈环的起点：收据 → 场景 → 对改过的提示词 / 策略 / 模型做回放 → 人审差异再决定是否采纳。失败案例要留下来（候选、所选 id、host 校验、fallback）；工具 schema 中途变更，也要能复现「重建工具集滤掉旧工具 / 仍被请求则拒绝」。通过任务本身不能证明功劳归 selector——工人在原路由上也许本来就能过。文中给出的是评测设计提议，并声明没有主张测到了编码质量增益。生产变更保持人工门禁：候选构造规则、selector 提示与 schema、fallback 策略、本地或托管路由、focus 对应的工具包——每项改动保留旧版、回放相关场景、看回归，再人工批准新基线。

收束清单几乎可当检查表：从 host 能检查的一个选择开始；Jev 只在 host 备好的选项里挑，不拥有 host；Laya 与 Jev 是不同模式；provider 内环归 provider；选型不授权；记录服务未来评测，不等于应用在自训。公开的 Jev engineering 仓库装框架与例子，Keel 才是本文讨论的应用构建。

解读： 在「Agent 会自己变强」刷屏的语境里，这篇最稀缺的诚实是：先把做错的事记得住，再谈变好。 与站内 Annie Wang 长文里的 harness / 检查点精神同族，但落点换成了 类型化决策收据 + 人工门禁的改进环。

适合谁读、不适合谁

更适合：在做或评审 coding harness / 多 provider 路由的人；已经接触 Jev / System One，想看它怎样嵌进真实 Mac 应用边界的人；想对照「营销级自我改进」与「可回放评测」差异的人。

不太适合：只想要 Windows / Linux 一键安装包的人（本构建明确偏 Apple Silicon + 源码构建）；指望读完就证明「Jev 一定让编码质量上升」的人（作者自己没这么主张）；以及把本稿当成 Keel 全文说明书或 Jev 官方文档替代品的人。

原文与延伸

• X Article 与帖：Av1dlive / 2102802621664985241
• 应用仓库：codejunkie99/keel（文内亦链到 decision_mode.rs、jev_routing.rs、embedded DeepSeek agent.rs、docs/decision-architecture.md 等 0.2.0 快照路径）
• 站内对照：Awesome Jev