阅读时间 : 18 minutes

LLM 的战争也在开发者的终端中进行。而非在无用的学术基准上。真实场景:一个 30,000 token 的提示、AsciiDoc 中的智能体治理、需要调试的 Gradle Kotlin DSL 插件,以及持续三周的连续会话。我为您测试了 DeepSeek-V4-Pro、Kimi K2.6 和 GLM-5.1。以下是结论,并附有技术证据。

背景:不是试验台,而是施工现场

三周前,我正在从事`codebase-gradle`, 我的元构建系统集中管理四个项目的 YAML 配置:一个 PlantUML README 生成器,一个 AsciiDoc 幻灯片构建器,一个静态 JBake 网站和一个 LLM 聊天机器人。Opencode 代理受我基于 AsciiDoc 的代理文件方法论管控,在每次会话开始时加载约 30K 个 EAGER 上下文 token——绝对规则、待办事项列表以及最近 10 次会话的历史。

我在这块土地上面对了三种模型:

  • Kimi K2.6(Moonshot AI, 1T 参数 / 32B 已激活, 256K 最大上下文, MLA) - GLM-5.1(智谱 AI/Tsinghua, 744B 参数 / DSA, 200K 上下文最大) - **(DeepSeek, 1.6T 参数 / 49B 已激活, 1M 上下文 最大, CSA+HCA)

全部通过 Ollama 在云服务器上运行,全部处于 thinking 模式(已激活思考阶段)。挑战:生成正确的代码,在长会话中保持一致性,并且在上下文超过 80K tokens 时不产生幻觉。

我的测试环境

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 220

title 测试环境 — Opencode 会话 × 3 LLMs
left to right direction

package "🖥️ 开发者终端" #E8F5E9 {
  rectangle "AGENT.adoc\n(规则,待办事项)" as AG
  rectangle "PROMPT_REPRISE\n(任务)" as PR
  rectangle "INDEX.adoc\n(路线图)" as IDX
}

package "☁️ Ollama 云" #BBDEFB {
  rectangle "DeepSeek-V4-Pro\n1.6T / CSA+HCA" as DV4
  rectangle "Kimi K2.6\n1T / MLA" as KIMI
  rectangle "GLM-5.1\n744B / MLA+DSA" as GLMG
}

package "⚙️ 代码库 Gradle" #FFF9C4 {
  folder "buildSrc/" {
    file "codebase.kt"
    file "readme.kt"
    file "site.kt"
    file "slider.kt"
    file "snapshot.kt"
  }
  file "build.gradle.kts\n(947 行)"
  file "embeds.yml"
}

AG --> DV4 : Sessions 1-8 ✅
AG --> KIMI : 第9-10节 ⚠️
AG --> GLMG : 第11-13节 ⚠️

DV4 --> "代码库" : "TDD, 重构,\n快照"
KIMI --> "代码库" : "降级\n自 60K 令牌"

note bottom of GLMG
比 Kimi 更好
但延迟更高
DSA 稳健性较差
比 CSA+HCA
end note

@enduml

每个会话开始时大约有30K个EAGER上下文标记:AGENT.adoc(287 行)PROMPT_REPRISE.adoc(51 行),.agents/INDEX.adoc(218 行)LAZY_EAGER_ESSENTIALS.adoc(50行)。上下文随着交流快速增长 — 典型的10条消息会话会向累积提示添加15-20K tokens。

评估表格

我对每个模型在四个关键维度上进行了评估,以辅助软件开发:

轴 具体标准

长上下文一致性

代理人记得40条消息前决定的惯例吗?

生产代码的质量

代码能一次编译通过吗? 它是否遵循现有的模式?

建筑推理

代理人能否在我不必向其重新解释的情况下理解模块之间的关系?

抗幻觉

从多少个 token 开始,代理会开始编造不存在的 API 或类?

以及一个内部合成指标:恢复系数(我花在纠正代理上的时间,而不是与之共同编码的时间。)

