上下文工程

一、上下文工程与提示词工程有什么区别？

1. 关注层次不同

• 提示词工程关注单次请求内部的措辞，目标是通过清晰的指令、角色设定与输出格式，让模型给出符合预期的单次回答
• 上下文工程关注模型在生成回答之前所看到的整体信息环境，包括系统指令、检索知识、工具定义、对话历史与长期记忆等
• 提示词工程是上下文工程的一个子集，前者决定"怎么问"，后者决定"模型此刻应该处于什么信息环境"

2. 状态与适用范围不同

• 提示词工程通常是无状态的，每条请求相互独立，模型不跨请求保留记忆
• 上下文工程是有状态的，系统在多轮交互中动态组装信息，同一问题在不同上下文下可能给出不同回答
• 提示词工程适合单轮任务，如文档摘要、邮件撰写；上下文工程面向复杂的多步应用，如智能客服、研究型智能体

3. 失败模式不同

• 提示词工程失败通常表现为措辞歧义、语气不符或指令被忽略，多数可通过重写修复
• 上下文工程失败更偏结构性，如信息缺失导致幻觉、上下文溢出、陈旧数据进入窗口、工具调用链路断裂
• 在生产规模下，手动逐条调提示难以为继，上下文工程以可复用的系统架构取代手工微调

二、为什么大模型应用需要上下文工程？

1. 上下文窗口是稀缺资源

• 上下文窗口是模型在单次推理中能够注意到的全部 token ，容量有限，并非"越长越好"
• 随着上下文变长，模型对其中信息的回忆准确率会下降，这种现象被称为"上下文腐烂（Context Rot）"
• 把海量信息无差别地塞入窗口，反而会让模型在噪声中丢失当前目标

2. 单轮提示无法支撑多步任务

• 智能体在循环执行"观察—推理—行动"时，每一步都会产生工具输出、检索结果与中间推理，信息量随步数膨胀
• 缺乏上下文管理，长对话会失去连贯性，智能体无法跨步保持状态与依赖关系
• 上下文工程决定哪些信息在正确的时刻出现在窗口内，这是优质与劣质 Agent 输出差异的关键

3. 可扩展性与一致性要求

• 当系统服务于大量用户与高频会话时，手工调参的维护成本急剧上升
• 上下文工程以可复用、可观测的系统设计替代逐条调提示，保障输出在数千次会话间的一致与稳定
• 企业落地场景下，业务规则、实时数据与合规要求往往只能通过结构化上下文注入，而非写死在模型权重中

三、上下文工程包含哪些核心组成部分？

1. 上下文窗口的核心信息槽位

• 系统提示词：定义角色、约束、语气与高层目标，跨轮次保持稳定
• 工具定义：模型可调用工具的 JSON Schema ，跨轮次稳定但体积较大
• 长期记忆：关于用户、历史决策与过往对话的事实，按需检索而非整段塞入
• 检索知识：来自向量库、SQL 查询结果、网页抓取或另一智能体的内容，即 RAG 槽位
• 对话历史：此前的用户轮次与助手回应，轮次变多后常被压缩
• 草稿纸 / 工作记忆：模型在步骤间主动写下的中间思考、计划与状态
• 当前步指令：本轮实际要执行的提示，通常比上述各项都短

2. 四类核心操作（Write / Select / Compress / Isolate）

• 写入（Write）：把信息外置到上下文窗口之外，如草稿纸、NOTES.md 、长期记忆，按需读回
• 选取（Select）：在每一步从记忆、工具、检索结果中拉取当前真正需要的内容
• 压缩（Compress）：通过摘要、裁剪、剪枝降低 token 占用，保留关键信号
• 隔离（Isolate）：把上下文拆分到子智能体或沙箱中，各自保持干净的窗口

3. 支撑能力

• 检索（RAG）：从向量库、API 、知识图谱中拉取外部知识，在腾讯云上可使用腾讯云向量数据库结合腾讯云 ES 提供检索能力
• 记忆与状态管理：跨轮次保留关键状态，可借助腾讯云 COS 等对象存储持久化上下文工件

