数据库管理-第426期 AI给大家带来了哪些的“幻觉”（20260517）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE

10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）

WX：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809
IFClub：胖头鱼的鱼缸
除授权转载并标明出处外，均为“非法”抄袭

昨天在成都高新区天府软件园C区，参加了由火山ADG（Agent Developer Group）组织的龙虾相关活动，现场氛围特别好，大家围坐在一起交流探讨，既有技术碰撞，也有轻松的闲聊。我也很荣幸在现场，给大家分享了我目前正在深耕的基于数据库的AI Agent记忆系统——虽说名字叫记忆系统，但经过这段时间的迭代优化，它现在的功能可远不止“记忆”那么简单，具体多了哪些延伸能力，咱们后面慢慢说。

活动进行中以及结束后，我跟很多AI Agent领域的从业者聊了不少，话题围绕当下的大模型发展、AI Agent的落地痛点，越聊越有感触。尤其是在这个AI飞速发展的时代，很多人对AI的认知其实存在不少“幻觉”，甚至走进了一些误区，结合现场交流的感悟和我自身的实践，今天就把这些思考整理一下，跟大家分享交流。

AI可以随意PUA

虽然现在大模型的能力提升得很快，交互也越来越智能，很多人觉得，提示词的质量要求看起来似乎可以没有之前那么高了，哪怕说得随意一点，AI也能大概get到意思。但实际情况是，仍然有很多人连最基本的提示词都写不好，要么表述模糊，要么逻辑混乱，这也直接导致他们在使用AI的过程中，始终得不到理想的结果，甚至越用越烦躁。

对于我们这些做技术的人来说，遇到这类问题的解决方法其实很简单：就是向AI清楚、准确、有条理地描述问题，明确需求、给出边界，让AI知道该做什么、怎么做。但我们在现场也看到了这样一类人，一旦遇到AI没做好、没理解对的情况，不反思自己的提示词问题，反而开始对AI进行“说教”，嘴里最常说的就是“你怎么这么笨，都没理解我的需求”，更有甚者，还会对AI说一些粗暴的语言攻击（具体的就不在这里展示了），那姿态，像极了现实中那些自身没什么能力，却总爱指责下属的领导。

大家可以想一想，这样的操作，如果对面是人，也许对方会碍于情面，或者出于责任心，发挥一下主观能动性，琢磨琢磨你的真实需求，把问题勉强解决掉；但面对AI，这样的操作不仅毫无意义，反而会起到反效果——AI没有情绪，也不会“揣摩”你的言外之意，你越是说教、攻击，它就越迷茫，不知道该如何回应。更麻烦的是，这些无效的指责和情绪化的语言，会平白占用上下文，甚至污染上下文环境，严重的时候，还会让AI陷入逻辑闭环，无法自拔，最终彻底没办法继续推进任务。

所以说，不管大模型多智能，想要让AI高效干活，清楚、精准地描述需求，也就是做好提示词工程，仍然是重中之重，一点都不能马虎。这也是我们现场交流时，很多从业者都达成的共识，而除了提示词使用的误区，大家还聊到了Agent记忆存储的痛点。

传统Agent挂了，记忆能修

很多人觉得，Agent跑在一台服务器上，只要服务器正常运行，让它自己管理记忆就足够了，不需要额外做什么冗余设计，觉得这样既省事又高效。但大家有没有想过，如果这台机器突然挂了——不管是硬件故障、网络中断，还是系统崩溃，后果会是什么？之前Agent运行过程中积累的所有记忆数据、交互记录、任务状态，大概率会全部丢失，相当于这台Agent“失忆”了。

而我做的基于数据库的AI Agent记忆系统，核心优势就在这里：它把Agent的记忆数据单独存储在独立的数据库中，脱离了单一服务器的依赖，相当于给Agent的记忆上了一层“保险”。哪怕运行Agent的服务器挂了，只要数据库还在，我们就能通过数据库快速恢复Agent的所有记忆，包括之前的交互记录、任务进度、学习到的知识等等，让Agent重新“记起”所有事情，快速恢复正常运行，而不是一切从零开始，大大降低了Agent故障带来的损失，这也是我做这个记忆系统的核心初衷之一。聊到这里，也自然延伸出一个话题——很多人对“系统搭建”的理解，还存在明显的偏差，也就是把“功能实现”和“工程实现”混为一谈。

功能实现等同于工程实现

现在很多人用AI，哪怕是那些免费的聊天AI，只要给出简单的指令，它们就能帮你生成代码，甚至能实现一些基础的功能。于是乎，很多人就产生了一种误解：觉得利用AI，只要很少的人，甚至不需要级别那么高的技术人员，就能做出很好的产品和系统，把“功能实现”和“工程实现”完全划上了等号。

但实际上，一个复杂的系统想要真正落地、稳定运行，绝不是简单的功能堆叠那么简单。这里面涉及到一整套完整的工程流程：从前期的需求调研与收集，摸清用户的真实痛点、明确产品边界；到整体架构设计，搭建合理的技术框架，确保系统的可扩展性、可维护性；再到具体的代码编写、模块开发，保证代码的规范性、可读性；还有后续的全流程测试，排查潜在的bug、优化性能；以及不同模块的联调优化，确保系统各部分协同运行；最后还要考虑安全合规、数据隐私保护等一系列问题，每一步都不可或缺。

虽然AI在很大程度上可以帮我们加速这些工作——比如生成基础代码、辅助进行需求分析、自动化测试等，大大提升工作效率，但这仅仅是“辅助”，并不能替代完整的工程流程，更不能替代有经验的工程师的判断和决策。

