我们的AI统筹员工，用
delegate_task派发任务------违反了铁律。我们把铁律写进了 skill、写进了 SOUL.md、写进了 AGENTS.md。
改了十次。它还是老样子。
重启了网关，还是老样子。
最后发现：你改的不是它的脑子，是下一个它的脑子。
事故现场
团队有一条铁律：派发任务必须用 send_task.py------这是唯一正式入口，会写数据库、会走复核闭环。
但AI统筹员工（我们叫它小密）连续几次派发，用的都是 delegate_task：
Delegating 根据《平台建设方案》，设计6个主要页面的可交互原型...
✅ 任务已派发 DEV-20260811-001 → 小虾（开发岗位）任务派发了，数据库里却没有这条任务。没有任务ID、没有复核、没有闭环------它绕过了整个机制。
我们改规则：在 skill 里写死"禁止 delegate_task 派发正式任务"。
它不听。
我们再改：在 SOUL.md（系统提示词）里写"send_task.py是唯一正式派发入口"。
它还是不听。
我们改 AGENTS.md、改环境说明、改 memory------前后改了十次。它每次都是老样子。
排查：规则文件全都对
我们把规则文件逐个打开检查：
SOUL.md: "禁止用delegate_task派发正式任务" ✅ 在
skill: "send_task.py是唯一正式派发入口" ✅ 在
AGENTS.md: "创建任务MD → send_task.py派发" ✅ 在文件都对。路径都对。甚至重启了网关进程。
它还是用 delegate_task。
那一刻的困惑是真实的：规则就在文件里，它为什么看不见？
根因：系统提示词是会话创建时的快照
翻文档才发现机制：
Hermes 的系统提示词，在会话创建的那一刻组装并缓存。
整个会话期间，提示词不再重新读取文件。
也就是说：
会话创建时:
SOUL.md（旧版------没有铁律） → 组装进系统提示词 → 缓存
之后你改SOUL.md（加了铁律）:
文件变了------但【当前会话的提示词】还是旧快照
→ agent永远看不到新规则我们改的不是它的脑子------我们改的是下一个它的脑子。
当前会话的它，永远活在过去那个快照里。
代码级：提示词什么时候组装
如果把机制写成伪代码，它是这样的：
python
def create_session(user_id):
# 会话创建：组装系统提示词（一次性）
system_prompt = build_system_prompt(
soul=read_file('SOUL.md'), # ← 此刻读一次
skills=scan_skills(), # ← 此刻读一次
agents=read_file('AGENTS.md') # ← 此刻读一次
)
session.cache_prompt(system_prompt) # 整个会话缓存
def on_message(session, msg):
# 之后的每一条消息：用缓存的提示词------不再读文件
model.call(session.cached_prompt, msg)关键在 create_session 那一步：文件只读一次。之后你改多少次文件，当前会话都无感知。
重启网关也一样------gateway restart 不会销毁已存在的会话，提示词快照还在。
验证：重启不重建，新会话才生效
我们做了对照组：
❌ 改SOUL.md + 重启网关 → 旧会话继续用旧快照 → 还是delegate_task
✅ 改SOUL.md + 新开会话（清sessions） → 新会话加载新快照 → 立刻用send_task.py同一个文件，同一个时刻------只有新会话能看到。
这也解释了为什么"身份改名不生效"、"skill更新不生效"、"铁律不生效"------全是同一个机制。
解决方案：改完规则，必须"重启 + 新会话"
现在我们的操作规范变成了：
① 改规则文件（skill/SOUL/AGENTS）
② 重启网关（让新会话有干净环境）
③ 【新开会话】（新DM/清sessions）------这是最容易漏的一步
= 三步缺一不可------第二步不能替代第三步以及一个认知修正：这不是 bug，是特性。会话缓存保证上下文连贯------用户上一句说的事，下一句 agent 还记得。代价是规则修改对存量会话不生效。我们要做的不是"修掉缓存"，而是"改完规则记得开新会话"。
你改的不是AI的脑子，是下一个AI的脑子。
规则文件是给"未来的会话"看的。想让"现在的它"听话------请先和它说再见，开个新会话。