智谱为什么重押 Coding Agent？大模型的下半场，不是“写代码”，而是要“把活干完”

题图摄于北京北三环

“把这个老系统的依赖升级一下，修掉所有废弃接口，补齐测试，最后给我一个可以审查的代码变更。”

如果把这项任务交给早期的 AI 编程助手，它大概率会给出几段示例代码，然后把剩下的工作还给程序员。但新一代 Coding Agent （编程智能体）的目标完全不同：先读懂项目，修改多个文件，运行编译和测试，遇到报错后继续查日志、改代码，直到交付结果。

是“帮你写”，还是“替你做”？

我觉得，这正是理解智谱近期动作的关键。从 CodeGeeX 到 GLM-4.5、GLM-4.7，再到今年的 GLM-5 系列，智谱正把越来越多资源投入编程与长程任务。表面上，它押注的是 Coding Agent；更深一层，它押注的是：大模型能否从回答问题，走向完成工作。

代码，为什么成为Agent的最佳试验田？

AI可以写文案、做PPT、分析报表，为什么头部模型公司却集体涌向编程？

一个重要原因是，代码能给 AI 提供清晰而连续的反馈。文案好不好，往往见仁见智；但一个接口能不能运行，编译、测试和响应结果都能立即验证。模型写完代码可以运行测试，发现报错可以读取日志，再根据错误继续修改。这就形成了“规划—执行—检查—修正”的闭环。

普通 Chatbot 回答完一句话，任务基本结束；Agent 却要不断判断下一步做什么、结果是否符合预期、出了问题如何回退。软件工程恰好提供了一个可以反复试错的数字环境。

其次，软件开发价值高、数字化程度也高。代码、文档、测试和版本记录都已在计算机里，企业也习惯为研发工具付费。Coding Agent 不需要先改造大量线下流程，就有机会进入生产环境。

更重要的是，编程并不只是一个垂直应用。Agent 在其中学到的目标拆解、工具调用、自主纠错和结果验证，也是通用执行型智能体需要的基本能力。

所以在我看来，代码不是Agent的普通应用场景，而是AI学习“把活干完”的第一块训练场。

从CodeGeeX到GLM-5：智谱想做的不只是代码补全

智谱布局编程并非临时跟风。CodeGeeX最初更多承担代码补全、生成和开发辅助的角色，类似一个更聪明的编程副驾驶。现在，GLM-5系列的目标已经从“补几行代码”转向“接手一段工程任务”。

智谱公布的数据显示，GLM-5 在 SWE-bench Verified —— 一个模拟真实代码仓库问题修复的评测——上得分 77.8，处于公开榜单第一梯队。到了GLM-5.2，在更侧重命令行任务执行的 Terminal Bench 2.1 中得分 81.0，仅次于Claude Opus 4.8 的 85.0。不同基准和版本并非同一把尺子，厂商测试设置也未必完全一致；但评价标准已经变了：行业不再只看代码生成得像不像，而开始看问题有没有真正解决。

GLM-5.2 还支持最高 100万 Token 的上下文。通俗地说，就是 Agent 在持续工作时可以保留更多需求、代码、日志和测试结果，不至于做着做着忘掉前面的决定。

智谱在 GLM-5.2 发布材料中展示过一个长程开发案例：模型连续完成开发、联调、测试和打包，交付覆盖 Web、移动端与小程序的多端应用，处理超过 88 万 Token。厂商演示不能代表所有真实项目，但它说明了智谱想把竞争推进到哪里——不是生成一个页面，而是尽可能跑完整条工程链路。

真正的难点不只是把 88 万 Token “塞进去”，而是从庞大上下文中找回早期需求和架构决定，保持前后逻辑一致。单纯堆上下文，就像给一个人塞进大量资料，却不教他如何做笔记和总结。只有当长上下文转化为连续、可靠的决策，它才不再只是营销参数。

传统代码助手与新一代 Coding Agent 的差别，可以归结为四句话：

• 从被动补全，走向自主拆解任务；
• 从生成片段，走向读取代码库、修改多个文件；
• 从一次回答，走向运行测试、排错和反复修正；
• 从处理代码文本，走向理解设计稿、操作浏览器和调用终端工具。

聊天入口太拥挤，Coding是智谱的突围窗口

这种能力跃迁不只是技术升级，也对应着一个商业判断：开发者也许是最难取悦的用户，却是最懂工具价值、也最愿意为生产力付费的人群之一。

国内通用聊天入口已经异常拥挤。豆包拥有字节的流量，Kimi已经形成专业助手的用户认知，腾讯、阿里、百度也有自己的入口。智谱清言只靠聊天体验建立压倒性优势，难度很大。

Coding 市场不太一样。开发者更在意模型能否读懂代码库、工具调用是否稳定，以及完成任务要花多少钱。流量仍然重要，但能力、工程适配和性价比更有发言权。

