当你把文档交给大模型修改，它正在慢慢把你的文件改坏——微软 DELEGATE-52 万字拆解（深度研究 · 格帕文士风格）

一句话：微软研究院用 52 个专业领域、19 个 LLM、20 轮往返编辑测试证明了一件事——你把文档交给 AI 的时间越长，文件损坏得越严重。不是偶尔出错，是系统性腐蚀；不是小错误累积，是稀疏但致命的关键故障。

这不是一篇唱衰 AI 的论文。这是迄今为止对「委托工作流」最系统、最残酷的体检报告。读完之后，你会重新思考：vibe coding 的轻松感，到底付出了什么代价？

01 为什么这件事值得被放在解剖台上？

**委托工作（Delegated Work）**正在成为主流交互范式。vibe coding、AI 辅助写作、自动文档整理——本质都是同一件事：你把一个需要多步修改的重要文件交给 AI，然后忙别的去了。

这种模式成立的前提是信任：你相信 AI 会忠实执行，不会偷偷引入错误、删除内容、扭曲结构。

但微软研究院的 Philippe Laban、Tobias Schnabel、Jennifer Neville 在《LLMs Corrupt Your Documents When You Delegate》中提出了一个尖锐的问题：当前 LLM 真的值得被信任吗？

论文核心数据：

• 52 个专业领域，从 Python 代码到音乐乐谱，从会计账簿到晶体学文件
• 19 个 LLM，覆盖 OpenAI、Anthropic、Google、Mistral、xAI、Moonshot 六大家族
• 20 轮交互模拟长程委托工作流
• 前沿模型平均损坏 25% 内容，所有模型平均损坏 50%

这不是「偶尔出点小错」。这是「你把文件交给 AI 改 20 次，回来的东西已经面目全非」。

02 DELEGATE-52：一个专门设计的「残酷体检」

2.1 往返中继模拟（Round-Trip Relay）

传统评估的问题是：你怎么知道 AI 修改后的文件还保留着原始内容？

DELEGATE-52 的解法是往返编辑：

种子文档 s → [前向编辑 σ] → 变换文档 t → [反向编辑 σ⁻¹] → 重建文档 ŝ

理想情况下，ŝ 应该等于 s。如果 AI 在前向或反向编辑中引入了错误，重建文档就会偏离原始。

评估指标 RS@k：k 次交互后的重建分数。100% 表示完美恢复，0% 表示完全损坏。

2.2 为什么往返评估比单次评估更残酷？

单次评估的问题：AI 把文件改好了，你看着觉得 OK，但可能它偷偷删了一段、改了一个数字、换了一个专业术语。你如果不是领域专家，根本发现不了。

往返评估的妙处：通过可逆操作，把「隐性损坏」变成「可测量偏差」。 如果 AI 在编辑时引入了一个错误，反向编辑时这个错误会被放大或固化，最终体现在重建分数上。

2.3 52 个领域：不是只测代码

关键设计：

• 真实文档（非合成），2-5k tokens
• 干扰上下文（8-12k tokens），模拟真实检索不完美场景
• 领域特定评估：食谱比较食材/步骤/提示的权重；乐谱比较音符/节奏/调性

03 核心实验结果：数据说话

3.1 19 个 LLM 的排名表（20 轮交互后）

最差的模型（GPT 4o, GPT 5 Nano）：RS@20 仅 10-15%，意味着 85-90% 的内容被破坏。

3.2 前沿模型的退化轨迹

Gemini 3.1 Pro:  96.8% → 93.5% → 86.6% → 82.2% → 80.9%
                    (2轮)   (4轮)   (10轮)  (14轮)  (20轮)

Claude 4.6 Opus: 94.2% → 90.1% → 79.5% → 76.3% → 73.1%

GPT 5.4:         94.3% → 89.3% → 79.4% → 74.6% → 71.5%

关键洞察：退化不是线性的。 前几轮可能掉得慢，但从第 10 轮开始加速。论文称之为「单调下降，无平台期」（monotonic decline, no plateau）。

