企业官网建设流程全解析

做过多轮对话Agent的人都有这种体验：上下文窗口明明还剩一大半，回复质量却开始飘。我一开始以为是自己选的模型不行，换了好几个商用API，也调过采样参数，折腾几周之后才发现，问题出在信息供给方式上——你一次性把所有背景资料、规则说明、知识片段通通塞进系统提示词里，模型反而抓不住重点，等于让一个阅读者同时看十本书，他哪知道你希望他盯着哪一本。

这个瓶颈催生了“渐进式披露”的思路。它的名字听起来抽象，核心却特别朴素：别把上下文当成需要一次性装满的仓库，而是当成随取随用的货架。先用最小信息让模型跑起来，等任务推进到某个节点，再按需补充对应的细节参数、领域规则和背景知识。这篇文章就从小型项目实践出发，聊聊为什么渐进式披露能实实在在地把上下文效率拉高，以及具体怎么落地、配参数、避坑。

1. 渐进式披露：用“分批上菜”的方式重构上下文供给

1.1 上下文效率的本质问题

先把概念对准。大模型应用开发里，“上下文窗口”是真正稀缺的资源。一个几万token的窗口，看着容量不小，可一旦塞进系统提示词、历史对话、外部检索片段、工具定义，空间立刻紧张起来。我见过太多项目，系统提示词写了两三千字，历史消息囤了十几轮，知识库召回一次性给了八千token，结果模型光“读题”就读出了幻觉。

效率低不在模型推理本身，而在信息密度与相关性。模型对上下文中最晚出现、结构最清晰、和当前任务最相关的信息天然敏感。如果这堆信息被大量无关背景淹没，模型只能靠注意力机制从中“捞取”关键点，捞成功了还好，捞偏了就是答非所问。换句话说，一次性全量披露导致三个后果：计算浪费、注意力稀释、token成本失控。渐进式披露要治的，就是这三个病。

从上手难度看，它比花哨的Agent框架、复杂微调流程低得多，本质上是提示工程层面的策略重组。你不需要重新训练模型，也不需要改底层推理服务，只改上下文组装方式，就能肉眼看到效果。我之所以觉得它该被更多人重视，是因为很多团队在纠结“换更大模型”还是“加长窗口”，却忽略了真正的问题是给模型喂信息的姿势不对。

1.2 从界面设计到提示工程的迁移

“渐进式披露”这词其实是从UI/UX领域借来的。当年做表单，如果一次性让用户填三四十个字段，体感特别差，改成先问关键信息、再根据选择展示后续字段，完成率会高很多。大模型应用也是一样的道理——系统在同一时刻给模型的上下文越少，模型的“认知负担”越低，对关键信息的利用效率反而越高。

把这个逻辑搬到提示工程里，最大的变化是视角转换：以前写系统提示词，想的是“把所有可能的规则都写上去，免得模型犯错”，现在要想的是“当前这一步，模型最需要哪些规则”。出发点是反的，效果也完全不同。

我刚实践这个思路时，是给一个文档问答助手做改造。最初版本把项目背景、术语表、回答风格、示例对答全部堆在系统提示里，效果一直不算稳。后来我把背景和术语表拆出去，只在用户主动问术语时再注入对应条目，同样的模型和后端，回答命中率反而上去了。这个案例让我确信：披露的时机和信息本身同样重要。

2. 四层披露结构：从最小启动包到兜底式全量

2.1 分层设计的思路与职责边界

在实际工程里，我会把上下文按披露深度拆成四层。这种拆法不是我拍脑袋定的，而是参考信息架构里的“渐进披露”原则，结合大模型对话的交互节奏调整出来的。

第一层叫“启动层”，对应的是最小可用上下文。它只包含三样东西：角色一句话、任务约束一句话、本次交互的口径开关。拿客服Agent举例，启动层只需要“你是客服助手，回答要简洁，不确定的事情直说不确定”这三句话。这个层级的体积控制在一两百token以内，目的是让模型“知道自己是谁、要干什么”。

第二层是“规则层”，在需要执行具体策略时披露。比如用户要做退换货，模型该知道退换货的时限、条件、操作入口。这层信息的特征是：和某一类任务强相关，提前塞给模型没有收益，等到用户明确表达对应诉求，再一次性注进去，成本最低。

第三层叫“数据层”，承载外部知识片段和用户专属上下文。比如用户历史上反映过的设备型号、售后工单记录，这类信息从数据库或向量库检索出来，再拼接到上下文里。放到第三层是因为数据层往往体积大、时效性强，不适合常驻上下文窗口。