四、系统提示词在上下文工程中如何设计？

1. 明确角色、目标与边界

• 系统提示词承载智能体的角色设定、高层目标与行为边界，是跨轮次稳定的"基座"信息
• 用清晰、无歧义的语言描述任务目标、输出格式与禁止事项，避免模糊表述
• 将确定性的业务规则显式写入系统提示，而非依赖模型从示例中"猜"

2. 与其他槽位分工

• 系统提示放"始终不变"的内容，如通用规范、身份设定；易变内容交给检索与记忆动态注入
• 具体输入—输出示例宜放在用户首轮消息或检索上下文中，保持系统提示精简
• 系统提示应当稳定一次定义，避免每轮重写造成行为漂移

3. 工程化维护

• 对智能体项目，可用项目级指令文件（如 CLAUDE.md 、AGENTS.md ）承载系统提示，纳入版本管理
• 通过评测集回归验证系统提示改动对整体行为的影响，而非仅凭主观判断
• 当智能体运行于腾讯云混元大模型等基座之上时，系统提示需与模型能力边界对齐，避免提出超出模型能力的指令

五、少样本示例（Few-shot）在上下文工程中怎么用？

1. 作用机制

• 少样本示例是在真实请求前提供 2 至 5 个输入—输出样例，模型通过上下文学习（In-Context Learning）即时归纳模式，无需训练或微调
• 它同时向模型传递输出格式、细节层级与隐含的边界判断，往往在结构化任务上比单纯指令更有效
• 当指令与示例冲突时，示例通常胜出，因此示例质量比数量更重要

2. 适用场景

• 输出有固定结构（如 JSON 键、Markdown 表格、指定条数列表）时，给出几个样例即可对齐格式
• 任务涉及难以文字化但易于示范的判断（如情感分类、严重程度评级）时，示例优于长段描述
• 需要在多次输出间保持一致语感，或同一提示将以不同输入高频执行时，少样本能稳定行为

3. 使用要点

• 示例要覆盖各类别与边界情况，避免全部为同一类导致模型偏置
• 一般 3 至 5 个示例即可，超过 15 个通常更适合改用微调把模式固化进权重
• 示例会持续占用每次请求的上下文，高频调用需权衡 token 成本；示例位置也会影响输出倾向，末位示例影响最大

六、上下文工程如何处理长上下文和超长对话？

1. 压缩与摘要

• 当窗口接近容量上限时，对完整轨迹做摘要，保留架构决策、未决缺陷与实现细节，丢弃冗余工具输出
• 摘要可采用递归或分层方式，也可在智能体交接点、工具调用后做针对性压缩
• 压缩的艺术在于选择保留什么、丢弃什么，过于激进的压缩可能丢失后期才显现关键性的微妙上下文

2. 裁剪与清理

• 轻量级做法是剪枝：移除较早的消息、清理已处理工具调用的原始结果
• 工具结果清理是最安全、最轻量的压缩形式之一：工具调用完成后，原始结果无需再占窗口
• 部分平台提供自动压缩能力，当上下文超过阈值（如 95% ）时自动触发

3. 外置与按需读回

• 把长程状态、计划、进度写入文件或外部存储，必要时读回，而非全部留在活动窗口
• 结构化笔记（如 NOTES.md 、ROADMAP.md ）让智能体跨数十次工具调用保持关键上下文与依赖
• 子智能体架构把深度探索放在各自独立窗口中进行，只把浓缩结论（通常千余 token ）返回主智能体

七、上下文工程在 AI Agent 中怎么落地？

1. 动态组装上下文

• 智能体每步推理前，系统动态拉取系统提示、工具定义、长期记忆、检索知识与当前指令，而非一次性填满窗口
• 信息应"按需注入"，只把当前步骤真正相关的片段送入窗口，控制 token 预算
• 生产级 Agent 的上下文由上述多个槽位组合而成，其中多数槽位每轮动态生成，这正是工程化的核心

