从 Prompt 到上下文工程

背景

过去一年大家都在聊“Prompt Engineering”——怎么写一句更聪明的提示词。但当应用从“问答”走向“能动手的 Agent”，我发现真正的瓶颈往往不在那一句话，而在于：推理这一刻，模型到底看到了什么。

2025 年前后，“Context Engineering（上下文工程）”被越来越多地提起。它的核心观点是：上下文窗口是有限且昂贵的资源，工程师的活儿不是雕琢一句 prompt，而是在每次推理时，动态地组装出最合适的一整批信息。

核心思路

上下文工程把“喂给模型的东西”拆成几类来源，每次调用时按需拼装：

• 1 指令（System Prompt）：角色、边界、输出规范，相对稳定。
• 2 检索内容（RAG）：从知识库、向量库拉取的相关片段，动态注入。
• 3 工具定义（Tool Schema）：当前可用的函数签名，模型据此决定调用。
• 4 历史与记忆：对话记录、长期记忆，需要压缩以控制长度。
• 5 示例（Few-shot）：少量示范，帮模型对齐风格与格式。

与“写一句好 prompt”相比，上下文工程更像是一场带预算的内容编排：窗口就那么大，放什么、砍什么、按什么顺序放，直接影响结果。

示例

一次典型的 Agent 调用，上下文由多个模块在运行期组装而成：

context = [
  system_prompt,                      # 稳定指令
  retrieve_relevant_docs(query),      # RAG 动态检索
  compress(history, budget=4000),     # 历史压缩，控制长度
  few_shot_examples(task),            # 示例
  tool_definitions,                   # 当前可用工具
]

response = llm(messages=context)

这里的“压缩”很关键：直接把整段对话塞进窗口，不仅贵，还会稀释重点。常见做法是对旧消息做摘要、只保留最近几轮原文，或者用检索从记忆里挑相关片段。

总结

对简单问答，一句好 prompt 够了；但对 Agent，上下文工程比 prompt 技巧更值钱——它决定了模型是否“看得到”关键信息。

下一步我打算在我们 Agent 工作台里做一个“上下文面板”，把每次调用的组装内容可视化出来，方便调试“为什么模型没用上某条知识”。