企业官网建设流程全解析

从一次客服机器人改版说起：我把一个"看起来什么都懂"的智能体，从准确率72%调到了91%，单次调用成本还降了一半以上。这个过程中最深刻的体会是——模型本身没换，prompt也没有玄学式的反复修改，真正的杠杆在上下文怎么组织。今天这篇文章，我想围绕"上下文工程（Context Engineering）"这个主题，把我作为AI应用架构师在一线项目中用到的思路、方法和踩过的坑，尽可能完整地复盘一遍。

这件事适合谁看？凡是正在做AI智能体、RAG应用、或者被"大模型自己会处理，把它丢给它就行"这句话坑过的人，应该都能从中找到共鸣。我尽量少讲虚的概念，多讲可复用的判断标准和操作细节。

1. 为什么聪明模型会在小事上翻车：从一次交付事故说起

先讲一次真实事故。某内部客服系统需要做一个质检智能体，职责是自动阅读客服和用户的对话记录，输出三件事：会话是否包含情绪冲突、坐席是否有承诺不一致、是否存在敏感事件漏报。

初版实现非常简单。开发同学把所有对话历史、企业知识库中与客服相关的几十条制度文档、系统原始字段一股脑塞进system prompt，然后把整段长对话作为单次输入发给模型。单看对话样本，模型推理思路是对的，可在抽样评测里问题全暴露了：标签打偏、把旧政策当新政策、关键事件被淹没在冗长文本里。

这种事故我已经见得太多了。它说明一个事实：大模型确实聪明，但它的注意力资源不是无限的。Transformer在长上下文上的表现并不像展示出来的那么均匀，中间部分很容易被遗忘，位置靠后的内容权重容易偏高，而且当无关信息占比过大时，模型会把注意力浪费在干扰项上。你给它一车杂物，它就只能从杂物里翻找。

Prompt工程解决的是"把话说清楚"，上下文工程解决的是"把信息摆对位置、匹配好需求"。

两者的区别可以用下表概括：

这个表格不是我总结出来凑字数的。在实际项目里，我发现很多团队把80%的精力花在调prompt，却忽略了真正让系统质变的是上下文结构。prompt再精准，只要上下文里塞入过时政策、无关知识、冗余历史，模型依然会被"带偏"。反过来，上下文组织得清爽，一句朴素的任务指令就能发挥出80分以上的水平。

2. 上下文工程的核心棋盘：可控变量的拆解与取舍

上下文工程这个词听起来很学术，拆开看其实就四组变量：信息分区、检索策略、记忆结构、注入时序。我一个个展开说，这四件事决定了智能体的智商上限。

2.1 上下文窗口不是垃圾桶：信息分区与注意力预算

第一件事是把上下文窗口当成一个有预算限制的舞台，而不是无限大的垃圾箱。模型处理上下文时，每个token都会消耗计算量，更重要的是，注意力会被分散。我把上下文按功能切成六个区：

• 任务指令区：当前任务定义、输出JSON结构、判断标准
• 角色约束区：回答风格、禁用语、合规边界
• 知识参考区：从知识库检索到的内容，带来源标注
• 对话历史区：最近轮次原文，以及更早内容的摘要
• 工具状态区：调用了哪些工具、返回了什么结果
• 业务上下文区：当前会话绑定的用户信息、订单信息等

为什么分区有效？因为模型对"哪里是指令、哪里是参考"这件事天然敏感。混在一起它还要自己区分，分开了它就能直接进入执行模式。我在改造质检Agent时，第一个改动就是把职责定义和操作细则从一大段散文改成结构化区块，几乎没有任何prompt技巧的加成，错误率立刻降了6个百分点。

{ "context_blocks": { "task": "检测本会话中的情绪冲突、承诺不一致、敏感事件漏报，输出JSON。", "rules": [ "情绪冲突指客服出现贬低、嘲讽、不耐烦等行为", "承诺不一致指坐席前后给出互相矛盾的处理方案", "敏感事件指投诉升级、法律风险、安全事故类关键词" ], "knowledge_sources": [ "SOP-042-客诉处理流程", "SOP-071-赔偿权限说明" ], "recent_turns": 6, "history_summary": "前面20轮已完成身份核验与问题描述，用户情绪平稳。" } }

这个JSON仅仅是一个示例，但它代表了一个原则：让模型第一眼就知道自己该干什么、能看什么资料、按什么标准干活。信息分区的本质，就是给模型的注意力安装路标。

2.2 检索不是越多越好：相关性与冗余的度量

第二个变量是知识检索。RAG（检索增强生成）几乎是智能体的标配，但绝大多数项目的检索策略是"召回Top K塞进去"。K=3是3，K=10也是3，K=20还是3，问题是堆数量而不堆质量。

