大家好，我是专注于分享技术实战经验的博主。在构建复杂业务系统时，你是否遇到过这样的困扰：任务调度逻辑与业务代码深度耦合，定时任务、延迟任务、工作流编排等需求散落在各处，导致代码难以维护、监控困难、扩展性差？今天，我们就来深入探讨一个由字节跳动开源的分布式任务调度框架—— Deer-Flow 。本文将带你从零开始，全面解析其核心概念、架构设计，并通过一个完整的Spring Boot集成实战案例，手把手教你如何搭建、配置和使用Deer-Flow，让你能轻松应对企业级任务调度场景，提升系统架构的清晰度和可维护性。

1. Deer-Flow 核心概念与背景

1.1 什么是 Deer-Flow？

Deer-Flow 是一个由字节跳动贡献给开源社区的、轻量级且功能强大的分布式任务调度框架。它的名字寓意着像鹿一样敏捷、流畅地处理任务流。与传统的单一任务调度器（如 Quartz、XXL-Job）相比，Deer-Flow 更侧重于 工作流 的编排与调度。它允许你将多个独立的任务（Task）按照特定的依赖关系和逻辑（如顺序、并行、条件分支）组织成一个有向无环图（DAG），然后由调度引擎统一、可靠地执行。

简单来说，你可以把 Deer-Flow 想象成一个“乐高积木”的组装平台。每个积木（任务）完成一项具体工作（如发送邮件、清洗数据、调用API），而 Deer-Flow 提供了图纸（DAG定义）和组装流水线（调度引擎），确保这些积木能按照正确的顺序和逻辑拼装成最终的作品（业务流程）。

1.2 它解决了什么问题？

在微服务和分布式架构成为主流的今天，业务逻辑的复杂性日益增长，传统的任务调度方式面临诸多挑战：

  1. 硬编码与耦合 ：在业务代码中直接使用 @Scheduled 注解或 Timer，调度逻辑变更需要修改代码并重启服务。
  2. 缺乏可视化与可观测性 ：任务执行状态、历史记录、失败重试情况难以直观查看和追踪。
  3. 任务依赖管理复杂 ：任务B需要在任务A成功后才能执行，这种依赖关系如果手动编码维护，会变得极其脆弱和混乱。
  4. 容错与高可用能力弱 ：单点调度器存在故障风险，任务失败后的重试、报警机制需要自行实现。
  5. 资源隔离与扩展性差 ：所有任务共享同一个线程池，一个耗时任务可能阻塞其他关键任务。

Deer-Flow 正是为了系统性地解决这些问题而生。它通过中心化的调度服务器和分布式的执行器，实现了任务定义、调度触发、依赖管理、状态追踪、失败重试等功能的解耦与标准化。

1.3 核心应用场景

  • 数据管道与ETL ：定时从多个数据源抽取数据，经过清洗、转换、校验等多个步骤后，加载到数据仓库。
  • 报表系统 ：在每日凌晨，依次执行用户统计、订单汇总、财务对账等多个计算任务，最终生成业务报表。
  • 业务状态机与流程引擎 ：例如订单处理流程（创建订单 -> 风控检查 -> 扣减库存 -> 通知发货），每个环节都是一个可调度的任务。
  • 分布式批处理 ：将一个大任务拆分成多个可以并行执行的子任务，充分利用集群资源，加速处理过程。
  • 微服务间的协同作业 ：协调多个微服务按特定顺序完成一项跨服务业务操作。

2. 环境准备与版本说明

在开始实战之前，请确保你的开发环境满足以下要求。本文的示例将基于最常见的Java技术栈。

  • 操作系统 ：Windows 10/11, macOS, 或 Linux (如 Ubuntu 20.04+)。本文命令以 Linux/macOS 的 bash 为例，Windows 用户可使用 Git Bash 或 WSL。
  • Java ：JDK 8 或 JDK 11。建议使用 OpenJDK 或 Oracle JDK 的 LTS 版本。本文示例使用 JDK 11。 
    java -version
# 输出应类似：openjdk version "11.0.19" ...
  • 构建工具 ：Apache Maven 3.6+ 或 Gradle。本文使用 Maven。 
    mvn -v
