Agent 的上下文工程是什么？和提示词工程有什么区别？
面试怎么回答
提示词工程关注怎么写指令，上下文工程关注每一次调用模型能看到哪些信息，包括系统指令、工具定义、检索文档、历史、记忆和工具返回。对多轮多工具的 Agent，大部分 Token 来自历史和工具结果，所以效果瓶颈往往在上下文。我的做法是：只放和当前任务相关的信息；稳定内容在前、动态内容在后并做结构化标记；工具和知识按需加载；长任务定期把历史压缩成进度摘要，清理过期信息；中间结果写到外部存储需要时再读。效果用任务完成率、每步输入 Token 和因上下文导致的错误比例来衡量。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
2025 年之后，「上下文工程」（Context Engineering）这个说法越来越常见。面试官问它，不是要你背定义，而是想知道：你是否理解，Agent 效果的瓶颈往往不在提示词写得好不好，而在每一步给模型的上下文对不对。
两者的区别
- 提示词工程：关注「怎么写指令」，比如角色、格式要求、示例；
- 上下文工程：关注「每一次调用，模型能看到哪些信息」，包括系统指令、工具定义、检索到的文档、对话历史、记忆、工具返回结果，以及它们的组织方式和长度。
提示词是上下文的一部分。对一个多轮、多工具的 Agent 来说，大部分 Token 不是你写的提示词，而是历史和工具返回。
上下文工程要解决的问题
- 放什么：和当前任务相关的信息，而不是「越多越好」。无关内容会分散注意力，增加成本；
- 怎么放：稳定内容（系统指令、工具定义）放前面，动态内容放后面，有利于缓存；结构化标记，比如用标签区分「用户问题」「检索文档」「工具结果」；
- 何时放：工具和知识按需加载，而不是一开始就全部塞进去；
- 何时拿走：长任务中定期压缩历史，把已完成的部分变成结构化的进度摘要；过期、错误的信息要清理；
- 放到外面：把中间结果、笔记写到文件或外部存储，需要时再读回来，而不是一直留在上下文里。
和数据开发的关系
上下文工程很像数据开发熟悉的事情：
- 选什么进上下文，像选字段，只取需要的列；
- 压缩历史，像做汇总表；
- 外部记忆，像落盘到存储，而不是全放内存；
- 检索的质量，取决于元数据和数据质量。
怎么衡量
- 同一组任务下，任务完成率是否提升；
- 平均每步的输入 Token；
- 因上下文缺失或过时导致的错误比例（从 Trace 里标注）。