企业官网建设流程全解析

我最近在 Jetson Orin Nano 上折腾 Coding Agent，头两天差点把桌子掀了：让它在边缘 AI 环境里写一个摄像头实时检测脚本，它给出的代码从语法到逻辑都没问题，可一跑就报错——不是libnvinfer.so.8找不到，就是 CSI 摄像头打不开，更离谱的是它默认我在一台装满 CUDA 的 x86 服务器上，还会写一个wget命令去下根本下不动的模型权重。重复几轮之后我突然意识到：问题不在模型，而在于我从来没把 Jetson 这套“边缘环境的事实”喂给 Agent。

后来我用 NVIDIA 官方 SDK 和样例整理了一套“Skills”，再配合 Seeed 的硬件工具做验证闭环，Agent 写的东西终于从“看起来对”变成“真能跑”。整个过程挺有意思，也踩了不少坑。这篇就聊聊怎么让 Coding Agent 在 Jetson 上把代码写稳、跑稳，适合正在用 Jetson 做视觉、传感器项目，又想用 AI 编程助手提效的朋友。

1. 先看问题：Coding Agent 在 Jetson 上“胡说”的三个根因

1.1 “胡说”的本质：Agent 在补齐你环境之外的默认假设

先说一个我自己的判断：绝大多数 Coding Agent 生成的代码本身并没有语法问题，问题出在它对运行环境的假设上。语言模型在训练阶段看过海量代码样本，这些样本绝大多数运行在什么环境？x86_64 架构的 Linux 服务器、完整的 CUDA Toolkit、有 root 权限、内存随便造、模型权重想下载就下载。模型从中总结出来的“最常见代码模式”，天然带有服务器烙印。

Jetson 偏偏是另一个物种。它跑的是 ARM64 架构，系统是 NVIDIA 基于 Ubuntu 深度定制的 JetPack/L4T，CUDA、TensorRT、OpenCV 都是 NVIDIA 魔改过的版本，显存和内存共用，功耗模式还会直接影响推理速度。如果你在对话里不给 Agent 任何环境信息，它会按照最熟悉的服务器惯例来写代码，于是就有了我开头遇到的那一串报错。

这里有个很形象的类比：让一个习惯了城市公交的司机去山村开车，他当然懂油门和刹车，但他不知道山路坡度有多夸张，也不知道哪里需要提前鸣笛。Coding Agent 也是一样，它懂 Python、懂 PyTorch，但它不知道cv2.VideoCapture(0)在 Jetson 上很可能打不开 CSI 摄像头，不知道 Jetson 上pip install torch可能装回一个 x86 的包导致直接 crash。

所以“胡说”的根因不是模型能力不行，而是上下文里缺少“边缘环境事实”。想让它不说胡话，第一步就是把设备真实情况摆到它面前。

1.2 Jetson 平台的三类“反常识”差异

Jetson 在开发体验上和普通服务器差距很大，我归纳成三类，方便你在给 Agent 写约束时心里有数。

第一是硬件资源差异。Jetson 系列从入门到旗舰跨度很大，但和显卡服务器不是一个量级：

同样的模型，在不同型号上的内存余量、推理速度、能跑的分辨率都不一样。Agent 不知道你手上是哪块板子，就可能写出申请 4GB 显存的代码，在 Orin Nano 上直接 OOM。

第二是软件栈差异。JetPack 不同版本带的 CUDA、TensorRT、Python 版本都不同。比如 JetPack 5.x 常见对应 CUDA 11.x 和 TensorRT 8.x，JetPack 6.x 则升级到 CUDA 12.x。这些版本差一点，C++ 编译参数、Python API 都可能对不上。Agent 在服务器上写的import tensorrt as trt在 Jetson 上可能没问题，但直接用网上搜到的 trtexec 命令就可能会因为--workspace参数在新版里被废弃而报错。