智谱的产品分工也逐渐清晰：CodeGeeX 是面向开发者的入口，GLM 系列提供推理核心，GLM-5V-Turbo 负责理解截图、设计稿和软件界面；AutoGLM探索图形界面操作，AutoClaw 则把本地客户端、工具和Skills连接起来。

这套组合想构造的，是一个能看界面、能改代码、能用工具、能检查结果的执行体。比如，根据设计稿生成页面后，再打开浏览器检查效果，发现布局问题后继续修改。智谱真正的赌注，是让模型、工具与视觉操作形成“数字手脑协同”，把模型能力变成工程劳动力。

但这里也要保持克制。目前公开信息更多展示了各项能力，针对整条“数字手脑协同”链路的独立评测仍然有限。几块能力能否在复杂项目中稳定协同，仍需真实客户案例验证。

愿景需要财务数据来检验。财报显示，智谱 2025 年总收入约 7.24 亿元，同比增长 131.9%；其中开放平台及 API 收入约 1.90 亿元，同比增长 292.6%，企业级智能体收入约 1.66 亿元，同比增长 248.8%。智谱尚未单独披露Coding 业务收入占比，因此这些数字不能直接算作 Coding 路线的成绩，但至少说明 API 和 Agent 需求正在转化为业务。

另一方面，公司当年报告净亏损约 47.18 亿元；剔除股份支付等项目后，经调整净亏损仍达到 31.82 亿元。无论采用哪种口径，高增长距离可持续盈利都还有很长的路。

强敌环伺，智谱真正要比什么？

Coding 这条赛道当然拥挤。Kimi 押注长上下文和多 Agent 协作，MiniMax 强调 Agent 与成本效率，DeepSeek 依靠开源、性价比和开发者口碑，阿里则拥有 Qwen Coder 与云基础设施。海外还有 Claude Code、OpenAI Codex和 Gemini。

各家路线不同，也都在补齐工具链。智谱的差异化，不是某一个功能独占，而是较早把开发者工具、多模态模型、图形界面操作和本地 Agent 客户端放进同一张产品版图。它真正需要证明的，是这些组件能否形成协同，把“模型能力”稳定地转化为工程交付。

智谱的全栈布局值得关注，但它只是入场券，真正的护城河还在后面。它至少要跨过三道门槛。

一，长上下文不等于长程可靠性。GLM-5.2 和长程基准已经显示出进步，但Agent 工作几小时后是否仍不偏离目标，还需要更多第三方测试和生产数据。真正的系统必须具备任务分段、阶段性检查、失败回滚和人工确认。

二，基准测试不等于企业生产环境。智谱本地化部署收入的增长说明它具备进入企业的渠道，但在代码权限、修改追踪和上线审批上能否满足金融、政企等强合规场景，还要看具体产品与客户实践。

三，代码产量不等于业务价值。智谱已经把评测重心从代码生成扩展到长程任务，但企业最终考核的仍是任务完成率、测试通过率、返工成本和上线后的故障率。如果出了事故仍然找不到责任人，再高的自动化率也很难进入核心生产流程。

Coding Agent之后，AI何时能真正把活干完？

我一直认为，企业真正需要的不是更会聊天的大模型，而是能够进入流程、调用工具、交付结果，同时接受检查的 Execution Agent（通用执行型智能体）。Coding Agent 的意义，也远不只是帮助程序员提高效率。

它正在验证几个更普遍的问题：AI能否理解复杂目标，能否把目标拆成步骤，能否根据反馈自主修正，能否留下可审查的过程。

同样的逻辑还可以进入更多行业：财务 Agent 核对账目并标出异常；医药Agent 检查资料、追溯证据并提示风险；制造 Agent 读取产线数据、定位故障。只是这些行业缺少代码那样即时、标准化的测试反馈。

真正的挑战还在“敢不敢用”。可信的 Coding Agent，不仅要知道怎么修改代码，还要在删除关键数据前停下来确认，在改变核心接口时解释原因，在无法判断时主动标出风险。它需要的不只是能力，还有分寸。

所以，我对智谱重押 Coding 的判断是：这不是简单的产品转向，而是在争夺通往通用执行型智能体的入口。真正的分水岭，从来不是模型能写多少行代码，而是它能否交付可验证和无需反复返工的结果。

从开头那句“给我一个可以审查的代码变更”，到未来变更记录里的AI署名，Coding Agent 的终极目标从来不是写更多代码，而是接住一份完整的责任。

大模型已经越来越会写代码了。但接下来的竞赛，将从“代码通过编译”转向“工作通过验收”。谁能率先让企业敢在变更记录上签下 “Reviewed-by: AI” ，谁才算真正拿到了通用 Agent 的入场券。

如果你的团队已经开始把完整任务交给AI，最先卡住的是能力、成本，还是信任？评论区聊聊。