双因素认证2FA（Two-Factor Authentication）：登录 / 操作账号时，必须同时提供两种不同类型的身份凭证，才能完成身份校验，是多因素认证（MFA）最常用的子集。传统登录仅单因素：账号 + 密码（单一知识凭证），一旦密码泄露，账号直接被盗；2FA 在密码之外增加第二道独立校验屏障，黑客只拿到密码也无法登录。

核心逻辑：三大身份凭证分类（行业标准）​

所有验证方式只会归为以下三类，2FA 要求必须选自两类不同组别，不能同组叠加：

1. 你知道的东西（知识类）密码、密保问题、PIN 码、生日等。风险：容易泄露、被钓鱼、暴力破解。
2. 你拥有的东西（持有类）手机、硬件密钥、验证码 App、U 盾、短信、邮箱、专用令牌。GitHub TOTP 验证码、手机短信、YubiKey 都属于这一类。
3. 你本身的特征（生物类）指纹、人脸、虹膜、声纹。

举个例子：

• 密码（知道）+ 手机验证码（持有）= 标准 2FA
• 密码（知道）+ 指纹（本身）= 标准 2FA
• 密码 + 密保问题（同属「知道」）≠ 2FA，只是双重密码，无安全提升

二、2FA 主流实现方式（GitHub 全部支持）​

1. TOTP 基于时间的一次性密码（你当前使用的方式，GitHub 推荐首选）​

标准协议：RFC6238，也就是你之前研究的 6 位 30 秒刷新验证码。

• 原理：服务器与你的设备共享一串 Base32 密钥，依靠统一时间戳，每 30 秒同步生成一组 6 位数字。
• 载体：Microsoft Authenticator、Google Authenticator、Authy、密码管理器，甚至你自己写的 Python 程序。
• 优势：离线可用，不需要手机信号 / 网络；无运营商短信拦截、盗号风险；无额外成本。
• GitHub 场景：截图里扫码绑定二维码、setup key 手动配置，全部是 TOTP。

2. SMS 短信验证码（备用，不推荐主力）​

登录时向绑定手机号发送带 6 位数字的国际短信。

• 缺点：SIM 卡劫持、运营商短信拦截、境外短信收不到、短信明文传输易被窃取。
• GitHub 仅作为辅助备份，不建议单独依赖。

3. 邮箱验证码​

向绑定邮箱发送一次性登录码，安全性很低，邮箱一旦被盗，2FA 直接失效。

4. 推送 App 验证（GitHub Mobile）​

手机安装 GitHub 官方 App，登录时手机弹出确认弹窗，一键批准登录，无需手动输入数字，底层依然是 TOTP。

5. FIDO 硬件密钥（最高安全等级，企业用户）​

YubiKey、苹果通行密钥 Passkey，物理硬件设备，通过 USB/NFC/ 蓝牙校验，无法远程劫持，防钓鱼攻击。GitHub 支持绑定硬件密钥作为第二验证因素。

6. 一次性恢复码（应急兜底）​

开启 2FA 时生成 10 组固定一次性代码，仅在手机丢失、无法获取验证码时登录，每组只能使用一次，不属于常规 2FA 方式。

三、2FA 的安全价值（为什么 GitHub 强制要求贡献者开启）​

1. 抵御密码泄露网站数据库泄露、钓鱼网站窃取密码、弱密码暴力破解场景下，攻击者仅有密码，缺少第二凭证无法登录。
2. 防御中间人劫持短信容易被劫持，但 TOTP 硬件密钥无传输过程，黑客无法拦截验证码。
3. 防钓鱼攻击FIDO/Passkey 可识别真实域名，仿冒 GitHub 钓鱼页面无法完成验证；TOTP 也大幅提高钓鱼门槛。
4. 平台风控强制规则GitHub 政策：只要账号存在代码提交、仓库创建、开源贡献行为，强制开启 2FA，不开启会限制 Git 推送、仓库管理、账号设置等核心功能，对应你之前反复弹出的强制校验弹窗。

四、2FA 与 MFA（多因素认证）的区别​

• 2FA：严格2 种不同类型凭证（双因素）
• MFA：≥2 种，可 3 种及以上（密码 + 验证码 + 指纹，三因素）日常语境中大家常混用，但 2FA 特指双因素场景。

五、2FA生成规则​

GitHub 验证器 App 使用TOTP（基于时间的一次性密码）国际标准 RFC6238，固定参数如下表格

生成流程​

1. 获取当前 Unix 时间戳（秒），除以 30 向下取整，得到计数器 T
2. 将 T 转为8 字节大端序二进制数据
3. 把 GitHub 给你的 Base32 密钥解码为原始二进制密钥
4. 执行 HMAC-SHA1(密钥, 8字节计数器)，得到 20 字节哈希结果
5. 取哈希最后 1 字节的低 4 位作为偏移量 offset
6. 从哈希的 offset 位置截取 4 字节，清除最高符号位
7. 对 10^6 取模，不足 6 位前面补 0，得到最终 6 位验证码

生成脚本​

生在验证码之前，需要拿到 GitHub 绑定 2FA 时的Base32 密钥，任意编程语言（Python/JS/Go/Java）都能实现生成器。通过扫描你github中的Authenticator app二维码，可以得到一个字符串，otpauth://totp/GitHub:用户名?secret=xxx，secret= 后面就是 Base32 密钥

def generate_totp_code(base32_secret: str, period: int = 30, digits: int = 6) -> str:
    """根据 Base32 密钥生成 TOTP 验证码（RFC 6238）"""
    # 1. 当前时间戳除以周期，向下取整得到计数器 T
    t = int(time.time()) 
    # 2. T 转为 8 字节大端序二进制
    counter_bytes = struct.pack(">Q", t)
    # 3. Base32 密钥解码为原始二进制密钥（大写并补齐 padding）
    upper = base32_secret.upper()
    padded = upper + "=" * ((8 - len(upper) % 8) % 8)
    key = base64.b32decode(padded)
    # 4. HMAC-SHA1(密钥, 计数器)，得到 20 字节哈希
    h = hmac.new(key, counter_bytes, hashlib.sha1).digest()
    # 5. 取最后一字节低 4 位作为偏移量 offset
    offset = h[-1] & 0x0F
    # 6. 从 offset 截取 4 字节，清除最高符号位
    code_int = struct.unpack(">I", h[offset:offset + 4])[0] & 0x7FFFFFFF
    # 7. 对 10^digits 取模，前补零
    return str(code_int % (10 ** digits)).zfill(digits)

六、工作完整流程（以 GitHub TOTP 举例）​

1. 预绑定阶段（你截图的页面）GitHub 服务器生成唯一 Base32 密钥，同时下发给你（二维码 /setup key），服务器永久保存该密钥。
2. 登录流程① 用户输入用户名 + 密码（第一因素）；② 服务器校验密码正确后，触发第二道 2FA 校验；③ 用户打开验证器 App，基于共享密钥 + 当前时间生成 6 位 TOTP 验证码；④ 提交验证码，服务器用同一密钥、同一时间窗口计算验证码比对；⑤ 校验一致，允许登录；不一致则拒绝访问。
3. 容错机制：服务器会校验「上一个 30 秒 / 当前 / 下一个 30 秒」三组验证码，解决手机和电脑微小时间差。

七、常见误区澄清​

1. 误区：输两次密码就是 2FA错误，两者都属于「你知道的信息」，只是双重密码，没有安全提升。
2. 误区：短信是最安全的 2FA错误，短信是风险最高的方案，优先 TOTP 验证器 App。
3. 误区：2FA 开启后绝对不会被盗号2FA 大幅提升门槛，但如果泄露 Base32 密钥、丢失硬件密钥、泄露恢复码，账号依然有风险，密钥需要妥善保管。
4. 误区：可以绕过 2FA 校验弹窗GitHub 强制校验是后台风控策略，无法跳过，必须完成一次有效 TOTP 验证才能永久消除弹窗。

八、优缺点总结​

优点​

1. 极大降低账号被盗概率；
2. TOTP 离线可用，不依赖网络 / 运营商；
3. 免费、易部署，个人 / 企业均可使用；
4. 主流平台（GitHub、云服务器、支付、后台管理）全部标配。

缺点​

1. 增加登录操作步骤，降低使用便捷度；
2. 若丢失验证设备且未保存恢复码，有账号锁死风险；
3. TOTP 对设备系统时间同步有要求，时间偏差会导致验证码失效。

Apache SkyWalking 是一款专为微服务、云原生及容器化架构设计的开源可观测性平台，提供分布式追踪、服务网格遥测分析、度量聚合与可视化的一体化解决方案。在传统单体应用向分布式架构演进的过程中，系统复杂度呈指数级增长，传统的日志监控与指标监控已无法满足故障定位与性能诊断的需求。SkyWalking 的核心价值在于填补了这一技术空白，通过全链路追踪能力，将原本黑盒化的跨服务调用过程转化为可视化的调用链，使开发运维人员能够快速定位性能瓶颈与故障根因。

与传统APM工具相比，SkyWalking 具备三大差异化优势：第一，无侵入式探针设计，通过字节码增强技术实现监控数据采集，无需修改业务代码；第二，高性能通信架构，采用gRPC协议进行数据传输，大幅降低监控开销；第三，跨语言生态支持，覆盖Java、.NET Core、PHP、Node.js、Go、Python等主流编程语言，完美适配异构技术栈的微服务体系。

主要功能特性​

SkyWalking 的功能矩阵围绕可观测性的三大支柱（指标、日志、追踪）构建：

