1. 项目概述：一个本地API的“集线器”

最近在折腾一些自动化脚本和本地应用集成时，我遇到了一个挺普遍的问题：手头攒了一堆好用的本地工具和服务，比如本地的OCR识别引擎、AI模型推理接口、文件处理服务等等。它们各自都提供了API，但调用方式五花八门——有的用HTTP，有的用WebSocket，有的端口号不固定，有的认证方式麻烦。每次写脚本调用，都得重新查文档、配参数，效率低下不说，还容易出错。

这时候，我就想，能不能有一个统一的“集线器”来管理这些本地API？让它来负责协议转换、路由分发、认证鉴权、日志监控这些脏活累活，而我只需要面向这个“集线器”提供的一套标准、简单的接口来编程。于是，我动手搭建了 outhsics/localapi-hub 这个项目。简单来说，它就是一个运行在你本机或内网服务器上的轻量级API网关，专门用于聚合、管理和编排你本地的各种服务接口。

它的核心价值在于“统一”和“简化”。对于开发者或技术爱好者而言，无论你是想构建一个复杂的本地工作流（比如自动截图->OCR识别->翻译->保存笔记），还是想为你的智能家居中枢提供一个稳定的本地服务调用层， localapi-hub 都能作为一个可靠的中介层，让你的代码逻辑更清晰，维护成本更低。它不依赖任何云服务，所有数据都在本地流转，在注重隐私和延迟的场景下尤其有用。

2. 核心架构与设计思路拆解

2.1 为什么选择“中心化网关”模式？

在分布式或微服务架构里，API网关是一个成熟的概念，用于处理横切关注点。把这个思想“降维”应用到本地环境，同样有效。我放弃让每个客户端直接对接N个异构服务，转而让所有客户端只对接 localapi-hub 这一个入口。这样做有几个明显的好处：

第一，客户端复杂度大幅降低。 客户端无需关心后端服务有几个、在哪里、怎么调用。它只需要知道网关的地址和一套固定的API规范。比如，原来调用OCR服务需要知道它的IP和端口，构造特定的表单数据。现在，只需要向网关的 /api/ocr 发送一个标准JSON请求即可。

第二，后端服务的灵活性与可维护性提升。 我可以随时替换、升级或增减后端的本地服务，只要在网关里更新一下路由配置，客户端代码完全不用动。今天用A方案的OCR，明天换B方案的，对上游调用方透明。

第三，集中实现通用功能。 认证、限流、请求日志、错误处理、数据格式转换（如XML转JSON）这些功能，如果在每个服务里各自实现，是重复劳动且难以统一。在网关层统一实现，事半功倍。例如，我可以为所有经过网关的请求添加一个统一的请求ID，方便全链路追踪。

第四，便于监控和调试。 所有流量都经过网关，这就成了一个天然的观测点。我可以在这里集中记录所有请求和响应的日志，分析接口调用频率和性能，快速定位是哪个后端服务出了问题。

2.2 技术栈选型与权衡

localapi-hub 的目标是轻量、易部署、高性能。我主要考虑了以下几个技术选项：

1. 开发语言与框架：

  • Node.js + Express/Koa/Fastify: 这是最初想到的方案，JavaScript生态丰富，开发速度快。但对于一个需要长期运行、可能承载一定并发量的网关服务，我对Node.js在CPU密集型操作（如大量请求的协议转换）和内存管理上的表现有些顾虑。此外，部署需要Node环境。
  • Python + FastAPI/Flask: Python写起来更简单，生态同样强大。但性能通常弱于编译型语言，且作为常驻服务，在资源利用上不如Go或Rust高效。
  • Go + Gin/Echo: Go语言以高性能、高并发、低内存占用和简单的部署（单一二进制文件）著称。这对于一个网关类应用是绝佳选择。Gin框架轻量且性能出色，社区活跃。最终我选择了 Go + Gin 作为核心。编译后一个可执行文件，扔到任何机器上都能跑，依赖为零，非常适合作为基础工具分发。
  • Rust + Actix/Axum: 性能和安全性的终极选择，但开发成本和学习曲线较高。考虑到 localapi-hub 的核心逻辑是路由和转发，并非计算密集型，用Rust有点“杀鸡用牛刀”，会拖慢开发迭代速度。