第四层是“兜底层”，用于异常回退。当模型在低层级披露下反复无法完成任务，或用户主动追问深层原因时，才允许拉取完整背景资料。兜底层通常不会用到太频繁，但它的存在能让整个披露系统有“安全感”——毕竟谁也不敢保证低披露方案永远够用。

2.2 分层之间的切换时机与判定条件

分层之后，最核心的问题是什么时候从第一层切到第二层，从第二层切到第三层。我的经验是：不要靠“直觉判断”，要把它写成可解释的规则条件。

• 关键词命中：用户消息中出现强意图词，立即注入相关规则层。
• 槽位缺失触发：模型在回答过程中缺了某个参数，把它解析为一个披露请求，主动拉取对应数据。
• 轮次阈值：当多轮对话达到N轮，自动对前序对话做一次摘要压缩，为后续披露腾空间。
• 置信度回退：模型连续两轮给出低置信度信号，触发兜底层全量披露。

这四条规则在实现上都不复杂，性价比很高。要注意的是阈值N的设置：太短则频繁压缩，丢失细节；太长则上下文膨胀，披露效果打折。我这边的经验是先设N=5，再根据业务反馈调整，后面会展开讲。

2.3 分层披露与一次全量披露的对比实测

为了让大家对效果有个体感，放一组我自己跑过的对比数据。测试场景是某电商客服Agent，任务类型包括售前咨询、售后退换、订单查询，共100条真实对话样本。对照组A使用一次性全量上下文，对照组B使用四层渐进披露。

最让我高兴的不是延迟和token下降，而是回答质量一致性反而上涨。原因想通了也简单：模型在低噪声上下文里更容易保持稳定状态，不被冗余信息带跑。

3. 实操：给多轮Agent加上渐进披露管线

3.1 定义上下文分层协议

动手第一步，把“分层协议”写在代码里。我习惯用结构体定义每一层的字段，保证后面所有步骤都有据可查。

例如，在Python工程里我会这么定义：

from dataclasses import dataclass, field from typing import Optional @dataclass class ContextLayer: layer_id: str # 如 boot / rules / data / fallback priority: int max_tokens: int enabled: bool = True content: Optional[str] = None @dataclass class DisclosurePolicy: min_tokens: int = 180 context_window: int = 8000 layers: dict = field(default_factory=lambda: {}) def budget_for(self, layer_id: str) -> int: return self.context_window - self.min_tokens

这一步看起来简单，关键是token上限不是拍脑袋定的，而是用“业务必要信息量 + 模型输出预留空间”倒推出来的。比如模型输出平均需要1200 token，窗口8000 token，那么留给上下文的空间就是6800。启动层180 token，规则层通常压到800 token，数据层不超过3000 token，兜底层尽量控制在原有提示词范围内。

3.2 构造“最小启动包”

启动包是所有披露的起点，它决定了模型的第一印象。我写启动包有三条原则：角色一句话说清，职责边界一句话说清，不确定时的策略一句话说清。

以某跨平台系统运维助手为例，启动包大概是这样的：

你是运维助手，负责解答部署、监控、日志相关操作问题。 回答要直接，给出可执行命令或步骤。 如果问题超出你掌握的资料范围，明确说“当前上下文未覆盖”，并建议用户提供更多系统信息。

三个句子，60个token左右，足够让模型进入状态。这里有个关键细节：启动包里不要出现任何“高信息量内容”，例如具体产品参数、历史工单、术语字典。这些内容放到对应层去。启动包越薄，模型越不容易在开局阶段产生错误预期。

3.3 实现规则层的动态注入

当意图判定模块命中某个业务场景时，规则层就会触发注入。规则层的常见内容形式包括：流程步骤、边界条件、禁止事项。

我常做的一个动作是把规则写成JSON片段，而不是纯文本。纯文本对模型来说语义负担大，JSON则天然带结构，模型更容易提取“如果、那么”类逻辑。

{ "scene": "refund_request", "rules": [ {"condition": "订单状态为已发货且超过7天", "action": "告知用户需走人工审核"}, {"condition": "订单状态为未发货", "action": "可直接提交退款申请"}, {"condition": "退款原因含‘质量问题’", "action": "额外要求上传凭证"} ], "forbidden": ["不可承诺赔付金额", "不可引导用户关闭工单"] }

注入后，需要同步给模型一条明确的“使用说明”，否则模型不知道这堆JSON是干什么用的。我一般会在注入文字前加“当前用户行为命中了以下业务规则，按此规则响应”。指令越明确，模型把它纳入推理的概率越高。