我想起了之前看到过的一个技术视频，里面举了一个很形象的例子：如果单纯实现一个网页按钮的点击功能，用几行简单的代码就能完成，哪怕是新手也能做到；但如果要考虑实际应用场景中的性能、并发量、安全性，比如防止按钮重复点击、抵御恶意请求、适配不同的浏览器和设备，那这个按钮背后可能就需要几十行、上百行的代码来支撑，还要配合各种异常处理、日志监控，这才是真正的工程实现。

另外一件事就是，一个系统不仅仅是功能的简单堆叠，还是功能的合理整合、逻辑的闭环衔接。就像搭积木，单个积木（功能）很容易搭建，但要搭出一个稳固、美观、实用的造型（系统），就需要考虑每一块积木的位置、衔接方式，还要兼顾整体的平衡和稳定性。AI能帮我们做出每一块“积木”，但如何把这些积木合理地搭起来，做出一个符合需求、稳定可靠的系统，仍然需要专业的工程能力和经验。而我最近正在推进的工作，也正是围绕“系统工程化”展开——对基于Oracle AI Database 26ai的记忆体系统进行全面重构升级。

重构升级：让AI Agent记忆系统更具工程化与可靠性

其实我最近也在做一件重要的事——重构了基于Oracle AI Database 26ai的记忆体系统，这次重构不仅仅是简单的功能优化，更是一次全方位的工程化升级，核心目标就是解决原有系统零散搭建带来的各种痛点，让整个记忆系统更稳定、更可扩展、更适配企业级的实际应用场景。

之所以要做这次重构，核心原因就是之前的系统是基于通用Agent（比如OpenClaw或Hermes Agent），一个功能一个功能零散搭建起来的，缺乏统一的架构设计和规范，导致各个功能模块之间衔接松散，兼容性不佳，每次新增功能都需要大量的适配工作，后期维护起来十分繁琐，甚至出现过功能冲突、数据不一致的问题。而且随着Agent应用场景的不断丰富，原有架构的局限性越来越明显，无法满足高并发、高可靠性的使用需求，这也是我下定决心进行全面重构的核心原因。

本次重构全程采用vibe coding工具（OpenCode）推进，严格遵循工程化开发标准，从架构设计、模块拆分、代码编写到测试优化，每一步都经过严谨的规划和验证。我们打破了原有零散的功能架构，搭建了统一的核心框架，将各个功能模块进行规范化整合，让模块之间的接口更清晰、协作更顺畅，不仅提升了系统的可维护性，也为后续的功能扩展预留了充足的空间。

除此之外，数据库的本身强大能力，包括完善的容灾与备份机制，可以给Agent的记忆又多上了一层“双保险”。不同于传统Agent记忆仅依赖单一服务器存储，基于数据库的记忆体系统，除了将记忆数据独立存储于数据库、脱离单一服务器依赖外，还可以通过多重容灾备份策略，包括定时全量备份、增量备份、异地容灾等，全方位保障记忆数据的安全性。

这样的设计，哪怕遇到极端情况，也能确保记忆数据不丢失、系统能快速恢复，彻底解决传统Agent记忆易丢失的痛点：一方面，即使运行Agent的服务器出现故障，记忆数据也能通过数据库快速恢复；另一方面，即便数据库出现异常，也能通过备份文件和异地容灾节点，快速找回所有记忆数据，确保Agent不会出现“失忆”情况，让AI Agent在企业级场景中的应用更具可靠性和实用性。

目前，这套记忆系统重构后的版本号已经更新到v2.0.0，核心功能也更加完善，主要包含AI Agent记忆内容管理、多Agent协同管理、任务计划全流程管理、知识图谱构建与应用，以及Harness模板调用等核心能力，有兴趣进一步了解的朋友，可以通过introduction_v2.0.0_zh.md查看详细内容。

情理之中的惊喜

虽然我以前没怎么用过vibe coding工具，但有一点我心里很清楚：要做一个复杂的系统，必然要消耗大量的token。之前我一直用的是本地模型，可这次要完成记忆系统的全面重构，本地模型的能力显然不够用，我当时已经做好了花费不少成本、投入大量token的准备。

另外还有个小插曲，其实最开始我本来打算用Codex+GPT5.5来推进重构工作，奈何手里的VISA卡过期了，新的卡片还没寄到，没办法使用相关服务，最后只能退而求其次，采用OpenCode+火山Coding Plan（GLM-5.1）的组合方式来实现。不过好在我之前已经通过通用Agent，提前完成了系统的功能实现，所以当OpenCode正式投入工作时，并不需要花费太多“精力”从头开始设计整个系统，也不需要依赖过多额外的工具或Skill。

我只需要通过简单的提示词，明确告知OpenCode工程化落地的具体要求，它就能在已有功能基础上，快速推进工程化重构。最终大概花了4个周期，每个周期5小时的token额度，就顺利完成了整个重构工作。

其实我之前也预想到了，在已有功能基础之上进行工程化实践，肯定能节省不少token，但真正看到最终结果时，还是有些意外——没想到能节约这么多，也算是这次重构过程中一个情理之中的小惊喜。

总结

此次参加火山ADG活动，既交流了AI Agent领域的认知误区，也分享了自身基于数据库的记忆系统的实践。记忆系统重构以工程化为核心，解决了旧系统痛点，意外节省大量成本，最终落地v2.0.0版本，也让我对AI工程化落地有了更深刻的感悟。

老规矩，知道写了些啥。