文章

发布于

MCP一周年：从“AI世界的USB-C”到行业集体倒戈

一、背景与核心事件

MCP（Model Context Protocol） 由 Anthropic 于 2024 年 11 月推出，旨在统一大模型与外部工具、数据源的连接方式，被比喻为“AI 世界的 USB-C”。

一年后（2026年），MCP 并未迎来庆祝，而是被多家头部公司放弃或拒绝。

关键转折点：

  • Perplexity CTO Denis Yarats 于 2026 年 3 月宣布放弃 MCP，转向 API 和 CLI。
  • OpenClaw（GitHub 上全球第一的开源 AI Agent 项目，创始人已加入 OpenAI）从一开始就不支持 MCP，改用 Skills 系统 + CLI。

网友评论普遍支持这一转向，认为“早该如此”。

二、MCP 的三个致命缺陷

1. 线性上下文成本

MCP 将每个工具的名称、描述、参数 Schema 全部注入 Agent 的上下文窗口。连接 10 个服务、每个 5 个工具，数千 Token 在任务开始前已被消耗。

  • 社区反馈：仅一个 Playwright MCP Server 就占用 200K 上下文窗口的 8%。
  • Anthropic 自己的工程博客也在探索用代码交互代替工具调用，Token 使用量从 150,000 降至 2,000。

2. 使用摩擦大

  • 初始化地狱：配置错误、环境变量遗漏、端口冲突，需反复重启和清空。
  • 认证疲劳：需频繁处理 GitHub Token、数据库密码、云服务 Key，且常失效。
  • 权限粗糙：缺乏细粒度控制，如“只读”或“只查某张表”。

3. 安全黑天鹅

MCP 引入新的攻击面：Prompt Injection 可通过工具返回的数据注入恶意指令。相比之下，CLI 沙箱执行的命令完全可审计，安全性更高。

三、行业倒戈案例

1. Perplexity（估值 180 亿美元的 AI 独角兽）

在实际使用中遭遇上述所有问题，最终选择“止损”，放弃 MCP。

2. OpenClaw（GitHub 第一 AI Agent 项目）

从一开始就拒绝 MCP，采用 Skills 系统 + CLI。核心区别对比：

维度 MCP OpenClaw Skills
加载方式 预加载所有工具定义 按需加载
上下文成本 线性增长 最小化
知识注入 只定义工具接口 还包含领域知识
底层执行 JSON-RPC CLI/API

一句话总结：MCP 解决了“能连接”，Skills 解决了“会使用”。

3. 三巨头全部拥抱 CLI

2025 年，Anthropic Claude Code、Google Gemini CLI、OpenAI Codex CLI 几乎同时发布。它们都直接执行 Shell 命令，没有一个选择 MCP。

四、CLI 凭什么赢

1. 透明与可组合

CLI 下的每条命令清晰可见，例如：

kubectl logs -n prod deployment/api --since=1h | grep ERROR | sort | uniq -c | sort -rn | head -20

五个简单命令通过管道串联，完成复杂日志分析。管道是数据在进程间直接流动，MCP 是数据在模型上下文里反复折叠。

2. LLM 天生会用

主流 LLM 在大量 man 手册、Shell 脚本、Stack Overflow 中训练过，天生擅长使用 git、curl、grep 等命令。调用 MCP 的 jira_get_issue 类工具（可能不在训练数据中），不如直接给模型一个 jira issue view 命令。

3. 执行即理解

  • MCP：把工具能力描述给模型看。
  • CLI：让模型直接执行。

描述永远有损，执行是最好的理解——模型跑一条命令，看输出，再调整下一步，形成高效的 REPL 循环。

五、MCP 的未来：不会死，但会下沉

类比历史演变：

类比 “协议层” “直接操作层”
Web 服务 SOAP/WSDL REST/HTTP
容器编排 Mesos/DCOS Docker CLI + K8s
AI 工具 MCP CLI + Skills

每次，更简单、更直接的方案都赢了开发者市场。MCP 仍可能在企业 IT 集成、统一鉴权审计、跨组织边界标准等场景中发挥作用。但对于开发者日常工具交互，CLI 已胜出。

