企业官网建设流程全解析

从去年开始，我一直在做一个多轮对话类项目，反复调试提示词和模型参数。项目本身不算复杂，但有个问题一直卡着：模型在同一个会话里既要做意图识别、信息抽取，又要做最终答案生成，偶尔还会调用外部工具。几轮下来，模型经常“精神分裂”——上一轮还在老实抽取字段，这一轮就开始自由发挥。折腾了好几版prompt，效果都不稳定，后来才意识到问题出在一个容易被忽略的环节上：上下文的使用方式。当时梳理方案时写了个代号，就叫“context-mode”。这算是整个项目里最不起眼、却直接决定天花板的一个设计点。这篇就来聊聊它的核心思路、落地细节和我在实际工程中踩过的一些坑。

先说清楚“context-mode”到底指什么。它本质上是对大语言模型会话上下文的一种管理模式：在同一个业务系统里，根据当前请求的任务类型，决定模型到底携带多少历史上下文、以什么形式携带、上下文数据从哪里来。没有这套模式管理，模型每轮调用都背着完整对话历史，后果就是token费用飙升、响应变慢，更麻烦的是模型在某种任务里被多余的上下文干扰，输出质量反而下降。适合谁来参考？正在做智能客服、文档问答、Agent型应用，或者自己搭了一套LLM服务并对多轮效果不满意的开发者，这篇文章应该能给你一些直接的启发。

1. 项目概述与核心挑战

1.1 多轮对话里的“隐性失控”

我先说一个很典型的场景。假设你做了一个客服机器人，用户问完“你们家的快递一般几天到？”，接着又问“那如果周末下单呢？”。这时候模型需要理解“那”指的是快递、和上一轮的问题是关联的，所以要带历史上下文，这是“多轮”的典型需求。

但同一套系统里，用户可能在第三轮突然说“帮我查一下订单号 A123 的物流”。这是一个完全独立的信息查询请求，不需要理解上一轮的“快递几天到”，只需要把订单号准确抽取出来，然后调用物流接口。问题来了：如果这一轮也背着前面完整的对话历史，模型在抽取订单号的时候就可能被“周末下单”这种无关信息带偏，甚至在输出里自行脑补一段“亲亲，周末下单会在周一发货哦”——它把抽取任务当成对话任务了。

这个现象我称之为“隐性失控”。表面上看每轮调用都成功返回了，但内容质量完全不可控。你去看日志，token消耗还很均匀，模型每次都是满血输出，没有任何报错。这种问题最坑的地方在于不好复现，你单独调试一轮请求时一切正常，放到长会话里就出问题。

context-mode要解决的，就是给模型调用加一道“管理模式”的闸门：不再让所有请求共享同一套上下文策略，而是让每轮调用明确知道自己属于哪种模式——是带完整历史的对话模式，还是只带当前输入的抽取模式，还是完全不携带历史的独立处理模式。

1.2 为什么不是单纯压缩上下文

一开始我的第一反应很简单：既然上下文多了会干扰，那就压缩呗，每轮只截取最近两轮对话不就行了？于是我把历史消息列表截断，只留最近两条用户消息和最近两条助手回复，再送进模型。试了两天，发现一个严重的连带问题：用户问“刚才说的那个方案的具体报价是多少”时，模型根本不知道“那个方案”是什么，因为方案是在五轮之前讨论的，已经被截掉了。

这就引出了context-mode的真正价值点：它不是一个简单的“截断长度”问题，而是一个“上下文结构”问题。你需要做的不是统一地少带或全带，而是根据当前任务类型，动态决定上下文的内容范围、组织结构和持久化策略。

打个比方：全量上下文就像把一整本会议纪要甩给新入职的同事，轻量上下文就像只告诉对方“你今天负责回应报价相关的问题”，而独立模式则像“这张工单你单独处理，不用了解之前的讨论”。三种方式没有绝对的好坏，关键是应用场景要匹配。

所以在设计context-mode的时候，我定义了三层维度，每一层都要单独配置，分别是：上下文可见范围（要带哪些历史）、上下文组织方式（以什么格式拼进prompt）、上下文生命周期（要不要写入长期存储）。

1.3 项目的目标与边界

这个项目最初的目标其实很朴素：在同一个模型API基础上，让系统能够稳定支持三种不同形态的交互任务，分别是自然对话、信息抽取和工具调用。后来随着调试深入，目标扩展成了三个可量化的指标：

