首页
/ rtk Rust 开发指南：CLI 代理回退、LazyLock 正则与 Token 节省验证的核心实现模式

rtk Rust 开发指南：CLI 代理回退、LazyLock 正则与 Token 节省验证的核心实现模式

2026-09-05 10:53:25作者：盛欣凯Ernestine
rtk
CLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies
项目地址：https://gitcode.com/GitHub_Trending/rtk4/rtk

本文基于 RTK 仓库中的 Claude Code Agent 定义文件 rust-rtk.md 展开，系统讲解这个专职维护 RTK 代码库的 Rust 专家 Agent 所固化的核心工程规范：CLI 代理的命令路由与回退机制、基于 LazyLock<Regex> 的正则懒编译性能设计、以 count_tokens() 为准的 Token 节省验证体系，以及过滤器（filter）从创建到基准测试的完整开发工作流。读完本文，你将掌握在 RTK 这类“零依赖单 Rust 二进制”CLI 代理项目中编写高性能过滤器、保证 60–90% Token 节省可验证、并确保跨平台（macOS/Linux/Windows）可用性的关键技术与质量门禁。

Agent 定位与核心职责

RTK（Rust Token Killer）是一个通过过滤和总结常见开发命令的输出来降低 LLM Token 消耗的 CLI 代理，目标是在通用开发命令上实现 60–90% 的 Token 节省，以单 Rust 二进制、零依赖的方式交付。仓库中的 .claude/agents/ 目录定义了多个协作 Agent（如 code-reviewer.md、debugger.md、rtk-testing-specialist.md），其中 rust-rtk.md 的 frontmatter 声明如下：

name: rust-rtk
description: Expert Rust developer for RTK - CLI proxy patterns, filter design, performance optimization
model: sonnet
tools: Read, Write, Edit, MultiEdit, Bash, Grep, Glob

该 Agent 被定位为“RTK 代码库架构的专家 Rust 开发者”，其核心职责覆盖五个方面：

  • CLI 代理架构：命令路由（command routing）、stdin/stdout 转发、回退处理（fallback handling）；
  • 过滤器开发：基于正则的压缩（condensation）、Token 计数、输出格式保持；
  • 性能优化：零开销设计、LazyLock 正则、最小化内存分配；
  • 错误处理：CLI 二进制统一使用 anyhow，过滤器失败时优雅回退；
  • 跨平台兼容：macOS/Linux/Windows 下 bash/zsh/PowerShell 的 shell 兼容。

这个 Agent 定义本质上是一份“可执行的编码规范”：它不是泛泛的 Rust 最佳实践，而是每一条都能在当前仓库源码中找到印证的设计约束。

CLI 代理回退：RTK 的第一设计原则

规范：过滤失败必须回退到原始命令

文档将 “CLI Proxy Fallback” 标注为 Critical：过滤器失败或不存在时，必须回退到原始命令，且永不 panic。文档给出的标准写法：

pub fn execute_with_filter(cmd: &str, args: &[&str]) -> anyhow::Result<Output> {
    match get_filter(cmd) {
        Some(filter) => match filter.apply(cmd, args) {
            Ok(output) => Ok(output),
            Err(e) => {
                eprintln!("Filter failed: {}, falling back to raw", e);
                execute_raw(cmd, args) // Fallback on error
            }
        },
        None => execute_raw(cmd, args), // Fallback if no filter
    }
}

// ❌ NEVER panic if no filter or on filter failure
pub fn execute_with_filter(cmd: &str, args: &[&str]) -> anyhow::Result<Output> {
    let filter = get_filter(cmd).expect("Filter must exist"); // WRONG!
    filter.apply(cmd, args) // No fallback - breaks user workflow
}

文档给出的理由值得原样保留：RTK must never break user workflow（RTK 绝不能打断用户工作流）。如果过滤器失败，就原样执行原始命令。这是一条被反复强调的“关键设计原则”，并出现在文档末尾的反模式清单（❌ DON'T panic on filter failure）与正确做法清单（✅ DO provide fallback to raw command on filter failure）中。

源码印证：run_fallback 的实际实现

