企业应用大模型时一旦输出质量不稳定最先被修改的通常是提示词。团队不断增加要求语气要专业、结论要准确、格式要统一、不能遗漏信息。提示词越来越长效果却未必持续改善。这是因为大模型的回答不仅取决于“怎么问”还取决于它在回答之前“看到了什么”。同一句提示词如果提供的客户资料、业务规则、历史记录和实时数据不同最终结果自然不同。很多被认为是模型能力不足的问题实际来自上下文缺失、过期、冲突或过量。所谓上下文可以理解为模型完成当前任务时获得的全部信息。它不仅包括用户的问题和提示词还可能包括企业制度、产品资料、聊天历史、数据库查询结果、工具返回内容、用户身份以及当前任务状态。提示词告诉模型应该做什么上下文则决定模型依据什么完成。例如让大模型“判断客户是否可以退款”仅仅把退款制度写进提示词还不够。模型还需要知道客户购买了什么产品、支付时间、服务是否已经使用、是否存在特殊协议以及当前制度的生效版本。任何一项信息缺失都可能改变结论。上下文管理的第一个难点是信息不完整。员工可能只输入一句“这个客户能退款吗”却没有提供订单编号和购买时间。模型如果为了完成任务而自行推测就可能生成错误答案。更可靠的系统应先检查必要信息是否齐全。缺少关键字段时主动要求补充能够从业务系统查询时则在获得相应权限后自动获取。与其让模型在不完整信息上反复推理不如先保证输入条件满足任务要求。第二个难点是信息已经过期。企业的价格、产品规则、组织结构和审批流程都会变化。如果系统检索到旧版本文件大模型可能非常准确地复述一条已经失效的规定。因此资料不能只标注标题还要包含生效时间、失效状态、负责人和适用范围。检索时应优先使用当前有效版本历史资料需要保留时也要明确告诉模型它只用于追溯不能作为当前结论的依据。第三个难点是不同来源互相冲突。同一个业务规则可能同时出现在正式制度、会议纪要和员工笔记中内容却并不一致。如果系统把这些材料一起交给大模型模型可能自行选择其中一种说法或者把不同规则拼接成一个看似完整的答案。企业需要提前定义资料优先级。例如正式发布的制度高于讨论稿经过确认的产品说明高于个人记录最新生效版本高于历史版本。无法判断时模型应指出冲突并转交负责人而不是替企业作出未经授权的选择。第四个难点是上下文过多。一些团队认为大模型能够读取的内容越多回答就越准确于是把大量文档、完整聊天记录和多年的业务数据一次性提供给模型。结果不仅增加了处理时间和成本还可能让真正重要的信息被无关内容淹没。上下文不是越长越好而是越相关越好。一个有效的检索过程应根据当前问题找到最有可能提供答案的少量资料同时保留必要的来源信息。对于篇幅很长的文件可以先定位相关章节而不是每次都发送全文。对话历史也需要管理。用户前几轮表达的目标可能仍然有效但早期的临时要求可能已经被后续决定替代。如果系统机械地保留全部聊天内容大模型容易受到旧信息干扰。比较合理的方式是把长期有效的信息与临时对话分开。用户身份、业务规则和任务目标可以持续保留已经完成的步骤则压缩为简短状态过时内容及时移除。第五个难点是工具返回的信息缺少解释。当大模型连接客户系统、数据库或搜索工具后工具可能返回大量字段、状态码和空值。如果应用没有说明字段含义模型只能根据名称猜测。因此工具设计也属于上下文管理。返回内容应尽量结构清楚只包含当前任务需要的数据并说明关键字段代表什么。发生查询失败时要明确返回“未找到”还是“系统异常”避免模型把技术故障理解为业务上不存在记录。企业可以为高频任务建立一套稳定的上下文结构任务目标是什么需要哪些输入允许使用哪些资料哪些实时数据必须查询输出采用什么格式遇到什么情况应该停止并转交人工。这套结构比一段不断加长的提示词更容易维护也更容易测试。评估大模型应用时也应该记录每次任务实际使用了哪些上下文。输出错误后团队需要判断是模型理解错误、检索遗漏、资料过期还是业务数据本身有问题。如果只保存最终答案就很难找到真正原因。保留资料来源、工具调用和关键任务状态才能让系统持续改进。大模型本身具备的是通用语言和推理能力企业上下文提供的才是具体业务事实。没有准确上下文再强的模型也只能在不完整信息上进行猜测。提示词决定了模型如何工作上下文决定了模型有没有条件把工作做好。企业想让大模型从偶尔表现出色变成长期稳定可用真正需要建设的不只是一套提示词而是一套能够持续提供正确、相关、及时信息的上下文机制。