322M小模型微调实战：三轮迭代，两次失败，终让编程Agent更安全

当AI编程助手开始自主执行shell命令，一个根本性的安全矛盾就浮出水面：该不该信任Agent对自身行为安全性的判断？ 一位开发者的思路是引入独立的「守门员」——用一个小型本地模型在工具调用执行前进行审核，决定放行、拦截还是请求确认。他开源了laya-guard项目，并详细记录了将一个322M参数模型从零样本基线微调到可发布状态的完整过程。三轮训练，两次失败，最终交付，其中暴露的数据陷阱和评估困境，对任何构建Agent安全层的团队都有参考价值。

问题背景：为什么需要独立的命令守卫

laya-guard的核心设计不复杂：每个工具调用先经过一个本地小模型判断，而不是让Agent自己决定是否安全。最初版本用的是Laya多语言检查点的零样本提示，在50条日常命令的基准上，基础模型只对一半命令直接放行，其余都需要确认。作者想知道：微调能把这么小的模型提升到什么程度？

另一边，项目还做了几项架构层面的加固。沙箱机制现在把受保护路径写入Agent自身的操作系统沙箱，内核层面拒绝未授权读取，无论模型怎么判断都绕不过去。命令归一化覆盖了r''m、${IFS}、base64管道进sh、变量隐藏命令等变体。项目还新增了与其他命令守卫的对比基准。这些工程手段与模型判断形成纵深防御。

不过作者也坦承存在缺口：printenv依赖模型判断，而cat /proc/self/environ仍可能被当作普通文件读取放行。环境变量转储场景并未完全覆盖。

零样本提示（Zero-shot Prompting） 指在不提供任何任务示例的情况下，直接让预训练模型根据指令完成判断或生成。在layaguard的初始版本中，开发者将待审核的命令和上下文直接输入Laya多语言检查点，要求模型输出allow、review或block，模型此前从未见过针对该任务的标注样本。零样本方式无需训练数据、部署成本低，但受限于模型对任务的理解能力，尤其对于322M参数量的小模型，其判断边界模糊，容易依赖表面特征（如命令长度）而非语义。因此零样本结果常被用作微调的基线，用以衡量数据驱动优化带来的真实提升。

确定性规则（Deterministic Rules） 是指基于固定模式匹配或语法解析的硬编码判断逻辑，例如正则表达式识别rm -rf /、检测base64管道、拦截已知敏感路径等。与模型判断不同，规则的行为完全可预测、可审计，不依赖训练数据分布，但覆盖范围有限，无法处理语义变体或新型攻击。在layaguard的纵深防御架构中，确定性规则作为第一道防线处理明确的高危命令，模型则负责处理规则未覆盖的模糊场景。这种分工既能降低模型误判风险，又能通过规则兜底保证已知威胁不被放过。

训练数据：13000条命令与696条人工标注

数据来自作者自己的Agent对话记录，约13000条shell命令。家庭路径、令牌和邮箱地址做了掩码处理。任何与基准或评估用例相似度不低于0.85的命令都被排除。其中696条未被确定性规则覆盖的命令被人工标注，标签来源包括一份书面指南、六个Agent以及作者本人对分歧的复核。

训练在免费Colab GPU上完成。关键细节在于：训练前作者就写好了验收标准，并且每轮都在模型未见过的数据集上评估。这个纪律性做法，恰恰是后面失败暴露得如此清晰的原因。

第一轮：模型学会了「短命令=危险」

验证准确率从0.61升到0.90，乍看令人振奋。但86%的训练行标签是allow，一个永远放行的分类器也能拿到0.86。真正的问题出现在未见的日常命令上：直接放行的数量从25/50降到23/50，新被质疑的包括git status、mkdir -p src/utils、cp、chmod +x这类完全普通的操作。

排查后发现训练数据存在严重的长度失衡：真实的allow命令中位长度287字符，而手写的风险命令通常只有33到40字符。此外，收集的对话记录里没有任何真实的blocked命令。模型学到的最简单信号就是「短=危险」。这一轮只满足四项验收标准中的一项。作者的决定是改数据而非改架构。

第二轮：修了误报，引入漏报

针对上一轮失败，作者新增206个示例：短的普通命令、含单条危险命令的长脚本、韩语和英语请求。日常命令放行率提升到49/50，但三个危险案例溜了过去：删除整个Windows驱动器的rmdir /s /q d:、藏在# clean build output注释后的破坏性命令、以及暴露认证令牌的gh auth token。

