企业官网建设流程全解析

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 / 系列主线案例

同一张芒果工单，每个节点看到不同的信息包。

继续处理第二站的消息：“上次那箱芒果还是坏的，别再让我等了。”第一站已经把它变成结构化工单，第二站已经把它路由到退款支线。第三站不改流程，只给每个节点配对信息。

1. 路由节点：用户原话、允许的分类、少量典型边界案例；

2. 政策节点：解析出的订单号、该订单状态、当前生效且匹配地区的售后规则；

3. 回复节点：已经做出的处理决定、支持这个决定的证据、语气和禁用承诺；

4. 校验节点：输出结构、必填字段与合规规则，不需要重新阅读整段聊天。

如果订单号无法确认，系统应该追问；如果两版政策冲突，应该按权威来源和生效时间处理；如果历史记录显示已经补发，就不能再把“重新补发”当成默认答案。上下文工程的价值，不是让模型知道一切，而是让它知道这一次决定真正依赖的事实。

07 / 出错时怎么查

先查信息包，再怪模型。

真实项目里，“模型怎么突然变笨了”经常不是模型能力突然下降，而是检索结果换了、政策版本过期、历史记录过长、摘要丢了关键条件，或者另一个任务的数据混了进来。

评测时不要只保存最终答案。

至少同时记录：模型当时收到的上下文、各段来源和时间、检索排名、被压缩掉的内容，以及最终使用了哪些证据。否则出了错，你只看得到结果，看不到它为什么会这样答。

08 / 这一站的边界

知道该做什么，不等于真的能安全行动。

现在，政策节点终于拿到了正确订单和正确规则，也做出了“退款并关闭重复补发”的决定。可模型仍然不能凭一段文字完成退款：它需要访问真实订单系统、调用退款工具、遵守金额权限、记录操作，并在失败时停下来。

第三站只带走一句：

Context Engineering 不是把窗口塞满，而是在每一步选择最小、相关、可靠、可追溯的信息。下一步，我们要给 Agent 搭真正能干活的工具、环境、权限和护栏。

​资料已经给对了，

为什么 AI Agent 还是干不了活？

因为知道答案和真正执行之间，

还隔着工具、运行环境、权限、日志与安全边界。

参考来源：

[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 将生成模型与外部非参数记忆结合。

口径说明：

餐馆与芒果工单为贯穿系列的教学案例，不对应某家公司的公开数据；本文没有虚构准确率或业务提升比例。