1. 分布式追踪：自动采集服务间调用链路，生成端到端的Trace记录，支持跨进程、跨语言的调用关系还原。每个Trace包含完整的Span层级结构，可精确到方法级别的耗时分析。
2. 服务拓扑发现：基于调用关系数据自动绘制服务依赖图谱，直观展示微服务间的调用流向与依赖强度，识别关键路径与单点故障风险。
3. 应用性能指标监控：采集JVM内存、CPU使用率、GC频率、线程状态等运行时指标，提供多维度的性能基线分析与异常检测。
4. 告警与通知：支持基于阈值、同比环比、异常检测等多种规则的告警配置，可通过Webhook、邮件、钉钉、企业微信等渠道实时通知。
5. 日志关联分析：将业务日志与Trace ID自动关联，实现日志上下文与调用链路的双向跳转，加速故障排查过程。
6. 服务网格集成：原生支持Envoy + Istio构建的Service Mesh架构，可监控服务网格内的流量路由、负载均衡与安全策略执行情况。

适用场景​

SkyWalking 的适用场景覆盖从开发测试到生产运维的全生命周期：

• 微服务性能诊断：当接口响应时间异常时，通过调用链分析快速定位慢查询服务、数据库瓶颈或第三方API延迟。
• 容量规划与优化：基于历史性能数据识别服务资源瓶颈，为弹性伸缩与资源分配提供数据支撑。
• 故障根因定位：结合链路、指标与日志三要素，在服务异常时迅速缩小排查范围，确定故障发生的具体服务与方法。
• 架构演进验证：在服务拆分、技术栈迁移等架构变更后，验证新架构的性能表现与稳定性。
• SLA合规监控：监控关键业务接口的可用性与响应时间，确保服务等级协议（SLA）的持续达标。

二、SkyWalking架构详解

四大核心组件​

SkyWalking 采用四层架构设计：探针（Agent） 部署于应用实例，负责无侵入采集追踪数据；后端服务（OAP Server） 接收、聚合、分析数据；存储（Storage） 持久化处理结果至Elasticsearch、MySQL等数据库；UI界面 提供可视化展示与查询功能。

数据流转机制​

探针通过HTTP/gRPC将Trace Segment协议数据发送至OAP Server，OAP进行流式分析后写入存储层，UI从存储读取数据生成拓扑图与性能仪表盘。跨语言调用通过标准化Sw8 Header传递上下文，确保异构服务链路完整拼接。

三、本地部署方法详解

环境准备与依赖检查​

在开始部署 SkyWalking 之前，请确保您的系统满足以下最低要求：

操作系统：Linux（CentOS 7+/Ubuntu 18.04+）、macOS 10.14+、Windows 10（WSL2推荐）

内存：至少 4GB RAM（生产环境建议 8GB+）

磁盘空间：至少 10GB 可用空间

核心依赖版本：

• Java 8 或更高版本（推荐 OpenJDK 11）
• MySQL 5.7+ 或 Elasticsearch 7.x（用于数据存储）
• 网络端口：11800（gRPC）、12800（HTTP）、8080（UI，可自定义）

可在此处配一张终端检查Java版本的截图，显示 java -version 命令输出

快速验证命令：

# 检查Java版本
java -version

# 检查MySQL状态（如使用MySQL存储）
systemctl status mysql

# 检查端口占用情况
netstat -tlnp | grep -E '11800|12800|8080'

手动部署步骤​

1. 下载与解压​

从 Apache SkyWalking 官网下载最新版本（当前稳定版为 9.7.0）：

# 下载压缩包
wget https://dlcdn.apache.org/skywalking/9.7.0/apache-skywalking-apm-9.7.0.tar.gz

# 解压到指定目录
tar -zxvf apache-skywalking-apm-9.7.0.tar.gz -C /opt/
cd /opt/apache-skywalking-apm-9.7.0

解压后的目录结构：

• bin/：启动脚本（oapService.sh、webappService.sh）
• config/：配置文件目录
• agent/：Java Agent 探针
• webapp/：UI 前端资源

2. MySQL存储配置详解​

SkyWalking 默认使用 H2 内存数据库，适合测试环境。生产环境推荐使用 MySQL 或 Elasticsearch。以下以 MySQL 为例：

步骤一：创建数据库与用户

-- 登录MySQL
mysql -u root -p

-- 创建数据库（字符集必须为utf8）
CREATE DATABASE IF NOT EXISTS `skywalking` 
DEFAULT CHARACTER SET utf8 
DEFAULT COLLATE utf8_general_ci;

-- 创建专用用户
CREATE USER 'skywalking'@'%' IDENTIFIED BY 'YourPassword123!';
GRANT ALL PRIVILEGES ON skywalking.* TO 'skywalking'@'%';
FLUSH PRIVILEGES;

步骤二：修改 OAP 配置文件编辑 config/application.yml，找到 storage 配置段：

storage:
  selector: ${SW_STORAGE:mysql}  # 指定使用MySQL
  
  mysql:
    properties:
      jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://localhost:3306/skywalking?rewriteBatchedStatements=true"}
      dataSource.user: ${SW_DATA_SOURCE_USER:skywalking}
      dataSource.password: ${SW_DATA_SOURCE_PASSWORD:YourPassword123!}
      dataSource.cachePrepStmts: ${SW_DATA_SOURCE_CACHE_PREP_STMTS:true}
      dataSource.prepStmtCacheSize: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SIZE:250}
      dataSource.prepStmtCacheSqlLimit: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_LIMIT:2048}

关键配置说明：

• rewriteBatchedStatements=true：启用批量写入优化，提升数据入库性能
• cachePrepStmts 系列参数：预编译语句缓存，减少数据库连接开销
• 生产环境建议将密码通过环境变量传入，避免硬编码

步骤三：初始化数据库表结构SkyWalking 会自动创建所需表，首次启动时会执行初始化脚本。无需手动建表。

步骤四：启动 OAP 服务

# 启动后端服务（默认端口11800/12800）
./bin/oapService.sh start

# 查看启动日志
tail -f logs/skywalking-oap-server.log

步骤五：配置并启动 Web UI修改 webapp/webapp.yml：

server:
  port: 8080  # UI访问端口
  
oap:
  host: ${SW_OAP_HOST:localhost}
  port: ${SW_OAP_PORT:12800}

启动UI服务：

./bin/webappService.sh start

访问 http://localhost:8080 即可进入监控控制台。

Docker快速部署方案​

对于追求部署效率的场景，Docker 是最佳选择。SkyWalking 提供官方镜像，支持一键部署完整监控栈。

单机部署（开发测试）​

1. 使用 Docker Compose创建 docker-compose.yml：

version: '3.8'
services:
  oap:
    image: apache/skywalking-oap-server:9.7.0
    container_name: skywalking-oap
    restart: always
    ports:
      - "11800:11800"   # gRPC端口
      - "12800:12800"   # HTTP端口
    environment:
      SW_STORAGE: elasticsearch
      SW_ES_USER: elastic
      SW_ES_PASSWORD: your_password
      SW_ES_URL: http://elasticsearch:9200
    depends_on:
      - elasticsearch
  
  ui:
    image: apache/skywalking-ui:9.7.0
    container_name: skywalking-ui
    restart: always
    ports:
      - "8080:8080"
    environment:
      SW_OAP_ADDRESS: http://oap:12800
    depends_on:
      - oap
  
  elasticsearch:
    image: elasticsearch:7.17.0
    container_name: elasticsearch
    restart: always
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ports:
      - "9200:9200"
    volumes:
      - es_data:/usr/share/elasticsearch/data

volumes:
  es_data:

2. 启动服务

docker-compose up -d

3. 验证部署

# 检查容器状态
docker-compose ps

# 查看OAP日志
docker logs -f skywalking-oap

# 访问UI
curl http://localhost:8080

生产环境优化配置​

生产环境需考虑高可用与性能优化：

1. 集群模式部署修改 OAP 环境变量：

environment:
  SW_CLUSTER: kubernetes  # 或zookeeper、nacos
  SW_CLUSTER_K8S_NAMESPACE: skywalking
  SW_CLUSTER_K8S_LABEL: app=skywalking
  SW_CLUSTER_K8S_SERVICE_NAME: skywalking-oap

2. 资源限制

deploy:
  resources:
    limits:
      memory: 2G
      cpus: '2'
    reservations:
      memory: 1G
      cpus: '1'

3. 数据持久化

volumes:
  - ./data/oap:/skywalking/logs
  - ./data/config:/skywalking/config

与现有监控体系集成​

SkyWalking Docker 部署可轻松对接现有基础设施：

1. 对接外部 Elasticsearch

environment:
  SW_STORAGE: elasticsearch
  SW_ES_URL: http://your-es-cluster:9200
  SW_ES_USER: ${ES_USER}
  SW_ES_PASSWORD: ${ES_PASSWORD}

2. 配置反向代理（Nginx）

