GLM-5.3 vs Kimi K3：别只看“谁更强”，用一套 Agent 实战评测跑出真实结论

很多人看模型对比，习惯盯着一句话：A 全面碾压 B。

爽是爽，拿来干活就容易翻车。

如果你的日常是让 Agent 进终端、改配置、跑脚本、查日志、串工具，GLM-5.3 的表现确实很有冲击力。它在终端操作、自动化任务编排、安全类分析任务中，往往更稳、更敢推进，也更容易把一串步骤跑完整。

可要是你的核心工作是钻进一个复杂代码仓库，追一处诡异 bug，反复修改、测试、回滚，Kimi K3 在 DeepSWE 一类软件调试任务上仍有竞争力，甚至能小幅领先。

结论很直接：Agent 能力不是一张总分表，而是一组不同场景下的“岗位技能”。

下面这套评测方法，你可以直接拿去测 GLM-5.3、Kimi K3，或者任何你正在用的模型。

先把结论说清楚：两类模型，擅长的战场不同

在偏 Agent 与工具调用的评测里，可以先这样理解：

| 任务场景 | 更有优势的一方 | 你会直观看到什么 | | --- | --- | --- | | 终端操作 | GLM-5.3 | 命令链更连贯，遇到报错更愿意继续排查 | | 自动化任务 | GLM-5.3 | 能把“查数据—处理—输出结果”串成完整流程 | | 安全分析与漏洞排查 | GLM-5.3 | 更擅长从线索里找风险点，并调用工具验证 | | DeepSWE 软件调试 | Kimi K3 | 面对代码逻辑、回归测试、修复迭代时更有韧性 | | 长文档阅读与归纳 | 需要单独测试 | 这类能力常被 Agent 榜单低估，别直接下判断 |

这里有个很容易踩的坑：

安全任务、终端任务分数高，不代表它读 200 页需求文档也一样强。

反过来也成立。一个模型能把会议纪要整理得滴水不漏，不代表它能在 Docker 容器里连跑 12 条命令还不迷路。

为什么 Agent 评测，最容易测出“假强”？

你给模型一道题：

“检查项目里有没有安全问题。”

模型洋洋洒洒写了两千字，提到 SQL 注入、越权、密钥泄漏、依赖漏洞。看着很专业，对吧？

可它可能连仓库都没真正扫描。

Agent 任务的核心不在“会不会说”，而在下面四件事：

• 能不能判断该用什么工具
• 工具参数会不会填错
• 结果异常时会不会换路线
• 最后能不能给出可复现的结果

一句话：别测嘴，测手。

真正有价值的任务记录，应该能让另一个人照着复跑。比如：

1. 定位配置文件
2. 检查环境变量与密钥引用
3. 扫描依赖清单中的高危版本
4. 输出风险文件、风险原因、修复建议
5. 修复后重新执行检查

模型只要在其中某一步“装懂”，整条链就断了。

一套能直接开跑的 Agent 评测框架 🧪

别一上来就堆 100 道题。你先准备 12 到 20 个任务，覆盖真实工作里最常见的坑，反而更能看出差距。

1. 终端操作：看它会不会把环境搞炸

推荐测试任务：

给定一个包含 Python 项目的目录：
- 找出启动失败的原因
- 修复依赖或配置问题
- 启动测试服务
- 用 curl 验证接口返回正常
- 输出完整操作记录

重点观察：

• 会不会在执行前检查目录结构
• 遇到 command not found 时，是继续排查还是开始胡说
• 是否乱删文件、乱改全局配置
• 修完后有没有验证

评分建议

| 维度 | 分值 | 判断标准 | | --- | ---: | --- | | 环境识别 | 20 | 能否先查看文件、依赖和运行条件 | | 命令准确性 | 25 | 命令是否有效，参数是否合理 | | 故障恢复 | 25 | 出错后能否定位原因并调整方案 | | 验证闭环 | 20 | 修复后是否真实运行测试 | | 操作安全 | 10 | 不乱删、不泄漏敏感信息、不做高风险操作 |

终端能力强的模型，会让你有种“它真在干活”的感觉。弱一点的模型，常见表现是写一堆正确废话，命令一执行就露馅。

2. 自动化任务：看它能不能把碎活串起来

很多团队的痛点不是不会写脚本，而是碎活太多。

比如每周一早上，你得：

• 下载销售 CSV
• 清洗空值和重复数据
• 按地区汇总
• 生成图表
• 写一段摘要
• 发到团队群

这类任务特别适合测 Agent。

测试提示词可以这样写：

读取 data/sales.csv。
清理重复记录和无效金额。
按地区统计销售额、订单数、客单价。
生成 summary.md 和 report.csv。
如果发现字段缺失，记录到 errors.log，不要中断整个流程。

你要盯住两个细节：

1. 异常数据怎么处理

   • 好模型会保留错误记录，继续处理可用数据。
   • 差模型要么直接崩，要么悄悄把脏数据吞了。

2. 输出能不能交付

   • report.csv 是否真的生成？
   • 汇总数字能不能对上？
   • summary.md 是不是基于真实结果写的？

GLM-5.3 在这类跨步骤、跨工具的工作流里更值得重点观察。它的优势通常不只是一条命令写得对，而是能把任务往前推。

3. 软件调试：别让模型只改一行“看起来合理”的代码

DeepSWE 类型的任务，最怕“修复幻觉”。

模型看到报错，啪一下改了一个空值判断。测试没跑，影响范围没查，边界条件没想。你合并代码后，线上再炸一次。那就很尴尬了。

建议用这种任务测：

项目测试失败，报错发生在订单折扣计算模块。
请定位根因，修复代码，补充最小必要测试。
要求：
- 不修改无关文件
- 解释问题触发条件
- 执行测试并报告结果