3.4 按轮次做上下文压缩与回收

多轮对话跑久了，历史消息会不断膨胀，直接挤占后续披露空间。渐进式披露不只是“加法”，还要会做“减法”。

我实现的核心方法是“滚动窗口摘要”。每增加两轮对话，就跑一次轻量摘要，把“旧对话的结论、已解决事项、关键参数”抽成一两句话，替代原始对话。比如：

原始历史（约2400 token）： user: 我服务器上nginx报错，怎么处理？ assistant: 先查看错误日志…… user: 日志显示80端口被占用，怎么解决？ assistant: 用 lsof -i:80 检查占用进程…… 摘要（约120 token）： 用户在处理nginx端口占用问题，此前给出了查看日志和lsof检查占用的建议，问题尚未完全解决。

这个操作直接决定披露管线能不能长期稳定跑下去。忘了做压缩，上下文迟早会被历史吃掉；压缩做太狠，又会丢失关键细节。我的权衡标准是：把“已经解决的问题”和“还没解决的问题”分开，前者大胆摘要，后者保留原始关键片段。

3.5 设置Token预算监控与告警

披露做得再好，也得有监控兜底。我在项目里给每个上下文加了三档告警水位：

告警逻辑不复杂，只需要在调用模型前检查当前上下文的token估计值。token数量可以通过字符长度粗算，或者直接用分词器接口。我的建议是至少每天都看一眼监控曲线，因为上下文使用模式的突变往往对应交互流程的问题。

4. 踩坑实录：披露节奏失控的四个典型案例

4.1 案例一：披露过晚导致模型“睁眼瞎”

有一段时间我把规则层的触发条件设得很严格，结果用户都问了三次退款问题了，关键词一不留神没命中，模型一直用启动层的通用话术回复，答不到点上，用户直接转人工投诉。查下来发现是我把规则层触发条件写得太死，触发的意图词列表漏了好几个同义表达。

后面改成两层判定：意图词命中算强触发；轮次达到2轮且用户重复表述同一类诉求，算弱触发。强触发直接注入规则，弱触发先做一个“是否确认需求”的澄清，用户点头后再注入。这样既避免误触发，也没有漏触发。

这个案例给我的教训是：披露的时机阈值宁快勿慢。模型回答不符合预期一次，用户对系统的信任就削弱一分，成本远比多注入几百个token更高。

4.2 案例二：多轮转场时规则残留

另一个翻车点出现在多轮对话转场。用户前五分钟在问退换货，规则层已注入了退换货流程；后两分钟突然问订单支付方式，模型居然还在沿用退换货规则的措辞，导致回答文不对题。原因很简单：规则注入后没有在场景切换时回收。

修改方法是在规则注入与场景切换之间加一个“层级重置检查点”。一旦判定当前意图归属场景和已注入规则层不匹配，立刻清空规则层，回到启动层状态，再按新场景触发对应披露。“不留残留”这四个字我写在代码注释的最上面，提醒自己别偷懒。

4.3 案例三：数据层检索片段互相污染

做知识库问答的时候，我把检索片段也当成数据层的一部分。起初所有检索结果拼在一起直接塞进上下文，结果多篇文档都说到了同一个名词，模型把非当前问题相关的段落当成了主依据。

后来我在数据层内部加了“来源标记挤压法”。每段检索内容前面加上结构化的来源说明，例如“来源文档A（项目复盘记录）/来源文档B（官方操作手册）”，并且在拼接顺序上做了调整——优先放与用户原始表述关键词重叠度最高的片段，其余按相似度递减。模型在经过这种结构对比后，引用精度提升明显，幻觉比例也下来了。

4.4 案例四：压缩太勤导致关键细节蒸发

刚开始做滚动摘要时，我把压缩阈值设成每3轮一次，结果发现有些对话里的关键数字（比如产品ID、退款金额）被摘要吞了。模型回答时拿不到精确值，只能猜，出错率反而上升。

针对这个问题，我改造了摘要逻辑：在压缩之前，先扫描历史中是否包含数字、ID、时间、状态字段，这些字段强制保留原文，不进摘要。现在我把这个保留规则称为关键字段白名单。压缩只处理解释性文本、寒暄语音和已经解决的事项，核心数据始终留在上下文里。改动之后，长对话场景的精度稳定在了可接受范围内。

5. 进阶玩法：披露机制与Agent记忆体系的融合

5.1 短期缓存复用：同一个会话的披露不仅算一次成本