3.3 领域差异：Python 是唯一「安全区」

Gemini 3.1 Pro 是最强模型，但也只在 11/52 个领域达到「就绪」标准（RS@20 ≥ 98%）。

这意味着：即使最好的 AI，在 80% 的专业领域都不值得被完全信任。

3.4 最反直觉的发现：短期性能完全不能预测长期性能

结论： 你 demo 时测的那 2-3 轮交互，完全不能说明 AI 在长程工作流中的表现。短程模拟严重低估退化程度。

04 关键发现：工具使用反而使情况更糟

4.1 Agent 框架的讽刺

论文测试了「给 AI 工具」vs「不给 AI 工具」的对比。结果：

Agent 框架平均额外退化 6%。

为什么？

1. 上下文开销：工具调用消耗 2-5× 更多输入 tokens，长上下文性能下降
2. 任务特性：DELEGATE-52 的任务需要文本理解与推理，不是简单程序执行
3. 工具使用模式：即使给了代码执行工具，AI 仍然偏好手动写文件（GPT 5.4 仅 45% 用代码执行）

讽刺的结论： 我们以为给 AI 更多工具会更强，但在复杂文档编辑场景下，更多工具 = 更多出错机会 = 更多退化。

4.2 复合效应：三个因素叠加

文档大小：

• 1k tokens → 4k tokens：RS@20 从 91.4% 降到 79.0%（-12.4%）
• 1k tokens → 10k tokens：RS@20 从 91.4% 降到 59.9%（-31.5%）

关键机制：每增加 1k tokens，2 轮后退化 0.7%，但 20 轮后退化 3.6%——放大 5 倍。

交互长度：

• GPT 5.4：RS@20=71.5% → RS@50=62.9% → RS@100=58.7%
• 持续下降，无平台期。

干扰文件：

• 短期效应小（2 轮仅 +0.4-4%）
• 长期效应大（20 轮后 +2-8%）

结论：文档越大、交互越长、干扰越多，退化越严重。而且这些因素不是简单相加，是复合放大。

05 损坏模式：前沿模型「腐蚀」，弱模型「删除」

5.1 两种损坏类型

论文把损坏分解为「删除」和「腐蚀」：

删除：内容元素直接丢失（如少了一个食材、缺了一段代码）。
腐蚀：内容存在但错误（如 200g 黄油变成 800g、音符从 C 变成 D、代码逻辑被改写）。

5.2 为什么腐蚀更危险？

删除是显性的——你一眼就能发现「这里缺了东西」。
腐蚀是隐性的——文档看起来完整，但关键数据已经被悄悄改了。

前沿模型不是「死于千刀」（小错误累积），而是「死于要害」（稀疏但严重的关键错误）。

论文统计：前沿模型约 50-55% 的往返编辑在 20 轮中至少经历一次关键错误，而关键错误解释了约 80% 的总退化。

06 对行业的冲击：三个层面的反思

6.1 对 AI 用户：vibe coding 的隐性代价

vibe coding 的轻松感建立在「AI 会帮我搞定」的信念上。但 DELEGATE-52 揭示了一个残酷现实：

你把文档交给 AI 改的轮数越多，文件越不像原来的样子。而且最危险的损坏不是「缺了一段」，是「这段还在，但已经被改了」。

实用建议：

• Python 可以相对放心，其他领域必须逐轮检查
• 短程 demo 不可信，20 轮后的表现才是真正的表现
• 给 AI 工具不等于给 AI 能力，在文档编辑场景可能适得其反

6.2 对 AI 开发者：训练目标的重新设计

论文指出，现有训练主要优化「指令遵循」，但忽略了「内容保留」。

问题： 如果奖励函数只关心「有没有完成任务」，模型可能学会「不择手段完成任务」——包括偷偷删除难处理的部分、简化复杂结构、替换不确定的内容。

解法： 需要联合优化「指令遵循」和「内容保留」，防止奖励黑客（reward hacking）。

6.3 对评估者：长程基准的必要性

