Joycode 无法跨项目读取源码怎么办?MCP Easy Code Reader 帮你解决!

本篇文章主要介绍 MCP Server Easy Code Reader,它可以帮助你在使用 Joycode 编写代码时,根据调用链路将多个项目或 Jar 包中相关的代码读取到上下文中,供 Code Agent 帮我们分析逻辑和编写代码,而无需再手动将源码复制到对话框中发送给 AI,提高 Code Agent 准确度和编码效率。MCP 已发布 Github: easy-code-reader 和 Joycode MCP 市场,欢迎大家使用。在介绍如何接入 Easy Code Reader 之前,我们先来看看它到底能做什么:

Easy Code Reader 最佳实践

Easy Code Reader 特别适合与 Claude、ChatGPT 等大模型配合使用,接下来以 Joycode 结合 Claude4 为例,介绍最佳实践:

1. 跨项目调用,根据调用链路分析源码

在比较复杂的项目中一般会拆分多个微服务,某些功能的实现可能会跨多个项目调用,如果靠人梳理相关逻辑会比较耗时,所以可以将涉及的代码 clone 到本地后使用 Code Agent 结合 Easy Code Reader MCP 进行分析。接下来我们以实际业务项目为例,来通过两个例子来演示最佳实践:

解析跨项目的 JSF RPC 调用

我们先来看一个比较简单的例子,比如在本地应用 application-a 中存在以下调用逻辑,其中 YbServiceSubmitOrderPaasResource#submitOrderPaaS 是跨项目的 JSF RPC 调用:

@Slf4j
@Service
public class YbServiceSubmitOrderRpcImpl implements YbServiceSubmitOrderRpc {

    @Resource
    private YbServiceSubmitOrderPaasResource ybServiceSubmitOrderPaasResource;

    @Override
    public String newSubmitOrder(YbSubmitOrderReq submitOrderReq) {
        if (log.isInfoEnabled()) {
            log.info("[提交订单]请求开始,参数-submitOrderReq:" +JSON.toJSONString(submitOrderReq));
        }
        String result;
        try {
            Result<String> rpcResult = ybServiceSubmitOrderPaasResource.submitOrderPaaS(submitOrderReq);
            if (log.isInfoEnabled()) {
                log.info("[提交订单]rpc请求结束,结果-rpcResult:{}" , JSON.toJSONString(rpcResult));
            }
            if (rpcResult == null) {
                throw new RuntimeException("调用接口结果为空");
            }
            if (!rpcResult.getSuccess()) {
                throw new RuntimeException(rpcResult.getCode());
            }
            result = rpcResult.getData();
        } catch (Throwable t) {
            String logStr = "[提交订单]请求出错,参数-submitOrderReq:" +JSON.toJSONString(submitOrderReq);
            log.error(logStr, t);
            throw t;
        }
        if (log.isInfoEnabled()) {
            log.info("[提交订单]请求结束,结果-result:{}" , result);
        }
        return result;
    }
}

如果我想要了解 submitOrderPaaS的逻辑,那么我可能要打开相关的项目代码再去一步步找到对应的逻辑。但是如果借助 Easy Code Reader MCP Server 的话,那么便可以通过它来快速了解这个 RPC 接口的实现细节,下面是一个示例 Prompt:

你是一位 Java 技术专家,我想知道 @/xxx/YbServiceSubmitOrderRpcImpl.java 中调用的 Result<String> rpcResult = ybServiceSubmitOrderPaasResource.submitOrderPaaS(submitOrderReq); 方法实现逻辑是什么,这个方法真正的实现逻辑可能在本地项目的 rpc-pxxxorm 或 rpc-pxxxorm-export 中,请你使用 easy-code-reader MCP 检查相应地目录和文件,帮我找到核心实现逻辑并解释它的实现原理

在这里插入图片描述
在这里插入图片描述

如图所示,它会不断地根据源码调用链路,读取相关源码并进行分析,最终我们就能了解这个 RPC 接口的实现细节,在这个过程会使用到 MCP Easy Code Reader 提供的多个工具,使用 list_all_project 来找到对应的本地项目;使用list_project_files 查找可能相关的文件;使用 read_project_code来阅读源码,根据结果来总结实现原理。

解析消息驱动的分布式事务(协同式 Saga)

在这里我们让 Joycode 帮我们处理一个相对复杂的任务,在我们的业务中“某类型订单下单流程”使用了协同式 Saga 保证数据的一致性,在这个流程中跨越多个应用且流程复杂,我们可以借助 Joycode 帮我们从下单消息的接收开始分析,直到最终数据库收单完成。

开始任务时采用的是以下 Prompt,并且使用的是 “智能体团队” 智能体,这个智能体能开启多个任务,避免单一任务上下文太长:

你是一位 Java 技术专家,熟悉分布式事务的原理,我现在想了解“某类型订单下单流程”(不关注换货或退单),但是它的链路非常长,涉及的应用比较多,包括 yb-xxxde, yb-xxxrs, yb-xxxrm 和 lvxxxde 等本地应用,入口在 yb-xxxde 以 JMQ 消息的形式,它的主题是 pxx_xxx_xxxer 定义了 Order3csServiceHandler.java 消费者,请你根据源码分析,从这个消息消费,到调用 yb-xxxrs 再到 lvxxxde 落数据库订单的流程,你需要检查相关链路上的源码和配置文件(包括但不限于 jmq 或 jsf 配置),读取多个本地项目或依赖的 jar 包内容,在这个过程中你需要依赖 easy-code-reader 的 MCP 的能力,输出结果中请帮我画出接口调用的时序图,并告诉我在处理的过程中涉及那些具体的 JMQ 主题,JSF 接口和落数据库的表名