多轮对话里，同一层级的披露如果被重复注入，token浪费会非常明显。比如用户先问规则A，再问规则A的边界案例，结果规则层又被整份注入了一次。这个浪费可以通过“片段级缓存”解决：把注入过的规则片段哈希编号，相同编号的片段在后续轮次直接引用“已提供”状态，不重复拼接原文。

模型历史上其实会保留之前的内容，即便你不重复提供，它也“记得”。这个发现让我的披露框架加了一个基础假设：披露是可以累积的，不是每次调用都需要重放全量。这个假设成立的前提是上下文窗口够大、历史没有被截断，因此要和滚动摘要机制配合好。

5.2 把用户画像建成低优先级披露层

用户画像是一个典型的“看着有用、常驻浪费”的信息。我以前把画像写在系统提示里，结果占了几百token，绝大部分轮次根本用不上。后来我把用户画像也拆成低优先级层，只有当用户提到历史偏好、职业背景、既往诉求时，才把对应画像片段注入。

实际效果有两个：一是画像使用率大幅下降，因为模型真的需要画像信息的轮次远低于想象；二是画像命中时的准确性反而提升了。原因也能解释——平常不注入画像时，模型不依赖画像做预测，一旦注入，反而因为画像信息新鲜而给予更高注意力权重。这个特性用在个性化推荐场景里，收益很明显。

5.3 披露与Agent记忆池的联动

Agent项目大多有自己的记忆模块，有短期记忆和长期记忆。渐进式披露正好能当记忆模块的“出口闸门”。长期记忆里的内容不一定都适合直接进上下文，筛选标准就是记忆和当前任务的关联强度。

我在一个模拟项目X里实现了这个联动：向量库负责存储长期记忆，披露管线负责按需从向量库里召回。召回时不是只问“和当前问题相似度多少”，还加了一个新鲜度衰减系数——三天前记住的用户偏好要比三个月前的优先披露。这样披露的内容永远兼顾相关性和时效性，Agent的表现稳定不少。

5.4 多模态场景的披露模式

上下文效率问题不只存在于纯文本，在多模态场景更明显。图片、音频转写文本、视频字幕，这些信息量比纯文本大得多。之前做一个图像处理Demo，每次把图片的描述文本和截图信息一股脑丢进上下文，效果差且慢。

后来我把多模态数据也做了层次切分：第一层只给图片的类型、尺寸、主色调信息；用户问到具体物体、文字内容时，才叠加OCR结果或更高精度的视觉描述。这样下来，普通问题用低精度描述就能回答，高难度问题才动用高精度信息，整体成本下降一半以上。这个思路甚至可以直接复用到音视频问答场景中。

6. 常规文档不会写的三个细节经验

6.1 系统提示词里的“披露开关词”最容易被忽略

很多团队在做渐进式披露时只注意“塞什么”，没注意“怎么引导模型使用”。我发现在注入规则层时，如果只用分隔符隔开，模型经常分不清哪些新内容是普通对话、哪些是系统指令。后来我把每次披露都包在统一的开关词里，并且明确说“以下是本次回答需要遵守的临时规则，回答完毕即可忽略”。加了这句话之后，模型对临时性内容的服从度高很多，也减少了规则对后续对话的干扰。

6.2 披露不是只能做“加法”，也可以做“减法”

有些团队做披露，只想着如何把信息加进去，从来没想过如何把信息“移出来”。实际上，模型对旧信息的依赖是很强的，你上一轮注入了某套规则，这一轮不把它移除，它会继续按旧规则行事。所以披露函数至少要包含“剔除”操作：清空某层、恢复默认值、重置局部状态。上下文管理做到能加能减，才算完整。

6.3 先按领域拆规则，再按任务拆披露

架构设计初期最容易犯的错，是把所有规则写成一个“大杂烩层”。我前几个月重构了一个知识库应用，就是因为规则太多太杂，模型使用率很低。后来把规则按领域拆散，比如售后领域、技术答疑领域、商务沟通领域，每个领域独立成层，再按具体任务（退换、排障、报价）继续细分。这样披露的粒度更细，模型也更愿意遵循。粒度细了之后，测试对话的可控性也大幅提升。

我个人在实际操作中的体会是，渐进式披露不是一个“一键开启”的开关，而是一整套需要根据业务反复迭代的上下文哲学。它最大的魅力在于：不改变模型能力的前提下，仅靠调整信息供给的顺序、粒度与时机，就拿到了“更快、更准、更省”的三重收益。我建议先找一个小而高频的场景跑通闭环，比如客服问答或文档检索助手，把分层协议定好、阈值观察一两周，这个思路带来的改变会让你上瘾，然后你自然会想把它扩展到更复杂的Agent项目里。