LingBot-World 2.0 先跑通最小推理，再决定要不要接交互循环

把 LingBot-World 2.0 的仓库拉到本地之后，第一步不该是设计交互循环，而是按仓库自带的说明跑通一次单条输入的推理。交互循环会额外引入输入源、状态保持、时序控制这些变量，一旦跑不起来，报错到底来自模型、依赖还是你自己新写的那层框架，很难分清，排查成本会成倍增加。先让单次推理在日志和输出文件里留下可复现的证据，再判断值不值得接循环。

判断路径：先在仓库根目录找到 README 与依赖清单中的安装段落，逐条核对 Python、驱动与设备要求；再用一条最小启动命令完成单次推理，拿到输入输出的实际形态；接着核对推理后端与设备配置是否一致；最后把耗时、资源占用和报错原文写进记录。若单次推理都拿不到稳定输出，接交互循环只会把问题放大；只有当单次推理可复现、设备匹配、耗时与资源占用在可接受范围内，才值得投入循环改造。

在仓库根目录定位安装说明与依赖入口文件

安装依据应当来自仓库文件，而不是二手教程。先在根目录确认有哪些文件：README.md、docs/、requirements.txt、pyproject.toml、setup.py、environment.yml、package.json 这几类通常至少有一种存在。安装命令一般写在 README 的 Install、Getting Started、Quick Start 或 Usage 段落里，依赖清单则可能与 README 同目录，也可能在子目录。

ls -a
find . -maxdepth 2 -iname "*readme*" -o -maxdepth 2 -iname "requirements*.txt" -o -maxdepth 2 -iname "pyproject.toml"
grep -n -i -E "install|requirement|conda|pip|python|torch|cuda" README.md

定位到之后逐条核对：README 写明的 Python 版本区间、是否要求特定 CUDA 或驱动版本、是否需要额外下载权重文件、是否区分 CPU 与 GPU 安装路径。核对方法是用本地命令对齐，而不是凭印象：python `--version` 看解释器版本，pip list 看关键包是否已在环境内，nvidia-smi 看驱动与可识别设备，nvcc `--version` 在需要编译扩展时才核对。任何一条对不上，先按仓库说明调整环境，不要一边缺依赖一边往下走。

用一条最小启动命令完成单次推理

目标是拿到真实的输入输出形态，而不是跑满功能。命令骨架可以从仓库示例里抄，通常长这样，模块名、配置路径和参数名以仓库实际给出的为准：

python -m lingbot_world.infer \
  `--config` configs/minimal.yaml \
  `--input` samples/example_input.txt \
  `--output` runs/smoke_test \
  `--device` cuda:0

如果仓库提供的是脚本入口，就换成 python scripts/infer.py 这类写法；如果提供的是 CLI，则先执行 python -m lingbot_world `--help` 看已注册的子命令。参数不确定时不要猜，`--help` 和配置文件里的字段名是唯一可靠来源。

成功与失败的表现差异要看三处。其一，退出码：echo $? 返回 0 才算正常结束。其二，输出落盘位置：多数实现会写到 `--output` 指定目录下，形如 runs/smoke_test/ 内的结果文件与日志文件，用 ls -R runs/smoke_test 确认文件非空且可打开。其三，日志尾部是否有明确的完成字样。失败时常见的是 ModuleNotFoundError、FileNotFoundError（权重或输入路径不对）、CUDA out of memory、以及配置字段不被识别导致的 KeyError 或 unexpected keyword 报错。把失败那一行原文整段保留下来，后面记录表要用。

核对推理后端与所用设备是否匹配

启动失败里有相当一部分不是模型问题，而是后端与设备选错。先看环境里到底有什么设备，再看配置里选了哪个：

nvidia-smi
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available(), torch.cuda.device_count())"

输出里需要关注的字段：torch.cuda.is_available() 是否为 True、device_count() 返回几张卡、torch.version.cuda 与机器驱动支持的 CUDA 版本是否大致对得上。再对照仓库配置文件中的 device、backend、dtype 字段：如果配置写的是 cuda:0 而设备数为 0，必然启动失败；如果配置指定了某种半精度而当前设备不支持，通常会在加载阶段报类型或算子不支持的错。把 `--device` cpu 作为验证手段跑一次，能跑通说明代码路径本身没问题，瓶颈在设备选择或驱动匹配上。

把单次推理的耗时与资源占用写进记录

这条记录不是为了发报告，而是为了让你在决定是否接交互循环时有可对比的原始数据。建议每次运行都填这几项：

命令：      完整的启动命令原文
输入规模：  输入文件路径 + 行数/长度/分辨率等可量化的量
耗时：      用 time 或日志里的开始/结束时间戳，记冷启动与第二次运行两个值
资源占用：  nvidia-smi 观察的峰值显存，或 top 观察的峰值内存
结果形态：  输出文件路径 + 文件类型 + 大致内容
报错原文：  失败时整段粘贴，不要只写“报错了”

采集方式很直接：time python -m lingbot_world.infer ... 拿墙钟时间，另开一个终端用 watch -n 1 nvidia-smi 观察峰值。判断下一步的依据也在这份记录里：如果单次推理的冷启动时间明显长于一次交互能容忍的间隔，那交互循环的重点就不在框架，而在模型加载或缓存复用；如果两次运行耗时差异很大，先怀疑输入规模不一致或设备被其他进程占用；如果每次都在同一行报错，说明是配置或环境问题，此时接循环不会让错误消失。

在接循环前先明确输入来源与响应节奏

交互循环本质上是把“一次推理”包进“持续的输入—处理—输出”结构里。没有输入源就先搭框架，最后往往搭出一个空转的 while 循环。接之前先列清外部条件：输入从哪里来（键盘、摄像头、文件回放、HTTP 请求还是消息队列）、输入速率是否可控、输出送到哪里（终端、文件、接口响应）、单次响应能接受的时延上限、是否需要保持跨轮次的会话状态、出错后是重试还是跳过。

这些条件缺一项，就走对应的降级路径，而不是硬上：没有实时输入源，先用文件回放按固定间隔喂输入；没有事件驱动框架，先用同步阻塞的循环，一轮推理结束后再取下一份输入；没有并发要求，先用单会话串行；没有稳定的错误恢复策略，先让循环在报错时停下并打印原文，而不是静默重试。等这几步都验证过了，再把输入源换成真实设备或网络入口，改动范围也会小得多。