注意以下几点:
0. 每次创建子任务时需要使用编码智能体,这样才能使用 MCP 工具
1. 在读取项目文件时,请严格遵守使用 easy-code-reader MCP 的原则,不能自主扫描和读取应用代码,避免出现读错应用代码的情况
2. 如果遇到 jar 包需要读取,也需要使用 easy-code-reader MCP 的工具
3. “某类型订单下单流程”链路是自上向下的过程,由 yb-xxxde 到 yb-xxxrs 到 yb-xxxrm 到 lvxxxde,所以你在每分析完一个应用的逻辑后,会获取到衔接下一个应用的逻辑,请你记住这些衔接的逻辑,这些需要作为检查加一个项目的起点

它会执行一个时间非常长的任务,根据 消息 和 JSF RPC 接口的调用链路不断读取多个相关应用的相关代码,如下所示:

在这里插入图片描述

最终汇总出结果并绘制出 drawio 的流程图:

在这里插入图片描述

结果与业务流程基本一致,这会 极大的降低复杂系统的上手难度,加快开发者对现有微服务项目的理解。说实话我也对 AI 本次任务输出的结果感到吃惊,随着 AI 能力进一步的发展,处理任务的结果只会更好。

2. 阅读 jar 包源码,根据源码完成代码编写

在使用第三方或其他外部依赖时,Joycode Agent 并不能直接读取 jar 包中的源码,往往需要我们将源码内容手动复制到提示词中才能完成,费时费力。在 Easy Code Reader 中提供了 read_jar_source 工具来读取 jar 包中的源码,帮我们完成开发实现。我们在某项目中以如下提示词为例:

你是一位 Java 技术专家,请你使用 MCP 帮我读取 jar 包中 com.jd.xxx.OfflineInsureOrderResource 的源码信息

在提示词中我们并没有声明是哪个 Maven 依赖及其版本,但是它也能处理:

在这里插入图片描述

可以发现,它第一次读取时根据推测并没有找到实际的 Maven 依赖,而是通过读取 pom.xml 补偿了一次后读取到了。

3. 跨项目阅读源码,根据源码完成本项目实现

在大型项目中,某些功能的实现可能会跨多个模块或微服务,如果部分逻辑已经实现并且后续其他应用的逻辑需要依赖这部分逻辑时,可以借助 Easy Code Reader 读取相关模块的源码,帮助我们更好地理解和实现当前项目的功能,示例 Prompt 如下:

你是一位 Java 技术专家,现在我要实现 XXX 的业务逻辑,这部分逻辑的实现需要调用本地项目 A 中 XXX 的接口及其实现,请你借助 MCP easy-code-reader 来帮我读取 A 项目中的源码,并帮我实现 XXX 的业务逻辑

当然除了这几种场景以外,还可以使用 Easy Code Reader 完成以下事项:

  • 异常问题快速溯源:如果有异常信息是外部 jar 包依赖中抛出来的,可以使用 read_jar_source 工具根据异常堆栈日志快速定位异常点
  • 依赖升级影响评估(旧/新版本差异核对):同样是使用 read_jar_source 工具来完成新旧版本的实现差异,评估升级影响
  • 业务代码逻辑评审:如果业务逻辑开发实现在多个项目中,可以借助读取本地项目代码的工具 list_all_project、list_project_files 和 read_project_code,来分析新增的逻辑是否满足业务要求
  • 新人快速上手多个微服务:借助读取本地项目代码的工具,可以根据接口调用链路快速理清微服务项目代码之间的关系,提高上手速度

环境要求

既然它有这么多的应用场景,那么我们该如何接入 Easy Code Reader 呢?下面我们来介绍一下接入步骤,它的环境要求如下:

  • uv - Python 包和项目管理工具
  • Python 3.10 或更高版本(一般情况下,可以先安装 uv,安装成功后尝试启动 MCP Server,如果提示缺少 Python 环境再进行安装)
  • Java Development Kit (JDK) - 用于运行反编译器,要求至少 Java 8

如果您还没有安装 uv,可以通过以下方式快速安装:

# macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

或者参考 uv 官网 进行安装,并配置 uv 的安装路径添加到系统 PATH 中,以便可以直接使用 uv 命令。

快速接入(方法一):使用 uvx(推荐)

参考以下在 Joycode 中的 MCP 客户端配置,搜索 “Easy Code Reader”,点击安装:

在这里插入图片描述

注意以下两个参数变量的配置:

  • --maven-repo: 指定 Maven 仓库路径,将 /custom/path/to/maven/repository 内容替换为本地 Maven 仓库路径即可,不配置默认使用 MAVEN_HOME 目录或 ~/.m2/repository
  • --project-dir: 指定本地项目目录路径,将 /customer/path/to/project-dir 替换为实际保存所有项目的路径
{
  "mcpServers": {
    "Easy Code Reader": {
      "command": "uvx",
      "args": [
        "easy-code-reader",
        "--maven-repo",
        "/customer/maven-repository",
        "--project-dir",
        "/customer/path/to/project-dir"
      ]
    }
  }
}

将以上内容配置好后,AI 助手即可通过 MCP 协议调用 Easy Code Reader 提供的工具,完成多项目、多依赖的 Java 源代码读取工作。启动完成后,可以让 Joycode 执行 easy-code-reader://guide 命令获取使用指南 Resource,检查当前的配置是否为符合自己本地的目录配置:

在这里插入图片描述

快速接入(方法二):使用 uv 安装到本地

如果使用 快速接入(方法一) 安装运行失败,那么可以采用直接安装到本地的方法,运行如下命令:

uv tool install easy-code-reader

安装成功后,执行以下命令获取安装目录:

which easy-code-reader

比如,输出结果是:/Users/wangyilong13/.local/bin/easy-code-reader,那么需要按照如下方式配置 MCP 客户端,注意 args 参数配置,注意 args 参数配置,注意 args 参数配置:

{
  "mcpServers": {
    "easy-code-reader": {
      "command": "/Users/wangyilong13/.local/bin/easy-code-reader",
      "args": [
        "--maven-repo",
        "/custom/path/to/maven/repository",
        "--project-dir",
        "/customer/path/to/project-dir"
      ],
      "env": {}
    }
  }
}

一般这样操作都能完成安装,后续如果有版本更新,可以通过以下命令进行升级:

uv tool install --upgrade easy-code-reader

常见问题

Q1: spawn uvx ENOENT spawn uvx ENOENT

uv 命令未找到,确保已正确安装 uv 并将其路径添加到系统 PATH 中,参考 环境要求,并尝试重启 IDE 后再启动 MCP Server。

Q2: Downloading cpython-3.10.19-macos-aarch64-none (download) (17.7MiB) MCP error -32001: Request timed out

Python 环境下载失败,尝试手动下载或重试下载,或者参考 快速接入(方法二)。


以上内容就是 MCP Easy Code Reader 的介绍和接入方法,接下来的内容主要介绍一下它的实现原理,感兴趣的朋友可以继续往下看。

Easy Code Reader 实现原理

其实编写一个 MCP Server 并不复杂,大家可以参考这篇 Github 上的文章 Model Context Protocol(MCP) 编程极速入门。Easy Code Reader 通过 Python 语言实现,它提供了 4 个主要工具来协同完成源码读取工作:

  1. list_all_project: 列出所有本地项目,这个工具能将配置的项目目录 --project-dir 下所有的文件夹都读取出来,每个文件夹代表一个项目,这样 Code Agent 便能根据项目名称来选择需要读取的项目
  2. list_project_files: 列出指定项目中的所有文件名,这个工具能将指定项目下的所有源码文件名都读取出来,Code Agent 便能根据调用链路选择需要读取的文件
  3. read_project_code: 读取指定项目中的某个文件源码,通过以上两个工具,Code Agent 能够定位到需要读取的文件,然后使用这个工具将源码内容读取出来,供 Code Agent 进行分析
  4. read_jar_source: 读取指定 jar 包中的某个类源码,如果调用链路中有外部 jar 包依赖的话,Code Agent 便可以使用这个工具将 jar 包中的源码读取出来,供分析和编写代码

这四个工具协同工作,便能实现跨项目、多依赖的源码读取工作,帮助 Code Agent 更好地理解代码逻辑,从而提高代码编写效率和准确度,以下是 MCP Tool 实现的技术细节:

list_all_project

列举项目目录下所有的项目文件夹名称。

用途:

  • 查看所有可用的项目
  • 当输入不完整的项目名时,帮助推理出最接近的项目名
  • 验证项目是否存在
  • 支持项目名称模糊匹配,快速查找特定项目

参数:

  • project_dir (可选): 项目目录路径,如未提供则使用启动时配置的路径

  • project_name_pattern (可选): 项目名称模糊匹配模式(不区分大小写),用于过滤项目列表

    • 支持左右模糊匹配,例如 nacos 将匹配包含 nacos、Nacos、NACOS 的项目名
    • ⚠️ 使用建议:如果匹配模式过于严格可能导致遗漏目标项目
    • 💡 最佳实践:若未找到预期结果,建议不传此参数重新查询完整列表

智能提示机制:

  • 当使用 project_name_pattern 但未匹配到项目时,返回结果会包含提示信息
  • 建议 AI 助手在未找到预期项目时,不传 project_name_pattern 参数重新查询
  • 有效减少因过度过滤导致的查询失败

示例 1 - 列出所有项目:

{}

示例 2 - 使用项目名称模糊匹配:

{
  "project_name_pattern": "spring"
}

返回格式:

{
  "project_dir": "/path/to/projects",
  "project_name_pattern": "spring",
  "total_projects": 2,
  "projects": [
    "spring-boot",
    "spring-cloud-demo"
  ],
  "hint": "已使用项目名称模式 'spring' 进行过滤。如果未找到预期的项目,可能是模式匹配过于严格。建议:不传入 project_name_pattern 参数重新调用 list_all_project 工具查看完整项目列表。",
  "total_all_projects": 5
}

提示信息说明:

  • 当使用 project_name_pattern 但未匹配到任何项目时,hint 字段会提示模式可能过于严格,并显示总项目数 total_all_projects
  • 当使用 project_name_pattern 且有匹配结果时,hint 字段会提醒如果结果不符合预期可以不传参数重新查询,同时显示总项目数
  • 这个智能提示机制帮助 AI 助手更好地调整查询策略,避免因过度过滤错过目标项目
list_project_files

列出 Java 项目中的源代码文件和配置文件路径。

用途:

  • 了解项目结构和文件组织
  • 查找特定的类或配置文件
  • 分析类之间的关系和依赖
  • 当项目文件过多时,聚焦特定模块
  • 支持文件名模糊匹配,快速定位目标文件

