首页
/ agents24 Bash 防御式编程实践：从 Strict Mode 到生产级脚本的完整模式库

agents24 Bash 防御式编程实践：从 Strict Mode 到生产级脚本的完整模式库

2026-09-09 20:13:53作者：段琳惟
agents
Multi-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity
项目地址：https://gitcode.com/GitHub_Trending/agents24/agents

本篇技术指南围绕 agents24 仓库中 plugins/shell-scripting 插件的核心技能文档 bash-defensive-patterns/references/details.md 展开，系统讲解面向生产环境的 Bash 防御式编程：如何用 set -Eeuo pipefail 严格模式捕获早期错误、如何用 trap 与临时文件管理保证清理、如何用 10 个可复用模式（安全目录检测、参数解析、结构化日志、幂等设计等）写出容错与安全兼备的脚本。读完本文，你将掌握一套可直接复制进 CI/CD 流水线、系统运维脚本与部署自动化中的完整防御式 Bash 编程方法论，并了解它与 ShellCheck 静态分析、Bats 测试框架如何协同构成质量闭环。

一、核心防御原则：脚本稳健性的地基

1. Strict Mode：让脚本在错误发生时立刻失败

防御式 Bash 编程的第一原则，是在每个脚本开头启用严格模式，让错误尽早暴露而不是静默蔓延：

#!/bin/bash
set -Eeuo pipefail  # Exit on error, unset variables, pipe failures

各标志的语义如下（对应原文档 details.md 的说明，并在 bash-pro.md 中得到进一步印证）：

标志 作用 说明
set -E ERR trap 在函数中继承 确保 trap ... ERR 能捕获函数内部错误
set -e 遇到非零退出码立即退出 命令返回非零即终止脚本
set -u 引用未定义变量立即退出 拦截拼写错误与未初始化变量
set -o pipefail 管道中任一命令失败即整体失败 不再只取管道最后一个命令的退出码

需要说明的是，仓库中的 posix-shell-pro.md 明确指出：pipefail 是 Bash 特有的选项，POSIX sh 中只能使用 set -eu——这也是为什么在要求最大可移植性的场景下需要区分 Bash 严格模式与 POSIX 降级方案。另外 bash-pro.md 还补充了一个进阶技巧：在 Bash 4.4+ 中可追加 shopt -s inherit_errexit 让命令替换内的错误也能正确传播，形成更全面的错误传播机制。

2. Error Trapping：错误定位与退出清理

严格模式负责"停下来"，trap 则负责"收拾残局"：

#!/bin/bash
set -Eeuo pipefail

trap 'echo "Error on line $LINENO"' ERR
trap 'echo "Cleaning up..."; rm -rf "$TMPDIR"' EXIT

TMPDIR=$(mktemp -d)
# Script code here

这里体现了两个关键点：ERR trap 借助 $LINENO 精确报告出错行，配合 bash-pro.md 推荐的 trap 'echo "Error at line $LINENO: exit $?" >&2' ERR 还能输出退出码；而 EXIT trap 无论脚本正常结束还是异常退出都会执行，是临时资源清理的兜底保障。

3. Variable Safety：引号与必填变量校验

防御式编程中，未加引号的变量展开是词分割（word splitting）和路径通配（globbing）事故的头号来源：

# Wrong - unsafe
cp $source $dest

# Correct - safe
cp "$source" "$dest"

# Required variables - fail with message if unset
: "${REQUIRED_VAR:?REQUIRED_VAR is not set}"

: "${VAR:?message}" 是 Bash 参数展开的经典技巧：变量未设置或为空时立即以指定消息失败退出，常用于脚本必需的配置项与环境变量校验。仓库中 posix-shell-pro.md 还给出了 POSIX 等价的写法 [ -n "$VAR" ] || { echo "VAR required" >&2; exit 1; }，方便跨 shell 移植。

4. Array Handling：安全处理复杂数据

数组的正确使用能避开 "for i in $(ls)" 这类被 bash-pro.md 明确列为反模式的写法：