2. 配置管理：

  • 配置文件 vs. 数据库 vs. 控制台API。 为了极致简单，我选择了 YAML配置文件 。所有后端服务（我称之为 Upstream ）的定义、路由规则、插件配置都写在一个 config.yaml 文件里。服务启动时加载，支持热重载（发送信号或调用管理API重新加载配置）。这样不需要引入额外的数据库组件，部署和备份都极其简单。

3. 服务发现与健康检查：

  • 在本地或小型内网场景，服务变动不频繁，因此没有引入复杂的服务发现机制（如Consul, Etcd）。而是采用 静态配置 + 主动健康检查 的方式。在配置文件中定义每个上游服务的健康检查端点（如 /health ）和检查间隔。网关会定期探测，自动将不健康的服务实例从负载均衡池中剔除，并在其恢复后重新加入。

4. 插件化架构：

  • 为了保持核心的简洁和可扩展性，我设计了一个简单的插件接口。像“请求头转换”、“简单的JWT验证”、“请求日志输出到文件”这类功能，都以插件形式实现。插件在配置文件中声明和启用，核心路由引擎会在请求处理链的适当位置调用它们。这样，用户可以根据需要“装配”自己的网关，而不是面对一个功能臃肿的巨无霸。

3. 核心功能模块深度解析

3.1 路由引擎：请求如何找到正确的后端？

路由是网关最核心的功能。 localapi-hub 的路由规则设计追求灵活和直观。

路由匹配规则： 我支持多种匹配方式，优先级从高到低：

  1. 精确路径匹配： path: /api/v1/ocr 。请求路径必须完全一致。
  2. 路径前缀匹配： path_prefix: /api/user/ 。所有以 /api/user/ 开头的请求都会匹配到此规则。这是最常用的方式，可以将一个服务的所有接口统一管理。
  3. 域名匹配： host: local.service.com 。如果你在本地配置了Hosts或使用内网DNS，可以让不同域名指向同一个网关，然后网关根据域名将请求转发到不同的后端服务。这在模拟多租户或项目隔离时很有用。
  4. 方法匹配： methods: [“POST”, “PUT”] 。可以结合路径规则，限制只有特定HTTP方法的请求才能通过。

一个路由规则绑定一个“上游服务”。一个上游服务可以包含多个实例（比如同一个服务开了两个端口做负载均衡）。

配置示例： 

routes:
  - id: “ocr-service-route”
    match:
      path_prefix: “/api/ocr”
    upstream_id: “ocr-upstream”
    plugins:
      - name: “request-id”
      - name: “log-to-file”
        config:
          file_path: “./logs/ocr_requests.log”

upstreams:
  - id: “ocr-upstream”
    instances:
      - url: “http://localhost:8001”
        weight: 5
      - url: “http://localhost:8002”
        weight: 5
    health_check:
      path: “/health”
      interval: “30s”
      timeout: “5s”

这段配置意味着：所有以 /api/ocr 开头的请求，都会被转发到 ocr-upstream 。这个上游有两个实例，权重各为5，网关会以加权轮询的方式分发请求。同时，网关会每30秒检查一次每个实例的 /health 端点，超时5秒，失败则暂时禁用该实例。在转发前后，会执行 request-id 和 log-to-file 插件。

3.2 负载均衡与熔断降级

负载均衡策略： 除了上面提到的加权轮询，我还实现了：

  • 最小连接数： 将新请求发给当前活跃连接数最少的后端实例。这对于处理时间长短不一的服务更公平。
  • IP哈希： 根据客户端IP计算哈希值，固定分配到某个后端实例。这可以保证来自同一客户端的请求总是落到同一台后端，对于需要会话粘滞的场景有用。

选择策略在 upstream 配置中指定。对于本地服务，加权轮询通常就够了。

熔断与降级机制： 这是保障系统韧性的关键。想象一下，如果后端的OCR服务崩溃了，网关还不停地往那里转发请求，会导致大量请求快速失败。

  • 熔断器： 我为每个上游实例维护了一个熔断器状态。当在时间窗口内，该实例的失败率（如5xx错误或连接超时）超过阈值（如50%），熔断器会“跳闸”，进入 Open 状态。在此状态下，所有指向该实例的请求会立即失败（快速失败），而不会真正发出网络请求。经过一个设定的休眠期后，熔断器进入 Half-Open 状态，允许少量试探请求通过。如果试探成功，则关闭熔断器，恢复流量；如果失败，则再次进入 Open 状态。
  • 降级： 在路由配置中，可以指定一个“降级响应”。当某个路由的所有后端实例都不可用（或熔断）时，网关不再返回 502 Bad Gateway ，而是返回一个预设的友好响应。例如，对于查询天气的接口，降级响应可以返回 {“city”: “北京”, “weather”: “数据暂不可用”, “is_fallback”: true} 。这样前端应用可以展示一个友好的提示，而不是一个错误页面。