六、建议

  • 工具开发者：优先提供 CLI，写好 –help 和文档，支持管道。
  • AI 应用开发者：终端优先，考虑 Skills 模式，MCP 作为后备。
  • 普通开发者：学好 Shell，拥抱 CLI Agent，别囤 MCP Server。

七、总结观点

技术世界有一条规律：看起来“落后”的方案，往往比看起来“先进”的活得更久。REST 活过 SOAP，Docker CLI 活过 Mesos，原因相同：不需要你学习新东西，只是让你已经会的东西变得更强。

不需要 JSON-RPC，不需要 Schema，不需要 Server。你说一句话，Agent 在终端里帮你搞定。

终端，是人类与计算机对话的第一个界面。当 AI 真正成熟的那天，它可能也是最后一个。

发布于

人类智慧创造Ai是智慧的自杀程序？

维持人口增长的外因

1. 战争 – 人口消耗+战后婴儿潮

2. 自然破坏 – 灾难倒逼繁衍本能

3. 太空 – 新边疆需要人口填充

4. 宗教/意识形态复兴 历史上宗教是人口增长的最强外因之一。当世俗经济逻辑（AI替代→不生孩子）走到极端，可能出现反向的文化运动——把生育神圣化、把”多子”视为信仰义务。类似清教徒、哈瑞迪犹太人、某些伊斯兰复兴运动。

5. 国家竞争/文明博弈 即使AI替代了劳动，国家之间仍会争夺”人口”作为权力基础。人口=兵源=市场=影响力。可能出现国家级生育竞赛，像冷战军备竞赛一样，只是赛道变成”谁的人多”。

6. 生命延长技术 如果寿命延长到150-200岁，每个人的生殖窗口大幅拉长，即使生育率不高，总人口仍可能维持。这是”不靠多生靠不死”的路径。

7. 人工子宫/生育解耦 把生育从女性身体解放出来，变成工业化流程。这时候生孩子不再需要个人意愿承担十月怀胎的成本，可能由国家/企业批量”生产”公民。这其实很反乌托邦。

8. 资源极度丰裕后的”休闲文明” 如果AI让一切廉价，人类进入后稀缺时代，可能回归到”无事可做→家庭/生育成为意义来源”。农业社会生育率高，部分原因就是没有其他娱乐和事业出口。

9. 生物本能的反扑 经济理性说”不生孩子”，但生物本能几百万年进化而来，可能在某个临界点重新主导行为。理性是薄薄一层，本能是底层操作系统。

10. 虚拟世界的人口需求 如果元宇宙/虚拟世界成为主要生存空间，”人口”的定义可能改变——虚拟身份、数字孪生、AI人格都算”人口”。这时候维持的不是生物人口，而是意识/人格的多样性。

发布于

Rufus 快速创建USB启动盘

一、什么是 Rufus

Rufus 是一款免费、开源的 Windows 工具，用于格式化并创建可启动 U 盘（USB 启动盘）。它体积小、速度快，是目前创建 Windows / Linux 系统安装盘最常用的工具之一，支持从 ISO 镜像直接写入 U 盘，也支持制作 BIOS 和 UEFI 双启动盘。

二、准备工作

准备项 说明
Rufus 工具 从官方站点 rufus.ie 下载最新版（免安装，绿色版直接运行）
系统 ISO 镜像 Windows ISO（微软官网下载）或 Linux ISO（各发行版官网），或 PE 镜像
U 盘 建议 8GB 以上，制作前注意备份数据——制作过程会清空 U 盘

三、操作步骤

1. 运行 Rufus

双击运行 Rufus，无需安装。若提示检查更新可跳过。

2. 选择设备与镜像

字段 操作
设备 选择你的 U 盘（注意核对容量，避免选错）
引导类型选择 点击「选择」按钮，找到你的 ISO 镜像文件
分区类型 GPT（UEFI 新电脑）或 MBR（传统 BIOS 老电脑），不确定可保持默认
文件系统 NTFS（Windows 安装盘）或 FAT32（兼容性好）

