---

title: 2026-04-16 日志：从后端基础到多模态系统设计的一天 date: 2026-04-16 tags:

• 日志
• 学习记录
• 后端基础
• 多智能体
• YOLO
• Isaac Sim categories:
• Daily Log description: 记录今天在后端基础、多智能体系统设计、YOLO数据提取脚本以及 Isaac Sim 环境问题排查上的学习与推进情况。

---

2026-04-16 日志：从后端基础到多模态系统设计的一天

今天的节奏依旧比较紧凑，内容主要集中在四个方向：
一是继续梳理后端和操作系统相关的基础知识；
二是思考多智能体系统中如何引入 LangGraph 的设计思想；
三是推进 YOLO 在 ReID 场景中的数据提取需求；
四是排查 Isaac Sim 安装和显示环境相关的问题。

整体来看，今天更像是一次“知识梳理 + 需求拆解 + 工程排错”并行推进的过程。虽然没有在单一任务上一次性走到最终结果，但把几个关键问题的结构都逐渐理清了，这本身也是很重要的一步。

一、后端/操作系统基础：继续补齐底层理解

今天重新回看了 用户态与内核态 这一类经典问题。
这类问题看起来偏八股，但本质上考察的是对操作系统运行机制的理解，而不仅仅是背概念。

我今天的一个明显感受是：
这类知识点如果只停留在“定义”层面，很容易在面试里答得很空。真正更有效的方式，应该是从几个角度去组织：

1. 概念是什么
   用户态和内核态是 CPU 对程序执行权限的区分，用户态权限受限，内核态权限最高。

2. 为什么会有这种区分
   本质是为了保证操作系统安全性与稳定性，避免普通程序直接操作硬件或破坏系统资源。

3. 怎么发生切换
   常见场景包括系统调用、异常、中断等。程序在执行敏感操作时，需要从用户态切换到内核态，由操作系统代为完成。

4. 会带来什么影响
   状态切换有开销，因此频繁系统调用会影响性能。这也是很多高性能服务设计时会关注 syscall、上下文切换、零拷贝等问题的原因。

这让我再次意识到：
面试里的基础题，真正要练的不是“记住答案”，而是把一个知识点讲成一段有因果、有过程、有场景的解释。

二、多智能体系统设计：开始从“能不能做”转向“为什么这样设计”

今天还重点思考了一个更偏研究和系统设计的问题：
在当前智能体系统中，如何借鉴 LangGraph 的思想进行设计？它和传统通信、语义通信之间到底是什么关系？

这个问题一开始其实很容易直接下结论，但今天更重要的进展是：先把问题本身拆开了。

1. 当前真正要解决的是什么问题？

在做多智能体设计时，不能先急着谈框架，而要先明确系统目标。
目前更关键的问题包括：

• 多个智能体之间如何协作分工
• 信息在不同智能体之间如何流动
• 决策链路是否可追踪、可回溯
• 当任务复杂度提高时，系统是否还能稳定扩展

这样看下来，LangGraph 的价值并不只是“做流程编排”，而是在复杂任务里，把节点、状态、边和执行条件显式化，让整个系统从“对话式调用”变成“状态驱动的协作网络”。

2. LangGraph 思想适合解决什么

如果把智能体系统理解成一个动态工作流，那么 LangGraph 适合做的事情主要有：

• 定义不同智能体的职责节点
• 管理全局或局部状态
• 显式表示节点之间的跳转关系
• 支持循环、分支、回退和条件路由

这意味着它特别适合需要 多步骤推理、多角色协作、状态持续更新 的任务，而不是单轮问答式调用。

3. 与传统通信、语义通信的关系

今天比较重要的一个认识是：
它们并不是完全对立的概念，而是分处于不同层级。

• 传统通信 更关注“信息有没有传过去”
• 语义通信 更关注“传过去的信息是否保留了任务相关的语义”
• LangGraph 式多智能体协作 更关注“信息传递之后，系统如何基于状态继续组织推理和执行”

也就是说，传统通信和语义通信更偏“信息传输层”，而 LangGraph 更偏“任务组织层”和“推理流程层”。

这个区分理清之后，后面如果要做模型构建和实验设计，路径会更明确：
到底是要优化通信内容本身，还是要优化多智能体之间的协作逻辑，这两者不能混在一起谈。

三、YOLO 在 ReID 数据提取中的需求：从模糊目标走向清晰脚本设计

今天还推进了一个比较具体的工程需求：
希望使用 YOLO 模型，从 ReID 场景图像中提取 人的分割结果像素坐标 和 关键点坐标，并分别保存为 txt 和 npy 格式，供后续模型训练使用。

这个任务的核心，不是马上动手写代码，而是先把需求拆清楚。今天在这一步上推进得比较顺。

1. 需求本质

目前的目标并不是做完整检测展示，而是为了给后续训练过程准备结构化数据，因此输出设计很关键。

大致可以拆成两条线：

分割结果

• 对每张图提取人像 mask
• 将人和背景分别用 255 和 0 表示
• 输出为：
  • 图像可读型文本/索引信息
  • npy 数组文件

姿态关键点结果

• 提取 x, y, conf
• 分别保存为：
  • txt
  • npy

2. 今天比较关键的一点：明确了数据表达方式

在关键点部分，今天也注意到了一个容易混淆的细节：
当前保存的 x, y, conf 一般是 图像坐标系下的原始像素坐标，并不是自动归一化后的结果。

也就是说，像下面这种形式：

python
for idx, (x, y, conf) in enumerate(det.keypoints_xyc):
    lines.append(f"{idx} {x:.2f} {y:.2f} {conf:.6f}")