3.3 插件系统：如何按需扩展功能？

插件系统采用“中间件”模式。每个插件本质上是一个实现了特定接口的Go结构体。网关在启动时，根据配置加载并初始化这些插件。

插件执行阶段： 一个请求的生命周期被划分为多个阶段，插件可以挂载到不同阶段执行：

  1. BeforeRouting : 在路由匹配之前执行。适合做全局认证、限流。
  2. BeforeForwarding : 在路由匹配之后，转发请求到后端之前执行。适合修改请求头、请求体、做协议转换。
  3. AfterForwarding : 在收到后端响应之后，返回给客户端之前执行。适合修改响应头、响应体、记录日志。
  4. OnError : 在任何阶段发生错误时执行。适合统一的错误格式处理。

开发一个自定义插件： 假设我想开发一个插件，给所有请求添加一个 X-Request-Source: localapi-hub 的头。

  1. 定义一个结构体，实现 Plugin 接口的 Name() 和 Execute() 方法。
  2. 在 Execute() 方法中，判断阶段，如果是 BeforeForwarding ，就在请求头中添加字段。
  3. 将插件编译进网关，或者在支持动态加载的情况下，将插件代码放在指定目录。
  4. 在路由的 plugins 配置项中启用它。

这种设计使得核心代码非常稳定，而功能可以通过插件无限扩展。社区可以贡献各种插件，比如集成Prometheus指标导出、将日志发送到Elasticsearch、对请求体进行加密解密等。

4. 从零开始部署与配置实战

4.1 环境准备与快速启动

假设你有一台运行Linux/macOS的机器，部署 localapi-hub 简单到令人发指。

第一步：获取可执行文件。 你可以从项目的GitHub Release页面下载对应平台编译好的二进制文件。比如对于Linux x86_64： 

wget https://github.com/outhsics/localapi-hub/releases/download/v0.1.0/localapi-hub-linux-amd64
chmod +x localapi-hub-linux-amd64
sudo mv localapi-hub-linux-amd64 /usr/local/bin/localapi-hub

或者，如果你有Go环境（1.18+），可以直接从源码编译，能获得最新特性： 

git clone https://github.com/outhsics/localapi-hub.git
cd localapi-hub
go build -o localapi-hub cmd/main.go

第二步：编写配置文件。 创建一个 config.yaml 文件。我们从最简单的例子开始，假设你本地有一个在 http://127.0.0.1:5000 运行的Web服务，它提供了 /hello 接口。我们想通过网关的 /myapp/hello 来访问它。 

# config.yaml
server:
  port: 8080 # 网关监听的端口

routes:
  - id: “my-first-route”
    match:
      path_prefix: “/myapp”
    upstream_id: “my-local-app”
    # 可以在这里添加插件，比如添加一个请求ID
    plugins:
      - name: “request-id”

upstreams:
  - id: “my-local-app”
    # 这里配置你的后端服务地址
    instances:
      - url: “http://127.0.0.1:5000”
    # 简单的健康检查，确保服务是活的
    health_check:
      path: “/health” # 你的后端服务需要提供这个端点
      interval: “30s”

注意： 这里的 path_prefix: “/myapp” 是关键。当请求 http://localhost:8080/myapp/hello 时，网关会将其转发到 http://127.0.0.1:5000/hello 。网关默认会 剥离 匹配到的前缀（ /myapp ）。如果你希望保留前缀，需要在路由配置中设置 strip_path: false 。

第三步：启动网关。 

localapi-hub -c ./config.yaml

如果看到类似 [GIN] Listening on :8080 的日志，说明网关启动成功。

第四步：测试。 打开另一个终端，使用curl测试： 

curl http://localhost:8080/myapp/hello

你应该能收到来自 127.0.0.1:5000 服务的响应。至此，一个最基本的本地API网关就运行起来了。

4.2 配置详解：串联多个本地服务

