pi-jev

为什么选择 pi-jev？

当 Pi 工作流缺少的是轻量语义判断，而不是另一个编程模型时，pi-jev 就有用。传统安全钩子擅长识别已知命令模式，例如破坏性的 Git 操作或明显的文件删除。pi-jev 则针对操作含义与范围向 Jev 提出具体问题，再由普通代码根据返回概率决定后续行为。

对语法正常、但结合上下文可能有问题的操作，这一区别很重要。写入系统配置文件在某个任务中可能完全合理，在另一个任务中却明显越界。该扩展将这类判断显式化，避免完全依赖主编程模型对自己的操作做推理并相信自己的结论。

pi-jev 应视为行为防护层，而不是沙箱。Pi 本身使用本地用户的权限运行，其文档建议对不可信仓库或无人值守任务采用容器、虚拟机、微型虚拟机等操作系统级隔离。pi-jev 增加了判断节点，但不会建立权限隔离边界。

核心工作流程

实际流程是在选定的 Pi 工具活动前后做两阶段检查。执行会改变状态的操作前，pi-jev 从当前任务上下文构建简要状态，分别询问 Jev 各项风险。回答保持为独立数值信号，阈值逻辑由扩展负责。因此，修改策略无需让模型重新生成解释或决定动作。

shell 命令完成后，第二次判断可以检查返回文本，分析执行前无法获得的信息，例如输出是否包含凭证，或失败属于暂时性、环境、权限、调用方式还是代码问题。

jev_ask 的用途不限于安全。当前 Pi 智能体可将具体的语义判断交给 Jev，获取概率、类别或分数，而非生成一段文字。后续代码需要依据答案分支执行时，这种方式尤其有用。

适用场景

最适合的场景是：确定性规则已能发现明显危险，但在意图和任务范围上仍有缺口。例如判断一条看似普通的命令是否把本地数据传出电脑、计划中的修改是否超出用户要求，或工具结果是否应改变下一步恢复策略。

另一种用法是智能体侧分类。Pi 扩展或项目流程可通过 jev_ask 标记错误类别、判断证据相关性，或按简短评分标准评价结果。最终只需一个 if 分支的决定，就不必占用通用编程模型的一整轮对话。

对于确定性策略，这种方法的价值较小。如果某条命令绝不能执行，直接规则或沙箱策略比概率阈值更便于审计。语义判断最适合边界依赖上下文、字符串匹配难以可靠表达的情况。

同类工具对比

与 Pi Safety、CC Safety Net 或基于 AST 的命令过滤器相比，pi-jev 以语义解释取代确定性匹配。它可覆盖没有稳定命令特征的上下文相关情形，但也引入网络延迟、外部 API 依赖和阈值调整。

Pi Permission Gate 更接近，因为它也在执行前通过模型辅助分类风险。主要区别是决策接口：pi-jev 围绕 TypeSafe Jev 的类型化概率输出和固定判断维度设计；通用 LLM 关卡表达力可能更强，但需要更多提示词与输出处理。

两种方法都不应被当作隔离机制。面对可能恶意的仓库或自动化任务，操作系统级沙箱仍是更强的控制，即使模型或防护层误判，也能限制进程实际可访问的资源。

配置建议

合理的落地方式是先使用影子模式，在不拦截的情况下收集实际仓库和命令样本。内置阈值由作者做过冒烟测试，但 README 明确说明，调用前的校准不等于经过标注的生产评估集。不同项目对破坏性、越界及可接受数据外传的定义可能很不同。

对隐私敏感的项目，缩小需判断的工具范围可能比调整模型阈值更重要。仅检查 bash，可避免在调用前将 write 和 edit 的文件正文发出。降低参数与输出字符上限能进一步减少外传上下文，但也会减少 Jev 可据以判断的信息。

无人值守或 RPC 驱动的会话中，应先确认无界面行为，再依赖其拦截。无界面模式无法显示交互确认，因此若要求强制停止，必须明确配置非 UI 阻断行为，并在与生产相同的执行模式中测试。

迁移建议

替换确定性防护时，不应立即删除原策略层。先让 pi-jev 以影子模式运行，比较两套系统各自标记的操作。绝对禁止项通常更适合固定规则，意图与范围模糊的场景则更适合语义判断。

若另一个扩展已拦截同样的 Pi 工具调用，应测试是否出现重复提示、冲突决定及执行顺序影响。较清晰的配置是明确分工：硬规则负责绝对禁止项，pi-jev 负责上下文判断，沙箱负责权限隔离。

pi-jev 依赖外部 Jev 端点，迁移计划也应考虑 API 可用性。文档中的默认行为是请求出错时放行，因此要求保证拦截的流程，不应将远程判断服务本身视为安全边界。