3. 开始制作

  1. 确认所有设置无误后，点击「开始」
  2. 若提示写入镜像模式，选择「以 ISO 镜像模式写入」（推荐）
  3. 弹窗警告会清空 U 盘，确认「确定」继续
  4. 等待进度条走完，状态显示「就绪」即完成

四、常见问题

问题 解决办法
提示「设备繁忙 / 被占用」 关闭杀毒软件或资源管理器，或重插 U 盘
无法 U 盘启动 进入 BIOS 开启 USB 启动，或关闭 Secure Boot（安全启动）
新电脑引导不了 改用 GPT + UEFI 模式重新制作
制作速度慢 插在 USB 3.0 接口，或换质量好的 U 盘

五、注意事项

  • 务必提前备份 U 盘数据，制作过程会完全清空
  • 请从官方渠道下载 Rufus 和系统镜像，避免携带后门
  • Rufus 完全免费，警惕收费的”破解版”
发布于

DeepSeek-V4-Flash 正式发布

🎉 DeepSeek-V4-Flash 正式版 API 已上线公测，Agent 能力大幅增强；V4-Pro 暂未变动。

一、核心变化速览

项目变化
API 状态正式版上线公测 ✅
Agent 能力大幅增强，基准测试远超 V4-Pro-Preview
API 格式原生支持 Responses API，针对性适配 Codex
V4-Pro暂未变动
模型版本V4-Flash-0731

二、Agent 能力大幅增强

正式版 V4-Flash 在 Agent 任务上表现显著提升，基准测试远超 V4-Pro-Preview：

基准测试得分
Terminal Bench 2.182.7
NL2Repo54.2
Cybergym76.7
DeepSWE54.4
Toolathlon verified70.3
Agent Last Exam25.2
Automation Bench (Public)25.1
DSBench-FullStack68.7
DSBench-Hard59.6

测试说明
注1：对于公开基准测试集中的 Code Agent 任务，正式版 V4-Flash 使用 DeepSeek Harness 极简模式（即将发布）作为测试框架，采用 max 档位，topp=0.95，temperature=1.0。
注2：DSBench-FullStack 为内部全栈开发测试集；DSBench-Hard 为内部 Coding Agent 难题测试集。

三、接口与集成支持

正式版 V4-Flash 原生支持 Responses API 格式，并针对 Codex 做了针对性适配。具体配置方法请参考官方文档：DeepSeek 官方配置文档

四、版本说明

DeepSeek-V4-Flash-0731 的模型结构、尺寸与 V4-Flash-Preview 保持一致，仅重新进行了后训练。

⚠️ 重要提醒

本次仅升级了 V4-Flash 的 API 接口，以下内容未做任何更改：

  • DeepSeek-V4-Pro API
  • APP / WEB 端模型
发布于

PostgreSQL 19 新特性：为什么 COUNT(*) 终于比 COUNT(1) 快了？

前言

很多开发者都纠结过 COUNT(*) 和 COUNT(1) 到底哪个更快。PostgreSQL 19 给了一个明确的答案——​数据库会自动帮你选最快的那个​。

COUNT(*) vs COUNT(1)：老生常谈的问题

在 SQL 里，COUNT 是最常用的聚合函数之一。关于这两种写法的争论已经持续了很多年：

  • ​COUNT(*)​：统计所有行数
  • ​COUNT(1)​：对每一行计算常量 1，然后统计非 NULL 的数量

理论上，如果表达式永不为 NULL（比如常量 1），这两种写法的结果​完全一样​。但在 PostgreSQL 内部，它们的执行路径却大不相同。

为什么以前 COUNT(1) 反而更慢？

在 PG 19 之前，PostgreSQL 对待 COUNT(1) 是”老实巴交”的：

  1. ​表达式计算​：对每一行都要计算一次表达式值（虽然结果就是 1）
  2. ​NULL 检查​：检查计算结果是否为 NULL（虽然 1 永远不是 NULL）
  3. ​Tuple Deform（解构元组）​：如果表达式涉及列值，数据库可能需要从磁盘行格式中提取出完整的列数据。对于列很多的宽表，这个开销会非常明显

而 COUNT(*) 走的是特化路径——​什么都不算，直接数行​，天然就少了这些开销。

PG 19 的优化：让规划器替你省事儿