第1轮:Kimi K2.6 — 虚假起步

Kimi K2.6 是我的首选。它在 SWE-Bench Verified (80.2) 和 Terminal-Bench 2.0 (66.7) 上的基准表现出色。其 MLA 架构承诺在长序列上具有良好的效率。

第9节:改善

与 Kimi 的第一次会话。任务:实现该方法`resolveActiveKey()在`codebase.kt— 一个带有 CLI 回退的 API 密钥解析函数。上下文为 30K tokens,Kimi 推理迅速,生成干净的代码,具备密钥过期管理。

fun resolveActiveKey(
    cfg: CodebaseConfiguration,
    logger: Logger,
    cliProvider: String? = null,
    cliAccount: String? = null,
    cliKey: String? = null
): NamedApiKey? {
    // Résolution provider → compte → clé avec CLI override
    // Kimi a parfaitement compris la chaîne de priorité
}

代码编译通过。7 个测试用例通过。我乐观。

第10节:沉默的沉船

第二个会话。随着交流,上下文增长到约90K tokens。我要求 Kimi 添加一个 AsciiDoc 快照机制,在写入之前对秘密进行匿名处理。

这就是事情开始出错的地方。Kimi开始发明不存在的类。他向我提出`AnonymizedObjectMapper`— 一个虚构的类。他混淆`ReadmeYmlAnonymizer` et CodebaseYmlAnonymizer. 他建议我导入`com.fasterxml.jackson.anonymize.*`— 一个从未存在过的软件包。

更糟:在他反思的阶段,我看到他在错误的前提上构建推理。他“记得”GitConfig`有一个字段`anonymizedToken— 不,这是`resolvedToken(). 他把…​归因于`SiteYmlAnonymizer`一种方法`maskSupabaseCredentials()— 不存在的.

__ 这不是一个错误。这是连贯性的逐渐溶解。就像每个添加到上下文中的 token 都稍微稀释了前 30,000 个 token 的记忆。 (Empty output)

我在两次会话后停止了 Kimi。诊断很明确:MLA 在压缩 KV cache 方面表现良好,但如果没有细粒度的稀疏选择机制,注意力就会在超过 60K tokens 时机械地稀释。每个 token 对远距离上下文的“看到”程度越来越差,然后开始用噪声填补空白。

第 2 轮 : GLM-5.1 — 荣誉战士

GLM-5.1 采用不同的架构:MLA 用于基础模型,随后进行 continued pre-training,使用 DSA(DeepSeek Sparse Attention)——一个轻量级索引器,能够动态从全部历史中挑选出相关的前 2048 个 token。

架构:DSA 对抗纯 MLA

差异是根本的。正如 Kimi 将历史压缩到一个唯一的潜在空间中(并逐渐丧失区分相关信息的能力),GLM 添加了一个后训练的索引器,进行显式的稀疏选择。

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title 注意力架构 — MLA vs MLA+DSA
left to right direction

rectangle "Kimi K2.6 — MLA纯" as MLA #FFCDD2 {
  rectangle "KV Cache\n完整" as KV1
  rectangle "Compression\n潜在" as CL1
  rectangle "解码\n在潜在空间" as DL1
  KV1 --> CL1
  CL1 --> DL1
  note bottom of DL1
⚠️ 超过 60K 个 token 后 : 判别能力下降
  end note
}

rectangle "**GLM-5.1 — MLA + DSA**" as DSA #C8E6C9 {
  rectangle "KV Cache\n完整" as KV2
  rectangle "Compression\n潜在 (MLA)" as CL2
  rectangle "轻量索引器\n(DSA, top-k=2048)" as IL
  rectangle "解码\n在选定的tokens上" as DL2
  KV2 --> CL2
  CL2 --> IL
  IL --> DL2
  note bottom of DL2
    ✅ "固有无损"
    Sélection explicite
    des tokens pertinents
  end note
}

MLA --> DSA : "增益:稀疏选择\n避免稀释"