从源码结构看，src/main.rs 中的 run_fallback(parse_error: clap::Error) -> Result<i32> 正是这条原则的落地。当 Clap 无法解析一个子命令时，RTK 并不会报错退出，而是：

  1. 保护元命令：若第一个参数属于 RTK_META_COMMANDS（如 gain），说明用户打错了 RTK 自身命令，此时直接展示 Clap 错误，绝不把 rtk gain --typo 当作外部命令执行；
  2. TOML 过滤器查找：用 core::toml_filter::find_matching_filter(&lookup_cmd) 按命令 basename（支持 /usr/bin/make 匹配 ^make\b 这类锚定模式）查找声明式过滤器，可通过 RTK_NO_TOML=1 环境变量绕过；
  3. 捕获并过滤 stdout：匹配到过滤器时捕获 stdout（需要时合并 stderr，用于剥离 liquibase 一类工具输出的 banner），过滤后通过 core::tee::tee_and_hint 在失败时给出原始输出恢复提示；
  4. 无匹配则流式透传：Stdio::inherit 全继承，保持 rtk <cmd> | grep x 管道行为不变，并以 timer.track_passthrough 记录追踪；
  5. 命令不存在返回 127：与 shell 的 “command not found” 约定一致，只打印单条 [rtk: ...] 消息，避免重复 Clap 错误。

这条调用链与文档描述的 “Command routing, stdin/stdout forwarding, fallback handling” 三项职责一一对应：解析失败 → 路由到回退 → 透传或过滤 → 尊重退出码。

LazyLock 正则懒编译：性能关键模式

文档把 “Lazy Regex Compilation” 标注为 Performance Critical。核心结论：正则编译昂贵（每个模式约 1–5ms），而 RTK 的目标是总启动时间 <10ms，因此声明期固定的正则需要用 std::sync::LazyLock 编译一次、永久复用。

✅ 正确写法（编译一次，每行复用）：

use regex::Regex;
use std::sync::LazyLock;

static COMMIT_HASH: LazyLock<Regex> =
    LazyLock::new(|| Regex::new(r"[0-9a-f]{7,40}").unwrap());
static AUTHOR_LINE: LazyLock<Regex> =
    LazyLock::new(|| Regex::new(r"^Author: (.+) <(.+)>$").unwrap());

pub fn filter_git_log(input: &str) -> String {
    input.lines()
        .filter_map(|line| {
            // Regex compiled once, reused for every line
            COMMIT_HASH.find(line).map(|m| m.as_str())
        })
        .collect::<Vec<_>>()
        .join("\n")
}

❌ 错误写法（每行重新编译，摧毁性能）：

pub fn filter_git_log(input: &str) -> String {
    input.lines()
        .filter_map(|line| {
            // RECOMPILED ON EVERY LINE! Destroys performance
            let re = Regex::new(r"[0-9a-f]{7,40}").unwrap();
            re.find(line).map(|m| m.as_str())
        })
        .collect::<Vec<_>>()
        .join("\n")
}

这一模式在仓库中已被大规模采用：仅 src/cmds/ 与 src/core/ 下就有多处 LazyLock<Regex> 静态定义，例如 src/cmds/jvm/gradlew_cmd.rs、src/cmds/git/glab_cmd.rs、src/core/filter.rs 与 src/core/toml_filter.rs。可以推断，这些命令输出格式多变（Gradle、git log、测试报告），静态 LazyLock 正则是它们控制启动开销的共同手段。

文档在“反模式”一节再次给出量化约束：正则编译约 1–5ms/模式，引入 async 运行时约增加 5–10ms 启动开销，因此 RTK 保持单线程、无 tokio/async-std，目标总启动 <10ms。

Token 节省验证：60–90% 承诺必须可测试

RTK 对外承诺 60–90% 的 Token 节省。文档要求所有过滤器在测试中验证这一声明，并给出标准测试范式：

#[cfg(test)]
mod tests {
    use super::*;

    // Helper function (exists in tests/common/mod.rs)
    fn count_tokens(text: &str) -> usize {
        // Simple whitespace tokenization (good enough for tests)
        text.split_whitespace().count()
    }

    #[test]
    fn test_git_log_savings() {
        // Use real command output fixture
        let input = include_str!("../tests/fixtures/git_log_raw.txt");
        let output = filter_git_log(input);

        let input_tokens = count_tokens(input);
        let output_tokens = count_tokens(&output);

        let savings = 100.0 - (output_tokens as f64 / input_tokens as f64 * 100.0);

        // RTK promise: 60-90% savings
        assert!(
            savings >= 60.0,
            "Git log filter: expected ≥60% savings, got {:.1}%",
            savings
        );

        // Also verify output is not empty
        assert!(!output.is_empty(), "Filter produced empty output");
    }
}

