上下文工程的真正难点与一种优雅的解决方案
来源: 微信公众号/手工川 | 日期: 2026-04-07 原文: 上下文工程的真正难点与一种优雅的解决方案 精读日期: 2026-04-08
一句话总结
行业花三年解决了”怎么往上下文里塞东西”，但真正卡住所有人的是”怎么让上下文保持干净”——作者提出 AutoContext，让 AI 自主感知、评估和优化自身上下文状态。
核心内容
从 Prompt 到 Context 到 Harness：输入端的三次范式跃迁
作者梳理了 2023-2026 年 AI 输入端演进的完整时间线：
| 时间 | 事件 | 意义 |
|---|---|---|
| 2023.6 | OpenAI Function Calling | 模型从”会说话”到”会指挥干活” |
| 2024.11 | Anthropic 开源 MCP | 定义 AI 应用层连接标准 |
| 2025.2 | Claude Code 发布 | 输入从 API 参数进化到项目级知识库 |
| 2025.10 | Anthropic Agent Skills | MCP 管连接，Skills 管认知——双层架构 |
| 2026.2 | Harness Engineering 概念提出 | Agent = Model + Harness |
核心洞察：几乎每一次输入端范式扩展都是 Anthropic 先定义、行业再跟进。但所有这些优化解决的都是”怎么往 Context 里塞东西”，没人认真解决”怎么让 Context 保持干净”。
Context 污染：隐性的、渐进的质量退化
作者定义的核心问题：在同一 session 中连续执行多个需求后，前面任务的调试日志、错误信息、不相关代码片段占据上下文窗口，导致后续任务质量下降。大多数人的反应是”开个新对话”——丢掉所有有价值的上下文，只为逃离无价值的上下文。
现有四种方案的收益与代价
| 方案 | 核心思路 | 局限 |
|---|---|---|
| 主 Agent 并行 | 在一个对话里同时做 A/B/C | 认知负载指数级上升，需求多就崩 |
| 主 Agent 串行 | 做完 A 接着做 B | 最常见也最危险，有效注意力逐轮稀释 |
| Fork/Rebase | 回滚上下文到检查点 | Claude Code 已有 /fork、/rewind、/btw 工具链，但需手动判断时机 |
| 子 Agent | 不同需求分发给独立 Agent | 子 Agent 发现的关键信息无法回流主 Agent |
AutoContext：三层自管理机制
第一层 Sense（感知）：每次新需求输入时，AI 先评估当前上下文的”信噪比”——多少内容与新需求相关，多少是噪声。
第二层 Decide（决策）：
| 信噪比 | 策略 |
|---|---|
| >80% | 继续，无需操作 |
| 40-80% | 压缩，保留相关摘要，丢弃噪声 |
| <40% | Fork，创建干净分支 |
| <10% | 全新 session |
同时评估是否需要更新外部 Context（CLAUDE.md 等），将执行中发现的项目约定沉淀下来。
第三层 Evolve（进化）：从每次决策中积累模式，自动更新项目配置，形成自进化的上下文管理策略。
工程实现：Plugin + Skill 双层架构
- Plugin（Hook 注册）：在每次用户提交 prompt
时自动运行
context_sense.py，检测 transcript 行数和体积，超标时注入提示让 Claude 自己做定性判断 - Skill（手动入口）：
/auto-context提供上下文健康报告 - 设计哲学：“笨脚本 + 聪明提示”——脚本只做阈值比较，定性判断交给 Claude 自身
- 冷却机制：同一 session 每 10 条消息最多触发一次
组合拳公式
AI 输出质量 = 输入质量 × 上下文质量 × 推理深度
三个工具分别解决链路上的三个瓶颈：
/brainstorm：通过追问帮用户想清楚问题（输入质量）auto-context：自动监控上下文健康（上下文质量）/tttt：一键拉满推理深度（推理深度）
金句摘录
- “没有人在认真解决’怎么让 Context 保持干净’的问题。而这，才是本文真正想讨论的。”
- “Context 污染不像 Bug 那样报错，不像性能问题那样可量化。它是一种隐性的、渐进的、难以察觉的质量退化。”
- “三个时代，三个问题：Prompt 工程问’问什么’，Context 工程问’给模型看什么’，Harness 工程问’整个系统怎么运转’。三者嵌套：Prompt ⊂ Context ⊂ Harness。”
- “让 AI 变强的方式有很多种。但让 AI 学会自我管理，可能是其中最被低估的一种。”
- “窗口有限，但智慧的管理让它等效无限。”
Justin 视角
- 与我的实践高度共振：我在 CC 工作区中已通过 skills + memory + session-end 构建了类似的上下文管理体系。作者提出的 Sense → Decide → Evolve 三层框架，与我的”信号驱动记忆捕捉 + handoff + 日记归档”异曲同工，但他把自动化推得更远（Hook 自动触发 vs 我的手动 session-end）
- Plugin 机制值得关注：Claude Code 的 Plugin 体系（Hook 注册能力）是 Skill 的超集。AutoContext 的实现证明了 Hook 在”主动干预”场景下的不可替代性。值得评估是否将我的部分 session 管理逻辑迁移到 Plugin 形态
- 对投资判断的参考：作者的 Lovcode（聊天记录可视化 + 多面板 vibe coding）是 Claude Code 生态的第三方增强工具。从赛道角度看，AI IDE / AI 开发者工具的”上下文管理”层正在从隐性需求变为显性产品——这可能是一个投资信号
- 公式有启发但需验证：“输出 = 输入 × 上下文 × 推理深度”的乘法关系是否成立？三者更可能是非线性的——上下文质量可能存在阈值效应（脏到一定程度突然崩溃），而非线性衰减。值得用实验数据验证
- AutoContext v1 的局限：当前实现本质上是”阈值触发 + Claude 自判断”，Evolve 层（自进化）还停留在概念阶段。真正的难点在于：如何量化上下文质量？如何让 AI 的自我评估不被上下文污染本身所扭曲？
延伸阅读
- lovstudio/claude-code-plugin — AutoContext 插件开源仓库
- lovstudio/skills — Skill 仓库
- Lovcode — 作者的 AI 聊天记录可视化 + 多面板 vibe coding 工具
- Mitchell Hashimoto 的 Harness Engineering 概念（2026.2）
- Richard Hightower: Mastering Claude Code’s /btw, /fork and /rewind
- 值得追踪：手工川（作者）、Lovcode 项目进展