Ethan's Notes

Appearance

2026-06-07 上下文工程 拷问复盘 ​

本轮概览 ​

  • 知识点：上下文工程
  • 模块：5. AI Agent 架构
  • 分数：86/100
  • 是否过关：是
  • 来源卡片：[[上下文工程]]

本轮回答已经能把上下文工程放到 Agent 供给层来讲，并且能结合“苍穹外卖 AI 客服”说出用户上下文、工具白名单、RAG 规则、高风险后端校验和审计意识。主要扣分点是第 1 题对“Context Engineering 包含 Prompt Engineering”的表述容易被面试官追问，边界应更精确；第 2 题的组装顺序里“工具调用”和“工具 Schema 挂载”需要区分。

第 1 题 ​

题目：

如果面试官问你：“上下文工程到底解决什么问题？它和 Prompt Engineering 的边界在哪里？”你会怎么回答？

你的回答：

上下文工程是 Agent 系统的供给层，解决给什么信息、什么时候给、给多少信息；提示词工程是指令层，解决 Agent 应该做什么、怎么做，保证稳定、可解析、安全输出。你不确定两者边界。

缺失点：

边界不建议说成“Context Engineering 包含 Prompt Engineering”。更稳的说法是：二者在一次 LLM 调用里会共同组成输入，但关注点不同。Prompt 偏指令与约束表达，Context 偏信息来源、选择、排序、压缩、隔离和预算治理。

推荐答案：

上下文工程解决的是“模型每次调用前实际看到了什么世界”的问题，也就是在有限 Token 预算里，把系统规则、当前目标、历史摘要、RAG 证据、用户记忆、工具 Schema、工具结果等信息按优先级组装成高信噪比输入。Prompt Engineering 解决“怎么指挥模型”，比如角色、任务、格式、边界和失败兜底；Context Engineering 解决“给模型什么材料、什么时候给、给多少、旧信息怎么压缩或删除”。复杂 Agent 里只写好 Prompt 不够，因为工具结果、检索噪声、历史膨胀、记忆污染和安全边界都会影响模型决策。

项目口径：

在苍穹外卖 AI 客服里，我不是把全部规则和全部工具一次性塞进 Prompt，而是用 Spring AI Advisor 链分层注入用户上下文、对话记忆、RAG 证据、工具白名单和安全策略。Prompt 是行为约束，Context 是运行时材料供给，两者配合后再由 Java 端做权限校验、状态机查询和工具结果解析。

第 2 题 ​

题目：

一个生产级 Agent 如果把历史对话、RAG 检索结果、用户记忆、工具 Schema、工具调用结果全部塞进上下文窗口，可能会出现哪些问题？你会如何设计上下文组装链路来控制这些问题？

你的回答：

可能出现上下文腐化、Lost in the Middle、Token 账单爆炸。会判断预加载、动态加载或混合策略；装配时注入静态系统规则、用户指令、记忆、按需 RAG、工具调用，然后压缩历史，把重要信息排序到首尾，最后做 Token 优化和裁剪。

缺失点：

整体方向对，但“工具调用”不是上下文组装前置步骤。更准确是先根据意图选择并挂载工具 Schema，模型调用工具后，再把清洗后的工具结果作为 observation 回填上下文。还可以补充证据可追溯、过期记忆过滤、重复工具结果清理。

推荐答案：

全塞上下文会带来上下文腐化、检索噪声、记忆污染、Lost in the Middle、成本和延迟上升、工具错选、旧工具结果误导新决策等问题。组装链路可以按 Context Assembler 理解：先加载系统规则、安全边界和输出格式，再抽取当前目标；然后召回必要的用户上下文、历史摘要、长期记忆和 RAG 证据；再根据意图选择本轮可用工具 Schema；随后对证据、工具描述和历史做排序、去重、压缩和 Token 裁剪。工具调用发生后，要把工具结果清洗成结构化 observation，只保留关键字段、失败原因和下一步动作。

项目口径：

在客服场景里，FAQ 可以先走语义缓存，高置信命中就短路；不命中再走 RAG。订单、退款、取消订单这类任务则按意图挂载工具白名单，并只注入当前用户、当前订单和当前任务相关字段。历史对话只保留关键摘要，不把完整聊天流水塞给模型。

第 3 题 ​

题目：

结合你的“苍穹外卖 AI 客服”项目，如果用户说“帮我把最近两个还没送到的订单退了”，上下文工程应该怎样参与这条链路？请重点说明：哪些信息要注入，哪些工具不能一开始全暴露，以及高风险操作为什么不能只交给模型判断。

你的回答：

先用最近几轮记忆给意图识别系统，识别退单操作后先与用户交互确认；再加载用户 ID、对话 ID、用户画像等上下文；根据意图做工具白名单；RAG 检索退单规则；工具调用结果清洗后返回 Agent 决策。退单高危操作在后端做权限校验、状态机查询；你还指出应有审计步骤但项目未做，最后异步写入结构化记忆。

缺失点：

回答很贴近项目高分口径。可以再明确“不能一开始全暴露”的工具包括取消订单、退款、订单查询、地址修改、优惠券等不同域工具，应该随意图和阶段逐步开放；确认动作之外，还要强调后端不可相信模型的自然语言判断。

推荐答案：

这句话进入系统后，先抽取当前目标：用户想对最近两个未送达订单做退单或退款。上下文工程需要注入用户身份、当前会话、最近订单摘要、订单状态、退单规则、历史偏好和必要的安全边界，但不应注入完整历史聊天和全量订单。工具层面不能一开始暴露所有业务工具，而是先开放订单查询和规则查询；只有确认订单满足状态、用户确认且后端校验通过后，才进入取消订单或退款工具。高风险操作不能只交给模型判断，因为模型可能误解状态、忽略规则或被用户诱导绕过限制，必须由 Java 端做权限校验、订单状态机校验、参数 schema 校验、幂等控制和审计记录。

项目口径：

我会用 Spring AI Advisor 链做上下文分层：UserContextAdvisor 注入用户与订单上下文，RAG Advisor 注入退单规则，Tool Advisor 根据意图挂载订单查询和退单相关白名单，SafeToolCallAdvisor 限制重复调用和最大轮次。最终取消订单这类动作必须落在后端状态机和权限校验上，模型只负责理解意图和组织交互，不能直接拥有最终业务裁决权。

下次复习动作 ​

  • 把第 1 题背成一句稳定口径：Prompt 是指令层，Context 是供给层；二者共同组成输入，但治理对象不同。
  • 二刷第 2 题时重点区分“工具 Schema 挂载”和“工具调用结果回填”。
  • 第 3 题保留“审计记录我项目里还没做，但生产化应补上”的诚实表达，这是加分点，不要删。