AI Agent 代改关键文档，真正危险的是静默改坏底稿

你以为是在让 AI 改文档。论文里的结果更别扭：它可能一边完成指令，一边把底稿改坏。

这不是整份文件丢了，也不是 25% 的任务失败。更麻烦的是，错误稀疏、严重、静默累积。等你发现时，公式、代码、标记、引用、结构可能已经在几轮编辑里变形。

这篇论文真正戳中的，不是模型会不会写错一句话。它问的是：一个 AI agent 能不能被长期委托处理关键文档。

DELEGATE-52 测的不是写作能力，而是托管能力

论文题为《LLMs Corrupt Your Documents When You Delegate》，arXiv 编号 2604.15597，提交时间是 2026 年 4 月 17 日。

先把边界说清：这是 arXiv 预印本，不是已经同行评审的定论。它也不能推出“所有短文本生成、问答、一次性润色都不可靠”。

它测的是更窄、也更接近企业落地的一类场景：把复杂文档交给大模型，经过多轮指令、长流程编辑后，原文还能不能守住。

这张表已经说明问题。

最危险的场景不是让 AI 写一段介绍。是让它维护代码、科研材料、乐谱标记、合同条款、知识库页面。内容越结构化，越不能只看“读起来顺不顺”。

因为这些文档里的小错，不一定像错别字那样刺眼。一个标记错位、一段代码被误改、一个引用变形，后面可能牵出一串连锁问题。

受影响最大的是两类团队

第一类，是正在把 AI agent 接进文档、代码和知识库流程的团队。

如果原计划是让 agent 直接改主文档、自动提交、自动覆盖，那这篇论文至少给了一个暂停键。采购可以不必取消，但上线方式要改。先跑沙盒。先看 diff。先限制写权限。

第二类，是做企业 AI 产品和内部工具平台的团队。

卖点不能只写“端到端完成任务”。企业客户真正会问的是：改了哪里？谁批准？错了能不能回滚？关键字段有没有校验？干扰文件会不会误伤？

这里有个现实约束：模型越像一个能干员工，越容易让人放松流程。

但组织管理里从来不是“能干”就能随便改底账。人类编辑会犯错，所以成熟组织才有版本管理、审阅权限、变更记录、责任边界。AI agent 如果绕开这些制度，直接长时间操作底稿，那不是效率升级，是把风险藏进自动化里。

“差之毫厘，谬以千里。”这句老话放在普通聊天里有点重，放在晶体学、代码库、合同和乐谱里刚好。

我更在意的不是 25% 这个数本身。预印本、基准设计、评测口径都还需要更多验证。真正该盯住的是错误类型：它不是大喊一声“我失败了”，而是安静地把文档带偏。

这和一次性问答不同。一次性回答错了，人还容易怀疑。长流程委托最麻烦的地方，是人会逐步把注意力从逐字检查切到结果验收。

信任就是这么丢的。

接下来别看演示，看三道闸门

我不太买账“加上工具就好了”的说法。论文里一个刺眼点是：agentic tool use 没有改善表现。

这不等于工具没用。它说明工具不是护身符。没有验证、权限和回滚，工具调用只会让模型更方便地把错误写进文件系统。

接下来最该观察三件事。

• 产品是否默认保留原文，不直接覆盖底稿。
• 每次修改是否强制生成可审计 diff，而不是只给一段总结。
• 高风险文档是否有规则校验、分段锁定、人类确认和一键回滚。

这些功能听起来不性感。也不适合发布会上做三分钟炫技。

但生产系统靠的就是这些笨办法。铁路、电力、互联网早期都经历过类似阶段：能力先扩张，治理后补课。今天的 AI agent 不完全一样，但重复的是同一种组织惯性——新工具刚能干活，就被急着当基础设施。

这篇论文的价值，不是劝人别用大模型。它更像一条分界线：让 AI 生成内容，和让 AI 长期照看关键文档，是两种产品。

前者看智能上限。后者看可靠性下限。

企业团队现在该做的，不是急着问哪个模型赢了。论文没有给我们一个可以直接拿来采购的胜负表。更实际的问题是：你的流程里，AI 有没有权力直接改原件？有没有干扰文件？有没有长对话累积？有没有人真的看 diff？

如果答案都偏危险，那就别把 agent 放到主干流程里。先让它提建议、生成补丁、跑在副本上。等验证链条补齐，再谈长期委托。

能写，是能力。可托付，是制度和工程。两者之间，差着一整套刹车系统。