企业官网建设流程全解析

1. 从多智能体“翻车现场”说起：上下文工程到底是什么

先讲一个我亲眼见过的场景。某个系统里跑了三个智能体，分别负责问答、推荐和订单查询。单看任何一个，表现都还行。但只要丢进来一个稍微复杂的用户问题，比如“我想买个适合跑步用的耳机，顺便查一下昨天那单什么时候到”，三个智能体就开始互相打架：问答Agent把耳机推荐给做了，推荐Agent又把订单信息答错了，订单Agent因为拿到了一堆不相关的上下文，直接返回了一串不知所云的默认话术。

这个问题的根源，不在模型能力，而在上下文。

你给每个Agent喂了什么上下文，它就基于什么做判断。喂错了，喂多了，喂串了，Agent就会一本正经地胡说八道。传统的Prompt Engineering解决的是“怎么把指令写清楚”，但当你有多个Agent、多轮任务、多个信息源的时候，真正要解决的是另一件事：在每一轮交互中，只把当前任务需要的信息，以正确的结构和顺序，放到模型的上下文窗口里。这就是上下文工程（Context Engineering）。

上下文工程不是某个具体技术，而是一整套关于“如何设计、构造、管理、审计模型上下文”的方法论。它包含三个核心能力：预算管理（控制上下文窗口的使用）、规划结构（决定信息的层次和优先级）、动态装配（在正确的时间注入正确的信息）。它解决的是多智能体协作中三个最致命的问题：上下文污染、Token浪费、跨Agent信息错乱。

这篇文章不打算讲太多理论。我会从实际项目出发，先解释上下文工程和多智能体之间的关系，再给出可以直接落地的操作步骤、参数建议和踩坑记录。适合正在做多智能体系统的开发者、算法工程师，也适合那些已经发现“模型能力够了但系统总是不稳定”的团队参考。

先记住一个判断标准：如果你的多智能体系统经常出现答非所问、上下文串台、日志里Token消耗高得离谱，那大概率不是模型的问题，而是上下文工程没做到位。

1.1 一个典型的失败案例拆解

上面提到的那个三Agent系统，我用了一次完整的请求链路来做诊断。用户问的是跑步耳机和订单状态，这两个问题分属两个垂直业务域。原始方案把所有历史对话、用户画像、商品库摘要、订单库摘要全部拼在一个长上下文里，同时喂给三个Agent。从日志看，一次请求消耗了近8000个Token，其中真正和这次问题相关的有效上下文不到1200个。

更麻烦的是信息干扰。订单Agent读到了耳机相关的商品描述，就把“骨传导”“降噪”这些词当成了订单特征，开始一本正经地编造物流信息。推荐Agent读到了订单数据里的发货地址，就开始猜测用户所在城市的跑步路线。这些错误又被下一个环节当成“事实”继续使用，错误就像滚雪球一样在Agent之间传递。

这个问题就是典型的上下文规划缺失：所有信息无差别供给，所有Agent共享同一份上下文，没有隔离，没有优先级，没有淘汰机制。后面我重构这个系统时做的第一件事，就是把“一份上下文喂给所有人”改成“每个Agent单独装配自己的上下文”。效果立竿见影，上下文消耗下降了60%，错误率大幅降低。

1.2 上下文工程和Prompt Engineering到底有什么不同

很多人把上下文工程当成Prompt Engineering的进阶版，这个理解不够准确。我把两者的区别用一个表格说清楚：

这么说吧，Prompt Engineering解决的是“让模型听懂人话”，Context Engineering解决的是“让模型在复杂场景下一直听到对的、有用的、没有干扰的话”。在多智能体系统里，Prompt写的漂亮只是基本功，真正决定系统上限的，是你怎么管理每个Agent看到的上下文。

2. 上下文工程的核心要素：预算、结构与动态装配

上下文工程听起来玄乎，落到实操层面就三件事：先算账，再立规矩，最后按需装配。

2.1 Token预算：先算账再开工

很多开发者在做多智能体系统时，对上下文开销完全没有概念。我见过一个系统，每个Agent的Prompt里塞了8轮历史对话、20条Few-shot示例、一份完整的产品手册，再加一个实时检索结果。单次请求Token数轻松过万。更严重的是，上下文窗口是有限资源，一旦超出，系统就只能做截断。而多数截断策略都是“砍掉中间，保留头和尾”，这会导致Agent丢失关键任务信息，输出质量直线下降。

我的建议是，在每个Agent上线前，先做一张Token预算表。以我常用的文本模型为例，上下文窗口如果是32K Token，那我会按以下比例分配：

这只是一个参考模板，不同场景要按实际情况调整。但核心原则是通用的：每个Agent必须有明确的Token预算上限，预算分配要固定，防止某个环节无限制吞噬上下文。如果某个环节要用更多Token，就必须从其他环节挪预算，而不是无脑扩容。

