Back to Details

evanflow-compact

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

EvanFlow: Compact

EvanFlow: 精简版

Why this exists: Context drift kills agents before context limits do. Industry research found ~65% of enterprise AI failures in 2025 traced to context drift or memory loss in multi-step reasoning, NOT raw token exhaustion. The agent's ability to reason degrades as context fills with stale, redundant, or contradictory information — long before the hard token limit.
设计初衷： 上下文漂移会在上下文容量耗尽前导致Agent失效。行业研究显示，2025年约65%的企业AI故障源于多步推理中的上下文漂移或记忆丢失，而非单纯的令牌耗尽。当上下文充斥过时、冗余或矛盾的信息时，Agent的推理能力就会下降——这远早于令牌硬限制的到来。

Vocabulary

术语定义

See 
evanflow
meta-skill. Specific to this skill:
  • Drift — agent reasoning degrades as context fills with stale/contradictory/low-signal content. Manifests as: slower responses, more clarifying questions about already-established facts, forgetting recent decisions, inconsistent application of rules.
  • Anchor — a high-signal artifact (CONTEXT.md, ADR, current plan, current diff) that survives compaction.
  • Compaction — replacing a long stretch of conversation with a shorter summary that preserves the anchors plus key decisions.
  • Branch isolation — moving a side-quest into a separate session so the main session stays focused.
请参考
evanflow
元技能。本技能特有术语：
  • Drift（漂移） — 当上下文充斥过时、矛盾或低信号内容时，Agent的推理能力下降。表现为：响应变慢、对已明确的事实提出更多澄清问题、忘记近期决策、规则应用不一致。
  • Anchor（锚点） — 经过精简后仍保留的高信号工件（如CONTEXT.md、ADR、当前计划、当前差异文件）。
  • Compaction（精简） — 用更简短的总结替换长段对话，总结中保留锚点和关键决策。
  • Branch isolation（分支隔离） — 将支线任务移至单独会话，使主会话保持专注。

When to Use

使用时机

Trigger this skill when ANY of these are true:
  • A major phase boundary just completed (e.g., Phase A done, about to start Phase B). Proactive compaction at clean boundaries is much higher quality than reactive compaction mid-flow.
  • The session has accumulated 30+ turns of dense back-and-forth.
  • You notice drift symptoms: agent re-asking already-answered questions, contradicting earlier decisions, restating context the user already established, slower or vaguer responses.
  • Context display warns of high utilization (rough threshold: ~70%+).
  • About to fork into an unrelated side-quest that could be its own session.
SKIP when: the session is short, focused, and progressing without drift symptoms. Compaction has cost (loses fidelity); only invoke when the cost of NOT compacting is higher.
当出现以下任一情况时，触发此技能：
  • 刚完成一个重要阶段（例如，阶段A已完成，即将开始阶段B）。在清晰的阶段边界进行主动精简，比在流程中途进行被动精简的质量高得多。
  • 会话已累积30轮以上的密集交互。
  • 发现漂移症状：Agent重复询问已回答的问题、与先前决策矛盾、重述用户已明确的上下文、响应变慢或模糊。
  • 上下文显示警告使用率过高（大致阈值：~70%+）。
  • 即将切入与主线无关的支线任务，该任务可作为独立会话处理。
跳过场景： 会话简短、专注且无漂移症状地推进。精简存在成本（会损失保真度）；仅当不进行精简的成本更高时才调用此技能。

The Strategies (pick one based on situation)

策略选择（根据场景选其一）

Strategy 1 — Proactive Summarize-and-Continue (preferred at clean boundaries)

策略1 — 主动总结并继续（阶段边界首选）

When a major phase just finished cleanly:
  1. Identify anchors: what files, decisions, and open questions must survive? List them explicitly.
  2. Author a compaction summary in the conversation as a markdown block titled 
    ## Phase Summary (compaction anchor)
    . Include:
    • What was decided
    • What was built (file list + one-line each)
    • What's verified
    • What's deferred / open for next phase
    • Pointers to the persistent artifacts (memory files, CONTEXT.md sections, ADRs, plan file)
  3. Tell the user: "I'm at a clean boundary. Want me to compact context here? You can 
    /clear
    and re-orient from this summary + the saved memory."
  4. If user says yes → they 
    /clear
    , then start the next phase fresh with the summary in front of them.
当一个重要阶段顺利完成时：
  1. 确定锚点：哪些文件、决策和未解决问题必须保留？明确列出它们。
  2. 在对话中撰写一个标题为
    ## 阶段总结（精简锚点）
    的Markdown块作为精简总结，内容包括：
    • 已做出的决策
    • 已完成的工作（文件列表+每个文件的一行描述）
    • 已验证的内容
    • 推迟/留到下一阶段解决的问题
    • 指向持久化工件的链接（记忆文件、CONTEXT.md章节、ADR、计划文件）
  3. 告知用户：“当前处于清晰的阶段边界。是否需要我在此处精简上下文？您可以执行
    /clear
    ，然后基于此总结和保存的记忆重新定位。”
  4. 如果用户同意 → 用户执行
    /clear
    ，然后基于总结重新开始下一阶段。

Strategy 2 — Save Anchors to Memory, Then 
/clear

策略2 — 将锚点保存至记忆，然后执行
/clear

