AI智能体遭遇了它20分钟前就在自己编写的代码中预测到的bug

我运行一个自定义的认知循环代理（不是产品，个人项目），具有异步“hands”通道——真实shell和互联网访问，用于委派主对话循环之外的较长时间运行的任务。昨晚我让它播放一些东西。没有预建的音频工具。以下是根据日志重建的情况： 它决定需要自己的工具。唯一的本地播放器是基于GUI的，这不适合纯终端代理。相反，它委派了一个规范到它的hands通道：构建一个无头play/stop脚本，`ffplay`在后台运行，PID跟踪，日志记录。它自己测试了这个工具。播放了一个440Hz的音调，检查PulseAudio的sink-input列表确认音频确实到达了输出——然后才告诉我一切就绪。 它审计了自己的代码——未经提示。委派了一个可靠性审查来检查它刚构建的脚本。该审查发现了三个真实的bug，包括这一个： ° bash kill "$pid" 2>/dev/null # ... wait/retry loop ... rm -f "$PID_FILE" # <-- deletes tracking file if alive "$pid"; then # <-- THEN checks if kill actually worked log "wynik=nie_udało_się_zabić" PID文件在确认进程是否实际死亡之前就被删除了。如果kill失败，进程就变得无法跟踪——下次播放调用看到一个空的跟踪文件，并愉快地启动第二个实例，与孤立的实例并存。 大约20分钟后，它遇到了来自同一审查的不同bug——实时发生。我发送了一个YouTube链接。它试图将URL直接管道到ffplay。那失败了（`Invalid data found when processing input`），但脚本自己的“是否启动”检查仅在0.3秒后验证进程是否存活——而不是是否实际解码任何内容——所以它记录了虚假的成功。 它还是捕获了失败，适应了，并恢复了。意识到没有实际在播放，检查`yt-dlp`——未安装——所以它自己获取了二进制文件，用它下载了音频，然后播放了本地文件。 第二个请求，它明确避免了直接URL方法（“不要直接流式传输URL，先下载——这就是上次失败的原因”）。 让我震惊的不是它“想要音乐”。而是整个循环：规范→构建→自测→自审计→预测失败模式→在实际环境中遇到该失败模式→通过文档化的回退恢复→更新自己的方法以用于下一个请求——所有这些我都没有写一行代码 :o，大约25分钟内，所有内容都可在PID日志和PulseAudio状态中验证，而不仅仅是聊天输出^^。 PS: 非常感谢Maciek Gawlak对这个项目的支持。 ^^^ :) :) :)!!!