2.2 上下文规划：明确“谁看什么”

预算定完之后，下一步是规划信息结构。多智能体系统里常见的错误是把所有Agent当成“全知全能”的节点，让每个Agent都接触所有信息。正确做法是给每个Agent定义它的“信息边界”。

我在实际项目中把上下文规划分成三个层次：

全局白板：存放所有Agent都可能需要的基础信息，比如用户ID、会话ID、当前业务阶段、全局约束。这部分上下文对所有人可见，但必须严格控制长度，一般建议不超过500个Token。

任务卡：存放当前任务专属的信息。比如订单查询任务，任务卡只包含订单号、订单状态、物流轨迹。任务卡绑定到具体Agent，其他Agent不会读取。

角色档案：存放某个Agent的专属知识、行为准则、输出格式约束。这部分信息和业务数据分离，保证Agent的角色设定不被动态内容干扰。

这套分层设计最直接的好处是信息隔离。订单Agent只看订单数据，推荐Agent只看商品和用户偏好数据，谁都不会拿到自己不该看到的信息。我改造上面的三Agent系统时，就是用这个结构重新规划了每个Agent的上下文。订单Agent的上下文从8000Token降到了2000Token左右，而且错误率明显下降，因为它不再被无关的商品描述干扰。

2.3 动态装配：按需拼接上下文

静态规划解决的是“什么信息归谁”，动态装配解决的是“每个时刻注入什么信息”。这里的关键是时序和条件判断。

我在实操中总结了一套“三段式装配法”：

第一段是基础段。包含系统指令、角色档案、全局白板。这段内容在会话开始时一次性加载，通常保持不变。

第二段是检索段。系统根据当前输入，动态检索相关信息并注入。这个环节最核心的是检索质量：上下文工程不只是“检索到相关内容”，还要对检索结果做排序、过滤、去重。我经常看到很多团队直接把向量检索结果全部塞进上下文，结果相关度低的内容占了大片Token，反而把真正关键的信息挤掉了。我的做法是设置相似度阈值，低于阈值的检索结果直接丢弃，同时限制最多返回数量。

第三段是任务段。包含当前轮次用户输入、任务执行状态、上一步Agent的输出摘要。任务段是最容易失控的部分，因为多智能体系统里，每轮交互都会产生大量中间结果。如果全部保留，上下文很快会被撑爆。我的做法是只保留“上一步的结论摘要”，不保留“上一步的全部推理过程”。

3. 实操案例：模拟项目X的多Agent客服系统上下文装配流程

这个案例来自一个内部项目，代号模拟项目X。它不是一个理论模型，而是一个真实上线、真实跑了几个月的客服系统，业务场景就是前文提到的那个翻车系统。我拿这个项目说明上下文工程的具体落地过程。

3.1 系统架构与历史问题

模拟项目X共部署了四个Agent：意图识别Agent、售后客服Agent、物流查询Agent、质检Agent。用户发言先经过意图识别Agent，再分发到对应业务Agent。如下图所示意的交互链路（这里不用流程图，我用文字描述）：

用户输入 → 意图识别Agent判断意图 → 路由到售后或物流Agent → 业务Agent生成回复 → 质检Agent检查回复是否合规 → 返回给用户。

这个链路看似清晰，但上线初期问题非常多。最典型的是用户连续追问导致上下文爆炸：比如用户先问“耳机怎么样”，再问“那我的耳机订单呢”，又追问“物流到哪了”，最后加一句“顺便推荐个充电宝”。每一步都会把历史对话完整传给下一个Agent，并且每个Agent都会重跑一次检索，Token消耗迅速翻倍。

3.2 可复用的上下文装配流程

重构后的系统遵循五步装配流程，每一步都有明确目的：

第一步：初始化基础上下文。每个Agent构建自己的角色档案，注入全局白板信息，比如用户ID、会话ID、业务线标识、可用工具列表。这一步在会话建立时执行一次，不随用户输入变化。

第二步：意图识别与任务拆分。意图识别Agent先判断用户本次输入涉及几个业务意图。上面的例子会被拆成“耳机咨询”“订单查询”“充电宝推荐”三个子任务，每个子任务维护独立的上下文片段。

第三步：按意图检索边界信息。每个子任务只检索自己的业务域。耳机咨询只检索商品知识库，订单查询只检索订单接口，充电宝推荐只检索商品池。检索结果按相似度排序后，取Top-K注入，且K值由预算决定。

第四步：压缩历史上下文。系统不用原始历史对话，而是用历史摘要替换。摘要由一个独立的“总结Agent”在每轮结束时生成，格式是结构化JSON：{"已解决问题": "...", "当前任务": "...", "用户偏好": "...", "未解决问题": "..."}。下一轮Agent读到的不是原始对话，而是这份摘要。