# Safe array iteration
declare -a items=("item 1" "item 2" "item 3")

for item in "${items[@]}"; do
    echo "Processing: $item"
done

# Reading output into array safely
mapfile -t lines < <(some_command)
readarray -t numbers < <(seq 1 10)

"${items[@]}" 的引号是关键——它确保含空格的元素不被拆分；mapfile/readarray 则把命令输出逐行读入数组，比命令替换后再靠 IFS 拆分安全得多。bash-pro 还进一步建议 readarray -d '' files < <(find . -print0) 配合 NUL 分隔符处理包含换行符的极端文件名。

5. Conditional Safety：[[ ]] 与 [ ] 的选择

条件判断的选择取决于目标 shell：

# Bash - safer
if [[ -f "$file" && -r "$file" ]]; then
    content=$(<"$file")
fi

# POSIX - portable
if [ -f "$file" ] && [ -r "$file" ]; then
    content=$(cat "$file")
fi

# Test for existence before operations
if [[ -z "${VAR:-}" ]]; then
    echo "VAR is not set or is empty"
fi

[[ ]] 是 Bash 内置关键字，支持 &&/||、模式匹配和正则（=~），且不会对变量再做词分割；而 [ ] 是 POSIX 标准 test 命令，可移植到 dash、ash、BusyBox 等环境。"${VAR:-}" 的默认值展开则让空值判断不会触发 set -u。这与 posix-shell-pro.md 中"POSIX 下只用 [ ]、用 case 取代 [[ =~ ]]"的约束完全呼应。

二、十大基础模式：可直接复用的防御式代码块

Pattern 1：安全获取脚本自身目录

路径解析是脚本中最常见也最容易出错的环节之一：

#!/bin/bash
set -Eeuo pipefail

# Correctly determine script directory
SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd -P)"
SCRIPT_NAME="$(basename -- "${BASH_SOURCE[0]}")"

echo "Script location: $SCRIPT_DIR/$SCRIPT_NAME"

使用 BASH_SOURCE[0] 而非 $0（后者在脚本被 source 时会失真），cd 到目录后用 pwd -P 解析符号链接得到真实路径，双 -- 防止以 - 开头的目录名被误当作选项。这一写法在 bash-pro.md 中被原样列为标准实践。

Pattern 2：带文档与错误处理的函数模板

函数是脚本复用的基本单元，防御式函数模板应包含输入校验、明确的错误返回与命名规范：

#!/bin/bash
set -Eeuo pipefail

# Prefix for functions: handle_*, process_*, check_*, validate_*
# Include documentation and error handling

validate_file() {
    local -r file="$1"
    local -r message="${2:-File not found: $file}"

    if [[ ! -f "$file" ]]; then
        echo "ERROR: $message" >&2
        return 1
    fi
    return 0
}

process_files() {
    local -r input_dir="$1"
    local -r output_dir="$2"

    # Validate inputs
    [[ -d "$input_dir" ]] || { echo "ERROR: input_dir not a directory" >&2; return 1; }

    # Create output directory if needed
    mkdir -p "$output_dir" || { echo "ERROR: Cannot create output_dir" >&2; return 1; }

    # Process files safely
    while IFS= read -r -d '' file; do
        echo "Processing: $file"
        # Do work
    done < <(find "$input_dir" -maxdepth 1 -type f -print0)

    return 0
}

要点有三：local -r 声明只读局部变量防止污染全局作用域（对应 bash-pro 的"所有函数变量用 local"）；echo ... >&2 把错误信息写入 stderr；find -print0 | while IFS= read -r -d '' 构成 NUL 安全迭代，任何文件名（含空格、换行）都不会被拆分——这是 bash-pro 反复强调的二进制安全文件处理范式。

Pattern 3：安全的临时文件处理

临时目录必须由 mktemp -d 生成（而非硬编码路径），并确保任何退出路径都清理：

#!/bin/bash
set -Eeuo pipefail

trap 'rm -rf -- "$TMPDIR"' EXIT

