未来工作 —— 明确不做的部分#

这些是对门控模型的扩展，经过考虑后明确不做。在此记录，是为了让下一个想到同样点子的人能找到已有的推理，不必从头重做分析。

适用规则：默认与参考实现保持一致（claude-code / opencode / hermes）；只有存在具体的用户痛点时才新增机制。下列条目都没通过这条测试。

如果后续有用户把其中某一项当作真实问题碰到，就把症状补进本文档并推进实现。

1. 按会话的 gating 开关#

设想：让用户为某一次聊天会话覆盖 agent profile —— “在这次对话里，也启用 prod-deploy”。

为什么会被提出：偶尔某个 agent 角色的 gating 对于一次性任务来说过于收紧，而编辑 profile 又显得太重。

为什么不做：

• 没有任何参考框架有这个。claude-code 的 permissionMode 是按 agent 的，不是按会话的。opencode 的 ruleset 是按 agent 的。hermes 没有按会话的逃生口。
• 现有工作流是：编辑 agent.json，保存，下一轮就会读取生效。热重载很快。
• 加上按会话的覆盖会带来一个状态管理问题（覆盖存在哪里？刷新页面后还在吗？会在 WS 重连之间泄漏吗？），在没有证据表明更简单的“编辑 profile”工作流不够用之前，不值得去解这个问题。

何时重新考虑：如果用户开始提类似“我为了这一个调试任务反复来回编辑 agent.json”的 issue。

2. 插件子进程沙箱#

设想：在子进程里运行插件代码，限制其文件系统 / 网络访问 —— 用 subprocess.Popen 配合 seccomp-bpf 或类似手段。

为什么会被提出：插件带的是任意 Python 代码；恶意插件可能外泄 API key 或 rm -rf 整个工作区。

为什么不做：

• claude-code、opencode、hermes 都是在进程内加载插件的，没有一个对插件代码做沙箱。
• 插件已有信任级别（plugin.json 声明 trust: "verified" | "community"），危险能力在信任级别而非操作系统级别上做门控。
• 在 macOS / Windows 上做真正的沙箱确实很难 —— seccomp 只限 Linux，App Sandbox 只限 macOS，二者都覆盖不了跨平台开发的场景。
• 威胁模型还不足以支撑这份工程成本：插件安装是一个带 manifest 审查环节的显式用户动作。

何时重新考虑：如果哪天支持自动插件安装（例如让 LLM 在对话中途自行决定安装某个插件），威胁模型就变了，沙箱届时值这份成本。

3. Skill 的 requires 链#

设想：在 SKILL.md frontmatter 里加一个 requires: [other-skill] 字段 —— 调用 prod-deploy 时自动先加载 kubectl-helpers。

为什么会被提出：skill 有时依赖其他 skill 的上下文。目前用户需手动串起 /skill A /skill B。

为什么不做：

• 没有任何参考框架有它。Anthropic 的 SKILL.md 规范没有 requires 字段。
• 由 LLM 居中选择的模型假定模型会读取全部 SKILL 描述并自行挑选。如果 skill A “需要” skill B，正确答案通常是“把它们合并”或“在 A 的描述里写明它和 B 一起用效果最好”—— 而不是新增一张需要用户维护的依赖图。
• 依赖解析会引入加载顺序问题（依赖是否先于父项加载）、冲突问题（两个 skill 各自需要互不兼容的第三个 skill），以及版本问题，而这些问题在代码库其他任何地方都不存在。

何时重新考虑：如果 skill 作者开始反复以人类可读的形式写下“把这个 skill 和 X 一起用”，那就是一个真实信号，说明 requires 字段可以替代这些样板。

4. Hook 级 gating#

设想：claude-code 的按 agent 的 hooks 字段 —— 注册作用域限定在某一个 agent profile（而非全局）的 PreToolUse / PostToolUse 处理器。

为什么会被提出：插件 hooks（openprogram/plugins/hooks.py）把所有已加载插件的 handler 订阅到进程级事件总线上，没法说“这个 agent 跑这个 hook，那个 agent 不跑”。

为什么不做：

• 插件 hook 订阅已存在但用得很少 —— 几乎没有插件注册。在全局机制尚未被充分使用之前就加按 agent 的作用域，为时过早。
• claude-code 的按 agent hooks 确实存在，但它的文档暗示大多数用户是通过插件（host 级）注册 hook 的，而非按 agent。
• 统一门控模型已经覆盖了哪些 tools/skills/MCP 这个问题。Hooks 是一个调用如何通过的问题 —— 是正交的。加上按 agent 的 hooks 并不改变门控模型，只是多一个开关。

何时重新考虑：当有人写出一个需要按 agent 表现不同的插件时。大概率还要几个月。

5. 单一 ruleset 迁移（opencode 风格）#

设想：用单一的 permission: [{pattern, action}] 列表替换三个块（tools、skills、mcp）。

为什么会被提出：更干净、单一事实来源、以后更容易加入第 4 种扩展类型。

为什么不做：

• 按类型分的字段形态本身就是自解释的。迁移是纯重构，除语法层面外不带来任何新能力。
• 向后兼容成本 —— 用户 ~/.openprogram/agents/ 里现存的每个 agent profile 都需要迁移代码或一个弃用周期。
• Opencode 的 ruleset 是首次匹配获胜的，这意味着规则顺序很重要。按类型分的结构没有顺序方面的顾虑（每个块相互独立），少一类容易犯的错。

何时重新考虑：当受门控的扩展类型加到第 5 或第 6 种、schema 开始显得臃肿时。目前 3 种，按类型分的形态仍然划算。

如何重新考虑其中任何一项#

1. 找到症状 —— 一条用户抱怨、一次真实事故，或一个带具体用例的功能请求。
2. 与本文档交叉比对，查明当初的推理。
3. 如果当初的推理已被推翻（例如“没有参考实现有这个”已不再成立，因为 opencode 上个月加了它；或“没有用户痛点”已不再成立，因为为此收到了多个 issue），则推进实现，并更新本文档记录新的背景。
4. 如果当初的推理仍然成立，这里的分析就是对该请求的答复。