Agent Workload Visibility

采用 Copilot、Cursor、Claude Code 或类似工具的工程团队，应在试点项目里加一层轻量级追踪：记录聊天提示、细粒度编辑、文件保存和 shadow commit，然后在评审或复盘时把这些记录和 diff 一起回放。评审时最难追的是来源。拉取请求能显示最终补丁，但通常看不出是哪条提示触发了有风险的编辑，哪条 AI 建议被丢弃了，或者开发者是否在同一个错误上卡了很长时间。

RECAP 给出了一条可直接落地的路径。它的 VS Code 扩展会记录 Copilot 聊天 JSON 和 shadow git 变更，在五分钟窗口内把文本编辑组和 diff 关联起来，并将编辑标记为 Copilot、人类、部分匹配、未匹配，或很可能来自外部来源。在一项课程部署中，它捕获了 2,034 条提示和 8,239 次 shadow-git 提交，覆盖 406 个工作会话。软件团队可以先做一个小测试：在一个 AI 辅助项目上跑两周这种采集，然后查看重复的错误循环、按会话统计的 AI 编辑占比，以及和生成代码相关的评审意见。

计算科学团队在把编码代理当作研究助手之前，应先让它们做已复现的结果检查。一个可用的测试框架应当打包论文中的一个结论、元数据、可选工件、所需领域工具和隐藏的专家复现步骤。代理提交轨迹、日志、文件和简短报告，评估重点放在证据是否支持该结论。

AutoMat 说明了这个检查为什么重要。在 85 个计算材料科学结论上，最佳测试设置的成功率只有 54.1%。只靠论文文本复现时，各系统几乎都失败；基于工件的复现更容易。失败模式是操作层面的：步骤不完整、方法偏离、执行不稳定，以及缺少领域选择。实验室可以先拿最近的 10 个内部结论做起，要求代理在研究人员使用的同一个容器或 HPC 环境里运行，再把输出和专家复现笔记对比，然后再信任代理生成的脚本或后处理。

为共享 GPU 上的编码代理或浏览器代理提供服务的团队，应按任务级别衡量成本和延迟：一次缺陷修复、一次 SWE-bench 运行、一个浏览任务，或一次完整的工具使用会话。像首 token 时间这类按请求计的指标，忽略了用户实际感受到的等待时间里那些空闲间隔、工具调用和 KV-cache 重新生成。

SAGA 给出了一次明确的系统测试。代理任务通常会发起 10 到 100 次串联的 LLM 调用，中间夹着工具调用。在一次 SWE-bench 测量里，38% 的执行时间花在 KV-cache 重新生成上，平均 GPU 内存使用率是 42%，端到端延迟是只算推理基线的 6.0 倍。SAGA 在工具调用间保留可复用的 KV cache，并把后续步骤路由回同一个 worker。在 64 块 A100 GPU 上，它把 SWE-bench 的任务完成时间降到 vLLM 加 Automatic Prefix Caching 的 1.73 倍提升，把 WebArena 的任务完成时间降到 1.55 倍提升，但峰值吞吐量大约低了 30%。实际接入时，可以先在团队自己的代理轨迹上做一次 A/B 运行，对比完整任务完成时间、SLO 达成率、GPU 内存使用和吞吐损失。