三个要点缺一不可：使用真实命令输出 fixture、断言节省率 ≥60%、断言输出非空。文档明确：节省率声明必须可验证，用真实 fixture 的测试能防止回归；若节省率跌破 60%，属于发布阻断项（release blocker）。

对照当前仓库的实际实现，有几个值得注意的事实：

  • count_tokens 的真实位置在 src/core/utils.rs，实现正是文档中的空白分词：text.split_whitespace().count()，并标注 #[cfg(test)]、注释说明“用于过滤器测试验证 Token 节省声明”。文档中提到的 tests/common/mod.rs 为 Agent 建议的共享位置，当前仓库以 src/core/utils.rs 的测试辅助函数为准。
  • 该验证范式在各命令模块的测试中被广泛使用，例如 src/cmds/cloud/aws_cmd.rs 的测试直接 use crate::core::utils::count_tokens 计算输入/输出 Token 并断言节省比例。
  • tests/fixtures/ 目录存放了大量真实命令输出样本（ctest_*_raw.txt、gradlew_*_raw.txt、mvn_*_raw.txt、glab_*_raw.json、golangci_v2_json.txt 等），与文档 “DON'T assume command output format → Test with fixtures” 的要求一致。
  • 从 docs/contributing/TECHNICAL.md 的交叉印证看，count_tokens 与 rtk gain 背后的 bytes / 4 估算器都是近似值，作为比率可靠——这解释了为什么测试断言的是节省比例而非绝对 Token 数。

跨平台 Shell 转义

RTK 必须同时运行在 macOS（zsh）、Linux（bash）、Windows（PowerShell）上，而 shell 转义规则各不相同。文档给出的分平台实现：

#[cfg(target_os = "windows")]
fn escape_arg(arg: &str) -> String {
    // PowerShell escaping: wrap in quotes, escape inner quotes
    format!("\"{}\"", arg.replace('"', "`\""))
}

#[cfg(not(target_os = "windows"))]
fn escape_arg(arg: &str) -> String {
    // Bash/zsh escaping: escape special chars
    shell_escape::escape(arg.into()).into()
}

配套测试按 target_os 条件编译不同断言，覆盖 git log --format="%H %s" 这类含引号参数在 Windows/macOS/Linux 下的转义结果。文档还给出三平台测试矩阵：

  • macOS：本地 cargo test；
  • Linux：docker run --rm -v $(pwd):/rtk -w /rtk rust:latest cargo test；
  • Windows：依赖 CI/CD 或手动测试。

反模式清单进一步强调 “macOS ≠ Linux ≠ Windows”，至少要在 macOS + Linux（Docker）两个环境跑测试。管道兼容性同样是硬性要求：rtk git status | grep modified 必须可用——保持 stdout/stderr 分离，并尊重退出码语义（0 为成功，非零为失败）。

错误处理：anyhow + Context + 优雅降级

文档规定 RTK 的 CLI 二进制统一使用 anyhow::Result，并给出对比示例：

use anyhow::{Context, Result};

pub fn filter_cargo_test(input: &str) -> Result<String> {
    let lines: Vec<_> = input.lines().collect();

    // ✅ RIGHT: Context on every ? operator
    let test_summary = extract_summary(lines.last().ok_or_else(|| {
        anyhow::anyhow!("Empty input")
    })?)
    .context("Failed to extract test summary line")?;

    // ❌ WRONG: No context
    let test_summary = extract_summary(lines.last().unwrap())?;

    // ❌ WRONG: Panic in production
    let test_summary = extract_summary(lines.last().unwrap()).unwrap();

    Ok(format!("Tests: {}", test_summary))
}

三条硬性规则：

  1. 每个 ? 操作符都要带 .context("description")，让错误链可定位；
  2. 生产代码中禁止 unwrap()（测试代码可用，必要时用 expect("explanation")）；
  3. 优雅降级：过滤器失败时回退到原始命令执行，与上文 CLI 代理回退原则闭环。

这与 src/main.rs 的实际 import（use anyhow::{Context, Result};）一致，anyhow 贯穿整个二进制。

强制提交前检查（Quality Gates）

文档要求每次提交前执行三道检查，缺一不可：

