SWE-CC 基准：编码 Agent 功能正确仍违反 43.1% 仓库贡献规范

功能正确的补丁仍可能违反仓库贡献策略，而只跑单元测试的基准看不到这一差距。

• 场景：作者称成熟项目发布仓库级贡献策略，覆盖风格、git、测试流程与文档，以维持代码质量与长期可维护性。作者还称不合规的 AI 贡献增加维护者审查负担，并引用代码冻结期间一次删库事件，说明未受治理的智能体有操作风险。
• 现有不足：作者称 SWE-bench 及后续基准主要用既有测试套件判断功能正确。作者认为最接近的工作只评最终补丁，或把处理后的规则注入上下文；RepoComplianceBench 只覆盖 AI 辅助披露。
• 观察：Figure 1 的一次运行通过全部测试并标为 Resolved，但补丁使用 assertTrue；图中 Django 指南要求布尔检查使用 assertIs，并标为 Not merge-ready。作者称只靠测试执行发现不了这类违反。
• 项目特异性：正文写 823 条中仅 12 条（1.5%）在其他项目有内容词 Jaccard ≥ 0.6 的相似策略；同一类活动可以冲突，Django 要求 commit 含 issue 号，Flask 禁止。测试与代码质量指南出现在全部 12 个仓库，明确约束 AI 辅助贡献的策略已写入 11 个项目。
• 提出：作者提出半自动流水线，把 12 个开源仓库的开发者文档转为 823 条可机器检查的原子策略，并实例化为 SWE-CC。作者称这是首个系统评估编码智能体仓库级策略遵守的基准，同时审计运行轨迹与最终交付物。

功能正确性基准

• SWE-bench（Jimenez et al., 2024）——用项目既有测试套件评估语言模型能否解决真实 GitHub issue。作者把后续工作概括为多语言评测、训练数据合成与多缺陷维护等方向（Rashid et al., 2025; Miserendino et al., 2025; Yang et al., 2026a; Pan et al., 2024; Zhou et al., 2026; Tang et al., 2026），未逐篇对照。

非功能属性

• 效率、安全与一般质量：SWE-fficiency（Ma et al., 2025）评真实仓库上的执行效率；Lian et al.（2026）与 Wang et al.（2026b）评生成代码的安全；SWE-NFI（Xue et al., 2026）评非功能改进。论文将这些列为非功能评测，未逐项写与本文的方法差异。

补丁接受与披露

• SWE-Gate（He et al., 2026）与 SWE-SHIELD（Yu et al., 2026）——从历史 pull request 讨论挖掘隐式评审标准，判断补丁能否被接受。Table 1：策略分别 303 与 1,787 条，来自代码评审历史，不审计轨迹，不要求智能体自行检索；前者用可执行评估器，后者用 LLM-as-a-judge。作者称二者是最接近的工作。
• RepoComplianceBench（Yang et al., 2026b）——评 AI 辅助披露。作者称其不含更广的仓库治理。Table 1：455 条，来自 contribution file，要求检索，评估器为 Executable + LLM，不审计智能体行为。
• SWE-NFI 在 Table 1 中另有一行：评补丁质量，策略来自文献与常见实践，92 条，可执行评估器，不审计轨迹、不要求检索。

基线与数据

• 对照设置：论文没有外部合规方法基线。实验对照是两种 scaffold（mini-SWE-agent、OpenHands）和两种策略提供方式（Native、Consolidated）。任务是 SWE-bench Verified 上的 500 个实例；功能指标沿用其 Resolve Rate。Appendix C.2 用同一 scaffold 下 Vals AI 公布的 SWE-bench Verified 解决率作参照。

作者认为既有评测有两点不足：只评最终代码补丁，以及把处理后的规则注入上下文窗口。SWE-CC 对照项目文档审计工作流，并要求智能体在现场自行定位与理解策略。作者称 SWE-CC 是首个项目相关的代码合规基准。

作者把贡献文档编译成可执行检查器，在 SWE-bench Verified 的 12 个仓库上实例化为 SWE-CC。评测时检查器只读轨迹与交付物，不调用 LLM 裁判。

问题设定

给定任务指令与仓库环境，智能体产生步骤序列 τ 与最终输出 C。每个仓库有一组确定性检查器。论文把单次判定写成

f_k(τ, C)∈{0,1,⊥}

⊥ 表示该策略在这次执行中不适用。正文未在该式旁定义 0 与 1 哪个表示通过；后文用通过与违反描述结果。