支持两种模式:

  1. 全项目模式(不指定 sub_path):列出整个项目的所有文件
  2. 聚焦模式(指定 sub_path):只列出指定子目录下的文件

参数:

  • project_name (必需): 项目名称,例如 nacos

  • sub_path (可选): 指定项目内的子目录路径,例如 core 或 address/src/main/java

  • file_name_pattern (可选): 文件名模糊匹配模式(不区分大小写),用于进一步过滤文件列表

    • 支持左右模糊匹配,例如 Service 将匹配包含 service、Service、SERVICE 的文件名
    • ⚠️ 使用建议:如果匹配模式过于严格可能导致遗漏目标文件
    • 💡 最佳实践:若未找到预期结果,建议不传此参数重新查询完整列表
  • project_dir (可选): 项目所在的父目录路径,如未提供则使用启动时配置的路径

自动过滤内容:

  • ✅ 包含:Java 源代码 (.java)、配置文件 (.xml, .properties, .yaml, .json 等)、构建脚本、文档
  • ❌ 排除:测试目录 (src/test)、编译产物 (target, build)、IDE 配置、版本控制文件

智能提示机制:

  • 当使用 file_name_pattern 但未匹配到文件时,返回结果会包含提示信息
  • 建议 AI 助手在未找到预期文件时,不传 file_name_pattern 参数重新查询
  • 有效减少因过度过滤导致的查询失败

示例 1 - 列出整个项目:

{
  "project_name": "nacos"
}

示例 2 - 只列出 core 模块:

{
  "project_name": "nacos",
  "sub_path": "core"
}

示例 3 - 使用文件名模糊匹配:

{
  "project_name": "nacos",
  "file_name_pattern": "Service"
}

返回格式:

{
  "project_name": "nacos",
  "project_dir": "/path/to/projects/nacos",
  "search_scope": "core",
  "file_name_pattern": "Service",
  "total_files": 15,
  "files": [
    "core/src/main/java/com/alibaba/nacos/core/service/NacosService.java",
    "api/src/main/java/com/alibaba/nacos/api/naming/NamingService.java",
    "..."
  ],
  "hint": "已使用文件名模式 'Service' 进行过滤。如果未找到预期的文件,可能是模式匹配过于严格。建议:不传入 file_name_pattern 参数重新调用 list_project_files 工具查看完整文件列表。"
}

提示信息说明:

  • 当使用 file_name_pattern 但未匹配到任何文件时,hint 字段会提示模式可能过于严格
  • 当使用 file_name_pattern 且有匹配结果时,hint 字段会提醒如果结果不符合预期可以不传参数重新查询
  • 这个智能提示机制帮助 AI 助手更好地调整查询策略,避免因过度过滤错过目标文件
read_project_code

从本地项目目录中读取指定文件的源代码或配置文件内容。

用途:

  • 读取具体类或文件的完整源代码
  • 查看配置文件内容(pom.xml、application.yml、application.properties 等)
  • 读取项目文档(README.md、SQL 脚本等)
  • 支持多模块 Maven/Gradle 项目
  • 自动搜索常见的源代码和配置文件路径

参数:

  • project_name (必需): 项目名称,例如 my-project

  • file_path (必需): 文件标识符:可以是完全限定的 Java 类名或文件相对路径

    • Java 类名格式:com.example.MyClass (自动查找对应的 .java 文件)
    • 相对路径格式:src/main/java/com/example/MyClass.java
    • 模块相对路径:core/src/main/java/com/example/MyClass.java
    • 配置文件路径:src/main/resources/application.yml、pom.xml
    • 文档文件:README.md、docs/setup.md
  • project_dir (可选): 项目目录路径,如未提供则使用启动时配置的路径

支持的文件类型:

  • Java 源代码 (.java)
  • 配置文件 (.xml, .properties, .yaml, .yml, .json, .conf, .config)
  • 构建脚本 (.gradle, .gradle.kts, pom.xml)
  • 文档文件 (.md, .txt)
  • SQL 脚本 (.sql)
  • Shell 脚本 (.sh, .bat)

自动搜索路径:

  • 对于 Java 类名:src/main/java/{class_path}.java、src/{class_path}.java、{class_path}.java
  • 对于配置文件:项目根目录、src/main/resources/、src/、config/ 及子模块
  • 支持多模块项目中的子模块路径

推荐工作流程:

  1. 使用 list_all_project 确认项目存在
  2. 使用 list_project_files(建议带 file_name_pattern 参数)查看文件列表
  3. 使用本工具读取具体文件内容

示例 1 - 使用类名读取 Java 源代码:

{
  "project_name": "my-spring-app",
  "file_path": "com.example.service.UserService"
}

示例 2 - 使用相对路径读取 Java 文件:

{
  "project_name": "nacos",
  "file_path": "address/src/main/java/com/alibaba/nacos/address/component/AddressServerGeneratorManager.java"
}

示例 3 - 读取配置文件:

{
  "project_name": "my-spring-app",
  "file_path": "src/main/resources/application.yml"
}

示例 4 - 读取项目根目录的文件:

{
  "project_name": "my-spring-app",
  "file_path": "pom.xml"
}

返回格式:

{
  "project_name": "my-spring-app",
  "class_name": "com.example.service.UserService",
  "file_path": "/path/to/projects/my-spring-app/src/main/java/com/example/service/UserService.java",
  "code": "package com.example.service;\n\nimport ...\n\npublic class UserService {\n    // ...\n}"
}
read_jar_source