@enduml

技术报告明确指出:DSA 是 `lossless by construction` —— 与 SWA(模式搜索)、Gated DeltaNet 或 SimpleGDN 等替代方案不同,它们在 RULER@128K 上最高会损失 5.69 分。

第11至13场:扎实但令人沮丧

GLM-5.1 在保持距离方面表现更好。在会话 11(~60K tokens)中,它仍然保持连贯。它产生了一个`SnapshotManager`功能正常,正确管理四个匿名器。

但延迟是一个问题。DSA的反思阶段比纯MLA更重 — 索引器必须在每一步重新扫描历史记录。Kimi原本需要8秒的响应,在GLM下变成了15秒。在30条消息的会话中,这一点很明显。

然后还有细微的错误。GLM 不像 Kimi 一样胡言乱语 — 但它会出现 nommage 错误。它调用`toAnonymizedYaml()应该被称为的方法`anonymize(). 他反转`loadReadmeConfiguration()` et loadCodebaseConfiguration()`在`renderFileSection(). 这些不是幻觉,而是表面的混淆 — — 但在生产环境中,表面的混淆可能会破坏构建。

我与 GLM 进行了三次会话。它比 Kimi 更好,毫无疑问。但对命名细节进行三次人工修正会让人疲惫。

第3轮:DeepSeek-V4-Pro — 战争机器

DeepSeek-V4-Pro 搭载了三种架构中最雄心勃勃的架构:一种混合系统,结合了两种互补的注意力机制。

架构:CSA + HCA,双层网

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 180

title DeepSeek-V4-Pro — 混合架构 CSA + HCA
left to right direction

rectangle "KV Cache\n1M tokens" as KV #E3F2FD

rectangle "CSA\n压缩稀疏注意力" as CSA #C8E6C9 {
  rectangle "压缩\nm tokens → 1" as CC
  rectangle "稀疏注意力\n(DSA, top-k)" as SA
  CC --> SA

  note bottom of SA
局部注意力精细
+ 稀疏选择
  end note
}

rectangle "HCA\n高度压缩注意力" as HCA #BBDEFB {
  rectangle "极端压缩\nm' >> m → 1" as ECC
  rectangle "稠密注意力\n残差" as EDA
  ECC --> EDA

  note bottom of EDA
全局上下文 + 长距离连接
  end note
}

rectangle "融合\n混合" as FUSION #FFF9C4
rectangle "解码\n一致" as DEC #FFE0B2

KV --> CSA : 局部精度
KV --> HCA : 全局视野

CSA --> FUSION
HCA --> FUSION
FUSION --> DEC

@enduml

两个压缩层次,两个注意力粒度:

  • CSA: 压缩 KV 缓存所有的`m`tokens,然后应用稀疏注意力(DeepSeek Sparse Attention)——仅查询压缩输入的前 k 项。精准、局部、高效。 - HCA: 极端压缩(因子`m'`远大于`m`), 但在压缩残基上进行密集注意 — 保持全局连接而不出现二次爆炸。

结果:在 1M tokens 的情况下,DeepSeek-V4-Pro 仅消耗27% 的推理 FLOPs et KV 缓存大小的 10%相比 DeepSeek-V3.2。之前的模型。

尤其是,技术报告(图 9)宣布:"Retrieval performance remains highly stable within a 128K context window."

第1-8次会议:缓解

我与 DeepSeek-V4-Pro 进行了八次会话 在`codebase-gradle`.八次会话,没有一次幻觉,没有一次虚构的类别,没有一次命名混淆。

会话 1 : 实现`CodebaseYmlConfig` et CodebaseYmlAnonymizer. 350 行 Kotlin,内联测试,全部编译通过。第4课:添加`SnapshotManager`有 tree view, 文件收集, 每个文件的 AsciiDoc 渲染. 279 行, 零错误. 第 7 会话: 调试 du`renderFileSection()`它必须管理四种不同类型的匿名器,且没有解析歧义。用三条消息解决。