与只评孤立补丁的设置不同，智能体要把修复包装成贡献：组织 commit、撰写 PR 描述，并同时维护测试与文档。PR 在环境中以文本提交，不推送到远程。

从文档到原子策略

1. 找来源：从贡献者入口遍历开发文档，并收集导航之外的 PR 模板、changelog 说明和面向编码智能体的文件（如 AGENTS.md）。附录写渲染视图会去掉 HTML 注释，模板改从原始文本读取。
2. 抽原子义务：LLM 把每条贡献者义务写成前提（何时适用）与后件（要求的行为），保留原句、位置和例外或指定工具。一句话含多条义务时拆开，使下游一个检查器对应一条规则。
3. 筛可检查且强制的规则：规则必须指向可检查证据并给出非主观的通过/失败条件；只保留自主贡献者职责内的动作，去掉管理级治理和终端用户说明；只保留强制要求，排除建议。LLM 按书面量表标注这三维。

12 个仓库先抽出 1,759 条原子策略，989 条管辖可检查产物或运行行为，823 条通过过滤并编译成检查器。抽取与分类由 Claude Opus 5 在 high reasoning effort 下按仓库独立完成；量表先在两个项目上起草，再用于其余十个。

检查器

• 一对谓词：前提选出适用对象，如智能体创建的 commit、改动的文件或运行的命令；后件判定满足、违反，或产物证据不足时的未定。前提不选中任何对象时记为不适用，不算遵守。附录写更宽的所有权会把仓库原作者也评进去，而他们不是被测对象。
• 三条合成测试：满足、违反、前提不选中任何对象。失败则送入迭代修正。附录写共 2,603 条合成用例，767/823（93%）覆盖全部三种结果。
• 不调用模型：检查器是普通 Python，同一运行重复评分得到相同裁决。规则若点名只作用于改动文件的静态工具（如 flake8、black），则在 base 与 head 上运行并比较差异。
• 精确与近似：294 条标为 exact，529 条标为 approximate（Table 6 的合计列写 approx. 64%）。approximate 用词表、文本模式、代码结构、文件位置或伴随改动等可见痕迹近似文档未完全规定的读法，并在 docstring 中写明可能出错的方向。
• 所有权：Created 看智能体是否产出该产物；Touched 只评 diff 改过的行；Enclosing 在编辑函数时把其 docstring 与 doctest 纳入责任，但不评未改写的文字。

Figure 2 的例子：SymPy 文档要求提交首行不超过 71 个字符。前提是智能体创建了 commit，后件测量摘要行长度。

校验、设置与指标

两名有软件工程经验的标注者独立检查 150/823（18.2%）个检查器，看不到模型裁决。§3.2 报告裁决一致率 94.0%（Cohen's κ = 0.72），接受 87.2%。附录写按项目占比加权的平均接受率同为 87.2%（95% CI [82.1, 92.3]），审计后未修改或删除检查器。

策略提供有两种：

• Native：给出全部治理文档的位置（URL），并明确提示开工前查看，由智能体自行定位与解释。
• Consolidated：把原子策略汇总进环境中的本地文件并指示阅读，以去掉检索瓶颈，单独看遵守明示约束的能力。

指标有三项。Triggering Rate 是仓库策略中前提被激活的比例。Compliance Rate 是已触发策略中通过的比例。Resolve Rate 是补丁是否通过仓库单元测试。证据缺失时该策略计为已触发，但不进入合规率分母。

实验设置

• 被测模型：GPT-5.6 Luna、Gemini 3.7 Flash、DeepSeek V4 Flash 0731（Table 3 写作 DeepSeek V4 Flash）、Kimi K2.5。各配 mini-SWE-agent 与 OpenHands，共 8 个智能体配置。
• 任务与策略：SWE-bench Verified 扩展的 500 个端到端贡献任务，Table 6 的 12 个仓库；强制策略 823 条。两种策略提供设置，合计 8,000 次工作流。
• 提示与工具：沿用 scaffold 默认系统提示词与工具，只扩展任务提示：加入 commit 与 PR 步骤，允许编辑全部文件，PR 以文本提交。解决率由 SWE-bench 套件从最终输出抽取补丁后判定。
• 合规判定：确定性检查器，评测时不用 LLM 裁判。每次执行后本地评分 120–215 ms（MacBook Pro，Apple M4 Pro，24 GB）。
• 构建用模型：策略抽取、分类、检查器编写和自动预审使用 Claude Opus 5，high reasoning effort。
• 未写明项：论文写实验沿用默认配置，未报告被测模型温度或独立重复次数；8,000 对应每个实例、模型、scaffold、设置各一次。