cargo fmt --all && cargo clippy --all-targets && cargo test --all

规则：

  • 任何未通过全部 3 项检查的代码不得提交；
  • 修复所有 Clippy 警告（零容忍）；
  • 构建失败时立即修复，再继续开发。

文档给出的理由：RTK 是生产级 CLI 工具，bug 会直接打断开发者工作流，质量门禁用于防止回归。这与 scripts/test-all.sh 等仓库测试脚本的定位相互呼应。

测试策略：单元、快照与集成三层

单元测试（内嵌于模块）

单元测试放在各模块内部 #[cfg(test)] 中，标准做法是加载 tests/fixtures/ 下的真实命令输出，验证格式保持与节省率 ≥60%：

#[test]
fn test_filter_accuracy() {
    // Use real command output fixtures from tests/fixtures/
    let input = include_str!("../tests/fixtures/cargo_test_raw.txt");
    let output = filter_cargo_test(input).unwrap();

    // Verify format preservation
    assert!(output.contains("test result:"));

    // Verify token savings ≥60%
    let input_tokens = count_tokens(input);
    let output_tokens = count_tokens(&output);
    let savings = 100.0 - (output_tokens as f64 / input_tokens as f64 * 100.0);
    assert!(savings >= 60.0, "Expected ≥60% savings, got {:.1}%", savings);
}

同时对畸形输入做降级行为测试：

#[test]
fn test_fallback_on_error() {
    // Test graceful degradation
    let malformed_input = "not valid command output";
    let result = filter_cargo_test(malformed_input);

    // Should either:
    // 1. Return Ok with best-effort filtering, OR
    // 2. Return Err (caller will fallback to raw)
    // Both acceptable - just don't panic!
}

要点：对无法解析的输入，返回“尽力过滤的 Ok”或“由调用方回退的 Err”都算合规——唯一不可接受的是 panic。当前仓库的 tests/ 目录下如 search_faithful_test.rs、grep_faithful_format_test.rs、guard_integration_test.rs 等集成测试文件，正是这类“输出保真 + 错误路径”测试的实际形态。

快照测试（insta crate）

对复杂过滤器使用 insta 快照测试锁定输出格式：

use insta::assert_snapshot;

#[test]
fn test_git_log_output_format() {
    let input = include_str!("../tests/fixtures/git_log_raw.txt");
    let output = filter_git_log(input);

    // Snapshot test - will fail if output changes
    assert_snapshot!(output);
}

快照工作流为：cargo test 运行 → cargo insta review 审查差异 → cargo insta accept 接受变更。

集成测试（真实命令）

集成测试直接调用已安装的 rtk 二进制，验证端到端压缩效果，并以 #[ignore] 标记、按需运行：

#[test]
#[ignore] // Run with: cargo test --ignored
fn test_real_git_log() {
    let output = std::process::Command::new("rtk")
        .args(&["git", "log", "-10"])
        .output()
        .expect("Failed to run rtk");

    assert!(output.status.success());
    assert!(!output.stdout.is_empty());

    // Verify condensed (not raw git output)
    let stdout = String::from_utf8_lossy(&output.stdout);
    assert!(
        stdout.len() < 5000,
        "Output too large ({} bytes), filter not working",
        stdout.len()
    );
}

运行前提：处于 git 仓库且 rtk 已安装，命令为 cargo test --ignored。

关键文件参考

文档给出的文件地图与当前仓库结构吻合，可作为导航索引：

核心基础设施（src/core/）：

命令模块（src/cmds/<ecosystem>/）：

  • src/cmds/git/ — git.rs、gh_cmd.rs、glab_cmd.rs、gt_cmd.rs、diff_cmd.rs；
  • src/cmds/rust/ — cargo_cmd.rs、runner.rs；
  • src/cmds/js/ — lint_cmd.rs、tsc_cmd.rs、next_cmd.rs、prettier_cmd.rs、playwright_cmd.rs、prisma_cmd.rs、vitest_cmd.rs、pnpm_cmd.rs、npm_cmd.rs；
  • src/cmds/python/ — ruff_cmd.rs、pytest_cmd.rs、mypy_cmd.rs、pip_cmd.rs、uv_cmd.rs；
  • src/cmds/go/ — go_cmd.rs、golangci_cmd.rs；
  • src/cmds/ruby/ — rake_cmd.rs、rspec_cmd.rs、rubocop_cmd.rs；
  • src/cmds/cloud/ — aws_cmd.rs、container.rs、curl_cmd.rs、wget_cmd.rs、psql_cmd.rs；
  • src/cmds/system/ — ls.rs、tree.rs、read.rs、search.rs、find_cmd.rs 等；
  • 此外仓库还扩展了 src/cmds/jvm/（gradlew_cmd.rs、mvn_cmd.rs）、src/cmds/php/、src/cmds/scala/、src/cmds/dotnet/ 等生态模块，src/filters/ 下则是大量声明式 TOML 过滤器（如 make.toml、terraform-plan.toml、systemctl-status.toml），与上文 run_fallback 中的 TOML 过滤器查找路径相呼应。

