2026 年 AI 模型能力的六条技术主线：从 Agent 工程到具身智能

大模型的竞争正在发生一个明显变化：模型不再只比谁更会聊天，而是比谁能完成更长、更复杂、更接近真实工作的任务。

这种变化体现在几个方向上：

• 编程模型开始处理复杂软件工程任务，而不只是补全代码片段。
• 图像编辑模型从“生成一张图”走向“按指令精确修改局部内容”。
• 机器人模型开始把视觉、语言和动作统一到一个模型体系里。
• 智能眼镜这类终端开始支持接入私有智能体。
• 数学推理模型尝试进入开放科研问题。
• 模型安全评估从“有没有明显恶意”走向“是否具备长期自治能力”。

这些方向背后有一个共同逻辑：AI 系统正在从“回答问题的模型”变成“能感知环境、调用工具、持续行动的执行系统”。

flowchart LR
    A[用户目标] --> B[大模型理解与规划]
    B --> C[工具调用 / 代码执行 / 环境交互]
    C --> D[结果反馈]
    D --> B
    B --> E[最终交付物]

上面这个循环是很多新模型的核心形态。模型不只是一次性输出答案，而是在目标、工具、环境、反馈之间反复迭代，直到完成一个任务。

1. Agentic Engineering：编程模型开始进入复杂工程任务

Agentic Engineering 可以理解为“智能体化工程”。它不是让模型写一个函数，而是让模型像工程助手一样理解需求、拆分任务、读写代码、运行命令、修复错误，甚至完成一个完整应用的搭建。

这一方向里有两个典型信号：智谱 GLM-5 和 MiniMax M2.5。

这里的“激活参数”很关键。很多大模型采用类似 MoE（Mixture of Experts，混合专家）的稀疏激活思路，模型总参数可以很大，但每次推理只激活其中一部分专家网络。这样做的目标是同时获得较大的知识容量和较低的单次推理成本。

编程 Agent 评测在测什么

SWE-bench-Verified 是面向软件工程任务的评测集，重点不是“写一段算法题代码”，而是让模型在真实代码仓库里定位问题、修改代码并通过测试。Terminal Bench 2.0 更偏向命令行环境中的长程任务，模型需要使用终端完成多步骤操作。

这类评测比传统代码补全更接近真实工程，因为真实开发经常包含这些步骤：

flowchart TD
    A[读取需求或 Issue] --> B[理解项目结构]
    B --> C[定位相关文件]
    C --> D[修改代码]
    D --> E[运行测试或命令]
    E --> F{是否通过}
    F -- 否 --> G[分析错误日志]
    G --> C
    F -- 是 --> H[提交结果]

GLM-5 在 SWE-bench-Verified 和 Terminal Bench 2.0 上刷新开源模型表现，说明开源模型在工程 Agent 方向已经接近闭源旗舰模型的工作区间。它还完成了华为昇腾、寒武纪、昆仑芯等国产芯片适配，这对企业私有化部署很重要，因为工程 Agent 往往要接触内部代码、文档和权限系统，不一定适合完全依赖外部 API（Application Programming Interface，应用程序编程接口）。

MiniMax M2.5 的重点则是“小激活参数 + 高速推理 + Agent 训练”。它采用原生 Agent RL（Reinforcement Learning，强化学习）训练框架，并使用 CISPO 算法把训练速度提高到约 40 倍。对 Agent 来说，推理速度非常重要，因为一个任务可能包含几十次甚至上百次模型调用，单次延迟会被循环放大。

为什么速度对 Agent 特别重要

普通聊天场景里，模型生成一次答案就结束；Agent 场景里，模型经常要经历“规划—执行—观察—修正”的循环。

假设一个任务需要 40 次模型调用：

当模型被接入 IDE、终端、浏览器或自动化工作流时，速度会直接影响可用性。M2.5 宣称用 10B 激活参数达到旗舰模型能力，并把推理速度做到 Claude Opus 的数倍，本质上是在解决 Agent 落地时的成本和等待问题。

2. 图像编辑模型：从生成图片到精确修改图片

