你让 AI 写一份计划，执行到第三步才发现前提错了。常见模型更擅长顺着已有文字继续写，却不容易在同一次生成中回头删掉错误步骤，再把缺失内容插回原位。LLaDA2.2-flash 想换一种做法：让 Agent 不只会“续写”，也能像改稿一样直接编辑已有文本。这让它值得关注，但目前公开材料只说明了设计和规格，还没有实验足以证明它确实更会规划或改代码。
不再只从左往右写
主流的自回归模型会根据已有 token 预测下一个 token。token 可以理解为模型处理文字时使用的基本片段。这个过程像沿着一条路不断向前铺砖，已经铺好的部分通常不便在同一次生成中直接返工。
扩散语言模型走的是另一条路线：它从不完整或受到扰动的文本开始，经过多轮修正得到结果。LLaDA2.2-flash 又把 Levenshtein Editing 引入这一过程。Levenshtein Editing 是一种描述文本变化的方法，核心操作包括插入、删除和替换。模型页称，它通过 DELETE 和 INSERT 两种控制 token，让扩散解码可以移除多余内容，也可以先腾出位置，再补入新内容。
直观地说，模型不必把整份计划推倒重写。它可以删掉失效的一步，在中间插入新的工具调用，然后继续调整其余部分。这种生成方式与 Agent 的任务很贴：Agent 是能够调用工具、分步骤完成目标的 AI 系统，而多轮交互、规划、代码编辑和错误纠正，本来就经常需要反复修改已有内容。
编辑动作也要学会看结果
只有编辑按钮还不够，模型还要知道怎样改才有用。该模型页称，团队提出了 L-EBPO，全称是 Levenshtein Editing ELBO-based Block-level Policy Optimization。它是一种块级策略优化方法，利用 Agent 与环境交互后得到的奖励，训练模型在多轮工具调用中进行编辑和错误纠正。
这一步的思路是把“改稿”与任务结果连起来：不是只判断一段文字是否通顺，还要看修改后的工具调用能否得到更好的环境反馈。不过，公开材料没有披露奖励如何设置、训练使用了哪些 Agent 环境，也没有给出与其他方法的对比。
128K 上下文怎样跑起来
模型页把 LLaDA2.2-flash 描述为一个 MoE 扩散语言模型。MoE，即“专家混合”，会让不同的模型子模块处理不同输入，而不是每次都启用全部参数。页面列出的规格包括：128K token 上下文、100B 非嵌入参数、32 层和 32 个 attention heads；它采用 RoPE 位置编码，词表大小为 157,184。
为了面向长上下文 Agent 工作负载，模型还引入 Block Routing。它在 diffusion block，也就是扩散过程的文本块层级，限制需要激活的 MoE 专家。页面将其定位为提高长上下文效率的设计，但没有公布速度、显存占用或成本数据，因此目前只能确认结构思路，不能确认效率优势。
真正值得追问的是能力，而不是结构
LLaDA2.2-flash 的意义，在于把“生成”重新表述为“持续编辑”。如果 Agent 的工作本来就包括发现错误、修改计划和修补代码，那么允许模型直接插入和删除，确实比只能一路续写更贴近任务形态。
但结构适合某类任务，不等于能力已经提升。模型页将它称为 LLaDA2 系列迈向 Agent 应用的第一步，并提到长上下文工具调用、多轮交互和稳健纠错。这些仍是团队的产品定位。没有 benchmark、基线和第三方评测，我们尚不能判断它是否比自回归模型规划得更好、代码改得更准，或在多轮任务中更少犯错。
局限与未知
- 目前全部信息来自 inclusionAI 的单一 Hugging Face 模型页，且供稿元数据把来源标成 Reddit，实际链接却指向该模型页；文中的规格尚无独立信源印证。
- 材料没有提供 benchmark、对照基线、实验设置或第三方评测，无法验证“高效”和“稳健纠错”等效果表述。
- 技术报告、训练环境和具体案例均未包含在供稿中，因此还看不出 DELETE、INSERT 与 L-EBPO 在真实 Agent 任务里分别贡献了多少。