今天 Hacker News 上最热的几个话题里，有两个和中国开源大模型有关：Qwen3.6-Max-Preview（464 分，238 条评论）和 Kimi K2.6（496 分，249 条评论）。

让我停下来的不是"又出了一个新模型"，而是 Kimi K2.6 技术博客里的一段话：

Kimi K2.6 自主重构了一个有 8 年历史的开源撮合引擎。执行了 13 小时，发起了超过 1000 次工具调用，精确修改了超过 4000 行代码。吞吐量提升了 185%。

13 小时。1000 次工具调用。4000 行代码。

这不是"帮我写个函数"的聊天机器人。这是一个能坐在那里，盯着一个你不熟悉的老项目，连续干一整天，最后交出比你预期更好的结果的——编程搭档。

我想认真聊聊这件事。不是因为 Kimi K2.6 有多厉害（虽然我确实觉得它厉害），而是因为"长时程编码"这件事本身，正在从根本上改变我们和 AI 写代码的关系。

什么是"长时程编码"

先定义清楚我们在说什么。

"短程编码"你每天都在用：

• "帮我写个 Python 函数，解析这个 JSON"
• "这个报错是什么意思？"
• "给这段代码加个类型注解"

模型读你的代码，理解上下文，给出回答。通常几十秒搞定。你看完回答，复制粘贴，完事。

"长程编码"稍微复杂一点：

• "帮我把这个项目从 JavaScript 迁移到 TypeScript"
• "重构这个模块，把单体拆成微服务"

这需要模型理解整个代码库的结构，做出跨文件的一致修改。可能需要几百秒。

但"长时程编码"是另一个量级。它的特征是：

关键区别不在时间长短，而在于模型是否能自主处理过程中的不确定性。

一个典型的长时程任务里，模型会遇到：依赖不兼容、测试跑不通、文档过时、API 变更、环境配置缺失、甚至它自己前面几步的决策导致了后面需要回退。如果每一步都要人工介入，那就不叫"agent"，叫"非常慢的 autocomplete"。

Kimi K2.6 的三个真实案例

Kimi K2.6 的技术博客里放了三个让人印象深刻的案例，我来逐个拆解，看看它们到底做对了什么。

案例一：12 小时部署大模型

任务：在一台 Mac 上本地部署 Qwen3.5-0.8B 模型，并用 Zig 语言实现和优化推理。

结果：

• 4000+ 次工具调用
• 12 小时持续执行
• 14 次迭代优化
• 吞吐量从 ~15 tok/s 提升到 ~193 tok/s
• 最终速度比 LM Studio 快约 20%

这个案例的核心难点在于：Zig 是一个非常小众的语言。绝大多数模型的训练数据里 Zig 的代码量远远不够。K2.6 能做到"out-of-distribution generalization"——在自己不熟悉的语言里持续工作、持续学习、持续优化，这是长时程能力的基础。

14 次迭代意味着什么？意味着模型不是"一次写对"，而是"写了、跑了、看了结果、分析瓶颈、改了、再跑"的循环。这个循环要能自己转起来，不需要人每次都手动介入。

案例二：13 小时重构撮合引擎

任务：优化一个有 8 年历史的开源金融撮合引擎 exchange-core。

结果：

• 13 小时执行
• 12 种优化策略
• 1000+ 次工具调用
• 修改 4000+ 行代码
• 中等负载吞吐量提升 185%（0.43 → 1.24 MT/s）
• 性能负载吞吐量提升 133%（1.23 → 2.86 MT/s）

最让我惊讶的是这段描述：

模型分析了 CPU 和内存分配的火焰图，精确定位隐藏瓶颈，并大胆重构了核心线程拓扑（从 4ME+2RE 改为 2ME+1RE）。

火焰图分析。线程拓扑重构。这不是"改改变量名"级别的优化，而是架构级别的重新设计。

一个 8 年历史的项目，里面的代码往往充满了"当时只能这样做"的妥协和"后来加了个 patch 就跑了"的补丁。能读进去，理解为什么这样写，然后决定"这里可以彻底重写"——这需要很强的代码理解能力和重构信心。

案例三：多个合作伙伴的独立评估

Kimi 团队列出了 11 家合作伙伴的独立评估反馈，这不是 Kimi 自己说的，是外部团队的实际使用体验。挑几个值得注意的：

