上下文工程，究竟在工程化什么？

模型很强，系统仍可能拿不到正确上下文

真实 AI 产品的常见故障，很少只对应“提示写得不好”。模型可能没拿到公司内部资料，不知道刚发生的业务变化，记不住上一步已经确认的决定，或者在十几个相似工具中选错一个。继续加提示，最多修补当前调用，无法补齐数据、状态和行动接口。

这里说的上下文工程，是对意图、证据、规则、状态和工具结果进行运行时选择与装配，让模型在当前一步拿到足够且相关的信息。

手册把长上下文的风险分成四类：错误内容被反复复用，形成污染；无关内容太多，造成分心；相似材料挤在一起，产生混乱；互相矛盾的规则同时存在，形成冲突。它们共同说明一个事实：上下文窗口是注意力预算，容量和质量必须分开管理。

因此，每轮运行都要做四个明确决策：哪些信息继续留在当前窗口，哪些状态转存到外部并按需取回，哪些历史可以压缩成摘要，以及要为计划和回答预留多少空间。只盯着“还能塞多少 token”，就会漏掉更关键的预算问题：模型还剩多少注意力来判断下一步。

一套完整系统会反复经过六个动作：先理解意图，再选择证据，把规则和当前状态装配进窗口，决定是否行动，把必要状态写到外部，最后用结果修正下一轮。Agent 是这条链路的调度者，查询增强、检索、提示、记忆和工具分别给它提供接口。

手册给 Agent 的具体任务也很清楚：定期压缩历史，验证检索结果是否一致可用，删除过期或无关上下文，第一次检索失败后改写查询、切换知识库或更换切块策略，把暂时不用的细节卸载到外部，只加载当前相关工具，并在多来源互相冲突时完成综合。Agent 不替代这些技术，它负责在运行时决定何时使用哪一种。

这张运行时轨道也给了一个排错顺序。回答跑偏，先查意图有没有被误解；事实不对，查检索到的证据；反复推翻旧决定，查状态有没有持久化；工具用错，查工具合同和选择逻辑。直接换模型往往跳过了最便宜、最可定位的故障点。

第一步，把用户问题改造成系统能执行的意图

人不会按照数据库字段说话。用户可能只写“这个怎么还是不行”，把三个目标塞进一句话，或者默认系统知道“这批客户”指哪个时间段。入口不澄清，后面的检索、重排和生成都会认真优化一个错误目标。

查询重写、扩展、分解和查询 Agent 处理的是四种不同情况。

查询重写本身有三个基础动作：把别扭或省略严重的问题重新组织，删除会干扰检索的无关背景，补入目标资料常用的关键词。必要时再把复杂问题拆成子问题。这里的目标在于为不同环节准备不同形式的查询：给检索器的版本追求匹配，给最终回答的版本保留完整意图，而非单纯润色用户原话。

例如，“帮我看看最近客户为什么流失，并找三家最值得回访”至少包含三层意图：最近指哪个周期，流失要按什么口径判断，最值得回访由金额、活跃度还是挽回概率决定。系统可以先重写成结构化问题，再把原因分析和客户筛选拆开检索，最后综合。若数据分散在 CRM、工单和通话记录里，查询 Agent 才需要根据各库的 schema 动态决定搜索、过滤和聚合顺序。

一个完整的查询 Agent 至少经过分析、执行和可选综合三个阶段。它先判断问题类型、需要哪些来源和过滤条件，再执行搜索；如果结果缺字段、证据互相冲突或不足以完成任务，它要评估缺口，改写或扩展查询后重试。只有证据齐备时，才进入综合回答。这个循环比“一次搜索后直接生成”更贵，却能把检索失败暴露为可恢复的中间状态。

扩展查询能提高召回，但也会把用户意图越扩越远；分解能提高精度，但会增加调用次数和综合难度；查询 Agent 能适应未知路径，同时带来延迟、成本和调试复杂度。选择标准应落在任务上：是否含糊、是否多目标、是否需要跨库、第一次检索失败后是否值得继续探索。