延迟比 Kimi 高——大约每次思考模式下的响应需要 10-12 秒。但纠错率几乎为零。我不花时间去修复代理的错误。我是与他一起编码。

决定性测试:100K token 的重构

在第8个会话,累积上下文超过100K tokens。我要求进行大规模重构:提取内联的四个验证任务`build.gradle.kts`向 JUnit5 测试文件内`buildSrc/src/test/`.

代理提出了一项三阶段计划:

  1. 创建带有现有用例迁移的测试类

  2. 添加 JUnit5 和 Kotest 依赖项在`buildSrc/build.gradle.kts`

  3. 删除内联代码的`build.gradle.kts`

计划是正确的。执行很干净。它甚至还指出了我漏掉的一个边界情况:Jackson 依赖项在之间重复`buildscript {}` et `buildSrc/build.gradle.kts`需要在迁移过程中统一的。

100K个令牌的上下文,并且代理记得`CodebaseYmlAnonymizer.TOKEN_MASK`是`"*"`, 的`GitConfig.resolvedToken()是在 …​ 中定义的扩展函数`readme.kt, 并且`SnapshotManager.PRUNED_DIRS`排除`build`, .gradle et .git.

这就是差别。

面对面:比较指标

标准 Kimi K2.6 GLM-5.1 (Empty)

最大上下文

256K

200千

1M

注意力机制

MLA 纯

MLA + DSA

CSA + HCA 混合

总参数

1T

744B

1.6T

已启用的参数

32B

未发布

49B

观测到的降级阈值

~60K tokens

~120K 标记

(Empty output)

超出行为

大规模幻觉

表面混淆

渐进的缓慢恶化

稳定性 NIAH

未发布

100% @128K (DSA)

稳定至 128K (图 9)

MRCR @128K

未发布

未发布

优于 Gemini 3.1 Pro

放弃之前进行的会议

2

3

8 (继续)

校正时间 / 编码时间

60%

30%

<5%

平均延迟(思考模式)

8 s

15 s

11 s

置信系数*

2/10

6/10

9/10

*信任系数 = 主观衡量我能够接受代理人的代码并提交而不逐行审阅的能力.

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title 比较雷达 — 3 LLMs 在辅助软件开发中
legend right
  |= Couleur |= Modèle |
  | <#FF5252> | Kimi K2.6 |
  | <#FFC107> | GLM-5.1 |
  | <#4CAF50> | DeepSeek-V4-Pro |
endlegend

rectangle " " as space #FFFFFF

rectangle "一致性\n80K+ tokens" as coh #F5F5F5
rectangle "质量\ncode" as qual #F5F5F5
rectangle "推理\narchitectural" as arch #F5F5F5
rectangle "抵抗\nhallucinations" as hall #F5F5F5
rectangle "速度\n(开发体验)" as speed #F5F5F5
rectangle "知识\nGradle/Kotlin" as kg #F5F5F5
rectangle "纠正率\ncorrection" as corr #F5F5F5

coh --> qual
qual --> arch
arch --> hall
hall --> speed
speed --> kg
kg --> corr

note top of coh
  Kimi      ████░░░░░░ 4/10
  GLM       ██████░░░░ 6/10
  DeepSeek  █████████░ 9/10
end note

note top of qual
Kimi      ███████░░░ 7/10 (低于60K)
GLM       ████████░░ 8/10
DeepSeek  █████████░ 9/10
end note

note top of arch
  Kimi      █████░░░░░ 5/10
  GLM       ███████░░░ 7/10
  DeepSeek  █████████░ 9/10
end note

note top of hall
  Kimi      ██████░░░░ 6/10 → ██░░░░░░░░ 2/10 (> 60K)
  GLM       ███████░░░ 7/10
  DeepSeek  █████████░ 9/10
end note

note top of speed
  Kimi      █████████░ 9/10
  GLM       ██████░░░░ 6/10
  DeepSeek  █████░░░░░ 5/10