现在我们来构建一个更真实的场景：你本地有三个服务。

  1. OCR服务： http://localhost:8001 ，提供 /ocr 接口 (POST)。
  2. 翻译服务： http://localhost:8002 ，提供 /translate 接口 (POST)。
  3. 数据库查询服务： http://localhost:8003 ，提供 /query 接口 (GET)。

你想通过统一的网关 localhost:8080 来访问它们，并且为OCR和翻译接口添加一个简单的API Key认证。

配置文件进阶版： 

server:
  port: 8080
  # 可以启用管理API，用于动态查看状态、重载配置
  admin_port: 8081

# 定义全局插件，对所有路由生效
global_plugins:
  - name: “cors” # 处理跨域请求，方便前端调试
    config:
      allow_origins: [“*”]
      allow_methods: [“GET”, “POST”, “PUT”, “DELETE”]

routes:
  - id: “ocr-route”
    match:
      path_prefix: “/api/ocr”
      methods: [“POST”] # 只允许POST方法
    upstream_id: “ocr-upstream”
    plugins:
      - name: “auth-apikey” # 使用API Key认证插件
        config:
          header_name: “X-API-Key”
          valid_keys: [“my-secret-ocr-key-123”]
      - name: “logger”
        config:
          level: “info”

  - id: “translate-route”
    match:
      path_prefix: “/api/translate”
      methods: [“POST”]
    upstream_id: “translate-upstream”
    plugins:
      - name: “auth-apikey”
        config:
          header_name: “X-API-Key”
          valid_keys: [“my-secret-translate-key-456”]
      # 这个插件会在转发前，将请求体从JSON转换成后端服务需要的格式
      - name: “request-transformer”
        config:
          body_template: ‘{“text”: “{{.input}}”, “target_lang”: “{{.lang}}”}’

  - id: “query-route”
    match:
      path_prefix: “/api/db”
    upstream_id: “db-upstream”
    # 这个路由不需要认证，但需要限流，防止被刷
    plugins:
      - name: “rate-limiter”
        config:
          requests_per_minute: 60
          burst: 10

upstreams:
  - id: “ocr-upstream”
    load_balancer: “round_robin”
    instances:
      - url: “http://localhost:8001”
    health_check:
      path: “/health”
      interval: “30s”

  - id: “translate-upstream”
    instances:
      - url: “http://localhost:8002”
    health_check:
      path: “/ping”
      interval: “20s” # 翻译服务检查可以更频繁一些

  - id: “db-upstream”
    instances:
      - url: “http://localhost:8003”
    # 这个服务没有健康检查端点，所以不配置health_check

配置解读与实操要点：

  1. 路由优先级： 网关会按顺序匹配路由。通常把最具体的路径（如 /api/ocr ）放在前面，通用路径（如 /api/ ）放在后面，避免被错误匹配。
  2. 插件链： 一个路由上的插件按配置顺序执行。例如对于OCR请求，先执行 auth-apikey 认证，认证通过后再执行 logger 记录日志。
  3. 健康检查： 强烈建议为所有重要的上游服务配置健康检查。 path 需要是后端服务上一个能快速返回成功状态码（如200）的端点。 interval 不宜太短，避免给后端造成压力；也不宜太长，否则故障发现慢。
  4. 管理接口： 开启了 admin_port: 8081 后，你可以通过 curl http://localhost:8081/status 查看网关状态、上游健康情况，或者发送 POST 请求到 /reload 来热重载配置文件，无需重启服务。

4.3 高级场景：请求/响应转换与编排

有时后端服务需要的请求格式和客户端发送的不一致，或者你需要对响应进行加工。 request-transformer 和 response-transformer 插件就派上用场了。

场景： 客户端发送 {“image_url”: “...”} 到网关的 /api/ocr ，但后端OCR服务需要 {“image_base64”: “...”} 。我们需要在网关层完成这个转换。

配置示例： 

routes:
  - id: “ocr-with-transform”
    match:
      path_prefix: “/api/v2/ocr”
    upstream_id: “ocr-upstream”
    plugins:
      - name: “request-transformer”
        config:
          # 假设我们有一个插件能根据URL下载图片并转base64
          # 这里只是一个逻辑示例，实际插件需要自己实现或寻找
          body_template: |
            {
              “image_base64”: “{{ downloadAndEncode .request.body.image_url }}”,
              “language”: “chi_sim”
            }
          headers:
            add:
              Content-Type: “application/json”

