GLM-4.7智能体部署实战：从模型选型到性能调优全解析

1. 项目概述：从GLM-4.5到GLM-4.7，一个开源智能体基座的演进之路

如果你在过去一年里深度参与过AI智能体或者大语言模型的应用开发，那么“GLM”这个系列对你来说一定不陌生。从GLM-4.5的横空出世，到GLM-4.6的稳步提升，再到最近GLM-4.7的惊艳亮相，智谱AI的这套开源模型家族，已经从一个“不错的选项”变成了许多团队在构建复杂AI应用时，尤其是在智能体（Agent）场景下，会优先考虑甚至深度依赖的基座。我自己的团队在过去几个项目中，从早期的模型选型、到中期的性能调优、再到后期的生产部署，都不同程度地使用了GLM系列模型，踩过一些坑，也积累了不少实战经验。今天，我就以一个一线开发者的视角，来为你深度拆解GLM-4.5/4.6/4.7这一系列模型，特别是最新的GLM-4.7，到底带来了哪些实质性的改变，以及在实际部署和应用中，我们该如何选择、如何避坑、如何榨干它的每一分性能。

简单来说，GLM-4.5系列是智谱AI专门为“智能体”场景设计的混合专家（MoE）模型。它最大的特点，就是官方宣称的“ARC”三位一体能力：Agentic（智能体）、Reasoning（推理）、Coding（编程）。这意味着它从设计之初就不是一个单纯的聊天模型，而是为了处理多步骤规划、工具调用、代码生成与执行等复杂任务而生的。GLM-4.5拥有3550亿总参数，其中活跃参数为320亿，这个规模在开源MoE模型中属于第一梯队。同时，它还提供了一个更轻量的“Air”版本（总参1060亿，活跃120亿），为资源受限的场景提供了可能。到了GLM-4.6，最显著的提升是将上下文长度从128K扩展到了200K，这对于需要处理超长文档或维持超长对话历史的智能体任务至关重要。而GLM-4.7，则是在其前辈坚实的基础上，对“思考”能力进行了革命性的增强，引入了“交错思考”和“持久思考”等新机制，让模型在解决复杂任务时的稳定性和可控性上了一个新台阶。

2. 核心能力演进与模型选型深度解析

面对GLM-4.5、4.6、4.7以及它们各自的Base、FP8、Flash变体，很多开发者第一反应是眼花缭乱。别急，我们一层层剥开来看。选型的核心，永远是基于你的具体任务场景、硬件预算和对延迟/效果的权衡。

2.1 代际差异：从4.5到4.7，能力跃迁在哪里？

首先，我们得搞清楚这三个主要版本的本质区别，这决定了你的基线选择。

GLM-4.5：智能体基座的奠基者这是整个系列的起点。它的核心价值在于证明了MoE架构在复杂任务上的巨大潜力。在发布时，其在多项基准测试（如AgentBench、HumanEval等）上的表现就足以媲美甚至超越许多闭源模型。对于大多数常规的智能体应用——比如基于自然语言操作数据库、自动编写并执行数据分析脚本、调用外部API完成工作流——GLM-4.5-Air版本往往已经足够胜任，且部署成本低得多。它的“思考模式”是一个重要特性，在需要复杂推理或工具调用的任务中开启，模型会先输出一段“内心独白”（推理链），再给出最终答案或行动，这大大提升了任务的可解释性和成功率。

GLM-4.6：长上下文与综合性能的强化GLM-4.6可以看作是4.5的“完全体”。除了基准分数上的普遍提升，它最实用的升级是200K上下文窗口。在实际项目中，这意味着什么？假设你正在构建一个代码助手，用户可以将整个中小型项目的代码库（可能数万行）作为上下文喂给模型，让它进行全局分析、重构建议或bug查找。或者，在客服场景中，模型可以记住更长的对话历史，避免“健忘”。另一个容易被忽略但至关重要的提升是工具调用（Tool Using）和搜索能力的增强。根据官方报告，在τ²-Bench和BrowseComp等基准上进步显著。如果你做的智能体严重依赖准确调用各种工具（搜索引擎、计算器、专业API）或进行网页信息提取，4.6会比4.5更可靠。

GLM-4.7：思考机制的质变与编码专精GLM-4.7的升级点非常集中且深刻，主要围绕“如何更好地思考”。它引入了三个关键概念：

