国庆七日谈 | 上下文窗口越来越长，Agent为什么还是不懂你的业务？

作者 / 来源：中智凯灵 / AiDD

【篇首语｜企业 AI，正在从“会用”走向“能交付” 】

“国庆七日谈”不追逐短期工具热度，而是每天回答一个企业 AI 进入生产必须面对的工程问题：从需求契约出发，依次讨论业务上下文、多 Agent 协作、运行底座、质量验证、控制边界与组织规模化。我们会把AiDD2026上海、北京、成都三站的相关实践放在同一条链路上，寻找那些正在从个别案例沉淀为共同方法的答案。

第二日，把视线转向每一次执行背后的业务上下文：当上下文窗口越来越长，Agent 为什么还是不懂你的业务？

国庆七日谈·第二日｜业务上下文

▼

把产品手册、历史工单、会议纪要、数据库说明和几十轮对话一起交给 Agent，它就会更懂业务吗？

很多时候，结果恰好相反。

材料越多，真正相关的事实越容易被淹没；文档越全，过期版本、冲突口径和权限边界越难识别；窗口越长，Agent 越可能在大量“看似相关”的内容里选择了错误依据。它也许能复述一份制度，却不知道这条制度是否仍然有效；能找到一段故障说明，却无法判断它和眼前告警之间的因果关系；能记住上次对话，却未必知道上次结论应不应该带进这次任务。

2026 年 AiDD 上海站、北京站和成都站的三场分享，从记忆、多源实时数据和知识图谱三个方向揭示了同一个事实：上下文不是一堆被塞进窗口的文字，而是一套持续选择、组织、验证和更新业务事实的工程系统。

窗口长度解决“装得下”，上下文工程解决的是另外四个问题：什么时候拿什么、从哪里拿、以什么结构交给谁，以及用完之后怎样留下新的事实。

长窗口解决的是容量，不是业务理解

大模型的上下文窗口持续增长，给复杂任务带来了更大的信息容纳空间。但“能读更多”与“理解正确”之间，并没有自动的等号。

企业里的业务事实分散在订单、工单、日志、设备事件、数据库、SaaS、API 和人的经验中。它们有不同的更新时间、不同的可信等级，也有不同的权限边界。同一个“客户状态”，可能在 CRM、交易系统和售后工单里分别存在；同一个“净收入”，也可能因为口径和时间范围不同得出不同结果。

如果只把这些内容复制进一个更大的窗口，Agent 面对的仍然是未经整理的信息堆。它缺少的不是字符容量，而是判断依据：哪一份是当前版本，哪些对象彼此关联，哪条规则适用于这个场景，哪个来源可以被信任。

这就是为什么企业 Agent 的竞争，正在从“能接多少 Token”转向“能不能持续获得正确上下文”。真正有价值的上下文，不是越多越好，而是与当前任务相关、来源可追踪、语义一致、状态新鲜，并且允许被下一步工具或流程直接消费。

第一层：从“记住对话”到“管理任务记忆”

在 AiDD 上海站，记忆张量应用算法负责人唐波在《从记住到学会：MemOS记忆工程的技术实践与系统思考》中区分了两类完全不同的记忆。

对话记忆主要回答“前面说过什么”，帮助模型保持表达连贯、延续用户偏好。执行型 Agent 的记忆则要回答“做过什么、为什么这样做、哪里失败、如何纠正”。它记录的不只是问答文本，还包括任务目标、工具调用、执行结果、反馈、反思和修复路径。

图 1：唐波《从记住到学会：MemOS记忆工程的技术实践与系统思考》：对话记忆与 Agent 记忆面对的是两类不同对象

这一区别很重要。把所有历史对话原样拼回窗口，只会不断增加噪声。真正可用的任务记忆，需要先经过抽取、去重、组织和分层，再根据当前任务按需召回。

唐波的课件进一步把执行时的记忆调用分成三个层次：Skill 提供成熟的执行骨架，Trace 和 Episode 补充历史任务的动作与反馈，场域认知帮助 Agent 理解环境规律和约束。不同任务调用不同层次，而不是把全部历史一次性塞回窗口。

图 2：唐波《从记住到学会：MemOS记忆工程的技术实践与系统思考》：Skill、Trace/Episode 与场域认知构成分层记忆调用