从 Maven 依赖中读取 Java 类的源代码(优先从 sources jar,否则反编译)。

参数:

  • group_id (必需): Maven group ID,例如 org.springframework
  • artifact_id (必需): Maven artifact ID,例如 spring-core
  • version (必需): Maven version,例如 5.3.21
  • class_name (必需): 完全限定的类名,例如 org.springframework.core.SpringVersion
  • prefer_sources (可选,默认 true): 优先使用 sources jar 而不是反编译

工作原理:

  1. 首先尝试从 -sources.jar 中提取源代码(如果 prefer_sources=true)
  2. 如果 sources jar 不存在或提取失败,自动回退到反编译主 JAR 文件
  3. 支持 SNAPSHOT 版本的智能处理

智能错误提示:

当 JAR 文件未找到时,工具会提供详细的排查建议:

  • 提示可能的原因(依赖未安装、Maven 坐标错误)
  • 建议使用 read_project_code 工具读取项目的 pom.xml 文件
  • 指导在 <dependencies> 部分核对正确的 Maven 坐标
  • 提示确认坐标后重新调用工具
  • 说明可能需要执行 Maven 构建命令安装依赖

这个智能提示机制特别适合与 AI 助手配合使用,能有效减少因 Maven 坐标错误导致的重复尝试。

示例:

{
  "group_id": "org.springframework",
  "artifact_id": "spring-core",
  "version": "5.3.21",
  "class_name": "org.springframework.core.SpringVersion"
}

返回格式:

{
  "class_name": "org.springframework.core.SpringVersion",
  "artifact": "org.springframework:spring-core:5.3.21",
  "source_type": "sources.jar",
  "code": "package org.springframework.core;\n\npublic class SpringVersion {\n    // ...\n}"
}

source_type 字段说明:

source_type 字段标识源码的来源,帮助 AI 助手了解代码的可靠性和新鲜度:

  • "sources.jar": 从 Maven 的 sources JAR 文件中提取(最可靠,与发布版本完全一致)
  • "decompiled": 通过反编译器新反编译生成(可能存在反编译不完整的情况)
  • "decompiled_cache": 从之前反编译的缓存中读取(避免重复反编译,提升性能)

💡 使用建议:

  • sources.jar 来源的代码最准确,可直接作为分析依据
  • decompiled 来源的代码可能会有语法糖恢复、泛型擦除等反编译特征
  • decompiled_cache 与 decompiled 质量相同,只是从缓存读取以提升效率
反编译器选择与缓存机制

read_jar_source 工具支持多个反编译器,并根据 Java 版本自动选择最合适的:

Java 版本推荐反编译器说明
8 - 20CFR自动使用 CFR 反编译器(兼容 Java 8+),已包含在包中:src/easy_code_reader/decompilers/cfr.jar
21+Fernflower自动使用 Fernflower 反编译器(IntelliJ IDEA 使用的反编译器),已包含在包中:src/easy_code_reader/decompilers/fernflower.jar

反编译后的文件会被缓存在 JAR 包所在目录的 easy-code-reader/ 子目录中,例如:

如果 JAR 包位置为:

~/.m2/repository/org/springframework/spring-core/5.3.21/spring-core-5.3.21.jar

反编译后的源文件将存储在:

~/.m2/repository/org/springframework/spring-core/5.3.21/easy-code-reader/spring-core-5.3.21.jar

缓存文件本身也是一个 JAR 格式的压缩包,包含所有反编译后的 .java 文件,这样可以避免重复反编译相同的 JAR 包,提高性能。但 针对 SNAPSHOT 版本需要特殊处理: 因为 Maven 针对快照版本会生成带时间戳的 JAR(如 artifact-1.0.0-20251030.085053-1.jar),Easy Code Reader 会自动查找最新的带时间戳版本进行反编译,并且以缓存以 artifact-1.0.0-20251030.085053-1.jar 名称存储,提供版本判断的依据,当检测到新版本时,会自动清理旧的 SNAPSHOT 缓存,生成新的缓存文件。


巨人的肩膀

相关推荐

AI 会写代码之后,交付为什么还没变快?

AI 写代码,只是这场变革的起点,而不是终点。真正决定一个组织能否吃到 AI 红利的,不是"能不能用 AI 写出代码",而是敢不敢用 AI 重新设计交付流程、重新划分角色分工、重新组织团队结构。研发视角能把工具和个人推到极致,却会在组织的边界前止步;只有站上组织视角,把AI × 工具一路推进到AI × 组织,那些被 AI 照出来的摩擦,才会真正被抹平。国际技术部 Multi AI Native 想做的,正是这件事——让 Agent 成为你可靠的数字战友,让每一次迭代交付都快一个量级;

京东科技开发者 249

OxygenData-Vibe搭建:用 AI Coding重新定义数据看板搭建

长期以来,数据看板开发主要有两种方式:一种是使用标准化 BI 工具,交付快、成本低,但图表样式、交互体验和功能扩展都受限于 BI 本身的能力;另一种是自研定制开发,能够充分满足复杂和个性化需求,但需要投入大量研发资源,交付周期也更长。比如一个通过 BI 只需要 1 天就能搭建出来的看板,如果采用自研方式,可能需要投入 30 PD 的研发人力。既然 BI 交付这么快,为什么不把所有看板需求都交给 BI?原因在于,业务某些场景需要的不只是把数据展示出来。

京东科技开发者 311

当我谈数据库高可用时我谈些什么