1. 交错思考（Interleaved Thinking）的增强：在4.5/4.6中，思考模式是“一次性”的。而在4.7中，模型可以在一次多步骤任务中，在每一个动作（如调用一个工具、生成一段代码）之前都进行思考，使得每一步的决策都更加审慎，指令跟随能力更强。
2. 持久思考（Preserved Thinking）：这是解决智能体任务中“信息丢失”痛点的利器。在传统的多轮对话中，模型每轮都需要重新理解整个历史和之前的推理过程。而持久思考允许模型在对话中自动保留所有的思考块，在后续轮次中直接复用，而不是从头推导。这对于代码调试、分步问题解决等长视野任务来说，稳定性和一致性会有质的飞跃。
3. 轮次级思考控制（Turn-level Thinking）：你可以在会话粒度上灵活控制是否开启思考。对于简单的问答，关闭思考以降低延迟和成本；对于复杂任务，再开启。这给了开发者精细的成本与效果调控能力。

此外，GLM-4.7在编码能力上提升巨大，特别是在SWE-bench（解决真实GitHub问题）和Terminal Bench（终端任务）上。如果你的核心场景是AI编程助手、自动化脚本生成，或者需要模型与命令行交互，4.7是目前开源模型中的顶级选择。它还专门推出了一个轻量级的GLM-4.7-Flash模型（300亿总参，30亿活跃），在性能和效率间取得了新平衡，为端侧或低成本部署打开了新大门。

实操心得：版本选择策略我的经验是：求稳且预算有限选4.5-Air，要长上下文和强工具调用选4.6，攻坚复杂编码与长任务智能体必上4.7。对于大多数企业内部自动化流程、知识问答机器人，4.5-Air性价比极高。如果是面向开发者的重度编码工具，或者需要处理超长技术文档的智能体，4.6是更全面的选择。而如果你的项目类似于AutoGPT、Devin这类需要高度自主规划、执行复杂多步任务（尤其是涉及代码编写和终端操作）的智能体，那么GLM-4.7的持久思考特性几乎是“降维打击”，能显著降低任务中途“跑偏”或“失忆”的概率。

2.2 模型变体详解：Base、FP8、Flash都是什么？

确定了主版本后，你还会看到一堆后缀。它们决定了模型的“形态”和部署要求。

• Base模型：指经过预训练但未经过指令微调（SFT）和人类偏好对齐（RLHF）的“原始”模型。它的语言能力很强，但在遵循指令、安全回复、对话格式上表现不佳。除非你要从头开始做领域特定的微调，否则不要直接使用Base模型。它适合研究机构或大型企业进行大规模定制化训练。
• 标准模型（无后缀）：即经过完整SFT和RLHF对齐的聊天模型，也是我们通常所说的“GLM-4.5/6/7”。它直接用于对话、推理、工具调用等任务。我们日常讨论和使用的默认就是这个版本。
• FP8量化版本：这是用FP8（8位浮点数）精度存储的模型权重。FP8能在几乎不损失精度的情况下（对于大语言模型，精度损失通常可忽略），将模型的内存占用和计算量减半。这是生产部署的首选，尤其是对于GLM-4.5/4.7这种大模型，FP8版本能让你用一半的GPU数量达到相近的性能。例如，GLM-4.5 FP8只需8张H100，而BF16版本需要16张。
• Flash版本（仅4.7有）：这是一个全新的、更小的模型架构（300亿总参/30亿活跃），并非原模型的量化版。它旨在提供接近标准版的能力，但拥有更快的推理速度和低得多的硬件需求。官方称其“在性能与效率间提供了新的选择”。对于延迟敏感或计算资源紧张的应用（如实时对话、边缘设备），Flash版本值得重点评估。

注意事项：关于量化与精度很多团队会纠结于“量化会不会影响效果”。根据我们和业内的实测，对于GLM系列，FP8量化对最终任务效果的影响微乎其微，尤其是在智能体、代码生成这类任务上，差异远小于不同prompt带来的波动。因此，在资源允许的情况下，优先尝试FP8版本，它能为你节省大量成本。只有在极端追求最高精度、且资源无限充足的科研场景下，才需要考虑BF16版本。

2.3 硬件需求与部署成本估算

这是最现实的一环。官方给出了详细的配置表，但我们需要解读其背后的含义。