# Create temporary directory
TMPDIR=$(mktemp -d) || { echo "ERROR: Failed to create temp directory" >&2; exit 1; }

# Create temporary files in directory
TMPFILE1="$TMPDIR/temp1.txt"
TMPFILE2="$TMPDIR/temp2.txt"

# Use temporary files
touch "$TMPFILE1" "$TMPFILE2"

echo "Temp files created in: $TMPDIR"

创建失败立即显式退出并报告；EXIT trap 兜底清理，-- 防止路径以 - 开头被误解析。这与 bash-pro.md 中"trap 'rm -rf "$tmpdir"' EXIT; tmpdir=$(mktemp -d)"的安全临时目录配方一致。

Pattern 4：健壮的命令行参数解析

手写 while + case 的解析循环是 Bash 脚本的常见需求，模式化实现如下：

#!/bin/bash
set -Eeuo pipefail

# Default values
VERBOSE=false
DRY_RUN=false
OUTPUT_FILE=""
THREADS=4

usage() {
    cat <<EOF
Usage: $0 [OPTIONS]

Options:
    -v, --verbose       Enable verbose output
    -d, --dry-run       Run without making changes
    -o, --output FILE   Output file path
    -j, --jobs NUM      Number of parallel jobs
    -h, --help          Show this help message
EOF
    exit "${1:-0}"
}

# Parse arguments
while [[ $# -gt 0 ]]; do
    case "$1" in
        -v|--verbose)
            VERBOSE=true
            shift
            ;;
        -d|--dry-run)
            DRY_RUN=true
            shift
            ;;
        -o|--output)
            OUTPUT_FILE="$2"
            shift 2
            ;;
        -j|--jobs)
            THREADS="$2"
            shift 2
            ;;
        -h|--help)
            usage 0
            ;;
        --)
            shift
            break
            ;;
        *)
            echo "ERROR: Unknown option: $1" >&2
            usage 1
            ;;
    esac
done

# Validate required arguments
[[ -n "$OUTPUT_FILE" ]] || { echo "ERROR: -o/--output is required" >&2; usage 1; }

该模式的要点：先声明默认值再覆盖；带参选项用 shift 2；-- 显式终止选项解析（对应 bash-pro 的"用 -- 结束选项解析"）；未知选项报错并返回非零退出码；最后校验必填参数。bash-pro 还建议在 help 中注明退出码约定（0 成功、1 一般错误、特定码对应特定失败），让脚本行为可预期。

Pattern 5：带时间戳与级别的结构化日志

统一日志函数让脚本可观测、可排查：

#!/bin/bash
set -Eeuo pipefail

# Logging functions
log_info() {
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] INFO: $*" >&2
}

log_warn() {
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] WARN: $*" >&2
}

log_error() {
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] ERROR: $*" >&2
}

log_debug() {
    if [[ "${DEBUG:-0}" == "1" ]]; then
        echo "[$(date +'%Y-%m-%d %H:%M:%S')] DEBUG: $*" >&2
    fi
}

# Usage
log_info "Starting script"
log_debug "Debug information"
log_warn "Warning message"
log_error "Error occurred"

所有日志写往 stderr 而不是 stdout，避免污染脚本的数据输出（这正是管道数据输出场景的关键约定）；log_debug 通过 DEBUG 环境变量控制冗长级别。bash-pro 在此基础上建议更深的可观测性：JSON 结构化输出以对接日志聚合系统、logger -t "$SCRIPT_NAME" -p user.info "$*" 写入 syslog、为多脚本工作流添加 trace ID 做分布式关联。

Pattern 6：带信号处理的进程编排

管理后台进程需要记录 PID 并优雅停机：

#!/bin/bash
set -Eeuo pipefail

# Track background processes
PIDS=()

cleanup() {
    log_info "Shutting down..."

    # Terminate all background processes
    for pid in "${PIDS[@]}"; do
        if kill -0 "$pid" 2>/dev/null; then
            kill -TERM "$pid" 2>/dev/null || true
        fi
    done

    # Wait for graceful shutdown
    for pid in "${PIDS[@]}"; do
        wait "$pid" 2>/dev/null || true
    done
}