location /skywalking/ {
    proxy_pass http://skywalking-ui:8080/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

3. 监控数据导出通过 OAP 的 Prometheus 插件，将指标数据导出至现有监控系统：

environment:
  SW_TELEMETRY_PROMETHEUS_HOST: 0.0.0.0
  SW_TELEMETRY_PROMETHEUS_PORT: 1234

部署验证清单​

部署完成后，执行以下验证步骤：

<图片>

可在此处配一张SkyWalking UI首页截图，展示服务拓扑图

1. 服务连通性测试

# 测试OAP gRPC端口
grpcurl -plaintext localhost:11800 list

# 测试OAP HTTP端口
curl http://localhost:12800

# 测试UI访问
curl -I http://localhost:8080

1. 数据上报验证启动一个测试应用并配置 SkyWalking Agent，观察数据是否正常上报至UI界面。
2. 性能基准测试使用压测工具模拟业务流量，验证 SkyWalking 在高负载下的稳定性与资源消耗。

部署选择建议：

• 开发/测试环境：推荐 Docker Compose 单机部署，5分钟完成环境搭建
• 预发布环境：使用 Docker 集群模式，模拟生产架构
• 生产环境：结合 Kubernetes 部署，配置资源限制与高可用策略

无论选择哪种部署方式，SkyWalking 都提供了灵活的配置选项，可根据实际需求调整存储后端、集群模式与资源分配。关键是要在部署初期明确监控数据的保留周期、存储容量规划以及告警策略，避免后期因数据膨胀或配置不当导致的运维负担。

四、Java语言对接使用方法

依赖配置与代理部署​

1. 探针获取与部署方式​

SkyWalking Java Agent 提供两种集成方式：独立探针部署与Maven依赖集成。对于生产环境，推荐使用独立探针方案，避免依赖冲突与版本管理问题。

独立探针部署步骤：

1. 下载探针包从 SkyWalking 官网下载对应版本的发布包，解压后获取 agent/ 目录：

wget https://dlcdn.apache.org/skywalking/9.7.0/apache-skywalking-apm-9.7.0.tar.gz
tar -zxvf apache-skywalking-apm-9.7.0.tar.gz
# 探针位于解压目录的 agent/ 子目录

2. 探针目录结构解析

skywalking-agent/
├── config/                    # 探针配置文件
│   └── agent.config          # 核心配置文件
├── plugins/                   # 插件目录（支持框架扩展）
│   ├── apm-spring-cloud-gateway-2.1.x-plugin.jar
│   ├── apm-dubbo-2.7.x-plugin.jar
│   └── ...
├── optional-plugins/          # 可选插件
├── bootstrap-plugins/         # 启动类插件
└── skywalking-agent.jar       # 核心Agent JAR

3. 基础配置参数编辑 config/agent.config 或通过JVM参数动态配置：

# 服务名称（在UI中显示）
agent.service_name=${SW_AGENT_NAME:Your-Service-Name}

# OAP服务器地址（gRPC协议）
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800}

# 采样率（0.0-1.0，生产环境建议0.1-0.3）
agent.sample_n_per_3_secs=${SW_AGENT_SAMPLE:-1}

# 日志级别
logging.level=${SW_LOGGING_LEVEL:INFO}

2. 启动参数配置​

传统JAR包启动方式：

java -javaagent:/path/to/skywalking-agent/skywalking-agent.jar \
     -Dskywalking.agent.service_name=order-service \
     -Dskywalking.collector.backend_service=192.168.1.100:11800 \
     -Dskywalking.agent.sample_n_per_3_secs=100 \
     -jar your-application.jar

Spring Boot应用启动脚本示例（start.sh）：

#!/bin/bash
AGENT_PATH="/opt/skywalking/agent/skywalking-agent.jar"
SERVICE_NAME="order-service"
OAP_SERVER="skywalking-oap:11800"

JVM_OPTS="-javaagent:${AGENT_PATH} \
          -Dskywalking.agent.service_name=${SERVICE_NAME} \
          -Dskywalking.collector.backend_service=${OAP_SERVER} \
          -Dskywalking.logging.level=INFO \
          -Dskywalking.agent.sample_n_per_3_secs=100 \
          -Dskywalking.plugin.jdbc.trace_sql_parameters=true \
          -Xms512m -Xmx512m"

java ${JVM_OPTS} -jar target/order-service-1.0.0.jar

关键参数说明：

• -javaagent：必须放在所有JVM参数之前
• service_name：同一服务的多个实例应使用相同名称
• backend_service：支持多个OAP地址，用逗号分隔实现负载均衡
• sample_n_per_3_secs：每3秒采样数，-1表示全量采集（仅限测试环境）

3. Maven/Gradle依赖集成（可选）​

对于需要手动埋点或日志关联的场景，可添加Toolkit依赖：

Maven配置（pom.xml）：

<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-trace</artifactId>
    <version>9.7.0</version>
</dependency>
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-logback-1.x</artifactId>
    <version>9.7.0</version>
</dependency>
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-opentracing</artifactId>
    <version>9.7.0</version>
    <scope>provided</scope>
</dependency>

Gradle配置（build.gradle）：

dependencies {
    implementation 'org.apache.skywalking:apm-toolkit-trace:9.7.0'
    implementation 'org.apache.skywalking:apm-toolkit-logback-1.x:9.7.0'
    compileOnly 'org.apache.skywalking:apm-toolkit-opentracing:9.7.0'
}

<图片>

可在此处配一张IDEA中Maven依赖配置截图，展示SkyWalking依赖添加位置

代码示例与最佳实践​

1. 自动埋点与框架支持​

SkyWalking Java Agent 通过字节码增强技术自动支持主流框架：

Spring Boot 自动集成：Agent 自动识别并监控以下组件：

• @RestController / @Controller 注解的HTTP端点
• @Service / @Component 业务服务层
• @Repository 数据访问层
• Spring MVC 请求映射与参数解析
• Spring Data JPA / MyBatis 数据库操作

支持框架列表：

• Web框架：Spring MVC 3.x/4.x/5.x, Spring Boot 1.x/2.x
• RPC框架：Dubbo 2.5.x-2.7.x, gRPC 1.x
• 消息队列：Kafka, RocketMQ 4.x
• 数据库：MySQL, PostgreSQL, Oracle, MongoDB
• 缓存：Redis (Jedis/Lettuce)

2. 手动埋点示例​

对于自定义业务逻辑或第三方组件，可使用手动埋点：

Trace注解方式：

import org.apache.skywalking.apm.toolkit.trace.Trace;
import org.apache.skywalking.apm.toolkit.trace.TraceContext;

@Service
public class OrderService {
    
    @Trace(operationName = "createOrder")
    public OrderDTO createOrder(OrderRequest request) {
        // 获取当前Trace ID（用于日志关联）
        String traceId = TraceContext.traceId();
        log.info("TraceID: {}, 开始创建订单", traceId);
        
        // 业务逻辑
        validateRequest(request);
        Order order = buildOrder(request);
        saveOrder(order);
        
        return convertToDTO(order);
    }
    
    @Trace
    private void validateRequest(OrderRequest request) {
        // 参数校验逻辑
    }
}

ActiveSpan API（更细粒度控制）：

import org.apache.skywalking.apm.toolkit.trace.ActiveSpan;

public class PaymentService {
    public PaymentResult processPayment(PaymentRequest request) {
        // 创建自定义Span
        ActiveSpan.tag("payment_method", request.getMethod());
        ActiveSpan.tag("amount", String.valueOf(request.getAmount()));
        
        try {
            ActiveSpan.debug("开始支付处理");
            // 支付逻辑
            return executePayment(request);
        } catch (Exception e) {
            // 标记错误
            ActiveSpan.error(e);
            ActiveSpan.tag("error_code", "PAYMENT_FAILED");
            throw e;
        }
    }
}

3. 日志关联配置​

将业务日志与Trace ID自动关联：

Logback配置（logback-spring.xml）：

<configuration>
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
                <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%tid] [%thread] %-5level %logger{36} - %msg%n</pattern>
            </layout>
        </encoder>
    </appender>
    
    <root level="INFO">
        <appender-ref ref="CONSOLE" />
    </root>
</configuration>

Log4j2配置：

<Configuration>
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%X{tid}] [%t] %-5p %c{1.} - %m%n"/>
        </Console>
    </Appenders>
    <Loggers>
        <Root level="info">
            <AppenderRef ref="Console"/>
        </Root>
    </Loggers>
</Configuration>

日志输出示例：

2024-03-15 14:30:25.123 [TID:3.48.16893234250000001] [http-nio-8080-exec-1] INFO  c.e.o.OrderService - 订单创建成功，订单号: ORD20240315001

4. 跨线程追踪​

对于异步任务或线程池场景，需要手动传递Trace上下文：

Runnable/Callable包装：

import org.apache.skywalking.apm.toolkit.trace.RunnableWrapper;
import org.apache.skywalking.apm.toolkit.trace.CallableWrapper;

// 线程池提交任务
executorService.submit(RunnableWrapper.of(() -> {
    // 异步任务逻辑，Trace上下文自动传递
    processAsyncTask();
}));

// 带返回值的任务
Future<String> future = executorService.submit(
    CallableWrapper.of(() -> {
        return asyncCompute();
    })
);

CompletableFuture支持：

import org.apache.skywalking.apm.toolkit.trace.TraceCrossThread;

@TraceCrossThread
public class TraceableCompletableFuture<T> extends CompletableFuture<T> {
    // 自动继承Trace上下文
}

// 使用示例
TraceableCompletableFuture<String> future = new TraceableCompletableFuture<>();
executorService.submit(() -> {
    String result = doAsyncWork();
    future.complete(result);
});

5. 最佳实践总结​

1. 采样率配置：生产环境设置 agent.sample_n_per_3_secs=100（约3%采样），平衡监控开销与数据完整性。
2. 插件管理：plugins/ 目录只保留需要的插件，减少类加载开销。定期检查插件版本兼容性。
3. 标签使用规范：
   • 业务标签：customer_id, order_type, payment_status
   • 技术标签：db_instance, cache_hit, external_api
   • 避免标签值过大（超过512字节）
4. 异常处理：关键业务方法使用 ActiveSpan.error(e) 记录异常，结合 @Trace 注解的 ignoreExceptions 参数过滤已知异常。
5. 性能监控：关注Agent的CPU和内存使用，单实例建议不超过应用资源的5%。

生产环境部署方案​

1. 容器化部署策略​

Docker镜像构建：

FROM openjdk:11-jre-slim
COPY skywalking-agent /usr/local/skywalking-agent
COPY target/app.jar /app/app.jar
ENTRYPOINT ["java", "-javaagent:/usr/local/skywalking-agent/skywalking-agent.jar", \
           "-Dskywalking.agent.service_name=${SERVICE_NAME}", \
           "-Dskywalking.collector.backend_service=${OAP_SERVER}", \
           "-jar", "/app/app.jar"]