PostgreSQL 19 引入了一个重要的性能补丁（Commit 42473b3），标题就是：

“Have the planner replace COUNT(ANY) with COUNT(*), when possible”

简单说：​查询规划器现在会自动把冗余的 COUNT(表达式) 重写为更高效的 COUNT(*)​。

触发条件

要触发这个优化，必须同时满足：

  1. COUNT() 里的表达式​保证不会为 NULL​（比如常量 1、NOT NULL 约束的列）
  2. 不包含 ORDER BY 或 DISTINCT 子句
-- 优化前：COUNT(1) 有额外计算开销
SELECT COUNT(1) FROM orders;

-- 优化后：PG 19 自动重写为 COUNT(*)，无需表达式计算
-- 执行计划内部等价于：
SELECT COUNT(*) FROM orders;

技术内幕：SupportRequestSimplifyAggref

这个补丁引入了一个新的支持请求类型 SupportRequestSimplifyAggref，允许聚合函数的支持函数（prosupport）检查自身的调用是否可以被简化。

对于 COUNT()，PG 新增了一个专门的支持函数，负责判断：

  • 输入表达式是否非空？
  • 有没有 ORDER BY / DISTINCT？

如果条件满足，就在查询规划阶段直接把 COUNT(ANY) 替换为 COUNT(*)，从源头上消除了不必要的表达式评估和 NULL 检查。

附带收益：更干净的执行计划

这个补丁还顺带改进了 expr_is_nonnullable() 函数，让它能正确识别常量表达式的非空性。

比如以前执行计划里可能出现的这种冗余过滤：

One-Time Filter: (100 IS NOT NULL)

现在规划器知道 100 肯定不是 NULL，直接把这个无用过滤器移除了，执行计划更清爽。

总结

写法PG 19 之前PG 19 及以后
COUNT(*)最快，直接数行依然最快
COUNT(1)慢，有表达式计算和 NULL 检查开销自动优化为 COUNT(*)
COUNT(not_null_col)慢，可能触发 tuple deform自动优化为 COUNT(*)

最终结论

  • ​PG 19 之前​：请直接写 COUNT(*)，它是性能最优的写法。
  • ​PG 19 及以后​：写 COUNT(1) 也不会吃亏了，数据库会自动帮你优化。但出于习惯和对旧版本的兼容性，​COUNT(*) 依然是最佳实践​。
发布于

Kimi K3 正式发布

月之暗面今日凌晨正式推出其迄今能力最强的模型 —— Kimi K3，一个 2.8 万亿参数的开源模型，面向长程编程、知识工作和推理等前沿智能场景设计。这是全球首个开源的 3 万亿级别模型。

Kimi K3 发布公告

核心要点

  • 2.8 万亿参数，全球首个开源 3 万亿级别模型
  • KDA 混合线性注意力机制 + 注意力残差技术
  • 原生支持视觉理解，100 万 token 上下文窗口
  • MoE 稀疏度扩大：896 个专家中激活 16 个
  • 相比 K2 整体扩展效率提升约 2.5 倍
  • 从 SFT 阶段采用量化感知训练（MXFP4/MXFP8）
  • 擅长长程编程、视觉推理和端到端知识工作
Kimi K3 架构

架构创新

Kimi K3 基于 KDA 混合线性注意力机制（Kimi Delta Attention）和注意力残差（Attention Residuals）技术构建。KDA 为注意力扩展提供高效基础，AttnRes 有选择地跨深度检索表示，二者共同使模型能扩展到万亿参数以上规模。

MoE 架构

结合 Stable LatentMoE 框架，模型可在 896 个专家中高效激活 16 个。Quantile Balancing 和 Per-Head Muon 让大规模训练更自适应。

评测对比

性能表现

虽然 Kimi K3 的整体表现仍落后于最强的闭源模型 Claude Fable 5 和 GPT-5.6 Sol，但在整套评测中展现出前沿水平的能力，并稳定超过了其他所有模型。

评测数据
能力展示