• 分类准确率达到95%以上，即系统能准确判断当前请求应该进入哪一种context-mode。
• 在信息抽取和工具调用场景下，token消耗降低40%以上。
• 在长会话场景下，关键信息不丢失率保持在90%以上。

后面我会逐一展开这些指标是怎么通过模式设计实现的。

2. 上下文模式的三种形态与选择思路

2.1 全上下文模式：适合有状态的连续对话

先聊最基础的模式：全上下文模式。在这个模式里，模型能获得当前会话从第一轮开始的所有消息记录，包括用户的历史提问、助手的历史回复、中间插入的工具调用结果。

什么场景必须用全上下文？我总结了一个判断标准：当前轮次的回复，是否依赖之前多轮积累的隐含信息。举例：用户说“我还是觉得第一个方案好，咱们再讨论一下执行风险”。这句话里的“第一个方案”可能在五轮之前出现过，而“执行风险”是当下新增的关键词。如果上下文被截断，模型看到的就是一句没头没尾的话，它只能靠猜。

全上下文模式最大的价值，是让模型保持对话的“记忆连贯性”。用户不需要反复重复背景，模型能自己从历史里找回“第一个方案”的实际内容。这点体验上的提升非常明显，尤其是做陪伴型助手、深度咨询、项目协作这类产品时，用户不能接受一个“失忆”的对话机器人。

但这个模式也有明显的资源代价。每一轮都要把所有历史重新编码一次，token开销和响应延迟都会随轮数线性增长。更难受的是，历史越长，模型在生成时越容易“抓不住重点”——它不是不知道历史里有什么，而是不知道当前这一刻什么最重要。

我的建议是：全上下文模式只用于真正的“对话型任务”，并且要给它的历史长度设上限。比如超过20轮就做一次历史摘要压缩，而不是永远无限膨胀。

2.2 轻上下文模式：让流程任务不带包袱

第二种是轻上下文模式，也是我在这个项目里用得最多的一种。它的策略是：每条请求只携带与当前任务直接相关的少量信息，其余历史一律不进入模型。

以一个“订单状态查询”为例。用户历史里可能聊了“你们发什么快递”“能不能开增值税发票”“周末处理订单吗”等一堆东西。当用户说“查一下A123的物流”，我只需要从历史里提取“A123”这个订单号，再把一个固定的工具指令模板拼进prompt，模型就专注做格式化输出。历史里其他内容一概不传。

轻上下文模式的核心在于，系统本身要承担一部分“上下文预筛选”工作。模型不负责“判断哪些历史重要”，而是由程序先把重要条目筛出来、拼成一个精简的上下文块，再交给模型。这跟很多开发者习惯的“把全部历史丢给模型让它自己抓重点”是完全相反的设计思路，但效果要稳定得多。

我举个例子来对比：同样查询订单，全上下文模式下的prompt可能是“以下是对话历史…用户最新问题：查一下A123的物流”，模型需要自己去分辨A123是订单号还是快递单号，历史里如果出现其他数字它可能就懵了。而轻上下文模式下的prompt是“当前任务：查询订单状态。订单编号：A123。输出格式：JSON”。模型不需要做任何多余的推断，输出自然干净。

缺点是它需要不少工程投入：你要为每种任务写清提取规则、设计模板、决定哪些历史字段需要带。如果你只是快速做Demo，可能觉得不值得。但只要任务类型一多，这种模式带来的稳定性提升是肉眼可见的。

2.3 无上下文模式：独立任务的“隔离舱”

第三种模式最容易被忽略：无上下文模式。它不携带任何历史对话信息，每次调用都像第一次和模型说话一样。

无上下文模式适合所有“不需要历史也能完成”的任务。例如：把一段用户输入做情感分类、把一段文本翻译成英文、把一份产品描述总结成三条卖点。这些任务天然不依赖上下文，强行塞历史只是增加噪声。

我最喜欢举的例子是内容审核场景。你接了一个用户输入，需要判断它有没有攻击性。如果你把完整历史一起传给审核模型，历史里那些“用户崩溃抱怨”的话可能被模型误判为当前轮的攻击信号，导致正常内容被拦下。单独给审核模型喂当前这句话，它的判断才会足够“冷”。