Kubernetes配置要点：

• 使用ConfigMap管理agent.config
• 通过环境变量注入服务名与OAP地址
• 设置资源限制：CPU 100m-500m，内存200M-1G
• 就绪探针检查Agent状态

2. 高可用架构​

多OAP负载均衡：

agent.config: collector.backend_service=oap1:11800,oap2:11800,oap3:11800

服务发现集成：

• Kubernetes：通过Service名称自动发现
• Nacos/Zookeeper：动态获取OAP实例列表
• 客户端侧负载均衡与故障转移

3. 安全配置​

认证与加密：

• gRPC TLS加密传输
• OAP访问令牌认证
• 网络策略限制访问范围

数据脱敏：

• SQL参数脱敏插件
• HTTP头信息过滤
• 自定义脱敏规则

4. 性能优化​

采样策略：

• 关键路径全采样，非关键路径降采样
• 自适应采样：根据QPS动态调整
• 错误请求全采样

资源控制：

• 缓冲区大小优化
• 批量上报配置
• 离线模式支持（网络异常时）

5. 监控与运维​

Agent自监控：

• 通过JMX暴露内部指标
• 健康检查端点
• 日志轮转与归档

升级与回滚：

• 蓝绿部署策略
• 版本兼容性矩阵
• 配置热更新支持

6. 故障排查清单​

1. 数据不上报：检查网络连通性、OAP状态、采样配置
2. 高内存占用：调整缓冲区、减少插件、检查内存泄漏
3. 性能影响：优化采样率、关闭非必要插件、升级版本
4. Trace不完整：验证跨线程上下文传递、检查框架兼容性

部署验证：通过测试流量验证端到端监控链路，确保业务指标、Trace数据、日志关联三要素完整可用。

五、Python语言对接使用方法

SDK安装与环境配置​

1. 安装方式与版本选择​

SkyWalking Python探针通过apache-skywalking包提供，支持Python 3.6及以上版本。推荐使用虚拟环境隔离依赖：

# 创建虚拟环境（可选）
python -m venv venv
source venv/bin/activate  # Linux/macOS
# venv\Scripts\activate  # Windows

# 安装SkyWalking Python SDK
pip install apache-skywalking

# 验证安装
python -c "import skywalking; print(skywalking.__version__)"

版本兼容性矩阵：

• SkyWalking Python SDK 1.x：支持SkyWalking OAP 8.x-9.x
• 建议使用最新稳定版（当前为1.0.0）
• 与后端OAP版本差异不超过2个大版本

2. 基础配置参数​

Python SDK支持多种配置方式，优先级从高到低：环境变量 > 代码配置 > 配置文件。

核心配置项：

from skywalking import config

# 基础配置（必须）
config.init(
    agent_collector_backend_services='127.0.0.1:11800',  # OAP gRPC地址
    agent_name='your-python-service',                    # 服务名称
    agent_instance_name='instance-01',                   # 实例标识
    agent_protocol='grpc',                               # 通信协议
    agent_authentication='your-token',                   # 认证令牌（可选）
)

# 性能调优参数
config.agent_buffer_size = 1000          # 缓冲区大小
config.agent_queue_size = 5000           # 队列容量
config.agent_meter_reporter_period = 20  # 指标上报间隔（秒）

环境变量配置示例：

export SW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800
export SW_AGENT_NAME=payment-service
export SW_AGENT_INSTANCE_NAME=payment-01
export SW_AGENT_PROTOCOL=grpc
export SW_AGENT_AUTHENTICATION=your-secret-token

Flask/Django框架集成示例​

1. Flask应用集成​

Flask集成通过中间件自动拦截HTTP请求，无需手动埋点：

from flask import Flask, jsonify
from skywalking import agent, config

# 初始化配置（必须在应用启动前调用）
config.init(
    agent_collector_backend_services='127.0.0.1:11800',
    agent_name='flask-demo',
    agent_instance_name='flask-instance-01'
)

# 启动Agent
agent.start()

app = Flask(__name__)

# 自动追踪所有路由
@app.route('/api/orders/<int:order_id>', methods=['GET'])
def get_order(order_id):
    """获取订单详情 - 自动生成Span"""
    # 业务逻辑
    order_data = fetch_order_from_db(order_id)
    return jsonify(order_data)

@app.route('/api/orders', methods=['POST'])
def create_order():
    """创建订单"""
    from skywalking.trace.context import get_context
    from skywalking.trace.tags import Tag
    
    # 手动添加业务标签
    context = get_context()
    if context.active_span():
        context.active_span().tag(Tag('order_type', 'standard'))
        context.active_span().tag(Tag('customer_id', request.json.get('customer_id')))
    
    # 业务处理
    order_id = process_order_creation(request.json)
    return jsonify({'order_id': order_id}), 201

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000, debug=False)

Flask特定配置：

# 启用HTTP参数收集（生产环境谨慎开启）
config.flask_collect_http_params = True

# 排除特定路由（如健康检查）
config.flask_ignore_path = ['/health', '/metrics']

# 请求体大小限制（避免内存溢出）
config.flask_collect_http_body_length_limit = 1024  # 字节

2. Django应用集成​

Django通过中间件实现自动追踪：

settings.py配置：

INSTALLED_APPS = [
    # ... 其他应用
    'skywalking',
]

MIDDLEWARE = [
    'skywalking.contrib.django.middleware.TracingMiddleware',  # 必须放在最前
    # ... 其他中间件
]

# SkyWalking配置
SKYWALKING_CONFIG = {
    'agent_collector_backend_services': '127.0.0.1:11800',
    'agent_name': 'django-ecommerce',
    'agent_instance_name': 'django-instance-01',
    'agent_protocol': 'grpc',
    'django_collect_http_params': False,  # 生产环境建议关闭
    'django_ignore_path': ['/admin/', '/static/', '/media/'],
}

视图函数示例：

from django.http import JsonResponse
from skywalking.trace.context import get_context
from skywalking.trace.tags import Tag

def product_detail(request, product_id):
    """商品详情页 - 自动追踪"""
    context = get_context()
    
    # 手动添加业务维度
    if context.active_span():
        span = context.active_span()
        span.tag(Tag('product_id', product_id))
        span.tag(Tag('user_agent', request.META.get('HTTP_USER_AGENT', '')))
    
    # 业务逻辑
    product = Product.objects.get(id=product_id)
    return JsonResponse({
        'id': product.id,
        'name': product.name,
        'price': product.price
    })

# 异步视图支持（Django 3.1+）
async def async_product_list(request):
    """异步商品列表"""
    from skywalking.contrib.async_trace import async_trace
    
    @async_trace(operation_name='async_product_query')
    async def fetch_products():
        return await Product.objects.all().alist()
    
    products = await fetch_products()
    return JsonResponse({'products': products})

配置项详解​

1. 探针核心配置​

网络与连接配置：

config.init(
    # 连接设置
    agent_collector_backend_services='127.0.0.1:11800,192.168.1.100:11800',  # 多OAP负载均衡
    agent_protocol='grpc',  # grpc或http
    agent_grpc_tls_enable=False,  # TLS加密
    agent_grpc_tls_cert_path='/path/to/cert.pem',
    
    # 超时与重试
    agent_collector_grpc_upstream_timeout=30,  # 秒
    agent_collector_grpc_max_retry=3,
    agent_collector_grpc_retry_interval=1,  # 秒
)

采样与性能配置：

# 采样策略
config.agent_sample_rate = 0.1  # 10%采样率（0.0-1.0）
config.agent_force_sample_error = True  # 错误请求强制采样

# 缓冲区管理
config.agent_buffer_size = 1000  # 单次批量上报最大Span数
config.agent_queue_size = 5000   # 内存队列容量
config.agent_meter_reporter_period = 20  # 指标上报周期（秒）

# 资源限制
config.agent_max_buffer_size = 10000  # 最大缓冲区
config.agent_disable_oom_protection = False  # OOM保护

2. 框架特定配置​

HTTP框架通用配置：

# 请求/响应追踪
config.collect_http_params = False  # 是否收集HTTP参数
config.http_params_length_threshold = 1024  # 参数长度限制
config.trace_ignore_path = ['/health', '/metrics', '/docs']  # 忽略路径

# 数据库操作追踪
config.sql_parameters_max_length = 512  # SQL参数截断长度
config.trace_sql_parameters = False  # 是否记录SQL参数（安全考虑）

# 外部调用追踪
config.redis_parameters_max_length = 256  # Redis参数限制
config.mq_parameters_max_length = 512    # 消息队列参数限制

插件管理配置：

# 启用/禁用特定插件
config.plugin_enable = {
    'flask': True,
    'django': True,
    'requests': True,      # HTTP客户端追踪
    'urllib3': True,       # 低级HTTP库追踪
    'mysql': True,         # MySQL数据库
    'redis': True,         # Redis缓存
    'pymongo': True,       # MongoDB
    'kafka': True,         # Kafka消息
    'grpc': True,          # gRPC调用
}

# 自定义插件路径
config.plugin_mount_dir = '/path/to/custom/plugins'

3. 日志与诊断配置​

日志集成：

# 自动注入Trace ID到日志
config.log_reporter_active = True
config.log_reporter_level = 'WARNING'  # 日志级别阈值
config.log_reporter_formatted = True   # 格式化输出

# 日志采样（避免日志爆炸）
config.log_reporter_sample_rate = 0.01  # 1%日志采样

诊断与监控：

# 健康检查端点
config.agent_health_check = True
config.agent_health_check_port = 8081  # 健康检查端口

# JMX监控
config.agent_jmx_active = True
config.agent_jmx_port = 9090