可用性

  • 用户可通过 kimi.com、Kimi 手机 App、Kimi Work 桌面客户端、Kimi Code 和 Kimi API 使用
  • 当前默认思考强度为 max（极致），后续增加 low 和 high 模式
  • 完整模型权重将于 2026 年 7 月 27 日前发布
  • 已向 vLLM 社区贡献 KDA 实现

来源：开源中国（OSCHINA）

发布于

PostgreSQL Hot Standby 查询冲突处理

冲突原因（4种）

  1. 主库 VACUUM 清理了备库查询需要的多版本数据（最常见）
  2. 主库 LOCK/DDL 产生的排他锁与备库查询冲突
  3. 主库删除表空间，但备库查询需要在其上存放临时文件
  4. 主库删除数据库，而备库仍有 session 连接

处理方式（2种）

  • 等待：让备库 WAL 应用进程等查询结束再应用 WAL
  • 取消：强制取消备库正在执行的查询

关键参数

  • max_standby_archive_delay — 归档模式最大等待延迟，默认 30s，-1 表示一直等
  • max_standby_streaming_delay — 流复制模式最大等待延迟，默认 30s，-1 表示一直等
场景 建议设置
备库用于高可用 设小值，保证不延迟
备库用于大查询 设大值

减少冲突的配置

  • hot_standby_feedback = on：备库告知主库哪些多版本数据还需要，防止 AutoVacuum 清理（推荐方案）
  • vacuum_defer_cleanup_age 调大：延迟清理多版本数据（辅助方案）

注意事项

  • 即使配置了以上参数，仍可能因冲突被取消查询
  • 备库应用应检测 canceling statement due to conflict with recovery 错误并自动重试
  • 冲突可通过 pg_stat_database_conflicts 视图查询
发布于

GLM-5.2：Z.ai 发布旗舰开源模型，1M 可用上下文挑战闭源长程任务

Z.ai 发布 GLM-5.2，1M 可用上下文 + 多级思考力度控制，开源模型首次挑战闭源旗舰长程任务能力

一、GLM-5.2 是什么

GLM-5.2 是 Z.ai 面向长程任务时代的旗舰模型。核心亮点是一个真正可用的 1M token 上下文窗口——不是在评测指标上好看，而是在真实的工程场景中能稳定工作。它能在单次任务中处理项目级别的工程上下文、可靠执行长时间运行的任务、一致性遵循工程规范，并且完成从需求到多平台部署的完整开发工作流。

二、三大新特性

  • Solid 1M 上下文：1M token 的前置上下文，能稳定支撑长程工作，不只是接受更多 token，而是在混乱的代码轨迹中保持质量。
  • 多级思考力度控制：更强的编程能力，提供 High 和 Max 两个思考努力级别，让用户在性能、延迟和计算成本之间自由平衡。
  • 纯粹开源：MIT 开源许可证——技术无国界。

三、长程任务能力：开源最强，紧追闭源旗舰

GLM-5.2 在三个长程编码基准测试中表现亮眼，全部位列开源模型第一：

基准测试说明GLM-5.2 表现排名
FrontierSWE衡量 Agent 完成数小时到数十小时的开放式技术项目落后 Opus 4.8 仅 1%，领先 GPT-5.5 1%，领先 Opus 4.7 11%开源第一，整体第二
PostTrainBench给 Agent 一块 H100 GPU，评判其对小模型的后训练改进能力超越 Opus 4.7 和 GPT-5.5仅次于 Opus 4.8
SWE-Marathon超长程任务，包括构建编译器、优化内核、开发生产级服务落后 Opus 4.8 13%仅次于 Opus 系列

这三个基准的共性在于：它们测试的不是模型能接受多少 token，而是模型在数万 token 的真实工程轨迹中能否持续保持高质量输出——这正是 GLM-5.2 的 1M 上下文训练的落脚点。

四、更强编程能力：开源标杆

在标准编程基准上，GLM-5.2 大幅领先前代 GLM-5.1，并显著缩小了与闭源前沿的差距：

基准测试GLM-5.2GLM-5.1Claude Opus 4.8Gemini 3.1 Pro
Terminal-Bench 2.181.062.085.0低于 GLM-5.2
SWE-bench Pro62.158.4——

