长连接无处不在：Agent 架构背后的通信真相

一句话概括：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 是一段结构化的提示词。

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

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

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

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

背景

用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 本身也建议两者都配置。

一句话概括：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：一个独立进程（或远程服务），向外暴露”工具 / 资源 / 提示词”。

通信方式有两种：

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

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

为什么？

因为 LLM 本身没有记忆。

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

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

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

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

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

背景

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

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

数据库有哪几种锁？

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

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

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

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

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

背景

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

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

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

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

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

错误排查

任务有在正常的执行吗？

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

前言

现在对于一个开发来说，Docker应该是再熟悉不过了。 还记得在2013~2014左右的时候，听说多最多的就是Cloud Foundry，那个时候就一直在说云的事情。后面Docker就绝杀了它~

那它帮我们解决了一个什么问题了？面试的时候也许会问到。

在很久以前，我们开发代码，估计最蛋疼的事情就是发布版本了。我还记得在房多多的时候(2014~2016)左右，每次发布几个开发围绕在运维的身边，有时候运维忙不过来，开发就直接在运维的电脑上开始VIM干活了，修改若干配置。由于多环境的原因，我们无法保证每个环境都是一样的。

• 可能你的操作系统不同，导致打包、发布的脚本不同
• 环境不同，没有很好的配置管理，你的代码有不同的写法
• 特别是跟操作系统相关的那些参数，可能瞬间就会带来性能问题

那么Docker就可以把我们的操作系统、代码、脚本等都一起打包成一个Image，就可以保证只要是运行同一个Image，我们的所有内容都是一样的。就不会出现，我在测试环境跑的好好的，一到生产连启动都成问题。

问题

现在一般一个POD就只跑一个进程，DevOps会根据我们的发布流水线自动的将一个项目进行打包、发布，整套的CI、CD做的是行云流水。但是，每个项目ROOT下都会需要一个叫Dockerfile的文件。但偏偏有一些历史项目，没有Dockerfile文件，只有一个Run的容器再跑，真的是非常惊悚。docker rm [OPTIONS] CONTAINER [CONTAINER...],就GAME OVER了。

怎么办？

方法1：以当前容器作为基础镜像