AI 编码 Agent 是否像人类一样打日志？一项实证研究 Do AI Coding Agents Log Like Humans? An Empirical Study

整个方法的具体步骤如下。第一步是数据筛选（Section 3.1）：从 AIDev-pop（33596 个 Agent PR、6618 个人类 PR、2807 个仓库）出发，依次叠加'主语言 Py/Java/JS-TS''≥500 stars''≥10 个 Agent PR 与 ≥10 个人类 PR'三道过滤，得到 130 仓库 / 6843 Agent PR / 4784 人类 PR 的候选集，最终因排除 4 个无日志变更的仓库得到 77 仓库 / 4550 Agent PR / 3276 人类 PR 的最终集。第二步是日志识别（Section 3.2）：对每个 PR 的代码 diff，针对其修改文件的扩展名运行对应的语言正则（Table 1）；同时排除构建产物目录（如 node_modules/、dist/）与测试文件（test_*.py、*Test.java 等，Table 2）；最终输出每个 PR 中'被增加、修改或删除的日志语句集合'以及对应的代码上下文（if/try/loop/unnested，Table 5）。第三步是指令收集（Section 3.3.1）：对每个 Agent PR，收集三类指令——通过 GitHub API 拉取关联 issue（仅 Copilot PR 可关联），按 Table 3 的正则（如 \*\*/CLAUDE.md、\.github/copilot-instructions\.md）扫描仓库指令文件在 PR 创建时点的快照，并拉取 PR 的 review 评论。第四步是指令意图分类（Section 3.3.2）：构造一个 system+user prompt（Fig. 2）让 GPT-4o/GLM-4.7/DeepSeek-V3.2 各自独立给出 {label, rationale} JSON；通过 100 条人工标注样本迭代调参至 Cohen's κ=0.83 后，采用 majority voting 决定最终标签；与此同时，第一作者与第二作者按 'Strong/Weak' 维度双盲标注 100 条指令，κ=0.96，用于 RQ2 的强度分析。第五步是指标计算（Section 4）：对每个项目-类型（Agent/Human）组合，计算 logging prevalence（改日志的 PR 比例）、log density（每 1K LOC 改动日志数）、message length、log level 分布（按 Table 4 的 verbosity 分类）、syntactic context 分布（按 Table 5 归一化）。第六步是配对比较与统计：每个项目得到一个 [0,1] 的归一化分数；用 Wilcoxon signed-rank 或配对 t 检验比较 Agent vs Human 的项目级中位数；RQ3 进一步用 Kaplan-Meier（scikit-survival）追踪 Agent 引入日志在后续 commit 中被修改的时间分布，并用 commit authorship metadata 把每次后续修改归因于 human 或 bot。

方法层面有三个新颖点。第一，'按指令源分别计算合规率'的拆解视角（Table 6）——同一份日志指令可能来自不同渠道，本文把渠道差异（task specification vs repository instruction）作为变量考察，发现两者合规率差异显著（40% vs 8.3%），并指出部分原因可能是某些 Agent 工作流根本不会加载仓库指令文件。第二，'指令强度'作为调节变量的引入——通过对 100 条指令人工标注 Strong/Weak，发现一个反直觉现象：弱指令合规率反而高于强指令（50% vs 27.3%），提示'越具体的指令越难被 LLM 准确解读'，这是一个之前未被量化讨论的 LLM 行为模式。第三，把 Kaplan-Meier 引入到日志稳定性研究——传统日志研究多用静态指标（如修改率），本文用生存分析刻画'日志多久会被改'，揭示出 Agent 日志更'sticky'（被改动频率低于人类日志）这一新发现。