trap cleanup SIGTERM SIGINT

# Start background tasks
background_task &
PIDS+=($!)

another_task &
PIDS+=($!)

# Wait for all background processes
wait

kill -0 先探测进程是否存在，|| true 容忍已被杀死的 PID，trap cleanup SIGTERM SIGINT 让 Ctrl-C 和终止信号都能触发有序清理。bash-pro 补充了进阶手段：Bash 4.3+ 的 wait -n 可等待任意一个后台任务完成，xargs -P $(nproc) 则适合无状态的并行批处理。

Pattern 7：安全的文件操作

覆盖移动、清理与原子写入三类高频操作：

#!/bin/bash
set -Eeuo pipefail

# Use -i flag to move safely without overwriting
safe_move() {
    local -r source="$1"
    local -r dest="$2"

    if [[ ! -e "$source" ]]; then
        echo "ERROR: Source does not exist: $source" >&2
        return 1
    fi

    if [[ -e "$dest" ]]; then
        echo "ERROR: Destination already exists: $dest" >&2
        return 1
    fi

    mv "$source" "$dest"
}

# Safe directory cleanup
safe_rmdir() {
    local -r dir="$1"

    if [[ ! -d "$dir" ]]; then
        echo "ERROR: Not a directory: $dir" >&2
        return 1
    fi

    # Use -I flag to prompt before rm (BSD/GNU compatible)
    rm -rI -- "$dir"
}

# Atomic file writes
atomic_write() {
    local -r target="$1"
    local -r tmpfile
    tmpfile=$(mktemp) || return 1

    # Write to temp file first
    cat > "$tmpfile"

    # Atomic rename
    mv "$tmpfile" "$target"
}

safe_move 前置检查源存在性与目标冲突；safe_rmdir 用 rm -rI 的交互式确认兼顾 BSD/GNU 兼容；atomic_write 先写临时文件再 mv 原子改名，避免读者看到半写入状态。bash-pro 强调的安全细节还包括：rm -rf -- "$user_input" 的 -- 分隔、敏感操作前 (umask 077; touch "$secure_file") 收紧权限、绝不对外部输入使用 eval。

Pattern 8：幂等脚本设计

脚本应当可安全重复执行，这是自动化与 cron 场景的硬性要求：

#!/bin/bash
set -Eeuo pipefail

# Check if resource already exists
ensure_directory() {
    local -r dir="$1"

    if [[ -d "$dir" ]]; then
        log_info "Directory already exists: $dir"
        return 0
    fi

    mkdir -p "$dir" || {
        log_error "Failed to create directory: $dir"
        return 1
    }

    log_info "Created directory: $dir"
}

# Ensure configuration state
ensure_config() {
    local -r config_file="$1"
    local -r default_value="$2"

    if [[ ! -f "$config_file" ]]; then
        echo "$default_value" > "$config_file"
        log_info "Created config: $config_file"
    fi
}

# Rerunning script multiple times should be safe
ensure_directory "/var/cache/myapp"
ensure_config "/etc/myapp/config" "DEBUG=false"

"先检查再创建、已存在则跳过"的 ensure_* 命名约定让脚本任意次执行结果一致。这一设计理念与 bash-pro.md 的"Design scripts to be idempotent and support dry-run modes"相互印证。

Pattern 9：安全的命令替换

现代 Bash 中应全面弃用反引号：

#!/bin/bash
set -Eeuo pipefail

# Use $() instead of backticks
name=$(<"$file")  # Modern, safe variable assignment from file
output=$(command -v python3)  # Get command location safely

# Handle command substitution with error checking
result=$(command -v node) || {
    log_error "node command not found"
    return 1
}

# For multiple lines
mapfile -t lines < <(grep "pattern" "$file")

# NUL-safe iteration
while IFS= read -r -d '' file; do
    echo "Processing: $file"