主结果

Swipe horizontally to read the table

模型	设置	mini合规	OH合规	mini解决	OH解决
GPT-5.6 Luna	Native	51.8%	55.3%	78.6%	86.6%
Gemini 3.7 Flash	Native	53.9%	56.3%	80.2%	78.4%
DeepSeek V4 Flash	Native	61.3%	63.8%	93.4%	94.4%
Kimi K2.5	Native	55.9%	57.2%	74.6%	76.2%
GPT-5.6 Luna	Consolidated	67.6%	67.5%	77.6%	84.8%
Gemini 3.7 Flash	Consolidated	65.3%	66.8%	81.2%	79.4%
DeepSeek V4 Flash	Consolidated	67.7%	71.2%	92.6%	93.8%
Kimi K2.5	Consolidated	56.9%	62.4%	74.0%	74.2%

据 Table 3。OH 为 OpenHands。该表另有触发率，上表未列入：四个 Average 行的触发率，Native 为 24.4% 与 24.9%，Consolidated 为 25.6%（+1.2）与 26.6%（+1.7）。

• 作者称功能补丁出现在 74.6%–94.4% 的运行中，Native 下只遵守 51.8%–63.8% 的适用策略。摘要与贡献写四模型、两脚手架下违反 43.1% 的适用策略。引言写 GPT-5.6 Luna 违反 44.7% 的仓库策略，该句未写明 scaffold 或设置。
• 作者称 Consolidated 相对 Native 的合规平均增益为 8.75%。Table 3 标注的最大合规增益在 GPT-5.6 Luna：mini-SWE-agent +15.8，OpenHands +12.2。Kimi K2.5 在 mini-SWE-agent 上为 +1.0。作者称解决率波动在 2% 以内；表中也有负向 ∆，如 OpenHands 上 Kimi K2.5 为 −2.0、GPT-5.6 Luna 为 −1.8。作者称提供策略不降低解题能力。
• 作者称即便在 best configuration 下，顶级模型仍违反约 30% 策略。Table 3 中 Consolidated 最高合规是 OpenHands 上 DeepSeek V4 Flash 的 71.2%。

违规位置与策略获取

• Figure 4 标注功能已解决运行的违反均值：Native 7.7，Consolidated 6.6。正文写平均每次违反 7.7/22.6 条已触发策略（34.1%）；图注写一次执行平均触发 22.6 条，并称提供策略后分布左移约一条违反。
• 引言写 50.3% 的策略违反发生在最终提交打包之前，该句未写是否限于已解决运行。正文与 Figure 5 写的是已解决运行：轨迹 50.3%，最终交付物 49.7%。作者称只检查最终补丁会漏掉轨迹中的违反，例如提交前运行测试套件。
• Table 5：Native 平均 Attempt 28.9%、Retrieve 12.6%。作者称平均 71.1% 的执行未尝试获取文档；超过一半的尝试未取回策略文本。模型差异大：OpenHands 上 GPT-5.6 Luna 的 Attempt 为 75.6%、Retrieve 为 43.2%；Gemini 3.7 Flash 为 2.8% 与 1.0%；Kimi K2.5 两个 scaffold 的 Attempt 均为 3.6%。Consolidated 下平均 91.6% 的执行打开文件，99.6% 的内容进入上下文；Kimi K2.5 在 mini-SWE-agent 上打开比例为 42.6%。作者认为合规失败来自检索与推理两侧。

治理领域

• Table 4：AI 辅助贡献策略的触发率在各 scaffold 与设置为 91.6%–95.9%，Native 合规为 mini-SWE-agent 15.3%、OpenHands 20.6%；Consolidated 升至 26.6% 与 30.7%。作者称这类策略触发频繁但合规最低，给入汇总指南后仍常省略规定的 AI 披露。正文把触发概括为 92%、Native 合规概括为 15%。
• 语言与框架风格在 OpenHands 上 Native 合规 84.2%、Consolidated 85.9%。作者称提供指南后变化为 +1.7%，并认为预训练模型默认更接近惯用格式。代码与质量的触发率为 82.5%–83.8%，合规为 41.1%–56.1%。
• Git 与 commit 规范的合规升幅较大：mini-SWE-agent 从 59.9% 到 87.0%，OpenHands 从 63.4% 到 90.1%。文档与 docstring、专门变更的触发率低；作者称修 bug 基准很少要求改项目级文档。