独立审视论文，我识别出以下几个具体弱点及对应改进方向。(1) 指令合规率的'强度悖论'——强指令合规率（27.3%）反而低于弱指令（50%），作者只报告现象但未深入归因。改进方向是用 interpretability 方法（如 attention rollout、logit lens）检验 LLM 是否对'Strong'指令中具体字段（log level、文件名）产生 token-level 冲突，或在 prompt 中用 few-shot 示例替代自然语言细则。(2) 'Remove 100% 合规'是 vacuous compliance——dropseed/plain 这一个项目贡献了所有 10 条 Remove 指令，且要求是'先打日志调试，提交前删除'，但代码中本来就没有 debug 语句，于是被计为 100% 合规。改进方向是把 vacuous compliance 单独标记或在合规率计算中引入'非平凡编辑量'阈值。(3) 缺少对'为什么 Agent 不打 INFO'的因果分析——RQ1 只观察到 INFO 显著偏少（24.7% 仓库中人类更多），但没解释是训练数据偏差、reward model 偏好还是安全审查触发。改进方向是用 rejection sampling + counterfactual prompt 探查因果，例如把 issue 中加一句'请添加 INFO 级别日志以追踪状态'对比自然状态。(4) PR 规模效应虽有讨论但没有形式化建模——Fig. 5 显示 log density 与 PR 规模强相关，但论文未给出密度对规模的回归方程。改进方向是用 $\log(\text{density}) = \alpha + \beta \cdot \log(\text{LOC}) + \gamma \cdot \text{Agent} + \epsilon$ 拟合，从 $\gamma$ 是否显著区分 Agent/Human 的'本质行为'。(5) 缺乏对 Agent 类型（Copilot vs Claude Code vs Cursor 等）的分层分析——Table 3 列出了五种 Agent 但论文结果未按 Agent 类型拆分。改进方向是对每类 Agent 单独跑一遍指标，可能揭示某些 Agent（如 Claude Code）的指令合规率显著高于其他（如 Devin）。

作者在 Section 5 给出三类未来方向。(a) For Tool Builders：从 prompt 治理转向 CI/CD 硬约束。具体可探索的方案包括：在 agent 工作流中插入 observability-focused linter（如自定义 ESLint rule、pylint plugin），把'每个 catch 块必须有 logger.exception'作为可执行检查；或在 PR 创建前自动运行基于 AST 的日志覆盖率分析，未达标则阻断 PR。(b) For Researchers：训练主动可观测性 Agent。论文建议 RLHF + RLVR 两条路径：RLHF 用开发者对日志质量的偏好对（如'这个日志太啰嗦'vs'这个日志不够'）做 pairwise 比较训练 reward model；RLVR 把静态分析器（log coverage、log level distribution）的输出作为 verifiable reward，自动惩罚未埋点的控制流分支。此外还可探索：把 logging 视为 sequence labeling 任务做专用 pre-training；用 agentic self-play 让一个 Agent 生成代码、另一个 Agent 做'observability critique'形成对抗训练。(c) For Practitioners：把可观测性纳入 PR 审查 checklist。具体的工程动作包括：code review template 强制要求 reviewer 勾选'agentic PR 是否覆盖了所有异常分支'；定期 audit 仓库的 log churn 率作为可观测性健康的 leading indicator。基于论文结果可延伸的方向还包括：(i) 跨语言泛化——论文限 Py/Java/JS-TS，但 Rust/Go/C++ 的 Agent 日志实践尚未被研究；(ii) 跨组织对比——企业内部仓库的日志指令密度与合规率是否与 OSS 一致？企业内部更可能存在硬性 SLA，可作为对照实验组；(iii) 长周期效应——Agent 引入日志后 6/12/24 个月的演化趋势，是否会逐渐沉淀成事实标准？(iv) 多 Agent 协作场景——多个 Agent 协作修改同一文件时日志的归属与冲突解决。

复现性方面论文提供了完整的 replication package（参考文献 [20]），作者明示愿意公开所有代码。数据来源是 AIDev 公开数据集（DOI 已索引），覆盖 81 个真实仓库的 PR 与 review 评论，可通过 GitHub API 重新拉取 patch。计算依赖方面，方法主体是 Python（regex、pandas、scikit-survival、scipy），LLM 评审团使用 GPT-4o/GLM-4.7/DeepSeek-V3.2 的 API 调用，复现成本主要在于 API 费用（4550 个 PR 的指令分类 + 多次 majority vote 估计在数十美元量级）；Kaplan-Meier 在 scikit-survival 中是几行代码即可跑通；统计检验用 scipy.stats 的 wilcoxon 与 chi2_contingency。复现难度整体评估为中等偏低，主要门槛在于 LLM API 的可访问性与费用。需要注意的是：(1) AIDev 数据集的时间窗（2024-12 至 2026-07）跨越多个 Agent 版本升级，论文结果绑定到具体的模型快照（如 Claude 3.5 Sonnet），新模型上的合规率可能变化；(2) regex 是基于 Py/Java/JS-TS 惯用法调优的，移植到新语言需要重新调参与人工验证；(3) LLM-as-Judge 的 prompt 是关键资产，作者已附在论文中（Fig. 2），但完全复现 κ=0.83 需要重新做 100 条人工标注作为 ground truth。总体而言，对于熟悉 Python 数据栈与 LLM API 的研究者，复现周期估计在 1-2 周内可完成。