When the session is heavy and the next move is unclear:
  1. Audit what's been learned that ISN'T already in memory or files. Anything important?
  2. Save those things to memory (
    ~/.claude/projects/<project>/memory/*.md
    ) as appropriate types (user / feedback / project / reference).
  3. Save any in-progress thinking to a plan file or a scratch doc.
  4. Tell the user: "Important state is now persisted in memory + 
    <files>
    . Recommend 
    /clear
    and re-engage fresh."
当会话负载过重且下一步方向不明确时：
  1. 检查哪些已获取的信息尚未保存到记忆或文件中？是否有重要内容？
  2. 将这些内容按需保存到记忆（
    ~/.claude/projects/<project>/memory/*.md
    ），类型包括用户信息/反馈/项目信息/参考资料。
  3. 将任何正在进行的思考保存到计划文件或草稿文档中。
  4. 告知用户：“重要状态已持久化到记忆 + 
    <文件>
    中。建议执行
    /clear
    并重新开始交互。”

Strategy 3 — Branch Isolation

策略3 — 分支隔离

When a side-quest emerges that's unrelated to the main thread:
  1. Don't pull it into this session. Tell the user: "This is a separate concern from 
    <main thread>
    . Recommend handling it in a fresh session — your context will stay clean and the side-quest gets full attention."
  2. If the user wants to do it now anyway, save the main-thread state per Strategy 2 first, then proceed.
当出现与主线无关的支线任务时：
  1. 不要将其拉入当前会话。告知用户：“这与
    <主线任务>
    是独立的事项。建议在新会话中处理——这样您的上下文会保持整洁，支线任务也能得到充分关注。”
  2. 如果用户仍希望立即处理，请先按照策略2保存主线任务状态，再继续。

Strategy 4 — Reactive Mid-Flow Summarization

策略4 — 流程中途被动总结

When drift symptoms appear and you can't reach a clean boundary:
  1. Stop the current task.
  2. Audit what's been established that's still relevant. Discard the rest mentally.
  3. Author an explicit "current state" block in the conversation summarizing only the live concerns.
  4. Continue from there, referencing the new summary as the truth.
This is less effective than proactive compaction — use only when needed.
当出现漂移症状且无法抵达清晰阶段边界时：
  1. 暂停当前任务。
  2. 检查哪些已确定的内容仍相关，在脑中舍弃其余内容。
  3. 在对话中撰写一个明确的“当前状态”块，仅总结当前相关的事项。
  4. 从此处继续，以新总结为依据。
此策略的效果不如主动精简——仅在必要时使用。

Drift Symptoms Checklist

漂移症状检查清单

Watch for these. Each is a signal to consider compaction:
  • Agent re-asks a question the user already answered
  • Agent restates the user's instructions back ("just to confirm, you want X" when X has been confirmed multiple times)
  • Agent contradicts its own earlier decision without acknowledging the change
  • Agent forgets a constraint that was set in the same session (e.g., "don't auto-commit" being violated)
  • Agent's responses become noticeably slower or vaguer
  • Agent struggles to find files it referenced minutes ago
  • Tool calls become less efficient (more reads of the same file, more redundant checks)
If 2+ symptoms in the last few turns, invoke this skill.
留意以下症状，每个都是需要考虑精简的信号：
  • Agent重复询问用户已回答过的问题
  • Agent重述用户的指令（例如，“确认一下，您想要X”，而X已被多次确认）
  • Agent在未说明原因的情况下推翻自己先前的决策
  • Agent忘记同一会话中设定的约束条件（例如，违反“不要自动提交”的规则）
  • Agent的响应明显变慢或模糊
  • Agent难以找到几分钟前还引用过的文件
  • 工具调用效率降低（重复读取同一文件、重复进行相同检查）
如果在最近几轮交互中出现2个及以上症状，请调用此技能。

Hard Rules

硬性规则

  • Never compact without an explicit checkpoint. Always write down what's being preserved before any 
    /clear
    or summary swap. Lost context that was assumed-saved is the worst failure mode.
  • Anchors first, then compaction. Save to memory / files BEFORE asking the user to 
    /clear
    .
  • User initiates 
    /clear
    .     Like commits, this is a user-controlled action. The skill recommends; the user does.
  • Compaction is lossy by design. Be explicit with the user about what's being summarized away. They might catch something you'd drop that they want kept.
  • Never auto-commit, never auto-stage. Same rule as everywhere else.
  • 禁止在无明确检查点的情况下进行精简。 在执行任何
    /clear
    或替换总结之前，务必记录下需要保留的内容。因误以为已保存而丢失上下文是最严重的失败情况。
  • 先保存锚点，再进行精简。 在请求用户执行
    /clear
    之前，先将内容保存到记忆/文件中。
  • 由用户发起
    /clear
    。     如同提交代码，这是用户可控的操作。本技能仅提供建议，由用户执行。
  • 精简本质上会丢失信息。 需明确告知用户哪些内容会被总结掉。他们可能会发现一些您忽略但希望保留的内容。
  • 禁止自动提交、禁止自动暂存。 与其他场景的规则一致。

Hand-offs

交接流程

  • After Strategy 1 or 2, before 
    /clear
    → the user runs 
    /clear
    , then re-engages from the saved anchor + memory
  • Drift symptoms persist after compaction → there may be a deeper architectural issue with how state is being managed; consider 
    evanflow-improve-architecture
  • A new feature/change is about to start with fresh context → resume 
    evanflow-brainstorming
    or 
    evanflow-writing-plans
    as appropriate
  • 执行策略1或2后，在
    /clear
    之前 → 用户执行
    /clear
    ，然后从保存的锚点和记忆重新开始交互
  • 精简后漂移症状仍存在 → 可能存在状态管理的深层架构问题；考虑调用
    evanflow-improve-architecture
  • 即将在全新上下文下启动新功能/变更 → 酌情恢复
    evanflow-brainstorming
    或
    evanflow-writing-plans