简栈

一句话概括：APM 不是”上个监控系统”，而是回答四个递进的问题——系统健康吗（Metrics）、慢在哪一跳（Traces）、当时到底发生了什么（Logs）、哪里是系统性瓶颈（三者聚合）。这四层缺一层，排查就会退化成人肉翻日志。而把它们串起来的那根线，只有一个东西：一个全局唯一的 traceId。

一、先还原一次真实的排查现场

线上告警来了，某个接口开始报错。你会怎么查？

我把我们团队过去的真实动作拆出来，是这样一条路径：

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

告警响了
   │
   ▼
① 打开配置中心 ──── 这个服务当前是什么配置？连的哪个环境？
   │
   ▼
② 打开注册中心 ──── 这个服务注册了几个实例？哪些还活着？
   │
   ▼
③ 打开容器平台 ──── 找到对应的 Deployment
   │
   ▼
④ 进到 Pod 里 ───── kubectl exec，一个一个进
   │
   ▼
⑤ grep / less ───── 在几万行日志里翻，凭时间戳猜哪条是这次请求
   │
   ▼
⑥ 发现是 RPC 报错 ── 下游服务返回了 error
   │
   ▼
⑦ 换到下游系统 ───── ①②③④⑤ 再走一遍  ← 死循环从这里开始

举个具体例子。一次报错的完整链路是：

1

api-gateway  →  query-service  →  queryByThirdParty  →  error

三跳。为了知道 error 出在第三跳，你要把上面那套动作做三遍。

这套流程的平均耗时：15～30 分钟。

一句话概括：Agent 架构里几乎每一条链路——UI ↔ Agent、Agent ↔ LLM、Agent ↔ MCP——都是长连接。这不是工程师故意”炫技”，而是被 LLM 的流式生成这一底层特性逼出来的必然结果。一旦生成是”边想边说”的，请求-响应就塌了，整条链路都得跟着流起来。

一个你可能忽略的细节

打开 ChatGPT、Claude、Cursor 这些 AI 应用，你都会看到同一个现象：

回复是一个字一个字”蹦”出来的，不是整段刷新出来的。

看起来只是个动画效果？不是。

它背后是整个 Agent 架构区别于传统 Web 应用的底层通信范式——没有任何一个字是等全部生成完才发过来的，每一个 token 都是实时推送的。

再往深看一层，你会发现：

• 浏览器和 Agent 服务之间，连接一直没断
• Agent 和 LLM 厂商（OpenAI / Anthropic）之间，连接也没断
• Agent 和它调用的 MCP Server 之间，连接还是没断

三段链路，全是长连接。

白天先是在x上看到微信官方发的post，后面才是在微信公帐号看到很多的文章，今天也算是终于跟微信结合起来了，肯定效率是更加高+便捷的。安装微信ClawBot的几个前置条件。

1、微信是国内版本，并且升级到Version 8.0.70，可惜美区的wechat、PC版本的不行。
2、更新后从设置➡️插件，第一次会出现看不到（可能有缓存，我跟群里的小伙伴都遇到了），重启微信就可以解决

安装微信ClawBot

1

openclaw plugins install "@tencent-weixin/openclaw-weixin"

剩下的就是扫描登录，这里注意的是它绑定的是main agent。

微信插件安装了些什么？

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

.
├── agents
├── canvas
├── completions
├── credentials
├── cron
├── devices
├── exec-approvals.json
├── extensions
│    └── openclaw-weixin
├── identity
├── memory
├── openclaw-weixin
│    ├── accounts
│    └── accounts.json
├── openclaw.json
├── README.md
├── skills
├── update-check.json
└── workspace

绑定多个微信如何做？

最近有两种声音在同时流传：

一种说 “CLI 正在替代 MCP”，另一种说 “MCP 才是未来，CLI 要被淘汰”。

你信哪个？

我的答案是——两种都说错了，因为它们在比较两件根本不在同一维度的事。

就像有人说”锤子要替代快递”。锤子是工具，快递是运输协议，它们根本不在同一个维度上竞争。

先把概念说清楚

CLI（命令行界面）：git commit -m "fix bug"，文本命令，直接执行，Unix 哲学的精髓——做一件事，做好它。

API（应用程序接口）：POST /api/send-email，程序间的通信契约，成熟、稳定、跨语言，是系统集成的基础。

MCP（模型上下文协议）：Anthropic 提出的 AI 工具调用标准，专门为”AI Agent 调用工具”设计的协议层。

注意最后这句话——MCP 是协议，CLI 是工具形态。

最近媒体在密集传播一个观点：Skills 正在替代 MCP。

你信吗？

我第一反应是——这话听起来有道理，但哪里不对劲。

就像有人说”操作手册要替代机器”。手册写得再详细，机器不在，活儿还是干不了。

Skills 到底是什么？

说白了，Skills 是一段结构化的提示词。

它告诉模型：遇到这类任务，你应该怎么思考、按什么步骤来、注意哪些边界。比你随手写一句”帮我分析这个问题”要强得多——它更像一本操作手册，有流程、有角色、有约束。

但本质上，它还是提示词。

它的能力来源，是模型自身。

这一点很关键，也是后面所有判断的基础。

一句话概括：MCP（Model Context Protocol）是给 Agent 接上”手”和”眼”的标准插头。它定义了一套严格的握手协议，让 Agent 知道”有什么工具可用、怎么调用”——从建立连接到最终执行工具，每一步都有明确的分工。LLM 在其中只负责推理和决策，真正调用 MCP 的是 Host（宿主应用）。

背景：为什么需要 MCP？

