Hermes Team 拆分方案整理

目的：把前面关于 Hermes Team 拆分、Profile 创建、角色职责、命令报错、执行步骤、后续任务的讨论整理成一个可直接落地执行的 hermes-team.md 文档。

Table of Contents

• Table of Contents
• 1：开发工具
• 2：调试工具
• 3：常用网站
• 4：golang 常用库

1：开发工具

1: sql2go sql 语句转换为 Go 结构体，使用 ddl。 http://stming.cn/tool/sql2go.html

2: json2go 将 json 格式转为 Go struct https://mholt.github.io/json-to-go/

3: toml2go 将编码后的 toml 文本转为 Go struct https://xuri.me/toml-to-go/

4: curl2go 将 curl 命令转为 go 代码 https://mholt.github.io/curl-to-go/

• 08-code-review-graph：用知识图谱让 AI Code Review 省下 8 倍 Token
  • 1：为什么 AI Code Review 会浪费大量 Token
  • 2：code-review-graph 是怎么工作的
    • 2.1 用 Tree-sitter 构建结构化代码图谱
    • 2.2 用 blast radius 只圈出真正相关的文件
    • 2.3 用 MCP 把图谱能力暴露给 AI Coding 工具
  • 3：它到底省了多少 Token
  • 4：适合什么场景，不适合什么场景
  • 5：快速上手
  • 6：我对这个工具的看法
  • 7：相关链接

08-code-review-graph：用知识图谱让 AI Code Review 省下 8 倍 Token

平常用 Claude Code、Codex、Cursor 这类 AI Coding Agent 时，一个很常见的问题是：每次问一个稍微复杂一点的问题，AI 都会重新读一遍整个项目。

1: 概述

• 最近看 AI Coding 工具的使用成本时，一个很容易被忽略的问题不是“模型推理本身有多贵”，而是 AI 为了理解代码，要先读掉多少无关上下文；

1: skill-hub 管理众多 Skills

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# WSL

# npm install -g https://github.com/Backtthefuture/skillmanager/raw/main/release/claude-skill-hub.tgz && skill-hub
npm install -g https://github.com/Backtthefuture/huangshu/raw/main/tools/skill-hub/release/claude-skill-hub.tgz && skill-hub

added 104 packages in 5s

34 packages are looking for funding
  run `npm fund` for details

🚀 Claude Skill Hub running at http://localhost:3456
🌐 Web UI:   http://localhost:3456
🔍 Debug:    http://localhost:3456/api/debug
✅ Found 134 skills (9/41 locations, 525ms)
👀 File watcher active
💡 下次启动直接敲: skill-hub  (或访问 http://localhost:3456)

tmux 使用速查（面向 Claude TUI 场景）

1. 先记住 tmux 的 3 个层级

• session：一个独立会话，像一整套工作台
• window：会话里的标签页
• pane：窗口里的分屏

你现在最需要会的是：

• 原文链接: https://mp.weixin.qq.com/s/AocomOFTTr2V0PPL2rKiRA
• 本文按照当前 content/post/C++ 目录文章风格整理，核心关注点是低延迟行情链路中的 CPU 绑核设计。

1: 为什么行情模块要绑核

• 在高频交易系统中，行情接收、排序、因子计算、策略串行处理都属于延迟极其敏感的链路；
• 如果线程完全交给操作系统调度，线程可能在不同 CPU 核之间迁移；
• 一旦发生迁移，就可能引入上下文切换、缓存失效、TLB 抖动等额外开销；
• 对于普通业务系统，这类开销通常可以接受，但在微秒级优化场景里，抖动本身就是问题；
• 因此，行情模块做绑核，本质上是在用更强的确定性换更低的延迟波动。

2: 绑核前需要先处理哪些前提

• 绑核并不是简单地把线程固定到某个 CPU 上；
• 如果机器本身还有很多后台任务、IRQ 中断、SMT 竞争，单纯调用一次绑核接口往往效果有限；
• 一般要先处理以下几个前提。

2.1 优先使用物理核

• 对低延迟线程，优先绑定到物理核心而不是超线程；
• 因为同一个物理核心上的两个超线程仍然共享执行单元、缓存和带宽；
• 如果关键线程落在 SMT sibling 上，抖动很容易被放大。

2.2 处理 irqbalance

• irqbalance 会自动平衡硬件中断；
• 在通用服务器场景这很有用，但在低延迟交易系统中，它可能把网络中断重新分配到不希望被打扰的核心上；
• 所以实践里常见做法是停掉 irqbalance，然后手动规划网卡队列和 CPU 的对应关系。

1
2

sudo systemctl stop irqbalance
sudo systemctl disable irqbalance

2.3 视情况关闭 SMT / Hyper-Threading

• 如果机器专门用于极低延迟场景，可以考虑关闭 SMT；
• 这样做的代价是吞吐下降，但能换来更干净的物理核心资源；
• 是否关闭，要结合机器用途和实际压测结果决定。

3: C++ 中如何实现线程绑核

• Linux 下常见做法是使用 pthread_setaffinity_np；
• 如果项目里用的是 std::thread 或 std::jthread，可以封装一层通用 helper，避免到处散落平台细节；
• 除了设置亲和性，最好还要增加一次实际验证，确认线程真的运行在预期 CPU 上。

3.1 一个简单的绑核辅助函数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#include <pthread.h>
#include <sched.h>
#include <unistd.h>

#include <iostream>
#include <stdexcept>
#include <thread>

void bind_thread_to_cpu(std::thread& th, int cpu_id) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(cpu_id, &cpuset);

    int rc = pthread_setaffinity_np(
        th.native_handle(),
        sizeof(cpu_set_t),
        &cpuset
    );

    if (rc != 0) {
        throw std::runtime_error("pthread_setaffinity_np failed");
    }
}