大家都经常听到说数据库的双1,那双1指的是什么呢?参数=1(最安全)≠1(更快但可能丢)每次提交都把 redo 刷盘0/2:攒着刷,崩溃丢最近 1 秒每次提交都把 binlog 刷盘0/N:攒着刷,崩溃丢最近若干条"双 1"(都设为 1)= 单机不丢已提交事务的前提。生产核心库必须双 1;代价是每次提交两次 fsync。小结:单机层用 WAL 提速、用 2PC 保证 redo/binlog 一致、用崩溃恢复裁决半成品事务、用双 1 兜底持久性。

京东科技开发者 274

ScoAI:面向供应链的运筹原生决策智能

ScoAI 关注的并非 AI 能否进入供应链,而是 AI 参与供应链决策之后,哪些内容适合通过数据学习,哪些关系必须显式计算,以及哪些结果需要依据执行记录进行验证。其基本分工是:供应链业务定义问题、资源与行动后果,运筹学表达目标、约束和协同关系,AI 提供可复用的估计与判断。真正用于改进后续决策的,不仅是模型生成的初始结果,还包括实际采取的行动及其产生的业务反馈。

京东科技开发者 369

拆解海博 AI-Native 落地保障:海博团队 AI 知识库能力建设

绕了一大圈,回头看,我们其实一直在解开头那三个结:AI 读不懂系统、影响面靠人脑记、测试预期没处查。做到这里,本质上是把"AI 用不好"这个问题,从"是不是该换个更强的模型"重新定义成了"怎么把上下文经营好"。顺着这个思路,我们攒下了这么几样东西:•。

京东科技开发者 521

从零构建一个生产级记忆型 AI Agent —— AgentScope 项目全景技术与学习指南

domain 层端口接口(domain)职责适配器实现(infra)对话流水账读写经验记忆检索/落库请求级幂等四态会话元数据 CRUD会话级 Skill 选择态Skill 元数据HITL 权限网关(domain 内含逻辑,见第四篇)StreamSink技术中立的流式下沉(client 层桥接)以幂等端口为例,头部注释明确写道:实现 domain 端口,持有实体不出 infra 边界,对外只暴露嵌套视图GateResult。

京东科技开发者 572

数据涅槃:Agentic 重塑搜推数据生产体系

当前大模型已经能够理解需求、生成代码和解释错误,但数据生产的难点并不只是“写出一段 SQL”。一个需求还要经过数据源确认、口径澄清、加工编排、资源规划、任务提交、调度运行、结果交付和故障处置。任何一步缺少都可能让“看起来正确”的任务变成生产事故。

京东科技开发者 338

81.8 秒的视频,我们改了 15 个版本:一次纯 Codex 驱动的 AI-native 视频实践

81.8 秒、15 个版本,这些数字真正想说明什么?视频制作正在从一组专业软件里的复杂操作,变成一场围绕目标、参考和反馈展开的持续对话。AI 已经可以接住从脚本到交付的大量工作。你可以把精力留给更重要的部分:理解观众、选择故事、判断好坏。过去停在 PPT 和脑海里的想法,现在有机会被快速做成一支能看、能改、也愿意转发的视频。如果明天就要介绍你手头的项目,你最想先把哪一步交给 AI?

京东科技开发者 434

Codex 驱动的移动端AI全栈开发:从 Relay 原型图到可交付链路

AI 编程工具降低了跨端开发门槛,但“让 AI 写页面”并不等于“完成移动端交付”。PC 运营端页面通常以功能闭环为中心,设计约束较弱,研发可以基于组件库快速搭建;移动端 C 端页面直接面对用户,Relay 原型图和 UI 设计稿不仅是视觉参考,更是交互、信息层级、状态反馈和业务信任感的综合契约。

京东科技开发者 568

Claude Code vs Codex 记忆体系深度对比

Claude Code —— 分层自动记忆系统四层分层架构(CLAUDE.md / Auto Memory / Session Memory / AutoDream)构成自优化闭环,系统主动捕获、分类、去冗并跨会话接力经验。走的是自动化优先路线——让机器替人记忆、替人整理,以少量可控性的不确定换取强大的经验积累能力。Codex —— 声明式契约系统两层扁平架构(AGENTS.md 静态声明层 + 会话上下文层),记忆完全由人显式订立、显式修改,系统只读契约、绝不擅自变更。走的是可控性优先。

京东科技开发者 606

上游给空、下游拿到 -1,我把故障一直追到了 commons-beanutils 的构造函数

这篇手记是一份事后复盘,写在我们已经把修复推上线、把测试用例跑绿、把约束文档沉淀进团队库之后。非研发同事,可以直接从第八章开始看,前七章都是讲排障和代码分析。故障本身不复杂,修复也不复杂,但这次排查真正让我想写下来的,不是技术本身——而是从问题提报到解决全程AI的作用:问题定位:业务方反馈了一个异常单号说「下发失败」,一线运维同事直接在日志系统捞到相关的系统日志,用IDE打开下游代码库,把异常信息给到JoyCode——AI 直接指向了问题是serialType值非法,系统只接受0和1,而当前上游给的是-1。

京东科技开发者 704

SKill测评:谁才是真正的Skill之王?

巧合的是,阿里近期开源了一款名为 Skill-Up 的测评工具——它专门面向 Agent Skill 开发者,支持在 Claude Code、Codex、Qoder CLI 等真实 Agent Engine 环境中验证 Skill 的功能正确性,并可将失败用例转化为精准的修复指引,同时支持本地与 CI 环境的持续回归。2026年,Skill 的热度不减,已成为 AI 辅助编程领域的标配。在日常研发中,无论是沉淀个人经验,还是将团队的优秀范本标准化,将知识“蒸馏”为 Skill 已是大家的常规操作。