Hook 与分析（src/hooks/、src/analytics/）：src/hooks/init.rs 实现 rtk init，src/analytics/gain.rs 实现 rtk gain。

测试：tests/fixtures/ 存放真实命令输出 fixture；count_tokens 等测试辅助位于 src/core/utils.rs。

常用命令速查

文档汇总的 RTK 开发命令集：

# Development
cargo build --release              # Release build (optimized)
cargo install --path .             # Install locally

# Run with specific command (development)
cargo run -- git status
cargo run -- cargo test
cargo run -- gh pr view 123

# Token savings analytics
rtk gain                           # Show overall savings
rtk gain --history                 # Show per-command history
rtk discover                       # Analyze Claude Code history for missed opportunities

# Testing
cargo test --all-features          # All tests
cargo test --test snapshots        # Snapshot tests only
cargo test --ignored               # Integration tests (requires rtk installed)
cargo insta review                 # Review snapshot changes

# Performance profiling
hyperfine 'rtk git log -10' 'git log -10'         # Benchmark startup
/usr/bin/time -l rtk git status                   # Memory usage (macOS)
cargo flamegraph -- rtk git log -10               # Flamegraph profiling

# Cross-platform testing
cargo test --target x86_64-pc-windows-gnu         # Windows
cargo test --target x86_64-unknown-linux-gnu      # Linux
docker run --rm -v $(pwd):/rtk -w /rtk rust:latest cargo test  # Linux via Docker

其中 rtk discover 对应仓库的 src/discover/ 模块（lexer、provider、registry、report、rules），用于分析 Claude Code 历史中未被捕获的节省机会；rtk gain 则依赖 src/core/tracking.rs 的 SQLite 追踪。

反模式与正确做法清单

文档以 ❌/✅ 对照收尾，这是 RTK 代码评审的准绳：

❌ 反模式 ✅ 正确做法
引入 async（tokio/async-std），增加约 5–10ms 启动开销，破坏单线程零开销设计 保持同步单线程，守住 <10ms 启动目标
重复编译固定正则模式 固定复用模式一律 LazyLock<Regex>
过滤失败时 panic 回退到原始命令执行，用户工作流永不中断
假设命令输出格式不变 用柔性正则 + 真实 fixture 测试
跳过跨平台测试 至少覆盖 macOS + Linux（Docker），Windows 走 CI
破坏管道兼容（stdout/stderr 混流、退出码丢失） 保持 stdout/stderr 分离，尊重退出码
— 提交前跑 cargo fmt && cargo clippy --all-targets && cargo test
— 用 hyperfine 基准测试启动时间（<10ms 目标）
— 所有错误传播使用 anyhow::Result + .context()

过滤器开发工作流（8 步）

以新增 rtk newcmd 为例，文档定义的完整流程可直接复用：

1. 创建模块

touch src/cmds/<ecosystem>/newcmd_cmd.rs

// src/cmds/<ecosystem>/newcmd_cmd.rs
use anyhow::{Context, Result};
use regex::Regex;
use std::sync::LazyLock;

static PATTERN: LazyLock<Regex> =
    LazyLock::new(|| Regex::new(r"pattern").unwrap());

pub fn filter_newcmd(input: &str) -> Result<String> {
    // Implement filtering logic
    // Use PATTERN regex (compiled once)
    // Add fallback logic on error
    Ok(condensed_output)
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_token_savings() {
        let input = include_str!("../tests/fixtures/newcmd_raw.txt");
        let output = filter_newcmd(input).unwrap();

        let savings = calculate_savings(input, &output);
        assert!(savings >= 60.0, "Expected ≥60% savings, got {:.1}%", savings);
    }
}