无上下文模式还有一层好处：它可以作为整个系统的安全隔离区。如果一个请求被判定为“高风险”或“需要独立处理”，直接扔进无上下文模式，确保它不被历史里其他内容影响，也算是一种最简单的防御机制。

从资源角度看，无上下文模式是成本最低的。响应速度最快，token消耗最少。所以在架构设计时，凡是能不进全上下文模式的请求，我都尽量往无上下文或轻上下文模式里分流。

2.4 模式选择的决策逻辑

三种模式都明确了，真正的工程问题就是：系统如何决定当前请求该用哪一种？我采用的方案是一套“分级路由判断”：

• 第一级：先判断请求是否可独立完成。如果用户输入本身包含完整信息（比如“把这段文字翻译成日语”），直接进无上下文模式。
• 第二级：判断当前任务是否属于已定义的“流程型任务”。如果是，走轻上下文模式，按任务的模板提取必要字段。
• 第三级：以上都不是，说明当前输入依赖会话历史或属于开放对话，走全上下文模式。

这套路由在程序里就是几个if判断，核心是提前把“任务类型”定义清楚。我在项目里把它们写成一个枚举类型，每个枚举对应一个context-mode的配置。这样后续新增任务时，只需要注册枚举和模板，不需要改动主流程。

3. 工程实现的关键环节与参数配置

3.1 提示词模板的结构化拆分

确定模式只是第一步，真正跑起来要靠提示词模板。我建议不要把提示词写成一整段文字，而是拆成三层：

第一层是任务描述，说明模型当前扮演什么角色，要做什么事。第二层是上下文数据区，按固定格式填入筛选后的历史信息或字段信息。第三层是输出约束，明确指定输出格式、必须包含的字段、禁止出现的内容。

以轻上下文模式的查询订单为例，模板大致长这样：

当前任务：查询订单物流状态 从下面的对话历史中提取订单编号，如果未找到请回复MISSING。 对话历史： {filtered_history} 请以JSON格式输出，结构如下： {"order_id": "提取的订单编号"}

这里{filtered_history}这个槽位就是上下文筛选后的结果。每次调用前，程序会从原始对话历史里把时间最近的、包含数字或订单关键词的句子提取出来，填进这个槽位。大部分情况下槽位里只有一两句有效信息，模型一眼就能看明白。

全上下文模式的模板就简单很多，直接把完整历史按角色拼进去。但我会刻意在任务描述里加一行：“请参考以上对话历史回答当前问题，如历史中存在与问题无关的内容请忽略”。这行话虽然朴素，但实测能明显降低模型被历史带偏的概率。

3.2 上下文持久化的取舍

context-mode设计方案里还有一个隐蔽但关键的技术点：上下文持久化。持久化决定了每一轮调用开始时，系统能不能拿到正确的历史数据。

我在早期版本里用的是最简单的方式：把原始消息数组原样存到内存里，每次调用前从数组里取全部消息。这套方案在Demo阶段完全够用，但一旦系统要同时服务多个用户、多个会话，内存开销就会迅速膨胀，而且重启后所有历史丢失。

后来我改成了一套基于会话ID的持久化方案。每个会话有一个独立的上下文文件，文件里存三类数据：消息记录、抽取出来的业务字段、最近一次上下文摘要。每次请求进来时，系统根据当前的context-mode决定读取哪部分数据。全上下文模式读取完整消息记录，轻上下文模式读取业务字段和摘要，无上下文模式什么都不读。

这套方案让我意识到一件事：context-mode并不仅仅是“修改prompt的做法”，它本质上是一种数据访问策略。你在每个模式下要读不同的数据子集，数据的存储结构必须从一开始就支持这种多粒度访问。如果只存一份原始消息数组，想切模式就无从切起。

3.3 参数调优的实测经验

模型参数方面，我调试最多的是temperature和max_tokens。这两个参数在不同context-mode下的最优值差异很大，统一配置会顾此失彼。

全上下文模式下，我一般把temperature设到0.6到0.8之间，给模型一些自由度。因为这种模式主要用于自然对话，太低的温度会让回答变得生硬，像在念说明书。而轻上下文模式和无上下文模式，我基本都设在0到0.2之间，任务型输出要求确定性，不需要创造性。尤其在抽取订单号这种场景里，temperature设为0几乎能保证模型每次都稳定给出完全一致的格式化结果。