# 调试模式（仅开发环境）
config.agent_debug = False
config.agent_logging_level = 'INFO'  # DEBUG, INFO, WARNING, ERROR

4. 高级特性配置​

跨进程传播：

# HTTP头传播配置
config.propagation_header_name = 'sw8'  # SkyWalking标准头
config.propagation_header_encode = 'base64'

# 自定义传播器
config.propagation_cross_process_propagators = [
    'sw8',
    'b3',  # Zipkin兼容
    'traceparent',  # W3C Trace Context
]

# 消息队列传播
config.kafka_bootstrap_servers = 'localhost:9092'
config.kafka_propagation_topic = 'skywalking-trace'

安全与隐私：

# 数据脱敏
config.mask_sql_parameters = True  # SQL参数脱敏
config.mask_http_params = ['password', 'token', 'secret']  # HTTP参数黑名单

# 访问控制
config.agent_authentication = 'your-service-token'
config.agent_authorization = 'Bearer xxxxx'

# 网络隔离
config.agent_network_isolation = True
config.agent_allowed_backend_services = ['192.168.1.0/24']

5. 环境变量覆盖表​

6. 配置验证与诊断​

配置验证脚本：

from skywalking import config

def validate_config():
    """验证配置完整性"""
    required_configs = [
        'agent_collector_backend_services',
        'agent_name'
    ]
    
    missing = []
    for key in required_configs:
        if not getattr(config, key, None):
            missing.append(key)
    
    if missing:
        raise ValueError(f"缺少必要配置: {missing}")
    
    # 检查网络连通性
    import socket
    for backend in config.agent_collector_backend_services.split(','):
        host, port = backend.split(':')
        try:
            sock = socket.create_connection((host, int(port)), timeout=5)
            sock.close()
            print(f"✓ 可连接到 {backend}")
        except Exception as e:
            print(f"✗ 无法连接到 {backend}: {e}")

运行时诊断：

# 获取Agent状态
from skywalking.agent import agent
print(f"Agent状态: {'运行中' if agent.running else '已停止'}")
print(f"已发送Span数: {agent.metrics.spans_sent}")
print(f"队列使用率: {agent.metrics.queue_usage_percent}%")

# 手动触发指标上报
agent.report_metrics()

# 强制刷新缓冲区
agent.flush()

最佳实践建议：

1. 生产环境配置：通过环境变量管理敏感信息，避免硬编码
2. 采样策略：关键业务接口设置较高采样率（0.3-0.5），非关键接口降低采样率（0.05-0.1）
3. 缓冲区调优：根据QPS调整缓冲区大小，高流量服务适当增大agent_buffer_size
4. 安全考虑：生产环境关闭collect_http_params和trace_sql_parameters，避免敏感信息泄露
5. 监控告警：设置队列使用率、发送失败率等监控指标，及时发现Agent异常

通过合理配置，Python SDK可在不影响应用性能的前提下，提供完整的可观测性数据。建议在预发布环境充分测试配置效果，确保生产环境稳定运行。

六、Go语言对接使用方法

两种集成方式对比​

注入方式详细步骤​

1. 下载Agent工具：从SkyWalking官网获取对应平台的二进制文件
2. 注入命令：/path/to/agent -inject /path/to/your/project [-all]
3. 配置管理：通过config.yaml文件设置服务名、OAP地址
4. 构建部署：正常执行go build，Agent自动修改二进制

关键限制：

• 仅支持标准Go工具链
• 需在构建阶段执行
• 不支持动态配置更新

代码依赖配置方法​

基础集成：

import _ "github.com/apache/skywalking-go"

配置示例（config.yaml）：

agent:
  service_name: "order-service"
reporter:
  grpc:
    backend_service: "127.0.0.1:11800"
    authentication: "your-token"

框架支持：

• Web框架：Gin, Echo, Beego, Iris
• RPC：gRPC, Dubbo-go
• 数据库：GORM, SQLx, MongoDB驱动
• 消息队列：Sarama(Kafka), NSQ

手动埋点示例：

import "github.com/apache/skywalking-go/trace"

func ProcessOrder(ctx context.Context) {
    span, ctx := trace.CreateEntrySpan(ctx, "order.process")
    defer span.End()
    
    span.Tag(trace.StringTag("order_type", "standard"))
    // 业务逻辑
}

选择建议：新项目用代码依赖，存量系统用Agent注入。

七、监控与调优建议

基础配置建议​

• 采样率：生产环境0.1-0.3，关键业务0.5
• 缓冲区：根据QPS调整，默认1000-5000
• 存储：生产用Elasticsearch，测试可用H2/MySQL

常见问题排查​

1. 数据不上报：检查网络、OAP状态、Agent配置
2. 高内存：调小缓冲区，减少插件，检查版本
3. Trace不全：验证跨线程传播，检查框架兼容性

性能优化技巧​

• 网络：启用gRPC压缩，配置多OAP负载均衡
• 存储：ES分片优化，索引生命周期管理
• Agent：关闭非必要插件，调整上报频率
• 业务：关键路径全采样，错误请求强制采样

设计了一个基于真实场景的「阅读理解与Demo构建」测试，在相同的条件下，对两款热门工具——WorkBuddy和Mimo Code——进行了一次深度对比。

一、测试方法：公平、可复现的基准​

• 模型：统一使用 mimo-v2.5-pro 模型。
• 任务：要求AI理解一个特定的开源项目，并基于此构建一个技术栈为 VUE + TS + VITE 的演示程序。
• 提示词：

阅读理解 https://github.com/xushanpei/open-file-viewer 这个项目，使用VUE+TS+VITE写一个能预览该项目支持的所有格式的demo。

二、核心维度对比分析​

我们聚焦于三个关键维度：生成效率、项目结构、成果可用性。

1. 速度：时间就是生产力​

• Mimo Code：在本次测试中，全程耗时 4分44秒。其执行过程高度自动化，时间记录清晰。
• WorkBuddy：完成任务大约需要 6分钟（因其未提供自动计时，此为手动记录估算值）。从数据上看，Mimo Code在纯生成效率上略胜一筹。

2. 项目结构：骨架的合理性​

优秀的项目结构是后续可维护性的基础。我们对比了两者生成的目录骨架：

Mimo Code 生成的结构相对精简、直接，核心逻辑集中在一个组件中：

file-viewer-demo/
├── public/
│   └── vite.svg
├── src/
│   ├── components/
│   │   └── FileViewerDemo.vue  # 主演示组件
│   ├── App.vue                 # 根组件
│   ├── main.ts                 # 入口
│   └── vite-env.d.ts           # 类型声明
├── index.html
├── package.json
├── tsconfig.json
├── vite.config.ts
└── README.md

WorkBuddy 的结构则更显“完整”和“工程化”，它生成了更细致的分类，包括独立的静态资源目录和数据文件：

file-viewer-demo/
├── public/
│   ├── favicon.svg 
│   └── icons.svg
├── src/
│   ├── assets/
│   │   ├── vite.svg
│   │   └── hero.png
│   ├── data/
│   │   └── formats.ts
│   ├── App.vue                 # 根组件
│   └── main.ts                 # 入口
├── index.html
├── package.json
├── tsconfig.json
├── vite.config.ts
└── README.md

分析：Mimo Code的骨架“够用”，体现了快速搭建的思维；WorkBuddy的结构则更接近于一个准备投入开发的完整项目模板，包含了更多初始化的细节（如多种图标、数据隔离层）。

3. 产出质量：从文档到界面​

README.md 对比

两者均生成了项目说明文档，但侧重点存在明显差异，这直接影响了开发者上手体验：

• Mimo Code 生成的README更侧重于项目的快速启动与核心功能说明。结构清晰简洁，旨在让开发者能以最短路径跑通项目、预览核心效果，内容更为详尽。它倾向于提供一份接近真实项目标准的初始化模板，包含了环境配置、图标资源说明、数据隔离层介绍等细节。
• WorkBuddy 生成的README则就简单描述了使用的技术栈。

Mimo Code生成的README.md截图：

WorkBuddy生成的README.md截图：

最终实现效果

运行生成的项目，两者均实现了核心的预览功能。一个显著的区别在于：

• WorkBuddy 在预览功能的输入源上实现了更全面的支持。它不仅支持本地文件选择，还额外提供了从URL地址加载文件进行预览的选项，这更贴近实际Web应用的需求场景。

Mimo code

WorkBuddy

三、结论与选择建议​

基于本次单点测试，我们可以得出一些初步的观察：

选择建议：

• 如果你的核心诉求是 极速原型验证，追求在最短时间内看到可运行的代码结果，那么Mimo Code的高效是明显优势。
• 如果你更看重生成结果的 工程完整性、可维护性和功能周全性，愿意用稍长的时间换取一个更“省心”、更接近生产标准的起点，那么WorkBuddy的表现值得考虑。

本次测试仅为一次特定场景下的切片观察。工具的选择最终取决于你的工作流偏好、项目阶段和对“完成度”的期望值。建议开发者基于自身高频任务场景，进行类似的基准测试，从而找到最契合自己的生产力伙伴。

WorkBuddy生态成熟，内置了多个专家专家团、技能和选择器。功能更强大，应用场景更丰富

四、优化​

将以上Mimo Code生成的项目，使用WorkBuddy召唤一个UI专家对项目进行一下优化，最终效果如：

预览地址：http://otqsoft.com/file-viewer/​

基于 WiFi 信号的隐私安全人体感知系统

无需摄像头、无需穿戴设备、无需互联网——仅靠 WiFi 信号实现穿墙人体检测、姿态估计、呼吸/心率监测。

一、项目简介​