更复杂的场景是 API编排 ：网关接收一个请求，然后并行或串行调用多个后端服务，将结果组合后返回。这超出了简单反向代理的范畴。在 localapi-hub 中，可以通过编写一个专用的“编排插件”来实现。例如，一个“智能处理”接口，内部依次调用OCR->翻译->情感分析服务，最后返回一个整合的结果。这种插件逻辑复杂，但能极大简化客户端的调用逻辑。

5. 性能调优、监控与故障排查

5.1 性能关键点与调优建议

网关作为所有流量的出入口，其性能至关重要。以下是一些实战中的调优经验：

1. 连接池管理： 网关对每个上游服务实例都应维护一个HTTP连接池。Go的 http.Client 默认就有连接复用机制。关键参数是 Transport 中的 MaxIdleConnsPerHost 。设置过小，会导致频繁建立TCP连接；设置过大，会浪费内存。根据你的后端服务数量和并发量调整。对于本地服务，通常几十到几百就足够了。 

# 可以在全局配置或上游配置中指定
upstreams:
  - id: “my-service”
    client_config:
      max_idle_conns_per_host: 100
      idle_conn_timeout: “90s” # 空闲连接超时时间

2. 超时控制： 这是防止雪崩的关键。必须为每个路由或上游设置合理的超时。

  • 拨号超时： 建立TCP连接的最长时间。
  • 请求超时： 从发送请求到读完响应体的总时间。
  • 响应头超时： 从发送请求到收到响应头的最长时间。 如果后端服务响应慢，超时设置太短会导致大量请求失败；设置太长，会拖慢网关的整体响应速度并占用连接资源。建议根据后端服务的P99响应时间来设置，并留有一定余量。 
routes:
  - id: “slow-api”
    timeout: “10s” # 整个路由级别的超时
upstreams:
  - id: “slow-upstream”
    client_config:
      dial_timeout: “2s”
      request_timeout: “8s”

3. 缓冲区大小： 网关需要读取完整的客户端请求体才能转发，也需要读取完整的后端响应体才能返回。对于可能传输大文件（如图片、视频）的路由，需要适当增加读写缓冲区的大小，避免内存暴涨或IO效率低下。可以在相关路由的插件配置或上游配置中调整。

4. 启用压缩： 如果客户端和网关、网关和后端之间传输的数据主要是文本（如JSON），启用GZIP压缩可以显著减少网络传输量。Go的Gin框架默认支持，确保你的配置中启用了压缩中间件（如果作为全局插件）。

5.2 监控与可观测性建设

“没有监控的系统就是在裸奔。” 对于网关，我们需要监控以下几点：

1. 基础资源监控： 使用 top , htop , vmstat 等工具，或通过集成 pprof ，监控网关进程的CPU、内存占用。网关本身应该很轻量，如果内存持续增长，可能有内存泄漏。

2. 业务指标监控： 这是最重要的。我通过插件实现了Prometheus指标导出。网关会暴露 /metrics 端点，包含：

  • http_requests_total ：请求总数，按路由、方法、状态码分类。
  • http_request_duration_seconds ：请求耗时分布直方图。
  • upstream_health_status ：上游服务健康状态（1健康，0不健康）。
  • circuit_breaker_state ：熔断器状态。 将这些指标接入Prometheus + Grafana，可以绘制出漂亮的仪表盘，实时查看各接口的QPS、延迟、错误率。

3. 日志聚合： 网关的访问日志和错误日志是排查问题的第一手资料。我建议：

  • 结构化日志： 使用JSON格式输出日志，方便后续用ELK（Elasticsearch, Logstash, Kibana）或Loki进行收集和检索。每条日志应包含请求ID、路径、客户端IP、响应时间、状态码等关键字段。
  • 日志分级： 区分 info , warn , error 等级别。生产环境可以只记录 warn 和 error ，避免日志量过大。
  • 敏感信息过滤： 在日志插件中，务必过滤掉请求头或请求体中的密码、Token等敏感信息。

5.3 常见问题与排查实录

在开发和运维 localapi-hub 的过程中，我踩过不少坑，这里总结几个典型问题：