小红书基础模型团队开源的 FireRed-Image-Edit 代表了图像模型的另一个方向：图像编辑不再只是“重新生成一张相似图片”，而是要在保持主体、风格和布局的同时，按照指令准确修改局部内容。

它在 ImgEdit、GEdit 等图像编辑榜单达到 SOTA（State of the Art，当前公开评测中的最佳水平），支持的任务包括：

• 指令遵循一致性
• 文字编辑
• 风格迁移
• 多图融合
• 老照片修复
• 局部内容替换

图像编辑模型的难点在于“既要变，又不能乱变”。比如用户要求“把牌子上的英文改成中文”，模型只应该改牌子上的文字，不能顺手改变背景、人物衣服、光照和构图。

flowchart LR
    A[输入图像] --> C[图像编辑模型]
    B[编辑指令] --> C
    C --> D[编辑结果]
    D --> E[文字是否正确]
    D --> F[布局是否保持]
    D --> G[风格是否一致]

FireRed-Image-Edit 的一个关键设计是 Layout-Aware OCR-based Reward，可以理解为“感知布局的 OCR 奖励”。OCR（Optical Character Recognition，光学字符识别）负责识别图像里的文字，Layout-Aware 则要求模型关注文字所在位置、大小和布局关系。

这类奖励机制解决的是文字编辑场景里的常见问题：

图像编辑模型要真正进入设计、广告、内容生产、修复等工作流，文字准确性和局部稳定性比单纯“画得好看”更重要。FireRed-Image-Edit 的路线说明，图像模型训练正在从大规模生成数据走向更细的任务奖励设计。

3. 具身智能：VLA 模型把视觉、语言和动作连起来

机器人和自动驾驶场景里，模型不能只理解图像和语言，还必须输出动作。VLA（Vision-Language-Action，视觉-语言-动作）模型就是为这个问题设计的。

典型输入和输出是这样的：

flowchart LR
    A[摄像头图像] --> D[VLA 模型]
    B[语言指令] --> D
    C[机器人状态] --> D
    D --> E[动作序列]
    E --> F[机械臂 / 移动机器人执行]

小米开源的 Xiaomi-Robotics-0 和高德 ABot 系列，分别代表了具身智能里的两个重要方向：操作和导航。

Xiaomi-Robotics-0：用“大脑 + 小脑”拆分理解与控制

Xiaomi-Robotics-0 是一个 47 亿参数的 VLA 模型，在 LIBERO、CALVIN、SimplerEnv 等机器人评测中表现领先。LIBERO、CALVIN 和 SimplerEnv 都是常见机器人任务基准，用来测试模型在操作、泛化、环境交互中的能力。

它采用 Mixture-of-Transformers 架构，可以理解为把不同能力模块组织到同一个系统中：

• VLM（Vision-Language Model，视觉语言模型）部分像“大脑”，负责理解视觉场景和语言指令。
• Diffusion Transformer（扩散 Transformer）部分像“小脑”，负责生成平滑、高频的动作序列。

flowchart TD
    A[视觉输入] --> B[VLM 大脑]
    C[语言指令] --> B
    B --> D[任务语义与目标状态]
    D --> E[Diffusion Transformer 小脑]
    F[机器人当前状态] --> E
    E --> G[连续动作序列]
    G --> H[机器人执行]

机器人控制和聊天生成有一个根本区别：动作必须连续、平滑、及时。语言模型晚半秒输出，用户通常还能接受；机器人手臂晚半秒或动作断层，可能导致抓取失败、碰撞或物体掉落。

Xiaomi-Robotics-0 使用异步推理模式和 Λ-shape 注意力掩码来处理动作断层问题。异步推理的目标是让模型在执行上一段动作时提前计算下一段动作，减少停顿；注意力掩码则控制模型在生成动作时能看到哪些上下文，避免动作序列之间出现不自然跳变。

ABot：把操作和导航分别做成基座模型

高德发布的 ABot 系列包含两个模型：

操作任务和导航任务看起来都属于机器人，但技术难点不同。