第三是运行模式强相关。Jetson 的功耗模式（nvpmodel）对性能影响极大，同样的设备在 7W 和 15W 模式下推理帧率能差一倍。CPU 频率、GPU 频率、内存频率都由电源管理模式控制。Agent 看不到这些状态，它只会优化算法逻辑，不会意识到你的板子正在高温降频。

给 Agent 下指令前，至少让它跑一个环境探测脚本，把架构、JetPack 版本、TensorRT 版本、内存状态、摄像设备节点都看一遍，这是治本的第一步。

1.3 为什么这个问题值得花力气解决

有朋友可能会说：与其在 Jetson 上折腾，不如把计算放云端服务器，让 Agent 在服务器上写代码不香吗？

这就要回到边缘 AI 的本质。很多时候模型不能放云端，不是技术问题，而是场景不允许：数据敏感、网络不稳定、延迟要求高、带宽成本贵。边缘智能的价值恰恰在于把 AI 推理放到设备端本地完成，摄像头画面不用上传到云端，在设备上直接检测、直接决策、直接响应。果园里的虫害识别、产线上的小件质检、移动机器人避障，都属于这类场景。

Jetson 是这些场景里最常用的计算平台之一，Coding Agent 如果能在 Jetson 上写好代码，开发和迭代效率会提升一大截。所以别嫌麻烦，把环境约束这件事做好，后面每一次让 Agent 干活都会快很多。我的做法是整理一套可复用的“技能包”，让 Agent 每次写代码前先读设备信息、先看官方样例、先跑验证脚本。下面就从 NVIDIA Skills 怎么落地开始说。

2. NVIDIA Skills 实操：把 Jetson 的环境约束写进 Agent 的上下文

2.1 我理解的“NVIDIA Skills”到底是什么

先说清楚，我这里说的“NVIDIA Skills”不是官网某个单一软件包的名字，而是我在实践中沉淀的一套组合：NVIDIA 为 Jetson 提供的 JetPack SDK、TensorRT、DeepStream、官方样例代码，再加上你自己整理的工程脚本。

为什么要把这些东西叫“技能”？因为 Coding Agent 要写出能在 Jetson 上跑的代码，光靠脑子里那点通用知识不够，它需要可参考的“标准答案”。NVIDIA 官方包和样例就是最权威的标准答案。比如/usr/src/tensorrt/samples下的 C++ 示例、/opt/nvidia下的 VPI 和 CUDA 示例、DeepStream 的 Python apps，这些代码的 API 用法是你让 Agent 照猫画虎的最好素材。

我的做法是：在项目里建一个skills/目录，把设备信息脚本、TensorRT 转换脚本、摄像头测试脚本、官方样例的路径说明全部放进去，再写一个AGENTS.md文件告诉 Agent：先看这些技能，再动手写代码。这样 Agent 每次开工前，能拿到准确的 API 用法和环境事实，减掉瞎猜的概率。

2.2 给 Agent 建一个“设备档案”脚本

设备档案是整个技能包的地基。我写了一个skills/device/01_device_info.sh，里面收集了 Agent 写代码前最需要知道的几类信息：

#!/bin/bash # 01_device_info.sh - Jetson 设备信息收集 echo "=== Architecture ===" uname -m echo "=== JetPack / L4T ===" cat /etc/nv_tegra_release 2>/dev/null || true dpkg -l | grep -E "nvidia-l4t-core|nvidia-jetpack" | head -5 || true echo "=== CUDA & TensorRT ===" nvcc --version 2>/dev/null | grep release || echo "no nvcc" python3 -c "import tensorrt as trt; print('TensorRT', trt.__version__)" 2>/dev/null || echo "no tensorrt" echo "=== Memory & Power Mode ===" free -h sudo nvpmodel -q 2>/dev/null || true echo "=== Camera Devices ===" ls -l /dev/video* 2>/dev/null || echo "no /dev/video*" echo "=== Python ===" python3 --version which python3

这个脚本的作用，就是让 Agent 不再“凭空想象环境”。它在服务器上写代码时从不需要关心uname -m，但在 Jetson 上，这一行能帮它避开 90% 的架构坑。