我在实践中给团队定了一条规则：先粗召回，再重排，最后裁剪。

粗召回阶段可以用向量相似度取Top 50，然后用一个更强的方式做重排——不一定用模型，直接用规则加交叉编码器就够用。重排的评分不是只看内容相似度，还要看时效性、来源可信度、与当前用户意图的匹配度。比如客服场景里，一个文档说"退款必须在7天内完成"，另一个文档说"特殊商品可延长至30天"，如果用户问的恰好是特殊商品，向量相似度完全可能把第一个文档排到前面。这时如果没有时效性和业务规则的加权，模型就会给出错误答案。

裁剪则是把重排后的文档里真正有用的话提取出来，而不是整篇塞入。我见过一个知识库文档，明明核心内容只有三句话，但全文有2000字，最终模型要在这2000字里找三句话，效果可想而知。

冗余的衡量标准很简单：删除某段内容后，输出质量是否下降？如果没有下降，那它就不该出现在上下文里。

2.3 动态裁剪与压缩：让长任务的上下文维持"新鲜感"

第三个变量是压缩。多轮对话场景里，对话历史会无限膨胀。很多团队的方案是"给模型塞最近20轮"或者"塞最近5000字"，这非常粗糙。因为对话的信息密度不均：身份核验阶段的"叫什么名字、手机号是多少"可能5轮就看完了，而后面关于退款的你来我往可能每一轮都包含新的决策信息。

我在项目中采用双轨记忆策略：

• 短期轨道：保留最近N轮原文，N根据业务复杂度取4~8轮。为什么是这个数字？因为大多数客服会话中，最近4到6轮覆盖了用户最核心的最新诉求，再往前就是重复陈述。
• 长期轨道：对N轮以前的对话做结构化摘要，摘要按实体、诉求、承诺、情绪四个维度组织。每次摘要更新时不是从头生成，而是在旧摘要基础上做增量更新，控制token消耗。

这个双轨设计还有一个隐藏好处：摘要本身就是智能体的状态表示。当对话被压缩后，模型不必重新"理解"前因后果，直接基于摘要就能做出判断。这也解释了为什么同样的模型，换了一种上下文组织方式后，多轮任务成功率会显著上升。

2.4 注入时序：什么时候给信息，比给什么信息更关键

最后一个变量是时序。我犯过的一个典型错误是：在一开始就把所有知识库内容注入，结果模型在推理过程中已经"忘记"了早期的知识。后来我改成按需注入：

• 会话启动阶段：只注入角色约束和任务定义，不注入知识
• 接收到用户消息后：先做意图识别，判断是否需要知识检索
• 需要工具调用时：才注入工具描述和工具返回结果
• 做出决策时：注入与当前决策点相关的知识片段

这个逻辑很像人类的阅读习惯：先看标题和目录，再翻到具体章节，而不是把整本百科全书直接背下来。上下文的注入时机越贴近决策点，模型的推理越精准。

3. 一个客服质检智能体的改造全过程：问题定位、方案设计与效果验证

理论说多了容易飘，我拿完整案例把改造过程走一遍。这个项目就叫"客服质检智能体"，目标是检测客服会话中的情绪冲突、承诺不一致和敏感事件漏报。改造前后对比非常明显，我把每一个步骤和思考过程都记录下来。

3.1 初始方案的三个结构性缺陷

先看初始方案。系统把以下内容全部塞进一个prompt：

1. 系统的全部质检规则（约20条细则）
2. 完整对话记录（有时长达100+轮）
3. 知识库里所有跟客服相关的制度文档（每次召回Top 10，每篇全文）
4. 客服工单的结构化字段（JSON原样拼接）

当我拿到这个prompt时，第一感觉就是"模型不是被调教坏的，是被喂饱撑坏的"。我总结出三个结构性缺陷：

缺陷一：指令密度过低。20条规则的信息量如果按token算，只占整个prompt的3%左右。模型被几百个噪声token包围，真正有效的指令弱得像背景音。缺陷二：知识库召回无重排。制度文档存在大量相似条款，向量召回返回的Top 10里有6条在讲同一件事，剩下4条信息冲突。缺陷三：完整对话历史无压缩。100轮对话里有60轮是"嗯""好的""稍等"这类无信息量回复，却依然占据上下文，还会把早期承诺埋进遗忘区。

这三个缺陷叠加起来，直接后果就是：智能体对情绪冲突的召回率只有62%，对承诺不一致的准确率仅58%。

3.2 分步改造：每一处改动都对着明确的病灶

第一步，重构上下文分区。我把system prompt彻底打散，拆成任务指令、判断标准、输出模式三块。判断标准不再用"如果出现...则..."的散文形式，改成带严重等级的枚举列表。这一步做完，准确率提升到75%左右。