推理配置解读以GLM-4.5标准版（BF16）为例，“H100 x 16”是最低配置，能跑起来，但可能无法充分发挥128K全部上下文的能力。而“H100 x 32”是推荐配置，能保证在满上下文（128K）下仍有良好性能。这里的差异主要在于KV Cache（键值缓存）的内存占用。上下文越长，KV Cache越大，对显存的要求呈线性增长。

对于FP8版本，所需GPU数量减半，这得益于FP8精度将权重和KV Cache的显存占用都减少了约50%。因此，GLM-4.5 FP8用8张H100，就能达到接近BF16版用16张H100的效果和上下文支持能力。

GLM-4.7-Flash的吸引力GLM-4.7-Flash（BF16）仅需1-2张H100，这个门槛就低了很多。对于很多创业团队或中等规模的业务，2张H100（或同等算力的A100/A800）的服务器是负担得起的。这意味着一台单机服务器就能部署一个能力接近顶级大模型的智能体服务，部署复杂度和管理成本大大降低。

非NVIDIA硬件支持官方文档也提到了对华为昇腾Ascend NPU（通过xLLM框架）和AMD GPU的支持。这对于有特定国产化或多元化硬件需求的团队是个好消息。不过，相关生态和优化程度可能不如NVIDIA CUDA成熟，需要投入更多调优精力。

避坑指南：显存估算与选型不要只看GPU数量，要算显存。一张80GB显存的H100，实际可用显存约76GB。以GLM-4.5（355B-A32B）BF16为例，每个参数占2字节。仅模型权重就需要约710GB，通过张量并行（Tensor Parallelism）分摊到16张卡，每卡约44.4GB。这还没算上KV Cache、激活值等开销。因此，16张H100是刚够加载。如果还要开大的批处理（batch size），或者用更长上下文，就必须要更多卡或使用FP8。一个简单的公式：所需GPU数量 ≈ 模型参数量（以十亿计）2（BF16）或 * 1（FP8） / 单卡可用显存（GB）*。然后在此基础上，为KV Cache和批处理留出至少20%-30%的余量。

3. 实战部署：从零搭建GLM推理服务

理论说再多，不如动手跑起来。这里我以部署GLM-4.7-FP8为例，分享最常用的两种部署方式：vLLM和SGLang。我会详细解释每个参数的意义，以及我们在生产环境中遇到的典型问题和解决方案。

3.1 环境准备与依赖安装

首先，你需要一台满足硬件要求的Linux服务器。假设你已经安装好了NVIDIA驱动、CUDA（>=12.1）和conda环境。

# 1. 创建并激活conda环境 conda create -n glm-serving python=3.10 -y conda activate glm-serving # 2. 安装PyTorch（根据你的CUDA版本） pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 3. 根据你的部署框架选择安装 # 方案A: 使用vLLM（以速度快、生态好著称） pip install vllm # 方案B: 使用SGLang（对GLM系列思考模式、PD-Disaggregation等特性支持更原生） pip install sglang[all] # 安装全部后端，包括vLLM # 4. 其他可能需要的工具 pip install huggingface-hub # 用于从Hugging Face下载模型

注意：sglang[all]会安装一个较大的包，如果网络或环境有问题，可以尝试pip install sglang安装核心包，再按需安装sglang[vllm]等子组件。

3.2 使用vLLM部署服务

vLLM以其高效的PagedAttention内存管理和开箱即用的OpenAI兼容API而广受欢迎。部署GLM-4.7需要一些特殊参数。

# 这是一个启动GLM-4.7-FP8模型的示例命令 vllm serve zai-org/GLM-4.7-FP8 \ --tensor-parallel-size 4 \ # 张量并行度，根据你的GPU数量调整。4表示将模型拆分到4张GPU上。 --speculative-config.method mtp \ # 使用MTP（Mixture-of-Thought Prediction）推测解码，加速推理 --speculative-config.num_speculative_tokens 1 \ # 推测解码的token数 --tool-call-parser glm47 \ # **关键**：指定使用GLM-4.7的工具调用解析器 --reasoning-parser glm45 \ # 指定推理解析器（4.7兼容4.5的解析器） --enable-auto-tool-choice \ # 启用自动工具选择（模型可以决定何时调用哪个工具） --served-model-name glm-4.7-fp8 \ # 服务名称，客户端连接时使用 --port 8000 # 服务端口，默认为8000

参数深度解析：

