上下文工程基础

要解决什么问题

代理系统里，模型能「看见」什么直接决定行为是否稳定、token 是否失控。很多人把上下文当成「窗口越大越好」，或把系统提示、工具定义、RAG 文档和历史消息一股脑堆进 prompt，结果出现长程任务跑偏、工具输出占满窗口、成本与延迟陡增。本技能面向设计、调试或审查代理架构时，先建立对「上下文到底是什么」的共同语言。

技能在讲什么

上下文是推理时可用的完整状态，通常包括：

• 系统提示：身份、约束与行为指南；需要平衡「写死逻辑」与「过于模糊」两种失效模式
• 工具定义：名称、描述、参数与返回格式；描述质量共同决定代理是否会猜错工具
• 检索文档：RAG 与即时加载（路径、查询、链接等轻量引用）
• 消息历史：多轮对话与任务状态；长任务里常成为主要 token 来源
• 工具输出：命令、API、文件内容等；轨迹中可占绝大部分上下文

注意力机制带来有限注意力预算：上下文变长时，中间段信息往往不如首尾可靠。工程上应追求最小高信号 token 集合，并采用渐进式披露——例如技能只先暴露名称与描述，激活后再加载全文；有文件系统访问时，把资料外置，按需读取。

适用边界与注意点

• 本技能是概念与架构层基础，不替代 context-degradation、context-optimization 等专题技能里的具体对策
• 长上下文在技术上可行，但检索与长程推理精度仍可能相对短上下文下降；设计时应假设会退化，并在开发期监控用量、在约 70–80% 利用率考虑压缩
• 整合原则：若人类工程师说不清「此情境该用哪个工具」，不要指望代理自行选对

适合在新系统立项、排查「像上下文问题」的异常行为、或给团队统一术语时使用。