当你把文档交给大模型修改，它正在慢慢把你的文件改坏——微软 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 个领域：不是只测代码

大类	数量	代表性领域
代码与配置	11	Python, Docker, Makefile, JSON, Graphviz
科学与工程	11	晶体学, 量子计算, 蛋白质结构, 卫星数据
创意与媒体	11	乐谱, 3D 模型, 编织图案, LaTeX
结构化记录	11	会计账簿, 家谱, 地理数据, 电子表格
日常	8	食谱, 公交时刻表, 地标, 求职信息

关键设计：

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

---

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

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

排名	模型	RS@20	退化幅度
1	Gemini 3.1 Pro	80.9%	19.1%
2	Claude 4.6 Opus	73.1%	26.9%
3	GPT 5.4	71.5%	28.5%
4	GPT 5.2	66.1%	33.9%
5	Kimi K2.5	64.1%	35.9%
6	Claude 4.6 Sonnet	64.0%	36.0%
7	GPT 5.1	60.5%	39.5%
8	Grok 4	59.3%	40.7%
9	o3	55.9%	44.1%
10	o1	48.3%	51.7%

最差的模型（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 是唯一「安全区」

领域类型	表现	原因
Python	✅ 17/19 模型 ≥ 98%	结构化、语法严格、训练数据丰富
其他代码（DBSchema, Docker）	较好	结构化，但比 Python 复杂
自然语言（Recipe, Fiction）	❌ 差	词汇丰富、结构松散、歧义多
小众专业（MusicSheet, Weaving）	❌❌ 最差	专业符号、训练数据极少

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

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

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

对比	2 轮后	20 轮后	差距
GPT 5 vs Kimi K2.5	91.5% vs 91.1%	48.3% vs 64.1%	15.8% 逆转
Gemini 3 Flash vs Mistral Large 3	76.0% vs 82.4%	35.8% vs 35.5%	早期落后 6.4%，后期反超

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

---

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

4.1 Agent 框架的讽刺

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

模型	无工具 RS@20	有工具 RS@20	额外退化
GPT 5.4	71.5%	68.3%	-3.2%
GPT 5.2	66.1%	63.4%	-2.7%
GPT 5.1	60.5%	52.1%	-8.4%
GPT 4.1	49.5%	40.4%	-9.1%

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 两种损坏类型

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

模型梯队	删除占比	腐蚀占比	模式
弱模型（GPT 4o, Nano）	70-73%	27-30%	删除为主
前沿模型（Gemini, Claude, GPT 5.4）	22-27%	73-78%	腐蚀为主

删除：内容元素直接丢失（如少了一个食材、缺了一段代码）。 腐蚀：内容存在但错误（如 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 #长程交互 #基准测试 #微软研究院 #小凯