LLM 本质上只会”说话”，它没有办法自己去查数据库、调接口、读文件。要让 LLM 具备这些能力，必须给它一个标准化的方式来”发现工具”并”使用工具”。

以前每家公司都自己搞一套，乱得很。Anthropic 提出了 MCP，相当于制定了一个通用的 USB 接口标准——不管是什么工具（数据库插件、网页抓取、代码执行器），只要实现了 MCP 协议，LLM 就能用统一的方式调用。

整体架构：三个角色

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

┌─────────────────────────────────┐
│         Host（宿主应用）          │
│                                 │
│  ┌───────────┐  ┌─────────────┐ │
│  │    LLM    │  │  MCP Client │ │
│  │ (推理决策) │  │  (协议通信)  │ │
│  └───────────┘  └──────┬──────┘ │
└─────────────────────────┼───────┘
                          │  JSON-RPC
                          ▼
              ┌───────────────────┐
              │    MCP Server     │
              │   （工具提供方）    │
              └───────────────────┘

• Host（宿主）：运行整个 Agent 的应用，比如 Claude Desktop、Cursor、你自己写的 Agent 程序。它同时持有 LLM 调用能力和 MCP Client。
• LLM：只负责推理和决策，输出 tool_use JSON 表达意图，从不直接调用任何工具。
• MCP Client：嵌在 Host 内部，负责实现 MCP 协议、与 MCP Server 通信。Host 解析 LLM 的 tool_use 输出后，由 MCP Client 代为执行。
• MCP Server：一个独立进程（或远程服务），向外暴露”工具 / 资源 / 提示词”。

通信方式有两种：

背景

用Proxyman抓包来分析一下CODEBUDDY、CLAUDE CODE与LLM之间的交互，如果是用Terminal的方式发现无法抓到，发现需要在环境变量里开启才行，所以就了解了下多种开启代理的区别。

两种方式的区别

有本质区别，作用范围完全不同：

1. networksetup — 系统级代理
   修改的是 macOS 系统网络设置（等同于在「系统设置 → 网络 → 代理」里手动勾选）
   立即生效，无需重启终端
   影响范围：所有 GUI 应用（Safari、Chrome、Postman 等）以及大多数遵循系统代理的程序
   不影响终端里的命令行工具（curl、npm、pip、node 等默认不读系统代理）

2. ~/.zshrc 环境变量 — Shell 级代理
   修改的是 Shell 进程的环境变量
   需要重新 source ~/.zshrc 或开新终端才生效
   影响范围：仅终端内的命令行工具（curl、npm、pip、git、node 等）
   不影响 GUI 应用

对比总结

结论

如果你用 Proxyman 抓 终端命令行工具（如 curl、npm 、install、node 发的请求）的包，必须设置 ~/.zshrc 环境变量，networksetup 对这些工具无效。
两者可以同时开启，互不冲突，Proxyman 本身也建议两者都配置。

你有没有遇到过这种情况——

同一个 AI 助手，在 A 项目里像个老手：熟悉技术栈、遵守规范、说话有分寸。换到 B 项目，却像个刚入职的新人，什么都不知道，什么都要从头解释。

为什么？

因为 LLM 本身没有记忆。

每次对话，它都从零开始。它不知道你的项目用什么语言，不知道你的团队有什么规范，不知道你上次说了什么。它只是一个极其强大的”推理引擎”——给它什么上下文，它就基于什么上下文思考。

这就是问题所在，也是 AGENT.md 存在的原因。

LLM 是大脑，但大脑需要被”装配”

想象你雇了一个能力极强的顾问。

但每次见面，他都完全不记得你是谁、你的公司做什么、你们上次谈了什么。你每次都要从头介绍，每次都要重新建立信任，每次都要重新解释规则。

背景

前段时间做了很多慢SQL的优化工作，这周刚好又被反馈服务出现了死锁导致了业务报错。看了一下云数据库的告警日志，发现出现了比较多的事务未提交、死锁、等待行锁的严重警告。都是一些棘手的运维工作，涉及到业务流程的梳理、SQL的优化等工作。

今天趁这个机会，我们一起看下如何去分析这些问题，主要看下等待行锁、死锁。

数据库有哪几种锁？

每次说数据库锁，感觉一大堆。其实如果按照一定的纬度去整理下，还是比较清晰的。如图:

力度划分：表锁、页锁、行锁

算法划分：Record Lock、Gap Lock、Next-key Lock

实现机制：乐观锁、悲观锁

兼容性：排它锁、共享锁、意向锁

背景

我们来先看一个图，了解一下故(事)事(故)的背景：

有2个跑批任务，其实做的事情是同一件事情，都是为了跟下游系统保持数据的一致性。大任务是每个2h跑一次，小任务是每隔10mins跑一次。除了这2个定时任务以外，还有一个额外的监控任务来做类似的对账，如果发现出现对账不平，就会出现邮件/短信告警到相关的责任上。

这是一个非常有特点的定时任务跑批任务+监控告警的场景了。

从上面的场景上看，我们可以得出一些结论：为了保证一致性写了大小Job来保证，并且还给出了监控告警，说明数据的重要性是比较强的。

某天，出现了频繁的告警提示，每10分钟就告警一次，而且内容没有发生变化，说明同步的index没有变化过。

错误排查

任务有在正常的执行吗？

第一反应肯定是在思考，我的大任务与小任务都有正常执行吗？因为之前的都是正常的。上午看了一下日志与进程发现有在跑，还跑除了多次任务，日志打印不明确，看不到具体分支的逻辑。总结一下问题点：