一个完整层级图

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

产品层
└── Assistant（ChatGPT / Copilot）

智能体层
└── Agent
    ├── Planner
    ├── Memory
    ├── Tools
    └── Skills

能力编排层
├── Skill（流程封装）
├── Chain（固定步骤）
└── Function Calling

工具层
└── Tools（API / DB / Search）

模型层
└── LLM（GPT / Claude / LLaMA）

Assistant = UI壳子
Agent = 决策大脑
Skill = 固定能力流程
Tool = 外部执行器
Model = 语言与推理引擎
Infra = 运行与部署系统

更详细的内容

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141

🟣 产品交互层（Product / Experience Layer）
│
├── Assistant（AI助手产品）
│   ├── ChatGPT / Copilot / Claude App
│   ├── Web / Mobile UI
│   ├── 对话管理（session / thread）
│   └── 权限 / 用户系统
│
├── Copilot（半自动辅助）
│   ├── IDE插件（代码补全）
│   ├── Office助手
│   └── 人类主导 + AI辅助
│
└── Multi-Agent Apps（多智能体应用）
    ├── Research App
    ├── AI Analyst
    └── AI Dev Team

🟡 智能体编排层（Agent Orchestration Layer）
│
├── Agent（智能体核心）
│   ├── Goal / Objective（目标）
│   ├── Reasoning Engine（推理）
│   ├── Action Selector（动作选择）
│   └── Loop Controller（循环执行）
│
├── Planner（任务规划器）
│   ├── Task decomposition（任务拆解）
│   ├── Dependency graph（依赖关系）
│   └── Step ordering（步骤排序）
│
├── Executor（执行器）
│   ├── Tool invocation
│   ├── Skill execution
│   └── Result validation
│
├── Memory System（记忆系统）
│   ├── Short-term memory（上下文窗口）
│   ├── Long-term memory（向量数据库）
│   └── Episodic memory（事件记录）
│
└── Reflection / Critic（反思系统）
    ├── Self-check
    ├── Error correction
    └── Retry strategy

🔵 能力编排层（Cognitive / Workflow Layer）
│
├── Skill（技能封装）
│   ├── Data analysis skill
│   ├── Report generation skill
│   └── Code generation skill
│
├── Chain（固定流程）
│   ├── Prompt Chain
│   ├── Tool Chain
│   └── RAG Chain
│
├── Workflow Engine
│   ├── DAG execution（有向无环图）
│   ├── condition branching
│   └── parallel execution
│
└── Prompt Engineering Layer
    ├── System prompt
    ├── Few-shot examples
    └── Role prompting

🟢 工具与外部能力层（Tooling Layer）
│
├── Tools（工具/API）
│   ├── REST APIs
│   ├── gRPC services
│   ├── DB query tools
│   ├── Web search tools
│   └── Code execution tools
│
├── Function Calling Protocol
│   ├── JSON schema
│   ├── parameter validation
│   └── structured output
│
├── RAG System（检索增强生成）
│   ├── embedding model
│   ├── vector database
│   ├── retriever
│   └── reranker
│
└── External Systems
    ├── SaaS APIs (Slack, Jira)
    ├── Internal microservices
    └── data warehouse

🟠 模型能力层（Model Layer）
│
├── Foundation Model
│   ├── GPT-4 / GPT-5 系列
│   ├── Claude 系列
│   ├── LLaMA 系列
│   └── Mistral 等
│
├── Instruction-tuned Model
│   ├── RLHF / DPO 训练
│   └── chat optimization
│
├── Multimodal Models
│   ├── text + image
│   ├── text + audio
│   └── text + video
│
└── Reasoning Models
    ├── chain-of-thought
    ├── tree-of-thought
    └── planning enhanced models

🔴 基础设施层（Infra Layer）
│
├── Inference Engine
│   ├── vLLM
│   ├── TensorRT-LLM
│   └── Ollama
│
├── Serving Layer
│   ├── API Gateway
│   ├── Load Balancer
│   └── Rate Limiting
│
├── Data Layer
│   ├── Vector DB (Pinecone / Milvus)
│   ├── Relational DB
│   └── Object Storage
│
├── Observability
│   ├── logging
│   ├── tracing
│   └── prompt monitoring
│
└── Security Layer
    ├── prompt injection protection
    ├── tool sandboxing
    └── data isolation