max_tokens也要分模式设置。全上下文模式的回复通常比较长，我会设到800到1000，给足输出空间。轻上下文模式的输出是格式化JSON，200到300就够。无上下文模式看任务是摘要还是翻译，灵活设。这里提一个容易踩的坑：如果max_tokens设小了，模型输出会被截断成半截JSON，解析直接报错。早期我把轻上下文模式也设成100，结果模型偶尔输出内容超出长度，DEBUG花了一个下午才发现不是代码问题而是token上限不够。

3.4 模式切换的上下文对齐机制

多模式系统很容易遇到一个尴尬场景：用户先走了轻上下文模式，查完订单后又说“那运费是多少来着？”——这个“那”是回到对话状态了。如果系统还是按轻上下文模式处理，模型拿到的上下文里没有运费信息，只能瞎猜。

我解决这个问题的方法是引入一个“对齐点”概念。每当一个流程型任务（比如查询订单）结束后，程序主动做一次上下文摘要，把这次查询的关键结果写回会话的上下文存储。然后把状态标记为“已回到对话模式”。下一轮请求到来时，路由层看到用户输入里有“那”“这个”“再问一下”这类指代词，就直接转全上下文模式，并且上下文数据里包含了刚才的查询结果，模型就能顺利接住这个指代。

这套对齐机制的实现逻辑并不复杂，但非常管用。它解决的是多模式系统里最容易被忽略的“模式切换后的信息断层”问题。没有这个机制，上下文模式切来切去，用户的体验就像跟一个间歇性失忆的人聊天。

4. 实际操作中的避坑指南与问题排查

4.1 不要把所有压力都推给模型

我在这个项目里最大的教训，就是不要把“判断应该带多少历史”这件事完全交给模型。模型确实有很强的理解能力，但它没有稳定的“边界感”。你给它全量历史，它可能把上下文里一个无关的抱怨当作当前任务的情感前提。你给它截断历史，它又会自作聪明地用“可能”“也许”来补全缺失的信息。

正确做法是用程序先做一道过滤。无论哪种模式，prompt里出现的上下文都应该是程序明确选择过的，而不是模型自主选择的。这套系统真正的工作量不在prompt写得有多精妙，而在如何设计一套可靠的过滤逻辑，把噪声挡在模型之外。

我后来在项目里加了一个独立的“上下文过滤器”模块。它做的事情包括：从历史里抽取本轮任务的关键实体、剔除与任务类型无关的角色消息、对超长历史做摘要压缩。做完这些预处理后再按不同模式组装prompt，模型的输出质量提升了一个台阶，而且整个过程的耗时只有几十毫秒，比多传一轮token让模型自己理解要划算得多。

4.2 历史摘要是必须的，但别高频触发

长会话场景下，全量历史迟早会大到不可接受。我的做法是：当一个会话的消息数超过20轮，或者累计token数超过某个阈值（比如4000），就触发一次历史摘要。

摘要的生成也会消耗token，而且生成摘要的请求本身如果带全量历史，成本更高。所以我做了一个折中：摘要请求只携带“上一次摘要结果+新产生的5轮对话”，让模型生成一条更新的摘要，然后覆盖旧摘要。这样每次摘要成本可控，且不会丢失过远的历史信息。

这里有个值得注意的细节：摘要生成后，原始历史并不会删除。我在存储里保留了原始消息和摘要两条数据。全上下文模式仍然读取原始历史，只是当原始历史超过50轮时，系统会切换为“摘要+最近5轮”的组合。这套策略保证了模型永远有足够近的上下文来理解当下，又不至于背上过重的历史包袱。

4.3 查问题先查模式，再查prompt

分享一个排查思路上的转变。早先遇到模型输出不对，我第一反应就是调prompt，改措辞、加规则、重写示例，一轮又一轮地试。后来才发现，很多问题根子不在prompt的措辞上，而在模式选择上——模型压根没有拿到应该拿到的上下文。

后来我的排查顺序固定下来了：

• 先看请求日志里这一轮走了哪个context-mode。
• 看该模式下拼出来的prompt全文，确认上下文槽位里的数据是不是符合预期。
• 如果槽位数据有问题，说明上下文筛选逻辑或持久化数据出了问题，根本不关prompt的事。
• 只有槽位数据没问题，才进入prompt本身措辞的调整。

