让代码智能体学会提问却不泄露私有代码

本地代码智能体在遇到复杂问题时，通常会向更强大的云端模型求助。但这一过程往往会把仓库中的私有标识符、文件路径甚至源代码片段暴露出去。如何在保留求助能力的同时保护代码隐私，成为亟待解决的问题。

现有方案的局限

据研究论文《Teaching Code Agents to Ask Without Leaking Private Code》指出，目前常见的做法主要有两种：一是主机端掩码，二是训练智能体减少信息披露。前者只能隐藏已识别的标识符，但周围的代码和智能体的提问措辞保持不变，攻击者仍可能从上下文中推断出敏感信息；后者则可能矫枉过正，导致智能体不敢提问或提出的问题过于模糊，无法获得有效帮助。

这两种方案都没有从根本上教会智能体如何安全地表达问题。

主机端掩码（host-side masking）是一种在数据离开本地环境之前，由主机侧对敏感信息进行识别和替换的隐私保护技术。常见做法包括用占位符替换变量名、函数名、文件路径等标识符，或对代码片段进行脱敏处理。这种方法的优势在于实现简单、开销低，但局限性也很明显：它只能处理预先定义好规则的敏感实体，对于语义层面的信息泄露（如通过代码结构、注释或用例推断出的业务逻辑）无能为力。此外，掩码后的代码可能失去可读性，导致云端模型难以理解问题上下文，从而降低咨询效果。

训练智能体减少信息披露则是一种基于学习的方法，通过强化学习或微调让智能体在提问时主动避免包含敏感信息。然而，这种方法的训练目标难以精确控制：过度抑制会导致智能体变得“不敢问”或提问过于笼统，反而丧失了向云端模型求助的价值；抑制不足则仍存在泄露风险。这两种方案都停留在“隐藏”或“抑制”层面，没有教会智能体如何用安全且有效的方式表达问题，因此难以同时满足隐私和效用的双重要求。

效用验证抽象（UVA）方法

论文提出了一种名为“效用验证抽象”（Utility-Verified Abstraction, UVA）的新方法。其核心思想是：让智能体用实体的角色和类型来描述私有实体，同时保留专家所需的技术细节。

具体实现上，研究者从已解决的修复轨迹中，将每个问题改写成这种抽象形式。只有当改写后的问题披露的私有实体更少，并且修复过程能在相同执行状态下通过修复轨迹回放验证时，才保留该改写。这样既确保了问题不泄露隐私，又保证了问题仍然有效。

修复轨迹回放验证（repair trajectory replay verification）是UVA方法中的关键验证步骤。具体而言，研究者从已解决的修复轨迹中提取问题改写样本，每条轨迹记录了智能体从初始状态到修复完成所执行的一系列操作和状态变化。在验证改写后的问题是否有效时，系统会模拟在相同执行状态下，仅依据抽象化后的问题描述，重新运行修复轨迹中的关键步骤，检查是否能够达到相同的修复结果。如果回放成功，说明抽象化后的问题保留了足够的技术细节，能够指导专家模型复现修复过程；如果失败，则说明抽象过度，丢失了必要信息，该改写会被丢弃。这一机制确保了隐私保护不会以牺牲问题效用为代价，实现了隐私与效用的双重验证。

实验结果：更多咨询与更高解决率

在两个基准测试中，经过训练的智能体比训练前更频繁地发起咨询。在仓库级问题修复任务上，它解决了37.6%的问题，而同一模型单独工作时的解决率为25.3%。这一提升来自训练整体，而非仅仅来自咨询行为本身。

更关键的是隐私保护效果：与未训练的智能体向同一专家提出的问题相比，训练后的问题披露的私有实体减少了3.7倍，逐字代码减少了1.4倍。

仓库级问题修复任务（repository-level issue resolution）是评估代码智能体能力的一类基准测试，要求智能体在完整代码仓库的上下文中理解问题、定位缺陷并生成修复补丁。与函数级或文件级任务相比，仓库级任务涉及跨文件依赖、项目结构理解和构建配置等复杂因素，对智能体的上下文感知和推理能力要求更高。实验中，智能体在仓库级任务上的解决率从25.3%提升至37.6%，这一提升幅度在同类研究中较为显著，表明UVA训练不仅改善了隐私保护，还切实增强了智能体在真实开发场景中的问题解决能力。

意义与展望

UVA方法为代码智能体的隐私保护提供了新思路。它不依赖于简单的掩码或抑制提问，而是通过训练让智能体学会一种安全的表达方式。这既提升了智能体的实用性，又降低了隐私泄露风险。未来，该方法或许可以扩展到更多类型的敏感信息保护场景中。