# 输出应类似：Apache Maven 3.8.6 ...
  • IDE ：IntelliJ IDEA, Eclipse 或 VS Code。推荐使用 IntelliJ IDEA 以获得更好的 Spring Boot 支持。
  • 数据库 ：MySQL 5.7+ 或 PostgreSQL。Deer-Flow 调度服务器需要数据库来存储任务定义、执行记录等元数据。本文使用 MySQL 8.0。
  • 消息队列（可选，用于高级模式） ：RocketMQ, Kafka, Pulsar。Deer-Flow 可以利用消息队列进行任务派发，提升可靠性和解耦程度。入门演示可不配置。
  • Deer-Flow 版本 ：我们将使用其 GitHub 仓库中较新的稳定版本。由于开源项目迭代较快，请以官方发布版本为准。本文示例思路基于其核心 API 设计，具体依赖版本请在 Deer-Flow GitHub Releases 页面查看并替换。

重要提示 ：以下所有步骤和代码均为演示核心流程和配置思路。在实际项目中，请务必根据你选择的 Deer-Flow 具体版本号，调整 Maven 依赖和配置项。版本差异可能导致部分类名或配置属性发生变化。

3. Deer-Flow 架构与核心概念拆解

要用好 Deer-Flow，必须理解其核心组件和它们之间的交互关系。

3.1 系统架构

Deer-Flow 采用经典的主从（Master-Slave）架构，主要分为两部分：

  1. Deer-Flow Server (调度服务器) ：负责任务工作流（DAG）的定义、解析、调度触发和状态管理。它提供了管理控制台（Web UI）和 RESTful API。Server 是无状态的，可以部署多个实例以实现高可用，它们共享同一个数据库。
  2. Deer-Flow Executor (执行器) ：负责具体任务的执行。执行器需要嵌入到你的业务应用中（作为一个 Client），或者独立部署。它定期向 Server 拉取分配给自己的任务，执行完毕后向 Server 汇报结果。一个集群中可以注册多个执行器。
+-------------------+      HTTP / RPC      +----------------------+
|                   | <-------------------> |                      |
|  Deer-Flow Server |                      |  Your Business App 1 |
|  (Scheduler)      |      Task Pull       |  (with Executor)     |
|  +-------------+  | <-------------------> |                      |
|  |   Web UI    |  |      & Report        +----------------------+
|  +-------------+  |                            ...
|                   |      HTTP / RPC      +----------------------+
|  Meta Database    | <-------------------> |                      |
|  (MySQL/Postgres) |                      |  Your Business App N |
+-------------------+                      |  (with Executor)     |
                                           +----------------------+

3.2 核心概念详解

  • 工作流（Workflow） ：调度和管理的最高层级单元。一个工作流对应一个完整的业务流程，由多个任务和它们之间的依赖关系构成。
  • 任务（Task） ：工作流中的最小执行单元。每个任务代表一个具体的操作，例如执行一段 Java 方法、调用一个 HTTP 接口、运行一个 Shell 脚本等。Deer-Flow 支持多种任务类型。
  • DAG（有向无环图） ：用于描述工作流中任务依赖关系的数据结构。它定义了任务的执行顺序和并行路径，确保不会出现循环依赖。
  • 任务实例（Task Instance） ：每次工作流被触发运行时，其中的每个任务都会生成一个对应的任务实例。它记录了该次任务执行的详细信息，如开始时间、结束时间、状态（成功、失败、运行中）、日志、输入输出参数等。
  • 工作流实例（Workflow Instance） ：每次工作流被触发运行时生成的一个实例，包含了本次运行的所有任务实例及其全局上下文。
  • 触发器（Trigger） ：定义工作流何时被触发执行。支持 Cron 表达式定时触发、手动触发、API 调用触发、事件触发等。

4. 完整实战：Spring Boot 集成 Deer-Flow

接下来，我们通过一个模拟的“订单日报生成”流程，来演示如何集成和使用 Deer-Flow。该流程包含：数据准备 -> 数据校验 -> 报告生成 -> 通知发送 四个步骤。

