QCon 2026·京东科技：尽在上下文——JoyCode 的企业级 AI Coding 实践
主讲：徐翔（京东科技，JoyCode AI 架构师）
时长：约 47 分钟
检索得准，才是上下文工程的关键。JoyCode 分享了六类检索引擎的选型逻辑（ripgrep/向量/倒排/稀疏/RepoGraph）、RepoWiki 代码知识图谱的闲时构建方案，以及多 Agent 协同架构在 15 天紧急交付中的实战验证。
开场：JoyCode 面临的四大挑战
京东内部有大量不同的业务——零售、物流、健康等，业务场景极其复杂，内部项目大大小小各异，对知识来源有很高的要求。
挑战一：业务场景复杂
用户画像非常丰富：从普通开发者到架构师、算法工程师，甚至财务、法务等非开发同学也在用 JoyCode。
挑战二：复杂长任务
大型项目非常多，复杂长任务很容易造成上下文爆炸，频繁压缩，质量下降。
挑战三：超大代码仓
如何在超大代码仓里快速精准定位，塞入有效的上下文，是核心问题。
挑战四：多元用户需求
不同角色对 AI Coding 工具的期望差异显著，标准化工具难以满足所有人。
一、企业知识增强
我们提供四类企业知识增强来源：
1. Jira/Confluence + 在线企业文档
最常见的做法，把企业文档和知识平台打通，提供知识检索接口。
2. 多模态结构化知识增强
支持文档、图片、Excel、PDF 等各类内容的结构化解析。
3. RepoWiki：代码知识图谱
这是我们重点建设的能力。AI 在后台持续读取代码，生成高层次文档——设计文档、架构文档、核心模块文档、新手引导等。这些文档与企业知识库集成，注入到上下文里。
特点：
- 闲时算力利用：在服务器闲时（凌晨等）用自部署模型跑知识生成
- 多人共享：企业项目往往多人共用，闲时跑出的知识可以同时下发给多个同学
- 增量更新：基于默认分支跑整体 baseline，不同分支做增量更新，极大降低知识形成成本
RepoWiki 解决了新成员上手困难、培训成本高的问题。知识是 T+1 动态更新的，时效性比人工维护高很多。
4. D2C（Design to Code）
企业内部有设计平台和自研组件，传统 AI 生成的代码往往用通用组件，不符合企业内部规范。我们把设计稿 DSL 与企业内部组件关联绑定，实现从设计稿链接获取 → 解析 → 生成企业组件代码的完整链路，保证还原度同时确保使用企业内部资产。
二、上下文工程管理：检索优先
与其他方案不同，我们的重点放在检索上，而不是记忆压缩。
核心理念：检索得准，按需把东西读进上下文，才是最关键的。 而不是把内容先交给大模型，让它一股脑全塞进来，那会引起一系列连锁问题。
检索原则
- 先定位再读取：定位到代码函数的具体开始和结束位置，才注入到上下文，而不是知道在某个文件里就把整个文件读进来
- 把选择权交给大模型：定义好每个检索工具的职责边界，让模型自己选择用哪个
- 提供预处理的仓库理解知识：RepoWiki 和 RepoGraph 提供仓库级知识，避免模型自己去读 package.json、项目配置等
多路检索引擎
我们提供了六类检索工具：
1. ripgrep/glob（精确文本搜索）
优点：正则表达式精确匹配，响应速度快，即搜即用，无需建索引。
缺点：无法理解语义，模糊查询效果差，超大仓库可能较慢。
2. Embedding 向量检索
优点：理解语义，适合模糊的自然语言查询（”用户认证有什么错误处理机制”）。
缺点：索引成本高，有冷启动时间（需要先建向量索引）。
3. 倒排索引
基于关键词的快速检索，速度极快（基于索引，不管仓库多大都是常数时间），弥补 ripgrep 一次返回多个结果时的性能问题。适合技术词汇匹配。30 万行代码仓库，不到 1 分钟可以构建完成。
4. 稀疏索引
和倒排索引的区别：有相关性排序，把与检索语义最匹配的结果放前面。弥补倒排索引”只要匹配就返回”的问题，在向量索引冷启动阶段可以作为平替。基于 BM25 算法。
5. RepoGraph（代码图谱索引）
这是我们重点建设的能力，专门解决超大代码仓的问题。
通过语法树分析，得到所有类、方法的调用关系、继承关系，构建成一个大图。提供可视化界面供用户做交互式分析和反馈（图谱准确性很重要，不准确会给模型提供错误结果）。
主要用途：
- 复杂度分析：通过圈复杂度、函数参数数量、调用数量、依赖数量、继承深度等加权评分，找到项目中最复杂的类和函数。比大模型自己在百万行代码里一点点读要准确得多。
- 调用链路分析：一次检索就能把整体的调用者和被调用者关系全部返回（图的多跳特性，性能达到秒级甚至毫秒级）。传统方式需要十几次工具调用，RepoGraph 只需一次。
- 代码变更影响范围分析：给评估者提供变更影响范围工具，判断这次变更改动范围对不对，有没有漏改。在测试团队应用很广。
实测对比数据
案例一（中型仓库）：开源项目，2600+ 文件，64 万行代码，模型 Gemini。
对比方案（只有 ripgrep + glob）：需要 11 次工具调用，其中 4 次是文件读取，1 次 block，token 消耗很高（因为它一次读取 2000 行以下的文件会全部塞进上下文）。
JoyCode：只用了 1 次稀疏索引 + 2 次 grep，token 消耗少 1 万多。
案例二（大型仓库）：VS Code 仓库，4200+ 文件，1000 万行代码。
对比方案：18 次工具调用，8 次读文件。JoyCode 工具调用次数也更少，且 token 差异对后续任务影响深远——token 多了会更快触发压缩，压缩会有信息损失，进而影响后续任务。
结论：这仅仅是一次简单任务的差距，长任务中差距会成倍放大，对企业成本影响非常大。
三、智能体能力增强
Skills 生态
基于标准化 Skills 框架，构建可插拔的能力生态。根据任务需求动态加载相应工具和技能，避免资源浪费。
多智能体协同
支持三种模式：团队智能体 + 自定义智能体 + 企业知识三位一体。
自定义智能体：用户可以自由组合，指定规则、工具和业务知识，并进行对照测试。
自主规划生成
整合 Spec + TRD（技术需求文档）+ Rules，实现业务特色代码的自主规划和生成。
多智能体协同架构演示
参考 Anthropic 的文章，构建了协调者（Orchestrator）+ 计划者（Planner）+ 执行者（Executor）+ 评估者（Evaluator）四角色体系：
- 协调者：负责调度，不自己干活
- 计划者：制定计划、产品和运输合约
- 执行者：真正干活，把结果给到评估者
- 评估者：做最终测试，使用 Playwright 等工具做交互式测试（打开浏览器，对外部应用进行交互操作）
演示：生成了一个 2D 中国象棋游戏，跑了 6.5 小时（使用 Gemini，不是最优情况），完成度非常高——这是简单的 Vibe Coding 或 Spec 驱动编程很难达到的。
四、真实案例：15 天完成紧急项目交付
京东内部某业务有一个风险项目：供应商违约提前离场，仅剩 15 天完成剩余的高质量交付。
通过搭建智能体协作链路，覆盖整个产研流程：
- PRD → UI/UE → 架构 → 开发（每个环节用一个智能体替代）
- 中间调用 Spec 进行文档和任务状态追踪
- 人工参与：具体输入确认
结果：核心成本（人力、研发周期）大幅节约，代码质量达标。
关键发现：整个过程中需要反复与智能体沟通——Skills 打磨好之后，真正产生的效果也许不符合预期，需要不断给 Skills 反馈，这是相互反馈、相互完善的过程。这也是 Harness Engineering 当前最大的挑战：如何把一个月的调试周期压缩到 15 天。
技术架构师的角色：对比传统模式和 AI 驱动模式，技术架构师的人力投入反而增加了——这是我们未来重点要做的方向，如何让 Harness Engineering 的整个验证链路也能自动化。
五、未来趋势
1. 上下文工程持续演进
如何在有限的上下文窗口里，在数千次甚至数万次的 token 用完时，依然能稳定高效地完成任务——仍然是未来的重点。
2. 更好的 Harness 环境搭建
不只是工程约束，而是如何构建更灵活的驱动机制，让智能体更自由地完成任务。
3. 知识图谱技术
图技术在 AI Coding 里会得到更大规模的推广。不只是代码索引，记忆系统（Memory）也可以用图来构建，把整个记忆构建成图结构，利用图的高性能多跳特性。
Q&A
观众：业务迭代后如何保证 RepoWiki 的知识不过时？支持跨仓库识别吗？
徐翔：T+1 自动更新，后台自动跑。跨仓库支持——我们除了代码维度，还有产品维度的 Wiki，会把所有相关仓库关联起来。也支持 CLI 接入。
观众：D2C 的方向，AI 能力这么强，DSL 还有必要吗？
徐翔：必要。不管 AI 能力多强，要做到企业级的精确还原，并且让生成的组件是企业内部的组件，必须有 DSL 做真正可配置、可控的约束。只有这样才能既保证还原度，又保证生成的组件准确可用。
观众：提供了这么多检索工具，大模型怎么知道用哪个？
徐翔：两方面：第一，每个工具的描述、职责边界定义得非常详细，有明确的”适合用于”和”不适合用于”的指令；第二，Skills 里有专门的搜索策略引导。基本上大模型会灵活选择，我们不希望把它限制得太死。
观众：检索体系的反馈链路怎么构建？
徐翔：必须有 Benchmark，而且是基于内部数据集的。我们评测召回率等指标。另外提供可视化界面，用户可以自己做图的检索和交互式分析，反馈哪块出了问题。每次策略调整后，先在不影响用户的情况下自己跑一遍指标（采纳率、任务耗时等），没问题再上线。检索工具也支持用户自己配置开关，可以自由测试效果。
观众：AI 时代大家每天产出几万行代码，但对代码越来越不了解，线上出了故障怎么办？
徐翔：这个担心是真实的。解决方向有两个：第一，让智能体干活的过程更可视化、更透明，每一步都有留存，这样你有把控感；第二，一定要有评估者——不要让大模型自我感觉良好就草草结束，评估者去做评估后任务才算完成，甚至可以再加一路观察者，保证每个任务最终完成下来有质量保证和实际留存。
我们不应该让生产的系统超出团队的掌控和理解范围，现在的 Harness 工具给我们提供了很多能力，让我们更容易掌控 AI，让它按照我们的想法来实施。