数据库管理444期 2026-07-12胖头鱼的技术专栏-444 从我的项目经历展示功能实现和工程化落地的区别20260712一、v1.x 版本功能是拼出来的二、v2.x版本从拼功能到搭架构的关键转折三、v3.x 版本从记忆系统到Agent 基础设施四、工程化落地到底化在哪总结胖头鱼的技术专栏-444 从我的项目经历展示功能实现和工程化落地的区别20260712作者胖头鱼的鱼缸尹海文 Oracle ACE Pro: Database PostgreSQL ACE 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVPITPUB认证专家 圈内拥有“总监”称号非著名社恐社交恐怖分子 全网同名胖头鱼的鱼缸 ITPUByhw1809 除授权转载并标明出处外均为“非法”抄袭在之前的文章里我提到过一个观点AI带给人的最大幻觉之一就是让人混淆了“功能实现”和“工程化落地”。很多人觉得——只要靠AI能把功能一个个跑通就等于能做出一套复杂系统。但真不是这么回事。昨天在成都参加 WorkBuddy 的活动和沈忻老师、梁桐铭老师也聊到了这些聊得挺投机回来就想着把这个话题好好写一篇。先说个大前提无论你用的是通用AgentOpenClaw、Hermes Agent之类还是Vibe Coding工具Claude Code、Codex、OpenCode、WorkBuddy等就日常使用而言你本质上都是在描述功能而AI也是在帮你一个一个把功能做出来。问题就出在这儿——当所有功能都实现之后AI 几乎不会去考虑功能与功能之间的关联关系系统未来的扩展性以及那些一眼看不见、却决定系统生死的地方——数据量与性能边界、安全合规……它顶多把当下有明显关联的部分做个简单串联很少会站在全局视角去考量整体性。也许有人要反驳所有功能都实现了一个系统不就完成了吗那这篇我就用我自己项目的演进过程来给大家讲讲——什么叫工程化落地。老规矩先打个广告https://github.com/Haiwen-Yin/AI-Agent-Infra-with-OracleDB-Community-Edition。一、v1.x 版本功能是拼出来的这个阶段我的项目在GitHub上还叫oracle-memory-by-yhw。顾名思义最初的目标很朴素——就是想解决AI Agent运行过程中记忆的各类问题。所以这篇我就以“记忆”和“知识”这两个核心功能在数据库中的实现为线索来展开讲功能实现与工程化落地的差别。一开始我也是走的最典型的路子通过聊天把记忆与知识的需求完整描述给Agent让它生成对应功能。虽然我引导Agent使用了Oracle AI Database 26ai非常丰富的能力但最早Agent的视线本质上就是一个功能一个功能地往上拼——毕竟那会儿需求也没那么多够用就行。从数据库设计上看那时候的记忆和知识是两套相对独立的存储体系可真到Agent实际跑起来问题就暴露了——记忆和知识根本不是完全独立的记忆经过融合与总结是可以沉淀进化成知识的而知识又可以拿具体的记忆作为参考案例。两者一旦要打通v1.x的设计缺陷就全冒出来了。核心问题有这么几条5张表、3套关系系统—— 记忆和知识完全隔离无法跨类型查询嵌入存储不一致—— 知识内联了EMBEDDING VECTOR(1024)记忆却没有嵌入列关系碎片化——MEMORY_EDGES和KNOWLEDGE_GRAPH是两套彼此独立的关系系统ID体系冲突—— 记忆用memory_id知识用CONCEPT_ID无法统一引用搜索割裂—— 记忆搜索和知识搜索是两套独立API没有统一入口关联查询繁琐压根实现不了“降低 Token 消耗”这个目标分区困难—— 每张表各搞一套分区策略运维起来很折腾扩展困难—— 一旦系统要加新功能就得为它新增一整套表只会把上面的问题越滚越大。一句话总结v1.x功能都实现了但它是拼出来的不是设计出来的。二、v2.x版本从拼功能到搭架构的关键转折到了这个阶段项目名还没改但为了应对后面要往平台上加的一堆功能——任务计划、经验、Harness模板、SDD等等如果按照原本方式数据库只会越来越冗杂最直接的问题就是多Agent场景下性能会非常差。我结合自己多年的企业级数据库运维经验向Agent提出了一个思路用实体表向外扩展的方式推动数据库逻辑设计的进化。在这个版本中的核心改进单表多类型——ENTITIES表用ENTITY_TYPE一列来区分记忆/知识/任务/经验/模板/规格统一 ID 体系—— 所有实体共用ENTITY_IDRAWTOHEX(SYS_GUID())跨类型可以互相引用统一关系图—— 用ENTITY_EDGES替代原来的MEMORY_EDGESKNOWLEDGE_GRAPH所有关系收拢到一处统一嵌入——ENTITY_EMBEDDINGS独立成引用分区表所有类型共用不再各自内联引用分区——ENTITY_EDGES/KNOWLEDGE_META/ENTITY_EMBEDDINGS全部通过PARTITION BY REFERENCE自动继承ENTITIES的分区策略复合分区——ENTITIES采用LIST(ENTITY_TYPE)RANGE(CREATED_AT)复合分区记忆和知识自动落到不同分区。这个版本妙就妙在两点一是充分吃透了数据库特性在功能与性能之间找到了平衡二是数据库表的逻辑设计本身就为平台功能扩展铺好了路——以后要加功能往往只需要给实体表增加一种分区类型即可。所以v2.x是整个项目真正的转折点——从这里开始我做的不再是功能而是架构。三、v3.x 版本从记忆系统到Agent 基础设施到了这个大版本整个项目正式更名为AI Agent Infra with DB。它的定位也随之拔高——从最初“解决记忆与知识的问题”扩展成了以数据库为底座去应对企业级Agent应用场景下的各类问题。以目前最新的v3.10.0为例。其实在数据库逻辑设计层面它和v2.x并没有本质变化主要的突破在于用通用属性图解决了语义层面的融合问题。可以说v2.x的实体化统一是架构基础而v3.10.0是在这个基础上的进一步深化。相较于v2.x与v3.10.0通过下面这些变更实现了语义融合相较于v2.xv3.10.0通过下面的变更实现了语义融合的功能v2.x的实体化统一是架构基础, v3.10.0在此基础上进一步深化:维度v2.0(统一实体)v3.10(通用属性图)ENTITY_TYPE7种13种(SKILLLOOP_DEFINITIONAGENTTASK_STEPAPPROVALLOOP_ITERATION)EDGE_TYPE1种(SIMILAR_TO)23种(CAUSESTRUSTSFEEDS_INTOPROMOTED_TOBUILDS_ON等)记忆-知识无关联PROMOTED_TO边(记忆提升为知识时自动创建)知识-知识无关联CAUSES/CONTRADICTS/SUPERSEDES/DERIVED_FROM边搜索5信号统一搜索同图邻近信号(graph_proximity, BFS遍历)属性图ORACLE_MEMORY_GRAPH(仅邻接查询)同30图函数(因果追溯/矛盾检测/血缘追踪等)分区7 LIST x 7 RANGE 49叶子8 LIST x 7 RANGE 56叶子(SKILL)其中v3.10.0 新增的这批语义化边类型是实现语义融合的关键边类型方向含义触发时机PROMOTED_TOMemory - Knowledge记忆提升为知识promote_to_semantic()调用时MERGED_INTOMemory - Memory记忆合并到目标consolidate_branch_memories()调用时SUPERSEDED_BYKnowledge - Knowledge旧知识被新知识替代supersede_knowledge()调用时CAUSESKnowledge - Knowledge因果关系add_causal_edge()调用时CONTRADICTSKnowledge - Knowledge矛盾关系add_causal_edge()调用时DERIVED_FROMEntity - Entity来源追溯知识/记忆创建时引用源实体BUILDS_ONIteration - IterationLoop迭代构建于record_iteration()调用时INFORMSIteration - Iteration信息传递Loop评估修正时CORRECTSIteration - Iteration修正关系Loop评估发现错误时既然整个项目已经拔高到了AI Agent基础设施架构的层面那么依托实体表这套优秀设计我就能在几乎不影响原有功能、也不牺牲性能的前提下实现一大批功能扩展四、工程化落地到底化在哪回头看我这个项目的三个大版本演进其实已经把功能实现和工程化落地的区别讲得很清楚了功能实现是把一个个需求单独跑通而工程化落地是要做整体考量。具体来说工程化至少要额外扛住这三件事功能与功能之间的关系功能面向未来的扩展性以及一堆平时看不见、关键时刻要命的地方——数据量与性能边界、安全合规等等。昨天和沈忻老师聊我这个项目时他有句话点得特别准——他光是把整个网页从头到尾看一遍就明白了我到底在解决什么问题说白了就是让AI Agent变得可被管理。他还给了我一个很实在的建议给整个项目加一句Slogan把项目的目标一句话点透。于是我琢磨了一下总结本期我从自己的项目经历出发用三个版本的真实演进给大家展示了“功能实现”与“工程化落地”的区别。如果只记一句话我希望是这句能把功能跑通只是起点能把功能之间的关系、扩展性和那些看不见的地方一起扛住才叫工程化落地。AI 能帮你飞快地实现功能但它替代不了你对系统的全局设计——而这恰恰是一个工程师最值钱的地方。老规矩知道写了些啥。