• --tensor-parallel-size：这是模型并行的核心参数。必须等于你用于承载模型的GPU数量。例如，你有4张GPU，就设为4。vLLM会自动将模型均匀切分到这些卡上。对于GLM-4.7-FP8，官方推荐至少4张H100。
• --speculative-config.*：推测解码是一种推理加速技术，用一个小的“草案模型”提前生成多个token，再由大模型快速验证。mtp是GLM系列支持的一种高效模式。开启后能显著提升生成速度，尤其是长文本生成。
• --tool-call-parser glm47：这是GLM-4.7专属参数，必须正确设置。GLM-4.7的工具调用格式可能有细微调整，使用正确的解析器才能正确识别和解析模型输出的工具调用JSON。
• --reasoning-parser glm45：推理（思考）输出的解析器。GLM-4.7的思考模式增强，但解析格式向后兼容GLM-4.5。
• --enable-auto-tool-choice：强烈建议开启。它允许模型在对话中自主决定是否需要调用工具，以及调用哪个工具。这是构建智能体的基础。

服务启动后，vLLM会提供一个完全兼容OpenAI API格式的接口（/v1/chat/completions），你可以用任何OpenAI SDK的客户端来调用它。

3.3 使用SGLang部署服务

SGLang是另一个高性能推理运行时，它对GLM系列的原生支持非常好，特别是对持久思考（Preserved Thinking）模式的支持目前是独家的。如果你要充分发挥GLM-4.7在复杂智能体任务上的优势，SGLang是更好的选择。

python3 -m sglang.launch_server \ --model-path zai-org/GLM-4.7-FP8 \ --tp-size 8 \ # 张量并行度，这里示例用8卡 --tool-call-parser glm47 \ # 同样指定GLM-4.7工具解析器 --reasoning-parser glm45 \ --speculative-algorithm EAGLE \ # 使用EAGLE算法进行推测解码 --speculative-num-steps 3 \ --speculative-eagle-topk 1 \ --speculative-num-draft-tokens 4 \ # 草案token数，影响加速比 --mem-fraction-static 0.8 \ # 为KV Cache静态预留80%的显存，适合长上下文 --served-model-name glm-4.7-fp8 \ --host 0.0.0.0 \ --port 8000

SGLang特有优势：