问题一：网关返回 502 Bad Gateway 或 504 Gateway Timeout 。 这是最常见的问题。

  • 排查步骤：
    1. 检查后端服务： 首先确认后端服务本身是否正常运行。直接curl它的地址和端口。
    2. 检查网关日志： 查看网关的错误日志，通常会记录连接被拒绝、连接超时或读超时的具体错误。
    3. 检查健康检查： 如果配置了健康检查，去管理界面 ( /status ) 查看该上游实例的健康状态。可能是健康检查失败导致实例被标记为下线。
    4. 检查网络和防火墙： 确认网关所在的机器能否访问后端服务的IP和端口。特别是如果后端服务运行在Docker容器内，需要注意网络模式。
    5. 检查超时设置： 504 通常是网关等待后端响应超时。适当增加 request_timeout 配置。
  • 我的教训： 有一次，一个后端服务在压力下响应变慢，但健康检查端点 /health 依然很快返回200，导致网关认为它健康，继续将流量打过去，最终大量请求超时。后来我将健康检查的端点改成了一个能反映核心业务状态（如连接数据库）的接口，更真实。

问题二：请求头丢失或修改未生效。

  • 原因： HTTP代理默认会过滤掉一些敏感头（如 Authorization ）或标准化一些头（如 Host ）。在转发时，需要显式配置哪些头需要传递。
  • 解决： 在路由或上游配置中，设置 preserve_host: true 可以保持原 Host 头。对于其他自定义头，确保没有在插件中被意外删除。使用 request-transformer 插件可以精确地添加、修改或删除请求头。

问题三：内存使用量缓慢增长。

  • 可能原因：
    1. 连接泄漏： 没有正确关闭响应体。在Go中，必须读取并关闭 response.Body ，否则连接不会放回连接池。
    2. 插件内存泄漏： 自定义插件中，可能存在全局变量不断增长，或goroutine未正确退出的情况。
    3. 大请求体未限制： 客户端上传超大文件，网关试图将整个文件读入内存。
  • 排查： 使用 pprof 工具分析内存占用和goroutine数量。在代码中，对所有 io.ReadAll 操作保持警惕，对于可能的大请求，使用流式处理或设置 MaxBytesReader 限制大小。

问题四：跨域（CORS）问题。

  • 现象： 浏览器前端应用调用网关接口时，控制台报CORS错误。
  • 解决： 启用全局的 cors 插件，并正确配置 allow_origins , allow_methods , allow_headers 。注意，在预检请求（OPTIONS）时，网关应直接返回200，而不转发到后端。 cors 插件通常会处理好这一点。

问题五：配置文件热重载失败。

  • 现象： 向 /reload 端点发送POST请求后，新配置未生效，或者网关报错。
  • 排查：
    1. 检查新配置文件的YAML语法是否正确。
    2. 检查网关进程是否有权限读取该配置文件。
    3. 查看网关日志，热重载过程会有详细日志输出，会指出哪一行配置有问题。
    4. 确保在重载期间，没有正在处理的请求使用即将被删除的上游或路由，否则可能导致请求失败。好的实现应该在重载时平滑切换。

最后，一个重要的心得是： 日志和指标是你的眼睛。 在关键路径上打上足够的日志（但不要滥用），并建立完善的监控仪表盘，能在问题出现的第一时间发出警报，并为你提供清晰的排查线索。 localapi-hub 的设计始终围绕着“简单可用”和“易于观测”这两个原则，让它不仅能解决问题，而且在出问题时能快速定位和恢复。

Logo
乐奇 Rokid 开放社区

更多推荐

cover

AI眼镜的赢家不在硅谷，在一个县城

avatar 乐奇 Rokid 开放社区
cover

极刻觅镜 | AI眼镜日报｜乐奇二代光学升级、Rokid Prism打通桌面智能体

avatar 乐奇 Rokid 开放社区

用 Rokid AIUI 做一个「专注时刻助手」：把一段专注时间挂在眼前

我用“开始专注 25 分钟背单词”和“专注 10 分钟”等输入方式，检查应用是否被正确调起、页面是否收到参数，以及倒计时和任务名是否正确显示。一次典型操作是：先说“开始专注 25 分钟背单词”，确认眼前卡片显示了正确的任务和时间，再选择“开始”。用户可以通过类似“开始专注 25 分钟背单词”的表达唤起智能体，页面接收任务名称和时长，显示待机倒计时。超过单次时长范围时，需要给出清楚的反馈。它没有任务

avatar 乐奇 Rokid 开放社区