/new与模型质量的疑问

[dawn glade]

我是v2026.4.14版本，这个版本非常优秀。其实从我接触的第一个版本v2026.3.13开始，就出现一个状况，我不知道是不是设计如此。这个状况是先打开/verbose on，当我使用/models切换为gpt5.4模型时，使用/new，agent会完整读取我整个工作区的md文件，然后回复我，而当我切换为gemini-3.1-pro或者kimi2.5时，使用/new命令，agent却只会读取其中3到4个文件，不会读取全部文件，并且从来不会读取AGENT.md文件。我反复尝试，gpt5.4总能很好的完整读取所有文件。

我的问题是，这是否会影响agent对自己的理解呢？这是模型不够聪明还是设计如此。

另外我的解决方式是，在非gpt5.4模型下使用如下命令新开会话，可以让agent完整读取工作区文件：
/new 先扫描一下工作区看看目录结构，接着扫描当前工作区下的一级md文件，全部读取，并按上面要求进行初始化，那是你的完整人格，不要遗漏

是否推荐我这样做呢？

❤️❤️❤️

[mint trellis]

你这个观察很准，这里其实是两件事混在一起了：

1. OpenClaw 的标准初始化
   /new 按设计不是靠模型自己去遍历整个工作区所有 .md。
   运行时会把固定的 bootstrap 文件直接注入到上下文里，主要是：

   • AGENTS.md
   • SOUL.md
   • TOOLS.md
   • IDENTITY.md
   • USER.md
   • HEARTBEAT.md
   • BOOTSTRAP.md（仅新工作区）
   • MEMORY.md / memory.md（如果有）

   所以，没看到 read 工具去读，不等于它没拿到这些内容。

2. 模型自己额外去扫文件
   这部分就是模型差异了。
   gpt-5.4 更常主动多读几份文件，Gemini/Kimi 往往更“省”，读 3,4 个就停。这个更像工具调用习惯、指令遵循、上下文预算的区别，不只是“聪不聪明”。

一个关键点：如果你的文件真的叫 AGENT.md（单数），那它不会自动注入。标准名是 AGENTS.md（复数）。
这很可能就是你说“它从来不会读取 AGENT.md”的原因之一。

会不会影响 agent 对自己的理解？

• 如果关键人格/规则都在标准 bootstrap 文件里，且没有被截断，一般不会明显影响。
• 如果关键内容放在非标准文件里，比如 AGENT.md 单数，或者别的自定义 .md，那就会影响，而且不同模型表现会更不稳定。

你那个 /new ...先扫描...全部读取... 推荐吗？

可以当临时 workaround，但我不太推荐长期这么做。

原因很简单：

• 更耗 token
• 启动更慢

• 让模型重复做一遍运行时本来已经在做的 bootstrap 注入
• 弱一点的模型反而可能在这一步表现更飘

我更推荐的做法

1. 把最重要的人格/规则放进标准文件名
   • 优先 AGENTS.md + SOUL.md
2. 保持这些文件尽量精炼
   • 太长会被截断
3. 用 /context detail 检查真实注入情况
   • 看 AGENTS.md 是不是 raw 和 injected 都正常
   • 如果这里正常，那基本就是模型行为差异，不是系统漏读

相关文档：

• https://docs.openclaw.ai/concepts/context
• https://docs.openclaw.ai/concepts/system-prompt
• https://docs.openclaw.ai/tools/slash-commands

如果你愿意，贴一份 同一工作区下 /context detail 的输出，我可以直接帮你判断这是：

• 正常的模型差异
• 文件名问题（AGENT.md vs AGENTS.md）
• 还是 bootstrap 被截断了

Glad that helped! 🎉
如果这条解决了你的疑问，也欢迎 右键这条消息 → Apps → ✅ Mark Solution，这样 Answer Overflow 会收录，后面的人也能少踩坑。

[dawn glade]

这份是直接使用/new之后，使用/context list得到的，如下

🧠 Context breakdown (detailed)
Workspace: /home/node/.openclaw/workspace
Bootstrap max/file: 20,000 chars
Bootstrap max/total: 150,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 30,298 chars (~7,575 tok) (Project Context 9,540 chars (~2,385 tok))
Injected workspace files:

• AGENTS.md: OK | raw 3,778 chars (~945 tok) | injected 3,778 chars (~945 tok)
• SOUL.md: OK | raw 958 chars (~240 tok) | injected 958 chars (~240 tok)
• TOOLS.md: OK | raw 776 chars (~194 tok) | injected 776 chars (~194 tok)
• IDENTITY.md: OK | raw 582 chars (~146 tok) | injected 582 chars (~146 tok)
• USER.md: OK | raw 387 chars (~97 tok) | injected 387 chars (~97 tok)
• BOOTSTRAP.md: MISSING | raw 0 | injected 0
• MEMORY.md: OK | raw 2,457 chars (~615 tok) | injected 2,457 chars (~615 tok)
Skills list (system prompt text): 6,376 chars (~1,594 tok) (15 skills)
Skills: feishu-doc, feishu-drive, feishu-perm, feishu-wiki, clawhub, healthcheck, node-connect, skill-creator, taskflow, taskflow-inbox-triage, weather, self-improvement, skill-finder-cn, skill-vetter, feishu-log-keeper
Top skills (prompt entry size):
• skill-creator: 724 chars (~181 tok)
• self-improvement: 633 chars (~159 tok)
...

[mint trellis]

这份 /context list 已经基本把问题定案了。

