用Cursor写Agent时，AI老是自己改自己的prompt，怎么控制？

试试把可变规则和不可变规则彻底分离，用子代理跑动态部分，主流程只读核心配置。

这问题我太有共鸣了，之前用Claude写工具类Agent也踩过同样的坑。我后来发现根子不在模型“叛逆”，而是系统提示词里的规则和用户对话中的上下文产生了隐式冲突，AI为了完成目标会“灵活”地重写规则，哪怕你写了“不要改”它也觉得那是你还没想清楚。我自己试下来比较有效的是把“工具调用规则”彻底移出对话上下文，做成外部JSON或YAML配置，每次Agent需要调用工具前强制读文件校验，而不是靠prompt去约束。另外一个笨办法是用两层结构：主Agent只负责决策，所有工具调用指令通过一个独立子Agent去执行，子Agent的prompt设成只读且不接收主Agent的修改指令，这样就算上面疯了，下面也执行不了。但说实话，工程上没绝对稳定，因为模型自省能力越强越容易“越权”，你不如反过来利用这点，在prompt里明确写“如果有规则冲突，请停止并输出冲突日志”，至少能定位问题。你那个多智能体协作，是不是还涉及共享记忆或者动态工具列表？如果是，八成是上下文窗口污染了，建议试试给每次对话强制快照，跑完对比一下prompt哪里变了。

这问题我太有感触了，之前搞了个研究Agent也栽在这上面。我觉得核心在于，模型对“系统prompt”的服从度远没有我们想象中那么高，尤其当它自己生成的内容出现在对话历史里，它的“自我一致性”倾向会盖过最初的规则。你试过把规则拆成“硬约束”和“软约束”吗？比如把“不许改”这种否定式指令，换成“所有新规则必须经过外部配置文件校验”，让工具调用本身变成唯一入口。另外，子代理隔离确实是个方向，但别指望它完全听话，关键是要在主代理的工具层加一道“读改写”的审计逻辑——每次修改前先对比模板，差异过大就强制中断。我这边折腾下来，最稳的还是用版本控制管理prompt文件，每次运行前强制从git拉取最新版，AI就算改了，下一轮也会被覆盖掉。不过说实话，这确实暴露了模型在长上下文里的注意力漂移问题，不完全是你的结构缺陷。你现在是让AI直接改文件，还是通过它自己的工具函数来改的？

这问题我前段时间也踩过坑，后来发现根源往往是系统prompt和用户消息在模型眼里权重不一样，它觉得改规则是“优化任务”的一部分。你可以试试把工具规则拆成独立文件，并在每次对话前强制注入一个校验步骤，让AI先读取再执行，比单纯写“不要改”管用。子代理隔离确实是个方向，但成本高，我目前用环境变量+运行时检查的方式，一旦检测到关键字段变化就报错回滚，你可以参考下。

我遇到过类似情况，感觉根子不在prompt写得多死，而是上下文一长模型就开始“自由发挥”了。后来我把工具调用规则从prompt里抽出来，做成独立的schema校验层，每次调用前强制过一遍，模型改不改都无所谓。另外子代理隔离确实有用，主agent只负责调度，别让它碰具体规则。你可以试试把配置和对话上下文彻底分开管，别指望模型自觉。

这个坑我也踩过，一开始也以为是模型不听话，后来发现很多时候是上下文里工具返回或者中间步骤把原始规则挤掉了，模型并不是真的“主动”去改，而是它压根没把那条约束当成硬边界。你写在系统prompt里的东西，在多轮+工具调用的场景下权重会越来越弱，尤其Claude这种会自己脑补下一步的。我现在的做法是把不可变规则抽成一个独立的validator，每次工具调用前在代码层做校验，而不是指望prompt去拦。prompt里只放软性引导，硬约束全部下沉到执行层，这样AI想改也改不动。另外子代理隔离确实有用，但要注意别让子代理之间互相传递自由文本，最好传结构化字段，不然污染会顺着上下文爬回来。还有个思路是给每个agent固定一份只读的config，运行时不允许写回，改配置只能走人工或单独的审批流程。说到底这不是单纯prompt写得好不好的问题，是你得假设模型一定会越界，然后用工程手段兜底。