然后在项目根目录写一个AGENTS.md，这是我现在觉得最有效的方式。像 Codex CLI、Claude Code 这类 Coding Agent 都会自动读取项目里的说明文件。你可以写上项目的地基规则：

# 项目环境规则 - 平台：Jetson Orin Nano 8GB，ARM64 - 系统：JetPack 6.0（具体以 skills/device/01_device_info.sh 输出为准） - Python 依赖全部装在 ~/venv 虚拟环境，不要安装系统级包 - 推理优先使用 TensorRT engine，其次是 ONNX Runtime，不要直接跑 PyTorch - 摄像头使用 GStreamer CSI pipeline，不能直接 cv2.VideoCapture(0) - 每次代码改动后运行 bash skills/test.sh 验证

实测下来，这个文件的价值非常大。项目一多，你不可能每次开新对话都把环境约束重新打一遍，把规则写进文件，Agent 自己会去读。这是把一次性调教变成可复用资产的关键。

2.3 关键一步：让 Agent 写 TensorRT 转换和推理，而不是直接跑 PyTorch

在 Jetson 上跑模型，PyTorch 直接推理不是不行，而是很浪费。边缘设备内存带宽有限，PyTorch 的动态图和算子开销又大，很容易把内存吃满、帧率拉低。TensorRT 能把模型做层融合、精度校准、用 FP16 推理，同样的模型在 Orin Nano 上跑 YOLOv8n，我实测 PyTorch 大概十几帧，TensorRT FP16 能到三十帧以上，差距非常明显。

所以我会让 Agent 不要去写“加载 PyTorch 权重再 forward”的代码，而是走一条标准流水线：PyTorch/ONNX 导出，然后用trtexec转成 engine，最后在 Python 里用 TensorRT Python API 加载推理。

导出 ONNX 可以用 PyTorch 的标准方法：

import torch model = torch.load("yolov8n.pt", map_location="cpu") # 示例 dummy = torch.randn(1, 3, 640, 640) torch.onnx.export(model, dummy, "yolov8n.onnx", opset_version=17, input_names=["input"], output_names=["output"])

然后在 Jetson 上转 TensorRT engine，命令大概是这样的：

/usr/src/tensorrt/bin/trtexec \ --onnx=yolov8n.onnx \ --saveEngine=yolov8n.engine \ --fp16 \ --memPoolSize=workspace:1024MiB

这里有个实际踩过的坑：JetPack 5.x 的 trtexec 用的是--workspace=1024这种写法，JetPack 6.x 改成了--memPoolSize=workspace:1024MiB。如果 Agent 不知道你的 JetPack 版本，它会照着网上搜来的旧命令跑，然后报参数错误。解决办法很简单，在提示词里让它先执行trtexec --help，或者直接把这个坑写进 AGENTS.md。

我把转换命令封装成一个skills/tensorrt/build_engine.sh：

#!/bin/bash # build_engine.sh <onnx_path> <engine_path> <batch_size> ONNX=$1; ENGINE=$2; BATCH=${3:-1} trtexec --onnx=$ONNX \ --saveEngine=$ENGINE \ --fp16 \ --shapes=input:${BATCH}x3x640x640 \ --memPoolSize=workspace:1024MiB

这样 Agent 只需要调用脚本，不用每次都纠结参数。脚本跑通了，后面所有推理代码都跟着稳。

3. Seeed 工具怎么接：让边缘 AI 真正拿到摄像头和传感器数据

3.1 Seeed 在 Jetson 生态里扮演什么角色

NVIDIA 的 JetPack 解决了“脑子”的问题，但一个完整的边缘 AI 项目还需要眼睛和手：摄像头采集画面、传感器感知环境、GPIO 控制执行器。Seeed 的工具在这里正好补位。

Seeed Studio 做了很多 Jetson 相关的硬件，最有代表性的是 reComputer 系列载板，比如 J2012（配 Orin Nano）和 J3010（配 Orin NX）。它把原本裸露的 Jetson 核心板做成带外壳、带散热、带丰富接口的整机，M.2 插槽、PoE 供电、RS485/RS232 工业接口、多路 USB 都提前引好了。临时做项目或者部署到现场，不用再自己焊载板、调电源。

