从0到1搭建可落地的AI Agent与工作流(21):第21期|Agent上下文越长越蠢?用n8n搭动态组装器,Token省一半

从0到1搭建可落地的AI Agent与工作流｜第21期

Agent不是看得越多越聪明，上下文一长，它反而会「lost in the middle」。你的token账单每个月涨20%，但回答质量没提升？问题大概率出在上下文组装上。今天用n8n搭一个动态上下文包，让模型只看该看的。

本期你将完成

🗺 BUILD MAP · 本期构建路径

先看一个现象：同一个Agent，刚上线时挺好用，跑了一个月后，回复开始抓不住重点，token费用还一路涨。很多人第一反应是换模型，但问题往往不在模型，而在上下文。

企业级Agent的模型调用不是只送一条用户消息，它是一个动态构建的上下文包：系统指令、用户输入、历史对话、长期偏好、RAG结果、工具状态都可能被塞进去。塞得越多，模型不一定越聪明。

长上下文模型存在「lost in the middle」现象：关键信息如果放在中间，模型的利用能力会明显下降。更别说token成本随会话长度线性甚至指数增长。所以我们的目标很明确：用n8n搭一个动态上下文组装器，让每个请求的上下文既精简又相关。

你需要准备：一个可用的n8n实例，一个已接入的LLM节点，以及至少一个数据源（比如数据库存历史、RAG检索库、或模拟记忆）。本期只解决一个问题：如何动态组装并交付上下文包。

先定输入输出，后面才不会乱。工作流接收的输入是一个JSON对象，包含用户ID、会话ID和本次query。

示例输入：

{"user_id": "u123", "session_id": "s456", "query": "帮我看看上季度销售数据"}

输出是一个组装好的context_package，包含多个来源产生的上下文片段，并标记了来源和相关性分数。

示例输出：

{"system_instruction": "你是企业销售助手", "user_query": "帮我看看上季度销售数据", "history_summary": "上一轮用户问过本季度目标", "memory_items": ["用户偏好看图表"], "retrieved_docs": ["doc_id:123, score:0.87"], "tool_outputs": ["销售数据库已连接"]}

n8n工作流分成六个核心节点，每个节点职责单一，方便调试和替换。第一个是Webhook触发器，接收外部请求并返回响应。第二个是历史上下文节点，从缓存或数据库读取最近N轮对话，并做摘要而不是全量拼接。

第三个是长期记忆节点，根据用户ID提取偏好设置，注意记忆必须来自可审计的系统，而不是模型自己写的小作文。第四个是RAG检索节点，拿query去知识库检索，返回带分数的文档。第五个是工具状态节点，如果当前有正在执行的工具，把结果整理成结构化摘要。

第六个是核心的Function节点，也就是上下文组装器。它接收前面所有节点的输出，执行评分、过滤、去重、压缩，最终拼成context_package。最后是LLM调用节点，使用组装好的上下文生成回复。

这个设计的妙处是每个来源独立，任何一个来源挂了，不会拖垮整个流程，只需要在Function节点里设置兜底逻辑。

先配置历史上下文节点，使用n8n的Function节点或Code节点，从数据库取最近5轮对话，并用一个轻量模型生成摘要。摘要长度控制在150字以内，这样可以大幅减少token占用。

长期记忆节点直接用数据库查询，返回用户偏好列表。RAG检索节点使用n8n的原生Retrieval节点或者HTTP节点调用向量库，返回top 3文档，每个文档附带相关性分数。工具状态节点如果无工具在跑，输出空数组即可。

重点是Function节点的逻辑：先把所有候选上下文放进一个数组，每个元素带上来源标签和权重。然后按权重排序，动态截取满足token预算的内容。去重使用文本相似度阈值，压缩则对超长文本做摘要。最后输出context_package。

伪代码大致如下：

const budget = 3000; let candidates = [...history, ...memory, ...docs, ...tools]; candidates = scoreAndSort(candidates); candidates = dedupe(candidates); let output = assemble(candidates, budget); return output;

第一个正常用例：用户有历史对话，RAG返回2个文档，记忆有1条偏好。预期输出包含history_summary、memory_items、retrieved_docs，且总token在预算内。

第二个边界用例：历史对话特别长，比如有50轮，RAG返回空。预期输出：历史被压缩成摘要，RAG结果为空数组，不会报错。

第三个失败用例：模拟RAG服务超时或返回500。预期：Function节点捕获异常，跳过RAG部分，仍然组装其他来源并返回，同时记录错误日志。

错误日志定位：n8n的执行日志里，每个节点的输出和错误码都能看到。如果Function节点报错，先检查JSON解析是否失败；如果LLM节点返回异常，检查上下文是否超过了模型的context window。

重试与幂等：给HTTP节点和RAG节点设置Retry on Fail，重试次数3次，间隔指数退避。同时使用幂等键，防止同一请求被外部重试时重复执行。

权限与安全：只给工作流授予读取必要数据源的凭据，不要把数据库根账号给n8n。上下文内容如果包含敏感信息，禁止写入执行日志，可以在Function节点里对敏感字段做脱敏。

验收标准：在10个测试query上，Token使用减少至少30%，关键信息保留率超过95%，端到端响应时间不超过2秒。生产检查清单：已设置token预算、已配置重试、已脱敏日志、已做权限最小化、已设置监控告警。