上下文工程实战指南

你要解决的问题

Agent 一旦进入生产环境，提示词文本只是上下文的一小部分。系统指令、工具定义、检索文档、消息历史、工具输出共同构成模型推理时可见的全部状态，任何一段都可能悄悄挤占真正重要的信息。

常见的失败往往不是模型能力不足，而是上下文工程出了问题：

• lost-in-middle：关键信息被埋在中间，注意力曲线呈 U 形，开头和结尾才被真正利用。
• 上下文中毒：一次错误输出被后续轮次当作事实继续使用，误差不断放大。
• 上下文干扰：无关内容淹没有效信息，信号噪声比持续下降。
• 长任务失控：任务跑得越久，状态越难维护，压缩后又丢失关键决策依据。
• 编排开销：多 Agent 系统里，主控积累的长轨迹让 worker 只看到狭窄文本片段，token 被重复消耗。

这个合集提供什么

它不是单一工具，而是一套结构化的工程指引，围绕上下文的生命周期展开：

1. 建立心智模型：先理解上下文包含什么、注意力如何工作，以及为什么上下文质量比数量更重要。
2. 识别退化模式：从现象出发定位上下文衰减，再决定该裁剪、重排还是拆分。
3. 组织架构：多 Agent 的核心目的不是模拟组织结构，而是隔离上下文。三种主流模式——集中式 supervisor、点对点 swarm、层级化分解——各有适用场景。
4. 设计记忆与文件系统：从简单 scratchpad 到时序知识图谱，文件系统本身可以作为接近无限容量的上下文载体，支持工具输出卸载、计划持久化、子 Agent 通信和动态技能加载。
5. 工具即契约：优先使用少量综合工具而非多个窄工具，错误信息里带上下文，返回格式支持 token 效率优化，命名清晰。
6. 运行期优化：compaction、观察掩码、前缀缓存、上下文分区，都是控制 token-per-task 的手段。
7. 评估与护栏：确定性检查加上多维评分，覆盖事实准确度、完整性、工具效率和流程质量；harness 提供锁定指标、持久日志、回滚规则和人工审批边界，防止 Agent 在压缩后丢失状态或把模糊目标改成不可审查的变更。
8. 自我改进：把 harness 本身作为优化对象时，约束必须更严格——双分割验收、原始 trace 归档、运行时强制边界，避免优化目标自我坍塌。

适用边界

这套方法论是平台无关的，Claude Code、Cursor 或任何支持自定义指令和 skill 的框架都可以使用，但前提是你对 Agent 的运行状态有足够可见性。

几点需要注意：

• 每个 skill 可以独立使用，但先掌握上下文基础概念再进入架构设计会更有效。
• 压缩不是越激进越好。结构化摘要保留文件、决策、下一步三个板块，通常比激进压缩保留更多有用信息；artifact 的完整性在各种方法里都是最弱的一环。
• 多 Agent 拆分有真实成本：协调延迟、上下文重复加载、评估难度上升。别在小任务上过度设计。
• Latent Briefing 这类 KV 共享优化依赖底层栈暴露 worker 的 KV 状态，且模型要兼容，不满足条件时不要硬套。
• 模型评审只应在结构、证据和评分逻辑都成立之后才引入，否则只是把主观判断包装成自动化流程。
• 优先从最小架构开始，只有在现有方案确实无法满足需求时再增加复杂度。