end note

note top of kg
  Kimi      ███████░░░ 7/10
  GLM       ███████░░░ 7/10
  DeepSeek  █████████░ 9/10
end note

note top of corr
Kimi      ██░░░░░░░░ 2/10 (大量更正)
GLM       █████░░░░░ 5/10
DeepSeek  ██████████ 10/10 (几乎没有需要修改的地方)
end note

@enduml

为什么 DeepSeek-V4-Pro 在软件开发中获胜

DeepSeek-V4-Pro 的优势并非源于单一因素 — — 而是多种因素的汇聚:

1. CSA+HCA 架构专为代码而设计。

辅助软件开发是长上下文注意力的一个*极端*用例。您需要: - 本地精确度(这个类继承自什么?这个方法是在哪里定义的?) →CSA - 全局视野(为什么这个模块存在?四个匿名器如何交互?) →HCA

Kimi 仅凭 MLA 能够处理局部精度,但超过 60K 时会失去全局视角。GLM 配合 DSA 能提升全局视角,但仍然是单层级的。DeepSeek 明确地结合了两者。

2. EAGER上下文是它的舒适区

我的治理系统在启动时加载约30K tokens的规则和待办事项。在稳定窗口最高可达128K的情况下,DeepSeek拥有约100K tokens的余量用于会话交互。这相当于Kimi在不降级情况下能处理的3到4倍。

__ 128K的完美稳定窗口完全符合我的需求:30K的`EAGER`+70K的交换=一段高产的20-30条消息会话,永不离开绿色区域。 (Empty)

3. 质量/延迟比率对流来说是最佳的

是的,DeepSeek-V4-Pro 比 Kimi 慢(11秒 对 8秒)。但任务的 总 时间要低得多,因为我不花 20 分钟来纠正代理的幻觉。

开发者不会测量响应的延迟。他测量的是从 je pose la question 到 le code est dans mon repo et il fonctionne 之间的时间。在此指标上,DeepSeek-V4-Pro 是三者中最快的。

经验教训:如何为 Vibe Coding 选择 LLM

除了瞬时排名之外,这次经历让我学会了根据不在任何基准中的标准来评估用于辅助软件开发的LLM。

  1. 看看架构,而不是宣布的上下文大小一个宣称支持 256K 上下文但实际上只有 MLA 的模型最终会像 Kimi 一样:理论上可行,但在 60K 以外实际上不可用。

  2. 在您的上下文中进行测试,而不是在通用基准上— 我的初始提示为30K tokens的AsciiDoc,带有绝对规则和backlog,与HLE或AIME的问题无关。

  3. 如果质量能够跟上,延迟就不是敌人— 一个产生正确代码的慢模型比一个产生错误代码的快模型更快。

  4. 警惕没有公开的技术报告的模型— 如果团队没有记录其注意力架构,那就是因为他们对其在长上下文中的表现没有信心。

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 260

title 决策树 — 为辅助开发选择自己的 LLM
start

:初始上下文\n> 20K 标记 ?;

if (Oui) then
  :注意力\n混合或多层架构?;

  if (CSA+HCA) then
    :DeepSeek-V4-Pro
    Fenetre stable 128K
    Ideal pour gouvernance EAGER;
    stop
  elseif (MLA + DSA) then
    :GLM-5.1
    Correct jusqu'a ~120K
    Latence elevee;
    stop
  else (MLA seul)
    :Kimi K2.6 (sessions courtes)
    ou eviter pour long contexte
    Chercher un modele avec
    sparse attention;
    stop
  endif
else (Contexte < 20K)
  :N'importe lequel fonctionne.
  Privilegier la latence.;
  stop
endif

@enduml

而治理代理在这种情况中呢?

此经验验证了我自《Eager/Lazy 治理》一文以来一直坚持的观点:LLM的质量和治理的质量是乘法关系,不是加法关系。

