很多智能体并不是“不会推理”，而是拿到的信息太多、太杂，或者关键资料根本没有在需要的时候出现。把一整段聊天记录、所有工具结果和模糊的任务要求一起塞进提示词，短任务或许还能运行，任务一复杂，智能体就容易抓错重点、重复调用工具，甚至依据已经过时的内容继续行动。上下文工程要解决的，正是“哪些信息应该进入当前任务，以及应该以什么顺序、什么形式进入”的问题。
传统提示词编写，通常关注一句话怎么写得更清楚：角色是什么、任务是什么、输出格式是什么、有哪些限制条件。它主要优化的是指令本身。
上下文工程关注的范围更大。除了指令，还要处理任务背景、用户资料、历史对话、外部文档、工具返回结果、当前运行状态和约束条件。智能体每次执行任务时，都需要从这些信息中挑出真正有用的部分，组成一次可用的上下文。
可以把两者理解为：
例如，让智能体整理一份活动方案，提示词可能规定输出结构、目标读者和语气；上下文工程则要进一步判断：活动的时间和预算是否仍然有效，历史讨论中哪些意见已经被否定，工具查到的资料哪些与当前方案直接相关，以及最终方案必须避开什么问题。
这也是智能体与一次性问答之间的重要区别。一次性问答往往只处理当前输入，而智能体会在多个步骤中持续接收新信息、调用工具并产生中间结果。上下文如果没有管理好，后面的判断就可能被无关内容干扰。
刚开始搭建智能体时，不要急着把所有资料都放进系统提示词。更实用的做法，是先按信息作用进行分层。
任务背景回答的是“为什么要做这件事”和“当前面对什么情况”。
它可以包括目标、对象、已有进展、业务场景和最终用途。例如，用户不是单纯要求“写一份文案”，而是要为某个活动准备适合发布在社交平台上的介绍；这时，活动对象、发布时间和内容用途都属于任务背景。
背景信息不必写得很长，但要保留能够改变判断的内容。与当前任务没有关系的历史闲聊、重复描述和已经结束的讨论，不应因为“可能有用”就全部保留。
约束条件回答的是“什么不能做”和“结果必须满足什么要求”。
常见约束包括输出语言、格式、篇幅、受众、禁止涉及的内容、可使用的资料范围，以及是否需要先确认再执行。约束的特点是优先级较高，一旦遗漏，智能体即使完成了主要任务，也可能交付错误结果。
约束最好用明确、可检查的表达，而不是模糊形容。例如，与其写“内容要专业一点”，不如说明面向谁、采用什么语气、哪些内容不应出现。这样，智能体在生成结果后也更容易进行自检。
工具结果回答的是“刚刚发生了什么”和“现在可以依据什么继续行动”。
这部分最容易失控。智能体调用工具后，返回内容可能包含大量原始数据，但并不是每一项都需要继续传递。更合理的方式是保留结果中的结论、关键字段、异常信息和下一步所需依据，同时标明数据来源或获取时间，避免把旧结果误当成当前状态。
如果工具返回的是较大的文件或数据集，可以先读取结构、字段和摘要，再按任务需要获取具体片段。资料线索中提到的“即时获取”思路，就是先确认需要什么，再读取对应部分，而不是默认把完整内容放入上下文。
历史记录回答的是“之前做过什么”和“哪些信息可能在以后继续使用”。
历史对话不等于长期记忆。某些内容只对当前任务有效，例如一次性的临时决定；另一些内容可能在后续任务中重复使用，例如稳定的偏好、固定的工作流程或已经确认的规则。两者混在一起，会让智能体难以判断信息是否仍然有效。
历史记录还需要区分“事实”和“过程”。用户最终确认的要求通常比早期讨论更重要；已经被否定的方案、过期的草稿和重复的中间推理，不应继续占据主要上下文。
信息越多，智能体不一定越可靠。筛选上下文时，可以连续问三个问题：
如果第一和第二个问题的答案都是“否”，通常可以先排除。如果信息重要，但并非马上需要，可以放入可检索或按需加载的资料中，而不是在任务开始时全部注入。
还可以给每条信息标记基本属性：
这张表不需要真的做成复杂系统。即使只是搭建一个简单的字段结构，也能帮助开发者避免把背景、指令、历史和原始数据混成一段长文本。
先写清楚智能体要完成的结果，而不是先收集资料。任务边界至少要包含目标、输入、输出和停止条件。
例如，不要只写“帮我整理资料”，而应进一步说明要整理成什么形式、服务于哪类读者、哪些资料可以使用，以及什么时候算完成。边界越清楚，后续筛选信息时就越容易判断取舍。
在收集阶段，可以暂时保留用户输入、历史对话、工具返回和外部资料，但不要直接把它们拼接成最终提示词。先把内容拆成独立的信息单元，例如一条要求、一个事实、一个工具结果或一个待确认问题。
这一步的重点不是压缩，而是防止信息在尚未判断前就混在一起。只有先看清每条内容的作用，才能判断它应该被保留、摘要、延迟加载还是丢弃。
同一事实可能在不同轮对话中重复出现，也可能出现前后不一致的版本。此时不要简单地把两段话都保留下来，而要标记冲突，并优先使用较新的、已经确认的内容。
对于工具结果，尤其要注意它代表的是“当前状态”还是“历史记录”。如果状态会变化，就不能仅因为它出现在历史对话中，便默认它仍然有效。
当对话变长时，直接删除最早内容可能会丢失重要背景；保留全部内容又会增加干扰。更稳妥的做法是生成结构化摘要，保留已经确认的事实、当前目标、未解决问题、已采取行动和后续限制。
摘要不应只是把原文缩短，而要改变信息组织方式。例如，把多轮讨论压缩为：
资料中提到的历史记录压缩和自动记忆管理，核心也是让上下文随着任务推进保持可用，而不是无限增长。
不要在任务开始时把所有内容一次性注入。可以按照“当前步骤必须知道什么”进行分段。
例如，一个需要查资料并生成方案的智能体，可以先获得任务目标和输出限制；完成资料检索后，再注入筛选后的工具结果；进入写作阶段时，保留结论和必要依据，减少原始检索过程。这样做能降低历史噪声，也方便定位是哪一阶段出现了问题。
对于较大的文档，可以先提供目录、字段说明或摘要，等智能体确认需要的部分后，再加载具体片段。这比让模型从头阅读全部资料更适合多步骤任务。
最终上下文可以采用相对固定的结构，例如：
当前目标： 输出要求： 必须遵守的约束： 已确认的任务背景： 当前状态： 本轮可用的工具结果： 仍待解决的问题： 执行顺序：
这不是必须照抄的模板，关键在于不同类型的信息要有清楚边界。尤其要把“指令”和“资料”分开，避免工具返回的文本被误当成新的指令，也避免历史讨论中的建议覆盖当前已经确认的规则。
工具调用是智能体上下文膨胀的常见来源。原始搜索结果、长文档、日志和表格都可能远大于当前任务真正需要的内容。
一个简单的处理原则是：工具负责获取，编排流程负责筛选，模型负责判断和生成。
工具返回后，可以先提取与当前目标相关的部分，再传给模型。对于结构化数据，优先提供字段含义、匹配记录和异常项；对于长文档，优先提供相关段落及其必要上下文；对于多轮调用，保留能影响下一步决策的结果即可。
如果工具结果之间存在冲突，不要让模型自行猜测哪一份正确。应在上下文中明确标注冲突来源，并把“需要确认”作为任务状态的一部分。比起输出一个看似完整但依据不明的答案，暴露不确定性更容易维护。
不要只看智能体最终有没有给出答案，还要检查它使用信息的过程是否稳定。可以用几类任务进行验证：信息很多但只有少数内容相关的任务、历史记录中存在冲突的任务、工具结果较长的任务，以及需要分多个阶段完成的任务。
重点观察几个问题：
如果某次结果出错，不要只修改最后一条提示词。先定位问题来自哪一层：是任务边界不清、约束丢失、历史摘要错误、工具结果过多，还是信息注入时机不对。上下文工程的价值，就在于可以从信息流角度排查问题，而不是把所有故障都归结为“模型不够聪明”。
刚开始搭建智能体时，不必一开始就设计复杂的记忆系统或多层代理结构。先为一个明确任务建立最小配置：固定任务目标，分离约束条件，记录当前状态，只注入经过筛选的工具结果，并保留一份可读的历史摘要。
运行几次后，再观察哪些信息经常被重复提供，哪些内容经常过期，哪些工具结果真正影响了决策。把这些观察结果反馈到信息分层和注入流程中，逐步形成适合自己任务的上下文配置方法。
上下文工程并不是把提示词写得更长，而是让智能体在正确的时间看到正确的信息。任务背景负责说明场景，约束条件负责限制行动，工具结果负责提供当前依据，历史记录负责保留必要连续性。只要这几类信息能够被区分、筛选、压缩并按阶段注入，智能体的稳定性通常就会比“把所有内容放进一个大提示词”更容易维护。
Δ
Ctrl+D