4.1 项目初始化与依赖引入

首先，使用 Spring Initializr 创建一个新的 Spring Boot 项目，选择 Web 和 Lombok 依赖。

然后，在 pom.xml 中添加 Deer-Flow 的依赖。 请注意，你需要根据官方仓库的指引找到正确的依赖坐标 。这里以假设的 deer-flow-spring-boot-starter 为例。

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.7.14</version> <!-- 请使用与Deer-Flow兼容的Spring Boot版本 -->
        <relativePath/>
    </parent>
    <groupId>com.example</groupId>
    <artifactId>deer-flow-demo</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>deer-flow-demo</name>
    <description>Demo project for Deer-Flow</description>

    <properties>
        <java.version>11</java.version>
        <!-- 假设的Deer-Flow版本，请替换为实际版本 -->
        <deer-flow.version>1.0.0</deer-flow.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <!-- Deer-Flow Executor Starter (嵌入业务应用) -->
        <dependency>
            <groupId>com.bytedance.deerflow</groupId>
            <artifactId>deer-flow-spring-boot-starter</artifactId>
            <version>${deer-flow.version}</version>
        </dependency>
        <!-- 数据库驱动 (Executor可能需要连接Deer-Flow Server的DB来汇报状态) -->
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <scope>runtime</scope>
        </dependency>
    </dependencies>
</project>

4.2 配置 Deer-Flow Executor

在 application.yml 或 application.properties 中配置执行器。关键配置包括执行器名称、Deer-Flow Server 的地址、以及执行器自身的网络信息。

# application.yml
spring:
  application:
    name: order-report-service

deer-flow:
  executor:
    # 执行器名称，在Server控制台显示，需唯一
    app-name: ${spring.application.name}
    # Deer-Flow Server 的地址
    server-addr: http://localhost:8080
    # 执行器IP，自动检测，也可手动指定
    ip: 
    # 执行器端口，用于Server回调或健康检查
    port: 9999
    # 日志路径
    log-path: ./logs/deer-flow/
    # 与Server通信的访问令牌（如果Server端启用了鉴权）
    access-token: your-token-here

# 数据库配置（如果执行器需要直连Server的元数据库，否则通常通过HTTP上报）
#  datasource:
#    url: jdbc:mysql://localhost:3306/deer_flow?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
#    username: root
#    password: 123456

4.3 编写业务任务（Task）代码

在 Deer-Flow 中，一个任务对应一个 Java 方法。我们需要创建这些方法，并使用 Deer-Flow 的注解或接口将其暴露为可执行任务。

首先，定义一个任务处理器类：

package com.example.deerflowdemo.task;

import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Component;

/**
 * 订单日报生成流程的任务处理器
 */
@Component
@Slf4j
public class OrderReportTasks {

    /**
     * 任务1: 准备订单数据
     * @param workflowContext 工作流上下文，可以传递参数
     * @return 任务执行结果，通常包含成功标志和输出数据
     */
    public Object prepareData(Object workflowContext) {
        log.info("[Task-PrepareData] 开始准备昨日订单数据...");
        // 模拟业务逻辑：查询数据库、调用服务等
        try {
            Thread.sleep(1000); // 模拟耗时操作
            // 假设准备了一些数据
            String preparedData = "order_data_20231027";
            log.info("[Task-PrepareData] 数据准备完成: {}", preparedData);
            // 将结果放入上下文，供下游任务使用
            // 实际使用中，workflowContext 可能是 Map 或特定对象
            return TaskResult.success(preparedData);
        } catch (InterruptedException e) {
            log.error("[Task-PrepareData] 任务执行失败", e);
            return TaskResult.failure(e.getMessage());
        }
    }

    /**
     * 任务2: 校验数据质量
     */
    public Object validateData(Object workflowContext) {
        log.info("[Task-ValidateData] 开始校验订单数据...");
        // 模拟从上游任务获取数据
        // 实际场景中，workflowContext 会包含 prepareData 任务的输出
        try {
            Thread.sleep(500);
            // 模拟校验逻辑
            boolean isValid = Math.random() > 0.2; // 80%成功率
            if (isValid) {
                log.info("[Task-ValidateData] 数据校验通过");
                return TaskResult.success("VALID");
            } else {
                log.warn("[Task-ValidateData] 数据校验失败，发现异常订单");
                return TaskResult.failure("Data validation failed");
            }
        } catch (InterruptedException e) {
            return TaskResult.failure(e.getMessage());
        }
    }

