9 月 9 日，以“JoyAI·跃迁物理世界”为主题的 2026 京东全球科技探索者大会（JDD）在北京亦庄举行。相比过去几年 AI 行业对模型参数、推理能力和 Agent 的集中讨论，今年大会释放出的一个明显信号是： AI 正在从能做什么，走向怎么真正进入现实世界和业务系统。
大会上午发布的京东 APP 16.0，是这种变化在消费端最直接的体现。这次升级，京东进一步将 AI 能力融入用户从需求产生、商品选择到购买决策、履约服务的完整链路。
新版京东 APP 保留搜索、货架、下单等原有购物方式，新增了 AI 购物助手“东东”，并融合 AI 对于用户需求的精准理解，从帮助用户找到商品，到理解用户现在需要解决什么问题，再到调度海量商品和服务满足用户需求，让用户的购物决策更高效，购物体验更省心。同一天的另一场分享，则把这个问题从消费者一端推到了企业内部。
在智能零售论坛的《零售企业的 AI 变革之路》分享中，京东零售产研团队介绍了过去两年在企业级 AI 上的探索，以及一个更现实的问题： 当 AI 已经能写代码、做分析、生成 PPT，为什么企业整体效率并没有同步提升？代码写得更快了，企业为什么没有跑得更快？
过去两年，企业谈 AI 提效，最常见的指标之一就是 AI Coding 率。前端、后端、测试、算法都开始使用 AI，模型能生成的代码越来越多。
按照最直观的逻辑，当一个工程师每天能够写出更多代码，整个研发团队的效率也应该随之提高。但京东零售产研团队在内部实践中发现，代码产量的增长并没有带来研发效率的同步提升，反而增加了代码审查、测试和评测等环节的压力。
原因在于，编码只是软件工程中的一环，如果把一条完整的研发链路拆开来看，大致可以分为“上工程”和“下工程”：代码产生之前的需求沟通、方案设计、任务拆分、系统评估和跨部门协调，属于“上工程”；代码产生之后的 Review、测试、发布和运维，则属于“下工程”。 AI Coding 目前解决得更多是中间的编码环节，但真正麻烦的，往往是“上工程”。
需求应该怎么定义，架构怎么设计，不同系统之间如何划分边界，一件事涉及几十个团队时，谁需要参与、怎么协同、最终围绕什么目标做判断，这些都属于“上工程”的范畴。这也是为什么，AI 看似已经让很多员工变得更高效，但企业整体的效率却没有按照同样的速度增长。
麦肯锡 2026 年的一项全球 AI 调研，也印证了这种落差：80% 的受访者称 AI 已经提高了自己的工作效率，但只有 37% 的受访者肯定 AI 对所在企业的 EBIT（息税前利润）产生了正向影响。在 Agent 加速进入企业、AI 应用密度明显提高的 2026 年，这个比例与 2025 年相比，却几乎没有变化。
经营场景同样如此。 Agent 可以帮助员工做 PPT、写报告、查资料、分析数据，但零售经营并不是把几份 PPT 做得更快。
一次经营决策可能同时涉及商品、定价、库存、流量、广告、内容、供应链、成本和利润，每一个环节都有自己的专业判断和目标。 AI 可以让每个人工作得更快，却未必能让这些人更顺畅地协作。
这也是此次分享中最值得关注的一个判断： 企业 AI 的主战场，正在从“帮助一个人完成任务”转向“帮助一个组织完成协作”。两个项目背后，是京东零售产研团队对组织协同的一次重构 围绕这个问题，京东零售产研团队展示了两个业务完全不同的项目：JoyOxygenSE 和 JoyOxygenRetail。
JoyOxygenSE 面向软件工程。会上介绍的一个案例，是通过优化直播频道“膨胀券”的发放机制提升 GMV 转化率。
按照传统流程，这项需求需要经过产品设计、技术评估、架构设计、开发测试和上线发布。在新的流程中，业务需求先被输入系统，平台结合内部业务知识、历史数据和产品经验，生成初步方案、PRD 和接近线上效果的原型，再进一步分析技术影响范围。
在这一案例中，系统最终识别出约 30 个业务域和上百个系统可能受到影响，并从风控、高可用、分布式架构等角度给出进一步建议。方案并不会直接交给 Agent 执行，而是发送给不同业务域的负责人审核，先由专业人员负责判断系统边界、业务规则和技术方案是否准确，相关反馈再被系统吸收。
确认完成后，平台才会调度研发、测试、算法和 SRE 等 Agent，继续完成开发、验证、发布和监控。 JoyOxygenRetail 把类似逻辑搬进了零售经营。
以开学季图书运营为例，团队设定的目标是销售额同比增长 30%。但对于真实经营来说，30% 只是结果，系统不能只盯着这一个数字，还要同时考虑利润率、成本、售价、库存、采购、供应链和广告预算等约束。
在此基础上，平台分析图书货盘中的新品、长尾商品和爆款，为不同商品制定页面优化、内容生产、流量分配、促销和广告策略。随后，搜索、商品、内容、营销、广告等专业团队分别审核自己负责的部分。
方案确认之后，各领域 Agent 再继续执行。 JoyOxygenSE 和 JoyOxygenRetail 一个面向软件工程，一个面向零售经营，看似相距很远，却形成了几乎相同的流程： 目标确认、业务推理、业务对齐、Agent 执行和持续对齐。
这套方法的重点不是让 AI 直接取代专业人员，而是 AI 负责先完成全局分析和初步规划，人负责在关键节点校正专业判断，Agent 再完成大量执行工作。这也意味着， 未来企业的协作方式可能逐渐从“人找人”，变成“Context 找能力” 。
过去，一项需求需要产品经理逐一寻找相关团队；未来，系统可以根据上下文自动判断涉及哪些业务域、系统和专业角色，并完成初步分工。这一思路真正击中的，是多 Agent 协作里一个很现实的问题：单个 Agent 再强，如果彼此之间看不到同一个目标，也无法共享上下文和执行状态，就很难真正接住跨部门、跨系统的复杂任务。
但把 Agent 连接起来，只是第一步。真正进入生产环境之后，更难的是把协作规则一起建立起来。
比如，哪些 Agent 能调用哪些数据，哪些动作必须经过人工确认，出现冲突时谁来裁决，出了问题如何追溯责任。如果这些问题没有解决，企业只是把过去依赖会议和审批的协作方式，换成了一套新的 Agent 排队机制。
比模型更难建设的，是企业上下文 要让这些规则真正被 AI 理解和执行，企业首先得讲清楚自己是怎么运转的。京东零售产研团队将这套体系的底层能力概括为： Model × Context × Learning Loop 。
Model 提供通用智能，Context 帮助 AI 理解企业，Learning Loop 则让系统通过反馈持续进化。其中最容易被低估的，是 Context。
现在很多企业建设 AI 知识库，本质上还是把已有文档塞给模型。但一家公司的真实运行方式，很少完整写在文档里。
比如，一个商品最近卖得不好，大模型根据商业知识，很快能判断出降价可能是一个解决办法。但它未必知道，30 天后还有一次大促，大促本身也会涉及降价。
现在降多少，大促时又降多少，两次动作之间怎么避免冲突？这些都和一家企业具体的经营节奏、规则和经验有关。
模型知道一般逻辑，却不知道场景之间的制约关系。软件开发也是如此。
AI 可以根据一个需求生成页面原型，但要让这个原型真正上线，它需要知道不同页面楼层承担什么功能、价格应该以什么方式展示、按钮放在哪里、设计规范是什么，甚至过去什么样的改动曾经影响过转化率。这些知识，既不存在于通用模型的预训练语料里，也未必存在于某一本完整的公司手册里。
它们散落在代码、数据库、流程、会议、系统配置和人的经验中。过去几十年，企业信息化一直在试图解决这件事。
写 Wiki、建知识库、整理 SOP，希望把人的经验和业务规则变成可以被组织复用的资产。但这些存在人脑里的经验，需要有人先主动总结，再把它翻译成系统能使用的形式。
这个过程太慢，也太依赖人的主动性。很多知识在真正进入系统之前，就已经过时了。
甚至很多经验从来没有被写下来，只停留在少数人的脑子里。大模型改变的，是这些经验进入系统的方式。
越来越多原本难以结构化的信息，开始有机会在业务发生的过程中被理解、提炼，并转化为 Context。但仅仅把经验放进 Context 还不够。
真正决定这套系统能不能持续进化的，是新的经验多久能够重新进入 Context。如果未来不同企业能够获得的 Model 能力越来越接近，那么真正拉开差距的，可能不再是谁先接入了一款更强的模型，而是谁能把更多业务经验沉淀下来，又能以更快的速度让这些经验参与下一次决策。
模型可以采购、替换，企业长期积累下来的业务规则、组织经验和决策逻辑，却很难被复制。这也解释了为什么，在 Model、Context、Learning Loop 三者之中，Learning Loop 并不是一个附属环节。
Context 决定 AI 今天知道多少，Learning Loop 决定它明天能不能比今天更懂这家公司。要让这套学习闭环真正运转起来，关键在于，能不能把人的反馈自然留在业务流程里。
这也是京东零售产研团队提出“分布式对齐”的原因。在京东零售产研团队提出的体系中， AI 生成的方案需要由各业务域专家分别审核，这一过程被称为“分布式对齐” 。
与传统审批相比，新的流程不再要求员工从零开始分析，而是由 AI 先基于全局上下文提出方案，专业人员重点判断结果是否正确。如果发现问题，修改意见会再次进入系统，成为后续推理的依据。
这套机制保留了现有组织里的专业分工，也试图降低跨部门协作成本。 AI 承担更多全局分析、方案生成和执行工作，人则逐渐转向目标确认、专业校正和异常处理。
它没有假设 AI 会迅速取代一整套组织，而是先尝试把 AI 嵌进现有协作关系里。这一点其实相当务实。
企业里的财务、风控、数据库、高可用、供应链等专业能力，不会因为模型升级就突然消失。真正可能发生变化的，是这些专业能力如何被调用，以及人是否还需要一次次通过拉群、开会和重复沟通来完成协作。
不过，“分布式对齐”能否真正提高效率，还取决于反馈机制是否足够自然。如果专家每完成一次审核，都要额外填写大量标注、整理经验、维护知识库，那么所谓 Learning Loop 很容易变成新的工作负担。
真正有效的反馈机制，应该尽量嵌入原有工作流，让员工在审核、修改和执行过程中，自然留下可以被系统继续使用的信息。只有这样，Learning Loop 才会真正成为企业日常运转的一部分。
模型之外，才是企业真正的壁垒？一家企业接入 AI，最容易被看到的通常是模型。
用了什么模型，参数有多大，推理能力有多强，评测分数高不高，这些都有相对清楚的衡量方式。京东零售产研团队对这件事却相对克制。
他们的判断是，长期来看，基础模型能力会逐渐趋同。真正决定一家企业 AI 能力上限的，反而越来越多发生在“模型外”。
这并不意味着模型不重要。在模型层，京东零售产研团队基于 JoyAI 基座大模型训练电商垂类相关模型应用、MaaS 平台、电商评测体系。
因此，京东零售产研团队选择建设自己的电商评测集和标准化增强管道，让模型经过业务训练、Agent 适配和专业评测之后再进入生产环境。同时，其自研推理引擎 xLLM 也在适配更多国产化硬件，以控制推理成本和算力供应风险。
背后的思路是，模型可以替换，企业不能跟着模型一起重建。如果这个判断成立，那么未来大型企业之间 AI 能力的差距，很可能越来越少取决于“谁最先接入了一款新模型”，更多取决于另外几件事： 谁能更灵活切换模型，谁拥有质量更高的业务 Context，谁建立了更可靠的评测、权限、调度和反馈体系。
这一判断仍需要更多结果验证。 JoyOxygenSE 和 JoyOxygenRetail 已经给出了比较完整的方法论和真实场景，但它究竟能够减少多少会议、缩短多少研发周期、提升多少经营收益，仍然需要更长期、更量化的结果验证。
流程被打通，并不意味着价值已经兑现，企业 AI 最终还是必须回到 ROI：它减少的是总工作量，还是只是把工作从一个人转移给另一个人；提高的是决策质量，还是仅仅生成了更多方案；这套机制又能否跨越不同业务稳定复制，而不长期依赖少数核心专家。这些问题，可能要比再发布一个 Agent 难回答得多。
但至少，京东零售产研团队已经开始问这些问题了。结束语：下一阶段，竞争的是“组织操作系统” 如果把企业 AI 的发展简单划分成几个阶段，第一阶段的竞争集中在模型能力；第二阶段是 Copilot 和 Agent，解决一个人的生产力；再往后，问题很可能会变成，谁能把模型、企业知识、工作流程和组织反馈真正连接成一个持续运行的系统。
京东零售产研团队提出的 Model、Context 和 Learning Loop，本质上是在尝试搭建这样一套面向 AI 时代的“组织操作系统”。模型负责推理，Context 告诉它这家公司究竟如何运转，Agent 负责执行，人留在关键决策节点，而一次次真实业务产生的经验，再重新进入 Learning Loop。
这套体系最有想象力的地方，不是 AI 可以替代多少岗位，而是让企业的协作机制逐步可计算、可调度、可学习。这也是为什么，这件事比做一个 Agent 难得多。
技术平台可以快速搭起来，组织几十年形成的业务规则、权责关系、专业共识和经验，却不可能一夜数字化。但也正因如此，一旦真正建成，它可能比任何单一模型更难复制。
模型决定了一家企业能够从哪里出发。而一家企业能否把多年沉淀在员工、系统和业务里的经验，持续转换成可以被 AI 调用的“Token 资本”，并让这些资产在一次又一次业务决策中继续增长，或许才决定了 AI 最终能够把这家公司带到哪里。