Agent 中上下文工程如何设计，如何组织 System Prompt、工具结果和记忆？｜高频面试题解析

60 秒回答模板

我会先把上下文工程定义成 Agent 运行时的信息装配问题，不只是写一个长 Prompt。一个好的上下文结构通常分层组织：最上层是稳定的角色、目标、边界和安全规则；第二层是当前用户任务和可见输入；第三层是可用工具、工具 schema、调用约束和返回格式；第四层是历史对话、任务状态、已完成步骤和待决问题；第五层是检索到的记忆或知识片段。设计时要给每类信息设置优先级、生命周期和最大预算：系统规则最高优先级，当前任务高于历史记忆，工具结果要结构化摘要，长期记忆必须按相关性和新鲜度检索，低置信或过期信息不能无脑塞入。工程上还要处理 token 预算、截断顺序、冲突消解、敏感信息过滤、trace 记录和效果评估。最后用真实任务看任务成功率、工具调用正确率、幻觉率、上下文遗漏率和成本延迟，持续优化上下文装配策略。

考点 信息分层

难度 真实面经题

回答目标 讲清工程边界与实现取舍

深入解析

先定义上下文工程

上下文工程不是把所有资料拼进 Prompt，而是在每次 Agent 决策前，把稳定规则、当前任务、工具能力、运行状态、历史信息和外部知识按优先级装配成模型可用输入。它的目标是提高任务完成率、降低幻觉和工具误用，同时控制 token、延迟和隐私风险。

把上下文拆成稳定区和动态区

稳定区包括系统角色、能力边界、安全规则、输出格式和工具使用原则，变化频率低，应该尽量短而明确。动态区包括当前用户问题、会话历史、任务计划、工具结果、检索记忆和临时约束，变化频率高，需要按当前步骤实时选择和压缩。两者混在一起会让规则被噪声稀释。

工具结果必须结构化

工具返回不应原样堆入上下文。要保留调用目的、关键输入、成功失败状态、结构化结果、错误信息和下一步可用结论。日志、网页、文件或检索结果很长时，应先做摘要、去重和证据标注，避免模型把低相关片段当成事实依据。

记忆要按相关性渐进加载

短期记忆适合保存当前任务状态，长期记忆适合保存稳定偏好、项目知识和可复用经验。长期记忆进入上下文前要经过检索、过滤、排序和冲突检查；当它和当前用户输入冲突时，应优先当前明确输入，并把冲突作为需要澄清的信号。

截断策略要可解释

token 不够时不能随机裁剪。通常优先保留系统规则、当前任务、最近关键步骤、未完成事项和高置信证据；可丢弃重复寒暄、低相关历史、过期工具结果和已总结的中间过程。截断策略要记录 trace，方便分析错误是否来自上下文丢失。

用任务结果反推上下文质量

评估上下文工程要看任务成功率、工具调用准确率、引用证据支持率、幻觉率、澄清率、上下文遗漏率、平均 token、延迟和成本。badcase 要区分是规则不清、工具描述不准、记忆污染、检索缺失、截断错误还是模型本身能力不足。

易错点

把上下文工程等同于写一个更长的 System Prompt。
把所有历史、工具结果和记忆都塞进上下文，导致噪声和成本失控。
没有区分稳定规则、当前任务、运行状态和长期记忆的优先级。
工具结果不做结构化摘要，模型难以判断成功失败和证据来源。
截断策略不可解释，失败后无法知道丢了哪类关键信息。
忽略隐私和权限，把不该暴露的用户配置或历史记忆加入上下文。

面试官追问

上下文工程和 Prompt Engineering 有什么区别？

Prompt Engineering 更偏静态指令表达，上下文工程更偏运行时信息装配，包括工具结果、状态、记忆、检索知识、截断策略和 trace 评估。

长期记忆和当前用户输入冲突怎么办？

优先当前明确输入，把长期记忆作为参考而不是硬规则；如果冲突影响任务结果，应向用户澄清或在内部标记低置信。

工具返回很长时怎么放进上下文？

先保留调用目的、状态、关键结论、证据来源和错误信息，再按任务需要摘要原始结果。只有需要精确引用时才加入局部原文。

如何判断一次失败是上下文问题？

检查 trace 中模型是否缺少必要事实、是否看到过期或冲突信息、是否被低相关历史干扰、是否因截断丢失关键约束。