Vercel：在他们的 Next.js 基准测试中，K2.6 比 K2.5 提升了超过 50%。

CodeBuddy：代码生成准确率提升 12%，长上下文稳定性提升 18%，工具调用成功率 96.60%。

Fireworks.ai：在长上下文任务中达到了 state-of-the-art 表现，特别适合自主 agent pipeline。

这些独立反馈的可信度高于官方宣传，因为它们来自实际集成场景，而不是精心挑选的 benchmark。

长时程编码为什么难

如果你试过让 AI 做超过半小时的编码任务，你可能已经遇到过这些问题：

1. 上下文丢失

模型在长对话中会逐渐"忘记"前面的决策。你让它重构 A，它改了 A 然后改了 B，改到 F 的时候已经忘了 A 的原始设计意图，开始做出不一致的修改。

Kimi K2.6 声称长上下文稳定性提升了 18%。这不是一个巨大的数字，但在长时程场景里，18% 的稳定性提升意味着它少犯了很多"回头改坏前面东西"的错误。

2. 错误恢复能力

AI 写代码最大的问题不是"写不出对的"，而是"写出错的之后不知道怎么办"。

短程场景里，AI 报错了你会告诉它"这个不对，试试那个"。但长时程场景里，模型必须自己：

• 理解错误信息
• 定位错误原因
• 判断是自己哪一步导致的
• 制定修复策略
• 执行修复并验证

这个循环如果失败率高，模型就会陷入"写了→错了→不知道怎么修→写更糟→彻底崩"的死亡螺旋。

Kimi K2.6 的 96.60% 工具调用成功率在这个维度上是有意义的——每次工具调用都是一个小决策点，失败率越低，长时程任务能走多远就越远。

3. 决策疲劳

人类长时间编码会犯更多错误。模型会不会也有类似问题？

从已有的案例看，模型不会"疲劳"，但会随着 token 累积，注意力分布发生变化。后面生成的内容质量可能不如前面。这就是为什么"长上下文稳定性"是一个真实存在的技术挑战。

4. 环境理解

AI 模型看到的是代码文本，不是运行中的系统。它不知道这个服务启动时要连哪个数据库，不知道这个环境变量在 CI 里是怎么设的，不知道这个第三方 API 昨天刚改了返回值格式。

长时程编码要求模型通过工具调用（读文件、跑命令、查日志）来逐步构建对运行环境的理解。每次工具调用都是一次"观察"，观察越多，理解越深。但观察本身也有成本——调用太多就慢，调用太少就盲目。

Kimi K2.6 在 12-13 小时的任务中进行了 1000-4000 次工具调用，平均每分钟 1.5-5 次。这个频率说明它在持续地"看"和"验证"，而不是一次写一大堆然后赌它能跑。

背后的技术趋势

长时程编码能力的出现不是孤立的。它是几个技术趋势交汇的结果。

架构层面：MoE 的规模化

Kimi K2.6 采用 MoE（Mixture of Experts）架构。这不是新闻——很多模型都在用 MoE。但关键在于，MoE 在长时程场景中有天然优势：不同的"专家"可以处理不同的子任务（写代码、读文档、分析错误、运行测试），模型的总容量可以做得很大，但每次推理只激活一小部分参数，成本可控。

这对于"持续工作 12 小时"的任务至关重要——如果每次推理都要跑完整模型，token 成本会让这种用法变得不现实。

训练层面：从对话到行动

传统 LLM 的训练目标是"预测下一个 token"。这训练出了一个很好的聊天机器人。

但长时程编码需要的不是聊天能力，而是行动能力——调用工具、观察结果、调整策略、持续执行。

Kimi K2.6 的训练明显强化了 agent 循环：

观察环境 → 制定计划 → 执行动作 → 检查结果 → 调整计划 → 重复

这个循环每一步都需要模型做出决策，而不是简单续写文本。

生态层面：工具链成熟

长时程编码不是模型一个人的事。它依赖一整套工具链：

• 代码编辑工具：精确插入、替换、删除代码
• 终端工具：运行命令、安装依赖、跑测试
• 文件浏览工具：读取项目结构、搜索代码
• 调试工具：查看日志、分析错误

这些工具在过去一年里迅速成熟。Claude Code、Cursor、OpenCode、Kilo、Qoder 等工具都在提供越来越好的 agent 基础设施。