记忆还不能停留在“查到历史”。在任务完成后，执行轨迹、成功或失败的反馈、环境约束和修复方法，还要被加工成新的长期资产。唐波材料中的 Reflect2Evolve，正是把一次任务拆成证据、价值判断、经验片段和可复用策略，再让下一次执行从这些资产中检索。

图 3：唐波《从记住到学会：MemOS记忆工程的技术实践与系统思考》：任务执行与反馈被加工为可检索、可复用的长期能力

因此，记忆工程的核心不是“让 Agent 永远不忘”，而是让它该记的留下、该忘的退出、需要时找得到、出错后会修正。如果没有这套治理，更长的历史只会把旧答案、错误判断和过期状态一起带进新任务。

第二层：从“导入资料”到“持续供给当下事实”

记忆解决了历史经验如何留下，但企业业务还在持续发生。订单在变化、设备在告警、客户在行动、工单在流转。Agent 如果只读取每天同步一次的资料库，看到的可能不是业务现场，而是一个已经过期的快照。

在 AiDD 北京站《Agent 开发范式演进：简化多源实时上下文构建》中，阿里云高级技术专家、EventBridge/EventHouse 负责人沈林提出了一个很实用的投资判断：模型和 Runtime 会持续变化，真正能被下一次模型升级放大的，是企业自己沉淀的业务事实、对象关系、统一语义、流程规则和行业知识。

图 4：沈林《Agent 开发范式演进：简化多源实时上下文构建》：模型持续升级，企业需要同步沉淀业务上下文资产

业务上下文还必须扎根于持续运行的数据。这并不等于把所有实时数据直接推给模型。订单、日志、设备事件和外部 API 的格式各不相同，跨系统对象也未必使用同一套命名。如果数据到了，但 Schema、语义、血缘、新鲜度和访问策略没有一起到达，Agent 仍会出现四种典型问题：找不到、看不懂、不敢用、用不准。

图 5：沈林《Agent 开发范式演进：简化多源实时上下文构建》：数据已经到达，不等于关于数据的上下文也一起到达

这里最关键的变化，是把“调用时临时猜测”改成“调用前持续沉淀认知”。系统需要知道字段代表什么、对象之间怎样关联、数据何时更新、经过哪些转换、谁对业务口径负责。Agent 得到的不是一张孤立表，而是一份带着解释、版本、关系和责任人的工作上下文。

而且，业务语义不能由模型自己宣布正确。沈林的课件把语义认证中的组织责任分成定义、关系、边界和发布四类：模型可以根据元数据、代表值和历史查询提出候选，业务专家仍要决定口径是否成立、关系是否会重复计数、适用范围在哪里、哪个版本可以发布。

图 6：沈林《Agent 开发范式演进：简化多源实时上下文构建》：定义、关系、边界和发布四类业务责任需要被明确认证

上下文供给还要形成反馈闭环。真实问题、生成过程、工具调用和最终结果需要被记录；错误被归因后，语义定义、检索规则或评测样本才能修订，并在回归验证后重新上线。

这意味着企业上下文不是一次知识整理项目，而是一项长期运行能力。只要业务继续变化，上下文就要继续发现、更新、认证和淘汰。

第三层：从“搜到相似文档”到“找到关系与路径”

即使记忆能够管理、实时数据能够供给，Agent 仍可能在复杂业务里失去方向。原因是很多问题的答案并不在某一段文字里，而藏在多个对象之间的关系中。

在 AiDD 成都站《面向云产品诊断的 RAG 与知识图谱融合实践》中，阿里云数据库技术专家李佳骏给出了一个典型场景：云产品故障往往横跨多个产品、组件、指标和操作步骤。纯 RAG 可以找到与问题相似的文档片段，却未必能回答“这个症状由什么引起、下一步验证什么、哪条路径已经排除”。

李佳骏把 RAG、知识图谱和 Ontology 分成三个互补层次：RAG 负责找到相关内容，知识图谱负责理清实体之间的关系，Ontology 负责统一概念和约束。三者组合后，上下文才不只是“几段相似文字”，而是包含对象、关系、因果和适用边界的结构。