现有基准大多测的是「单轮表现」或「短程交互」。DELEGATE-52 证明：

短程性能完全不能预测长程可靠性。

这意味着：

• 排行榜上排名高的模型，不代表在长程工作流中更可靠
• 需要更多像 DELEGATE-52 这样的长程、多域、真实文档基准
• Agent 评估和 LLM 评估应该统一，而非分离

07 局限与追问

7.1 论文自身的局限

作者明确承认：

1. 单轮交互：实际用户通过多轮对话逐步明确意图，多轮设置可能表现更差
2. 规模低估：文档 3-5k tokens、干扰 8-12k tokens、20 次交互——实际工作规模更大
3. 可逆任务约束：仅限文档编辑；任务必须可逆
4. 基本 Agent 框架：工具使用实验用的是基础框架，非 SOTA agent

7.2 三个追问

追问一：往返评估是否低估了真实损坏？

往返评估要求任务可逆。但真实工作中很多任务不可逆（如「把报告改得更正式」）。如果这些不可逆任务也引入同样程度的错误，真实损坏可能比论文测的更糟。

追问二：腐蚀错误的可检测性

论文测的是「重建分数」，不是「人类能否发现错误」。一个被腐蚀的文档可能 RS@20=70%，但人类专家可能一眼看出问题，也可能完全没注意到。腐蚀错误的「隐蔽性」本身就是一个更危险的问题。

追问三：快速进步的乐观信号

GPT 4o（2024.11）到 GPT 5.4（2026.3），16 个月内 RS@20 从 14.7% 提升到 71.5%。进步速度极快。但这个进步曲线能否持续？以及，即使达到 90%+，在 52 个领域中是否都能达标？

08 总结：信任是需要被测量的

LLM 委托工作流的可靠性现状

┌─────────────────────────────────────────────────────────┐
│  现状：前沿模型在 20 轮交互后平均损坏 25% 内容               │
│  只有 Python 领域可以相对放心（17/19 模型 ≥ 98%）           │
│  80% 的专业领域存在严重退化（≥ 20%）                        │
├─────────────────────────────────────────────────────────┤
│  退化模式：                                               │
│  • 弱模型 → 删除为主（显性，易发现）                        │
│  • 前沿模型 → 腐蚀为主（隐性，难发现）                       │
├─────────────────────────────────────────────────────────┤
│  影响因素（复合放大）：                                    │
│  • 文档大小 ↑ → 退化 ↑（10k tokens 比 1k 多退化 31.5%）    │
│  • 交互长度 ↑ → 退化 ↑（100 轮比 20 轮多退化 ~13%）         │
│  • 干扰文件 ↑ → 退化 ↑（长期效应更显著）                    │
├─────────────────────────────────────────────────────────┤
│  反直觉发现：                                             │
│  • 工具使用平均额外退化 6%                                │
│  • 短期性能完全不能预测长期可靠性                            │
│  • 退化单调递增，无平台期                                   │
└─────────────────────────────────────────────────────────┘

一句话收尾： 微软这篇论文的价值，不在于它告诉我们「AI 会出错」——这谁都知道。它的价值在于量化了出错的程度、刻画了出错的方式、揭示了出错的规律。当你下次把重要文档交给 AI 修改时，记住这个数据：20 轮后，最好的模型也会损坏你 19% 的内容。而你，可能根本发现不了。

参考

• 论文：LLMs Corrupt Your Documents When You Delegate (arXiv:2604.15597)
• 作者：Philippe Laban, Tobias Schnabel, Jennifer Neville
• 机构：Microsoft Research
• 发表时间：2026-04-17
• 代码/数据：https://github.com/microsoft/DELEGATE52
• 微软官方博客：https://www.microsoft.com/en-us/research/blog/further-notes-on-our-recent-research-on-ai-delegation-and-long-horizon-reliability/

#tag #DELEGATE52 #LLM #委托工作 #文档编辑 #可靠性 #vibecoding #长程交互 #基准测试 #微软研究院 #小凯