    /**
     * 任务3: 生成PDF报告 (依赖任务1的成功)
     */
    public Object generateReport(Object workflowContext) {
        log.info("[Task-GenerateReport] 开始生成PDF日报...");
        try {
            Thread.sleep(2000); // 模拟报告生成耗时
            String reportPath = "/tmp/reports/order_report_20231027.pdf";
            log.info("[Task-GenerateReport] 报告生成成功: {}", reportPath);
            return TaskResult.success(reportPath);
        } catch (Exception e) {
            log.error("[Task-GenerateReport] 报告生成失败", e);
            return TaskResult.failure(e.getMessage());
        }
    }

    /**
     * 任务4: 发送邮件通知 (依赖任务3的成功)
     */
    public Object sendNotification(Object workflowContext) {
        log.info("[Task-SendNotification] 开始发送邮件通知...");
        try {
            Thread.sleep(300);
            log.info("[Task-SendNotification] 邮件已发送至相关责任人邮箱");
            return TaskResult.success("EMAIL_SENT");
        } catch (Exception e) {
            log.error("[Task-SendNotification] 邮件发送失败", e);
            return TaskResult.failure(e.getMessage());
        }
    }

    // 一个简单的任务结果包装类（实际框架会提供）
    @Data
    @AllArgsConstructor
    public static class TaskResult {
        private boolean success;
        private String message;
        private Object data;

        public static TaskResult success(Object data) {
            return new TaskResult(true, "SUCCESS", data);
        }
        public static TaskResult failure(String message) {
            return new TaskResult(false, message, null);
        }
    }
}

关键点 ：

  1. 任务方法必须是 public 的。
  2. 方法参数通常包含工作流上下文对象，用于获取上游任务的输出或全局参数。
  3. 返回值需要符合框架要求，通常是一个包含执行状态和结果的对象。这里用自定义的 TaskResult 模拟。
  4. 实际集成时，你需要使用 Deer-Flow 提供的特定注解（如 @DeerFlowTask ）来标记这些方法，以便框架能自动发现和注册它们。具体注解请查阅官方文档。

4.4 在 Deer-Flow Server 控制台定义工作流

这是核心步骤。我们需要登录 Deer-Flow Server 提供的 Web 管理界面（假设部署在 http://localhost:8080 ）来可视化地定义工作流。

  1. 登录控制台 ：使用管理员账号登录。
  2. 创建项目/应用 ：通常先创建一个与你的业务服务对应的项目或应用空间。
  3. 定义任务 ：在“任务管理”中，为你刚才编写的四个 Java 方法创建对应的“任务定义”。需要指定：
    • 任务名称 ：如 prepare_order_data 。
    • 任务类型 ：选择 Java 或 Bean （表示执行一个 Spring Bean 的方法）。
    • 执行器 ：选择你配置的 order-report-service 。
    • 任务参数 ：填写完整的类名和方法名，例如 com.example.deerflowdemo.task.OrderReportTasks.prepareData 。
    • 其他参数 ：如超时时间、重试次数等。
  4. 绘制 DAG 工作流 ：进入“工作流定义”页面，创建一个新的工作流，例如命名为 Daily_Order_Report_Generation 。
    • 将上面定义的四个任务节点拖拽到画布上。
    • 建立依赖关系： validateData 依赖 prepareData ； generateReport 依赖 prepareData （且需要 validateData 成功）； sendNotification 依赖 generateReport 。
    • 最终形成的 DAG 应该是： prepareData -> validateData -> generateReport -> sendNotification ，并且 generateReport 也直接依赖 prepareData 。
    • 配置工作流级参数，如全局变量、失败策略（整体失败、继续执行后续等）、报警设置。
  5. 设置触发器 ：为该工作流配置一个触发器。例如，设置一个 Cron 表达式 0 0 2 * * ? ，表示每天凌晨2点自动执行。
  6. 上线工作流 ：保存并发布（上线）该工作流定义，使其处于可调度状态。

