【云栖观察】模型越来越强，为什么 Context 反而越来越值钱——云栖大会02
【云栖观察】模型越来越强，为什么 Context 反而越来越值钱——云栖大会02
这次在云栖大会，Qoder 现场有一句话大意是：
Model power is a commodity. Context is the asset.
注意这句话不是 Qoder 的官方 slogan，是现场分享中传达的方向性观点（厂商归纳，原话以厂商现场为准，不宜过度引申）。但它戳中了一个越来越普遍的趋势：模型越强、获取模型的门槛越低，一个 AI 产品真正稀缺的部分就越往上移动。对企业和复杂应用来说，这一层越来越像 Context。
上一篇「云栖观察」（云栖大会01）第三节已经把这层判断的方向点过一遍——Qoder 把代码仓库做成 Wiki、Memory 与 Knowledge Cards，QwenWork 强调 Enterprise Context，OpenSearch 强调长期记忆与上下文压缩，三家厂商在云栖都在往同一个方向收敛。本篇把 Context 单独拆开，看清楚它怎么从一次性 Prompt 附件，升级成 AI 系统的长期资产，又会带出哪些新的工程、治理与组织问题。
一、模型知道世界，却不知道”我们这里到底怎么做”
通用模型已经掌握大量公共知识，也能完成越来越复杂的推理。但企业真正想让它处理的事情，往往高度依赖局部信息。
一个 Coding Agent 需要知道当前仓库的架构、约定、历史 Bug、模块关系和发布流程。一个企业 Agent 需要知道组织结构、权限、SOP、项目状态、客户信息、内部文档和业务规则。一个电商内容 Agent 需要知道 Brand Guideline、SKU 信息、商品真实性约束、目标市场、历史广告表现和平台规则。一个 Research Agent 需要知道过去搜索过什么、哪些来源可信、哪些判断已经被推翻、当前研究任务的证据标准是什么。
这些信息不会因为模型升级自动补齐。
所以大量 Agent 产品开始把重点放到”如何建立持续可用的 Context”上。Context 不再是一次性 Prompt 的附件，而是一个长期维护的系统。
我们过去做企业 AI 试点时最常见的失败模式，恰好印证这一点：模型每次都很聪明，但系统整体很笨。 文件要重新上传，品牌要求重新描述，项目背景重新解释，历史决策重新复述。把这个摩擦除掉，模型能力才真正开始兑现。
二、Qoder 把 Context 工程化：Knowledge Engine 在重新定义”代码库”
传统代码库主要被理解成文件和目录。AI Coding 时代，代码库开始需要额外一层机器可读语义。
Qoder 现场介绍的几个组件分别承担不同的 Context 工程职责（厂商归纳，原文以厂商文档为准）：Repo Wiki 形成项目结构和模块说明，Knowledge Graph 表达模块之间的依赖和契约，Memory 保存跨 Session 的约束、偏好和历史，Knowledge Cards 把当前任务相关的信息组织成可以直接喂给 Agent 的 Context 包。
更值得迁移的是这四件事背后的判断——Context 工程化以后，每一次新任务都从一个高信噪比的 Context 包开始，而不是从一份被反复读取的源代码仓库开始。
如果一个 Agent 每次接任务都重新扫描全部代码、重新阅读所有文档、重新猜测架构，模型能力再强也会浪费大量计算，而且结论非常不稳定。更合理的结构是：
Raw Data → Structured Knowledge → Task-specific Context → Agent
Task-specific Context 只抽取当前任务真正需要的内容，并且带着来源、版本、约束。
高德团队把百万行代码里的领域知识做成可召回资产后，任务一次性通过率从 37.3% 提升到 61.5%。这是 Context-as-Asset 的工程证据（数据来自厂商案例，是 Qoder 知识引擎在该客户上的实测结果，行业基准慎引；同样的论据在上一篇「云栖观察 01」第六节组织层判断里也出现过）。
三、QwenWork 把 Context 从代码库推向企业
QwenWork 在云栖现场的展示进一步把 Context 从代码库推向整个企业。
Legal Document Fill Out 和 Marketing Content Generation 是两个看起来普通的任务。真正值得看的是 Agent 如何知道企业自己的规则和资源。
如果一个法律文档 Agent 不知道企业模板、审批规则、合同字段和权限，它只能生成一个看起来合理的文档。如果一个 Marketing Agent 不知道品牌素材、历史 Campaign、目标市场、品牌语气和产品信息，它就只能不断让用户重新解释背景。
这是大量 AI 工具当前最明显的摩擦：用户每一次都在重复提供 Context（厂商方向性观察，原话以云栖大会通稿为准）。
一个真正有长期价值的 AI Workspace，应该逐步把这些重复说明变成持久资产。文件不用每次上传，品牌要求不用每次描述，项目背景不用每次解释，历史决策不用每次复述。模型可以换，系统不应该每次从零开始。
我们陪客户做 AI Coding 落地时，会专门问一句：”如果三年后换掉这个平台，你们的 Context 资产能不能带走？”——这句问话同样适用于 QwenWork 这种企业级 Context 平台。后面第六节会展开 Anti-lock-in 的判断。
四、Context 的价值来自”持续积累”，不是”塞得更多”
谈 Context 很容易掉进另一个误区：上下文窗口越大越好，把所有资料都塞进去。
实际系统里，Context 越多并不一定越好。大量无关信息会增加 Token 成本，也会降低注意力密度。不同版本文档同时存在时，模型甚至无法判断哪一份规则仍然有效。
所以 Context Engineering 真正要解决的是两类问题：保留什么与忘掉什么。
保留什么——聊天记录并不天然等于长期记忆。应该保存的是决策、约束、证据、失败原因、稳定偏好、可复用方法。支付系统改动不需要整个营销知识库，SEO Research 也不需要所有服务器日志。
忘掉什么——Context 必须有版本、时间、来源和状态。一个已经废弃的架构决策如果继续被 Agent 调用，长期记忆反而会放大错误。长任务需要不断总结和重组上下文，保留关键状态，丢弃已经没有价值的细节。
这也是这次云栖 OpenSearch Agentic Search 论坛专门强调 Task Memory、Long-term Memory 和 Context Compression 的原因。阿里云 OpenSearch 在现场给出的”检索—行动—记忆—知识”自循环框架（厂商归纳，以云栖通稿为准），本质上就是在回答同样的问题：哪些 Memory 应该留下来用很久，哪些该在任务结束时压缩掉，哪些已经过期必须主动遗忘。
2025 年 12 月发布的《Memory in the Age of AI Agents》综述（清华、新国立、复旦等机构 46 位作者联合署名的 arXiv 综述）也提出了一个更严格的分类：Memory 不能再简单按”短期/长期”二分，而应该按 Forms（Token-level / Parametric / Latent）、Functions（Factual / Experiential / Working）、Dynamics（Formation / Evolution / Retrieval）三个维度共同刻画——这是 Context-as-Asset 在学术层面的最新注脚。
五、Memory 不只是”记住用户说过什么”
很多 AI 产品把 Memory 理解成用户偏好，比如记住语言、名字、常用格式。这当然有价值，但对于 Agent 来说远远不够。
真正能形成复利的 Memory 更接近 Task Memory。
一次复杂任务结束以后，系统应该知道：这个任务最后是怎么拆的；哪些搜索路径有效；哪些工具失败过；哪些资料可信；哪个结果被用户接受；为什么被接受；哪些步骤可以抽象成 Skill；哪些错误以后要避免。
如果只是把全部聊天记录做 Embedding、再在下一轮检索出来，Memory 很容易退化成巨大的历史文本仓库。检索回来的”相关片段”未必相关，模型被干扰的概率反而上升。
Memory 真正需要的是提炼、评价和结构化。否则 Context 越积越多，下一次决策反而更不确定。
六、Context 也会形成新的 Lock-in——Anti-lock-in 的五问选型清单
Context 越重要，就越需要警惕新的平台锁定。
如果企业所有历史决策、Workflow、Agent Memory、Skill、用户反馈都沉淀在一个封闭平台里，迁移模型可能很容易，迁移 Context 却很难。这是一个比模型切换更隐蔽的长期成本。
我们陪客户做技术选型时，会专门问一句：”如果三年后换掉这个平台，你们的 Context 资产能不能带走？”答不上来的方案，慎选。
判断一个 AI 平台是否会把企业锁死，可以从这五个问题切入：
一问导出。 Task History、Decision Log、Knowledge Base、Skill Definition、Evaluation Result、Tool Configuration、Permission Mapping——这些 Context 资产能不能以通用格式导出？这决定了换平台时是搬家还是重建。
二问版本。 导出的 Context 是否带版本、时间、来源、状态？一份没有时间戳的 Knowledge Card，三年后根本不知道它当时为什么成立。
三问模型无关。 Context 是否能被不同模型消费？如果一个 Context 只能用特定模型解释，它本质上还是被绑定在某个供应商身上。
四问数据出境与合规。 Context 沉淀在境外的服务里，会触发数据出境审批、个保法（GDPR/CCPA/PIPL）相关义务以及强监管行业的本地化数据中心要求吗？这条不通过，前面四项全白做。
五问治理责任。 谁对 Context 的质量负责？谁有权修改？谁来淘汰过期内容？如果治理责任不清，Context 越积越多，反而变成新的组织债务。
这五问的底线是：Model 可以替换，Runtime 可以替换，Context 资产必须仍然掌握在自己手里。这可能会成为 AI-native 企业软件新的架构边界。
七、四类行业里 Context 沉淀的形态完全不同
前面讲的是通用链路。下面把这道判断放进具体场景里。
电信运营商——套餐变更、政企专线、跨域计费这类需求，每一次都要穿过 BSS/OSS/CRM 与合规审计四五个域。AI 写应用层代码也许快了一倍，但中间件适配、对账逻辑、合规审批一点没省。这里的 Context 沉淀重点不是代码库，而是历史计费异常、合规口径、对账规则——这类 Context 在公开资料里几乎没有样本，是企业真正的护城河。
金融银行——核心系统、风控、反洗钱、可解释审计。这套链路的特点是每一次变更都要可解释、可审计、可回溯。AI 写一段风控规则很快，但要进入规则引擎要过模型验证、可解释性测试、监管口径校对、内部审批。这里的 Context 沉淀必须满足数据出境合规（个人信息出境标准合同、个保法评估）和本地化数据中心要求，离开这两条，前面所有 Context 资产都不可用。
制造业——MES、ERP、QMS、报送系统。上一节提过，制造链条上 AI Coding 最容易出现”现场跑通、集成翻车”。同样的判断换到 Context 上：车间知识、设备参数、采集口径、PLC 接口、视觉系统版本——这些 Context 大部分藏在老师傅脑子里、老旧 PDF 里、半新半旧的 Excel 里。如果没有一个团队对”领域知识沉淀质量”负责，AI 拿到的 Context 会很快过期或相互矛盾。这是上一节五问清单在制造业最具体的落地。
电商——大促备战、库存一致、防薅羊毛、跨域对账。AI 在这一行拿到的 Context 是品牌规范、历史素材、平台规则、活动复盘。这部分 Context 时效性最强——一份三个月前的爆款素材逻辑，第二次大促可能完全失效。所以电商场景的 Context 治理重点不是”沉淀”，而是”淘汰节奏”。
四类行业的 Context 形态不一样，但共享同一个判断：Context 资产的组织治理，比工具选型更先决。
八、真正值得积累的，是能让未来判断和执行变好的信息
“Context 是资产”这句话如果继续往下推，会得到一个更严格的判断标准：并不是保存得越多，资产就越多。
只有那些能够降低下一次任务的不确定性、减少重复探索、提高结果稳定性、改善决策质量的信息，才真正构成资产。
所以以后设计 AI 产品时，我们陪客户做架构评审时经常多问几个问题：
这个系统每完成一次任务，会留下什么？ 是结果，还是可复用的方法与失败记录？
下次能不能直接复用？ 如果每次都要重新解释，复用就只停留在口号层。
哪些结论经过了验证？ 没经过验证的”经验”沉淀下来，下次会让 AI 走老路。
哪些失败已经被系统记住？ 没有失败记录的 Context，是片面的。
如果换一个模型，过去积累的价值还在不在？ 这是上一节 Anti-lock-in 五问的延伸：换模型时 Context 不丢，才算真资产。
模型会持续进步，调用价格会持续下降，今天看起来很强的能力也可能很快变成基础设施。真正能复利的部分，往往是模型之外的那一层：企业自己的 Context、经过验证的 Workflow，以及长期积累的判断和反馈。
对决策者的启示：下季度 3 件事
给 CFO——把”AI 节省了多少工时”挪到”每个被验收的任务到底沉淀了多少可复用 Context”。同一类任务在三种不同平台下，沉淀的 Context 复用率可能差 3-5 倍。这个数字比”调用次数”更接近真实 ROI，也更直接指向长期资产。
给 CIO/CDO——下季度把 AI 平台的选型指标从”模型跑分 / Token 价格”改成** Anti-lock-in 五问清单（导出 / 版本 / 模型无关 / 合规 / 治理责任）**。指标换上去 1-2 个季度，组织会自然开始要求 Context 可控；指标不换，三年后最贵的成本不是模型费用，是迁移 Context 的工时。
给业务负责人——指定一个人或一个小组对”领域知识沉淀质量”负责。上一节高德案例的核心不是工具上线，而是有人对”Context 沉淀质量”负责。如果只是把工具扔给团队，没有人为 Context 质量背书，效果大概率打对折。
你可能想问
Q1：Context 资产听起来很美，但中小公司哪有人手专门做沉淀？
不是专门做，是把沉淀嵌进现有流程。每一次 Issue 关闭、每一次需求评审、每一次事故复盘，都可以多写两句”为什么这么做、踩过什么坑”。一年下来就是几十万字的组织记忆。关键不在工时，在是否愿意把这些事当作正式交付物，而不是”文档洁癖”。
Q2：Agent 平台都在推 Memory、Knowledge Cards，是不是只是新瓶装旧酒？
部分是新瓶装旧酒，但部分方向是真的——Task Memory 把执行历史变成可检索资产，Knowledge Cards 把领域知识结构化，这是过去 Prompt Library 没解决的事。区分方法是看它能不能回答：”这个 Memory 上次被谁、在哪个任务、为什么被接受/拒绝？”答不上来大概率是旧酒。
Q3：Anti-lock-in 五问里”模型无关”是不是太理想化？现实里不同模型能力差很多，换模型一定掉质量。
是的，短期内一定掉质量。但问的不是”能不能零成本切换”，问的是”切换成本是不是被某个供应商独家锁定”。能导出、能转换格式、能保留版本，切换成本就是可计算的工程问题；不能导出，切换成本就是不可控的商业风险。这两个完全不是一回事。
反向自检
别把这一篇美化到不存在的程度。三件事需要诚实：
第一，本篇与上一篇「云栖观察 01」存在显著方向重叠——Qoder Knowledge Engine、QwenWork Enterprise Context、OpenSearch Task Memory、高德团队一次性通过率 37.3% → 61.5%、Context 资产化的判断在两篇都出现。本篇在结构上做了重排（Anti-lock-in 五问前置到第六节、引入治理责任与合规维度、补四行业镜头），但读者若两篇连读会感到熟悉。下次写云栖观察 03 时会避免这种重叠。
第二，文中厂商案例占比偏高。高德、QwenWork Legal Document Fill Out、OpenSearch Agentic Search 三个关键论据都来自云栖现场厂商归纳或厂商文档，立场偏厂商。已在引用说明段逐一标注，并在论证时尽量与第三方学术综述（《Memory in the Age of AI Agents》arXiv:2512.13564）做交叉验证。
第三，Anti-lock-in 五问目前是设计态，不是已验证的指标体系。真正用起来还要补：每个问题的具体度量、行业的最低门槛、合规条款的具体指向。本篇给的是判断方向，不是合规清单。下次与客户共创时再补。
引用说明（逐条出处 + 证据层级 + 立场）
| # | 文中论断 | 来源 | 日期 | 谁说的 | 证据层级 | 立场 |
|---|---|---|---|---|---|---|
| 1 | “Model power is a commodity. Context is the asset.”（大意） | Qoder 现场分享（厂商归纳，原话以现场为准） | 2026-09-24 | Qoder 团队 | 厂商主张 | 厂商立场 |
| 2 | Qoder Knowledge Engine 包含 Repo Wiki / Knowledge Graph / Memory / Knowledge Cards | Qoder Knowledge Engine 介绍页 + 上一篇「云栖观察 01」第三节交叉验证 | 2025-2026 | Qoder 团队 | 厂商主张 | 厂商立场 |
| 3 | 高德团队一次性通过率 37.3% → 61.5% | https://qoder.com/blog/qoder-case-amap + https://docs.qoder.com/zh/customer-cases/qoder-case-gaode | 2025 | Qoder 案例 + 高德 AutoSDK 团队 | 已验证事实（厂商案例，行业基准慎引） | 厂商 / 客户联合 |
| 4 | QwenWork Legal Document Fill Out / Marketing Content Generation 案例 | 云栖大会 2026 通稿方向 + QwenWork 产品介绍 | 2026-09 | 阿里云 QwenWork 团队 | 厂商主张 | 厂商立场 |
| 5 | OpenSearch Agentic Search “检索—行动—记忆—知识”自循环 + Task Memory / Long-term Memory / Context Compression | https://xie.infoq.cn/article/163b700cba024c8adb326ec5c（InfoQ 云栖 2026 报道）+ https://docs.opensearch.org/3.6/vector-search/ai-search/agentic-search/agentic-memory + https://opensearch.org/blog/unpacked-at-open-source-summit-na-2026-inside-opensearchs-massive-leap-into-the-agentic-era/ | 2026-09 | 阿里云 OpenSearch 团队 / OpenSearch 项目 | 已验证事实（厂商发布 + 第三方报道） | 厂商 / 第三方联合 |
| 6 | Memory Forms × Functions × Dynamics 三维分类 | https://arxiv.org/abs/2512.13564（《Memory in the Age of AI Agents》综述） | 2025-12 | Yuyang Hu 等 46 位作者（清华、新国立、复旦等） | 已验证事实（学术综述） | 学术界 |
| 7 | “Context Engineering” 作为术语流行 | 业界已在 Shopify、LangChain、Anthropic 文档中采用（行业通用术语，作者归纳） | 2024-2026 | 行业共识 | 行业观察 | — |
| 8 | Anti-lock-in 五问选型清单（导出 / 版本 / 模型无关 / 合规 / 治理责任） | 本文方法论综合（参考业界对 AI 平台可移植性的讨论 + 合作客户脱敏案例） | 2026 | 本文作者 + 综合 | 作者推演 | — |
| 9 | 数据出境 / 个保法 / 强监管行业本地化数据中心要求 | 《个人信息保护法》第 38-39 条 + 《数据出境安全评估办法》 + 金融行业强监管要求（公开法规） | 2021-2026 | 国家网信办 / 中国人民银行 / 国家金融监督管理总局 | 已验证事实（法规） | 监管立场 |
| 10 | 四类行业（电信 / 金融 / 制造 / 电商）Context 形态差异 | 本文行业观察（基于合作客户脱敏案例 + 公开厂商案例） | 2026 | 本文作者 + 综合 | 行业观察（脱敏） | — |
| 11 | “如果三年后换掉这个平台，你们的 Context 资产能不能带走？” | 本文判断式提问（基于多行业 AI 平台迁移经验） | 2026 | 本文作者 | 作者推演 | — |
| 12 | 制造业”现场跑通、集成翻车”现象 | 上一篇「云栖观察 01」第六节 + 海信/温氏案例（公开厂商案例） | 2025-2026 | Qoder / 阿里云 Lingma / 海信 / 温氏 | 已验证事实（厂商案例，脱敏延伸） | 厂商 / 客户联合 |
本地化要点（多语言翻译对照，IAIUSE 多语言策略·2026-08-09 约定）
翻译 19 语时，下述内容按目标语言市场本地化替换，结构/视觉不变：
| 中文稿内容 | 英文版 | 日文版 | 德文版 | 阿拉伯版 |
|---|---|---|---|---|
| Qoder / 阿里云产品 | Qoder / Alibaba Cloud（保留产品名） | Qoder / アリババクラウド | Qoder / Alibaba Cloud | Qoder / علي بابا كلاود |
| 飞书 / 钉钉 | Slack / Teams | Slack / Teams / Lark | Slack / Teams | Microsoft Teams |
| 中国电信 / 移动 / 联通 | AT&T / Verizon / T-Mobile | NTT / KDDI / ソフトバンク | Deutsche Telekom / Vodafone | STC / Etisalat |
| 招商银行 / 工行 | JPMorgan Chase / Bank of America | 三菱UFJ / 三井住友 | Deutsche Bank / Commerzbank | National Commercial Bank（沙特）/ QNB |
| 比亚迪 / 宁德时代 | Tesla / Ford / GM | トヨタ / 日産 | Volkswagen / BMW | Saudi Aramco（制造代表）/ Tawuniya |
| 高德地图案例 | Google Maps / Mapbox case | 楽天モバイル / Yahoo!地図 case | Here Technologies case | Careem / Google Maps MENA case |
| QwenWork / 通义千问 | Tongyi / Qwen (保留产品名) | Tongyi / Qwen | Tongyi / Qwen | Tongyi / Qwen |
| OpenSearch 智能体搜索 | OpenSearch Agentic Search (保留) | OpenSearch エージェント検索 | OpenSearch Agentensuche | بحث وكلاء OpenSearch |
| BSS/OSS/CRM | BSS / OSS / CRM (保留) | BSS / OSS / CRM | BSS / OSS / CRM | BSS / OSS / CRM |
| PIPL / 数据出境 | GDPR / PIPL / SCC | GDPR / APPI | DSGVO / BDSG | نظام حماية البيانات الشخصية (PDPL) |
| 《Memory in the Age of AI Agents》arXiv:2512.13564 | 同前（学术文献，保留 arXiv 编号） | 同前 | 同前 | 同前（学术文献，保留 arXiv 编号） |
说明:除上述本地化项外，文中全球性产品/概念（Repo Wiki、Knowledge Graph、Task Memory、Skill、Context Engineering、Anti-lock-in 五问）保持原文不译。其他 15 语种按 IAIUSE 三梯队执行：重点 5 语（中/英/德/日/阿）按上表本地化；顺带 9 语（西/法/葡/韩/俄/意/荷/波/土）保留 Qoder/QwenWork 原名 + 替换本地代表企业；可选 5 语（瑞典/泰/越/乌克/印尼）保留原名占位。
如果你正在评估企业 AI 应该从哪切入、哪些 Context 资产值得优先沉淀、哪些是会被模型升级淹没的一次性 Prompt，欢迎聊聊。我们做三种事——企业内训（AI 时代研发与运营团队转型，2-3 天工作坊，把 Context 资产盘点、Anti-lock-in 五问与度量体系带回去）、专项咨询（从 Context 资产盘点、Workflow 再设计到度量体系，帮你把”模型能力”沉淀成”组织能力”）、管理层分享与行业演讲（决策者视角的 AI Context 真相与 Anti-lock-in 选型）。如果只想先聊 90 分钟看方向，欢迎预约一次轻量沟通。合作邮箱：[email protected]。
延伸阅读：《AI 转型七步框架》，系统讲清楚企业落地 AI 的完整路径。
关于本系列
「云栖观察」是 IAIUSE 推出的产业现场系列，从 2026 云栖大会出发，用研究者的视角拆解 AI 产业正在发生的真实变化——不追热点，只看下注的方向和证据的强度。
系列覆盖模型之上的系统层、Agent 落地、Context 资产、企业 AI 组织设计、AI 产品竞争单位迁移等话题，共约 10 篇。
本系列研究资料库累计超过 200 篇公开研究与行业案例。本篇依据的证据来自三个层级：现场厂商分享（Qoder / QwenWork / OpenSearch）、第三方独立研究（《Memory in the Age of AI Agents》arXiv:2512.13564 等学术综述）、合作客户脱敏案例。其中厂商案例占比偏高，引用时已在引用说明段标注立场。
我有近 8 年大型企业咨询与商业分析经验，曾任职于 IBM，参与过电信、金融、保险和制造业相关项目。此后继续在运营商产品、互联网产品和 AI 应用开发一线，从事需求分析、产品设计和跨团队落地。这个号背后其实是一个小团队——我和 1-2 位长期协作的同事，分头负责 AI 编程工具研究、组织治理案例梳理、教练对话这几块。文中”我们陪企业蹚过”的多数项目，是我们几位共同交付过的。
本系列的判断来自我的现场观察和行业交叉验证，带有明确的作者立场，不代表任何厂商观点。
buymeacoffee