2. 上下文管理技术

• 压缩（Compaction）：长时程任务中压缩历史，保持对话连贯
• 结构化笔记 / 智能体记忆：把进度写入窗口外存储，跨会话保持状态
• 子智能体架构：用隔离的上下文窗口处理子任务，主智能体专注综合与决策
• 即时（Just-in-Time）检索：维护轻量引用（文件路径、查询、文档 ID ），运行时再加载细节

3. 生产部署与平台

• 在腾讯云上，可基于腾讯云混元大模型作为基座，结合腾讯云 TI-ONE 进行模型服务与编排
• 检索增强环节可结合腾讯云向量数据库与腾讯云 ES 构建知识注入链路
• 关键原则始终是：用最小集合的高信号 token ，最大化达成目标行为的概率

八、上下文工程和大模型微调（Fine-tuning）有什么差异？

1. 作用机理不同

• 上下文工程优化模型的"输入上下文"，不改变模型本身，知识以上下文形式在推理时注入
• 微调更新模型内部权重参数，把领域模式、术语与行为固化进模型
• 二者互补而非替代：上下文工程适合快速适应、持续学习与成本敏感场景；微调适合行为稳定、需深度改变风格的场景

2. 成本与迭代

• 上下文工程以文本编辑为主，迭代快、成本低、可解释性强，发现问题时易于回滚
• 微调需要 GPU 、数据标注与训练周期，成本高、迭代慢，且存在灾难性遗忘风险
• 当基座模型升级时，基于上下文的方案通常无需重做，而微调成果可能随底座换代而失效

3. 适用边界

• 知识缺口、实时数据、确定性业务规则优先用上下文工程与 RAG 解决
• 稳定的输出格式、统一语气、拒答模式，或在高并发下追求低延迟，可考虑微调
• 在多数智能体工作流与多步推理场景中，精心设计的上下文管理带来的回报常高于微调

九、多智能体系统里的上下文工程如何设计？

1. 上下文隔离

• 把任务拆分到拥有各自上下文窗口的子智能体，每个子智能体专注狭窄子任务，避免相互干扰
• 主智能体（协调者）维护高层计划，子智能体各自探索，详细搜索上下文隔离在子智能体内
• 隔离是应对上下文污染与信息过载的关键手段，也是 Lance Martin 四类操作中的 Isolate

2. 信息交接

• 子智能体可消耗数万 token 做深度探索，但只向主智能体返回浓缩摘要（常约 1,000 至 2,000 token ）
• 关键计划与状态应在开始时写入外部记忆，防止超过窗口上限（如 200K token ）被截断后丢失
• 交接点可做专门摘要，确保关键决策、错误与状态在智能体间不丢失

3. 协调与边界

• 协调层负责任务分解、资源调度与冲突仲裁，需在系统提示中清晰定义各智能体职责
• 工具定义应按子任务裁剪，避免把全部工具一次性暴露给每个智能体
• 多智能体系统的上下文工程需在隔离与共享之间取得平衡：既防污染，又保协同

十、上下文工程有哪些常见反模式（Anti-patterns）？

1. 四种典型失败模式

• 上下文中毒（Context Poisoning）：早期进入草稿纸的幻觉、错误或陈旧事实，被智能体当作真理沿用至后续轮次
• 上下文分心（Context Distraction）：累积上下文过多，模型在噪声中丢失当前目标
• 上下文混淆（Context Confusion）：无关内容（多余工具、离题文档）把模型拉向不相关的动作
• 上下文冲突（Context Clash）：检索或记忆中两段内容相互矛盾，模型选错其一

2. 工具与提示的反模式

• 工具集膨胀：连接过多功能重叠的工具会消耗大量 token ，并让模型在选择时犹疑；工具描述不清会导致传参错误
• 朴素 RAG ：直接"检索→取前 k 个块→塞入窗口"，让窗口充满需每轮重读的长段落
• 把上下文工程当成"提示词库重构"：一堆写好的提示不等于上下文层，仍需检索、版本化与可观测