done < <(find /path -type f -print0)

$() 可嵌套、可读性更高；$(<"$file") 是从文件读入变量的高效内建写法；命令替换配合 || 可以做失败检测。bash-pro 与 posix-shell-pro 两份 agent 文档都明确指出：用 command -v 而非 which 检测命令是否存在（更可移植），且外部命令都应在头部注释中记录最低版本要求。

Pattern 10：Dry-Run 支持

预览模式让高风险操作（删除、覆盖、权限变更）先"彩排"再执行：

#!/bin/bash
set -Eeuo pipefail

DRY_RUN="${DRY_RUN:-false}"

run_cmd() {
    if [[ "$DRY_RUN" == "true" ]]; then
        echo "[DRY RUN] Would execute: $*"
        return 0
    fi

    "$@"
}

# Usage
run_cmd cp "$source" "$dest"
run_cmd rm "$file"
run_cmd chown "$owner" "$target"

run_cmd 封装统一入口，所有危险命令经由它执行，dry-run 时仅打印而不真正执行。这与 Pattern 4 中的 -d/--dry-run 参数可以无缝衔接，也是 bash-pro 质量清单中"支持 dry-run 模式"的具体落地。

三、进阶防御技巧

Named Parameters Pattern：命名参数风格的函数接口

长参数列表的函数可用 --key=value 风格提高可读性与自文档性：

#!/bin/bash
set -Eeuo pipefail

process_data() {
    local input_file=""
    local output_dir=""
    local format="json"

    # Parse named parameters
    while [[ $# -gt 0 ]]; do
        case "$1" in
            --input=*)
                input_file="${1#*=}"
                ;;
            --output=*)
                output_dir="${1#*=}"
                ;;
            --format=*)
                format="${1#*=}"
                ;;
            *)
                echo "ERROR: Unknown parameter: $1" >&2
                return 1
                ;;
        esac
        shift
    done

    # Validate required parameters
    [[ -n "$input_file" ]] || { echo "ERROR: --input is required" >&2; return 1; }
    [[ -n "$output_dir" ]] || { echo "ERROR: --output is required" >&2; return 1; }
}