最近在研究RAG，计划生成一个独立的文档的支持系统，但是总是感觉RAG是个中间技术方案，不会太长久。

今天读到了karpathy/llm-wiki.md，很受启发。

背景

某云原生 application 在部署阶段对磁盘 I/O 有明确要求：
在挂载的 volume 上执行如下命令时，返回结果必须 ≥ 1MB/s。

1

dd if=/dev/zero of=./test2.img bs=4k count=10240 oflag=direct

• 顺序写
• 使用 O_DIRECT（无 page cache）
• 无 fsync
• 无元数据更新
• 无 WAL / journal
• 无随机写
• 无多层 flush

这是一个 4K 小块、无缓存、直写磁盘的测试场景。
如果在该条件下仍能满足性能要求，基本可以覆盖关系型数据库的所有严苛 I/O 场景。

系统架构与部署环境

1. 3 台 Baremetal（HP DL380 Gen11）

   • CPU：96 Core × 4
   • 内存：512 GB
   • 磁盘：4 × 4T HDD + 4 × 4T SSD
   • 网络：10G 光口

2. HDD 做 RAID1 用于 Host OS，SSD 不做 RAID

3. Host OS：Ubuntu 24.04，启用 KVM

4. 每台 Host 上运行多个 VM，其中部分 VM 挂载 SSD

5. VM 上部署 OpenShift

6. 3 个挂载 SSD 的 VM 作为存储节点，部署 ODF（Ceph）

   • 每块 SSD 对应一个 Ceph OSD

7. OpenShift 内部署 MariaDB 集群

   • 1 Master + 2 Slave
   • 使用 Ceph RWO Volume

8. 在 MariaDB 数据卷中执行 I/O 测试

调优过程

初始测试结果约 500~600 KB/s，远低于目标。

• Host 与 VM 层磁盘性能正常（SSD >100MB/s）
• VM 磁盘使用 virtio + cache=none + io=native

1
2
3
4
5
6

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='native' iothreads='8'/>
  <source dev='/dev/nvme0n1'/>
  <target dev='sda' bus=virtio'/>
  <address type='pci' controller='0' bus='0' target='0' unit='0'/>
</disk>

徘徊多次后，仍旧提升非常有限，检查ceph的性能指标是发现：

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

root@service:~#  oc exec $(oc get pod -n openshift-storage | grep tools | head -n 1) -n openshift-storage -it -- bash
bash-5.1$ ceph osd perf
osd commit_latency(ms) apply_latency(ms)
11                   0                 0
10                   0                 0
 9                   0                 0
 8                   0                 0
 7                   0                 0
 6                   0                 0
 5                   4                 4
 4                   0                 0
 3                   0                 0
 2                   4                 4
 1                   2                 2
 0                   5                 5

这里很明显的发现问题，osd网络延时有问题，不在同一个host上的osd延时明显较大，对比site上的情况，osd之间的延时是低于1ms的。
进行下一步验证网络延时发现，VM和VM之间，甚至HOST之间的ping值也是高于1ms的，所以基本锁定，性能上不去基本上是网络延时引起的，而不是disk I/O本身性能瓶颈引起。
为了进一步验证，把ceph的副本个数从三个改成一个，测试的结果有了明显的提升。

错误的尝试

中间尝试把HOST的网卡开启SR-IOV，网络延时瞬间降到0.1ms，提升明显，但是部署OCP的过程遇到很多问题，而且考虑到NUMA的影响，资源会浪费一半，无法走通，遂放弃。

尝试更改MTU，从1500增加到8500，有提升到700K/s,仍是无法满足要求，而且OCP更改MTU的成本也挺高。

核心瓶颈

在同另外一套lab环境对比以后，发现有几不同，我们的网卡类型，英特尔的网卡+10G光口，另一套的lab是高通的网卡+10G电口，网速ping值的差距非常明显，一个是1ms，一个是0.1ms,怀疑网卡配置，但是调试多次以后，甚至交换网卡，仍然没有明显的改变。
最后猜测是不是CPU的调度问题，发现两个OS，一个是Ubuntu，一个是redhat，查询以后发现Ubuntu在很久前就引入了CPU idle（C-states），Ubuntu 默认启用内核的 cpuidle 子系统，允许 CPU 进入多级低功耗状态（如 C1, C2, C3 … 更深 C-states），Ubuntu 24.04 引入并默认使用 power-profiles-daemon 来统一管理电源策略，包括 idle、freq 和 sleep profiles。这意味着除了 CPU idle states 外，Ubuntu 24.04 会：