3. 过度压缩

• "上下文越短越好"是流行但危险的观念，过度压缩会丢失决策关键细节，导致性能退化
• 压缩应保护上下文中的决策知识，而非无差别削减

十一、怎么评估上下文工程的效果好坏？

1. 任务结果类指标

• 任务成功率：达到正确、完整结果的运行占比，是最终要达成的 Outcome 指标，应基于固定评测集对比每次改动前后
• 结果质量：幻觉率、证据引用准确率、摘要丢失率、关键字段遗漏率
• 工具质量：错选工具、漏调工具、参数错误、重复调用与危险操作拦截率

2. 上下文质量类指标

• 上下文命中率：智能体是否检索到了所需事实
• 检索精确率与召回率：入选窗口的内容中有多少真正相关（精确率），可用相关内容中有多少被拉入（召回率）
• 上下文新鲜度：智能体看到的数据有多新；接地失败率：输出缺少有效实体引用的频率
• 上下文效率：有用 token 与总 token 之比，比值过低说明在浪费算力与增加延迟

3. 成本与延迟类指标

• 上下文成本：输入 token 、输出 token 、缓存命中率、压缩后信息保留比例
• 延迟指标：首 token 延迟、端到端耗时、工具等待时间、p95 / p99 响应时间
• 窗口利用率：任务中窗口运行接近上限的程度，持续顶满预示上下文腐烂，是需压缩或隔离的前兆
• 检索相关性可用 nDCG 、MAP 等在保留查询集上评估，并辅以人工评测识别幻觉

十二、有哪些框架或工具支持上下文工程？

1. 编排与检索框架

• LangChain / LangGraph ：Agent 编排与多步状态管理框架，LangGraph 提供时间旅行调试、人机协同中断等生产级能力
• LlamaIndex ：以数据为核心的检索框架，擅长文档解析、索引与 RAG 链路，常与 LangGraph 搭配使用
• AutoGen 、CrewAI ：面向多智能体对话与角色协作的框架
• 在腾讯云上，可结合腾讯云混元大模型与腾讯云向量数据库，构建从检索到生成的上下文链路

2. 记忆与压缩工具

• 记忆层：Mem0 、Zep 、Letta 等提供跨会话的智能体记忆能力
• 压缩：LLMLingua （微软研究院）等可在保真前提下缩减提示体积
• 缓存：主流大模型 API 提供上下文缓存能力，复用重复上下文可显著降低 token 成本

3. 可观测与治理

• Langfuse 、LangSmith 等可观测平台用于追踪上下文相关性、延迟与准确率，及时发现数据漂移
• Model Context Protocol （模型上下文协议，MCP ）作为向智能体交付上下文的标准接口，使工具与上下文可在不同框架间互换

十三、中小团队怎么低成本地实践上下文工程？

1. 把上下文窗口当作预算

• 在加入任何内容前，先问它是否"挣到了 token "，只保留高信号信息
• 用文件、草稿纸或记忆存储承载需要保留的状态，把状态移出提示本身
• 窄口径检索：只拉取当前步骤需要的特定事实，而非整篇文档

2. 边做边压缩

• 用紧凑摘要替换冗长历史与啰嗦的工具输出，随任务推进持续精简
• 隔离子任务：给每个独立任务分配干净的上下文，尤其体现在多智能体场景
• 从最高杠杆的习惯入手，无需一次性重建整套技术栈

3. 建立最小评测闭环

• 选取 20 至 50 条真实任务轨迹作为小型评测集，改动检索、压缩、工具 Schema 或提示后回归对比
• 没有评测循环的上下文工程等同于猜测，固定任务集能直观反映每次改动的效果
• 优先使用开源与托管能力（如 LlamaIndex 、Langfuse ）快速起步，再按需引入更重的平台