使用 Kimi K2.6,我的治理非常完善 — 但模型稀释了信息。结果:完美治理 × 幻觉 = 零。

使用 DeepSeek-V4-Pro,EAGER 治理(30K 规则标记)+ LAZY(会话存档,技术参考)+ Hot/Warm/Cold(轮转备份)构成了一个生态系统,其中每一层都能放大另一层。代理人随时可以看到规则(EAGER),可以查看历史记录(LAZY),并且上下文永不会饱和(轮转备份)。

_ 一个没有治理的优秀LLM,就像一辆没有方向盘的法拉利引擎;一个没有优秀LLM的良好治理,就像一个没有引擎的方向盘。DeepSeek-V4-Pro + 我的代理治理 = 第一次我觉得自己在开车。 _

旋转备份机制(每10个会话或>500行 EAGER 轮换)在能够容纳128K上下文的模型中才真正发挥作用:10个活动会话的滑动窗口保持上下文新鲜,且永不超过退化区域。

技术来源

我将我的实证经验与官方技术报告进行交叉核对,以验证我的观察:

  1. DeepSeek-V4 Technical Report — PDF 检索自https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash[HuggingFace]. Figure 9 : "Retrieval performance remains highly stable within a 128K context window. While a performance degradation becomes visible beyond the 128K mark, the model’s retrieval capabilities at 1M tokens remain remarkably strong." CSA+HCA 架构在第 2.3 节中有文档说明。

  2. GLM-5 技术报告 —https://arxiv.org/abs/2602.15763[arXiv:2602.15763]. DSA 通过持续预训练引入,“按构造无损”。 最大上下文 202,752 个标记。 表格 3/5/6 记录了长上下文性能与替代方案(SWA、Gated DeltaNet、SimpleGDN)的对比。

  3. Kimi K2.6 模型卡 —https://huggingface.co/moonshotai/Kimi-K2.6[HuggingFace]. MLA,256K 最大上下文。 策略在阈值之外对代理任务采用 discard-all(这隐含地确认了 MLA 在长上下文中的实际限制)。

  4. Kimi K2 技术报告 —https://arxiv.org/abs/2507.20534[arXiv:2507.20534]. MoE 架构,MuonClip 优化器,智能体性能(HLE,BrowseComp,Terminal-Bench)。

最显著的一点:在他们自己的评估中,Moonshot 在超过上下文窗口时会采用 discard-all 策略(即丢弃旧上下文)。这正好印证了我的观察结果:单独的 MLA 无法在整个 256K 上下文窗口中保持一致性。架构无法跟上。

结论:工匠的选择

经过三周和十三次实际开发会话后,裁决毫无争议:

Kimi K2.6 GLM-5.1 DeepSeek-V4-Pro

优秀,低于60K

坚固可达120K

到处占主导

无法使用超出

表面混淆

稳定至128K

2 次会议,已放弃

3 次会话,已放弃

8 次会议,已通过

DeepSeek-V4-Pro 已成为我用于所有 Opencode 辅助软件开发会话的默认 LLM。不是因为它是最新的。也不是因为它具有最佳的学术基准。而是因为在一个开发者使用 30K tokens 代理上下文推送 Gradle Kotlin DSL 插件的真实生活中,它是唯一在上下文变长时不会背叛我的模型。

CSA+HCA 是一个架构上的 game changer。双层压缩 + 稀疏化不仅仅是实现细节 — 正是这一点区分了代码助手和可靠的队友。

我选择了 DeepSeek-V4-Pro,因为它是这三个中唯一能够将我的智能体治理从一种防御性约束(“如何避免智能体忘记?”)转变为进攻性优势(“既然智能体能记住一切,我们现在可以构建什么?”)的。 </think>


*这篇文章是该项目13次实际开发会议的成果`codebase-gradle`, 记录在`.agents/sessions/`根据我对代理的治理方法:Eager/Lazy/Hot/Warm/Cold。引用的技术来源在HuggingFace和arXiv上公开可访问。

相关文章