第五步：输出后校验。质检Agent负责检查最终回复。这个Agent的上下文设计很特别：它不看完整上下文，只看三种信息——用户原始问题摘要、业务Agent的最终输出、质检规则清单。上下文越精简，质检Agent反而越专注，不会因为读到太多背景信息而被干扰。

3.3 参数配置和实测数据

重构前后的上下文Token用量和数据表现对比如下：

另外我给每个Agent单独配置了检索参数。意图识别Agent的相似度阈值设为0.65，返回Top-3；售后客服Agent的阈值设为0.72，返回Top-5；物流查询Agent比较特殊，因为订单号是强结构化信息，所以不走向量检索，直接用精确匹配。很多人容易忽略这一点，不是所有信息都该走语义检索。结构化信息用结构化查询，准确率和效率都更高。

这里还要强调一个容易忽略的细节：动态装配完成后，要对最终上下文做一次“完整性校验”。常见的做法是检查关键字段是否存在，比如订单查询上下文里必须有order_id，如果没有就直接终止处理，而不是让模型硬猜。这个校验能拦截掉很多看似聪明、实则瞎编的回答。

4. 多Agent场景下的记忆设计：为什么“记忆”不等于“上下文”

做多智能体系统时，你会发现“记忆”和“上下文”这两个概念经常被混着说。但正式设计时，它们必须分开。

上下文是“当前窗口里模型能看到的所有内容”，记忆是“跨会话、跨任务需要保留并能够被检索的结构化信息”。上下文是记忆的“投影”，记忆本身存在外部存储里，只有被检索出来并注入窗口时，才成为上下文。

4.1 三层记忆架构

我在模拟项目X里把记忆分成了三层：

工作记忆：只存在于当前会话内，保存本轮任务的状态信息。比如“用户刚才问了耳机降噪效果，正在挑选两款耳机”，放在Redis里，会话结束或超时后清空。它的特点是生命周期短、访问频繁。

长期记忆：跨会话保存，使用向量数据库存储。保存的是用户偏好、历史投诉记录、历史购买行为等。它的检索方式是语义相似度检索，和当前用户输入的嵌入向量做比对，返回相似度最高的若干条记忆片段。

超长期记忆：保存业务规则、产品知识、合规约束。这部分内容通常更新频率低、权威性高，不适合用向量检索，更适合用规则引擎或知识图谱来查询。

这套三层架构的核心逻辑是：不同生命周期、不同检索方式的信息，必须分开存储、分开管理。如果全部塞进一个向量数据库，会导致“用户随口说的一句话”和“官方业务规则”被当成同等级的记忆来检索，权重完全失衡。

4.2 记忆的读写接口设计

记忆层不能只是“存进去、查出来”，还需要设计清晰的接口语义。我在项目中定义了四个基本操作：

• write_memory(key, content, ttl, importance)：写入记忆，设置过期时间和重要性权重。
• read_memory(query, filters, top_k)：读取记忆，支持按业务域过滤。
• update_memory(key, content)：更新已有记忆，通常用于修正错误信息。
• delete_memory(key)：删除记忆，一般用于移除过时或错误的内容。

这里有一个被很多人忽略的设计点：记忆写入前要做“重要性校验”。不是所有对话内容都值得写入长期记忆。比如用户说“嗯”“好的”“谢谢”，这些闭环话术没有任何记忆价值。我在项目里给每轮对话计算一个“记忆价值分数”，分数低于阈值就直接丢弃。这个机制大大减少了向量数据库的无效写入和检索噪声。

4.3 记忆淘汰与冲突解决

记忆系统最容易犯的错是“只进不出”。时间久了，向量库里塞满了过时信息，检索结果越来越不准确。我必须定期做两件事：

第一是过期清除。给记忆打上创建时间戳和过期时间戳，到期自动归档到冷存储，不再参与常规检索。

第二是冲突消解。当用户新说的话和历史记忆冲突时，系统要以新信息为准。比如用户半年内多次咨询耳机，但最近一次说“我又不跑步了，想换个办公耳机”，那系统就不能再把“跑步爱好者”这个标签当作用户偏好。我的做法是给每条用户偏好记忆附带一个“置信度”字段，新信息覆盖旧信息时，旧记录的置信度自动衰减。

记忆层做完之后，上下文工程的数据供给就闭环了：不是找一堆数据堆给模型看，而是从三层记忆里精准检索出“当前真正需要的那几条”，带着明确的时效性和优先级，注入到Agent的上下文窗口中。

5. 多Agent上下文工程中的常见坑：问题与排查实录