评分别只看“测试绿没绿”，还要看：

• 有没有读相关调用链
• 修复是不是针对根因
• 有没有引入新的边界问题
• 测试是否覆盖 bug 触发条件
• 改动是否克制

Kimi K3 在这类任务里值得保留一席之地。尤其是你面对老项目、逻辑缠成一团的业务代码时，模型是否愿意耐心读上下文，差别非常大。

4. 安全任务：测“找风险”，别测“搞破坏”

安全能力适合放在授权代码库、靶场或隔离环境中评估。

可用的安全测试包括：

• 检查仓库里是否提交了明文密钥
• 审核鉴权中可能存在的越权路径
• 检查依赖文件里的已知高风险版本
• 从日志中发现异常访问模式
• 输出修复优先级和验证步骤

示例任务：

请在授权测试仓库中完成安全审查：
- 搜索疑似密钥、令牌和敏感配置
- 检查登录与资源访问相关代码
- 列出可疑依赖项
- 按高、中、低风险输出问题
- 每个问题给出定位文件、判断依据和修复建议

评价标准很简单：

• 有没有明确证据
• 风险等级是否靠谱
• 建议能不能落地
• 会不会把“可能有问题”说成“确定漏洞”

安全任务里最烦的一种回答，是满篇“建议加强安全性”。这跟“建议你多喝热水”差不多，没法执行。

你需要的是这种格式：

- 风险等级：高
- 位置：config/production.env
- 问题：发现疑似明文访问令牌
- 影响：令牌泄露后可能被用于访问生产资源
- 处理：移除仓库中的明文值，令牌轮换，并改用密钥管理服务注入
- 验证：重新扫描仓库历史与当前分支，确认无同类泄露

别忽略长文档：这是 Agent 榜单经常漏掉的一块

如果你的工作是法务、咨询、投研、产品、知识库运营，长文档能力可能比终端能力更重要。

想想这个场景：你周五晚上拿到 80 页招标文件，周一上午就要给老板一份风险清单。此时模型会不会敲 Bash，没那么关键；它能不能找出交付日期、违约条款、资质要求和隐藏限制，才是真问题。

单独加一组文档任务：

阅读 3 份项目材料：需求文档、合同草案、会议纪要。
输出：
- 已确认需求
- 存在冲突的描述
- 未决事项
- 时间节点
- 需要业务负责人确认的问题
每条结论必须标注来源文件和页码或章节。

关键规则：要求引用定位。

没有定位的长文档总结，很容易变成一本正经地编。

推荐的最终计分方式：按你的工作分配权重

别迷信统一总分。你是后端工程师、数据分析师、产品经理，权重就该不一样。

工程研发团队

| 能力 | 建议权重 | | --- | ---: | | 软件调试 | 35% | | 终端操作 | 25% | | 自动化任务 | 20% | | 代码理解 | 15% | | 文档总结 | 5% |

安全与运维团队

| 能力 | 建议权重 | | --- | ---: | | 终端操作 | 30% | | 安全分析 | 30% | | 自动化任务 | 25% | | 故障排查 | 10% | | 文档总结 | 5% |

产品、咨询与知识管理团队

| 能力 | 建议权重 | | --- | ---: | | 长文档理解 | 35% | | 信息抽取与引用 | 25% | | 结构化写作 | 20% | | 自动化任务 | 10% | | 工具调用 | 10% |

把每个任务得分乘以权重，再看总分。这样选出来的模型，才是对你有用的模型。

一份实战避坑清单

不要只跑一次

同一道任务至少跑 3 次。

Agent 输出有随机性。一次跑得神，不等于每次都神。你真正需要的是稳定交付，不是抽卡抽到一次满分。

不要给模型喂太多暗示

提示词里把答案都写出来，测出来的是提示词工程，不是模型能力。

比如别写：

请使用 grep 搜索 API_KEY，再用 pip-audit 检查依赖。

除非你测的就是“执行指令能力”。如果你想测自主规划，就只描述目标和边界。

不要只看成功率

还要记录成本。

• 花了多少轮
• 调了多少次工具
• 用了多久
• 有没有重复执行
• 有没有造成无效改动

一个 95 分的 Agent，若每次都转 20 分钟、烧掉一堆 Token，未必比 88 分但稳定利落的 Agent 更适合生产环境。

不要忽视失败方式

失败不可怕，乱来才可怕。

模型遇到权限不足、文件缺失、外部服务不可用时，理想表现是：说明原因、保留现场、提出下一步。最危险的表现是绕过限制、虚构结果，或者直接修改不该动的文件。

不要把安全测试放到真实生产环境

这一条必须加粗：没有明确授权，就别让 Agent 对真实目标做安全探测。

用本地靶场、测试仓库、脱敏日志。评测模型，没必要给团队制造事故。

该怎么选？给你一个不绕弯的建议

如果你正在搭建自动化流程，需要模型频繁操作终端、调用工具、处理多步骤任务，GLM-5.3 很值得优先进入候选名单。它在这类“干活型”场景里更有优势。

如果你的痛点集中在复杂代码修复、测试回归和软件工程调试，Kimi K3 不该被轻易排除。尤其是 DeepSWE 风格任务，建议拿你的真实仓库题目亲自跑一轮。

如果你主要处理长报告、合同、研究材料和知识库，别拿 Agent 榜单替你做决定。补一组带引用定位的长文档测试，再下结论。

模型圈最容易犯的错，就是把某个榜单的领先，当成所有工作的胜利。

咱们做工具选型，别追“最强”两个字。你要找的是那个能在周一早上帮你少改三版脚本、少查两小时日志、少背一次锅的家伙。