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 认证)

两条规则缺一不可。

追忆父亲

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

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

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

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