这个顺序帮我节省了大量无效调试时间。上下文错配类的问题，靠调prompt是永远调不对的，因为模型的输入从一开始就是错的。

4.4 模式误判的经典场景

实际运行里最头疼的一类bug是模式误判——路由层把一个本该进入轻上下文模式的请求送进了全上下文模式，或者反过来。

举一个我踩过的例子。用户输入是“明天呢？”。孤立看这几乎是一句废话，没有任何实体或任务特征，路由层按我的第一级和第二级规则判断都不是流程型任务，于是归到全上下文模式。实际上用户上一轮可能问的是“今天天气怎么样？”，“明天呢？”只是自然口语里的省略。进全上下文模式反而是对的。

另一个例子是用户输入“第二个选项的报价是多少？”，孤立看有“报价”这个业务词，容易被路由层误判为流程型任务而进入轻上下文模式。但这里的“第二个选项”必须依赖历史才能知道是什么，进了轻上下文模式就傻了，模型只会输出MISSING。

这两个例子说明，模式判断不能只看当前输入里有没有业务关键词。我后来在路由判断里加了一条规则：如果当前输入里存在“它”“这个”“那个”“其”“该”一类指代词，或者出现“第二”“刚才”“之前”这类回指词，无条件走全上下文模式。这条规则简单粗暴，但几乎没有误杀正常请求。

5. 实战中的成本、速度与扩展性观察

5.1 token成本的对比数据

我自己的项目里做过一次对比测试，同一批1000条真实请求，分别用“全量上下文”和“context-mode分流”两种方案跑，结果差异非常明显。全量上下文方案平均每条请求消耗约2800 token，而分流方案的平均消耗降到约1200 token，降幅接近57%。

这个降幅主要来自两部分：一部分是无上下文和轻上下文模式的请求本身不需要带大量历史，这是大头；另一部分是长会话被摘要压缩后，全上下文模式请求的token也变小了。如果你的产品用户量上到一定规模，这个成本差就不是小数目了，甚至直接决定你能不能继续用大模型接口。

速度方面的提升同样明显。无上下文模式的响应时间基本就是单轮模型调用的时间，全上下文模式在高轮次会话里常有接近一倍的额外延迟。分流后，整个系统接口的平均延迟大约下降了三成。用户感知上，查询订单类操作几乎是秒回，比之前“先愣两秒再说”的体验顺畅多了。

5.2 模式数量与维护成本

有人可能会问，既然三种模式能解决问题，那四种、五种是不是更好？我的实际体会是：模式的种类不是越多越好，每新增一种模式，路由规则、模板、筛选逻辑、测试用例都要跟着扩展，维护成本是成倍上升的。

我把这个项目的模式数量控制为三，并非因为其他模式没有价值，而是因为三刚好能覆盖系统的绝大多数场景。如果某天真出现了一个无法归入这三类的复杂场景，我的首选方案不是新增第四种模式，而是看看能不能把它拆解成多个子任务，让每个子任务落到已有的模式里。

5.3 面向未来的可扩展设计

最后聊一下这套方案的扩展性。context-mode并不仅限于单模型应用，在多模型、多Agent的系统里同样适用。只要每个模型调用前都明确自己的上下文模式，系统整体就能保持稳定。

我在项目里预留了几个扩展点：一个是让每个会话支持独立的默认模式，不同产品线的会话可以有不同的默认上下文策略；另一个是支持从外部系统传入上下文槽位数据，比如从CRM里取用户偏好，从订单库里取历史订单。这些扩展点的共同思路是：上下文不再只是“对话历史的拷贝”，而是系统里各模块按需组合出的“信息快照”。

用context-mode的过程让我彻底改变了对大模型应用开发的看法。过去我追求的是“把prompt写得更详细”，后来我意识到，真正决定应用质量的是“你有没有把正确的信息放到模型面前”。上下文模式管理，就是那个保证信息正确性的关键开关。

最后分享一个我在实现中反复用到的自检方法：每次准备上线一个新场景前，我会把该场景的三段prompt打印出来看一眼——无上下文模式是什么样、轻上下文模式是什么样、全上下文模式是什么样。如果三段prompt长得差不多，说明这个场景没有把模式的价值用起来，值得重新设计一下。