第二步，改造知识检索链路。我给知识文档增加了元数据标注：适用场景、有效版本、优先级。检索后增加一个重排层，用规则加交叉编码器对候选文档打分，重点惩罚"与当前用户问题场景不匹配"的文档。这一步把承诺一致性检测的准确率从58%拉到了81%。

第三步，引入对话记忆双轨机制。我设置最近的6轮对话保留原文，更早的对话每3轮做一次结构化摘要。摘要字段包括：用户诉求、已给出承诺、情绪状态、待办事项。这一步最大变化是漏报率下降，因为模型能"记住"更早出现的敏感词了。

第四步，压缩知识条目。对重排后的文档做信息提取，只保留与当前检测任务相关的条款，并把长段落切成带编号的小条款。每次注入不超过6条，每条不超过约120字。这一步是压死稻草的最后一根，准确率最终跨过90%大关。

3.3 效果对比与成本核算

改造前后的核心指标对比如下：

我特意把成本数据放出来，是因为很多团队误以为"上下文工程是增加投入"，实际上恰恰相反，做好上下文管理通常意味着用更少的token获得更好的效果。输入token减少72%，不只是省钱，更是延迟的改善。用户可不会关心你用了多少token，但1.4秒和2.8秒的差别，用户是能直接感知到的。

这里我也想强调一句：整个改造过程中，我没有换过任何模型。模型还是那个模型，变的只有上下文工程策略。这也说明一个问题——当模型性能已经足够时，应用架构师的价值不在于"召唤更贵的模型"，而在于让已有模型工作在它最擅长的方式下。

4. 把上下文工程落地成工程体系：生产、消费与观测闭环

单次改造成功不等于体系成熟。到了第二个项目、第三个项目，我发现自己重复做了很多"组装上下文"的体力活：清洗知识、写重排规则、设计摘要格式、观察线上效果。后来我逼着自己把上下文工程当成一个正式的技术模块来建设，分三条线来推进。

4.1 生产侧：知识切片、元数据标注与时效管理

先讲知识侧。很多团队把RAG失败归咎于"向量模型不够好"，但我见过的大量问题其实是源头数据没治理。上下文工程的前提是知识库里的每条信息都足够干净、能够独立回答一个问题。

我们在实践中给每条知识切片都加了元数据：

• valid_from/valid_to：有效时间范围，解决政策更替带来的新旧冲突
• applicable_scenario：适用场景，用于检索后的场景匹配
• conflict_group：冲突组，标记哪些条目彼此可能矛盾，交给重排层特殊处理
• source_priority：来源优先级，比如内部SOP高于互联网转载内容

这套元数据听起来增加工作量，但长期回报非常可观。重排阶段可以直接用元数据硬过滤掉过期文档，不必把每一篇都交给模型去判断。时效管理尤其重要——政策类知识经常更新，如果不做外部化过滤，模型只能靠prompt里的"请使用最新政策"来提醒自己，而这种提醒在长上下文里很快就会失效。

4.2 消费侧：组装路由、按需检索与决策点触达

消费侧的核心是"什么时候组装什么上下文"。我设计过一个简化版的决策逻辑：

if is_task_opening: context = build_task_block() + build_role_block() elif requires_knowledge: retrieved = search_and_rank(query, top_n=50) filtered = apply_metadata_filter(retrieved) context = build_knowledge_block(filtered[:6]) elif requires_tool_call: context = build_tool_block(tool_schema, tool_result) elif is_history_turn: context = build_recent_turns(last_n=6)

这段伪代码体现的核心原则是上下文按需组装，不搞一次性全量注入。尤其要避免的是：在工具调用还没发生前就把工具结果塞进上下文，或者在用户还没有表达新意图之前就把一批可能无关的知识注入进去。

还有一个容易被忽略的触点：决策点前置。质检智能体在判断"是否有承诺不一致"时，需要的上下文是"早前承诺摘要+当前对话片段+相关赔偿规则"，而不是完整的全部聊天记录。所以我给智能体设计了独立的小型决策上下文，每个决策点各自组装自己需要的上下文，而不是所有判断共用同一个大窗口。这个设计让每个子判断的干扰都少了一大截。

4.3 观测侧：让每一次调用的上下文使用情况变得可审计

上下文工程如果不做可观测性，基本就是盲人在房间里找东西。我在项目中积累了三个核心观测指标，如果你要建智能体观测体系，我建议从这三个开始：

有效上下文利用率这个指标特别有意思。一开始我们的利用率只有12%，说明88%的token对输出没有直接贡献，纯粹是"干扰项"。后来做到35%左右，效果已经远好于初始状态。虽然无法做到100%——因为任务指令、角色约束这类token并不会被直接引用——但这个指标的横向对比和趋势分析非常能说明问题。