• 在桌面环境中提供电源模式（Balanced/Power-Saver/Performance）选项

• 默认是 Balanced 模式，结合 P-states + idle states 使功耗更低

https://help.ubuntu.com/stable/ubuntu-help/power-profile.html.en

检查Host OS以后，果然是默认开启了这个配置，修改成Performance模式，果然网速ping值里面提升到0.1ms， ceph的性能立马延时也降到1ms内。

再次测试dd，效果立竿见影达到1.4M/s，达成目标。

总结

1. 确认问题是网络延时引起的，明确瓶颈方向后持续深挖，避免无效调参。
2. HostOS尽量使用成熟的商业版本，推荐RedHat/RockyLinux。
3. 上层有软件级别的存储服务(Ceph),物理层就不要做raid了。
4. KVM跨node进行部署的时候还是会有小问题，优选还是安装openstack作为VNF层。

P.S. 以下命令会直接破坏磁盘数据，注意of的指向目录，请勿在生产环境使用：

1

dd if=/dev/zero of=/dev/vdd bs=4k count=10240 oflag=direct

今天中午在公司的比赛场地完成了今年的最后一次足球比赛，完美收官了。

统计记录来到了63场，122个小时，总消耗了超过了12万千卡，还是挺有成就感的。

大大超过了今年的预期，和去年的比例相当。（2024年6月-12月，37次）

明年加油！！！

在给XBot官方反馈了两次以后，APP得到了更新，每次的视频录像合并和处理的功能基本上满足日常需求了。

这周日的比赛，前三个星期一直没有踢，所以安全为上，踢了大半场的中后卫，最后几分钟冲上去打了一会饼锋，没想到特别快乐，斯特林附体。

请欣赏这一分钟两次的快乐足球。

在这篇文章中，介绍了如何使用飞天信诚的加密狗设备进行加密解密。
但是文章的最后，有一个遗憾，就是需要借助官方给的php代码来进行解密，自己尝试了几次用python实现，但是总是失败，今天终于发现了解决之道。

需要安装一个pycryptodome。

1

pip3 install pycryptodome -i http://mirrors.aliyun.com/pypi/simple/ --trusted-host mirrors.aliyun.com

最后的代码：

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

def check_rsa_code(encrypted_str: str) -> str:
        """
    使用公钥解密（等效于 PHP 的 openssl_public_decrypt）
    适配 PKCS#1 v1.5 两种 padding 格式 (0x01/0x02)

    :param encrypted_str: URL 编码 + Base64 编码的密文
    :return: 解密后的明文字符串
    """
    # === 1. RSA 公钥 ===
    public_key_pem = """-----BEGIN PUBLIC KEY-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxx
-----END PUBLIC KEY-----"""

    # === 2. 处理输入：urldecode + base64 decode ===
    # PHP 里是 rawurldecode(urlencode(urldecode(...)))，等效这里直接 unquote 一次
    encrypted_str = unquote(encrypted_str)
    encrypted_bytes = base64.b64decode(encrypted_str)

    # === 3. 导入 RSA 公钥，并获取模数 (n) 和指数 (e) ===
    rsa_key = RSA.import_key(public_key_pem)
    n = rsa_key.n
    e = rsa_key.e

    # === 4. 转换为整数，执行 RSA 运算 (cipher^e mod n) ===
    cipher_int = int.from_bytes(encrypted_bytes, byteorder="big")
    plain_int = pow(cipher_int, e, n)

    # === 5. 转回字节数组，长度按密钥大小补齐 ===
    k = (rsa_key.size_in_bits() + 7) // 8
    plain_bytes = plain_int.to_bytes(k, byteorder="big")

    # === 6. 处理 PKCS#1 v1.5 Padding ===
    # 格式有两种：
    #   - 00 01 FF FF ... FF 00 <data>
    #   - 00 02 xx xx ... xx 00 <data>
    if len(plain_bytes) > 2 and plain_bytes[0] == 0x00:
        if plain_bytes[1] == 0x01:  # 类型 1：FF 填充
            sep_idx = plain_bytes.find(b"\x00", 2)
            if sep_idx > 0:
                plain_bytes = plain_bytes[sep_idx+1:]
        elif plain_bytes[1] == 0x02:  # 类型 2：随机字节填充
            sep_idx = plain_bytes.find(b"\x00", 2)
            if sep_idx > 0:
                plain_bytes = plain_bytes[sep_idx+1:]
        else:
            # 如果不是标准 padding，就去掉前导 0
            plain_bytes = plain_bytes.lstrip(b"\x00")
    else:
        plain_bytes = plain_bytes.lstrip(b"\x00")

    # === 7. 返回解码结果（明文是 UTF-8 字符串，如 "3238095759"） ===
    return plain_bytes.decode("utf-8")