Kimi K2.6 的技术博客列出了 11 家合作伙伴——从 Ollama 到 Vercel 到 Fireworks.ai——说明整个生态都在围绕"agentic coding"这个方向构建。

作为开发者，这意味着什么

我不是在给 Kimi 写广告。我想说的是：长时程编码这件事，对普通开发者的工作流有真实的影响。

你能用它做什么

老项目改造：接手一个 5 年前的项目，文档没了，注释没了，前任离职了。让 agent 跑进去，读代码，跑测试，生成文档，识别技术债。它能做的事情比读一遍代码要多得多。

性能优化：就像 exchange-core 的案例一样，给 agent 一个目标（"把这个 API 的 P99 降到 200ms 以下"），它能自己定位瓶颈、尝试优化、跑基准测试、对比结果。

技术栈迁移：从 Vue 2 迁移到 Vue 3，从 Python 2 迁移到 Python 3。这种任务的特点是：改的东西很多，但模式很固定。正好适合 agent 来做。

基础设施搭建：配置 CI/CD、写 Dockerfile、设置监控告警。这些活不性感，但花时间。agent 可以一次性把整套基础设施搭起来。

它不能替代什么

架构决策：agent 可以执行架构变更，但不能决定"这个项目要不要上微服务"。这需要业务理解、团队能力评估、成本分析——这些超出代码范围的东西。

代码审查：agent 能发现语法错误和明显 bug，但"这个设计是否合理"、"这段代码的可维护性如何"、"有没有更好的抽象方式"——这些判断仍然需要人来做。

产品方向：agent 不会告诉你该做什么功能，不该做什么功能。它只会把你告诉它的东西做出来。

实际使用建议

如果你打算开始用长时程编码 agent，我的建议是：

1. 从明确的目标开始。不要说"帮我优化这个项目"，要说"把这个接口的响应时间从 2 秒降到 500ms 以下"。目标越明确，agent 越不容易跑偏。

2. 给它一个好的起点。长时程任务不是从零开始的。你应该先跑通基本环境、确认测试能跑、提供必要的文档。agent 不是魔术师，它需要基础设施。

3. 设置检查点。虽然 agent 可以自主工作，但你不应该完全放手。每隔几个小时看一下进展，确认方向没错。这和 code review 的逻辑一样——你不需要盯每一行代码，但需要看关键决策。

4. 记录过程。长时程任务的产出不只是最终代码，还有过程中的探索。agent 尝试过哪些方案、为什么放弃了某个方案、遇到了什么坑——这些信息对未来维护项目很有价值。

冷思考

最后，说几个冷静下来才能看清的事。

Benchmark 不等于现实。Kimi K2.6 的 benchmark 数据很好看，但 benchmark 是精心设计的。真实项目里的代码混乱度、文档质量、依赖复杂度，都远超 benchmark 的测试范围。别被数字迷惑。

12 小时不等于 12 小时的人类工作。agent 跑了 12 小时，做了 4000 次工具调用。如果人来做，可能 4 小时就能搞定——因为人有直觉、有经验、知道哪些东西不用试。agent 的优势不是"比人快"，而是"比人有耐心"和"可以在凌晨三点继续跑"。

生态锁定是真实风险。你现在用 Kimi K2.6 跑得好好的，但如果你的项目深度依赖了它的 agent 工作流，切换成本会越来越高。开源模型的好处是你可以换，但实际迁移的成本不低。

成本还没人认真算过。4000 次工具调用、12 小时执行，token 消耗是多少？API 费用是多少？如果这个费用超过了请一个初级开发者干一天的成本，那商业价值就要打问号了。目前还没有人公开做过这个核算。

结语

Kimi K2.6 和 Qwen3.6-Max-Preview 在同一天登上 HN 前排，这不是巧合。它反映的是一个正在发生的转变：AI 编码正在从"帮你写一段代码"进化到"帮你干一整天"。

这个转变的技术基础已经基本到位了——MoE 架构、长上下文、工具调用生态。剩下的问题不再是"能不能做"，而是"怎么用好"。

对于开发者来说，最务实的态度是：不要神话它，但也不要忽视它。现在就去试试长时程任务，看看它能做什么、做不好什么、在哪些场景里真的能帮到你。

毕竟，12 小时不眠的编程搭档，就算还不够完美，也比凌晨三点还在 debug 的你强一些。