前沿模型在长工作流里会悄悄破坏你的文档。不是偶发，是系统性问题。
Philippe Laban（Salesforce Research）、Tobias Schnabel 和 Jennifer Neville 在 arXiv 上发布了 DELEGATE-52 基准测试，用 52 个专业领域、19 个 LLM 做了一次大规模实验。结论不太好看：即使是 Gemini 3.1 Pro、Claude 4.6 Opus、GPT 5.4 这个级别，长工作流结束时平均有 25% 的文档内容被破坏。
什么是"破坏"
这里的"破坏"不是指模型返回乱码。是指模型在接收委托任务（比如编辑一份文档、修改一段代码、更新一份报告）后，在没有被告知的情况下，引入错误或删除了原本正确的内容。
稀疏，但致命。
DELEGATE-52 模拟的是真实的长委托工作流：你给 LLM 一份文档，让它做一系列修改，然后检查结果。52 个领域包括编码、晶体学、音乐记谱等，跨度很大。
结果：
- 前沿模型（Gemini 3.1 Pro、Claude 4.6 Opus、GPT 5.4）：平均 25% 内容在长工作流结束时被破坏
- 其他模型：失败率更高，部分模型在长工作流后期几乎不可用
- Agentic tool use 并没有改善表现：给模型加上工具调用能力，在 DELEGATE-52 上的表现没有提升
- 文档越大，破坏越严重：文档规模和交互长度与错误率正相关
- 干扰文件会加剧问题：工作目录里放几个不相关的文件，模型的错误率直接往上走
问题的核心
论文给出的解释是：当前 LLM 在委托场景中是不可靠的代理。它们会引入"稀疏但严重的错误"，这些错误在长交互中不断累积。
这不是一个可以通过"换更好的模型"解决的问题。论文测试的已经是当前最强的模型了。问题的根源在于 LLM 的架构特性——它们是概率模型，不是确定性引擎。在短对话里，这种不确定性可以被接受；在长工作流里，每次调用都是一次掷骰子，掷多了总会出问题。
更烦人的是，这些错误是静默的。模型不会告诉你"我把第三段的公式改错了"。它只是改了，然后自信满满地交回来。
对你的影响
如果你在用 LLM 做文档编辑、代码重构、报告更新这类委托任务，需要注意：
短任务问题不大。 修改几行代码、调整一个段落，前沿模型的表现是可靠的。
长工作流需要人工介入。 让 LLM 连续修改一份 50 页的文档，中间不检查，最终结果大概率有你不想要的改动。
干扰文件是个坑。 如果你的工作目录里混杂了不相关的文件，模型更容易犯错。保持工作环境的干净不只是代码规范问题，也是安全問題。
工具调用不是银弹。 这篇论文明确指出，加上工具调用能力并没有改善委托任务的表现。不要以为给 Agent 配上文件读写工具就能自动解决文档可靠性问题。
我的判断
这篇论文的价值在于它用大规模数据戳破了一个幻觉："前沿模型已经足够可靠，可以放心把文档交给它"。
现实是，对于需要准确性的委托任务，当前最好的做法仍然是"LLM 生成 + 人工审核"。不是 LLM 不够强，是它的概率本质决定了它不适合做需要 100% 确定性的工作。
DELEGATE-52 的意义不在于告诉我们 LLM 有多差，而在于给出了一个可以量化的基准。25% 的破坏率是一个起点，不是终点。下一次模型发布时，我们可以用同一个基准测试来跟踪进步。
只是在此之前，别把你的重要文档完全交给 LLM 托管。
主要来源：
- LLMs Corrupt Your Documents When You Delegate, Philippe Laban et al., arXiv:2604.15597
- Hacker News 讨论