一家企业换了一个更强的 Agent，之前维护的客户资料、报价规则、审批关系和工作进度，要不要重新整理一遍？
如果答案是“要”，那企业每更换一次入口，都在重复支付上下文建设成本。
这也是我对 AI 应用的一个判断：入口负责把智能送进企业，上下文决定智能能不能在企业兑现价值。
模型可以换，交互方式可以换，业务积累应该继续属于企业。
我把围绕这份积累的持续建设和维护，称为 Context as a Service，上下文即服务。这里讨论的是一种产品与商业模式，不是一项已经统一的行业标准。
内容多了，连接会比生产更重要
先说为什么我会关注这个方向。
过去的内容平台，用户承担了大量创作劳动，平台主要承担分发以及存储、审核等成本。AI 降低了生产门槛，但生成图片、视频和文本需要算力。如果平台替用户承担这些成本，成本就会随着使用增加。
内容供给可以变多，人的注意力却不会按同样的速度增长。更多内容也不自动意味着更多广告收入。
这不等于中心化平台马上失去盈利能力。AI 也可能帮助广告投放和商业转化。例如快手披露，2026 年第二季度线上营销服务收入同比增长 4.4%。官方业绩公告
我的判断是，生产、分发和价值兑现会出现更多分工。企业为自己的经营成果购买算力，个人为服务和创作购买算力；新的产品则帮助智能连接到具体的人、组织和业务。
对企业软件来说，这个问题更直接：Agent 生成了十份分析报告，不如准确知道今天哪个订单有风险，并推动有权限的人处理。
有知识库、有 MCP，为什么还不够？
因为接通了工具，不代表模型理解了业务。
MCP 可以提供模型应用与外部工具、数据源交互的协议；RAG 可以帮助系统检索相关资料。它们都很有用，但企业仍要定义数据含义、更新方式和执行约束。MCP 官方介绍
一个查询订单的接口已经连通，也不代表 Agent 知道“已成交”和“已收款”能不能互相替代。
知识库里同时保留去年和今年的报销制度，如果没有版本和生效范围，检索结果很相关，也可能用错规则。
一个返回“成功”的工具，如果只表示请求已接收，却没有对应业务记录，Agent 就不能据此告诉用户“已经处理完了”。
我理解的企业上下文，需要把这些东西组织到一起：
| 内容 | 回答的问题 |
|---|---|
| 业务对象与关系 | 这是谁的订单，关联哪些客户和供应商 |
| 知识与规则 | 依据哪项制度，什么情况适用 |
| 当前状态 | 事情进行到哪一步，还有什么没完成 |
| 身份与权限 | 当前用户可以读什么、执行什么 |
| 来源与版本 | 事实从哪里来，什么时候更新，哪一版有效 |
| 动作与回执 | 可以怎样改变状态，如何确认结果 |
这些内容不必装进一个巨大的 Prompt，更不必集中到一张数据库表里。它们可以分布在多个系统中，由受控的查询和业务操作提供给 Agent。
“同一份上下文”，不是把所有数据复制到一起
假设一家企业有采购 Agent、交付 Agent 和经营分析 Agent。
采购更关心成本，交付更关心交期，经营分析更关心毛利和风险。它们可以使用不同模型、不同提示词和不同决策策略，但对同一订单的数量、交期和实际成本，不应该各自维护一套互相矛盾的事实。
所以，“上下文只有一份”强调的是共同认可的业务依据。
订单事实仍然由订单系统负责；供应商报价有来源和有效期；知识规则有版本和生效范围。不同 Agent 按权限获取与任务有关的部分，保留来源和时间信息。
现实系统也不总能实时同步。比如库存数据半小时前更新过，就应明确显示时间；涉及下单等关键动作，还要在执行时重新校验，不能把旧的读取结果直接当成当前可用库存。
多个 Agent 可以基于同一事实提出不同建议。发生冲突时，由业务规则、授权边界或负责人决策来处理。事实共享并不意味着决策必须一致。
去中心化，先从数据与算法解绑开始
过去，许多平台把数据和分发机制放在同一套体系里。用户能获得怎样的连接，很大程度上取决于平台的规则。
我更看好另一种分工：个人和企业掌握自己的数据与授权，服务商负责把数据组织成可用上下文，不同 Agent 根据不同目标做识别、匹配和执行。
例如企业对外提供自己的产品能力、交付范围和可承接需求，在授权范围内被不同采购 Agent 发现。一个 Agent 优先找价格合适的供应商，另一个优先考虑交期，还有一个专门做资质与风险筛选。
同一份企业信息，可以参与多种匹配机制，不必只接受一个平台的统一排序。
但多接几个 Agent，还不能说明已经实现了这种模式。数据是否可导出，语义是否可理解，授权是否可撤销，客户能否更换模型和服务商，才是需要落地的条件。
商业智能网络是我们希望推进的方向。它依赖更多企业完成内部的数据和流程整理，以及跨企业身份、授权和协议的建设，不能把一次接口联通直接当成网络已经建成。
上下文每天都在变化，所以它是一项持续服务
如果上下文只是一次性整理的文档，建完就结束了，也谈不上多少持续价值。
但企业每天都在发生变化：采购更新价格，销售调整订单，管理者修改审批要求，客户取消合作。旧规则需要失效，新状态需要同步，正在执行的任务也可能需要重新判断。
一次成本更新，就可能带来一串事情：确认新价格的来源和生效时间，检查哪些未完成报价受影响，让相关岗位看到变化，必要时重新计算，并保存处理记录。
没有这部分持续工作，Agent 获取的上下文会越来越落后于企业现场。
这就是上下文服务可以提供的价值：建设业务模型、连接数据、维护规则版本、管理授权、追踪执行结果，并在业务变化时调整系统。
客户购买的是让 AI 持续理解和参与自己业务的能力。数据控制权仍然应该留在客户手里，服务商的价值来自把这件事做好。
我们为什么把企业 AI OS 和 AI FDE 放在一起
在 Tacore 的产品思路里，企业 AI OS 承载并维护企业上下文，让知识、数据、规则和工作结果在日常经营中持续积累。
AI FDE 工具箱则供 Coding Agent 使用，帮助建设和修改这套系统，把更多工程工作交给 AI。业务人员负责目标、授权和规则确认，通过实际业务结果验收。
两者结合，上下文才有机会随着经营持续更新。只有开发工具，系统建好后可能没人维护；只有静态知识库，业务变化以后又会逐渐失真。
对开发者来说，这里面有很具体的机会：把一个行业的数据关系梳理清楚，把一类反复发生的业务变化处理可靠，把旧系统的能力变成可控、可追溯的 Agent 操作。
与其只比较新入口有多聪明，我更愿意观察：企业更换一个 Agent 之后，原来的业务积累还能不能继续使用。
入口可以换，算法可以选，上下文要留在个人和企业手里。
本文是「企业 AI：从交付到上下文」系列第三篇。关于平台分工、上下文服务和企业间智能网络的讨论，属于我的产品判断与发展方向。
