尧图网页设计 
AI AGENT 工程范式进化史 • 第三站 • CONTEXT ENGINEERING把整个知识库塞给 AI 它反而找不到答案。第二站我们把工单接成了工作流先判断类型再走支线最后校验。可用户只说一句“上次那箱芒果还是坏的”流程虽然知道该进售后却不知道“上次”是哪张订单、是否已经补发、现在该执行哪版退款政策。很多团队的第一反应是把订单库、政策库、聊天记录全部塞给模型。问题也从这里开始——模型看见得更多不等于它更容易看见真正重要的那几条。00 / 接住第二站流程知道往哪走上下文决定拿什么走。还是总览里的那家餐馆。第一站把“来点吃的”写成标准订单第二站把订单送进备料、烹饪、复核和出餐。现在熟客说“还是上次那碗别放花生。”工作流可以准确把这张单送到过敏复核台但复核台需要三样具体信息上次到底点了什么、这个顾客的过敏记录、今天哪些食材真的有货。缺任何一项流程都可能沿着正确的路线做出错误结果。第三站不再讨论步骤怎么接。我们只问一个问题走到当前这一步模型究竟该看到什么01 / 先把概念说成人话Context 不是“多写一点 Prompt”。Anthropic 把 Context 定义为模型在一次推理时实际收到的全部 token。它不只有系统提示词还包括当前任务、对话历史、检索资料、工具返回、任务状态、示例以及其他被放进窗口的内容。所以 Prompt Engineering 更像“这张订单怎么写”Context Engineering 则是“厨师此刻的操作台上应该出现哪些订单、菜谱、忌口、库存和过程状态”。最实用的定义Context Engineering就是在每一次模型调用前组织一份“当前步骤最小够用的信息包”并在任务推进时持续更新它。02 / 为什么越多反而可能越差上下文窗口是容量不是注意力保修单。能放进几十万 token只代表容器够大不代表模型会稳定地利用其中每一条信息。资料一多真正相关的信息会和过期规则、重复日志、相似订单、其他用户的数据一起争夺注意力。Liu 等人在 TACL 论文《Lost in the Middle》中测试了多文档问答和键值检索。他们观察到相关信息放在长上下文的开头或结尾时模型表现往往更好关键信息落在中间时表现可能明显下降。这是一张论文结论的概念图不是复刻某个模型的精确数值曲线。这不等于“长上下文一定有害”也不等于所有新模型都会以相同幅度下降。更准确的结论是长窗口不能替代信息筛选关键事实的位置、相关性和冲突情况仍然需要测试。03 / 这一站的核心动作写入、选择、压缩、隔离。① 写入别指望模型凭空记住用户偏好、订单状态、已经做出的决定、尚未解决的问题要写进外部状态、数据库或可读取的笔记。上下文窗口是工作台不是永久仓库。② 选择不同节点只拿自己需要的路由节点只需要用户原话和允许的分类政策节点需要当前订单和匹配规则回复节点需要已经做出的决定和语气约束。把所有材料广播给所有节点既浪费也更容易互相干扰。③ 压缩保留结论和证据丢掉重复过程长对话和长任务会不断产生日志。压缩不是随便写个摘要而是保留目标、关键决定、证据出处、未解决问题和下一步重复工具输出、已经失败的枝节可以移出工作区。④ 隔离不该混在一起的信息必须分开不同用户、不同任务、不同角色和子流程要有清楚的信息边界。隔离不只是为了减少噪声也为了避免把甲用户的订单、乙任务的状态或某个子 Agent 的草稿误当成当前事实。04 / 不要提前塞满走到哪儿查到哪儿。Anthropic 把这种思路称为just-in-time context先保留轻量的标识符比如订单号、文件路径、存储查询和时间戳真正走到某一步时再用工具取回相关内容。餐馆不会在早上把冷库所有食材都摆到每个厨师面前而是用库位、标签和库存单定位做到某道菜时才把对应食材拿上操作台。Agent 也一样索引留在外面当前需要的内容才进入工作记忆。05 / RAG 不是全部检索解决“找回来”Context 还要负责“怎么用”。2020 年的 RAG 论文把生成模型与外部的非参数记忆结合起来让模型能够根据检索到的资料生成回答。今天大家常说的知识库问答大多沿着这条思路发展。但检索只是 Context Engineering 的一个组件。检索回来十段相似政策以后还要解决哪段是当前版本适用于哪个地区给哪个节点是否需要保留原文与订单记录冲突时信谁所以别把“做了向量库”当成 Context Engineering 已经完成。搜到资料只是上菜前找到了食材能不能在正确时间把正确食材送到正确档口才决定这道菜会不会做对。06 / 系列主线案例同一张芒果工单每个节点看到不同的信息包。继续处理第二站的消息“上次那箱芒果还是坏的别再让我等了。”第一站已经把它变成结构化工单第二站已经把它路由到退款支线。第三站不改流程只给每个节点配对信息。路由节点用户原话、允许的分类、少量典型边界案例政策节点解析出的订单号、该订单状态、当前生效且匹配地区的售后规则回复节点已经做出的处理决定、支持这个决定的证据、语气和禁用承诺校验节点输出结构、必填字段与合规规则不需要重新阅读整段聊天。如果订单号无法确认系统应该追问如果两版政策冲突应该按权威来源和生效时间处理如果历史记录显示已经补发就不能再把“重新补发”当成默认答案。上下文工程的价值不是让模型知道一切而是让它知道这一次决定真正依赖的事实。07 / 出错时怎么查先查信息包再怪模型。真实项目里“模型怎么突然变笨了”经常不是模型能力突然下降而是检索结果换了、政策版本过期、历史记录过长、摘要丢了关键条件或者另一个任务的数据混了进来。评测时不要只保存最终答案。至少同时记录模型当时收到的上下文、各段来源和时间、检索排名、被压缩掉的内容以及最终使用了哪些证据。否则出了错你只看得到结果看不到它为什么会这样答。08 / 这一站的边界知道该做什么不等于真的能安全行动。现在政策节点终于拿到了正确订单和正确规则也做出了“退款并关闭重复补发”的决定。可模型仍然不能凭一段文字完成退款它需要访问真实订单系统、调用退款工具、遵守金额权限、记录操作并在失败时停下来。第三站只带走一句Context Engineering 不是把窗口塞满而是在每一步选择最小、相关、可靠、可追溯的信息。下一步我们要给 Agent 搭真正能干活的工具、环境、权限和护栏。资料已经给对了为什么 AI Agent 还是干不了活因为知道答案和真正执行之间还隔着工具、运行环境、权限、日志与安全边界。【进入第四站 ·接上工具不等于搭好了 Harness →】关于这个系列《AI Agent 工程范式进化史》——跟着同一家餐馆连续升级一站一站讲透 AI Agent 工程的演进Prompt→Chain→Context→Harness→Loop→Graph→ 还会有的…参考来源[1] Anthropic, Effective Context Engineering for AI Agents, 2025-09-29。用于 Context 的定义、最小高信号信息、按需取用与压缩等工程原则。[2] Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL 2024。文章只使用其定性结论配图不是精确数值复刻。[3] Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020。用于说明 RAG 将生成模型与外部非参数记忆结合。口径说明餐馆与芒果工单为贯穿系列的教学案例不对应某家公司的公开数据本文没有虚构准确率或业务提升比例。 Context 不是越长越好，答案可能就埋在中间
AI AGENT 工程范式进化史 • 第三站 • CONTEXT ENGINEERING把整个知识库塞给 AI 它反而找不到答案。第二站我们把工单接成了工作流先判断类型再走支线最后校验。可用户只说一句“上次那箱芒果还是坏的”流程虽然知道该进售后却不知道“上次”是哪张订单、是否已经补发、现在该执行哪版退款政策。很多团队的第一反应是把订单库、政策库、聊天记录全部塞给模型。问题也从这里开始——模型看见得更多不等于它更容易看见真正重要的那几条。00 / 接住第二站流程知道往哪走上下文决定拿什么走。还是总览里的那家餐馆。第一站把“来点吃的”写成标准订单第二站把订单送进备料、烹饪、复核和出餐。现在熟客说“还是上次那碗别放花生。”工作流可以准确把这张单送到过敏复核台但复核台需要三样具体信息上次到底点了什么、这个顾客的过敏记录、今天哪些食材真的有货。缺任何一项流程都可能沿着正确的路线做出错误结果。第三站不再讨论步骤怎么接。我们只问一个问题走到当前这一步模型究竟该看到什么01 / 先把概念说成人话Context 不是“多写一点 Prompt”。Anthropic 把 Context 定义为模型在一次推理时实际收到的全部 token。它不只有系统提示词还包括当前任务、对话历史、检索资料、工具返回、任务状态、示例以及其他被放进窗口的内容。所以 Prompt Engineering 更像“这张订单怎么写”Context Engineering 则是“厨师此刻的操作台上应该出现哪些订单、菜谱、忌口、库存和过程状态”。最实用的定义Context Engineering就是在每一次模型调用前组织一份“当前步骤最小够用的信息包”并在任务推进时持续更新它。02 / 为什么越多反而可能越差上下文窗口是容量不是注意力保修单。能放进几十万 token只代表容器够大不代表模型会稳定地利用其中每一条信息。资料一多真正相关的信息会和过期规则、重复日志、相似订单、其他用户的数据一起争夺注意力。Liu 等人在 TACL 论文《Lost in the Middle》中测试了多文档问答和键值检索。他们观察到相关信息放在长上下文的开头或结尾时模型表现往往更好关键信息落在中间时表现可能明显下降。这是一张论文结论的概念图不是复刻某个模型的精确数值曲线。这不等于“长上下文一定有害”也不等于所有新模型都会以相同幅度下降。更准确的结论是长窗口不能替代信息筛选关键事实的位置、相关性和冲突情况仍然需要测试。03 / 这一站的核心动作写入、选择、压缩、隔离。① 写入别指望模型凭空记住用户偏好、订单状态、已经做出的决定、尚未解决的问题要写进外部状态、数据库或可读取的笔记。上下文窗口是工作台不是永久仓库。② 选择不同节点只拿自己需要的路由节点只需要用户原话和允许的分类政策节点需要当前订单和匹配规则回复节点需要已经做出的决定和语气约束。把所有材料广播给所有节点既浪费也更容易互相干扰。③ 压缩保留结论和证据丢掉重复过程长对话和长任务会不断产生日志。压缩不是随便写个摘要而是保留目标、关键决定、证据出处、未解决问题和下一步重复工具输出、已经失败的枝节可以移出工作区。④ 隔离不该混在一起的信息必须分开不同用户、不同任务、不同角色和子流程要有清楚的信息边界。隔离不只是为了减少噪声也为了避免把甲用户的订单、乙任务的状态或某个子 Agent 的草稿误当成当前事实。04 / 不要提前塞满走到哪儿查到哪儿。Anthropic 把这种思路称为just-in-time context先保留轻量的标识符比如订单号、文件路径、存储查询和时间戳真正走到某一步时再用工具取回相关内容。餐馆不会在早上把冷库所有食材都摆到每个厨师面前而是用库位、标签和库存单定位做到某道菜时才把对应食材拿上操作台。Agent 也一样索引留在外面当前需要的内容才进入工作记忆。05 / RAG 不是全部检索解决“找回来”Context 还要负责“怎么用”。2020 年的 RAG 论文把生成模型与外部的非参数记忆结合起来让模型能够根据检索到的资料生成回答。今天大家常说的知识库问答大多沿着这条思路发展。但检索只是 Context Engineering 的一个组件。检索回来十段相似政策以后还要解决哪段是当前版本适用于哪个地区给哪个节点是否需要保留原文与订单记录冲突时信谁所以别把“做了向量库”当成 Context Engineering 已经完成。搜到资料只是上菜前找到了食材能不能在正确时间把正确食材送到正确档口才决定这道菜会不会做对。06 / 系列主线案例同一张芒果工单每个节点看到不同的信息包。继续处理第二站的消息“上次那箱芒果还是坏的别再让我等了。”第一站已经把它变成结构化工单第二站已经把它路由到退款支线。第三站不改流程只给每个节点配对信息。路由节点用户原话、允许的分类、少量典型边界案例政策节点解析出的订单号、该订单状态、当前生效且匹配地区的售后规则回复节点已经做出的处理决定、支持这个决定的证据、语气和禁用承诺校验节点输出结构、必填字段与合规规则不需要重新阅读整段聊天。如果订单号无法确认系统应该追问如果两版政策冲突应该按权威来源和生效时间处理如果历史记录显示已经补发就不能再把“重新补发”当成默认答案。上下文工程的价值不是让模型知道一切而是让它知道这一次决定真正依赖的事实。07 / 出错时怎么查先查信息包再怪模型。真实项目里“模型怎么突然变笨了”经常不是模型能力突然下降而是检索结果换了、政策版本过期、历史记录过长、摘要丢了关键条件或者另一个任务的数据混了进来。评测时不要只保存最终答案。至少同时记录模型当时收到的上下文、各段来源和时间、检索排名、被压缩掉的内容以及最终使用了哪些证据。否则出了错你只看得到结果看不到它为什么会这样答。08 / 这一站的边界知道该做什么不等于真的能安全行动。现在政策节点终于拿到了正确订单和正确规则也做出了“退款并关闭重复补发”的决定。可模型仍然不能凭一段文字完成退款它需要访问真实订单系统、调用退款工具、遵守金额权限、记录操作并在失败时停下来。第三站只带走一句Context Engineering 不是把窗口塞满而是在每一步选择最小、相关、可靠、可追溯的信息。下一步我们要给 Agent 搭真正能干活的工具、环境、权限和护栏。资料已经给对了为什么 AI Agent 还是干不了活因为知道答案和真正执行之间还隔着工具、运行环境、权限、日志与安全边界。【进入第四站 ·接上工具不等于搭好了 Harness →】关于这个系列《AI Agent 工程范式进化史》——跟着同一家餐馆连续升级一站一站讲透 AI Agent 工程的演进Prompt→Chain→Context→Harness→Loop→Graph→ 还会有的…参考来源[1] Anthropic, Effective Context Engineering for AI Agents, 2025-09-29。用于 Context 的定义、最小高信号信息、按需取用与压缩等工程原则。[2] Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL 2024。文章只使用其定性结论配图不是精确数值复刻。[3] Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020。用于说明 RAG 将生成模型与外部非参数记忆结合。口径说明餐馆与芒果工单为贯穿系列的教学案例不对应某家公司的公开数据本文没有虚构准确率或业务提升比例。