今天研究 Coding Agent，公开数据大多停留在结果层：哪一个 Pull Request 由 Agent 提交、最终是否合并、修改了多少文件。可两个同样通过测试的补丁，执行过程可能完全不同：一个精准定位并完成修改，另一个搜索数百次、反复撤销、消耗大量 token 才偶然成功。
AgentLogs 首次大规模保存 GitHub 云端 Coding Agent 的过程数据。数据集包含 307,416 个任务、549,239 个会话、35,810 个出现 Agent 任务的公共仓库，以及 64,255,174 条会话日志。日志记录提示词、模型输出、工具调用、文件编辑、Git 操作、GitHub 交互与 token 使用。
#从“贡献了什么”转向“怎样完成”
GitHub 的云端 Agent 在临时环境中异步工作。开发者可以从 Agents 页面、PR 评论、自动化流程，或 Jira、Linear、Slack 等第三方入口分配任务。一次任务可能包含多个会话，每个会话又由大量步骤组成。
AgentLogs 将数据分为仓库、任务、会话、日志条目和用户五类 Parquet 表。研究者可以把自然语言请求与后续计划、搜索、编辑、命令、CI、PR 和评论关联起来，而不是只观察最终提交。
这使一批过去难回答的问题变得可研究：Agent 在什么任务上最容易绕路，哪些工具调用与成功相关，成本主要花在哪里，怎样的用户请求更容易产生可合并结果，人类在何处继续或修正 Agent，以及多会话重试是否真的带来收益。
#数据规模与来源
研究从超过 10 stars 的 1,812,362 个公开仓库开始扫描，其中 35,810 个仓库出现 Agent 任务，占 1.98%。最终获得 30.7 万个任务和 54.9 万个会话，意味着一个任务可能有多次运行。
日志表本身约 56 GB，包含 6,425 万条事件。仓库、任务、会话和用户表较小，数据被分片，便于按需下载和并行分析。完整 schema、示例分析与类型定义也同时发布。
采集发生在 2026 年 7 月 10 日至 17 日。研究先通过 GitHub REST API 获取任务标识，再使用 GitHub Copilot 的未文档化公开接口获取更完整的任务、会话与逐行 JSON 日志。作者说明其遵守平台速率限制，但依赖未文档化接口意味着未来复采的稳定性无法保证。
#它能揭示哪些新的工程指标
传统 benchmark 通常用任务通过率衡量 Agent。轨迹数据可以增加过程维度。
一是效率：按任务难度比较 token、工具调用、命令运行与墙钟时间，区分真正简洁的成功和高成本试错。二是策略：分析搜索、阅读、编辑与测试的顺序，寻找不同模型或任务类别的行为模式。三是失败：识别编译失败、权限错误、环境问题、错误修复方向和重复循环，而不是把所有未合并 PR 归成一类。
四是任务表述。任务表保存用户请求，研究者可以探索哪些提示缺少关键信息，Agent 如何补充上下文，以及人为追加消息是否改变结果。五是协作：日志能看到子 Agent 委派、PR 评论、复跑和后续会话，从而研究人机责任边界。
这些指标还可以用于构造更现实的训练与评测数据。成功轨迹提供工具使用范式，失败轨迹则揭示需要专门设计测试的薄弱环节。但直接把日志蒸馏成训练数据会继承其中的敏感信息、错误策略和平台偏差，不能把“大规模”当成“可直接训练”。
#数据不等于整个 Coding Agent 世界
样本来自公开 GitHub 仓库和特定云端 Agent 平台。私有企业代码、IDE 内本地会话、其他 Agent 产品以及没有超过 10 stars 的仓库不在覆盖范围内。仅 1.98% 的扫描仓库出现任务，也说明这是早期采用者切片，而非普通开发流程的随机样本。
数据集还没有进一步抓取所有相关 PR、分支和工作流资源的完整元数据。日志呈现 Agent 看到和做了什么，但不必然给出最终业务价值、合并原因或长期维护结果。研究需要把过程表与仓库事件、测试状态和后续提交谨慎关联。
隐私与可识别性同样重要。虽然数据来自公开资源，任务提示和推理日志可能包含开发者没有预期被批量分析的内容。数据集中保留了相关用户的 GitHub ID 与用户名。任何二次发布、训练或个体行为研究都应做额外脱敏、许可证检查和伦理审查。
AgentLogs 的意义不在于宣告一个“最大数据集”，而在于把 Coding Agent 研究的观察单位从补丁扩展到轨迹。当执行过程可以被查询，系统优化才不必只追求通过率：成本、可靠性、可解释失败和人类介入都可以成为一等指标。