操作任务更关注局部精细控制，比如抓杯子、开抽屉、移动物体。导航任务更关注空间理解、路径规划、社会行为约束，比如在室内避障、理解目标位置、绕开行人。

flowchart LR
    A[具身智能] --> B[操作 Manipulation]
    A --> C[导航 Navigation]
    B --> D[抓取 / 放置 / 推拉 / 工具使用]
    C --> E[定位 / 避障 / 找路 / 社交导航]

ABot-M0 通过“动作语言统一”把不同平台的轨迹数据映射到统一表示里，这样模型可以从多种机器人数据中学习共性动作。ABot-N0 则把多种导航任务收进一个 VLA 架构，重点解决导航任务之间数据格式和目标定义不统一的问题。

4. 智能眼镜接入私有 Agent：终端开始变成模型入口

Rokid Glasses 的灵珠平台支持“自定义智能体”，可以通过标准 SSE 接口接入 OpenClaw，或接入私有部署的 DeepSeek R1、Qwen3 等模型。

SSE（Server-Sent Events，服务器发送事件）是一种服务端向客户端持续推送数据的协议。它很适合大模型流式输出，因为模型可以一边生成，一边把 token 或事件返回给终端。

sequenceDiagram
    participant Glasses as 智能眼镜
    participant Agent as 自定义智能体服务
    participant LLM as 私有大模型
    participant Tools as 工具与技能

    Glasses->>Agent: 语音指令 / 快捷指令
    Agent->>LLM: 发送任务上下文
    LLM-->>Agent: 流式返回规划与回答
    Agent->>Tools: 调用文件、浏览器、IM 等能力
    Tools-->>Agent: 返回执行结果
    Agent-->>Glasses: SSE 流式推送结果

一个简化的 SSE 智能体服务可以长成这样，具体字段需要按设备平台协议调整：

from fastapi import FastAPI, Request
from sse_starlette.sse import EventSourceResponse

app = FastAPI()

async def call_private_model(prompt: str):
    # 这里可以替换成私有部署的 DeepSeek、Qwen 或其他模型
    for token in ["正在", "处理", "你的", "请求"]:
        yield token

@app.get("/agent/sse")
async def agent_sse(request: Request, q: str):
    async def event_stream():
        async for token in call_private_model(q):
            if await request.is_disconnected():
                break

            yield {
                "event": "delta",
                "data": token
            }

        yield {
            "event": "done",
            "data": "{}"
        }

    return EventSourceResponse(event_stream())

智能眼镜接入私有模型的价值主要有三点：

这种模式把智能眼镜从“固定功能设备”变成“可编排的 Agent 入口”。真正的难点不在于把模型接进去，而在于权限控制、隐私边界、工具调用审计和低延迟交互。

5. AI 数学家：从解题模型走向科研辅助系统

谷歌 DeepMind 基于 Gemini Deep Think 发布的 Aletheia，被定位为面向数学研究的 AI 系统。它在 IMO-ProofBench 上取得 91.9% 的成绩。IMO-ProofBench 是面向数学证明能力的评测，关注模型是否能给出严谨、可验证的推理过程。

更重要的信号不是刷题，而是它被用于开放问题探索：Aletheia 对 Erdős 猜想数据库中的 700 个开放问题进行系统评估，并自主解决了其中 4 个问题。Gemini Deep Think 还与专家协作解决了 18 个长期停滞的研究难题，其中一项成果被 ICLR（International Conference on Learning Representations，国际学习表征会议）2026 接收。

数学科研型 AI 和普通问答模型的区别在于，它需要处理更长的探索链条：

flowchart TD
    A[开放数学问题] --> B[理解定义与约束]
    B --> C[检索相关定理和已知结果]
    C --> D[提出证明路线]
    D --> E[推导关键引理]
    E --> F{是否自洽}
    F -- 否 --> G[发现漏洞并修正]
    G --> D
    F -- 是 --> H[形成证明或反例]
    H --> I[人工专家验证]

这类系统必须具备两个能力：

1. 长链推理稳定性：数学证明经常需要几十步甚至上百步推导，任何一步错误都可能导致结论失效。
2. 自我纠错与边界识别：遇到无法证明的问题时，模型需要承认限制，而不是生成看似合理但实际错误的证明。