这样就解决了这一问题，完全不再依赖PHP了，真好！
困扰了四年的问题，就这样解决了~

前一阵得到一笔意外收入，为了在葫芦娃俱乐部踢的更开心，和老边商量决定买一个xbot足球比赛录像设备。

开始用着感觉不错，但是有两点挺鸡肋，一是这个设备不能自己录像，设备只提供运动跟踪和云台功能，录像需要用手机的摄像头，这样就需要占用手机，如果被电话等程序打断，录制有可能中断。二是如果想快速剪辑，就需要在录像的时候用遥控器操作打点，这样如果我在场上踢比赛，是无法操作的，没有打点记录，剪辑的时候时间成本就比较高了。

但是，昨天的比赛中，当他录到我的一个高光时刻的时候，我对他的印象分又提高了不少。

请欣赏这一记精彩的后脚跟磕球助攻。

现在的两个解决方案：

• 录像现在直接传到B站，清晰度，速度都可以接受，这样不剪辑也可以。录制完直接传，占用不了多少时间。

• 视频录像上有实时的时间水印，这一点比较好，那么就需要在精彩时刻发生的时候，想办法快速的记录下时间，并且编辑的时候，直接补打上点，就可以快速的剪辑出来精彩集锦了。

所以目前唯一的不足，是如何在场上踢球的时候，也能多次快速的记录下准确的时间呢？

无锡的项目搞的差不多了，从忙碌的疯狂进代码的阶段进入了短暂的空闲期。
啤酒城的项目今年没有啥大的改动，等合同敲定，活动开业前，把服务器重新部署上线即可。
不夜城街区的项目，肥城的已经完成，等剑阁项目和临夏项目开业，服务器部署一下，活也不是太多。

那么，得琢磨个事情干干，这段空档期干点啥好呢~

软件的版本，又何尝不是人生的版本呢？

最近在把分散在各地的项目进行了整合，计划合并到一个服务器上，搬家工作搞了整整一天。

研究了一番，最后把去年项目剩的服务器全给取消了，买了一个阿里云的云小站 https://www.aliyun.com/minisite/goods 的ECS。

配置有两种：

1. 2核2G，3M固定带宽，40G ESSD Entry云盘 ￥99.00/1年起 官网折扣价: ¥956.64/1年

2. 2核4G，5M固定带宽，80G ESSD Entry云盘 ￥199.00/1年起 官网折扣价: ¥2507.70/1年

物超所值，几乎不到1折的价格，更重要的是，能不限年限的续费，一个账户只能嫖一个。

直接199的配置走起，2核4G完全够用。跑了两个Python Flask， 两个Python FastAPI, 两个静态site，还能剩余2.2G内存，妥妥够用。

感谢阿里云~

PyCharm里如果有js, html 和css文件，社区版本的IDE是不能直接格式化这些静态文件，需要专业版的来实现。
所以，可以尝试在terminal里直接使用prettier格式化代码。

1
2
3
4
5
6
7

# 用node全局安装
npm install -g prettier

# 格式化项目里的所有的js,jsx,ts,tsx,css,html,json
# 在宽屏幕下，可以设置代码的折行宽度大一些，在我的屏幕上180是个不错的选择。
npx prettier --write "**/*.{js,jsx,ts,tsx,css,html,json}" --print-width 180