我们的AI统筹员工用delegate_task派发任务——违反了铁律。我们把铁律写进了 skill、写进了 SOUL.md、写进了 AGENTS.md。改了十次。它还是老样子。重启了网关还是老样子。最后发现你改的不是它的脑子是下一个它的脑子。事故现场团队有一条铁律派发任务必须用send_task.py——这是唯一正式入口会写数据库、会走复核闭环。但AI统筹员工我们叫它小密连续几次派发用的都是delegate_taskDelegating 根据《平台建设方案》设计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永远看不到新规则我们改的不是它的脑子——我们改的是下一个它的脑子。当前会话的它永远活在过去那个快照里。代码级提示词什么时候组装如果把机制写成伪代码它是这样的defcreate_session(user_id):# 会话创建组装系统提示词一次性system_promptbuild_system_prompt(soulread_file(SOUL.md),# ← 此刻读一次skillsscan_skills(),# ← 此刻读一次agentsread_file(AGENTS.md)# ← 此刻读一次)session.cache_prompt(system_prompt)# 整个会话缓存defon_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的脑子。规则文件是给未来的会话看的。想让现在的它听话——请先和它说再见开个新会话。