1. 对思考模式的精细控制：在请求时，可以通过extra_body参数传递chat_template_kwargs来开启或关闭思考，以及控制是否清除历史思考。

   { "messages": [...], "chat_template_kwargs": { "enable_thinking": true, "clear_thinking": false // 设为false即启用“持久思考” } }

2. PD-Disaggregation（预填充-解码分离）：这是一个高级特性，可以将推理过程拆分成“预填充”（Prefill，处理输入提示）和“解码”（Decode，生成输出）两个阶段，并分配到不同的GPU组上执行。这能极大优化高并发场景下的资源利用率和吞吐量。官方给出了一个单机多卡的示例脚本，这对于构建高负载的智能体API服务非常有价值。

3.4 客户端调用示例与工具调用集成

服务跑起来后，我们来看看如何调用。这里以Python的openai库为例，演示如何调用本地vLLM/SGLang服务，并处理工具调用。

import openai import json # 1. 配置客户端，指向本地服务 client = openai.OpenAI( api_key="no-key-required", # 本地部署通常不需要key base_url="http://localhost:8000/v1" # vLLM或SGLang的API地址 ) # 2. 定义工具列表（OpenAI格式） tools = [ { "type": "function", "function": { "name": "get_current_weather", "description": "获取指定城市的当前天气", "parameters": { "type": "object", "properties": { "location": { "type": "string", "description": "城市名，例如：北京，上海", }, "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}, }, "required": ["location"], }, }, }, # ... 可以定义更多工具 ] # 3. 发起对话请求，并启用思考模式 response = client.chat.completions.create( model="glm-4.7-fp8", # 与 --served-model-name 一致 messages=[ {"role": "user", "content": "北京今天天气怎么样？"} ], tools=tools, tool_choice="auto", # 让模型自动决定是否调用工具 extra_body={ # SGLang特有参数，vLLM可能部分支持 "chat_template_kwargs": { "enable_thinking": True, # 开启思考 "clear_thinking": False # 持久思考（仅SGLang完全支持） } }, stream=False # 设为True可流式输出 ) # 4. 处理响应 message = response.choices[0].message print(f"模型回复: {message.content}") # 5. 检查是否有工具调用 if message.tool_calls: for tool_call in message.tool_calls: func_name = tool_call.function.name func_args = json.loads(tool_call.function.arguments) print(f"模型要求调用工具: {func_name}, 参数: {func_args}") # 在这里，你需要根据func_name执行相应的函数，获取结果 # 例如：weather_result = get_current_weather(**func_args) # 6. 将工具执行结果返回给模型，继续对话 second_response = client.chat.completions.create( model="glm-4.7-fp8", messages=[ {"role": "user", "content": "北京今天天气怎么样？"}, message, # 包含工具调用的上一条消息 { "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(weather_result), # 工具执行结果 }, ], extra_body={"chat_template_kwargs": {"enable_thinking": True, "clear_thinking": False}}, ) print(f"模型结合工具结果后的回复: {second_response.choices[0].message.content}")

实操心得：工具调用与思考模式

1. 工具描述要清晰：工具函数的description和parameters的description至关重要。GLM系列模型对工具的理解能力很强，清晰、无歧义的描述能极大提高调用准确率。
2. 善用tool_choice：除了"auto"，你还可以设置为"none"（强制不调用工具）或{"type": "function", "function": {"name": "xxx"}}（强制调用特定工具）。这在构建确定性的工作流时很有用。
3. 思考模式是双刃剑：开启后，模型会先输出<|think|>...<|/think|>格式的思考过程，再输出最终内容或工具调用。这增加了可解释性，但也增加了生成token数（从而增加成本和延迟）。对于简单查询，建议关闭思考以提升响应速度；对于复杂规划、数学推理或多步任务，务必开启，能显著提升成功率。
4. 持久思考的妙用：在SGLang中，将clear_thinking设为False后，模型会在整个会话中累积思考。这对于调试一个复杂bug的对话非常有用，模型不会忘记上一步的推理结论。你需要确保客户端在后续请求中传递完整的消息历史（包括之前的思考块）。

4. 高级应用与性能调优指南

部署起来只是第一步，要让GLM系列模型在你的业务中发挥最大价值，还需要一些高级技巧和调优手段。

4.1 推理性能优化策略

大模型推理是资源密集型任务，优化目标通常是：降低延迟（Latency）和提高吞吐量（Throughput）。

1. 批处理（Batching）：这是提高吞吐量最有效的方法。将多个用户的请求打包成一个批次（batch）一起推理，能大幅提升GPU计算单元的利用率。vLLM和SGLang都支持动态批处理（Continuous Batching），可以自动将不同长度的请求组合在一起。

   • 在vLLM中，可以通过--max-num-batched-tokens或--max-num-seqs来限制批次大小，平衡延迟和吞吐。
   • 在客户端，如果你的应用场景允许（如异步任务处理），可以主动收集请求进行批量发送。

2. 推测解码（Speculative Decoding）：如前所述，GLM系列支持MTP/EAGLE等推测解码算法。这通常能带来1.5倍到3倍的生成速度提升，且几乎不影响输出质量。在生产环境中强烈建议开启。你需要根据模型和硬件调整num_speculative_tokens等参数，找到一个速度和内存占用的平衡点。

3. 量化与精度：再次强调，FP8版本是你的朋友。在效果损失可接受的前提下，它能直接让硬件需求减半。对于GLM-4.7-Flash这种轻量模型，甚至可以考虑INT4/INT8量化，以进一步降低部署门槛，但需要仔细评估精度损失。

4. KV Cache量化与分页：vLLM的PagedAttention和SGLang的类似机制，能高效管理变长序列的KV Cache，避免内存碎片。确保你使用的版本支持这些特性。

4.2 构建复杂智能体工作流

GLM-4.7的持久思考特性，为构建鲁棒的、多轮次复杂智能体打开了新的大门。一个典型的智能体工作流可能如下：

# 伪代码，展示一个结合规划、工具调用、代码执行的智能体循环 class CodingAgent: def __init__(self, llm_client): self.client = llm_client self.conversation_history = [] self.thinking_context = None # 用于保存持久思考的上下文 def solve_issue(self, issue_description): # 第一轮：规划与拆解 plan_prompt = f"""你是一个资深程序员。请分析以下问题，并制定一个分步解决计划： 问题：{issue_description} 请一步步思考，并输出你的计划。""" plan_response = self.client.chat.completions.create( model="glm-4.7-fp8", messages=[{"role": "user", "content": plan_prompt}], extra_body={"chat_template_kwargs": {"enable_thinking": True, "clear_thinking": False}} ) plan = plan_response.choices[0].message.content self._update_history(plan_response) # 保存历史和思考上下文 # 根据计划，循环执行每一步 for step in self._parse_plan(plan): if step.type == "write_code": # 调用代码生成工具或直接让模型生成 code_response = self.client.chat.completions.create(...) generated_code = code_response.choices[0].message.content # 执行生成的代码（在沙箱中） execution_result = safe_execute(generated_code) # 将执行结果反馈给模型，进行下一轮 self._update_history_with_result(execution_result) elif step.type == "search_web": # 调用搜索工具 search_result = call_search_tool(step.query) self._update_history_with_result(search_result) # ... 处理其他类型的步骤 # 最终总结 final_response = self.client.chat.completions.create(...) return final_response.choices[0].message.content def _update_history(self, response): """更新对话历史，并保存思考上下文（对于SGLang）""" self.conversation_history.append(response.choices[0].message) # 如果是SGLang，并且开启了持久思考，可能需要传递一个特殊的session_id或上下文句柄 # 在实际中，这可能需要使用SGLang的stateful API

在这个工作流中，持久思考确保了模型在“写代码-执行-报错-调试”这个长循环中，不会忘记最初的问题分析和中间每一步的推理逻辑，从而能更连贯、更准确地解决问题。

4.3 微调（Fine-tuning）考量

虽然GLM-4.5/6/7已经是能力极强的通用模型，但在特定垂直领域（如法律、医疗、金融），或者需要固化某种特定风格或流程时，微调仍然是必要的。

• 微调框架：官方推荐使用LLaMA-Factory或Swift（ModelScope）。这两个框架都对GLM系列有良好的支持，且集成了LoRA、QLoRA等参数高效微调技术，能大幅降低微调所需的显存。
• 硬件需求：微调比推理需要更多的显存，因为它要保存优化器状态和梯度。官方给出的参考配置（如GLM-4.5用16张H100做LoRA）是针对全参数微调或特定配置的。对于大多数场景，使用QLoRA在2-4张A100/H100上微调GLM-4.5-Air是可行的。
• 数据准备：智能体微调的数据格式很关键。你需要准备(指令， 思考过程， 行动/回复)这样的三元组数据。思考过程可以先用基础模型生成，再进行人工修正和润色。高质量的“思考-行动”配对数据是微调出强大领域智能体的关键。
• 注意事项：微调可能会影响模型原有的通用能力和安全性。务必在微调后进行全面评估，包括通用能力测试、安全性测试以及你的特定领域任务测试。

5. 常见问题排查与实战经验录

在实际使用中，你肯定会遇到各种各样的问题。这里我总结了一些高频问题和解决方法。

5.1 部署与启动问题

5.2 模型推理与效果问题

5.3 成本与资源管理

• 监控GPU使用率：使用nvtop或gpustat实时监控。理想的推理服务，GPU计算单元（SM）利用率应在50%以上，显存使用稳定。如果利用率低，可能是批处理大小不足或请求间隔不均。
• 动态伸缩：对于云部署，可以根据请求队列长度自动伸缩服务实例。Kubernetes + 自定义指标（如请求延迟）是实现自动伸缩的常用方案。
• 缓存层：对于频繁出现的、结果确定的查询（如某些知识问答），可以在模型服务前加一层缓存（如Redis），直接返回缓存结果，大幅降低模型调用成本和延迟。

最后，我想分享一点个人体会。GLM-4.7的“持久思考”特性，是我近期测试过的开源模型中最令人兴奋的功能之一。它不仅仅是一个技术指标上的提升，更是改变了我们设计智能体系统的范式。以前我们需要在外部用代码费力地维护“状态”和“记忆”，现在模型内部就能更优雅地处理一部分。这让我们能将更多精力放在定义任务、设计工具和优化用户体验上，而不是绞尽脑汁解决模型“遗忘”的问题。当然，它也对我们的工程实现提出了新要求，比如如何高效地管理这些带思考的会话状态。但无论如何，这无疑是朝着更强大、更实用的AI智能体迈出的坚实一步。如果你正在这个领域探索，强烈建议你亲自部署体验一下GLM-4.7，特别是结合SGLang的持久思考模式，去构建一个能真正“深思熟虑”的AI助手。