上下文工程做起来，踩坑是必然的。这里我整理了几个高频问题，附上排查思路和解决办法，都是可以直接抄作业的。

5.1 Agent之间上下文污染

这是多智能体系统第一大坑。表现形式是Agent A的输出被错误地当成Agent B的输入，或者共享上下文里混入了本不该出现的业务数据。

我的经验是，排查上下文污染最有效的手段是“输入快照记录”。每次调用模型前，把组装好的上下文完整写入日志，出问题时直接检查快照内容，一眼就能看出是哪个环节混入了不该有的信息。这个机制虽然会额外消耗存储，但比猜测高效得多。

5.2 Token被无效内容占满

一个常见场景是：上下文窗口明明很大，但模型表现却很笨。打开日志一看，几千个Token里全是重复的检索结果、冗余的历史对话、互相矛盾的旧信息。

这个问题的根源通常有两个。一是检索环节没有过滤，把所有相似结果一股脑塞进上下文。二是历史对话没有压缩，原始对话越长，占用的Token越多，真正用于任务分析的空间越少。

我的建议很直接：给每个上下文环节设硬上限，超了就截断或丢弃，而不是“尽可能多塞一点”。另外，对历史对话一定要用“摘要替代法”。我之前测试过，5轮原始对话大约占用1500个Token，换成结构化摘要后只需要400个Token，而且模型对摘要的利用效果反而更好，因为信息密度更高、噪声更少。

5.3 幻觉被多级放大

在单Agent场景，幻觉只影响一个输出。在多Agent场景，幻觉会被逐级传递。比如物流Agent猜测了一个不存在的发货时间，质检Agent基于这个错误时间生成了“预计明天到达”的回复，用户收到错误信息后投诉，售后Agent在复盘时又把“物流承诺明天到达”当成了事实记录。

这个问题的核心是：中间环节的输出既没有被验证，也没有被标记信任度。

解决的思路有三个。第一，关键事实必须经过工具调用验证，不允许Agent“凭记忆回答”。比如查询发货时间，必须调用物流接口拿到数据，模型不能自己编。第二，Agent输出必须附带置信度字段，低于阈值的输出需要二次验证或人工介入。第三，链路中的下游Agent只接受结构化任务结果，不接受自由文本推测。

5.4 上下文窗口截断导致行为突变

很多团队上线后才发现，同一个Agent，短对话时表现正常，长对话后突然变得“像个傻子”。大概率是因为上下文超过了窗口限制，自动截断把关键信息给截掉了。

排查方法是在日志里记录每次请求的Token数和截断策略。如果发现“截断位置恰好位于检索结果附近”，那说明预算分配不合理。我的做法是给系统指令和高优先级信息设置“保护区间”，即组装上下文时，把最重要的内容放在窗口头部或尾部，中间位置留给可牺牲的辅助信息。这利用了主流模型对头和尾的记忆更强、对中间注意力较弱的特点。

5.5 工具选型和排查建议

上下文工程对基础设施的依赖比一般人想象中高。我整理过一个最小工具清单供参考：

• 可观测性：必须能记录每次模型调用的完整上下文快照和Token用量，否则无法排查问题。
• 向量检索：需要一个支持过滤条件和相似度阈值的向量数据库。
• 缓存层：高频使用的上下文片段，比如系统指令、角色档案，可以做缓存，减少重复消耗。
• 摘要服务：独立的历史对话摘要任务，建议单独部署，避免影响主链路响应速度。

6. 上下文工程继续深化的方向：评估与迭代

到这里，上下文工程的基本方法已经完整了：预算管理、结构规划、动态装配、记忆分层、问题排查。但最后我想再聊一个常被忽略的环节——上下文评估。

没有评估，就没有迭代。大部分团队做上下文工程是靠“感觉”：模型回答变好了就继续，变差了就调一调。但多智能体系统涉及多跳任务，评价“好和坏”很难凭直觉判断。我给一套轻量级的评估思路：

• 上下文精简率：重构前后Token用量的对比，衡量信息密度是否提升。
• 单Agent任务完成率：每个Agent独立完成其目标任务的比率。
• 跨Agent一致性：上下游Agent之间传递的信息是否一致，是否有错误信息传播。
• 用户侧无效回复率：最终输出的回复中，被用户认为“文不对题”的比例。

这些指标不需要一次性全部上线，先选一两个核心指标跑几周，再根据数据调整上下文结构，效果远好过无依据的频繁改动。

最后分享一个我在实践中的小技巧：每次修改上下文结构后，保留一份旧版本的完整快照。不要只在线上改完就跑，因为你很可能需要回头对比“到底是哪个改动让效果变好了”。上下文工程是一个持续迭代的过程，不是一锤子买卖。把每次改动当作一次实验来对待，系统才会越来越稳。