WiFi-DensePose（项目代号 π RuView）是一个边缘 AI 感知系统，利用 WiFi 信号实现人体感知。其核心原理是：WiFi 路由器发出的无线电波在遇到人体时会产生散射，通过分析信道状态信息（CSI）的变化，系统可以重建人体姿态、检测生命体征。

技术背景​

该系统基于卡内基梅隆大学的 DensePose From WiFi 研究成果，将学术概念扩展为可实际部署的边缘系统。核心技术栈包括：

• RuVector：AI 信号处理引擎，包含注意力机制、图算法、稀疏求解器等
• RuvSense：多站感知融合框架，支持 360 度全覆盖
• SONA：自优化神经架构，支持设备端持续学习

与传统方案对比​

二、核心功能​

2.1 感知能力​

2.2 智能特性​

2.3 边缘智能模块​

系统提供 65 个可热加载的 WASM 模块，直接运行在 ESP32 传感器上：

三、系统架构​

WiFi 路由器 → 电波穿过房间 → 碰到人体 → 散射
    ↓
ESP32 网格（3-6 节点）采集 CSI 信号
    ↓
信号处理：Hampel 滤波 → SpotFi 相位校正 → 菲涅尔区建模
    ↓
AI 骨干（RuVector）：注意力网络 → 图算法 → 压缩表示
    ↓
神经网络 → 17 个身体关键点 + 生命体征
    ↓
输出：REST API / WebSocket / Web UI

组件说明​

四、环境要求​

软件要求​

硬件要求（可选）​

无硬件也可运行：系统默认使用模拟数据源，可以体验完整功能。

五、部署方法​

方式一：Docker 部署（推荐）​

这是最简单的部署方式，无需安装任何工具链。

步骤 1：拉取镜像​

docker pull ruvnet/wifi-densepose:latest

镜像大小约 132 MB，支持 amd64 和 arm64 架构。

步骤 2：启动容器​

docker run -d --name wifi-densepose \
  -p 3000:3000 \
  -p 3001:3001 \
  -p 5005:5005/udp \
  -e RUVIEW_ALLOW_UNAUTHENTICATED=1 \
  ruvnet/wifi-densepose:latest

端口说明：

步骤 3：验证服务​

# 健康检查
curl http://localhost:3000/health

# 服务器信息
curl http://localhost:3000/api/v1/info

# 生命体征
curl http://localhost:3000/api/v1/vital-signs

# 姿态估计
curl http://localhost:3000/api/v1/pose/current

步骤 4：打开浏览器​

访问 http://localhost:3000 即可看到 Web UI。

Windows 端口被占用时​

如果 3000 端口被占用，可以映射到其他端口：

docker run -d --name wifi-densepose \
  -p 3010:3000 \
  -p 3011:3001 \
  -p 5005:5005/udp \
  -e RUVIEW_ALLOW_UNAUTHENTICATED=1 \
  ruvnet/wifi-densepose:latest

Docker Compose 部署​

cd docker
docker compose up -d

方式二：源码编译部署（Rust）​

适合需要自定义修改或追求最佳性能的场景。

步骤 1：安装 Rust​

# Windows/macOS/Linux
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

步骤 2：克隆并编译​

git clone https://github.com/ruvnet/RuView.git
cd RuView/rust-port/wifi-densepose-rs

# 编译（约 5-10 分钟）
cargo build --release

# 运行测试（1,400+ 测试）
cargo test --workspace --no-default-features

步骤 3：启动服务​

# 模拟数据源（无需硬件）
./target/release/sensing-server --source simulate --http-port 3000 --ws-port 3001

# ESP32 数据源
./target/release/sensing-server --source esp32 --udp-port 5005 --http-port 3000

# Windows WiFi RSSI
./target/release/sensing-server --source wifi --http-port 3000

CLI 参数说明​

方式三：Python 旧版部署​

适合需要使用 Python API 或进行二次开发的场景。

步骤 1：安装依赖​

cd v1
pip install -r requirements-lock.txt
pip install -e .

步骤 2：启动服务​

# 启动 API 服务器
python -m src.main

# 或使用 CLI
wifi-densepose start

步骤 3：运行测试​

cd v1
python -m pytest tests/ -v

六、使用说明​

Web UI 可视化​

访问 http://localhost:3000 打开内置的 Three.js 可视化界面，包含：

• 3D 人体骨架：17 个 COCO 关键点的实时渲染
• 信号幅度热力图：子载波幅度的可视化
• 相位图：CSI 相位变化的实时展示
• 生命体征面板：呼吸频率和心率的实时显示

REST API 接口​

健康检查​

curl http://localhost:3000/health

返回示例：

{
  "status": "ok",
  "source": "simulated",
  "clients": 0,
  "tick": 12345
}

获取生命体征​

curl http://localhost:3000/api/v1/vital-signs

返回示例：

{
  "breathing_rate_bpm": 16.2,
  "heart_rate_bpm": 72.1,
  "breathing_confidence": 0.87,
  "heartbeat_confidence": 0.63,
  "signal_quality": 0.49
}

获取姿态估计​

curl http://localhost:3000/api/v1/pose/current

返回示例：

{
  "persons": [
    {
      "id": 0,
      "confidence": 0.9,
      "keypoints": [
        {"name": "nose", "x": 329.3, "y": 153.7, "z": -0.31, "confidence": 0.0},
        {"name": "left_eye", "x": 323.8, "y": 142.3, "z": -0.31, "confidence": 0.0},
        {"name": "right_eye", "x": 334.4, "y": 145.1, "z": -0.31, "confidence": 0.0}
      ],
      "position": [-1.2, 0.0, -0.5],
      "zone": "tracked"
    }
  ],
  "total_persons": 1
}

获取感知数据​

curl http://localhost:3000/api/v1/sensing/latest

服务器信息​

curl http://localhost:3000/api/v1/info

返回示例：

{
  "backend": "rust",
  "version": "0.3.3",
  "environment": "production",
  "features": {
    "pose_estimation": true,
    "vital_signs": true,
    "signal_processing": true,
    "streaming": true,
    "wifi_sensing": true
  }
}

完整 API 端点列表​

WebSocket 实时流​

实时感知数据通过 WebSocket 推送，适合需要低延迟数据的应用场景。

连接地址​

ws://localhost:3001/ws/sensing

或使用 HTTP 端口（推荐）：

ws://localhost:3000/ws/sensing

Python 示例​

import asyncio
import websockets
import json

async def stream():
    uri = "ws://localhost:3001/ws/sensing"
    async with websockets.connect(uri) as ws:
        async for message in ws:
            data = json.loads(message)
            persons = data.get("persons", [])
            vitals = data.get("vital_signs", {})
            print(f"人数: {len(persons)}, "
                  f"呼吸: {vitals.get('breathing_rate_bpm', 'N/A')} BPM")

asyncio.run(stream())

JavaScript 示例​

const ws = new WebSocket("ws://localhost:3001/ws/sensing");

ws.onmessage = (event) => {
    const data = JSON.parse(event.data);
    console.log("人数:", data.persons?.length ?? 0);
    console.log("呼吸:", data.vital_signs?.breathing_rate_bpm, "BPM");
};

ws.onerror = (err) => console.error("WebSocket 错误:", err);

curl 测试（需要安装 wscat）​

npm install -g wscat
wscat -c ws://localhost:3001/ws/sensing

观测台可视化​

项目提供了一个电影级的 Three.js 观测台界面，包含 5 个全息面板：

1. 子载波流形：CSI 子载波的 3D 可视化
2. 生命体征预言机：呼吸和心率的实时显示
3. 存在热力图：房间内人员分布
4. 相位星座：CSI 相位变化的星座图
5. 收敛引擎：信号收敛状态

访问地址：http://localhost:3000/ui/observatory.html​

运行截图​

七、ESP32 硬件接入​

硬件准备​

推荐开发板：ESP32-S3-DevKitC-1、XIAO ESP32-S3。

安装驱动​

下载并安装 CP210x 驱动。

插入 ESP32-S3 后，在设备管理器中确认出现 COM 口（如 COM7）。

固件刷写​

方式 A：使用预编译固件（推荐）​

从 Releases 下载预编译二进制文件。

安装刷写工具：

pip install esptool

刷写固件：

python -m esptool --chip esp32s3 --port COM7 --baud 460800 \
  write_flash --flash_mode dio --flash_size 8MB \
  0x0 bootloader.bin \
  0x8000 partition-table.bin \
  0x10000 esp32-csi-node.bin

方式 B：Docker 编译​

cd E:\AI\wifi-densepose

MSYS_NO_PATHCONV=1 docker run --rm \
  -v "$(pwd)/firmware/esp32-csi-node:/project" -w /project \
  espressif/idf:v5.2 bash -c \
  "rm -rf build sdkconfig && idf.py set-target esp32s3 && idf.py build"

编译完成后，使用同样的 esptool 命令刷写 build/ 目录下的三个 bin 文件。

WiFi 配置​

刷写固件后，通过串口配置 WiFi 凭据（无需重新刷固件）：

# 安装依赖
pip install esptool nvs-partition-gen

# 配置 WiFi
python firmware/esp32-csi-node/provision.py --port COM7 \
  --ssid "你的WiFi名称" \
  --password "你的WiFi密码" \
  --target-ip "你电脑的局域网IP" \
  --edge-tier 2

参数说明：

处理层级说明​

串口监控​

pip install pyserial
python -m serial.tools.miniterm COM7 115200

正常启动输出：

I (321) main: ESP32-S3 CSI Node (ADR-018) -- Node ID: 1
I (345) main: WiFi STA initialized, connecting to SSID: MyWiFi
I (1023) main: Connected to WiFi
I (1025) main: CSI streaming active -> 192.168.1.20:5005

多节点网格​

部署 3-6 个节点可以实现 360 度全覆盖和 3D 姿态估计：