2. 注册模块

在所属生态的 mod.rs（如 src/cmds/system/mod.rs）中声明 pub mod newcmd_cmd;，并在 src/main.rs 的 Commands 枚举与路由 match 中接入：

// Add use import
use cmds::system::newcmd_cmd;

// In Commands enum
Newcmd {
    #[arg(trailing_var_arg = true, allow_hyphen_values = true)]
    args: Vec<String>,
},

// In match statement
Commands::Newcmd { args } => {
    let output = execute_newcmd(&args)?;
    let filtered = filter_newcmd(&output).unwrap_or(output);
    print!("{}", filtered);
}

注意路由中的 filter_newcmd(&output).unwrap_or(output)——过滤失败时保留原始输出，正是回退原则在枚举路由处的微观体现。

3. 测试先行（TDD）

创建 fixture 并让测试先红：

echo "raw newcmd output" > tests/fixtures/newcmd_raw.txt

按上文模板编写测试，cargo test 应失败（red）。

4. 实现过滤器

实现 filter_newcmd()，cargo test 转绿（green）。

5. 质量检查

cargo fmt --all && cargo clippy --all-targets && cargo test --all

6. 性能基准

hyperfine 'rtk newcmd args' --warmup 3
# Should be <10ms

7. 手动验证

rtk newcmd args
# Inspect output:
# - Is it condensed?
# - Critical info preserved?
# - Readable format?

8. 更新文档

更新 CLAUDE.md 的模块职责表与 README.md 的命令支持列表；注意 CHANGELOG.md 由 release-please 自动生成（见 release-please-config.json），不得手工编辑。

性能目标与发布阻断项

文档以一张量化目标表收尾，所有性能回归都是发布阻断项，变更前后必须基准对比：

指标 目标 验证方式
启动时间 <10ms hyperfine 'rtk git status'
内存开销 <5MB /usr/bin/time -l rtk git status
Token 节省 60–90% 基于 count_tokens() 的测试
二进制体积 <5MB（stripped） ls -lh target/release/rtk

小结

rust-rtk.md 把 RTK 的工程质量约束压缩为一套可操作的 Rust 开发规范：回退优先（任何过滤失败都回到原始命令，run_fallback 是其在 src/main.rs 的工程形态）、正则只编译一次（LazyLock<Regex> 遍布 src/core/filter.rs 与各命令模块）、节省率必须可验证（count_tokens 位于 src/core/utils.rs，fixture 驱动，≥60% 否则阻断发布）、错误永不 panic（anyhow + .context() + 优雅降级）、跨平台管道语义不可破坏（stdout/stderr 分离、退出码透传）。配合 8 步过滤器开发工作流与 fmt → clippy → test → hyperfine 的质量门禁，这份 Agent 文档实质上是一份“如何为一个追求 <10ms 启动的 CLI 代理安全地新增命令过滤器”的完整工程手册。

rtk
CLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies
项目地址：https://gitcode.com/GitHub_Trending/rtk4/rtk
登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
33
18
pytorchpytorch
作为 Ascend for PyTorch 社区的核心组件，TorchNPU 是昇腾专为 PyTorch 打造的深度学习适配插件，使 PyTorch 框架能够直接调用昇腾 NPU，为开发者提供昇腾 AI 处理器的超强算力。
Python
854
1.34 K
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库，实现网络在NPU上加速计算。
C++
1.12 K
2.72 K
kernelkernel
openEuler内核是openEuler操作系统的核心，既是系统性能与稳定性的基石，也是连接处理器、设备与服务的桥梁。
C
528
588
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库，实现网络在NPU上加速计算。
C++
906
1.83 K
jiuwenswarmjiuwenswarm
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent，它能够将大语言模型的强大能力，通过你日常使用的各类通讯应用，直接延伸至你的指尖。
Python
3.53 K
1.01 K
cann-learning-hubcann-learning-hub
CANN 学习中心仓，支持在线互动运行、边学边练，提供教程、示例与优化方案，一站式助力昇腾开发者快速上手。
Jupyter Notebook
989
508
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。
C++
1.34 K
1.45 K
docsdocs
暂无描述
Markdown
892
5.79 K
openGauss-serveropenGauss-server
openGauss kernel ~ openGauss is an open source relational database management system
C++
213
313