摘要：一篇新论文提出，当我们让 LLM 长链路处理文档时，文档内容会发生逐步退化。更危险的是，这种退化常常“看起来还像原文档”，但数字、引用、结构、术语、关系和细节已经悄悄变了。
过去一年，很多人对 LLM 的使用方式发生了变化：不再只是问答、润色、翻译，而是把一整份文档、一组文件，甚至一个工作目录交给模型，让它“帮我改完”“帮我整理”“帮我重构”“帮我提取”。这种模式可以叫做“委托式工作”：人提出目标，AI 负责执行过程。听起来，这是知识工作自动化的自然下一步。
但一篇新论文把这个假设敲了一记警钟。Philippe Laban、Tobias Schnabel 和 Jennifer Neville 在 arXiv:2604.15597《LLMs Corrupt Your Documents When You Delegate》中提出：当我们让 LLM 长链路处理文档时，文档内容会发生逐步退化。更危险的是，这种退化不一定表现为明显的删除或格式崩坏，而常常是“看起来还像原文档”，但数字、引用、结构、术语、关系和细节已经悄悄变了。论文将其概括为：当前 LLM 在委托式文档工作中仍是不可靠的代理。
这件事之所以重要，是因为很多真实业务并不要求 AI 写一篇全新的文章，而是要求它“保留原意地修改已有材料”。比如合同审阅、财务表格整理、科研论文改写、代码配置修改、字幕时间轴调整、乐谱转换、医学记录汇总、政策文档抽取等。这里的关键不是“生成得像不像”，而是“有没有把原始含义完整保存下来”。只要模型在第 3 次、第 7 次、第 15 次修改中悄悄改错一个关键事实，后续所有操作都可能建立在错误之上。
一、为什么“委托式文档工作”特别危险？
论文的核心实验叫 DELEGATE-52。它不是只测一两个写作任务，而是构建了一个覆盖 52 个专业领域的长链文档编辑基准，包括 coding、crystallography、genealogy、music sheet notation 等领域；论文还提到其包含 310 个工作环境，每个环境由真实文档、干扰上下文和 5 到 10 个复杂编辑任务组成。
这比普通“让模型改一句话”的测试更接近真实办公场景：用户给出高层指令，模型在包含上下文和文件的环境里执行任务，之后继续下一轮。
研究者采用了一种很聪明的评测方式：可逆编辑的 round-trip relay。简单说，先让模型执行一个正向编辑，比如“把表格按类别拆分”；再让它执行逆向编辑，比如“把拆分后的内容合并回原始形式”。如果模型完美执行，最终文档应该回到原状。这样就不需要人为为每个任务写标准答案，只要比较 round-trip 之后的文档与原始文档是否语义等价，就能衡量损坏程度。论文进一步把多个 round-trip 串起来，模拟长时间、多轮委托工作。
二、问题到底有多严重？
结果并不乐观。论文报告，在 19 个 LLM 的大规模实验中，即使是前沿模型，在 20 轮委托交互后也平均损坏约 25% 的文档内容；所有模型平均退化约 50%。论文中特别强调，这些错误是“稀疏但严重”的：不是每一步都大面积崩坏，而是某些关键位置突然出错，然后错误在长链路里继续累积。
这就是为什么短 demo 往往显得很好：前两三轮可能没问题，但真实办公流程不是两三轮，往往是十几轮、几十轮，还夹杂着文件切换、需求追加和上下文干扰。
更值得注意的是，工具并没有自动解决问题。研究者实现了一个基础代理框架，包含文件读取、写入和代码执行工具，并测试工具使用是否能降低退化。论文结论是，在这个基础 harness 下，所测试模型并未从 agentic tool use 中受益；相反，工具调用带来额外上下文和交互开销，模型平均每个任务会调用 8 到 12 次工具，输入 token 消耗也增加。
这并不等于“所有工具代理都没用”，但它说明：只给模型 read_file、write_file、run_python，并不能神奇地保证文档保真。代理系统设计本身需要严肃工程化。
三、为什么它会“看起来没问题”，却已经错了？
社区讨论也指出了这个限制。Hacker News 上有评论者质疑论文中的工具实验，认为基础工具 harness 可能只是把“整份文档读入再整份写回”的 round-trip 多包了一层；更成熟的编辑代理通常会使用搜索、精确替换、局部插入等“外科手术式”编辑，而不是让模型重新生成整份文件。
这个批评是有价值的：论文并没有证明“任何 AI 编辑系统都必然失败”，它证明的是“当前模型在这种委托式长链文档处理设置下并不可靠”。
但这个限制并不会削弱论文的现实意义。因为大量普通用户、企业内部工具和低成本 agent 产品，恰恰就是用类似方式工作：把文件塞进上下文，让模型读完、理解、再输出修改后的版本。用户看到的是一份格式完整、语气自然、段落顺滑的文档，于是很容易以为“没问题”。
可真正的问题不在文风，而在语义保真度：一个数值从 128.9 变成 125，一个引用被替换，一个条件被省略，一个“仅适用于 A 场景”的限定语消失，肉眼未必立刻发现，业务后果却可能很大。
四、退化为什么会在真实场景里更严重？
论文还指出，退化会受到多个因素放大：文档越长、交互轮次越多、干扰文件越多，问题越严重。作者在限制部分也说明，实验中的文档规模、干扰上下文和 20 轮交互其实仍低于许多真实世界任务的规模，因此真实场景可能更复杂。
这点尤其关键。很多公司在评估 AI 工具时，只做“单轮任务测试”：让模型改一份文档，看起来结果不错，于是上线。但真正的风险出现在长期使用中：一次小错被下一轮吸收，再被下一次摘要压缩，再被下一次改写包装成“合理叙述”。
这可以理解为一种“语义 JPEG 退化”。图片重复压缩时，最初只是边缘有点糊，后来细节逐渐消失，最后图像仍然像原图，但已经失真。LLM 文档委托也是类似：第一轮改写保留大意，第二轮删掉限定条件，第三轮把表格解释换成更顺滑但不准确的说法，第十轮以后，文档表面仍然完整，核心含义却已经偏移。不同的是，图像压缩痕迹肉眼可见，而语义退化常常隐藏在专业细节里。
五、那还能不能把文档交给 LLM？
这是否意味着不能用 LLM 处理文档？不是。更合理的结论是：不要把 LLM 当成可以独立托管文档真实性的黑箱代理。它适合做建议、草稿、局部改写、结构化辅助和检查清单，但不适合在缺乏校验机制的情况下反复接管完整文档。尤其是法律、金融、科研、医疗、合规、工程配置等场景，不能只看输出是否“通顺”，而要检查输出是否“仍然等价”。
实践上，可以采取几条防线。
第一，尽量避免整文重写。让模型提出补丁、diff、局部替换，而不是重新生成完整文件。
第二，保留版本控制，任何 AI 修改都应能追踪来源、回滚和逐行审阅。
第三，把任务拆成可验证的小步骤，每一步都配合规则检查、单元测试、数值校验、引用核对或人工复核。
第四，对关键事实建立外部真源，比如数据库、原始表格、合同条款编号、论文引用列表，而不是让模型凭上下文“记住”。
第五，评估 AI 系统时要做长链测试，不要只测一轮漂亮输出；论文也强调，短交互表现并不能可靠预测 20 轮后的表现。
六、真正的问题不是会不会错，而是错了能不能发现
这篇论文真正挑战的，不是“LLM 有没有用”，而是“我们应该怎样信任它”。过去很多产品叙事把 AI 描述成一个“数字员工”：你交代目标，它自动完成。但文档工作并不是单纯生成文本，而是维护一个不断演化的信息对象。这个对象有历史、有约束、有隐含关系、有不能丢的边界条件。当前 LLM 最大的问题是，它擅长制造连续、合理、自然的文本，却不天然保证每一次编辑都是保真变换。
所以，未来可靠的 AI 文档系统，可能不会是“更会写”的聊天机器人，而是“更会受约束”的编辑系统：模型负责理解意图和提出操作，工具负责精确执行，校验器负责发现偏差，人类负责关键决策。换句话说，AI 可以进入文档工作流，但不能独占文档真相。
DELEGATE-52 给出的警示很清楚：委托越深，信任越需要工程化。把文档交给 LLM 之前，我们应该先问一个问题：这次修改失败时，我能不能发现？如果答案是否定的，那么真正危险的不是模型会犯错，而是它会用一份看似正确的文档，把错误安静地带到下一轮。