ARTICLE · 1065332
Agent 改完的文档,凭什么让你敢签收?
Agent 改完的文档，凭什么让你敢签收？
核心问题
当一个 Agent 对你说「我已经把这份预算表改好了」，你凭什么相信它？
这不是一个关于模型能力的问题。今天的 Agent 确实能改文档、能写公式、能填数据——能力早就不是瓶颈。真正的瓶颈在签收那一刻：改动是对的，你无从核实；改动是错的，你不一定看得出来。
问题可以收得更紧一点：当执行者从人换成 Agent，「可信」是由什么来保证的？
一、能改，从来不是难点
先看一个被普遍低估的事实：一个 Agent 通过 API 把数据写进单元格，接口返回 success，这件事的技术含量接近于零。
难度在后面。结构化接口能告诉你的只有「值写进去了」，它告诉不了你三件事：
▢列宽是不是被撑爆了？
▢自动换行是不是把长备注挤成了三行？
▢原来精心设计的合并单元格是不是被一次批量写入破坏了？
这三件事有一个共同点：它们在数据层完全合法。 没有一个字段错了，没有一个校验规则被违反，但那份表在人眼里已经不能用了。
这一点不是旁观者的推测。Univer 在官方文档里把它写得很直白——结构化输出无法完整描述页面布局。正是这句判断，决定了它整套 Agent 能力的形状：光有结构化验证不够，必须再加一条能回到像素的路。
二、一条看不见的裂缝
把这条裂缝放大来看。
过去人类在办公软件里编辑，走的是一个天然带护栏的流程：动手改，眼睛看，觉得不对按撤销。编辑、观察、回滚三个动作在同一个界面里，由同一个人的同一双手完成。
Agent 插进来之后，这三个动作被拆开了：改的是服务端的一次 API 调用，观察的是返回的一段 JSON，回滚……很多时候根本没有回滚，只有「再让它改一次，希望这次对」。
裂缝就长在这里：
验证的证据和产出的事实来自同一个源头，于是它无法自证。
一个结构化断言说「我写对了」，另一个结构化断言也说「我写对了」，两份同源的证据说同一句话，不构成交叉验证——它们可能共享同一个错误前提，比如对「这个单元格该有多宽」的理解从一开始就是错的。
三、四个动作，把不可信的改动变成可签收的改动
Univer 给出的解法由四个动作组成，每一个都在补上裂缝的一段。
01
第一个动作：让改动走同一条账。
它的服务端 headless 运行时和浏览器编辑，共享同一个核心、同一套命令事务层。这意味着 Agent 的每一次改动不是「绕过界面偷偷改了文件」，而是「从同一个收银台过了一笔账」。账过了，界面里就看得见，历史里查得到，撤销也按得下去。
这一步的价值容易被忽略：它把 Agent 的改动从「一次不可见的数据改写」变成了「一笔可审计的事务」。
02
第二个动作：改动先落在草稿里。
Agent 在隔离的 Worktree 分支上工作，改多轮、自己检查、再改。这些改动不碰主文档。做错了，代价是丢掉一个草稿；做对了，才进入下一步。
03
第三个动作：用三种不同介质各取一份证据。
这是整套设计里最值得学的一处。验证不是把同一件事换个说法再断言一遍，而是从三个互不重叠的角度取证：
结构化读取，确认值对不对；渲染截图，确认人眼看到的样子对不对；布局诊断，用结构化方式指出列宽、换行、遮挡这类版面问题对不对。
前一份是数据层的真，后两份是视觉层的真。两种真都成立，才叫改完了。
04
第四个动作：让人签收，而不是让人抽查。
草稿做完了不等于落地。最后一步是人在界面里看 diff，然后做两个选择之一：Merge，或者 Reopen 打回重改。
这里的分工很清楚：Agent 是执行者，人是签收人。签收这个动作不能外包给它自己的日志。
四、这套办法站在哪些已知规律上
它不新，它只是把三样老东西装进了一个新场景。
01第一样是验证独立性。 在工程验证与确认体系里有一条老规矩：验证手段不能和被验证对象共享同一个前提，否则验证退化成复述。Univer 之所以要在结构化断言之外再加截图和布局诊断，本质就是在恢复验证的独立性。
02第二样是复式记账。 会计能审计，不是因为账记得漂亮，而是因为每一次变动都留下第二份可以交叉核对的记录。单式记账时代，账是记给记的人看的；复式记账之后，账是记给审的人看的。把 Agent 的改动放进共享命令层，做的是同一件事：让改动从一开始就是记给审阅者看的。
03第三样是代码评审的那套闸门。 分支隔离改动、diff 呈现变化、评审决定合并——软件工程花了几十年才把「人能安全地接收他人的改动」这件事做顺。Agent 生成文档，面对的是同一个问题：如何安全地接收一个非人类执行者的改动。答案是同一套：隔离、可读的差异、人工闸门。
五、这条规律在哪里失效
必须说清楚适用边界，否则容易用错。
第一种失效场景是纯数据管道。 如果这份产出不需要人读，只读数值、结果直接入库、下游是另一个程序，那么结构化断言已经足够，截图和布局诊断就是纯粹的浪费。给它加三路验证，是在给不需要的门装锁。
第二种是极致简化的交付物。 单值写入、纯文本追加这类改动，隔离草稿加三路验证的工程成本明显高于收益。护栏的厚度应该匹配交付物的复杂度。
第三种是能力受限的形态。 这套闭环依赖 Web 界面与协同能力。如果只跑命令行，实时页面、共享修订、Worktree 都会缺位——第三、四个动作直接不存在，剩下的只有改动和断言。这不是设计缺陷，是提醒：选了哪种形态，就等于选了哪几道护栏。
六、一条可以带走的判断
把整件事压成一句话：
当执行者变得自主，验证就必须变得独立。
这条规律不限于办公文档。Agent 生成 UI、改代码、写报表、填合同，只要产出最终要被一个人接收并签字，判断标准都一样——看这套流程有没有一条能回到「人真正看得到的形态」的验证路径，以及一条改错了能退回去的路。
只有「操作成功返回」的方案，把验证的责任推给了签收的人。而签收的人，往往既没有时间、也没有工具去发现那条裂缝。
能改，是能力问题；敢签收，是工程问题。这两件事之间隔着的，就是护栏。
— END —