其他消融与分析

• Table 8：只看 294 条 exact 检查时，合规率变化至多 4.7 个百分点；Consolidated 仍提高每个模型在两个 scaffold 上的合规，且增幅大于全部检查。DeepSeek V4 Flash 在四列中的三列仍居首。
• Table 15：mini-SWE-agent、Native 解决率相对 Vals AI，GPT-5.6 Luna 78.6% 对 93.0%（∆ −14.4），Gemini 3.7 Flash 80.2% 对 80.8%（−0.6），DeepSeek V4 Flash 0731 93.4% 对 88.8%（+4.6），Kimi K2.5 74.6% 对 70.0%（+4.6）。作者写 Vals AI 对 OpenAI 模型使用 Responses API 模型类，本文四个模型都用默认模型类。
• Table 16：823 条中 304 条（37%）在全部 8,000 次运行中从未触发；Specialized changes 为 107 条中 81 条（76%）。
• Appendix C.3：Code and quality 中被触发策略有 27% 被评分，Tests and test style 为 64%。作者称多数需要类型检查或完整环境中的测试运行，存储的运行没有该结果。
• Appendix C.1：61 次运行（0.8%）无功能裁决，计为未解决；另有 36 次运行中改过的文件无法作为 Python 解析，相关策略记为 withheld。两类合计 95 个不同运行。
• Table 4 中并非所有领域在 Consolidated 下都更高：OpenHands 上 Specialized changes 为 69.3%，低于 Native 的 72.8%；mini-SWE-agent 上 Documentation and docstrings 为 61.1%，低于 Native 的 62.7%。

作者指出的局限与后续方向

• 论文没有 Limitations 专节，也未在 Discussion 中把某项设计写成不足。Conclusion 写明后续方向：将把 SWE-CC 扩展到更多模型架构、scaffold 与仓库基准，以同时衡量正确性与合规。

实验覆盖范围

• 评测使用 SWE-bench Verified 的 12 个仓库、500 个任务和 823 条强制策略；4 个 LLM、2 个 scaffold、Native 与 Consolidated 两种设置，共 8,000 次工作流（§4.1、Table 6）。
• 合规由确定性检查器判定，评测时不调用 LLM 裁判；功能解决率由 SWE-bench 套件判定（§3.1.2、§4.1）。
• 检查器人工审计是分层样本 150/823，两名标注者独立标注；抽取、分类与检查器编写使用 Claude Opus 5、high reasoning effort（§3.2、Appendix B）。
• 论文报告 61/8,000 次运行无功能裁决，304/823 条策略在全部运行中从未触发（Appendix C.1、Table 16）。论文未报告被测模型的温度和独立重复次数。
• 823 条检查中 294 条标为 exact、529 条标为 approximate；Table 8 另报告了只保留 exact 检查时的合规率（Appendix B.5.3）。

SWE-CC 评测编码智能体是否遵守仓库贡献策略，而不只看补丁能否通过测试。

• 问题：作者认为通过既有测试不等于贡献可合并。成熟仓库把风格、提交、测试、文档和 AI 披露写成项目级规则，而且规则很少跨仓库重合，甚至互相冲突。现有基准主要评最终补丁的功能或补丁质量，不审计中间工作流，也不要求智能体自己找到规则。
• 做法：半自动流水线从 12 个 SWE-bench Verified 仓库的文档抽出 823 条强制原子策略，各编译成不调用 LLM 的检查器，同时读运行轨迹和最终 PR 交付。500 个任务要求智能体完成 commit 与 PR 描述。Native 只给文档位置并提示先读；Consolidated 把处理后的策略全文放进环境。
• 结果：作者报告四模型、两脚手架下违反 43.1% 的适用策略。Native 合规最高为 OpenHands 上 DeepSeek V4 Flash 的 63.8%，同配置 Consolidated 为 71.2%；对应解决率为 94.4% 与 93.8%（Table 3）。已解决运行中 50.3% 的违反在轨迹里（Figure 5）。即便被提示去读文档，平均只有 28.9% 的 Native 执行尝试获取策略文档（Table 5）。预先给入处理后策略后，作者报告合规平均提高 8.75%，解决率波动在 2% 以内。
• 作者结论：功能正确不保证可部署。作者认为合规失败来自检索和推理两侧，后续软件工程智能体必须稳定遵守仓库治理。作者计划扩展模型、scaffold 与仓库基准，并把合规与功能正确性一起报告。