在70年代的计算机领域，有一个十分著名的计算机游戏-龙宫探宝。这是一个早期大型机、中型机、小型机上都广泛部署的游戏。刚开始是汇编语言编写的，后来又有好事之徒用C改写了。这不是一家游戏公司的产品，而是一些计算机软硬件和系统开发者闲极无聊搞出来娱乐身心的。我们这帮老家伙都是大学里玩过DJS8中型机的，当年在学校上机实习的时候，我发现了一个标名games的目录，里面藏了一些c代码，居然都能编译通过，龙宫探宝就是其中一个，另外还有大家都很喜欢玩的“虚拟国家”。在刚刚工作的时候我也玩过几年vax小型机，我居然在games目录里找到了坦克大战、俄罗斯方块、PACKMAN等的c源码。

　　我们这些看过《新机器的灵魂》这本数的人，对于“龙宫探宝”有种特殊的迷恋。对于70年代的系统设计人员来说，如果一台计算机被生产出来了，被证明计算机和OS都没问题的一个重要的测试用例就是这个游戏。

　　帮我写一个Oracle的运维脚本（sql脚本或者shell脚本），分析数据库当前的存储容量是否存在风险，要根据表空间、文件系统、ASM磁盘组的情况，不是简单的根据表空间使用率判断，因为数据库文件可以扩展，对于bigfile扩展几乎是无限的，但是普通的文件，还会受到块大小的限制。底层的文件系统、ASM磁盘组也会限制总容量。

　　这是一个我们用于测试智能体脚本生成能力的“龙宫探宝”，Oracle的表空间使用率分析一直是一个挺麻烦的事情，因为涉及的地方特别多，传统的监控系统中直接从dba_tablespace/dba_data_files得到的使用率几乎是没有任何意义的，因为很多文件可能是支持自动扩展的，这么算出来的使用率没有意义。因为这个计算的复杂性，Oracle 不得已在12c里提供了一个“近似估算值”的Metric,不过文档上也做了说明，这只是一个近似的估算，不能完全替代真实环境的针对性计算。这个说明也证明了写出这个脚本的难度，公司的老储是90年代初的unixware核心的研发人员，对于编程是比较痴迷的，就是他也不太愿意接这个任务，后来被我们逼的没办法才花了半个多月写了一个。

　　我觉得bicagent如果能够一次性正确地写出这个脚本，运维脚本编写工具才算是及格了。于是上周我花了一天时间来优化知识图谱，让运维脚本编写工具能够一次性完成这个任务。首先我要通过codex来试试这个任务是否能很好地完成，不过经过三四轮交流之后，codex还是无法理解我的需求，生成出来的脚本还是那些常见的监控工具采集dba_tablespace/dba_free_space/dba_data_files这三个视图的，我刚才说的没啥实战价值的脚本。

　　在bicagent上的调试也不顺利，最终想要一次过的想法也没能实现，最终的问题居然是在shell语法的小阴沟里翻了船，在没有沙箱验证的情况下，仅仅依靠知识库还是很难让智能体在一些细节上都做得完美。我想最终的生产环境里，一定要建议有条件的用户把主要的沙箱都搞起来。

　　最终的结果还是很令人震惊的，仅用了一段简单的描述，就完成了完美的最终呈现。当然如果把任务描述得更加明确，不借助知识库，AI 也可能写出这样的脚本。不过在Qwen3.6-35b-a3b上，仅凭简单的描述，AI就完成得如此完美。这说明AIOPS向着实战化的目标又前行了一大段了。