入口阶段至少要留下三项可检查产物：一份保留用户原话的规范化意图、一组不可越过的范围条件、一个说明“什么结果算回答完成”的验收句。没有这三项，系统很难判断后面是在探索，还是已经跑题。

第二步，只把当前需要的知识送进上下文窗口

意图明确后，系统面临第二个问题：资料远大于窗口，哪一小部分既容易被找到，又带着足够语境？这就是检索和切块真正解决的事。

切得太小，单个片段容易命中，却可能丢掉主语、条件和例外；切得太大，语境完整，向量表示却被多个主题平均，检索时难以精准命中。手册把它画成“检索精度”和“语境完整度”的甜点区。这个甜点区没有全行业通用数字，它随文档结构、问题粒度和下游任务改变。

固定长度切块速度快，适合短而规则的资料；递归切块按段落、句子逐级处理，是常见默认；按标题或函数切块适合结构清楚的文档与代码；语义、LLM 和 Agentic 切块用更高成本判断主题边界；层级切块同时保留摘要、章节和细节；late chunking 先让表示看到全文，再从中生成片段表示。方法之外，还要决定何时切：预切块把成本放在离线阶段，查询快但策略固定；后切块根据当前问题动态处理，灵活但首轮更慢。

下面的选择器把手册的策略矩阵和 pre/post 取舍合在一起。它给的是工程起点，不是性能保证。

选择之后还要做任务级评测。本站建议先准备一小组真实问题，每题标出必须命中的原始段落；然后检查检索结果有没有覆盖答案、是否带着必要限定、无关片段占了多少、最终回答能否回到原文。若只看向量相似度或演示中的一个成功案例，切块策略很容易在换文档后失效。

这也暴露了材料的厂商视角：Weaviate 自然把向量数据库放在中心。生产系统还可能组合关键词检索、关系数据库、文件索引、事件日志和直接工具查询。检索层的目标是拿到可用证据，不是证明某一种存储方式先进。

第三步，用提示和记忆把一次调用接成长任务

检索结果不会自动变成好上下文。系统还要决定任务规则、证据、最近对话、工具说明和输出空间各占多少；哪些细节只在当前步骤有用，哪些状态值得跨轮保存。

提示在这里承担控制层：定义目标、边界、工具触发条件、参数格式、返回值和完成标准。手册介绍了 few-shot、Chain of Thought、Tree of Thoughts 与 ReAct。真正可迁移的部分，是用范例固定输出合同、把复杂任务拆成可检查阶段、让行动结果进入下一轮。无需要求模型展示私有推理；计划、工具参数、执行结果、引用和状态变化已经足够审计。

记忆则把时间拉长。当前窗口保存最近消息和这一步需要的材料；working memory 保存一个多步任务尚未完成的状态；episodic memory 记录发生过的事件；semantic memory 保存可复用事实；procedural memory 保存经过验证的做事方法。它们的存放位置、写入门和清理门不同。

“什么都存”会制造另一种遗忘：重要信息被重复、过期和低质量记录淹没。一个可用的记忆系统至少要回答五个问题：谁可以写入，凭什么写入，怎样合并冲突，什么时候取回，何时过期或删除。检索质量和写入质量同样重要；错误记忆被反复取回，会把一次失误扩散成长期偏差。

记忆架构必须服从任务。客服 Agent 更依赖能还原用户交互历史的情景记忆，财报分析 Agent 更依赖稳定的领域事实；简单任务可以先用最近若干轮对话的缓冲区，不必一开始就搭完整长期记忆。选择层级的依据，是任务是否需要跨轮状态、个性化历史、稳定知识或可复用流程。

取回记忆也不能只做一次盲搜。手册给出的改进路径包括：先扩大或迭代查询，再取回候选；用重排把真正相关的记录推到前面；必要时让查询 Agent 跨多个集合继续搜索，或让个性化逻辑结合用户偏好和交互历史重排。能存下来只是第一关，能在正确时刻取回正确一条才是记忆系统的核心能力。

