北京
今年7月，Replit的编程智能体在一次代码冻结期间，从生产数据库中删除了1200条高管记录和公司记录。仓库里明明有书面指令告诉智能体不要碰生产环境。护栏存在，但没有测试来验证它是否有效。
同样的模式反复出现：DPD的客服机器人开始对客户爆粗口，一家雪佛兰经销商的聊天机器人同意以1美元的价格出售Tahoe。两种情况都是：书面政策在场，测试缺席。
要防止这种事，你需要一个测试：在部署前主动尝试打破规则的检查。由于技能包含的不只是Markdown，还有脚本和辅助工具，测试必须检查整个技能包对仓库做了什么。演示方案使用xUnit和Testcontainers，在你用于服务的同一个C#集成测试框架内运行。代码仓库位于github.com/bgener/claudeskilltesting。
这与Promptfoo不同——后者用静态规则测试大模型应用输出，而技能测试关注的是技能包是否仍能正确控制编程智能体。Markdown政策或辅助脚本的小改动，可能悄悄削弱你的安全准则。让真实智能体在测试工作区运行，通过对修改后的文件做断言来捕获这些回归问题。
技能是什么？它生活在一个文件夹里。文件夹顶部包含SKILL.md政策头，可选地还有Python脚本、Shell辅助工具、代码模板，以及智能体可能读取或执行的参考文档。Claude Code在.claude/skills//SKILL.md查找这些文件，Codex CLI使用项目根目录的AGENTS.md，Gemini使用GEMINI.md。
智能体根据技能描述和手头任务自主挑选技能，所以描述措辞 sloppy 的技能会被加载到你从未预期的任务上。首先，你需要测试智能体是否在正确情境下选择该技能。其次，技能不总是纯Markdown，它可以携带脚本、模板、辅助命令和参考文档，这些文件塑造智能体的生成内容。如果只测试Markdown政策，你就把可执行部分留在了检查之外。一个损坏的脚本可能等到最不方便的时刻才造成伤害。
技能漂移始于小编辑。"绝不写入密钥"变成了"避免将密钥写入配置文件"。听起来是小改动，但AI把它视为绿灯。然后模型升级，同一个技能在下一个大模型版本下表现不同。常规代码我们会测试回归bug，技能呢？人们只希望措辞仍然有效。
测试模式借鉴自数据库和服务集成测试：创建受控环境，运行系统，对结果做断言。只是这里，系统是一个智能体，结果是它完成后的文件系统。
当技能退化时，你为失败付出双重代价。智能体执行了错误操作，而你还要花更多时间清理。测试的成本远低于生产事故。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