外设方面我常用的是 CSI 摄像头和 Grove 转接板。CSI 摄像头直接走 Jetson 的摄像头接口，带宽稳定、延迟低，比 USB 摄像头更适合实时视觉。Grove 系列传感器（温湿度、PIR 人体感应、光照、红外测距）通过一个 Grove HAT 接到 Jetson 的 I2C/GPIO 上，Python 里直接读写，非常适合让 Agent 做感知和控制的组合逻辑。

选 Seeed 的原因其实很朴素：官方配套资料全，引脚定义清楚，和 Jetson 的兼容性问题少。Coding Agent 写代码时最怕“硬件行为不确定”，硬件越标准，它生成的代码越容易一次跑通。

3.2 一个典型场景：PIR 触发拍照检测

我把一个实际项目简化成例子，你看下 Agent 怎么配合 Seeed 外设把功能串起来。场景是：Grove PIR 人体感应传感器检测到有人进入范围，触发 CSI 摄像头拍一帧，再用 TensorRT engine 做目标检测，结果写入日志。

先给 Agent 看摄像头测试命令：

gst-launch-1.0 nvarguscamerasrc ! "video/x-raw(memory:NVMM),width=1280,height=720" ! nvvidconv ! autovideosink

再给它看 GPIO 读取的 Python 片段：

import Jetson.GPIO as GPIO GPIO.setmode(GPIO.BOARD) pir_pin = 11 GPIO.setup(pir_pin, GPIO.IN) if GPIO.input(pir_pin): print("motion detected")

然后是合体逻辑。Agent 在知道这些基础能力后，写出来的代码大致是：

import cv2 import time import Jetson.GPIO as GPIO GPIO.setmode(GPIO.BOARD) pir_pin = 11 GPIO.setup(pir_pin, GPIO.IN) # GStreamer CSI pipeline，这里不要省略参数 cap = cv2.VideoCapture( "nvarguscamerasrc ! video/x-raw(memory:NVMM)," "width=(int)1280,height=(int)720 ! " "nvvidconv ! video/x-raw,format=BGRx ! " "videoconvert ! video/x-raw,format=BGR ! appsink", cv2.CAP_GSTREAMER ) def run_detection(frame): # 调用 skills/tensorrt/build_engine.sh 生成的 engine 推理 pass while True: if GPIO.input(pir_pin): ret, frame = cap.read() if ret: detections = run_detection(frame) print("detections:", detections) time.sleep(1)

这段代码本身不复杂，但关键点全是 Jetson 特有的：CSI 摄像头必须用 GStreamer pipeline、GPIO 引脚要用 BOARD 模式、检测必须走 TensorRT。没有前面那些技能包和示例，Agent 大概率会写成cv2.VideoCapture(0)，然后摄像头一直黑屏。

我踩过的坑是，让 Agent 一上来就同时处理摄像头、GPIO 和推理，结果出问题时完全分不清是哪一环。现在我的铁律是：先把摄像头单测跑通，再把 GPIO 单测跑通，最后才组合。这招对 Agent 尤其重要，它不像人有全局直觉，只能按你给定的验证顺序走。

3.3 供电、散热、网络这些硬件坑，Agent 不会替你解决

边缘 AI 项目跑不稳，很多时候不是代码问题，而是硬件环境。这些坑 Agent 完全看不见，得人来提前排掉。

我整理了一个速查表，都是实际遇到过的情况：

尤其是供电和散热。Jetson 满负荷推理时电流很高，电源不够会直接重启，你甚至会怀疑是 Agent 写崩了系统，实际上是硬件供电掉链子。散热更隐蔽，夏天室温一高，GPU 降频后 FPS 掉一半，Agent 再去优化代码也拉不回来。所以我会先固定硬件基线：电源用足、散热用上、网络走有线，再让 Agent 做优化，不然它在一个不稳定的环境里反复试错，结果全是噪声。

