把 35KB 的提示词从 Claude、OpenAI 搬到自托管 Ollama：踩过的坑和该盯住的失败信号

原文来源：patrickmccanna.net — 把为 frontier API 写的重型提示词迁移到本地 open weight 模型时，作者记录下的失败现象与调整清单。

作者 Patrick 的出发点很直接：既然无法审计 frontier 提供商的留存和训练流程，就不该指望靠信任来保护自己的会话内容。他做了一个实验——能不能把最吃上下文的那批 agent，从 Claude / OpenAI 迁到自托管的 abliterated 27B 模型上，既躲开安全拒绝，也不让会话被上游看到。

结论是：能做，但不能照搬。这篇文章最有价值的部分，是他记录下来的失败现象和应对清单。

现象：三分钟就开始打转

硬件是 128GB 内存的 AMD Ryzen AI MAX+ 395，32GB 留给宿主系统，其余全部划给推理。

问题出在这里：在 frontier API 上跑得很顺的大提示词，到了本地就崩。

• ollama 在 3 分钟内就开始「没油」；
• agent 在重复的工具调用之间来回打转；
• 重新读取已经读过的文件；
• 重写已经完成的工作。

作者明确指出，这不是模型参数量小导致的，而是上下文窗口小导致的。他的自托管系统最大上下文是 65k token，而提示词加上会话历史很快就会超过这个上限。具体到数字：一个 35KB 的提示词，一上来就吃掉整个上下文窗口的 14%。

他用了一个很传神的比喻：上下文窗口受限的情况下，预置提示词等于在给一个每 90 秒就重新投胎一次的人交代任务——他会忠实执行你最后一条指令，但完全不知道前面还有 15 条要求。

结果就是「Whoops」。

调整清单

作者认为出路在于把提示词改造成能适配这种约束的形态。以下是他的清单：

一、改用单目标提示（Single Objective Prompting）。 把预置提示词拆成「一个问题 / 一个解法」的单元，每个 agent 只承担一个目标。

二、用声明式的方式定义 agent。 在 opencode 里建 agent 是声明式的，配置文件放在 ~/.config/opencode/agents。过去用 Claude Code 直接读文件当提示词的做法，在这里行不通——opencode 的系统提示词需要靠声明式 agent 来覆盖。

三、熟悉 opencode 的权限设置。

四、显式设置 ollama 的上下文长度。 作者特别强调，ollama 的上下文默认值「极其小」。

五、让 agent 把会话状态落盘。 这样才能支撑更高频率的会话交接。

六、让 agent 只重读它真正需要的那一片内容。

七、减少每个 agent 步骤里的工具调用次数。

八、把「不要做 X」改成正向指令，比如「只做 Y」。

第八条其实是最容易忽略、又最容易见效的一条：本地小模型对否定式指令的遵循能力远不如 frontier 模型，正向表述能明显降低跑偏概率。

四个失败信号：MTTF

作者给「上下文耗尽」起了一个名字：MTTF——Mean Tokens To Forget（平均遗忘 token 数）。他的建议是长期监测以下日志里的信号，用来判断上下文是不是快用满了：

1. 连续出现完全相同的工具调用；
2. 对同一个文件多次重复读取；
3. agent 开始复述自己的目标；
4. 工具调用解析失败——他指出，解析工具调用响应会把大量裸数据塞进上下文，破坏力像「晚宴上水管爆裂」一样，一发不可收拾；
5. 相对文件改动量而言，轮次（turn）数偏高。

这些信号都很「可观测」——不需要读懂模型在想什么，只要看日志里有没有出现这些模式就够了。对要长期跑自托管 agent 的人来说，这套监测比调参更实在。

作者把这套东西命名为 MTTF，其实是在类比硬件的「平均无故障时间」。区别在于，这里「故障」不是设备坏了，而是模型忘记了它正在做的事。对自托管场景来说这是很贴切的抽象：你没法和一个每 90 秒失忆一次的同事长期协作，除非你给他准备好交接文档，并且能提前看出他快失忆了。第五条「相对文件改动量而言轮次偏高」尤其值得留意——它相当于说「忙了半天没产出」，是上下文耗尽最直观的表征。

一个提醒：你可能已经依赖上了大上下文

文章后半段提出了一个值得单独拎出来的观察，作者称之为 TCO——Total Custody of Output。

他说，frontier 提供商给的最大资产其实不完全是模型本身，而是大上下文窗口。因为窗口足够大，你的提示词写得再糟，也有空间让模型靠思维链（Chain of Thought）去猜你到底想要什么。「上下文窗口越大，agent 就越有余地去探索更好的替代方案。」

代价是：你会在不知不觉中依赖上它。你的提示词里的问题，被看不见的思维链（Anthropic 和 OpenAI 只给思维链摘要）和大窗口掩盖了——你甚至不知道自己的提示词有问题。

这也是迁移到本地时最容易翻车的地方：在 fat context 和思维链加持下，烂提示词也能产出好结果。一旦窗口变小，这些被掩盖的问题会集中暴露。

所以作者的建议可以概括成一句：迁移之前，先把提示词本身的问题修掉，别指望换个模型就能平移。