AI 进入科研场景后，模型输出不能只靠自然语言“看起来合理”。证明检查、专家验证、形式化工具和可复现实验会成为必要环节。

6. 安全评估：能力越像 Agent，风险越需要重新定义

模型能力提升带来两个互相拉扯的判断。

一边是乐观判断：HyperWrite CEO 的公开观点认为，GPT-5.3-Codex 和 Claude Opus 4.6 这类模型代表 AI 能力进入新阶段，模型已经可以独立完成人类专家数小时级别的任务，并可能开始参与自身训练流程，形成递归式自我提升循环。

另一边是安全警告：Anthropic 发布的 53 页报告把 Claude Opus 4.6 的风险放到接近 ASL-4 的讨论区间。ASL（AI Safety Level，AI 安全等级）是 Anthropic 用来描述模型能力和安全要求的分级框架。报告给出的判断并不是“模型已经有稳定恶意目标”，而是“灾难性破坏风险非常低但不为零”，并且模型能力已经进入评估灰区。

这里的核心问题是：当模型具备长程规划、工具调用、代码执行和环境交互能力后，风险不再只是“说错话”。

因此，Agent 系统的安全边界需要比聊天机器人更细。一个实际可用的 Agent 平台至少要做几件事：

flowchart TD
    A[用户任务] --> B[权限检查]
    B --> C[模型规划]
    C --> D[工具调用审批]
    D --> E[沙箱执行]
    E --> F[日志记录]
    F --> G[结果返回]
    G --> H[人工复核高风险操作]

权限、沙箱、审计、人类确认不是附加功能，而是 Agent 系统进入生产环境的基础设施。

7. 对开发团队意味着什么

这些模型进展放在一起，可以得到几个比较实际的工程判断。

不要只看榜单分数，要测自己的任务

SWE-bench、Terminal Bench、LIBERO、CALVIN、ImgEdit 这些榜单能说明模型能力方向，但不能直接代表生产环境表现。开发团队需要准备自己的评测集，覆盖真实任务中的代码库、文档格式、工具链、权限规则和失败案例。

Agent 系统要按“模型 + 工具 + 权限”整体设计

单独换一个更强模型，并不等于得到一个可用 Agent。模型只是系统的一部分，工具协议、上下文管理、执行沙箱、日志追踪和失败回滚同样重要。

flowchart LR
    A[模型能力] --> D[可用 Agent]
    B[工具系统] --> D
    C[权限与安全] --> D
    E[评测与日志] --> D

如果没有工具调用记录，失败后无法复盘；如果没有权限边界，模型一次错误调用就可能影响真实系统；如果没有任务级评测，很难判断模型升级到底带来了多少收益。

开源模型的价值会继续上升

GLM-5 这类大参数开源模型和 MiniMax M2.5 这类高效率模型说明，开源和可私有化部署正在成为重要路线。对企业来说，开源模型的意义不只是降低 API 成本，还包括：

• 代码和数据不离开内网。
• 可以适配国产芯片或自有推理集群。
• 可以针对内部任务继续微调或做工具链适配。
• 可以把模型能力嵌入 IDE、终端、知识库、机器人和硬件设备。

但开源也意味着团队要自己承担部署、监控、评测和安全治理成本。

8. 核心判断

2026 年的 AI 模型竞争可以概括成一句话：模型能力正在从“生成内容”走向“完成任务”。

GLM-5 和 MiniMax M2.5 代表工程 Agent 的加速；FireRed-Image-Edit 代表图像编辑进入精确控制阶段；Xiaomi-Robotics-0 和 ABot 代表 VLA 模型向真实物理世界延伸；Rokid Glasses 的自定义智能体说明终端设备开始成为模型入口；Aletheia 展示了 AI 进入科研推理的可能；Anthropic 的风险评估提醒工程系统必须同步建设安全边界。

真正的分水岭不在于模型能否回答得更像人，而在于它能否在受控环境中持续、可靠、可审计地完成复杂任务。