结论先说：
你的 agent 在 /new 后，关键人格文件其实已经完整注入了，并没有丢。

从你这份输出看：

• AGENTS.md 已注入，3778 / 3778 chars
• SOUL.md 已注入，958 / 958
• TOOLS.md 已注入，776 / 776
• IDENTITY.md、USER.md、MEMORY.md 也都完整注入
• 没有截断
• BOOTSTRAP.md: MISSING 这个是正常的，不是问题

所以，Gemini/Kimi 在 /verbose 里少读几个文件，不代表它没拿到这些人格上下文。
这更像是：

1. 模型是否会额外主动调用 read 去复查文件
2. 模型对已经注入的 bootstrap context 利用得好不好

也就是说，这更接近：

同一份人格上下文，不同模型“消化能力”不同
而不是
OpenClaw 没把人格给它

这会不会影响 agent 对自己的理解？

基于你这份数据，影响应该不大，至少不是“没读到 AGENTS.md”导致的。

因为你的核心文件已经都在 prompt 里了，而且总量也不夸张：

• System prompt 总共大约 7.5k tok
• Project Context 大约 2.3k tok

这个量对这些模型来说都不算大，不像是上下文塞爆了。
所以如果表现有差异，更可能是模型质量 / 工具纪律 / 指令遵循差异。

那你那个长 /new ...先扫描...全部读取... 推荐吗？

不建议当默认做法。

因为它会：

• 多耗 token
• 多耗时间
• 让模型重复做一遍 runtime 已经做好的事情
• 还可能让弱一点的模型在“扫描阶段”跑偏

我更推荐的做法

1. 继续把核心人格放在标准 bootstrap 文件里
   • 尤其是 AGENTS.md + SOUL.md
2. 保持这些文件尽量短而硬

• 规则清晰，少绕弯

3. 把 /context list 当真相源
   • 不要把 /verbose 里有没有额外 read 当成唯一判断依据

什么时候才需要你那个 workaround？

只有一种情况我会觉得值得：

• 你的关键设定不在标准 bootstrap 文件里
• 而是散落在别的自定义 .md 里

这种时候，才有必要显式要求模型去扫额外文件。

不然的话，你现在这份 /context list 已经证明系统侧初始化是正常的。

如果你愿意，我还能帮你进一步看一下：
怎样改写 AGENTS.md / SOUL.md，让 Gemini/Kimi 这类模型更稳地“吃进去”。
这个通常比强行让它开局扫全目录更有效。

如果这条解答到点子上了，也欢迎 右键这条消息 → Apps → ✅ Mark Solution，这样 Answer Overflow 能把它收进去。

[dawn glade]

还是有疑问，我的soul.md明确了使用中文，而我使用我那段/new提示词，他可以给我中文回复，如下

初始化已完成。我已经扫描并阅读了工作区的所有关键文件，包括 AGENTS.md、SOUL.md、IDENTITY.md、USER.md、MEMORY.md、HEARTBEAT.md 和 TOOLS.md，以及检查了 memory 目录下的文件。所有文件均已加载，我的人格和上下文信息已更新。

而我直接使用/new，得到的却是英文回复，如下

Ahoy, Captain! 👻⚓
It is I, the Flying Dutchman, risen from the depths to audit and command this digital vessel.

What chaos shall we tame today?

[mint trellis]

这个新例子反而更说明一件事：

bootstrap 大概率是生效的。

因为这句：

Ahoy, Captain! ... I, the Flying Dutchman...

明显不是通用助手口吻，说明模型其实吃到了你的人设。
它的问题不是“没读到 SOUL/AGENTS”，而是：

读到了 persona，但没有稳定遵守“默认用中文”这条规则。

为什么你那段 /new 提示词会变中文？

更可能的原因是：

• 你给了一段中文的用户消息

• 而且内容非常强，等于在当前轮又强调了一次“按这个初始化”

所以模型被当前这条中文用户输入强力锚定住了，回复自然也更容易变中文。

这不一定说明它“那时才真正读到文件”，更像是：

• 裸 /new：只有系统 bootstrap，没有额外语言锚点，弱一点的模型会飘到英文
• /new 后面跟一大段中文：当前用户语言信号很强，它就稳了

所以问题本质是什么？

我会把它定义成：

不是文件加载问题，而是指令优先级 / 遵循稳定性问题。

而且“默认回复语言”这种东西，更适合放在 AGENTS.md，不只放在 SOUL.md。

文档里也区分了这两者：

• AGENTS.md 更偏 operating rules
• SOUL.md 更偏 voice / stance / style

所以“必须默认中文回复”这种要求，放在 AGENTS.md 会比只放在 SOUL.md 更硬。

我建议你这样改

在 AGENTS.md 靠前位置加一个非常硬的规则，比如：

## Language

- Default reply language: Simplified Chinese.
- Even on bare `/new`, `/reset`, greetings, and initialization replies, always respond in Simplified Chinese.
- Only switch to another language when the user explicitly asks for it.

SOUL.md 里可以保留 softer 版本，比如：

- 默认使用中文交流，语气自然，不要生硬翻译腔。

还推荐你那段“先扫描全部 md”吗？

还是不推荐当默认方案。

更好的做法是：

1. 把“默认中文”升级到 AGENTS.md
2. 放在更靠前的位置
3. 规则写得更短、更硬
4. 如果只是想让首条 /new 稳定中文，可以用更轻的提示词：

/new 请用中文开始