4.5 运行与验证

  1. 启动你的 Spring Boot 应用 ：确保执行器成功启动，并注册到 Deer-Flow Server。查看应用日志，确认类似 DeerFlow Executor started successfully 的消息。
  2. 在 Server 控制台手动触发 ：在“工作流实例”页面，找到你上线的工作流，点击“执行一次”进行手动触发，用于测试。
  3. 观察执行过程 ：
    • 在“工作流实例”列表，可以看到新生成的实例及其状态（运行中、成功、失败）。
    • 点击该实例，进入详情页，可以清晰地看到 DAG 图，每个任务节点的状态会实时更新（绿色成功、红色失败、黄色运行中）。
    • 点击某个任务节点，可以查看该任务实例的详细日志，这正是你写在 OrderReportTasks 类中的 log.info 输出的内容。
  4. 查看业务应用日志 ：同时，在你的 order-report-service 应用控制台，也会看到对应的任务方法被调用和执行的日志输出。
  5. 测试失败场景 ：你可以修改 validateData 方法，让其模拟失败（例如总是返回 TaskResult.failure ）。重新触发工作流后，观察 DAG 图中失败节点的状态，以及工作流是否按照你配置的失败策略（如暂停后续任务）执行。

5. 常见问题与排查思路

在实际集成和使用过程中，你可能会遇到以下典型问题。

问题现象 可能原因 排查思路与解决方案
执行器无法注册到 Server 1. 网络不通或 server-addr 配置错误。
2. Server 未启动或端口被占用。
3. 执行器 app-name 冲突或配置错误。
4. 访问令牌 ( access-token ) 不正确。		 1. 使用 curl 或浏览器访问 http://server-addr/health 检查 Server 状态。
2. 检查执行器日志，查看注册请求的报错信息。
3. 确认 Server 和 Executor 的 app-name 配置一致且唯一。
4. 核对 Server 端配置的令牌。
任务一直处于“待执行”或“派发中”状态 1. 没有可用的执行器（未注册或离线）。
2. 任务定义中的“执行器”选择错误。
3. 任务队列阻塞。		 1. 在 Server 控制台“执行器管理”页面，确认目标执行器在线且健康。
2. 编辑任务定义，确保其绑定的执行器与应用名称匹配。
3. 检查 Server 日志，查看任务派发逻辑是否有异常。
任务执行失败，日志显示“找不到方法”或“类不存在” 1. 任务参数中的类名或方法名拼写错误。
2. 业务应用（执行器）中对应的类未被 Spring 管理（缺少 @Component 等注解）。
3. 执行器端的类与方法签名（参数、返回值）与框架要求不匹配。		 1. 仔细核对任务定义中的“任务参数”（全限定类名.方法名）。
2. 确保任务处理类在 Spring 的扫描路径下，并且已被成功加载为 Bean。
3. 查阅官方文档，确认任务方法的正确签名格式。
工作流中某个任务失败，但整个流程未按预期停止或回滚 工作流的“失败策略”配置问题。 在工作流定义中，检查并配置“失败策略”。通常有“继续执行后续”、“暂停后续”、“失败重试”等选项。根据业务需求选择。对于需要事务性的场景，需要在业务任务代码中自行实现补偿机制。
任务执行超时 1. 任务本身执行时间过长。
2. 网络延迟或资源不足。
3. 任务定义的超时时间设置过短。		 1. 优化任务逻辑，减少耗时。
2. 检查执行器所在服务器的 CPU、内存、网络状况。
3. 在任务定义中适当调大“超时时间”配置。
Server 控制台访问缓慢或无法打开 1. Server 所在机器资源不足。
2. 数据库连接池或查询性能瓶颈。
3. 前端资源加载问题。		 1. 监控 Server 的 JVM 和系统资源使用情况。
2. 检查数据库性能，对 deer_flow 数据库的相关表（如任务实例表）建立合适索引。
3. 查看浏览器控制台网络请求是否有错误。

6. 最佳实践与工程建议