图 7：李佳骏《面向云产品诊断的 RAG 与知识图谱融合实践》：RAG、知识图谱与 Ontology 分别承担检索、关系和语义约束

关系化上下文的价值，在于它可以支持路径。李佳骏展示的跨产品诊断案例，需要同时穿过线下 IDC、IPSec VPN、VPC 和 RDS 等多个系统。Agent 不能只找一份“相似故障文档”，而要沿着候选根因逐支验证：先排除常见原因，再核查网络连通、路由与安全策略，最后把确认和排除的证据串成完整路径。

图 8：李佳骏《面向云产品诊断的 RAG 与知识图谱融合实践》：跨产品问题需要沿候选根因逐步验证和排除

但图谱也不是建完就不会过期。新的故障会出现，旧知识会失效，某条因果关系也可能被真实执行证伪。李佳骏的课件用 DRAFT、CANDIDATE、VALIDATED、DEPRECATED 管理知识生命周期：新知识先成为候选，经过评测或人工门禁后才能转成已验证状态；过期知识也要确认后退出，而不是让自动生成内容直接污染正式知识库。

图 9：李佳骏《面向云产品诊断的 RAG 与知识图谱融合实践》：知识通过候选、验证与废弃状态持续治理

于是，上下文从静态资料变成了一张正在工作的认知网络：它不仅告诉 Agent “有哪些知识”，还告诉它“这些知识怎样相互关联、当前任务应该沿哪条路径前进、哪一步需要真实证据”。

上下文工程，要完成四个最小闭环

把三站分享放在一起，可以看到企业上下文至少需要四个连续动作。

第一，选择。围绕当前任务决定需要哪些业务事实、历史记忆和实时状态，而不是把所有资料都推给模型。选择机制要考虑相关性、新鲜度、权限和 Token 预算。

第二，组织。把零散内容转成 Agent 能消费的结构：术语和 Schema 保持一致，实体与关系可以追踪，任务过程和工具结果有明确边界。重要的不是文档放在哪里，而是信息进入任务时以什么形态出现。

第三，验证。给上下文保留来源、版本、血缘和责任人。业务口径不能由模型自己宣布正确；关键关系、权限边界和执行结果需要规则、专家或真实环境确认。

第四，更新。把任务轨迹、用户反馈、错误归因和新业务事实回写到记忆、语义层、图谱和评测样本中。旧信息需要淘汰，冲突需要合并，经过验证的路径要成为下一次任务的起点。

企业不必一开始就建设一套庞大的“上下文平台”。可以先选一个高频、跨系统、结果可验证的真实任务，完成一条最小链路：接入两三类必要数据，定义关键业务对象与口径，保留来源和更新时间，让 Agent 在真实工具上执行，再把错误与修复方法回写。

这个最小闭环一旦跑通，团队才有条件讨论扩展到更多 Agent。否则，增加 Agent 数量只是让更多执行者同时读取同一堆混乱信息。

结语：真正稀缺的不是窗口，而是上下文供给能力

上下文窗口会继续变长，模型检索和推理能力也会继续进步。但企业不能把“理解业务”的责任全部交给模型。

业务事实从哪里来、是否最新、术语如何统一、关系怎样表达、权限由谁确认、错误怎样回写，这些问题都属于企业自己的工程责任。模型可以在给定上下文中推理，却无法凭空替企业建立一套长期有效的业务事实系统。

所以，Agent 不懂业务，往往不是因为它读得还不够多，而是因为企业尚未把业务组织成一份可工作的上下文。记忆让经验不随会话消失，实时数据让 Agent 看见正在发生的事，RAG 与知识图谱让它从片段走向关系，反馈闭环让这套认知持续更新。

当这四件事连起来，企业拥有的就不再是一个“更大的提示词”，而是一套可以被不同模型、不同 Agent 和不同任务持续调用的上下文供给能力。

国庆七日谈·第三日，我们继续讨论：多 Agent 不是多开几个对话框，协作为什么比智能更难？

 主要参考演讲

这么好的内容，你不转一下吗

转发本篇文章至朋友圈，截图私信后台可免费领取AiDD演讲PPT下载链接！

下一站

第11届AiDD AI+研发数字峰会  

11.20‑21 · 深圳