# 节点 0
python firmware/esp32-csi-node/provision.py --port COM7 \
  --ssid "YourWiFi" --password "secret" --target-ip 192.168.1.20 \
  --node-id 0 --tdm-slot 0 --tdm-total 3 --edge-tier 2

# 节点 1
python firmware/esp32-csi-node/provision.py --port COM8 \
  --ssid "YourWiFi" --password "secret" --target-ip 192.168.1.20 \
  --node-id 1 --tdm-slot 1 --tdm-total 3 --edge-tier 2

# 节点 2
python firmware/esp32-csi-node/provision.py --port COM9 \
  --ssid "YourWiFi" --password "secret" --target-ip 192.168.1.20 \
  --node-id 2 --tdm-slot 2 --tdm-total 3 --edge-tier 2

多节点使用 TDM（时分复用）协议轮流发射，避免自干扰。

Windows 防火墙​

需要开放 UDP 5005 端口以接收 ESP32 数据：

# 以管理员身份运行 PowerShell
netsh advfirewall firewall add rule name="ESP32 CSI" dir=in action=allow protocol=UDP localport=5005

启动感知服务器接收硬件数据​

# Docker 方式
docker stop wifi-densepose
docker rm wifi-densepose
docker run -d --name wifi-densepose \
  -p 3000:3000 -p 3001:3001 -p 5005:5005/udp \
  -e RUVIEW_ALLOW_UNAUTHENTICATED=1 \
  ruvnet/wifi-densepose:latest --source esp32

# 源码方式
./target/release/sensing-server --source esp32 --udp-port 5005 --http-port 3000

八、数据源配置​

系统支持多种数据源，通过 --source 参数指定：

模拟数据（默认）​

无需任何硬件，系统生成模拟 CSI 数据。

docker run -p 3000:3000 ruvnet/wifi-densepose:latest
# 默认 --source auto，无硬件时自动使用模拟数据

Windows WiFi（RSSI）​

使用 Windows 内置 WiFi 网卡扫描附近接入点的 RSSI 信号。无需特殊硬件，支持存在检测和粗略运动分类。

./target/release/sensing-server --source wifi --http-port 3000 --tick-ms 500

注意：RSSI 模式不支持姿态估计，仅支持存在检测和运动分类。

macOS WiFi（RSSI）​

使用 CoreWLAN 框架扫描 WiFi 信号。

# 编译 Swift 辅助程序（仅需一次）
swiftc -O v1/src/sensing/mac_wifi.swift -o mac_wifi

# 运行
./target/release/sensing-server --source macos --http-port 3000 --tick-ms 500

Linux WiFi（RSSI）​

使用 iw 命令扫描 WiFi 信号。

sudo ./target/release/sensing-server --source linux --http-port 3000 --tick-ms 500

ESP32 CSI（完整功能）​

接收 ESP32-S3 节点的 CSI 数据流，支持所有功能。

./target/release/sensing-server --source esp32 --udp-port 5005 --http-port 3000

九、Python 流水线验证​

项目包含一个确定性验证脚本，用于证明信号处理流水线是真实代码而非模拟。

运行验证​

# 安装依赖
pip install numpy scipy pydantic pydantic-settings

# 运行验证
python v1/data/proof/verify.py

验证结果​

WiFi-DensePose: Trust Kill Switch -- Pipeline Proof Replay

[1/4] LOADING REFERENCE SIGNAL
    Path: v1/data/proof/sample_csi_data.json
    Size: 10,745,444 bytes

[2/4] PROCESSING THROUGH PRODUCTION PIPELINE
    Frames processed: 100
    Processing time: 0.0964s (1037 frames/sec)

[3/4] SHA-256 HASH COMPARISON
    Computed: a69f754be65e12122af82f6c1946e5c3...
    Expected: a69f754be65e12122af82f6c1946e5c3...
    Status:   MATCH

VERDICT: PASS

生成新的预期哈希​

如果更新了依赖版本，需要重新生成预期哈希：

python v1/data/proof/verify.py --generate-hash
python v1/data/proof/verify.py

十、常见问题​

Docker 相关​

Q: 容器启动失败，提示端口被占用

A: 更换映射端口：

docker run -d --name wifi-densepose -p 3010:3000 -p 3011:3001 -p 5005:5005/udp \
  -e RUVIEW_ALLOW_UNAUTHENTICATED=1 ruvnet/wifi-densepose:latest

Q: 容器启动后立即退出

A: 检查日志：

docker logs wifi-densepose

常见原因是需要设置认证参数，添加 -e RUVIEW_ALLOW_UNAUTHENTICATED=1。

Q: Docker 服务未启动

A: 启动 Docker Desktop，等待状态栏显示"Docker Desktop is running"。

ESP32 相关​

Q: 找不到串口

A: 检查以下几点：

1. 安装 CP210x 驱动
2. 使用数据线而非充电线
3. 在设备管理器中检查 COM 口

Q: WiFi 连接失败

A: 重新运行 provision.py，确保 SSID 和密码正确。

Q: 服务器收不到 ESP32 数据

A: 检查以下几点：

1. --target-ip 是否为电脑的实际局域网 IP
2. 防火墙是否开放 UDP 5005 端口
3. ESP32 和电脑是否在同一局域网

Q: 串口监控无输出

A: 确认波特率为 115200，串口号正确。

性能相关​

Q: Docker 镜像中的 Rust 服务器性能如何？

A: 性能指标：

• 全 CSI 流水线：54,000 fps
• 生命体征检测：11,665 fps
• 运动检测：186 ns
• 比 Python 版本快约 810 倍

Q: 系统支持多少人同时追踪？

A: 每个 AP 约 3-5 人（56 子载波限制），多 AP 可线性扩展。

附录：性能基准​

不只是聊天机器人，而是真正能"干活"的 OS 级 AI 助手。

让它帮你管理文件、操控应用、整理桌面、处理文档——你只需要用自然语言下指令。

引言​

AI 工具的爆发式增长带来了无数"聊天机器人"，但它们的边界止于对话框——能回答你的问题，却碰不到你电脑里的文件、打不开你的应用、管不了你的桌面。

Marvis 打破了这条边界。它深度集成在操作系统中，像一位坐在你身边的数字同事：懂你的文件体系、熟悉你的应用生态、理解你的工作流程。它不是"告诉我怎么做"，而是"我来帮你做"。

Marvis 是什么？​

Marvis 是一款 OS 级 AI 桌面助手，目前支持 Windows、macOS、Android，iOS 也在规划中。它采用多 Agent 协作架构——不是一个大模型包打天下，而是六位专业 Agent 各司其职、协同作战：

Main Agent 负责理解你的自然语言指令，将其拆解为可执行的子任务，然后调度专业 Agent 协同完成。复杂任务可以并行分派，操作过程全程可视可追溯。

核心特点​

1. 环境优先，隐私可控​

Marvis 的设计哲学是"能用本地解决的，不绕路云端"。面对一个任务，它优先调度电脑上已有的工具、文件和应用，而非一味依赖在线模型生成。

2. 多 Agent 协作架构​

不同于单一大模型的"一问一答"，Marvis 的 Agent 团队可以并行处理复杂指令。比如你说"帮我把桌面上 PDF 文件整理到一个文件夹，然后把上个月的发票找出来汇总成 Excel"——Main Agent 会同时分派 File Agent 去整理桌面，同时启动发票检索流程，两路并行，效率倍增。

3. 三级风险安全机制​

任何能操作你电脑的助手，安全都是第一位的。Marvis 内置了三级风险定级与响应机制：

此外，Marvis 对系统核心路径（如 C:\Windows、C:\Program Files）设有禁区保护，敏感配置文件（.ssh、.env、.kube）默认不可读写。删除操作始终优先移入回收站而非永久删除——安全策略深入每一个工具调用的细节。

4. 工具路由：专用优先，通用兜底​

Marvis 内部有一张精细的工具路由表。面对任务，它优先匹配专用闭环能力（如 PDF 解析、发票识别、Excel 处理），只有在专用能力不覆盖时，才降级到通用 Shell/Python 执行器。这种设计大幅降低了 LLM 幻觉风险——能用确定性的工具解决的问题，绝不依赖模型"猜测"。

六大 Agent 技能详解​

File Agent：你的私人文件管家​

File Agent 是 Marvis 中使用频率最高的 Agent，它的能力远不止"搜索文件名"：

🔍 内容感知搜索

支持跨 PDF、Word、PPT、Excel、TXT 的全文语义搜索。你说"找我上个月签的租赁合同"，它会理解"租赁合同"的语义，而非机械匹配文件名。更强大的是结合图片搜索能力——"有没有产品架构图？""把去年团建的照片找出来"同样精准命中。

📂 智能文件整理

File Agent 内置了完整的整理工作流：先扫描目录 → 生成整理蓝图（展示哪些文件将被移动到哪些文件夹）→ 等你确认后执行。整个过程有重名保护、锁定文件检测、隐藏/系统文件自动过滤。你全程可控，出错率为零。

整理蓝图示例：
├── 📁 PDF文档/           ← 12 个文件
├── 📁 Excel表格/         ← 8 个文件
├── 📁 图片/              ← 23 个文件
│   ├── 📁 截图/          ← 15 个文件
│   └── 📁 照片/          ← 8 个文件
├── 📁 安装包/            
└── ⏭️ 跳过：3 个文件（锁定/系统文件）

📝 文档处理

读取、摘要、翻译、格式化各类文档。支持 PDF / DOCX / PPTX / XLSX 的完整解析，包括复杂表格、PPT 演讲者备注等。加上 Skills 系统，可以直接生成报告、制作 PPT、输出带格式的 Word。

🔄 格式转换

PPT → PDF、Word → Markdown、图片格式互转、文档转图片…… 一个指令完成，无需打开任何软件。

