当编码代理比我们更快时，Git diff 还是适合人类审查的正确工具吗？

我一直在思考一个问题，随着编码代理变得更快和更自主，这个问题似乎变得越来越重要。传统的代码审查假设开发者主要改变的是代码。有人写代码，另一个人查看差异，运行测试，然后我们决定是否合并。但代理能做的远不止产生一个差异。在一个任务中，它可能：运行数十个 shell 命令、安装或移除依赖、启动后台进程、访问网络、修改本地配置、运行迁移、与 Git/GitHub 交互、生成子代理、失败、改变计划并重试、触及最终差异中未出现的内容。此时，Git diff 只是代理实际所做之事的一个投影。显而易见的答案是'查看转录/工具日志'，但我认为这也不具备扩展性。如果代理在几分钟内进行 100 次工具调用并更改 20 个文件，阅读整个执行跟踪在很大程度上违背了拥有代理的初衷。这让我想知道代理工具链的人类界面是否仍然不发达。今天的工具链通常从它为代理做什么的角度讨论：工具、权限、上下文、沙箱、子代理、内存、重试、验证等。但也许一个成熟的工具链也需要为监督它做一些事情：将大量的代理活动转化为人类能够真正推理的内容。例如，在一个任务之后，我可能更关心这样的问题：代理被允许做什么？它实际做了什么？它改变了什么持久状态？它是否执行了任何外部或高后果的操作？验证实际运行了什么？它在哪里偏离了原始计划？系统能证明什么，什么是仍不确定的？当某些内容看起来可疑时，我能深入查看确切的差异/命令/跟踪吗？类似于：重要部分是这些事实来自运行时/工具证据，而不仅仅是代理说'这是我所做的'。我还没有提出具体的产品或仪表板。我主要想知道，随着代理吞吐量的增加，人类审查的单位是否需要向上移动。而不是审查每一行和每一个动作，也许人类越来越多地审查代理的后果、决策、证据和例外情况，代码和原始跟踪作为深入查看的选项。对于已经大量运行编码代理或构建自己的工具链的人：在信任代理的工作之前，你实际想检查什么？你是否仍然主要依赖 Git diff + 测试？你检查工具历史吗？你构建了摘要、检查点、沙箱、审计日志、审批门或其他东西吗？你认为有用压缩和误导性的'一切正常'仪表板之间的界限在哪里？