京东科技开发者 619

让AI真正参与工作!JoyDesk已上线京东云

JoyDesk提供覆盖AI资产管理、权限控制、安全策略、审批审计、运营监控等企业级治理能力,支持按组织、角色和项目进行精细化权限管理,并支持私有化部署,确保企业数据边界清晰、AI行为全程可追溯、安全策略灵活可配置,满足金融、政企等行业对数据安全和合规治理的要求,让AI真正成为企业可信赖的生产力。JoyDesk支持MCP协议、标准API、技能等多种开放接入方式,可快速连接企业现有业务系统,将业务能力封装为AI可调用的技能和专家,让AI能够理解业务流程、调用业务系统、完成业务任务,而无需改变企业原有IT架构。

京东科技开发者 656

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手【最终版】

这个项目展示了AI Agent 在垂直内容创作领域端到端自动化:从内容理解到播客输出,全流程 AI 驱动多模态融合:文字、图片、音频、视频统一处理专业级音频质量:音色设计 + 智能混音,输出广播级品质低门槛使用:可视化配置 + 自然语言交互,无需技术背景。

京东科技开发者 557

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手(高级篇)

这是一个 AI 驱动的播客创作助手,专注于从文字/视频/音频内容识别到播客制作的全流程。你可以用自然语言与它对话,也可以上传视频和音频,它会理解意图、调用相应的语音合成工具,把他们变成真实的播客音频。

京东科技开发者 721

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手(进阶篇)

这是一个AI 驱动的音频内容创作助手。你可以用自然语言与它对话,它会理解意图、调用相应的语音合成工具,把文字变成真实的播客音频,并保存在本地。关于项目的详细介绍见第一篇文章:第一个 AI Agent 项目:从零搭建 AI 音频创作助手(入门篇)这篇文章更多介绍进阶篇添加的功能。

京东科技开发者 545

【全栈实践】第一个 AI Agent 项目:从零搭建 AI 音频创作助手(入门篇)

这个项目让我第一次把前端、后端、AI Agent 三块内容独立串联起来。技术选型上每一块都是当下主流的方案,实际跑通整条链路之后对"全栈"有了更具体的感受。框架版本要锁定:LangChain 这类快速迭代的框架,版本差异带来的问题远比你想象的多先跑通链路,再追求完美:新手阶段能把用户输入 → AI 处理 → 结果展示这条链跑通,比深入某个技术点更有价值多看官方文档:相比博客和教程,官方文档更新及时,特别是 LangGraph 这种新框架后续计划继续迭代,欢迎交流!

京东科技开发者 603

ICLR 2026 | 面向序列决策的贝叶斯集成方法

在这篇工作中,我们关注的是。

京东科技开发者 294

ICML 2026|NaviAgent:面向 Oxygen 智能体的可扩展工具编排

大型语言模型(LLM)越来越多地作为函数调用代理,调用外部工具来处理超出其静态知识范围的任务。然而,它们通常一次只调用一个工具,缺乏对任务结构的全局视图。由于工具之间往往相互依赖,这会导致错误累积和可扩展性差,尤其是在扩展到数百或数千个工具时。为了解决这些局限性,我们提出了NaviAgent,一种显式的双层架构,它通过基于图的工具关系建模将任务规划与工具执行解耦。在规划层,基于 LLM 的代理决定是直接响应、澄清意图,还是检索并执行一个独立于工具间复杂性的工具链。

京东科技开发者 384

实测 9 款 AI 架构图工具:从 Mermaid 美化到 GPT-Image2,一份选型清单

支持 5 类图(架构图、工作流图、时序图、数据流图、生命周期/状态机图),主题 4 种(Classic、Signal Flow、Blueprint、Editorial)+ 3 种色彩模式(Dark / Light / System Auto),输出格式含 HTML、PNG、SVG、WebM、Share Card PNG、JSON IR。它把提示词图库、图像生成案例、参考图编辑流程和命令行工具整合在一起,让 AI Agent 能直接调用 GPT Image 2 模型完成文生图、图生图、参考图编辑等任务。

京东科技开发者 898

别再守着 Claude Code 了——学会指挥它自主干活

回到开头那句:别再一句一句地喂它、然后守着屏幕。真正的用法是——把一件事想清楚、划好边界、给它一个能自我验证的目标,然后交出去。你会发现,省下来的时间不是一点半点。把重复的判断和执行还给机器,把真正需要你的判断留给自己。

京东科技开发者 584

CVPR 2026|Oxygen XR 团队在原生鱼眼高斯泼溅技术上带来新突破

京东零售技术团队联合清华大学提出DirectFisheye-GS框架,创新性地将鱼眼相机模型原生嵌入3D高斯泼溅管线,通过跨视角联合优化策略直接处理鱼眼图像,避免了传统去畸变预处理导致的信息损失。该方案在多个公开数据集上达到SOTA性能,有效解决了单视角优化引起的几何畸变和视角不一致问题,同时保持与现有3DGS工具链的兼容性。技术已应用于电商3D重建和4D体积视频等场景,显著提升了沉浸式体验。相关论文被CVPR 2026接收,为宽视场场景重建提供了高效解决方案。

京东科技开发者 354

