大模型失忆问题探讨

在 Agent 环境中，触发某个 Skill 后导致大模型"遗忘"用户原始输入的要求，是一个非常典型的上下文工程（Context Engineering）与记忆管理问题。

这通常是因为：Skill 的详细操作指南被动态注入到上下文中，或者 Skill 内部的工具调用链过长，导致产生大量 Token，将系统提示（System Prompt）和用户初始要求（User Input）"挤"到了上下文窗口的边缘，从而产生了工作记忆污染 和注意力稀释。

结合众多主流 Agent 框架的工程实践，可以通过以下几个维度的方案来彻底解决这一问题：

当 Agent 决定触发一个 Skill 或将任务交给子 Agent 执行时，千万不要假设它会自动继承之前的上下文记忆。

做法：在调用 Skill 的入口参数或系统指令中，强制携带用户的核心要求。
示例：不要只传递 Task: 执行数据清洗，而是传递 Task: 执行数据清洗。Constraints: 记住用户最初的要求是'保留所有负数，并且最后输出中文'，请在执行完清洗后核对该目标。通过这种方式，强制把用户的核心诉求作为独立变量传入 Skill 内部。

不要盲目相信大模型的短时上下文记忆（Context Window），一旦执行流变长，信息必然丢失。AI Agent 应该被视为"无状态函数"，它的状态应该保存在外部。

设立 USER.md / SOUL.md ：将用户的初始要求、全局约束单独写入一个外部的文本文件（如 USER.md）。在 Skill 执行的 SOP（标准作业程序）中，明确规定**"第一步：读取 USER.md 确认用户目标"**。
临终备忘录机制 (Death Note / Checkpoint) ：在触发一个极其复杂、耗时的 Skill 之前，让 Agent 触发一次"保存进度"。主动写下一份备忘录，记录：1. 用户的原始目标是什么；2. 接下来要做什么 Skill；3. 期望的结果。当 Skill 执行完毕或中途中断重启时，优先读取该备忘录，实现无缝衔接。

如果把 Skill 的所有步骤、范例代码、中间冗长的报错日志全堆在上下文里，模型必定会"断片"。需要像管理计算机内存一样管理上下文：

渐进式加载 (Progressive Disclosure)：只在必要时加载 Skill。不要一开始把所有的详细 Skill 文档塞进系统提示中，只保留轻量的"元数据（名称和简介）"，等确实命中某个 Skill 时，再动态注入该 Skill 的对应章节。
及时折叠或清理历史 (Memory Consolidation) ：在 Skill 执行的循环中，定期触发一个总结动作。把之前的 10 轮废话或工具调用日志，利用 LLM（甚至可以用更小、更便宜的模型）压缩成一句话摘要（例如："已完成前三轮参数调优，基础模型已跑通"），从而为用户最初的要求腾出注意力空间。

有时候"遗忘"是因为 Skill 本身只负责执行具体动作，却没有"回头看"的机制。你在编写 SKILL.md 时，需要加入校验逻辑：

在 Skill 的最后一步增加校验要求 ：在 Skill 的文件末尾强制加上一条指令，例如：第四步：在输出最终结果前，回顾用户的初始 Prompt。验证当前的结果是否完全满足了用户的特定要求（如格式、语言、偏好等），如果有遗漏，请重新补全。
通过脚本约束（Scripts）锁死输出：如果用户要求的是固定的格式或流程，不要让大模型去自由发挥。利用 Agent Skills 的机制，把确定性的步骤（如结果排版、数据过滤）交给 Python/Shell 脚本去处理，AI 只负责提供参数，从而规避 AI 因上下文过长而产生的"幻觉性遗忘"。

总结：解决"触发 Skill 后失忆"的核心法则就是**"好记性不如烂笔头"**------不要让模型在脑海（上下文）里强行记住用户的要求，而是要把要求写在虚拟的"便签纸"上（单独的文件、备忘录、显式参数），并要求它在执行 Skill 的过程中随时低头看一眼。