上下文工程比提示词工程更重要

两年前，让模型输出变好的主要手段是调提示词。现在这个手段的收益正在快速衰减——因为模型本身变强了，同一个提示词在不同模型上的表现差异，已经大于不同提示词在同一个模型上的差异。

真正的瓶颈转移到了另一个地方：模型在回答的那一刻，手上有什么信息。

提示词工程解决的是「怎么说」

提示词解决的是表达问题：怎么把意图说清楚、怎么约束输出格式、怎么让语气符合预期。

它是有上限的。当你的提示词已经把任务描述清楚、给出了示例、约束了格式之后，继续调优能带来的提升非常有限。

上下文工程解决的是「知道什么」

上下文工程解决的是信息供给问题：模型在这一步需要看到哪些数据、不需要看到哪些、历史信息保留多少、外部知识怎么检索进来。

它几乎没有上限，因为它取决于你对业务的理解深度。

一个具体的例子：

同样是「帮我处理这个客户的投诉」，一个 Agent 手里只有投诉文本，另一个手里有这个客户过去半年的订单记录、三次沟通记录、以及当前库存状态。同样的模型、同样的提示词，两者的输出质量不在一个量级上。

差别不在提示词，在上下文。

三个我已经在用的原则

第一，按需供给，不要全量投喂。 上下文窗口变大之后，最常见的错误是把所有能拿到的信息都塞进去。结果是模型注意力被稀释，成本还上升。正确做法是先判断这一步真正需要什么。

第二，区分「稳定上下文」和「动态上下文」。 岗位职责、业务规则、历史偏好这类是稳定的，可以预置；当前工单、实时状态是动态的，需要按需拉取。混在一起管理会失控。

第三，给模型留「不知道」的出口。 明确告诉模型：如果上下文里没有支撑结论的信息，就说不知道，不要编。这一条比任何优化技巧都有用——它把幻觉从「偶发」变成了「可控」。

一个判断方法

想评估一个 Agent 项目的工程成熟度，问一个问题：

上个月业务规则改了一次，你们改了几个地方？

答「改了提示词」，说明上下文和业务逻辑是耦合的，不可维护。答「改了业务规则表，提示词没动」，说明架构是对的。

提示词会越来越不重要。但「在正确的时刻给模型正确的信息」这件事，会越来越值钱。