ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

Context Engineering:LLM Agent 上下文工程实战,不要盲目往上下文塞数据

Context Engineering:LLM Agent 上下文工程实战,不要盲目往上下文塞数据 很多同学开发AI Agent时存在一个误区把尽可能多的文档、历史对话、工具返回结果全部丢进大模型上下文窗口认为信息越多模型效果越好。但实际项目中上下文塞满冗余噪声反而会引发幻觉、工具调用错乱、Token成本暴涨。上下文工程Context Engineering核心思想不是塞更多信息而是把对的信息放进上下文。本文结合项目案例拆解上下文工程三大核心原则以及落地实践方案。金句上下文给对了中等模型也能完成复杂任务上下文烂掉再强的模型也会输出噪声。1 什么是 Context Engineering每次调用LLM之前我们主动组装、裁剪、过滤、排序送入模型窗口的全部内容这套工程实践就是上下文工程。组装送入LLM的上下文一般包含5部分系统规则角色定义、约束条件、输出格式要求检索信息RAG检索出来的业务知识库片段工具上下文Function‑call工具定义、Schema描述历史摘要压缩后的历史对话关键信息不保存完整原始聊天上下文预算对上下文做裁剪、排序控制总token上限目标构建最小高密度信息集合行业经验上下文利用率维持在40%‑60%。利用率真正有效信息Token / 总上下文Token。利用率不是强制阈值是经验区间不同业务需要基于真实业务数据调优。2 原则一高信噪比比信息总量更加重要高信噪比 有用信息 / 全部输入信息。冗余无关信息就是噪声。反例线上踩坑案例业务场景企业内部知识库问答Agent。最初实现用户提问直接检索Top10文档片段全部原封不动丢入Prompt同时把完整10轮历史聊天全部拼接进上下文。现象Token消耗居高不下接口成本翻倍模型经常引用检索文档里无关段落生成幻觉答案偶尔工具调用参数错乱出现非法schema输出问题根源大量无关检索片段、过期历史消息作为噪声淹没关键证据。模型需要在海量文本里自己筛选有效信息很容易混淆。优化方案不追求检索返回更多片段优先保证信噪比RAG阶段增加重排器Cross‑Encoder过滤掉相关性低的文档只保留Top3高相关片段历史对话不做全量携带只保留关键结论丢弃中间试错过程移除无关背景描述只保留决策所必须的约束和证据优化之后上下文总token下降45%问答幻觉率明显下降中等参数模型即可达到原先大模型的回答质量。核心不是放得越多越好而是放得越准越好。3 原则二长任务要主动清理过期上下文状态短对话任务上下文不会持续膨胀直接使用原始历史消息即可。但Agent长任务场景多轮工具调用、子任务循环执行会不断累积消息早期推理、已经解决完毕的问题、旧工具返回结果全部堆积在上下文窗口。过期信息会持续干扰模型判断。业务案例数据库查询Agent场景Agent需要多轮调用SQL工具完成复杂统计分析一轮任务会产生8‑15轮工具交互。原始实现所有工具返回结果、用户提问、模型输出全部完整保留在message列表送入LLM。运行现象任务跑到第6轮之后模型经常引用很早之前已经失效的SQL查询结果输出错误结论上下文窗口快速打满触发截断。三种解决手段按需组合使用Compaction 消息压缩对较早轮次消息做压缩摘要保存关键结论丢弃完整原始工具返回内容。结构化笔记(Notes)把任务关键状态写入结构化笔记只把笔记送入上下文不需要携带完整历史。Sub‑agent拆分任务复杂子任务交给子Agent执行子Agent完整过程不灌入主上下文仅把最终结果带回主流程。注意短任务没有上下文膨胀问题不要强行引入记忆、结构化笔记避免过度设计增加排查难度。4 原则三先把最简单方案跑通再叠加复杂能力Anthropic 理念do the simplest thing that works先让能工作的最简单版本跑通基线。反面实践很多同学开发Agent一上来全套组件直接堆上记忆分层、复杂多路检索、Sub‑agent子代理、长期状态管理。一旦结果出错很难定位根因到底是RAG检索出问题摘要压缩逻辑bug工具Schema描述不对还是模型本身能力不足组件越多排查链路越长。正确落地迭代顺序第一步固定System Prompt固定工具边界只实现最基础的对话工具调用跑通基线版本。记录成功率、Token消耗作为基准。第二步确认基础版本稳定后接入RAG检索能力。第三步业务出现上下文过长问题再加入摘要压缩、上下文预算最大token限制。第四步只有长任务出现明确瓶颈再引入结构化笔记、Sub‑agent、高级检索策略。每次改动都要和基线做对比记录每一轮实际进入窗口的消息对比成功率、Token成本、工具调用质量验证改动是否真的带来收益。5 工程落地注意事项必须记录每轮真实上下文快照修改检索策略、摘要逻辑、工具挂载顺序之后需要保存每一轮真正送入LLM窗口的消息方便复现问题对比基线指标。不能只看上层业务输入很多bug藏在组装之后的上下文里面。40%‑60%上下文利用率只是经验区间不要硬编码当做阈值要从真实业务轨迹中寻找完成决策需要的最小信息集合。警惕过度设计短任务不要硬上记忆层、子代理能靠精简上下文解决的问题不要指望换更大参数模型去兜底。6 总结上下文工程是Agent开发非常关键但经常被忽略的一环高信噪比优先拒绝无脑堆砌信息宁可少而准不要多而杂长任务主动做状态清理Compaction压缩、结构化笔记、Sub‑agent按需选用解决上下文膨胀由简到繁迭代先跑通最简基线确认瓶颈后再叠加高级组件方便问题排查。同样的大模型上下文组装策略不同最终效果会天差地别。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进