拆解海博 AI-Native 落地保障:Harness、双 Loop、知识库与技能自主迭代实践

海博研发RoadMap 的落地,彻底终结了 AI 编程“对话式玄学”的旧模式,真正落地了AI Native 研发工程化。它证明 AI 规模化赋能研发的核心,不在于堆砌大模型能力,而在于用工程思维重构 AI 的工作范式:用结构化流程替代随机对话,用固化规则约束模型行为,用持续沉淀实现能力复利,用分层架构支撑规模化落地。

京东科技开发者 634

让 AI 快速「读懂」你的代码仓:Joy-Code-Graph 云端图谱服务的三次进化

代码知识图谱不是要取代 AI 的智能,而是要补齐它对代码全局关系的认知盲区。当 AI 能一眼看清「谁调用了谁、改动会波及哪里」,它写出的代码才真正靠谱;当这份认知安全地留在自己手里、随时被 Joygen 调用、并且永久沉淀在代码仓里——AI 编程的体验,才算真正上了一个台阶。这,就是我们做 Joy-Code-Graph 云端服务的初衷。能力共享,数据自主;一次建图,长期受用。

京东科技开发者 751

【Coding生态】从代码托管到 AI 能力底座:与Coding一起共建 AI 研发生态

前两种框架能够很好地支撑对话式能力和预设流程式能力。它们适合基于提示词或预设工作流完成研发问答、知识查询、流程编排等任务。但在更复杂的研发场景中,仅仅“回答问题”还不够。当用户业务逻辑复杂时,一旦场景进入真实落地阶段,例如下载代码、修改文件、执行命令、安装依赖、运行测试、读取完整代码文件,或者与自有系统联动、将结果渲染到 Coding 页面、推送到京 ME,AI 应用需要的不只是知识能力,还需要真实的代码库操作能力和独立可执行环境。

京东科技开发者 768

GPT-5.6、ChatGPT Work 与 Codex 更新食用指南

三档模型当前都提供 1,050,000 tokens 上下文、922,000 tokens 最大输入和 128,000 tokens 最大输出,接受文本与图像输入、输出文本,并支持 web search、file search、Computer Use、MCP、Tool Search、Skills、Apply Patch 等工具。Work 可以读取你提供的文件,通过插件连接 Slack、Google Drive、SharePoint、邮箱、日历、CRM 或项目系统,调用获批工具,并在执行中展示进度。

京东科技开发者 860

把业务流程沉淀成高质量 Skill 的实践路径

使用Record & Replay创建的Skill,尽管创建流程简单,但它的本质实际是让 AI 去操作页面,这不但有可能影响我们对电脑的操作,还有可能无法稳定复现。创建Skill时,可以使用 Codex 的 Record & Replay 插件,把一次手工操作录下来,再让 AI 生成可复用流程。刚开始切换时,很容易遇到接口报错,可以让Codex排查原因进行优化,直到可以稳定执行;补充相应业务背景,说明这件事为什么要做,谁会用,输入从哪来,输出给谁看。电脑休眠、关机、软件没开时,本地任务可能无法执行。

京东科技开发者 835

政企前台AI-Agent的架构实践:打造可复用的 AI 服务平台-【灯塔计划】

不止是爆火的龙虾,还是各种Skills,MCP、Agent,脱离的具体的场景谈方案,最后只会是一场空。这一套可复用的 AI 服务平台,截止目前,通过前后端对接规范文档,多项能力已快速接入到各个场域的不同端平台,大幅降低研发成本, 并且各业务线新场景的接入从原来的 “开发驱动” 转为 “配置驱动”,接入周期从天维度缩短至小时级。

京东科技开发者 860

京东 Oxygen xLLM 大模型推理引擎正式捐赠开放原子开源基金会,共建国产 AI Infra 生态

下一阶段 AI 基础设施的核心命题,不是简单的算力堆叠,而是让工程本身变得智能——让调度系统能自主感知负载特征并动态优化,让推理引擎能根据模型结构和硬件特性自动生成最优执行方案,让整个 AI 工程链路具备自感知、自决策、自优化的能力。未来,Oxygen xLLM 的项目官网、社区沟通渠道及微信社区将陆续向开发者开放,诚邀芯片厂商、模型厂商、云厂商、企业用户及个人开发者共同参与,让国产大模型推理引擎在开放生态中加速成长。硬件层,原生支持 GPU / NPU / MLU 多类 AI 芯片,深度适配国产芯片。

京东科技开发者 1000

【京东云】全球首个!京东全栈开源JoyAI-VL-Interaction,让大模型从“一问一答”走向“边看边说”

开源一套系统,而不只是一个模型在实时视频流中,JoyAI-VL-Interaction每秒都会做一次判断,比如,继续观察、保持沉默,发现关键事件、主动回应,遇到复杂任务,交给后台Agent处理。一个好的AI 助手,不应该一直打扰用户,而应该知道什么时候该出现,什么时候该安静,以及什么时候自己解决,什么时候交由agent解决。深耕零售、物流、健康、工业等实体产业二十余年,京东拥有全球领先的物理世界运营网络,覆盖仓储、配送、门店、直播、客服、售后海量真实场景,每天都在发生人、货、场的实时互动。

京东科技开发者 1029
上一篇: 宝剑锋从磨砺出——零售数据库内核,为大促铸剑!
下一篇: 多智能体设计模式和智能体框架,你会了么?
京东云开发者
京东云开发者 企业官方账号 企业官方账号
博客等级 码龄8年 1万+粉丝 2139原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值