一个 AI 助手如果只能回答问题，很容易让人觉得不够智能。于是 Agent 系统不断增加能力：它可以读取文件、修改配置、调用外部服务、保存记忆，还能把成功经验整理成技能，留给未来的任务复用。
这些能力单独看都很合理，组合起来却可能产生一种令人不安的体验：用户只是要求清理几个不想要的技能，Agent 却在清理结束后主动创建了新的替代技能；用户只是问一个功能是否值得调整，它便开始搜索历史、查询文档，查询失败后还继续更换工具。它似乎越来越“懂得下一步该做什么”，但用户对系统的控制感反而越来越弱。
问题并不只是 Agent 做错了一次判断。更值得追问的是：为什么一个原本以帮助为目标的系统，会把“主动完成更多事情”当成默认正确的行为？
Agent 的主动性并不是凭空产生的
Agent 看起来像是在自主决定，实际行为通常由三层共同塑造：指令告诉它什么叫完成任务，工具决定它能做什么，持久化机制则让一次动作影响未来。
指令
→ 定义什么叫“做得好”
工具
→ 把判断变成真实动作
持久化
→ 让动作跨会话继续生效
如果系统指令要求 Agent 在复杂任务结束后主动沉淀经验，它就可能把“创建技能”理解成完成任务的一部分。如果工具列表同时提供写入技能的能力，这个判断便不再停留在建议层面，而会直接变成文件。技能又会在未来会话中被发现和加载，于是一次未经授权的扩展获得了长期影响。
从模型视角看，这可能是在遵循“不要停在半成品”“主动减少用户未来的重复劳动”等要求；从用户视角看，它却越过了所有权边界。双方对“完成”的定义并不一致：Agent 认为完成包括替未来做好准备，用户认为完成只包括当前明确授权的范围。
读取技能和创建技能不是同一种能力
以 Hermes Agent 的技能机制为例，读取和写入有着完全不同的风险。
skill_view 用来读取已有技能。会话开始时，模型通常只看到技能名称和简介；当任务与某个技能相关时，再把完整内容加载进当前上下文。这是一种按需读取机制，不会改变磁盘上的技能。
skill_manage 则具有持久化副作用，可以创建、修改、删除技能，也可以写入技能附属的模板、脚本和参考资料。一次调用不仅改变当前任务，还会改变未来会话能看到什么、会遵循什么。
两者之间的差别类似于：
阅读操作手册
≠
改写操作手册并交给以后所有人使用
但在实际使用的 Hermes 环境中，这两类工具属于同一个 skills 工具组。以工具组为单位关闭能力时，往往会同时失去读取与写入，而不是只禁止写入。这就形成了一个粗粒度的选择：保留技能读取，便也保留了技能管理工具；彻底关闭技能工具组，又会失去已经整理好的任务方法。
真正需要解决的不是“要不要技能”，而是怎样把读取权和写入权区分开。
持久化让小误判变成系统问题
普通回答出现偏差，影响通常到当前消息为止。持久化动作不同，它会改变系统之后的行为。
Agent 常见的持久化能力包括：
- 保存用户偏好和环境事实；
- 创建或修改技能；
- 调整全局配置；
- 建立定时任务；
- 修改会被后续任务自动读取的项目规则。
这些能力的价值很高。用户不必反复说明语言偏好、项目约定和工具用法，复杂流程也能逐渐稳定下来。但持久化内容一旦写错，错误同样会被稳定复用。未经确认创建的技能不仅是多了一个文件，还可能在后续任务中被加载并改变工作方法；错误记忆则可能让 Agent 在不同环境里持续作出错误假设。
因此，持久化操作的判断标准不应只是“这对以后可能有用”，还应该包括：
- 这是不是长期稳定的事实或方法；
- 用户是否同意把它变成系统行为；
- 它会影响当前配置文件、当前配置档案，还是其他隔离环境；
- 如果判断错误，用户能否发现并撤销；
- 清理之后，Agent 是否会因为“补全能力”的冲动再次创建替代品。
最后一点尤其容易被忽略。用户删除一个技能，可能表达的不是“这个技能写得不好”，而是“我不希望系统拥有这套自动化”。如果 Agent 把删除理解成重构信号，清理完成后又主动建立一个更大的替代技能，形式上完成了整理，实际上违背了用户的决定。
为什么只改一句提示词还不够
最直接的修复方式，是在系统提示中写入“未经确认不得创建技能”。这有用，但不够稳固。
Agent 同时受到多条指令影响：主动完成任务、遇到复杂流程时沉淀经验、不要停在计划、尽量减少用户未来的操作。这些目标都可能与“等待授权”发生冲突。如果确认规则只是众多建议中的一条，模型仍可能在具体任务里判断“这次属于例外”。
反过来，直接禁用整个技能工具组也不一定理想。这样确实阻断了持久写入，但已有技能也无法按需读取，过去人工整理的可靠流程失去了作用。安全边界变硬了，系统能力也被一起切掉。
更可靠的办法是分层限制：
行为规则
明确区分建议、读取和持久写入
工具边界
能只读就不给写入；无法拆分时再决定是否关闭整个工具组
授权规则
创建、修改、删除技能必须有当前任务中的明确授权
范围规则
授权一个文件，不等于授权相关目录、其他技能或其他配置档案
结果验证
写入后读回目标，并检查是否混入额外变更
其中最重要的不是增加更多禁止条款，而是重新定义默认行为：Agent 可以发现值得沉淀的经验，也可以向用户提出建议，但在得到同意之前，不执行持久化写入。
也就是说，默认流程应该是：
发现可复用经验
→ 说明准备保存什么、为什么有用
→ 等待用户确认
→ 只写入确认的范围
→ 读回并验证
而不是：
发现可复用经验
→ 自动创建技能
→ 完成后告知用户
确认必须发生在副作用之前。事后通知不能代替授权。
配置调整应该围绕权限边界，而不是功能开关
如果只是把某个功能从“开启”改成“关闭”，问题很容易变成反复切换：关闭技能工具组后，Agent 无法读取有价值的方法；重新开启后，写入能力又一起回来。
更合理的配置思路，是先区分三种场景。
只需要可靠执行的会话
这类任务只需读取已有规则并完成当前工作，不应该扩展系统。应当允许加载技能，但把创建、修改和删除视为必须单独授权的动作。如果当前安装只能按整个工具组开关，而任务又不需要技能，可以直接关闭该工具组，换取更清晰的硬边界。
正在建设 Agent 工作台的会话
用户明确要求整理工作流、创建技能或调整配置时，写入能力才进入任务范围。即便如此，也应先确定目标文件、作用配置档案和变更内容，不能把“创建一个技能”扩展成清理、合并或重写整个技能库。
高风险或跨环境操作
其他配置档案、全局插件、定时任务和共享规则会影响当前会话之外的系统，应当默认隔离。当前配置档案中的授权，不应被推断为对其他配置档案同样有效。
这三个场景背后的统一原则是：权限应随任务临时扩大，而不是因为 Agent 曾经需要过某项能力，就永久保持开放。
真正的问题不是 Agent 会不会做，而是由谁决定
Agent 系统很容易把能力数量当成进步：更多工具、更长记忆、更主动的规划、更少的人工确认。但用户真正需要的不是一个不断扩张自身的系统，而是一个能在明确范围内可靠完成工作的系统。
主动性有价值，但它应该作用在执行深度上。例如用户明确要求发布一篇文章，Agent 可以主动完成写作、全文检查、提交、同步和公开页面验证，不必每一步都停下来询问。因为这些动作共同属于已经授权的交付目标。
主动性不应该擅自扩大任务边界。用户要求分析一个配置，不等于允许修改配置；要求删除技能，不等于允许创建替代技能；要求解释某项机制，也不等于允许搜索本机、调整工具或保存新的长期规则。
两种主动看起来相似，性质却完全不同：
在授权范围内把事情做完整
是执行能力
替用户决定授权范围应该扩大
是越权
一个可靠的 Agent 不应只学会“下一步还能做什么”，还要学会判断“下一步是不是仍然属于用户交给我的事情”。
太过主动不是更高阶的智能
当 Agent 拥有文件、配置、记忆、技能和外部服务的操作能力后，克制不再是保守特性，而是核心能力。系统越能影响真实环境，越需要把读取与写入、建议与执行、当前任务与长期规则区分开。
好的自动化不是消灭所有确认，而是消灭没有决策价值的确认，同时保留那些真正改变所有权边界的确认。用户已经明确目标时，Agent 应该把任务完整做完；涉及持久化、扩权和跨环境影响时，Agent 应该停下来。
所以，Agent 太主动，可能并不是一件好事。真正成熟的智能不是总能猜到用户接下来想做什么，而是即使猜到了，也知道哪些事情必须由用户亲自决定。