# 未来工作 —— 明确不做的部分 这些是对门控模型的扩展，经过考虑后**明确不做**。在此记录，是为了让下一个想到同样点子的人能找到已有的推理，不必从头重做分析。 适用规则：**默认与参考实现保持一致（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. 如果当初的推理仍然成立，这里的分析就是对该请求的答复。