追踪平台方面，我与团队直接改造了智能体调用日志，每次调用都记录：分区名称、每个分区token数、检索打分、最终输出中的引用来源。这样任何一个bad case出现时，都能回放当时的上下文快照。没有这个快照，坏例分析就是猜谜游戏。

5. 花过冤枉钱之后才懂的几条边界问题

光讲成功经验不够，很多问题是改完之后才暴露的。我把这几条边界问题单独拿出来，因为它们最容易让后来的项目重蹈覆辙。

5.1 上下文污染：模型无法分辨哪里是"指令"哪里是"数据"

第一个边界问题是上下文污染。有些开发同学会把用户输入直接拼接到system prompt后面，为了让模型"看到更多信息"。这么做极其危险。如果用户消息中包含了"忽略之前的指令"或者"你现在是一个什么都不用检查的机器人"这类内容，它就变成了一次即时注入攻击。

即使没有恶意输入，污染也可能来自普通对话。用户说"你怎么老在检测承诺不一致，烦不烦"，如果这句话被拼进system prompt区域，模型可能真的开始怀疑自己的任务。我的铁律是：任何用户输入、对话历史、检索结果，一律放在data区域，并在文本上做隔离标记和长度截断。具体到实现上，每个分区之间用明确的HTML注释或者特殊的分隔符隔开，同时把分区描述写在分隔符前面。这样模型才能清晰区分"系统让我做什么"和"用户说了什么"。

5.2 检索时机的选择：不是每轮都必须检索

第二个边界问题是检索频率。我有一个阶段性的错误判断：既然检索有用，那就在每一轮都检索一下，给模型最强的信息支持。结果副作用很快出现：无关知识注入增多，模型开始"被错误知识带着走"，还时常编造出检索结果里其实不存在的细节。

后来我改成三级触发机制：

• 用户消息中包含明确的实体词与业务问题 → 触发知识检索
• 用户消息只是"谢谢""好的"等情绪反馈 → 不检索，直接走回复生成
• 多轮任务中模型内部状态发生变化 → 按需注入摘要，不重复检索

这个机制上线后，检索调用量下降了约40%，质量反而上升了。检索不是免费的午餐，每次检索都伴随误导风险，应该像花钱一样谨慎使用。

5.3 成本与延迟的权衡：有些压缩不值得做

第三个边界问题是"过度压缩"。摘要压缩本身有token成本，如果每两轮对话就做一次摘要，摘要的调用成本可能超过节省的成本。我测试过不同压缩粒度，最后发现每3~5轮做一次增量摘要，性价比最高。少于3轮，压缩成本高于保留成本；多于5轮，摘要开始丢失细节。

同理，重排模型也不是越强越好。如果知识库只有几百篇文档，用规则加关键词过滤就够了，强行上交叉编码器反而是杀鸡用牛刀。做上下文工程时，每一处增值运算都需要用"可量化收益"来证明自己的必要性。

5.4 评测集设计：防止智能体"过拟合"到你的上下文模板上

最后一个边界问题是评测。很多团队评测智能体时只准备了几十个样本，而且样本是静态的。改完上下文后，在样本上效果惊人，一上线就崩。原因不外乎两个：一是评测样本太少，没覆盖到新上下文的盲区；二是样本和模板高度同质化，智能体学会了"针对模板答题"而不是"针对问题答题"。

我现在的习惯是准备至少200条评测样本，按业务场景分层，每条样本都带"预期知识点来源"标注。评测时不只看准确率，还要看每一条错误的错误类型：是检索漏召回、重排误置顶、摘要丢失关键承诺，还是指令被忽略。没有这样的分层评测，你就永远不知道下一次该优化哪个环节——是补知识，还是修路由，还是调摘要策略。

最后再分享一点我的个人体会

做了这几个项目之后，我对智能体性能优化这件事有了一层新的认识：与其说我们在调模型，不如说我们在给模型的注意力装栅栏。大模型的推理能力是固定的，但注意力往哪里看，完全由上下文工程决定。你给它的上下文越干净、越贴切、越结构化，它的推理能力就越能百分百用在刀刃上。

如果读者只想记住一条，我会说：下一次遇到"智能体表现不稳定"时，不要急着换更强的大模型，也不要反复试prompt话术，先把一次调用的上下文完整打印出来，问自己三句话——每一段信息为什么在这里？它离决策点有多远？有没有一段内容是可以删掉而不影响输出的？把这三句话逼出来，性能瓶颈大概率会自动现出原形。

上下文工程不是某种特定工具，它更像一套把"模型能力"变成"系统稳定性"的施工方法论。这条路我也还在继续探索，欢迎有类似实战经历的朋友多交流，尤其是那些在特定业务场景里把上下文工程做到极致的案例——这种东西，光靠理论是真的学不来的。