将 Deer-Flow 引入生产环境，需要遵循一些最佳实践以确保其稳定、高效和安全。

  1. 环境隔离 ：

    • 开发、测试、生产环境 的 Deer-Flow Server 和数据库必须严格隔离。避免测试环境的任务调度影响到生产数据。
    • 可以通过不同的 app-name 前缀或分组来区分不同环境的执行器。

  2. 高可用部署 ：

    • Deer-Flow Server ：部署至少两个实例，前面通过 Nginx 等负载均衡器做代理。多个 Server 实例共享同一个元数据库，通过数据库锁或选举机制来保证同一时间只有一个 Master Server 在调度，实现高可用。
    • 数据库 ：使用主从复制或高可用架构的 MySQL/PostgreSQL。
    • 执行器 ：业务应用本身通常就是多实例部署的，这天然实现了执行器的高可用。Server 会从健康的执行器实例中选择一个来执行任务。

  3. 任务设计原则 ：

    • 幂等性 ：任务逻辑必须设计成幂等的，即多次执行产生的结果与一次执行相同。因为网络超时等原因，Server 可能会重复派发任务。可以通过业务唯一键、状态机或分布式锁来保证。
    • 职责单一 ：一个任务只做一件事，保持简洁。复杂的业务逻辑可以拆分成多个任务，通过工作流编排。
    • 超时与重试 ：为每个任务设置合理的超时时间和重试次数。对于非幂等或对实时性要求高的任务，慎用重试。
    • 资源限制 ：对 CPU/内存密集型或 IO 密集型任务，要在执行器端做好线程池隔离和资源控制，避免一个任务拖垮整个执行器。

  4. 配置与版本管理 ：

    • 工作流定义和任务定义也属于“配置”。建议建立配置变更流程，重要的修改需经过评审。
    • 对于核心工作流，可以考虑使用代码化的方式定义（如果框架支持），并将其纳入 Git 版本控制，实现 Infrastructure as Code。

  5. 监控与报警 ：

    • 关键指标监控 ：监控 Server 和 Executor 的 JVM 状态（GC、内存）、线程池活跃度、数据库连接池。
    • 业务监控 ：重点关注工作流实例的成功率、任务平均耗时、失败任务排行。Deer-Flow Server 的控制台通常提供这些数据。
    • 报警 ：对工作流失败、任务连续失败、调度延迟等异常情况配置报警，及时通知负责人（如通过钉钉、企业微信、邮件）。

  6. 安全与权限 ：

    • 访问控制 ：一定要为 Deer-Flow Server 的控制台和 API 配置强密码，并启用访问令牌 ( access-token ) 机制。
    • 权限细分 ：如果团队规模大，应利用 Deer-Flow 的项目/租户功能和权限系统，为不同团队或开发者分配不同的查看和操作权限。
    • 网络隔离 ：将 Deer-Flow Server 部署在内网，禁止公网直接访问。执行器与 Server 之间的通信也应走内网。

  7. 日志与排查 ：

    • 确保执行器任务的日志被正确收集到统一的日志平台（如 ELK）。
    • 在工作流和任务定义时，就规划好清晰的日志格式，包含 workflowInstanceId , taskInstanceId 等关键信息，便于链路追踪。

通过本文的详细介绍和实战演练，你应该对 Deer-Flow 的核心价值、架构原理和集成方法有了全面的认识。从环境搭建、任务编写、工作流编排到上线调试，我们走完了一个完整的闭环。在实际项目中，建议先从非核心的、相对独立的定时任务开始试点，逐步积累经验，再将其应用到更复杂的业务流程编排中。记住，任何调度框架都是工具，清晰的任务边界设计、幂等性保证和完备的监控报警，才是系统稳定运行的基石。

Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

一个 API 入口调用多个大模型：AiiOnly客户端 + CC Switch 打通 Codex AI编程流程

avatar AI编程社区
cover

VSCode Claude Code + MiMo 中转免登录完整配置教程（解决原生登录弹窗 + 模型报错）

avatar AI编程社区
cover

从零开始做一个属于自己的 Skill（保姆级教程）

avatar AI编程社区