手册把上下文卸载写成把信息放到窗口外，需要时再取回。现实中，最轻量的实现往往是一份结构化任务状态：目标、已完成步骤、关键决定、未解决问题、证据位置。它比保留全部聊天记录更便宜，也更容易验证。

如果你想看这一原则在真实产品里如何落地，站内这篇文章拆了 Claude Code 缩减系统提示和工具描述的具体做法。

继续阅读Anthropic 砍掉 Claude Code 八成系统提示词，给出六条新的上下文写法规则换判断、示例换接口；一个工具描述从约 9100 字符压到一句话加一个枚举→

第四步，让 Agent 选择工具，并用结果继续下一轮

工具让模型从回答问题进入行动。function calling 把“输出一段像命令的文本”推进到结构化函数名和参数；MCP 又把资源、提示和工具的连接方式标准化。连接成功只说明接口可用，无法证明 Agent 会在正确时间、用正确参数、经过正确授权调用它。

单个工具调用和工具链是两种不同难度。查一次航班，只需选中工具、填好参数并解释结果；规划一次周末旅行，可能要依次查询航班、酒店和当地活动，还要把前一步结果转成后一步约束。工具链增加了计划顺序、中间状态、局部失败和停止条件。

可靠工具循环至少包含七个检查点：发现可用工具，筛掉无关工具，选择或规划，构造参数，经过授权，执行并校验 Observation，最后判断继续、换策略、询问用户还是停止。

参数构造是最容易被低估的一关。Agent 即使选对工具，也可能漏掉必填字段、混淆单位或生成格式错误的参数。手册中的例子展示了一个可恢复路径：首次调用因参数不合格而报错，错误作为 Observation 回到窗口，Agent 据此修正参数再次执行。所谓自我修正，必须落到“读懂错误—改变参数—重新校验”的可观察过程，不能只写一句“模型会反思”。

工具描述是上下文的一部分。一个好合同要写清动词、适用范围、必填参数、单位与格式、返回结构、错误状态和限制。工具返回也要控制体积；把几万行日志原样塞回窗口，会让下一步决策被噪声拖垮。保留摘要、关键字段、原始结果位置和可复查引用，通常更稳。

MCP 的价值在于降低重复适配。传统方式里，M 个 AI 应用分别对接 N 个外部系统，最坏需要维护 M×N 组定制连接；标准协议让应用端和服务端各自适配一次，把连接问题收敛为 M+N。它提高的是模块可组合性，不是调用可靠性。官方规范里的基础原语包括 Resources、Prompts 和 Tools，远不止“给模型接工具”。它仍然不替应用决定权限、审批、数据边界、幂等、重试和停止条件。把 MCP 接通当成 Agent 完成，是把插座装好误当成电器已经安全运行。

多 Agent 也遵守同一规律。专业子 Agent 可以带着干净上下文并行处理窄任务，主 Agent 只接收压缩结果；代价是任务拆分、证据回传、冲突合并和共享状态变得更难。任务没有明显并行收益时，单 Agent 加清楚的工具和状态往往更容易验证。

一套上下文工程系统，最后要过这六道验收

这份手册把提示、检索、记忆和工具放进同一张系统图。它没有提供效果实验，也不能替你选定框架。它留下六道工程关口：每一步都要有可检查产物、失败信号和下一步交接。

评审一套 Agent 时，可以从失败反推：意图层有没有保留用户原话和完成标准；证据层能否定位原始片段；装配层是否把高信号内容和输出空间同时纳入预算；状态层有没有写入、更新和遗忘规则；行动层是否有授权、参数与幂等合同；反馈层能否根据 Observation 继续、回退或停止。

全部通过，才说明系统开始具备上下文工程。它仍需要用真实任务集验证正确率、成本、延迟和恢复能力。指南里的方法清单是设计地图，生产可靠性来自持续的 eval、日志和故障复盘。

末页把提示工程和上下文工程画成两个不同尺度：前者聚焦当前窗口里的指令，后者还要管理文档、工具、记忆文件、历史与工具结果怎样动态进入。这个对照可以再压成一句话：模型能力决定它可能做到什么，上下文系统决定它此刻依据什么、能做什么，以及做完以后留下什么。