4. 端到端跑通：一次目标检测任务的完整调教记录

4.1 环境准备：JetPack、SSH、远程访问

工欲善其事，必先利其器。Jetson 开发我一般先走这套流程：

系统镜像用 NVIDIA SDK Manager 刷机，选择对应设备的 JetPack 版本。如果你拿到的是别人刷好的板子，先确认版本：cat /etc/nv_tegra_release，避免后面装包时和系统自带的 CUDA/TensorRT 版本冲突。

网络我强烈建议用有线。Wi-Fi 在 Jetson 上不是不能用，而是环境复杂，信道干扰、驱动版本、省电策略都会造成连接不稳。Agent 干活时如果 SSH 突然断掉，整个任务就废了。固定 IP 更是必须，方便你反复 ssh 进去调试。

远程桌面方面，需要图形界面时我会开 VNC，但日常还是命令行 +scp同步文件为主。Coding Agent 本来就是命令行工具，SSH 加终端就是它最舒服的工作环境。

Python 环境我会单独建虚拟环境，绝不污染系统 Python：

python3 -m venv ~/venv source ~/venv/bin/activate

装 PyTorch 这类重包一定要用 NVIDIA 为 JetPack 编译好的轮子，直接从 PyPI 装 torch 很容易装到 x86 版本或版本不匹配的包，import 直接崩。这里很容易让 Agent 翻车，所以我干脆在 AGENTS.md 里写死，依赖全部从虚拟环境安装，版本以设备上实际探测到的为准。

4.2 “技能包”目录结构

我现在的项目结构固定如下：

~/jetson-project/ ├── AGENTS.md ├── skills/ │ ├── device/ │ │ └── 01_device_info.sh │ ├── tensorrt/ │ │ └── build_engine.sh │ ├── camera/ │ │ ├── test_csi_camera.py │ │ └── use_csi_camera.py │ ├── grove/ │ │ └── read_sensor.py │ └── test.sh ├── models/ ├── engines/ └── scripts/

AGENTS.md的内容前面已经给过，里面最核心的一句话是：每次写代码前，先运行bash skills/device/01_device_info.sh，再把输出贴回对话。这句话看着简单，实际效果却立竿见影。Agent 一旦知道了自己是 ARM64、JetPack 6.0、有 TensorRT 8.x，它的行为会立刻从“通用代码生成器”变成“Jetson 专用工程师”。

4.3 一次完整调教：从报错到跑通

我把一次真实的调教过程简化记录在这里，你感受下 Agent 是怎么一步步被“拉回正轨”的。

第一轮，我让 Agent“写一个用摄像头检测桌面上物体的脚本”。它没有读 AGENTS.md，直接输出：

import cv2 net = cv2.dnn.readNetFromONNX("yolov8n.onnx") cap = cv2.VideoCapture(0)

我拿到代码就知道要出事。果然，它没有下载权重、没有检查yolov8n.onnx是否存在、cv2.VideoCapture(0)也打不开 CSI 摄像头。这一轮的问题不是 Agent 不会写检测，而是它把通用服务器的习惯搬了过来。

第二轮，我把 AGENTS.md 路径指给它，并让它先跑01_device_info.sh。它看到输出里写着aarch64、JetPack 6.0、TensorRT 版本后，重新生成的方案变成三步：先下载 YOLOv8 权重并导出 ONNX，再用build_engine.sh转 engine，最后用 GStreamer pipeline 打开摄像头。这一版代码能跑通摄像头了，但 engine 推理时又报了维度不匹配——因为trtexec转换时固定了输入 shape，而 Python 端传入的图片尺寸没有做对应 resize。

第三轮，我把报错信息原封不动贴给 Agent，告诉它“引擎构建参数和推理参数必须一致”。它自己查了trtexec --help，补上了--shapes=input:1x3x640x640，并修正了 Python 端的预处理尺寸。这次终于跑通，摄像头实时出图，检测框稳定显示。