${1#*=} 的参数展开负责剥离 --input= 前缀，未知参数报错返回非零，必填参数最后统一校验。bash-pro 建议在函数头部注释中记录参数与返回值语义，让命名参数模式更可维护。

Dependency Checking：启动前依赖预检

脚本运行前应一次性验证所有外部命令可用：

#!/bin/bash
set -Eeuo pipefail

check_dependencies() {
    local -a missing_deps=()
    local -a required=("jq" "curl" "git")

    for cmd in "${required[@]}"; do
        if ! command -v "$cmd" &>/dev/null; then
            missing_deps+=("$cmd")
        fi
    done

    if [[ ${#missing_deps[@]} -gt 0 ]]; then
        echo "ERROR: Missing required commands: ${missing_deps[*]}" >&2
        return 1
    fi
}

check_dependencies

command -v 在 Bash 与 POSIX 下均可移植，一次性汇总全部缺失依赖而不是逐个报错。bash-pro 进一步建议：对超时敏感的外部命令套 timeout 30s curl ... 防挂起；posix-shell-pro 则给出嵌入式环境下的回退实现思路——如 command -v mktemp >/dev/null 2>&1 || mktemp() { ... }，为缺失工具提供内置兜底。

四、与仓库工具的协同：从"写对"到"验证对"

防御式编程不止于代码本身。agents24 仓库的 shell-scripting 插件围绕 bash-defensive-patterns 还配套了两个关键技能，构成"编写 → 静态检查 → 自动化测试"的质量闭环：

静态分析（shellcheck-configuration）：ShellCheck 能自动识别本文档涉及的绝大多数陷阱——SC2086（未加引号的变量展开）、SC2181（应直接 if some_command 而非检查 $?）、SC2015（避免 &&/|| 代替 if-then-else）、SC2009（用 pgrep 取代 ps | grep）等。项目级配置写入 .shellcheckrc（指定 shell=bash、enable=avoid-nullary-conditions,require-variable-braces、按需 disable=SC1091），CI 中用 --format=gcc 或 --format=json 输出便于机器解析。

自动化测试（bats-testing-patterns）：Bats（Bash Automated Testing System）提供 TAP 兼容的测试语法，能对防御模式中的错误路径逐条验证——例如"函数在文件缺失时返回非零且输出含 not found"、"参数解析错误时输出 Usage 且状态非零"、"权限不足场景下正确失败"。配套的 setup/teardown 钩子、fixture 与 stub 机制（如临时目录中伪造 curl 可执行文件）让测试可隔离、可重复。

仓库中 bash-pro.md 给出的参考工作流是一个很好的落地示例：

shellcheck *.sh && shfmt -d *.sh && bats test/

即静态分析、格式检查、测试三关全过后才允许合并。此外还可以用 checkbashisms 检测脚本中意外引入的 Bash 专属语法（对应 POSIX 移植场景），用 pre-commit 钩子在提交前完成本地校验。

五、最佳实践清单与常见陷阱

结合 SKILL.md 的最佳实践摘要与 bash-pro.md 的注意事项，可沉淀为以下检查清单：

  1. 始终启用严格模式 —— set -Eeuo pipefail（POSIX 下退化为 set -eu）
  2. 所有变量加引号 —— "$variable" 防止词分割与通配展开
  3. 条件判断用 [[ ]] —— Bash 场景下比 [ ] 更健壮；POSIX 场景退回 [ ]
  4. 实现错误陷阱 —— ERR trap 报行号、EXIT trap 做清理
  5. 校验一切输入 —— 文件存在性、可读性、格式、必填参数
  6. 函数化复用 —— 用 validate_*/check_*/handle_* 前缀命名，local 声明局部变量
  7. 结构化日志 —— 时间戳 + 级别，写 stderr，用 DEBUG 环境变量控制冗长度
  8. 支持 dry-run —— 让高风险操作可预览
  9. 安全处理临时资源 —— mktemp -d + EXIT trap 清理
  10. 设计幂等 —— 脚本可安全重复执行
  11. 文档化依赖 —— 列出所需命令与最低版本
  12. 测试错误路径 —— 用 Bats 覆盖成功与失败双向
  13. 用 command -v —— 比 which 更安全可移植
  14. 优先 printf —— 跨系统行为比 echo 更可预测

必须避开的常见陷阱（同时见于 bash-pro.md 与 ShellCheck 常见告警）：for f in $(ls ...) 导致的词分割/通配 bug（改用 find -print0 | while IFS= read -r -d ''）；未加引号的变量展开；复杂流程中依赖 set -e 却不配错误 trap；用 echo 输出数据；缺少临时文件清理 trap；用命令替换而非 readarray/mapfile 填充数组；忽略 NUL 分隔符的二进制安全文件处理。

结语

防御式 Bash 编程的本质，是把"脚本能跑"升级为"脚本在任何失败路径下都行为可预期"。本文继承并展开了 bash-defensive-patterns 技能文档中的 5 项核心原则、10 个基础模式与 2 组进阶技巧，并补充了来自仓库 bash-pro.md、posix-shell-pro.md 及配套 shellcheck-configuration、bats-testing-patterns 技能的实现细节与工具链协同方法。将这些模式投入 CI/CD 流水线、系统运维脚本与部署自动化中，配合 ShellCheck 静态分析和 Bats 自动化测试，即可构建出真正生产级、可移植、可维护的 Bash 脚本体系。

agents
Multi-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity
项目地址：https://gitcode.com/GitHub_Trending/agents24/agents
登录后查看全文

相关内容推荐

1 agents 插件仓库 mTLS 配置技能实战：Istio、Linkerd 与 SPIFFE 模板及运维命令全解2 Kubernetes 安全策略实战指南：基于 k8s-security-policies 技能实现 NetworkPolicy、Pod 安全标准与 RBAC 纵深防御3 ShellCheck 配置与静态分析实战：在 agents 插件市场中构建 Shell 脚本质量治理体系4 Service Mesh Expert Agent：在 Claude Code / Codex 等多框架下落地 Istio 与 Linkerd 服务网格架构5 agents24 项目 bash-pro 专家指南：生产级防御式 Bash 脚本的完整工程实践6 mTLS 配置实战指南：基于 agents 插件库实现服务网格零信任通信7 AGENTS.md 治理范式：一个 Markdown 事实源如何支撑 94 插件 202 子代理的多 Harness 分发生态8 ShellCheck 配置与静态分析实战：从 .shellcheckrc 到 CI/CD 质量门禁的完整指南9 agents24 TypeScript Pro Agent 深度解析：企业级类型系统、严格编译与工程化实践指南10 为 claude-agents 多 Harness Agentic 插件市场贡献指南：从新增插件到跨 Harness 可移植性
热门项目推荐
相关项目推荐

热门内容推荐

1 编程实践项目探索指南：从零构建技术能力体系2 技术解构式学习：从0到1构建你的编程知识体系3 构建自己的技术世界：build-your-own-x项目的实践探索指南4 解锁编程技能的实践之旅：从零构建你的技术世界5 技术实践探索：从零开始构建核心系统的实践指南6 亲手锻造技术引擎：从0到1构建核心系统的实践指南

最新内容推荐

Deep Agents 数据库 Schema 探索技能（schema-exploration）实战指南：从建表清单到外键关系映射使用 Fabric `write_pull-request` Pattern：从 git diff 一键生成专业 PR 描述SGLang 生产事故排查指南：从 Replay、Trace、Profile 到 Bisect 的可复现调试全流程Data-Science-For-Beginners 用 pd.read_csv 读取 CSV 报错怎么排查？如何用困惑度（Perplexity）指标在 Transformers 中评估语言模型？Sketch ManifestClaude Code 如何用 /plan 规划模式先出实施计划再执行？claude-howto 的激活方式与计划修改comprehensive-rust 控制流基础（Control Flow Basics）全解：从块表达式到 Collatz 练习oh-my-codex 0.18.13 发布就绪全解析：项目级会话发现、Setup/Hook 加固与兼容性保持补丁的验证流程iced 颜色调色板生成器实战：基于根颜色驱动的多颜色空间交互与 Canvas 渲染

项目优选

收起
kernelkernel
deepin linux kernel
C
33
18
docsdocs
暂无描述
Markdown
899
5.83 K
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库，实现网络在NPU上加速计算。
C++
1.14 K
2.76 K
pytorchpytorch
作为 Ascend for PyTorch 社区的核心组件，TorchNPU 是昇腾专为 PyTorch 打造的深度学习适配插件，使 PyTorch 框架能够直接调用昇腾 NPU，为开发者提供昇腾 AI 处理器的超强算力。
Python
860
1.35 K
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库，实现网络在NPU上加速计算。
C++
925
1.85 K
jiuwenswarmjiuwenswarm
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent，它能够将大语言模型的强大能力，通过你日常使用的各类通讯应用，直接延伸至你的指尖。
Python
3.84 K
1.02 K
kernelkernel
openEuler内核是openEuler操作系统的核心，既是系统性能与稳定性的基石，也是连接处理器、设备与服务的桥梁。
C
533
601
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。
C++
1.37 K
1.46 K
AscendNPU-IRAscendNPU-IR
AscendNPU-IR是基于MLIR（Multi-Level Intermediate Representation）构建的，面向昇腾亲和算子编译时使用的中间表示，提供昇腾完备表达能力，通过编译优化提升昇腾AI处理器计算效率，支持通过生态框架使能昇腾AI处理器与深度调优
C++
548
395
cann-learning-hubcann-learning-hub
CANN 学习中心仓，支持在线互动运行、边学边练，提供教程、示例与优化方案，一站式助力昇腾开发者快速上手。
Jupyter Notebook
1.04 K
525