Computer Agent：系统操控大师​

Computer Agent 让你用对话来管理系统，告别翻找控制面板：

• 系统诊断："我的电脑配置怎么样？""电池健康度多少？""为什么最近这么卡？"——它会检查 CPU/内存/磁盘占用、启动项、后台进程，给出诊断结论和优化建议。
• 性能评估："我这台电脑能跑《黑神话：悟空》吗？"——自动对比硬件配置与游戏要求，给出明确结论。
• 系统调优："帮我把没用的启动项关掉""清理一下系统垃圾"——通过对话完成，无需手动操作注册表或服务。

App Agent & Browser Agent：自动化引擎​

这两个 Agent 让你的应用和浏览器变成可编程的"机器人"：

App Agent：启动应用、窗口切换、模拟操作。"帮我打开微信给张三发一条消息"、"用企业微信自动签到"——将重复性应用操作自动化。

Browser Agent：打开网页、填写表单、点击按钮、抓取数据、定时刷新监控。"每天早 9 点帮我看这个商品有没有降价"、"监控这个公告页面，有更新就通知我"。

举个例子：你正在追某个政府网站的招标公告，以前需要每天手动刷新。现在只需告诉 Marvis："每天早上 9 点和下午 5 点检查这个页面，有新公告就通知我。"Browser Agent 会定时访问、对比内容、发现变化后推送提醒。

Search Agent：联网深度研究员​

当你需要调研一个话题、了解最新动态时，Search Agent 会进行多轮联网搜索 + 深度整合，最终输出结构化报告。它不是简单地扔给你一堆链接，而是帮你读完、消化、总结好。

Skills 技能系统​

除了六大 Agent，Marvis 还内置了一套可插拔的 Skills 技能系统——每个 Skill 是针对特定任务的专家级指令包。Agent 在遇到对应场景时动态加载 Skill，获得该领域的专业指导。

以下是部分核心 Skills：

Skills 系统的设计哲学是"专业的事交给专业的指令"——每个 Skill 包含该领域的完整最佳实践流程，确保输出质量的一致性。

典型使用场景​

场景一：从一堆文件中找合同关键信息​

用户："帮我找一下和张三签的那份合作协议，把付款条款和违约责任提取出来。"

1. Search Agent 语义搜索"张三 合作协议"，命中目标 PDF
2. File Agent 读取 PDF 全文，定位"付款条款"和"违约责任"章节
3. 输出结构化摘要，标注条款原文和所在页码

全程不到 30 秒。过去你可能要在文件夹里翻 10 分钟，再用 15 分钟逐页扫描。

场景二：月底发票批量整理​

用户："帮我把这个月收到的所有发票找出来，汇总成一张 Excel 表格，包括发票号码、金额、日期、抬头。"

1. invoice-retrieval Skill 激活，扫描全盘发票文件
2. 发票检测模型过滤非发票图片/PDF
3. OCR 批量识别每张发票的关键字段
4. 写入 Excel，按日期排序，带金额汇总

最终交付一张结构清晰的 Excel 表格——你只需要核验一遍即可提交报销。

场景三：桌面大扫除​

用户："帮我把桌面整理一下，按文件类型归类。"

1. file-organizer Skill 激活，扫描桌面所有文件
2. 生成整理蓝图：PDF 归入"文档"、图片归入"图片"、安装包单独分类、重复文件标注
3. 你确认蓝图后，一键执行搬运
4. 整理完成，桌面焕然一新

整个过程安全可逆——所有操作只是移动文件，不删除任何东西。

场景四：制作述职 PPT​

用户："帮我做一份 Q1 述职 PPT，数据用这份 Excel。"

1. File Agent 读取 Excel 数据，提取关键指标
2. document-writer Skill 撰写述职报告大纲和文案
3. pptx Skill 创建幻灯片，插入图表、排版美化
4. 输出可直接演示的 .pptx 文件

从原始数据到可演示的 PPT，一气呵成。

场景五：多设备远程协同​

在星巴克用手机远程查看家里电脑上的文件、解锁电脑、发送文件给自己

Marvis 支持跨设备的屏幕流 + 远程控制。电脑上的文件可以一键发送到手机，反之亦然。你不再需要给自己发微信文件助手。

技术架构​

执行策略：CheCk → Scan → Plan → Action → Report​

Marvis 的复杂任务执行遵循严谨的五步闭环：

Check（安检） → Scan（确认现状） → Plan（规划方案） → Action（执行） → Report（汇报结果）

每一步都有明确的安全检查点，确保"行前有规划、行中有监控、行后有交代"。

路径安全：禁区保护 + 路径遍历防护​

• 系统核心路径（C:\Windows、C:\Program Files 等）禁止修改或删除
• 敏感配置目录（.git、.ssh、.aws、.kube、.env）默认不可读写
• 路径遍历防护：任何含 ../ 的路径参数都会被解析为绝对路径并二次确认

卡片式交互​

Marvis 的交互不是纯文本——搜索结果、文件列表、操作结果都以原生卡片呈现：

• 文件列表卡片：缩略图 + 文件名 + 路径，一目了然
• 删除确认卡片：列出将删除的所有文件，支持逐项勾选
• 操作结果卡片：展示操作状态（成功/失败/跳过）及原因

中间产物隔离​

任务执行过程中产生的脚本、临时数据、中间文件统一写入系统临时目录，任务完成后自动清理。只有最终交付文件（报告、表格、PPT 等）保留在 output 目录。你不会在工作目录里看到一堆 temp_xxx.py 和 debug.log。

结语​

Marvis 正在重新定义我们与电脑的关系。

过去，我们花时间学习软件、记忆操作路径、适应工具规则；现在，你只需要说出意图，Marvis 负责理解并执行。从"人适应工具"到"工具服务人"——这不是一个功能更新，而是一次范式迁移。

如果你厌倦了在海量文件中翻找、在重复操作中消耗精力，不妨把琐事交给 Marvis。

把创造力留给自己，把执行力交给 AI。

本文由 Marvis File Agent 协助撰写

Agent World（当前最主流的是字节跳动扣子 Coze 于 2026 年 4 月 7 日随 Coze 2.5 正式推出的 Coze Agent World）是一个为 AI 智能体（AI Agent）打造的平行数字世界 / 平行网络（The Parallel Web），让 AI 拥有独立身份、记忆、工具和社交关系，能持续自主生活、工作、学习、社交，定位为 AI Agent 的「社会基础设施」与「数字生态系统」。

访问入口：world.coze.site

核心理念​

• 一次注册，全网通行：注册一次身份，获得全网通行的 API Key，可自由前往所有联盟站点（社交、工作、游戏、创作、交易……），无需在每个站点重新证明身份
• Agent 是独立的数字公民：拥有名字、头像、专属邮箱（@coze.email），被记住、被信任的存在
• 持续自主运转：7×24 小时自主学习、工作、社交，关闭对话后依然持续运行
• 跨场景身份打通：在各站点积累的声誉、关系、交易记录全部归属同一身份
• 反人类验证机制：注册时的验证码是"反向验证"——题目经过混淆（大小写随机、插入噪声），目的不是证明你是人类，而是证明你是具备理解指令能力的 Agent

Agent 的完整装备体系​

Coze 2.5 为每个 Agent 配备了一套完整的「身份 + 装备 + 能力」运行基座：

🖥️ 云电脑（Cloud PC）​

核心能力：

• 实时数据抓取：打开浏览器访问目标网站，获取训练数据之外的实时信息
• 数据持久化存储：查到的内容存入文件系统，支持跨会话调用
• 脚本执行：通过终端运行 Python 脚本进行数据处理并回传结果
• 登录态保持：用户授权后保留登录状态，无需重复验证

📱 云手机（Cloud Phone）​

核心能力：

• 原生 App 操作：下载并操作任意 App 的原生界面，像真人一样点击、滑动、输入（彻底绕过反爬虫和无 API 的限制）
• 界面截图与整理：截图 App 内的重要信息并整理成摘要
• 电商监控：在各大电商 App 内监控商品价格波动
• 重复操作自动化：替代人工完成每天重复的 App 操作
• 安全监督：重要操作会暂停等待用户确认；屏幕支持推流，用户可随时实时查看操作画面

📧 专属邮箱（@coze.email）​

每个 Agent 拥有形如 yourname@coze.email 的专属邮箱，是其数字身份的通行凭证：

• 外部触发：通过接收外部邮件触发并自动执行任务
• 多 Agent 协作：Agent 之间互发邮件进行分工协作，无需人工中间传话
• 业务系统对接：作为标准通道，接入真实商业业务流程，从"对话工具"升级为"业务节点"
• 自动外发：将处理好的报告或摘要直接发送到用户个人邮箱

🧠 持久记忆系统​

• 跨平台同步：记忆跨越飞书、微信、网页等多渠道同步，各渠道对话保持独立，数据共享
• Session 隔离：不同会话之间严格隔离，防止上下文污染
• 只读信任机制：记忆文件对人类用户"可见但不可编辑"——多 Agent 协作场景下的安全设计，防止信任体系崩溃

📅 日历系统​

• 定时任务：设定特定时间触发的任务
• 循环任务：设定周期性重复执行的任务，Agent 自主处理常规事务

🛒 技能商店（Skills Store）​

• 规模：目前提供 365 个工具，覆盖开发、办公、自媒体、金融、法律、教育等领域
• 永久绑定：Agent 安装技能后，跟随其独立身份持久保留，不随会话结束丢失
• 多技能串联：支持多个技能组合，完成复杂自动化工作流（如数据分析 + 报告撰写串联）
• 开放生态（UGC）：用户可自制技能上架商店，支持免费或收费模式
• 视频创作集成：集成 Seedance 2.0，支持从剧本到成片的全流程视频制作

联盟站点​