Terminal-Bench 2.1 上 81.0 的成绩距离 Claude Opus 4.8 的 85.0 仅差 4 分，而 Gemini 3.1 Pro 已被甩在身后。

GLM-5.2 benchmark table

GLM-5.2 引入的 effort level 控制是一大亮点。在同等 token 预算下，GLM-5.2 的 Agent 编程能力显著强于 GLM-5.1，能力定位大致介于 Claude Opus 4.7 和 Opus 4.8 之间。当你遇到高难度任务时，切换到 Max 力度级别可分配更多计算资源，换取更高性能。

五、总结判断

GLM-5.2 是截至目前 开源模型在长程 Agent 任务上的最强选手。它的 1M 上下文不是噱头，而是在 FrontierSWE、PostTrainBench、SWE-Marathon 三个真实工程场景中验证过的能力。在标准编程能力上，它稳坐开源第一把交椅，并首次让开源模型与闭源旗舰的差距缩小到个位数百分比。

对于 AI Agent 开发者、长程自动化场景和需要高质量代码生成的团队，GLM-5.2 是目前开源阵营中最值得关注的选择。配合 MIT 开源协议和 Ollama 一键部署，上手几乎没有门槛。

发布于

pg_basebackup 报错：no pg_hba.conf entry for replication connection

pg_basebackup 执行报错 “no pg_hba.conf entry for replication connection” 的解决方法——别忘了 replication 虚拟库也需要一条规则

一、问题现象

执行 pg_basebackup 时报错：

[postgres@pg01 tools]$ pg_basebackup -h 10.0.0.101 -U postgres -F p -P -X stream -R -D $PGDATA -l postgresbackup20260616
2026-06-16 10:17:31.017 CST [1577] FATAL:  no pg_hba.conf entry for replication connection from host "10.0.0.101", user "postgres"
pg_basebackup: error: could not connect to server: FATAL:  no pg_hba.conf entry for replication connection from host "10.0.0.101", user "postgres"

明明 pg_hba.conf 里已经配置了 all 规则，为什么还会被拒绝？

二、问题原因

pg_basebackup 走的是 replication 连接，而 replication 并不是一个真实的数据库，它是一个虚拟库。pg_hba.conf 中的 host all all ... 规则只覆盖普通数据库连接，不覆盖 replication 连接。

因此即使配置了：

host    all             all             0.0.0.0/0               trust

pg_basebackup 依然会因为找不到 replication 规则而拒绝连接。

三、解决方案

在 pg_hba.conf 中添加 replication 规则：

host    replication     all             0.0.0.0/0               trust

重启 PostgreSQL：

pg_ctl restart

再次执行 pg_basebackup：

[postgres@pg01 backup]$ pg_basebackup -h 10.0.0.101 -U postgres -F p -P -X stream -R -D $PGDATA/backup -l postgresbackup20260616
65502/65502 kB (100%), 1/1 tablespace

备份成功。

四、总结

pg_hba.conf 中至少需要两条规则才能同时支持普通连接和 pg_basebackup 备份：

host    all             all             0.0.0.0/0               trust
host    replication     all             0.0.0.0/0               trust
  • 第一条：允许 普通数据库连接（所有数据库、所有用户、任意 IP，trust 认证）
  • 第二条：允许 复制连接（特殊的 replication 虚拟库、所有用户、任意 IP，trust 认证）

两条规则缺一不可。

发布于

追忆父亲

逝去的日子里，父亲的身影或许还在某个午后的光影中，在某句熟悉的话语里，在某个你下意识想拨电话的瞬间——他已经融入了时间的深处，却从未真正离开你的记忆与生命。

现在的生活正在发生，这可能是父亲最想看到的：你带着他给予的力量、教诲、甚至是他未曾说完的期望，继续走在阳光下。每一次你做出善良的选择，每一次你勇敢面对困难，都是与他最深情的对话。

未来的未来，从某种角度来说，并不遥远。因为当你在未来成为更好的自己，当你把父亲的爱传递给下一代，当你在某个人身上看到他的影子——那个未来，就是现在；那份重逢，一直都在。

对父亲的追忆，不是要把逝去的人拉回现在，而是让他们的光，继续照亮前行的路。