dsh-rule-engine
v0.5.6
Published
DSH 规则执行引擎 v3:容器解析 AGENTS.md + 理解器 + 匹配机 + 执行框架
Maintainers
Readme
dsh-rule-engine
DSH 规则执行引擎 v3 的插件实现。它把 ~/.dsh/AGENTS.md 当作唯一真相源,自动解析规则四要素与执行等级,再通过「工具守卫 + 文本检测 + 时序检查 + 审计台账」执行用户规则,而不是内置一套与用户无关的安全清单。
项目背景
这个项目来自一个非常具体的个人需求:
- 作者是零编程基础用户,但极其重视规则的制定、执行、遵守与复盘。
- 作者发现:规则如果只写在文本里、靠模型“自觉”执行,会反复失效(例如时间词写错、内联命令违规、交付前漏验证等)。
- 因此核心思路是:规则的执行不能只靠自觉,要尽量靠插件在机制层强制。
- 本插件所有规则均从
AGENTS.md动态解析,规则增删改后无需重写插件。
当前实现基于已有的 AGENTS.md 规则体系拓展,社区暂无类似插件供参考(大概率为该等约束可能限制开发自由性,不适用于专业编程人员),可能存在大量不完备、误判或边界问题。欢迎任何使用者提出调整建议、提交 issue 或 PR。项目仍处于“可运行但需要持续打磨”的阶段。
功能分层
- 阶段 1 容器:解析 AGENTS.md 全部规则 → 理解产物(
rule-understanding.json可生成) - 阶段 2 匹配机 + 工具守卫 + 文本检测
- 阶段 3 时序检查 + 授权询问集成
- 阶段 4 D 级自证调度 +
/guard命令完善
当前实现以「模式库兜底」为主,LLM 理解器预留扩展点;所有规则均从 AGENTS.md 实时解析。
任务契约与反过度工程(可选)
- 默认关闭;可在规则引擎设置页开启「任务边界与反过度工程」总开关。
- 开启后默认观察模式,只审计提醒;切到
armed才真正拦截。 - 弹窗询问默认关闭;
askEnabled开启后,对依赖/hash 等动作走官方 approval 询问。 - 支持
/guard mode|budget|contract|label命令。
命令
| 命令 | 作用 |
|---|---|
| /guard status | 引擎状态(规则数/置信度/放行/解锁) |
| /guard rules | 规则清单 + 理解产物 |
| /guard active | 最近激活了哪些规则、为什么 |
| /guard log [N] | 最近 N 条审计 |
| /guard unlock [N] | 解锁配置写保护 N 分钟(仅用户) |
| /guard bypass [N] | 临时整体放行 N 分钟(仅用户) |
| /guard lock | 立即恢复全部守卫(取消解锁/放行) |
| /guard revoke | 撤销全部授权记录 |
| /guard reload | 强制重解析 AGENTS.md |
| /guard mode <模式> | 设置任务契约模式(review/answer/change/monitor/watch/off) |
| /guard budget ... | 设置预算(agents=N files=... deps=allow hash=allow) |
| /guard contract | 查看当前任务契约 |
| /guard label <id> <label> | 给审计记录打标(correct/incorrect/inconclusive) |
装配方式
本插件已按官方 bundle 规范打包,包内自带 cordis.patch.yml。
推荐安装方式:
dsh plugin --profile web add dsh-rule-engine或手动将 dsh-rule-engine 加入 profile 的 dsh.profile.bundles 数组。包内的 cordis.patch.yml 会自动挂载插件行:
- insert:
- id: dsh-rule-engine
name: 'dsh-rule-engine'如果你是从源码手动调试,也可以沿用 insert 方式挂载,但正式安装建议走 bundle。
安全设计
- 只读操作(read/grep/glob/read_image/str_replace_editor view)无条件放行,拦截只针对变更类操作
- 插件自身配置/理解产物对模型只读:直接
edit/write会被守卫拒绝,需/guard unlock - AGENTS.md mtime 变化后自动重解析(
fs.watch+ stat 兜底),规则增删改无需重启 - 修改插件 lib 代码后必须重启 DSH 生效:bundle 装配下
dev_reload_package热重载不可靠(报成功但行为仍旧代码,踩坑 65);重启后以行为实测(如“请继续”放行)验证 - LLM 意图兜底:对词表低置信/歧义的用户消息异步调用
ctx.llm判定意图(sha256 缓存 + 会话每日限额),词表判拦且 LLM 高置信判执行时放行;失败自动降级词表(rule-engine.json的llmIntent配置段可开关/调阈值) - 状态信号:用户“我已重启/已输入/完成”等就绪确认与无消息回合不做规则 22 拦截,敏感操作仍由 12A/13A 把关(规则 22⑩)
- 低置信规则不参与硬拦,避免误伤;在
/guard rules中标记人工复核 - 授权证据按“操作类型 + 目标路径前缀”结构化匹配,区分“询问”与“授权”
- 备份证据按“目标路径 → 备份路径”记录,删除/覆盖前必须存在对应路径且备份文件真实存在
- 版本/手册类文件写后自检:版本号连续、append 不覆盖上一行,失败自动回滚并审计
- 跨工具一致性:同一敏感操作经
edit/write/str_replace_editor/pwsh必须得到相同拦截/放行结论 - 命令输出静默错误检测:全 false/0/null 或与上一条完全一致时审计 + 注入提醒,不阻断
- 注入提醒通道实测限制(2026-08-24,O1 实测——已修复,批次 6): 根因:
agent.inject在session/event观察回调内同步调用,命中 dsh-session 的 append 重入保护(session append cannot reenter,日志kind:inject可见);2026-08-24 批次 6 已修复:投递延迟到 append 发布边界之后(宏任务),语义不变(inject 官方语义即“为下一 pre-step 排队、不唤醒”);审计从注入异常变为注入已投递可对账(详见局限 6) - 消息注入判别(机制 A,2026-08-24):
user/message先判source.kind(user以外的官方/插件注入一律跳过:不覆盖回合状态、不产生授权),并用已知注入模板兜底(Current runtime context 快照 / Background subagent 通知 / vision-router 挂载提醒 /[规则引擎]前缀),全部留source-skip审计——系统注入与插件挂载通知不再污染授权池 - 工具分类制(机制 B,2026-08-24):工具按 analysis / artifact / mutating / unknown 四类判定;未归类工具(新装插件的工具)首次调用走 ask 确认(防“参数名猜不出就放行”的绕过),已归类只读命令(
npm test/git -C/node --check/gh auth status等,按命令链分段判定)无条件放行 - 授权双轨 + revoke 全清(机制 C,2026-08-24):自动来源授权(执行分点/ask/指令)绝不写入全局池(全局仅显式白名单);
/guard revoke全清 session + turn.scopes + global + askRejections;授权路径匹配带边界(d:/a.txt不再误匹配d:/a.txt.bak) - 技能目录实时联动:
ctx.skills目录变化后自动刷新,已禁用/不存在的技能不触发 12B - LLM 增量理解:对非 high 置信规则调用
ctx.llm补全结构化理解,失败自动回退模式库;AGENTS.md 变化触发重载后会自动补一次增量理解(按规则+版本去重,不重复烧 token) - D 级自证泛化:按规则特征触发自证提示,每规则每会话限 3 次
- 授权记录默认 10 分钟 TTL,无路径的全局授权 TTL 缩短为 2 分钟;可用
/guard revoke撤销 - 用户直接命令式指令(如“删除这个文件”)也视为授权
- 规则 1 支持“用户明确要求重试”豁免
- 会话状态有容量上限并自动清理,防止长跑内存膨胀
- LLM 理解按“规则 + AGENTS.md mtime”去重,避免重复烧 token
- 审计日志:
~/.dsh/rule-engine.log.jsonl - 守卫使用
ctx.tools.guard()单调拒绝,模型无法自行绕过 - 自由区域(Free Zone):AGENTS.md 中
<!-- free-zone:start -->/<!-- free-zone:end -->标记框住的区段整区跳过(不解析、不产生规则、不硬拦、不审计)——适合放“想生效但不想被机器强制”的软约束(如法律守则)。区内的### [规则 F<n>]条目由配套插件 dsh-rules-manager 在设置页//rules中可见可管理。新增自由规则请手动在标记内编写(/rules add只会插入到 free-zone 之前),详见 dsh-rules-manager 的 README「📝 新增一条自由规则(零基础三步)」 - 禁用规则联动:dsh-rules-manager 的「禁用规则」存储(
~/.dsh/disabled-rules.json)会被引擎读取,被禁用的规则标记为 disabled,不参与硬拦/纠察;恢复启用后自动重新生效
当前局限与后续优化路线
当前版本已经具备完整四层骨架,但距离“成熟”仍有距离。以下是一些难度较高、尚未完全实现的优化方向,欢迎社区共同推进:
LLM 理解器深化 当前只对非 high 置信规则做一次 LLM 增量理解;未来应支持“规则变更窗口期”、增量重理解、低置信人工复核队列。
授权语义精确化 当前 ask 授权记录为宽泛
any+ 路径前缀;未来可要求 ask 面板显式声明操作类型,或支持“一次授权仅针对单个 callId”。备份证据完整化 当前校验备份文件存在;未来可增加哈希/大小一致性校验、备份链管理与自动清理。
规则 12C / 13B / 10 / 15 / 19 等流程类规则深度执行 这些规则需要更多业务语义(下载校验、会话三层验证、版本判断、知识沉淀),目前偏“自证提示”,尚未做到机器可判定。
跨会话持久化 授权/备份目前为内存态,重启失效。持久化涉及写入保护、并发与恢复,风险较高,暂未实现。
输出文本实时拦截 受 DSH 官方架构限制,
assistant/message无法“拦下不发”,只能事后审计 + 纠正注入;这是平台边界,不是插件能单独突破的。 另外(2026-08-24 实测 O1 → 批次 6 已修复):纠正注入通道根因是引擎在session/event观察回调内同步调用agent.inject,触发 dsh-session 的 append 同步重入保护(session append cannot reenter while another append is being published,kind:inject审计全程可见——注入消息从未到达模型/界面);修复为延迟到 append 发布边界后投递(宏任务setTimeout 0),inject 官方语义本就是“为下一 pre-step 排队、不唤醒”,语义不变;审计 reason 从注入异常:session append cannot reenter...变为注入已投递(agent=...),可对账(测试test/phase1f-inject.test.mjs锁定)。
致谢
感谢以下项目与作者的无私开源付出,本项目在开发过程中直接受益:
- DeepSeek Harness 官方团队(@deepseek-ai):提供了 DSH 平台、插件机制与官方文档。
- 本机已安装插件的作者们:
- dsh-guardian(lonelymoon87)
- dsh-visualize(Nagi-ovo)
- dsh-rules-manager(jilian-dsh)
- dsh-vision-router、dsh-super-injector 等未列出的作者
- 学习参考的社区文档/库作者:
- dsh-handbook(Electricitysheep)
- SandBase deepseek-harness-handbook(sandbaseai)
- 以及 DSH 官方文档镜像与源码维护者
免责声明
本项目是个人/社区项目,不属于 DeepSeek Harness 官方项目,与官方无隶属关系。使用风险自负,请在生产环境前充分测试。
开发与测试
npm test
bash scripts/build.shLicense
MIT