void worker() {
    std::cout << "running on cpu: " << sched_getcpu() << std::endl;
}

int main() {
    std::thread th(worker);
    bind_thread_to_cpu(th, 2);
    th.join();
    return 0;
}

3.2 更实用的封装建议

• 对 cpu_id 做合法性检查，避免绑定到不存在的核心；
• 给绑定操作加日志，方便排查部署环境差异；
• 在线程启动后增加一次 sched_getcpu() 验证；
• 如果是线程池或多阶段流水线，建议把绑核规则和业务线程角色分离配置。

4: 行情模块的绑核分层设计

• 行情模块不是一个线程，而是一条流水线；
• 真正有效的做法，不是“所有线程都绑核”，而是按照链路角色进行分层绑定；
• 常见的划分方式如下。

4.1 行情接收线程

• 行情接收线程负责从网卡队列读取数据，是链路最前端；
• 这类线程应当优先独占物理核，并尽量和 NIC queue 一一对应；
• 这样可以减少中断分发和线程迁移带来的额外抖动。

4.2 排序线程

• 如果行情源较多，接收后通常还需要排序或重组；
• 排序线程应与接收线程分开绑定到独立核心；
• 最好放在拓扑上相近的核心，降低跨核通信代价。

4.3 串行核心线程

• 因子、模型、策略串行主链路通常更强调确定性；
• 这一类线程往往要独占一个核心，尽可能不与其他任务共享；
• 它是整条交易决策链的热点线程之一。

4.4 监控与日志线程

• 监控、埋点、日志落盘线程优先级相对较低；
• 它们可以被安排到非关键核心，甚至低价值的超线程上；
• 原则是不要抢占行情主链路的缓存与调度资源。

4.5 一个典型的核心分配示意

5: 仅仅线程绑核还不够

• 如果操作系统仍然把其它任务调度到这些核心上，那么“独占核心”只是一种错觉；
• 真正想把关键 CPU 留给行情链路，还需要做系统级隔离。

5.1 isolcpus

• isolcpus 用于把指定 CPU 从常规调度域里隔离出去；
• 这样系统中的普通任务不会轻易落到这些 CPU 上。

5.2 nohz_full

• nohz_full 用于减少指定 CPU 上的调度 tick；
• 对低延迟线程来说，减少无关系统打扰是有价值的。

5.3 rcu_nocbs

• rcu_nocbs 可以让指定 CPU 避开 RCU callback 的干扰；
• 对需要极致稳定性的核心，这一点也很关键。

1

GRUB_CMDLINE_LINUX="isolcpus=0-8 nohz_full=0-8 rcu_nocbs=0-8"

• 上面的参数只是示例；
• 实际使用时应结合机器拓扑、服务部署方式以及运维策略统一规划。

6: 如何验证绑核是否真的生效

• 绑核不是“代码能运行就算完成”；
• 必须从代码层、系统层和性能层分别验证。

6.1 代码层验证

• 在线程工作函数中调用 sched_getcpu()；
• 确认线程运行时所在核心是否符合预期。

1

std::cout << "current cpu = " << sched_getcpu() << std::endl;

6.2 系统层验证

• 使用 taskset -cp <pid> 查看某个线程或进程的 CPU 亲和性；
• 也可以结合 ps -eLo pid,tid,psr,comm 观察线程实际落在哪个 CPU 上。

1
2

taskset -cp 12345
ps -eLo pid,tid,psr,comm | grep your_process

6.3 性能层验证

• 最终还是要看上下文切换、cache miss、延迟抖动这些指标有没有下降；
• 常见工具是 perf stat；
• 如果绑核后上下文切换次数和 cache miss 没有明显改善，就说明设计仍需调整。

1

perf stat -e context-switches,cache-misses,cache-references ./your_app

7: NUMA 是绑核设计里最容易被忽略的问题

• 在双路或多路服务器上，CPU、内存、PCIe 设备通常分布在不同 NUMA 节点；
• 如果线程绑在 node0，但网卡和内存分配落在 node1，那么跨 NUMA 访问会直接拉高延迟；
• 这会抵消很多绑核带来的收益。

7.1 NUMA 设计原则

• 行情接收线程、网卡队列、中间缓冲区最好放在同一个 NUMA node；
• 排序线程与后续串行线程也尽量保持局部性；
• 低延迟系统做绑核时，不能只看 CPU 编号，还要看拓扑关系。

7.2 常用排查工具

1
2

numactl --hardware
lscpu

• 如果需要更直观的硬件拓扑，也可以借助 lstopo 查看。

8: 一个更稳妥的实践结论

• 行情模块绑核的目标，不是为了“看起来专业”，而是为了降低链路中的非确定性；

1: 为什么 Claude Code 的差距不只在模型

很多人刚开始用 Claude Code 时，最先关注的是模型强不强、上下文长不长、生成速度快不快。 但真正用一段时间后就会发现，拉开人与人差距的，往往不是模型本身，而是你有没有把一批高频、稳定、可复用的 Skills 装进自己的工作流。

1: 概述

• 在 Web 服务、RPC 接口、配置加载这类场景里，我们经常要对输入数据做合法性校验；

• 如果完全手写 if/else 或正则，一个字段一个字段判断，代码很快就会变得又长又散；

1: 概述

• zerolog 是一个面向 Go 的结构化日志库，默认输出 JSON 格式;

• 它的核心卖点是高性能和低开销，比较适合接口服务、后台任务、网关等对吞吐比较敏感的场景;

• zero 这个名字通常对应它强调的 zero-allocation 设计思路;