关于 context-canary
Context Canary 是一项 Agent 技能，通过重复执行简单指令，让长会话中的上下文丢失显现。它跟踪名称、轮次计数和自评状态，并为确认故障提供检查点与重新锚定流程。
主要功能
- 01每次回复首行显示金丝雀
- 02逐条回复递增轮次
- 03自评上下文状态
- 04检测并校准触发情况
- 05检查点与重新锚定流程
- 06会话与持久指令两种模式
适用场景
- 01监测长会话中的上下文
- 02检查压缩后的连续性
- 03处理金丝雀指令缺失
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/context-canary确认已加载。
附带文件references/research.md
详细介绍
上下文金丝雀
上下文金丝雀是一条很容易核验的持续指令，唯一作用就是在失效时明显暴露出来。经典形式是：“每条回复都以我的名字开头。”遵守这条指令几乎不费力，因此，当名字消失时，这种缺失本身就是一种信号。指令并没有变得更难遵守；只是 Agent 对早期上下文指令的把握变弱了。就像煤矿里的金丝雀，它会先于你真正关心的问题（忘记约束、无视惯例、重新讨论已敲定的决定）在代码中出现而倒下。
这种方法之所以有效，是因为上下文退化是无声且渐进的。模型不会告知你它们已经不再关注 8 万个 token 之前的指令，而压缩摘要也会悄悄丢弃持续指令。金丝雀将不可见的失效转化为一种每轮都能进行、结果明确且无需费力的检查。关于这种现象为何发生的研究——上下文腐化、中间内容遗失、指令漂移、压缩损失——见 references/research.md。
何时使用此技能
- 在较长或事关重大的会话开始时设置金丝雀。
- 用户发现金丝雀不再出现，并询问发生了什么。
- Agent 自己意识到已无法在上下文中找到金丝雀约定。
- 用户询问当前上下文还剩多少可信度。
金丝雀约定
调用后，用一条简短消息明确说明约定，以此启用金丝雀，然后遵守约定。默认格式——从此以后，每条回复的第一行：
**Julius · t14 · ctx ok**
三个字段分别用于探测不同情况：
| 字段 | 示例 | 失效意味着什么 |
|---|---|---|
| 名字 | Julius | 持续指令本身已脱离有效上下文——可能是遵循度漂移，也可能是被压缩过程丢弃。 |
| 轮次计数器 | t14 | 每条回复递增 1。重置、跳过或重复都意味着连续性中断——几乎总是压缩或摘要边界所致。 |
| 自检 | ctx ok / ctx aging / ctx thin | Agent 的诚实估计。aging：会话很长，早期细节正在 Agent 对任务的工作认知中被概括。thin：Agent 正在重建早先的决定，而不是回忆它们。 |
使用用户的真实姓名（如果不知道就询问）。如果用户希望采用最简形式，只用名字即可——这就是最初的做法，仍能捕捉重大失效。绝不要解释、道歉或修饰金丝雀行；它必须保持字节级稳定，方便人类在半秒内识别模式。
会话金丝雀与持续金丝雀。 只存在于对话中的金丝雀用于测试对话上下文是否得以保留（压缩、截断、漂移）。写入 CLAUDE.md 或 Agent 记忆中的金丝雀按设计可以在压缩后保留——这意味着它测试的是 Agent 是否关注基于文件的指令，这是另一种更弱的信号。默认使用会话金丝雀；只有它能检测退化。只有当用户希望在所有会话中都保持这一习惯时，才提供持续金丝雀，并告知用户这种做法不再能衡量什么。
输出规则
- 金丝雀必须是每条回复的第一行，包括简短回复、错误报告以及工具调用后的回复。
- 每条回复都要递增计数器。如果不确定计数，就说明这种不确定性本身就是信号——输出
t?并标明这一点，绝不要猜一个看似合理的数字。 - 自检必须诚实。习惯性地报告
ctx ok会让整个监测工具失去意义。 - 如果在任何时候都无法从上下文中找到金丝雀约定（你只从摘要中知道它，或者根本不知道它），就主动声明触发失效——不要等用户发现。
Trip 协议
Trip 指：canary 缺失、格式错误、计数器不连续，或 Agent 端自行声明。
先校准，再报警——如果整体响应连贯，只漏掉一次 canary，那只是警告（记下来，恢复 canary，然后继续）。连续漏掉两次、计数器不连续，或 Agent 未通过自身的契约检查，都表示已确认 trip。 此时：
- 停止信任发生漂移的状态。 不要再基于你已无法确认的上下文，贸然继续当前任务。
- 建立检查点。 将持久状态写在对话之外：当前目标、已做出的决定及其原因、修改过的文件、已验证与进行中的事项，以及下一步。在仓库中创建
HANDOFF.md或笔记文件即可。 - 重新锚定。 重读项目指示（
CLAUDE.md、原始任务说明）和检查点。用三四行向用户复述你认为的任务和约束——让他们能以低成本纠正任何偏差。 - 有意重置。 建议用户开启新会话（或执行显式 compact），并以检查点文件作为上下文，而不是勉强继续。受损的上下文不会自行恢复，只会持续恶化。
- 重新安装 canary，并将计数器重置为
t1，注明代次：t1 (gen 2)。
间隔后绝不要不作说明地恢复 canary，仿佛什么都没发生——这会毁掉这个工具仅有的可信度。
canary 能告诉你什么，不能告诉你什么
这项测试是单向的。canary 缺失，是上下文已退化的有力证据；canary 存在，只能提供较弱的健康证据——一种简单的风格习惯或许能保留下来，但更难遵守的约束（架构决策、“绝不触碰 X”）可能已悄然失效；而塞进记忆文件的 canary，也可能在它原本要监测的上下文消失后继续存在。把 canary 当作烟雾探测器，而非结构检查：触发时就采取行动；未触发时，在上下文窗口使用率超过约 50% 或发生任何 compact 事件后，仍应保持合理的警惕。
将它与那些能减少 canary 需要捕捉的问题的简单结构化习惯结合起来：将持久决策保存在文件中，而不是聊天记录里；在有意设定的节点进行 compact，而不是等到被迫压缩；每项任务优先使用新会话，而不是让单个会话无限延续。详情和来源见 references/research.md。