《AI OS的升维之旅》文章系列第六篇：可观测性升维，三条 trace 链路覆盖所有盲区- 大数跨境

《AI OS的升维之旅》文章系列第六篇：可观测性升维，三条 trace 链路覆盖所有盲区

AI驱动数字化转型

2026-07-17

导读：我构建了一套多智能体协同系统，取名为三体架构。三个体各有独立职责。《AI OS的升维之旅》文章系列第六篇：可观测性升维，三条 trace 链路覆盖所有盲区。

我构建了一套多智能体协同系统，取名为三体架构。三个体各有独立职责。OpenClaw 是意识中枢，负责理解意图、路由任务、管理对话，不做任何有副作用的操作。Hermes 是执行层，负责搜索、文件操作、浏览器自动化、shell 命令以及内容写作，不做决策。Codex 是编码层，负责写代码、重构、调试、测试。三个体通过 sessions_spawn 通信，不共享内存，不共享进程空间，故障互相隔离。

支撑这套系统持续进化的是一套知识基础设施，以 Obsidian 为基础的知识库。每次写作完成，新概念自动写入原子笔记，文章索引自动更新，知识图谱重新关联。知识不会停在原地，它会在系统内部流动，从原始对话逐渐提炼成可复用的结构化知识。

三体加 Obsidian 知识库构成了一个从意图理解到执行落地到知识沉淀的完整闭环。

本文是「AI OS 升维之旅」系列第六篇。

三体架构的故障定位问题

三体架构把单进程拆成三个独立体。拆分解决了故障隔离问题，也制造了新问题：出了故障怎么定位。单进程时代一份日志够了，三体模式下需要追踪 trace_id 在三个进程之间的传播。哪个体出了问题，问题发生在哪一步，影响范围多大。答案不能靠猜。

三层监控链路：SabreTiger 剑齿虎

SabreTiger 剑齿虎就是为这个场景设计的。它在三体之上包裹了三层监控链路，覆盖从进程存活到宿主机状态到 trace 追踪的全部需求。

链路 A：核心 trace

链路 A 是核心 trace。三体各体写入管道文件，tri-tracer-v3 做字节偏移增量读取，每条服务独立 OTel Resource。tri-trace-ctx.py 的 new 和 inherit 机制生成 traceid 继承链。父进程 spawn 子任务时继承 traceid，子任务的每个 span 都带着父进程的上下文。

链路 B：守护进程

链路 B 是守护进程。sabretiger-guardian.py 监听 OpenClaw SQLite 和 Hermes processes.json 的变化。不主动轮询，被动捕捉事件。SQLite 有新 session 开始或 Hermes 有新的子进程启动时，guardian 写入一个 span。这个链路的价值在对事件敏感，不对轮询敏感。

链路 C：心跳

链路 C 是心跳。tri-heartbeat.py 每三十秒检查三体进程存活和宿主机 CPU 内存和 Docker 容器状态。Windows 上 tasklist 过滤镜像名，Linux 上 pgrep。检测结果汇总写入 tribodysummary Span。

数据流转与可视化

三条链路通过同一个管道文件汇入 OTel Collector。tri-tracer-v3 从管道文件读取后组装成 OTLP Span，发送到 OTel Collector 的 4317 端口。Collector 分发到 DataBuff、Tempo、Prometheus、Loki。Grafana 做统一可视化。

以一个 span 的生命为例。用户发一句搜一下昨天的日志。OpenClaw 路由匹配后 sessionsspawn 创建子会话。tri-trace-ctx.py inherit 机制从当前 traceid 生成子 traceid，继承的 span 记录 start 时间戳和父 span ID。Hermes 收到 task 开始执行，hermes-hook.py 在 exec 结束时写入一行 JSON 到 tri-tracer-pipe.json，字段包括 service name 固定为 hermes，span name 为 execshell，status 为 OK 或 ERROR，执行时间戳，attributes 字典记录命令和退出码。tri-tracer-v3 通过字节偏移增量读取管道文件，读取到新行后解析 JSON，组装 OTLP Span。每个 service 有独立的 OTel Resource，resource 属性包含 service name 和对应的容器名。OTLP Span 发送到 OTel Collector 的 4317 端口，Collector 根据配置分发到多个后端。DataBuff 的 Doris 做底层存储，tracedcspan 表按天分区，七天 TTL 自动过期。Tempo 也收到同样的 span 用于快速检索。Grafana 上可以按 trace_id 检索整个调用链。写完 span 后 Hermes 把执行结果序列化回传给 OpenClaw，OpenClaw 的反序列化完成时写入一个 response span，status 同样记录 OK 或 ERROR。从请求到返回的三体链路变成了 Grafana 上一条带时间轴的 trace 链。

心跳检查逻辑

tri-heartbeat.py 的检查逻辑很直接。TRIBODYPROCS 字典里三个 key 对应 openclaw、hermes、codex，每个有 exe 名称和描述。Windows 上 tasklist 过滤镜像名，Linux 上 pgrep。每体写入独立心跳 Span 到 DataBuff。tribodysummary 汇总总存活数和死亡数。除此之外还检查宿主机状态。CPU 负载走 wmic cpu get loadpercentage，内存走 wmic OS 获取 TotalVisibleMemorySize 和 FreePhysicalMemory。宿主机数据写入 hosthealth Span。Docker 容器状态通过 docker ps 检查，每个容器写入 dockercontainer Span。

智能分析

DataBuff 使用 Doris 4.1.1 做底层存储。tracedcspan 表按天分区，七天 TTL 的数据保留策略。metricservicetrace 每分钟做一次聚合。DataBuff 注册了两位数字专家，一位 Trace 分析师，一位主机健康分析师，都走 DeepSeek Chat 模型。分析师不参与决策，只做分析报告。在 Grafana 上看到告警时，分析师的分析报告已经生成在 DataBuff 的 Web UI 上。

资源消耗

三条链路、两个 Collector、五个后端、一套 APM。这个可观测性体系本身的资源消耗是多少。tri-tracer-pipe.json 每二十四小时约五到十 MB。tri-tracer-v3 的 Python 进程稳定在 30MB RSS。OTel Collector 的内存根据负载不同在一百到三百 MB。Doris BE 约五百 MB，FE 约两百 MB。全部加起来约 1GB 内存。在 32GB 总内存的笔记本上占比百分之三。对于一套企业级可观测性来说，这个成本是划算的。同等能力的 SaaS 方案月费在五十美元以上，这里用 1GB 内存换来了同等水平的 trace 存储和可视化能力。

完整的《AI OS升维之旅：从单体到三体·社区版到定制版的工程跃迁》全书，关注公众号或者加我好友索取pdf。

【声明】内容源于网络

AI驱动数字化转型

专注AI，促进智造行业数据衍生，服务智能制造企业的数字化、智能化，聚焦大模型私域部署、大模型微调、数据清洗、AI模型训练、私域知识库及agent技术延展等。行业智能，落地为先。

内容 1046

粉丝 1

AI驱动数字化转型专注AI，促进智造行业数据衍生，服务智能制造企业的数字化、智能化，聚焦大模型私域部署、大模型微调、数据清洗、AI模型训练、私域知识库及agent技术延展等。行业智能，落地为先。

总阅读8.0k

粉丝1

内容1.0k