--- kind: ideas granularity: day period_start: '2026-06-23T00:00:00' period_end: '2026-06-24T00:00:00' run_id: materialize-outputs status: succeeded topics: - coding agents - software engineering - agent safety - secure code generation - research automation tags: - recoleta/ideas - topic/coding-agents - topic/software-engineering - topic/agent-safety - topic/secure-code-generation - topic/research-automation language_code: zh-CN --- # 编码智能体运行保障 ## 摘要 编码智能体的采用现在需要运行记录，这些记录要能应对微弱痕迹、高成本验证，以及只停留在静态检查层面的安全声明。实际工作包括仓库多信号普查、智能体运行的验证器预算控制器，以及面向代码和工具使用的漏洞利用支撑评审关卡。 ## 用于编码智能体活动的多信号仓库普查 开源维护者、安全研究人员和供应链团队不应再把机器人账号或拉取请求当作编码智能体使用情况的主要记录。有效的普查应同时扫描多种信号：提交消息签名、作者名模式、集中式机器人身份，以及智能体配置文件。检测器应先去除项目分叉，分开处理机器人身份和人类别名，并在把采用率数字用于风险或质量研究前，对每类信号抽样做人工标注。 把这项能力纳入仓库分析有明确原因。在 World of Code V2510 快照中，多方法检测发现了 850,157 个 Claude Code 提交，而机器人账号查找只发现 28,154 个。在 V2604 中，按提交归因的智能体产生了 1,772,677 个提交，其中 Claude Code 为 886,122 个。基于拉取请求的普查还漏掉了 79% 通过提交检测到的 Claude Code 采用者，而只看提交的检测几乎漏掉了所有 Codex 采用者。一个低成本的内部检查方法，是在一个组织的仓库中运行四信号扫描，并与当前用于 AI 辅助变更的审计方法对比。 ### 资料来源 - [Detecting AI Coding Agents in Open Source: A Validated Multi-Method Census of 180 Million Repositories](../Inbox/2026-06-23--detecting-ai-coding-agents-in-open-source-a-validated-multi-method-census-of-180-million-repositories.md): 概述多方法普查、验证方法，以及机器人账号查找、提交检测、配置文件和拉取请求痕迹之间的数量差距。 - [Detecting AI Coding Agents in Open Source: A Validated Multi-Method Census of 180 Million Repositories](../Inbox/2026-06-23--detecting-ai-coding-agents-in-open-source-a-validated-multi-method-census-of-180-million-repositories.md): 说明论文摘要中的主张：没有任何单一检测方法能覆盖 AI 活动总量的一小部分以上，并给出 Claude Code 机器人账号召回率差距。 - [Detecting AI Coding Agents in Open Source: A Validated Multi-Method Census of 180 Million Repositories](../Inbox/2026-06-23--detecting-ai-coding-agents-in-open-source-a-validated-multi-method-census-of-180-million-repositories.md): 给出 V2604 的提交量、配置文件发现，以及 PR 与提交渠道覆盖范围几乎不重合的情况。 ## CI 中编码智能体运行的验证器预算控制器 在慢速测试或仓库级验证器上运行编码智能体的团队，可以在每次高成本检查前增加一个小型控制器。控制器维护一个信念值，表示当前候选方案会通过验证；它用语法检查、公开测试或 LLM 评审等低成本证据更新该值，并决定是重新生成、再运行一个评审器、调用完整验证器，还是停止。对于完整 CI 运行或 SWE-Bench 式 oracle 成本高到挤占其他工作的队列，这种做法最有用。 Bayesian control 论文给出了一条直接的实现路径：估计每类任务的先验通过率，用通过和失败似然校准评审器，为生成、评审器和验证设置明确成本，然后选择期望效用最高的动作。其评估覆盖六个生成器和九个编码基准；报告的优势主要出现在验证成本高、评审器有用但不完美的场景。团队可以用近期智能体尝试的回放来测试这一想法，利用已记录的语法结果、单元测试、CI 结果和墙钟成本，把该控制器与当前固定循环进行比较。 ### 资料来源 - [Bayesian control for coding agents](../Inbox/2026-06-23--bayesian-control-for-coding-agents.md): 描述贝叶斯信念状态、评审器更新、动作选择、成本模型，以及跨生成器和基准的评估范围。 - [Bayesian control for coding agents](../Inbox/2026-06-23--bayesian-control-for-coding-agents.md): 说明核心主张：当验证成本高且评审器信息有用但不完美时，贝叶斯控制最有价值。 - [Bayesian control for coding agents](../Inbox/2026-06-23--bayesian-control-for-coding-agents.md): 解释围绕候选方案正确性、评审器调用、重新生成和高成本验证的序贯决策模型。 ## 用漏洞利用测试支撑的智能体安全修复评审关卡 对智能体编写代码的安全评审应要求可执行证据，证明防护在正确边界生效。面向高风险变更的实用关卡可以把变更映射到一条 OWASP 或 CERT 安全编码原则，运行正常功能测试，运行一次漏洞利用或滥用测试，并记录生成代码是否实现了预期防护机制。这能给评审者提供有用的失败标签：模型缺少该原则、破坏了功能、通过另一条路径阻断了利用，或知道原则但把防护放在了错误的代码路径中。 Kauge 通过区分安全编码知识、代码执行能力，以及二者之间的差距来支持这一流程。它报告的发现是，当前系统经常能识别相关安全编码原则，却不能把原则转化为安全且功能正常的代码。对于智能体工具使用，AutoSpec 增加了一个可读安全规则的维护循环：从专家规则开始，把执行轨迹标注为安全或不安全，收集假阳性和假阴性，并且只保留能提高轨迹级分数的规则编辑。在代码执行和具身智能体领域的 291 条轨迹上，AutoSpec 报告 F1 分数为 0.98 和 0.93，假阳性最多减少 94%。小规模试验可以从近期涉及认证、输入处理、文件操作或网络调用的智能体 PR 开始。 ### 资料来源 - [SoK: AI Secure Code Generation: Progress, Pitfalls, and Paths Forward](../Inbox/2026-06-23--sok-ai-secure-code-generation-progress-pitfalls-and-paths-forward.md): 描述 Kauge 如何使用 OWASP 和 CERT 原则以及面向漏洞利用的测试，区分知识、执行能力和差距检查。 - [SoK: AI Secure Code Generation: Progress, Pitfalls, and Paths Forward](../Inbox/2026-06-23--sok-ai-secure-code-generation-progress-pitfalls-and-paths-forward.md): 说明知识到执行能力的差距：模型可以识别相关安全原则，但仍然无法生成安全且功能正常的代码。 - [AutoSpec: Safety Rule Evolution for LLM Agents via Inductive Logic Programming](../Inbox/2026-06-23--autospec-safety-rule-evolution-for-llm-agents-via-inductive-logic-programming.md): 概述 AutoSpec 基于轨迹标注的规则修订循环，并报告 F1 分数、假阳性减少和收敛细节。