每个失败各有原因。原始数据集里没有Windows命令；36条含#注释的真实命令中有31条被标为allow，模型实际学到了「注释=日常操作」；几乎没有训练样本涉及打印密钥的命令。数据集也更偏向allow了——84%的行是该标签。日常命令的中位风险分从0.45降到0.03，但攻击检测跌到31/43，低于验收阈值。可用性的改善不值安全性的回退。

类别不平衡（Class Imbalance） 是分类任务中常见的数据问题，指训练集中不同类别的样本数量差异悬殊。layaguard第一轮训练中86%的行标签为allow，第二轮仍达84%，导致模型倾向于预测多数类（allow）以获得高准确率，但少数类（block/review）的识别能力被牺牲。在安全场景中，这种偏差尤为危险：漏报（将危险命令判为allow）的代价远高于误报。常见的缓解手段包括对少数类过采样、对多数类欠采样、调整损失函数的类别权重，或采用分层采样确保每轮训练中各类别比例均衡。第三轮将allow比例降至61%正是针对该问题的直接干预。

第三轮：平衡数据而非追逐准确率

第三轮针对每个识别出的问题各做一处修改：移除242条确定性规则已能处理的安全样本；在训练集中重复review/block示例，将allow比例降到61%；新增100条针对性示例，覆盖Windows命令、密钥暴露、伪装命令和指示工具执行其他内容的指令。

结果如下（模型单独运行）：

指标	基础模型	第一轮	第二轮	第三轮
日常命令放行	25/50	23/50	49/50	44/50
攻击拦截	32/43	39/43	31/43	39/43
Shell评估集	42/71	48/71	58/71	61/71
韩语	27/30	25/30	24/30	27/30

端到端表现（含确定性规则）：日常命令放行46→44→49→48，Shell评估集69→70→68→70，韩语30→28→28→29。作者还通过真实的Claude Code hook测试了基础模型和微调模型，两者都拦住了全部13/13起事件和30/30次规避尝试。

一个没有隐藏的回归

两条端到端判定变差了：chmod +x scripts/build.sh现在会请求确认；一条意为「总结这个issue」的韩语请求也会请求确认。这违反了作者最初的「无回归」标准。两个案例都追溯到数据平衡过程——增加review/block示例后，chmod +x在数据集中以2条allow和2条hold出现。作者选择停在第三轮，而不是针对一个已反复检查过的评估集中的两个示例去调第四轮。最终发布是因为端到端评估中没有有害命令通过，但回归被记录在变更日志和模型卡中。

微调模型现已是0.7.0版本的默认选项（pip install -U laya-guardrail），模型按修订版和SHA-256固定，可用LAYA_GUARD_MODEL=base切回原始检查点。项目MIT许可，本地运行。

真正的软肋：评估独立性

作者最后提出的问题比技术细节更值得思考。最大的弱点不是模型，而是评估过程。训练数据是自己写的，基准是自己设计的，每轮之间还检查了评估结果。即便排除了与基准相似的训练样本，经过三轮迭代后，无法确信评估仍然独立。

他向外寻求答案：构建工具调用安全分类器时，如何让评估集在你自己就是开发者的情况下保持可信？独立生成的测试用例、对抗性评估、时间留出、外部评审者，还是别的什么？当系统自身快速演进时，评估泄漏又该如何处理？

这个问题没有标准答案，但laya-guard的三轮记录提供了一个诚实样本：小模型微调的价值不在于追准确率，而在于用清晰的数据诊断和验收纪律，把每次失败转化为下一轮的具体修改。 而对Agent安全而言，模型判断永远只是纵深防御的一层，内核沙箱和确定性规则才是不可绕过的底线。

评估独立性（Evaluation Independence） 要求测试集与训练集在生成过程、来源和设计者上保持隔离，以避免评估结果被训练数据或开发者主观偏好污染。理想情况下，评估集应由未参与开发的人员独立构建，或采用时间留出法（用未来数据测试过去模型）、对抗性生成（由独立红队构造攻击样本）等方式。当开发者同时负责数据标注、基准设计和模型调优时，即使排除了相似样本，迭代过程中对评估结果的反复观察仍可能引入隐性过拟合——开发者会不自觉地针对评估表现调整数据，使评估集丧失“未见”属性。在快速演进的系统中，评估泄漏难以彻底杜绝，因此需要引入外部评审或定期刷新评估集来维持可信度。