这整个过程中，我几乎没有替它写代码，只做了三件事：给设备信息、给官方技能、给报错反馈。只要这三样东西到位，Agent 的自我修正速度远超我的预期。

4.4 编写回归脚本，让 Agent 自己验证

“能让 Agent 自我修正”的前提，是你有一套快速验证的手段。如果验证一次要五分钟，Agent 试错成本太高；如果十秒能出结果，它就能快速迭代。

我写了一个skills/test.sh，每次 Agent 改完代码就跑一遍：

#!/bin/bash set -e source ~/venv/bin/activate echo "[1/4] Check engine" [ -f engines/yolov8n.engine ] || { echo "engine missing"; exit 1; } echo "[2/4] Check camera" ls /dev/video0 >/dev/null 2>&1 || { echo "camera missing"; exit 1; } echo "[3/4] Check TensorRT binding" python3 -c "import tensorrt as trt; print('trt', trt.__version__)" echo "[4/4] Run smoke test" python3 scripts/detect_smoke.py --input tests/sample.jpg --output /tmp/out.jpg

这个脚本的巧妙之处在于它把 Agent 的“想象空间”挤压到最小。它写完代码，自己跑test.sh，如果挂了，把输出带回来继续修；如果过了，它知道这次真的可以。这套“设备事实 + 技能示例 + 自动验证”的组合，就是我在 Jetson 上让 Coding Agent 从“会写”到“能跑”的全部秘密。

5. 边缘 AI 避坑速查表：这些坑我几乎每次都会碰到

5.1 高频问题与排查方案

在 Jetson 上带 Coding Agent 干活，有几类问题出现频率特别高。我把它们整理成一张速查表，遇到情况直接对号入座：

这里面最容易被忽视的是 GPU 频率和内存占用。Jetson 的 GPU 和内存是一体的，TensorRT 的--fp16能省一半显存并提速；AGX Orin 这类大设备还好，Orin Nano 这种 8GB 内存的板子，跑 1080p 输入很容易直接 OOM，必须学会给 Agent 设一个“分辨率上限”。“你的输入分辨率不要超过 960x544”这句话，比让它优化十次代码都管用。

5.2 工作流上的三个建议

技术问题能查表解决，但流程上的问题只能靠习惯。我带 Coding Agent 在 Jetson 上折腾了这些日子，沉淀了三条建议，你可以直接用。

第一，把 Agent 当“话很多的实习生”，不当全能工程师。每次派活前给出三个东西：环境事实（跑一下 device_info）、参考入口（skills 目录）、验收标准（test.sh）。只要这三个东西齐了，实习生也能干得像熟手。

第二，任务拆到“十分钟内能验证”的粒度。不要一句话让它“做一个完整的边缘检测系统”，而是先“让摄像头输出一帧画面”，再“跑通 engine 推理”，最后“接上 PIR 触发”。每个小目标都能快速验证，Agent 的试错效率会高很多。我在 4.3 节里那三轮调试，核心就是把一个大任务拆成了三个小闭环。

第三，跑通的脚本马上沉淀回 skills 目录。今天让 Agent 调通的 CSI 摄像头代码，明天新项目里还会遇到。与其让它重新写，不如把这段代码保存为skills/camera/use_csi_camera.py，下次在 AGENTS.md 里指个路径就行。做的项目越多，这个技能包越值钱，Agent 翻车次数也肉眼可见地下降。

我在实际使用中最深的一点体会是：Coding Agent 在 Jetson 这类边缘设备上的表现，五成取决于你给的约束，三成取决于你准备的示例和脚本，剩下两成才轮到模型本身发挥。它真的不笨，很多时候只是没人告诉它“你现在站在一块 ARM 板子上，内存只有 8GB，摄像头要用 GStreamer 打开”。把设备事实、官方技能、验证闭环这三样东西喂给它，再复杂的边缘 AI 任务，它也能慢慢给你跑稳。我自己的这套技能包还在持续补充，后面遇到新的硬件坑、新的模型部署问题，再回来继续分享。