EveryInfra Blog · BL-25
Jev 生态观察（二）：30 个 agent 守门项目，拦住了什么、放过了什么
给编码 agent 站岗是 Jev 生态第一大场景，72 小时内 30+ 个项目同质化。我们把它们拆成四种守护形态，对照带数字的实测案例，提炼出可以照抄的设计原则。
上一篇我们交代了 Jev 生态四天的全貌。这一篇深潜第一大场景：给 agent 站岗。TypeSafe 发布 Jev 后 72 小时内，仅"agent 安全/监督"一类就冒出 30+ 个项目，到第四天已经同质化到从业者自己开始喊"红海"——这恰恰说明需求真实。本文把它们拆成四种形态，对照少数带数字的案例，回答一个实用问题：你的 agent 到底该装哪种门。
先交代证据口径：以下项目数字全部为作者自报（我们按证据强度做了 A/B/C 分级），延迟与成本用项目侧实测值；完整案例集在 jev-radar，每条带一手出处。
为什么守门突然成立了
agent 守门不是新想法，以前做不成是经济账：让 LLM 判断"这个工具调用危不危险"，一次推理几秒钟、几分钱，塞进 agent 每一步，循环直接被拖死。pi-warden 的 README 给出了新账本：单次判断约 1,000 输入 token、约 $0.00004、约 0.3 秒（作者自报）——"每次守卫调用都过一遍"第一次不心疼。这就是为什么守门类成为第一大场景：延迟和单价把"每步监督"从奢侈品变成了默认件。
四种守护形态
把 30+ 个项目按"判什么、拦不拦"切，其实是四种形态：
- 影子监督：判规则符合性、废话、卡死、"说做完了但没测"；不拦，把判断注入上下文让 agent 自纠。代表：pi-warden、Foreman。
- 硬边界 + 灰区判断：判白名单之外的调用；拦，但硬规则优先、Jev 只判灰区。代表：jevgate、rh-guard。
- 审批闸门：判昂贵或危险步骤前的最后一道；拦下转人工或降级。代表：toolgate、noulgate、hermes-approvals。
- 声明对账：判 agent 声称的与实际发生的对账；事后揭示，不实时拦。代表：clear-head。
影子监督是证据最足的形态。pi-warden 在每次写入时让 Jev 对照项目规则文件做判断，把违反的规则"引用回"agent 自己的上下文——用户不打断，agent 收到一次纠正。作者的两组自报数字值得记下：150 次配对无头运行中，关闭守卫时规则被破坏 6 次，开启后 0 次；321 个真实会话、17,160 次守卫调用里只 hold 了 42 次，其中 5 次被作者下一条消息放行，37 次维持——好守门是稀缺干预，不是见谁都拦。它还有个细节：某个拦截能力（off-task 判断）在作者自己的评测里落败后没有被删除，而是降级成"轻推"。
硬边界 + 灰区判断的设计最值得抄。rh-guard 专拦编码 agent 的 reward-hacking——篡改评分器、偷看隐藏测试、操纵评测过程。它的架构立场写在 README 里：结构化硬规则先拒，Jev 只判剩下的灰区，录制 demo 里 sed 改断言被拦下、无害 echo 放行。同族设计者把这条原则说得更直白：jevgate 是"白名单证明什么可以跑，Jev 只判名单外的部分，软判断永不单独一票否决（fail-open）"——校准概率会错，所以它不能是那道唯一的门。这个家族甚至长出了一个"什么时候不该用 Jev"的设计判断层（Augustus）。
审批闸门给昂贵步骤设收费口。hermes-jev-approvals 是这一类少数带对比数字的：自报比原方案快 8.7 倍、便宜 4 倍。toolgate 则默认影子模式——先只观察记录，攒够信任再开拦。
声明对账最新也最轻：clear-head 在 agent 声称"已完成"时核对其宣称读过的东西与实际读到的，专门抓"说做了但没做"。
一个反面教训
WebMCP 基准（nekuda-ai，开源可复现）给所有守门项目泼了盆有用的冷水：裸 Jev 挂上浏览器 harness 只解出 49 项网页任务里的 25 项，配上把点击序列压缩为单次工具调用的 WebMCP 层后才是 49/49。结论适用于守门设计：选对合法按钮不等于选对下一步——判断层的价值受制于你喂给它的状态形状。守门项目同理：问题问得窄、状态给得对，判断才可靠。
如果你要装一扇门
从 30+ 个项目里提炼的五条设计原则，按重要性排序：
- 硬规则兜底，Jev 判灰区：能用白名单和结构化规则表达的就不要交给概率判断；Jev 负责的是规则覆盖不到的地带。
- fail-open，软判断永不单独一票否决：校准概率会错，错误的方向应该是多问一次人，不是拦死工作流。
- 先影子，后拦截：先只记录不干预，看误拦率再决定开不开闸（toolgate 默认即此）。
- 窄问题：判"是否不可逆、是否符不符意图"这类可枚举窄问题，不判"这个改动好不好"（Supercov 教训在守门场景同样成立）。
- 评测落败的能力降级而非删除：保留能力、降低权限，比整个砍掉保留更多信号（pi-warden 的 off-task 处理）。
红海之后的机会
单形态 10+ 实现之后，新项目的差异化路径已经清晰：往细分宿主走（Neovim 的 jury.nvim、Emacs 的 jev.el、GitHub Actions 的 git-judge-jev、OpenCode 插件族），往新判断类走（rh-guard 的 eval 完整性、clear-head 的声明对账），或者往设计层走（Augustus 的"何时不该用"）。对后来者的启示：通用守门的位置已经满了，但每个新宿主、每种新越界行为都是新门位。
判断层的事讲完了。下一篇我们看这个生态的另一面：那些翻车的样本。如果你要给判断层喂数据——评论、口碑、价格的可靠采集是 EveryInfra 的本行，从统一数据 API 接入指南开始。