llvm-project 构建与自定义 Pass 开发实战指南-北京尧图网络

提到llvm-project懂行的人都知道这不是一个普通仓库。它里面装的是 LLVM 核心库、Clang 编译器、LLD 链接器、libc、编译器 RT、OpenMP 运行时……几乎把现代编译工具链的半壁江山都塞进去了。很多人第一次打开这个仓库时一脸懵目录这么多到底该看哪个从哪里开始构建构建完又有什么用这篇文章就专门聊清楚这件事不绕弯子从架构逻辑讲到完整编译流程再带大家手写一个最简单的优化 pass最后把我在实际构建和二次开发中踩过的坑一并列出来。这篇文章适合三类读者看想深入了解编译器原理的初学者、需要基于 LLVM 做二次开发的工程师、以及那些只是想把llvm-project从源码完整构建一遍、却总在 CMake 阶段被劝退的同学。读完之后你至少能搞清楚两件事这个项目为什么设计成现在这个样子以及怎么从零开始顺利把它跑起来。1. 项目核心价值LLVM 到底强在哪里1.1 不只是“编译器”而是一整套可复用基础设施传统编译器通常是一个整体前端负责解析源码后端直接生成机器码中间过程被紧紧耦合在一起。LLVM 的项目哲学完全相反它把编译过程拆成三段前端负责把高级语言变成一份统一的中间表示 IR中端基于这份 IR 做各种平台无关的优化后端再把优化后的 IR 翻译成不同 CPU 架构的机器码。好处很明显如果你要发明一门新语言只需要写一个前端把代码翻译成 LLVM IR就能免费获得各种成熟的优化能力以及 x86、ARM、RISC-V、WebAssembly 等十几个后端的支持。更直白点说LLVM 就像一套乐高积木你不需要自己烧制每一块砖只需要挑需要的零件拼出想要的结构。这也是llvm-project会被这么多重量级项目采用的根本原因。Rust 编译器 rustc 的代码生成后端用的就是 LLVMApple 的 Swift 语言也构建在 LLVM 之上Julia 的 JIT 编译同样调用 LLVM C API。除此之外还有 Ruby、Haskell、D 语言、以及大量 GPU 编译器项目都在围绕这套生态做开发。1.2 从桌面软件到游戏主机LLVM 的应用场景无处不在LLVM 的应用范围并不局限于编译器开发者。数据库系统可以用它实现向量化执行引擎游戏公司用它做跨平台代码生成芯片厂商会基于 LLVM 定制自己的后端安全研究团队用它做二进制分析和插桩工具。如果你在顶级科技公司做底层基础设施研发LLVM 几乎是绕不开的技能点。国内互联网大厂的编译器团队、芯片公司的基础软件团队、以及各类数据库和分布式系统项目招聘要求里经常会出现“熟悉 LLVM 或 GCC 后端”这样的条件。即便不做编译器理解 LLVM 的核心设计理念对日常写代码时建立“中间层”和“分层抽象”的思路也有非常直接的帮助。对于普通开发者来说最常用的路径是装一个 Clang 替代 GCC 来编译项目或者通过opt和llc手动分析优化过程。很多人没有意识到每次用clang -O2编译时背后执行的其实就是一个前端分析、中端优化、后端生成代码的完整流水线。2. 核心设计思路为什么“中间表示 IR”是 LLVM 的灵魂2.1 三层架构与 IR 的枢纽地位llvm-project的架构设计可以用一个非常简单的三段式来理解前端把 C/C/Rust/Swift 等源码解析成 AST再翻译成 LLVM IR。中端优化器读入 IR做内联、常量传播、循环展开、死代码消除等优化输出新的 IR。后端接管优化后的 IR执行指令选择、寄存器分配、指令调度最终生成目标平台的汇编或机器码。这个设计最关键的工程决策是 IR 的存在。IR 不是源码也不是机器码而是一种结构化的中间语言。它的形式比较接近带类型的汇编语言但保留了变量、函数、基本块等高层信息。它把前端关心的事情和后端关心的事情彻底拆开任何新语言只要产出正确的 IR后面整条优化和代码生成链路直接复用。C 语言源码可以翻译成 IRRust 代码也可以翻译成同一套 IR这样后端完全不需要知道它处理的是 C 还是 Rust。这就是为什么 LLVM 能同时服务这么多语言项目因为所有前端共用了同一个“公共语言”。2.2 静态单赋值形式与优化友好性LLVM IR 的核心特征之一是静态单赋值形式也就是每个变量只能被赋值一次。为了表达条件分支里的变量选择IR 引入了phi指令来选择合适的入值。这么做的好处是数据流关系被直接写进变量名里每个值从哪里来一目了然后续优化算法处理起来非常顺手。举个例子考虑这样一段 C 代码int f(int x, int y) { int a x * 2; int b a y; return b; }经过前端转换后的 LLVM IR 大致是define i32 f(i32 %x, i32 %y) { %a mul i32 %x, 2 %b add i32 %a, %y ret i32 %b }每条指令都定义一个临时变量并且后续指令直接引用这些变量。如果中端优化器把%a替换成mul i32 %x, 2那么依赖关系立刻能更新不会出现传统编译器里到处搜索修改引用的麻烦。对初学者来讲理解 SSA 是学会读 IR 和写优化 pass 的门槛。你自己写的 pass 要遵守这个约束不要试图给一个 SSA 变量二次赋值而是生成新的变量。真正操作时LLVM API 会自动帮你建新变量不需要小心到什么都不敢动但理解约束可以少踩很多坑。2.3 同一份 IR 通向多个硬件平台LLVM 后端把同一份 IR 翻译成不同架构的机器码这是它另一大卖点。编译时你可以通过--target指定目标平台比如在本机用 Clang 交叉编译一个 ARM64 的可执行文件。clang --targetaarch64-linux-gnu -O2 -o hello_aarch64 hello.c这样不需要部署 ARM 机器也能提前验证语法和基础逻辑是否正常。完整链接还需要交叉编译版的系统库但单文件编译这种玩法足够表演“一份 IR到处生成代码”了。后端实现里包含指令选择、寄存器分配、指令调度等一系列复杂流程其中寄存器分配算法比如 Greedy Register Allocator是一个工程复杂度很高的模块。普通应用开发不需要深入了解但如果你想做性能分析或者定制芯片支持的设计这部分知识早晚要用到。3. 从零构建 llvm-project完整实操与避坑指北3.1 环境准备先搞清楚自己的硬件条件构建llvm-project对硬件有一定要求尤其是当你选择全量构建 Clang、LLD 等所有组件时。官方文档建议磁盘剩余空间至少 30GB实际构建 Release 版本时中间产物加安装内容很容易超过这个数字。内存方面最低 8GB16GB 以上会比较舒服。全量并行编译时内存占用会明显上升并行度太高容易把机器卡死。操作系统支持方面Linux、macOS、Windows 都能构建但不同平台踩的坑不一样。Linux 下相对顺滑macOS 需要用 Xcode Command Line Tools 里的 Clang 来编译 ClangWindows 则强烈建议用 Visual Studio 的生成器或配合 Ninja 使用。读者如果没有特殊原因建议拿一台 Linux 机器操作省掉大量的环境兼容问题。依赖工具主要需要CMake 3.20 以上、Ninja推荐或 GNU Make、Python 3、以及一个能用的 C/C 编译器。如果你打算用 Clang 编译 Clang还需要确保系统中有一个可用的 GCC 或 Clang 作为引导编译器。3.2 获取源码浅克隆与全量克隆的取舍llvm-project仓库体积非常大完整克隆需要下载相当多的历史数据。这里有两种拿法要拿到特定稳定版本推荐浅克隆加指定分支的方式git clone --depth1 --branch llvmorg-18.1.8 https://github.com/llvm/llvm-project.git cd llvm-project这样只拉取最新一份快照体积小很多。如果你打算频繁切换分支、甚至自己修改代码后提交那还是要完整克隆后续提交和切换会方便很多。其实还有一个更轻量的办法只克隆llvm单目录。但有个前提后续构建范围里面不能勾选 Clang 等项目因为 Clang 的代码独立在clang目录之外。想快速体验 IR 优化和 pass 开发只 clonellvm目录就够了。但如果你要全面接触工具链特别是想用自己构建的 Clang 编译实际项目还是把clang一起拉下来比较好。3.3 CMake 配置关键参数逐个解释进入源码根目录后强烈建议建一个独立的构建目录不要把生成文件混到源码目录里cd llvm-project mkdir build cd build接下来执行 CMake 配置。这里给出一个比较推荐的参数组合cmake -G Ninja ../llvm \ -DCMAKE_BUILD_TYPERelease \ -DLLVM_ENABLE_PROJECTSclang;lld \ -DLLVM_TARGETS_TO_BUILDhost \ -DLLVM_ENABLE_ASSERTIONSON \ -DLLVM_CCACHE_BUILDON \ -DCMAKE_INSTALL_PREFIX/opt/llvm-18几个关键参数分别解释一下CMAKE_BUILD_TYPE设为Release编译产物会应用高度优化构建速度较慢但运行时性能好。调试版本更慢通常给调试 LLVM 本身的人用。LLVM_ENABLE_PROJECTS决定额外构建哪些项目。默认只构建核心 LLVM 库和基本工具想用 Clang 就把clang加进来想有自己的链接器就加lld。多个项目之间用分号隔开。LLVM_TARGETS_TO_BUILD决定生成哪些后端的代码。默认全平台都要构建极慢。只在当前机器上做实验就设成host这样只生成宿主架构的后端代码构建时间大大缩短。LLVM_ENABLE_ASSERTIONS在构建 Release 时通常建议打开它能让 IR 验证器等运行时检查生效写 pass 时很多低级错误能立刻暴露出来。LLVM_CCACHE_BUILD很重要。如果你需要反复修改 LLVM 源码并重新编译开 ccache 能节省大量时间。首次构建会慢一点后续增量构建就是另一个故事了。CMAKE_INSTALL_PREFIX是安装路径根据自己的习惯设置避免和系统自带 LLVM 冲突。有些教程会让你上来就把LLVM_ENABLE_PROJECTS设置为clang;lld;libcxx;compiler-rt;openmp全都构建这是全量锅炖时间非常长。建议第一次构建保持克制先只加核心工具链。3.4 编译、验证与安装配置完成后进入构建环节cmake --build . -j$(nproc)这里-j后面的并行数建议不超过 CPU 物理核心数。8 核心 16GB 内存机器上构建clang加lld大概需要 30 到 60 分钟。如果看到失败信息也不要慌绝大多数是环境导致的问题后面第 5 节会专门列一个排查表。构建完成之后可以先验证一下基础工具./bin/llvm-config --version ./bin/clang --version如果输出正常说明核心构建成功。接下来可以用你亲手构建的 Clang 编译一个简单 C 程序./bin/clang -O2 -emit-llvm -c hello.c -o hello.bc ./bin/llvm-dis hello.bc -o hello.ll cat hello.ll通过clang前端生成字节码再用llvm-dis转成可读的 IR 文本这样你第一次真正看到了 C 代码长成 IR 的样子。很多人在这一步恍然大悟原来高级语言经过编译会变得这么规则化。如果需要安装到系统目录cmake --build . --target install除非确实要把自定义版本部署到环境里否则在build目录里直接使用./bin下的工具就足够了完全不需要污染系统。4. Pass 开发实战给 LLVM 加一个自定义优化4.1 选对入口新 Pass Manager 才是正确方向很多旧教程还在用opt -load ./libMyPass.so -my-pass这种写 Legacy Pass Manager 的加载方式。LLVM 14 之后新 Pass Manager 成为默认老接口已经逐渐退出历史舞台。现在动手写 pass直接奔着 New Pass Manager 去学不要浪费时间在过时接口上。这里分享一个我在开发中踩过的坑旧文章里的示例代码里会用FunctionPass、Pass等基类然后实现runOnFunction()方法。这些类进入新 Pass Manager 后统统不推荐使用了直接编译会报错或者行为异常。新写法是基于PassInfoMixin写模板结构体实现run()方法。如果你看到这类旧接口的博客CtrlW 直接关掉别犹豫。4.2 编写你的第一个模块级 Pass为了尽量简单且能直观看到效果我们写一个 Module Pass功能是把所有函数的名称打印出来顺便统计函数数量。注实际优化时需要选择不同 pass 类型比如 Function Pass、Module Pass 等但入门阶段先跑通一个再说。创建目录结构my-pass/ ├── CMakeLists.txt └── MyPass.cppCMakeLists.txt内容cmake_minimum_required(VERSION 3.20) project(MyPass) find_package(LLVM REQUIRED CONFIG) message(STATUS Found LLVM ${LLVM_PACKAGE_VERSION}) include_directories(${LLVM_INCLUDE_DIRS}) separate_arguments(LLVM_DEFINITIONS_LIST NATIVE_COMMAND ${LLVM_DEFINITIONS}) add_definitions(${LLVM_DEFINITIONS_LIST}) add_library(MyPass MODULE MyPass.cpp) if(LLVM_ENABLE_RTTI) set_target_properties(MyPass PROPERTIES COMPILE_FLAGS -fno-rtti) endif() set_target_properties(MyPass PROPERTIES PREFIX OUTPUT_NAME MyPass )注意变量里的 RTTI 处理其实是有讲究的。LLVM 默认关闭 RTTIpass 插件也要保持同一选项否则模板实例化可能会崩。如果你在编译时发现各种关于 RTTI 的报错通常就是这里没对上。MyPass.cpp内容#include llvm/IR/Function.h #include llvm/IR/Module.h #include llvm/Pass.h #include llvm/Passes/PassBuilder.h #include llvm/Passes/PassPlugin.h #include llvm/Support/raw_ostream.h using namespace llvm; namespace { struct MyModulePass : public PassInfoMixinMyModulePass { PreservedAnalyses run(Module M, ModuleAnalysisManager MAM) { unsigned FuncCount 0; for (auto F : M) { if (F.isDeclaration()) continue; errs() [MyPass] Found function: F.getName() \n; FuncCount; } errs() [MyPass] Total non-declaration functions: FuncCount \n; return PreservedAnalyses::all(); } }; } // namespace llvm::PassPluginLibraryInfo getMyPassPluginInfo() { return {LLVM_PLUGIN_API_VERSION, MyPass, 0.1, [](PassBuilder PB) { PB.registerPipelineParsingCallback( [](StringRef Name, ModulePassManager MPM, ArrayRefPassBuilder::PipelineElement) { if (Name my-pass) { MPM.addPass(MyModulePass()); return true; } return false; }); }}; } extern C LLVM_ATTRIBUTE_WEAK ::llvm::PassPluginLibraryInfo llvmGetPassPluginInfo() { return getMyPassPluginInfo(); }这段代码的意义在于它并不是一个真正优化代码的 pass而是告诉你“如何让 LLVM 认识你的 pass”这是所有进一步开发的地基。后面想改成向所有add指令加注释、去掉 printf 调用等更有实际用途的 pass也只需要改run里面的遍历逻辑。4.3 构建并加载 pass亲眼看到输出构建这个插件需要链接前面构建出的 LLVM 库。最方便的方式是使用llvm-config辅助cd my-pass LLVM_CONFIG/path/to/llvm-project/build/bin/llvm-config cmake -S . -B build -DLLVM_DIR/path/to/llvm-project/build/lib/cmake/llvm cmake --build build构建完成后会生成build/MyPass.so。这时候回到构建目录准备一个简单的测试文件cat test.c EOF int add(int a, int b) { return a b; } int main() { return add(1, 2); } EOF ./bin/clang -emit-llvm -S test.c -o test.ll生成的test.ll里有define i32 add和define i32 main两个函数然后加载插件跑一下./bin/opt -load-pass-plugin../my-pass/build/MyPass.so \ -passesmy-pass -S test.ll -o /dev/null预期输出[MyPass] Found function: add [MyPass] Found function: main [MyPass] Total non-declaration functions: 2如果你能走到这一步说明你的开发环境已经打通了。接下来可以随便改代码统计查询指令、加密函数名、为每条 printf 调用插入日志等思路全打通了。4.4 Pass 开发里最容易翻车的几个细节第一个大坑是插件和opt版本必须完全一致。我试过用 LLVM 17 构建的插件拿 LLVM 18 的 opt 去加载直接崩溃或者报未知插件。llvmGetPassPluginInfo里那串LLVM_PLUGIN_API_VERSION就是在做版本匹配但很多潜在的不兼容问题不是靠这个宏就能完全兜住的。第二个坑是符号可见性。插件必须导出llvmGetPassPluginInfo符号所以代码里用了extern C LLVM_ATTRIBUTE_WEAK。有的编译器或链接配置会把符号隐藏掉加载时明明文件存在却找不到插件信息。出现这种情况就检查编译参数必要时用-fvisibilitydefault显式导出。第三个坑是 pass 作用域搞混。Module Pass 处理整个模块Function Pass 逐函数处理如果你在 Function Pass 里试图删模块级的全局变量API 设计上就很不顺手甚至不能这么干。动手前要先想清楚“我这个优化在哪里做最合适”。再有就是如果你写的 pass 修改了 IR需要返回PreservedAnalyses::none()告诉框架某些分析失效了。返回all()等于告诉框架“我的 pass 没改任何东西”框架可以直接复用之前缓存的分析结果。如果改了 IR 还声明保持全部后续 pass 拿到的就是过期分析结果轻则优化不准确重则直接崩溃。我第一次写 DCE 时没改返回值跑出来的结果一度让我怀疑人生排查半天才发现是这个原因。5. 常见问题与高速排查手册构建llvm-project最考验人的其实是各种环境问题。这一节把我自己遇到过的以及群里高频出现的问题整理成一张速查表方便大家直接对照。症状常见原因解决方案CMake 报找不到 Ninja未安装或未加入 PATHapt install ninja-buildDebian/Ubuntu或brew install ninjamacOS编译中途内存不足被 kill并行度太高调低-j参数比如 4 或 88GB 内存建议-j2保险磁盘空间不够Release 构建产生大量中间文件清理旧 build 目录关掉不需要的项目和 target编译器版本太老LLVM 18 需要较新的 GCC 或 Clang升级系统编译器或改用 Xcode 自带的 Clang链接时报libLLVM.so相关找不到LD_LIBRARY_PATH未设置设置export LD_LIBRARY_PATH/path/to/build/lib:$LD_LIBRARY_PATH编译自己的 pass 找不到llvm/...头文件LLVM_DIR或 include 路径不对用llvm-config --includedir和--libdir检查再喂给 CMake加载插件后无任何输出插件没被识别检查符号导出用llvm-nm MyPass.so查看是否有llvmGetPassPluginInfo另外如果你在配置时执行cmake --build . -j$(nproc)发现进度条长时间不动不要立刻以为卡死。链接阶段经常要链接一个巨型的libLLVM.so单线程做链接慢是正常的。放那里喝杯咖啡再回来看通常就好了。还有一个很多新手会犯的路径错误在源码顶层目录直接执行cmake ..这样会把构建产物和源码混在一起导致后面想清理都无从下手。正确操作是新建build目录在目录里执行cmake ../llvm。这不算技术难题但能避免后面无数麻烦。6. 日常调试 IR 与优化效果的高效技巧6.1 用打印选项“看穿”优化器的一举一动opt提供了非常灵活的调试手段。想观察每个优化 pass 之后 IR 变成什么样可以加上./bin/opt -passesdefaultO2 -print-after-all -S test.ll -o /dev/null这样会把每个 pass 执行后的 IR 全部打印出来信息量爆炸适合做针对性分析。只想看某一类 pass 的前后变化可以用-print-afterpass名称精确控制。我调 pass 时会先看整体输出找到可疑的 pass再单独把所有 pass 前后对比效率比乱翻 dump 文件高很多。在实际开发中opt的输出可能非常长。建议输出到文件再用编辑器查看./bin/opt -passesdefaultO2 -print-after-all -S test.ll -o /dev/null opt_dump.txt 21然后把opt_dump.txt打开搜索关键函数名会清晰很多。6.2 快速查看源码到 IR 的对应关系如果你想看某一段 C 代码到底生成了什么样的 IR强烈建议先用clang -O0 -emit-llvm -S看看未优化的原始形态然后用opt -O2优化看变化。对比两份文件你对优化器在做的事情会建立直观感受。./bin/clang -O0 -emit-llvm -S test.c -o test_O0.ll ./bin/opt -O2 -S test_O0.ll -o test_O2.ll我在讲优化原理时经常用这招。比如-O2可能把函数内联、循环展开、常量传播全部应用代码行数暴增或骤减都可能发生。亲眼看过一次比背十篇优化文档都有用。FileCheck工具也值得一提。写 LLVM 回归测试时FileCheck可以从一个校验文件里读取预期匹配文本再和命令的实际输出做比较。它比 grep 更灵活支持占位符、重复匹配、否定断言等。我写 pass 自测时基本靠它保证输出的 IR 与预期模式一致。6.3 多版本共存如何优雅地切换 LLVM系统自带的 LLVM 可能和你源码构建的版本不一样导致llvm-config、opt等命令的优先级冲突。我个人的处理方式是把构建完的工具放在独立 prefix 下比如/opt/llvm-18然后用环境变量去切换export PATH/opt/llvm-18/bin:$PATH export LD_LIBRARY_PATH/opt/llvm-18/lib:$LD_LIBRARY_PATH这样系统自带的版本不受影响项目需要使用新版本时直接加载这一段环境变量即可。如果只是某个项目的构建需要特定版本也可以写进该项目的CMakePresets.json避免全局污染。需要注意的是llvm-config输出路径和 CMake 的LLVM_DIR要用同一份安装树的路径不能混用不同版本的库和头文件。混搭是 crash 重灾区。6.4 构建时间太长的终极解法自己编过一次 LLVM 之后很多人问的第一句话是“怎么编一次就够以后别再编了”。这里给几个亲测有效的策略优先用系统包管理器安装已发布的稳定版比如 apt 里的llvm-18只有在需要改源码时才自己构建。如果必须源码构建每次增删代码用ccache缓存编译产物增量编译效率提升非常明显。只构建你需要的 target比如-DLLVM_TARGETS_TO_BUILDhost不要贪多。按需选择需要开启的项目不要一次性clang;lld;compiler-rt;libcxx;openmp全上后面需要的模块可以再单独补。我第一次全量构建时没开 ccache 也没裁剪 target结果磁盘爆掉、内存拉满顺手把系统搞得卡到没法用。后来养成最小化构建的习惯真正常用的就是clang加lld构建时间直接砍半。7. 从使用到选修下一步还能在 llvm-project 里玩什么跑通基础构建和实践 pass 之后学习路径可以往更多方向延伸。自己能写一些 Function Pass 之后可以尝试实现简单的死代码消除或者内置函数内联逻辑。过程会逼着你研究DominatorTree、LoopInfo这些分析结果怎么获取。这些分析结果是 LLVM 的“情报系统”优化 pass 都靠它们做决策。对编程语言设计感兴趣的人可以用 LLVM 的 C API 或 Cpp 接口把自定义语言编译成 IR。这个目标推进过程中会遇到类型系统映射、作用域管理、栈帧布局等经典问题。亲自动手写过一遍解释器或编译器对高级语言特性的理解会变得异常扎实。另外llvm-project里还有MLIRMulti-Level Intermediate Representation专门用于构建更广义的编译基础设施。它解决的是从机器学习框架到芯片指令之间多层抽象转换的问题在 AI 编译器领域用得非常频繁。如果你对深度学习和编译器结合的方向感兴趣从 LLVM IR 熟悉后迁移到 MLIR 是一条比较顺的路径。性能分析方向也有得玩llvm-mca能做静态性能预测llvm-profdata和llvm-cov可以配合做覆盖率分析XRay是一个很强大的函数级追踪工具。这些都是直接从构建产物里拿到的“武器”把工具链吃透会让日常开发效率提升很多。我在实际使用中最大的体会是不要在学 LLVM 的初始阶段就陷进改源码的泥潭先把工具链用熟练把 IR 读明白等看得懂优化器输出后再考虑动源码。构建一次只是开始真正值钱的是把 IR、pass、分析结构这套知识串起来的能力。如果这篇文章能帮你顺利跨过“从源码构建到第一个 pass 运行”这个门槛目的就算达到了。

llvm-project 构建与自定义 Pass 开发实战指南

相关推荐

Proteus 8.17 安装教程：从下载、补丁、汉化到 Keil 联调全流程

SwiftUI构建Homebrew图形界面：BrewUI开发实践指南

接口测试全流程与工具实战指南

更多资讯

长途光缆维护全解析：从障碍定位到割接实战的工程管理指南

光缆应急抢修全流程实战指南：从告警到业务恢复

文华财经MACD、KDJ、RSI背离公式源码深度解析与优化实战

运营管理期末复习核心：从流程分析到EOQ模型的高效备考策略

BrewUI：给Homebrew套上友好图形界面，彻底告别命令行恐惧

Matlab License checkout failed中文路径解决方案

今日更新

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？