问题现象与适用场景
有些用户在 Windows 端使用 OpenClaw 时，会遇到一种很典型的代理行为异常：明明已经在 agent.md 里写了“禁止使用 read 工具”，实际运行时它还是会去调用 read 工具读取图片，随后给出看起来像“猜测出来”的结果；同时，原本希望它优先使用 skills 的场景，它也没有主动调用。
这类问题通常不只是“提示词没写好”，更常见的是：agent.md 的约束没有进入真正生效的系统层，或者工具暴露、优先级、运行时配置之间存在冲突。对于这类情况，单纯改一两句提示词往往不够，需要按配置链路逐层排查。
常见原因
- 提示词层级不一致：
agent.md只是某一层输入，可能被系统提示词、默认策略或运行时模板覆盖。 - 工具权限没有真正收紧：界面里看似禁用了某个工具，但底层仍然注册了该工具，模型仍可调用。
- skills 没有被正确加载：技能目录、命名、索引或触发条件不符合当前运行方式，导致模型“看不见”可用技能。
- 任务描述不够明确：如果没有明确要求“先判断是否需要工具，再决定是否调用”，模型可能倾向于直接走默认工具链。
- 图片/文件处理链路有默认行为：某些代理会对图片、附件自动走读取流程，即使你在上层提示词里写了限制，也未必能阻止底层自动处理。
分步解决方案
1. 先确认 agent.md 是否真的被加载
不要先假设“规则没生效”，先确认文件是否被当前会话读取。可以检查：
agent.md的路径是否是当前实例实际使用的路径；- 文件名是否大小写、后缀、编码都正确；
- 是否存在多个同名配置文件，导致加载了别的版本；
- 启动后是否有日志提示已读取该文件。
如果没有日志或界面提示，建议先把 agent.md 改成非常容易识别的内容，例如加入一条明显标记，再观察模型是否会在回复中体现该内容。若完全没有体现，说明问题可能在“文件未加载”而不是“模型不听话”。
2. 检查工具是否只是“写了禁止”，但没有“禁用”
很多代理系统里，“提示词禁止使用某工具”和“运行时禁用该工具”是两回事。前者只是约束模型倾向，后者才是真正的权限控制。
如果你的目标是绝对不要调用 read 工具，应优先在工具注册、权限配置或启动参数里关闭它，而不是只靠 agent.md。如果当前版本没有提供显式禁用入口，至少要确认：
- 工具列表中是否仍能看到
read； - 是否存在“默认启用全部工具”的配置；
- 是否有按任务类型自动开放工具的策略。
如果工具仍然可见，模型就可能继续调用它，尤其是在处理图片、附件或需要读取上下文时。
3. 把“禁止”改成更可执行的决策规则
与其只写“不要用 read 工具”，不如把规则写成更明确的流程约束，例如：
仅在以下条件满足时才允许调用工具：1）任务明确需要读取外部内容；2）没有其他更安全的替代方式；3）调用前先说明原因。若不满足条件，直接基于已有文本回答，并明确说明无法确认图片内容。这种写法的重点不是“更强硬”，而是把模型的决策顺序说清楚。很多时候，模型不是故意违背，而是没有足够明确的“何时可以调用、何时必须停止”的边界。
4. 给 skills 明确入口，而不是只写“请主动使用”
“主动使用 skills”这类要求如果过于抽象，模型可能不知道该从哪里开始。建议在提示词或任务模板中补充：
- skills 的名称、用途和触发条件；
- 优先级顺序，例如“先检查是否存在可用技能，再考虑通用回答”；
- 失败回退策略，例如“找不到匹配技能时，先说明原因，再给出保守建议”。
如果 skills 需要特定目录、索引文件或命名规范，也要确认这些资源是否真的存在并可被当前会话访问。很多“不会主动用 skills”的问题，本质上是技能没有被正确暴露，而不是模型不愿意用。
5. 对图片读取做单独约束
你提到它会“读取图片然后瞎编”，这说明图片处理可能走了独立链路。建议把图片相关规则单独写清楚：
- 如果没有明确授权，不要解析图片内容；
- 如果必须处理图片，先说明将使用什么方式处理；
- 如果无法确认图片细节，直接说明“无法从当前上下文确认”。
这样做的目的，是避免模型在“看见图片”后自动进入推断模式。对于不确定内容，宁可保守回答，也不要让它把猜测包装成事实。
6. 用最小化场景验证配置是否生效
排查时不要一上来就拿复杂任务测试。建议准备一个最小化验证样例：
- 只保留一条明确规则，例如“禁止调用 read 工具”。
- 只发一个简单任务，例如“描述当前是否会调用工具”。
- 观察日志或输出中是否出现工具调用痕迹。
- 再逐步加入 skills、图片、附件等复杂因素。
如果最小化场景都无法阻止 read 调用，说明问题大概率不在任务本身，而在工具权限、默认策略或配置加载链路。
如何验证是否修复成功
判断是否真的修复，不要只看“这次回复对不对”，而要看工具链是否按预期工作。可以从以下几个点验证：
- 日志层面：不再出现
read工具调用记录，或只在明确授权时调用。 - 行为层面：遇到图片或附件时，模型会先说明限制，而不是直接给出猜测结论。
- 技能层面：在适用任务中，
skills能被优先识别并调用，或至少能明确说明为什么没有调用。 - 一致性：多次重复同类任务，行为保持一致，而不是一次遵守、一次失控。
如果你能在日志里看到“未调用工具，直接基于文本回答”或“因权限限制跳过 read”，通常说明约束开始生效了。
解决不了时的补充建议
如果按上述步骤排查后仍然无效，建议继续从以下方向缩小范围：
- 检查是否存在多层提示词叠加：系统提示词、项目提示词、会话提示词可能互相覆盖。
- 确认是否有默认代理策略：有些运行模式会自动启用图片读取、文件解析或工具补全。
- 尝试关闭非必要工具：先保留最少工具集，再逐步恢复，找出是哪一个工具触发了异常链路。
- 查看官方最新文档：不同版本对工具权限、skills 加载方式和提示词优先级的实现可能不同，请以官方最新说明为准。
如果你需要的是“绝对不读图、绝对不猜测”，那就不要只依赖自然语言约束，最好把权限控制、任务模板和验证日志一起纳入配置。对代理类产品来说，真正可靠的限制通常来自运行时权限，而不是单独一段提示词。
排查这类问题的核心思路是：先确认配置是否加载，再确认工具是否真的被禁用，最后再看技能是否被正确暴露。只改
agent.md往往只能影响倾向，不能替代权限控制。
总结
Windows 端 OpenClaw 出现“agent.md 写了禁止 read 工具却仍然调用、还不会主动用 skills”的情况，通常不是单点故障，而是提示词层级、工具权限、技能加载和默认策略共同作用的结果。处理时应优先确认配置是否生效，再检查工具是否真正禁用，最后通过最小化场景验证修复效果。若当前版本的行为与文档不一致，建议以官方最新文档和日志输出为准，避免只靠提示词硬扛。
转载请注明：AI工具问题解答站 » Windows 端 OpenClaw 不按 agent.md 执行、仍然调用 read 工具怎么办