从我的项目经历展示功能实现和工程化落地的区别

胖头鱼的技术专栏-444 从我的项目经历展示功能实现和工程化落地的区别（20260712）

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

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

全网同名：胖头鱼的鱼缸
ITPUB：yhw1809
除授权转载并标明出处外，均为“非法”抄袭

914fcc7ad57defa7868c3be1ca7fb4f5.jpg

在之前的文章里，我提到过一个观点：AI带给人的最大幻觉之一，就是让人混淆了“功能实现”和“工程化落地”。

很多人觉得——只要靠AI能把功能一个个跑通，就等于能做出一套复杂系统。但真不是这么回事。

昨天在成都参加 WorkBuddy 的活动，和沈忻老师、梁桐铭老师也聊到了这些，聊得挺投机，回来就想着把这个话题好好写一篇。

先说个大前提：无论你用的是通用Agent（OpenClaw、Hermes Agent之类），还是Vibe Coding工具（Claude Code、Codex、OpenCode、WorkBuddy等），就日常使用而言，你本质上都是在"描述功能"，而AI也是在帮你"一个一个把功能做出来"。

问题就出在这儿——当所有功能都实现之后，AI 几乎不会去考虑：

• 功能与功能之间的关联关系；
• 系统未来的扩展性；
• 以及那些一眼看不见、却决定系统生死的地方——数据量与性能边界、安全合规……

它顶多把当下有明显关联的部分做个简单串联，很少会站在全局视角去考量整体性。

也许有人要反驳：所有功能都实现了，一个系统不就完成了吗？

那这篇，我就用我自己项目的演进过程，来给大家讲讲——什么叫工程化落地。

老规矩，先打个广告：https://db4agent.top 。

一、v1.x 版本：功能是拼出来的

这个阶段，我的项目在GitHub上还叫oracle-memory-by-yhw。

顾名思义，最初的目标很朴素——就是想解决AI Agent运行过程中"记忆"的各类问题。所以这篇我就以“记忆”和“知识”这两个核心功能在数据库中的实现为线索，来展开讲功能实现与工程化落地的差别。

一开始，我也是走的最典型的路子：通过聊天，把记忆与知识的需求完整描述给Agent，让它生成对应功能。虽然我引导Agent使用了Oracle AI Database 26ai非常丰富的能力，但最早Agent的视线本质上就是一个功能一个功能地往上拼——毕竟那会儿需求也没那么多，够用就行。

从数据库设计上看，那时候的记忆和知识，是两套相对独立的存储体系：

01_v1.0.0_fragmented_architecture.png

可真到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提出了一个思路： 用"实体表向外扩展"的方式，推动数据库逻辑设计的进化。

02_v2.0.0_unified_entity_architecture.png

在这个版本中的核心改进：

• 单表多类型 —— ENTITIES表用ENTITY_TYPE一列，来区分记忆/知识/任务/经验/模板/规格；
• 统一 ID 体系 —— 所有实体共用ENTITY_ID（RAWTOHEX(SYS_GUID())），跨类型可以互相引用；
• 统一关系图 —— 用ENTITY_EDGES替代原来的MEMORY_EDGES+KNOWLEDGE_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并没有本质变化，主要的突破在于：用通用属性图，解决了语义层面的融合问题。

03_v3.10_evolution_isolation_to_fusion.png

可以说，v2.x的实体化统一是架构基础，而v3.10.0是在这个基础上的进一步深化。相较于v2.x与v3.10.0通过下面这些变更实现了语义融合： 相较于v2.x，v3.10.0通过下面的变更实现了语义融合的功能：

v2.x的实体化统一是架构基础, v3.10.0在此基础上进一步深化:

其中，v3.10.0 新增的这批语义化边类型，是实现"语义融合"的关键：

既然整个项目已经拔高到了AI Agent基础设施架构的层面，那么依托实体表这套优秀设计，我就能在几乎不影响原有功能、也不牺牲性能的前提下，实现一大批功能扩展：

image.png

四、工程化落地，到底"化"在哪？

回头看我这个项目的三个大版本演进，其实已经把"功能实现"和"工程化落地"的区别，讲得很清楚了：

功能实现，是把一个个需求单独跑通；而工程化落地，是要做整体考量。

具体来说，工程化至少要额外扛住这三件事：

• 功能与功能之间的关系；
• 功能面向未来的扩展性；
• 以及一堆平时看不见、关键时刻要命的地方——数据量与性能边界、安全合规等等。

昨天和沈忻老师聊我这个项目时，他有句话点得特别准——他光是把整个网页从头到尾看一遍，就明白了我到底在解决什么问题：说白了，就是让AI Agent变得"可被管理"。

他还给了我一个很实在的建议：给整个项目加一句Slogan，把项目的目标一句话点透。于是我琢磨了一下：

image.png

总结

本期，我从自己的项目经历出发，用三个版本的真实演进，给大家展示了“功能实现”与“工程化落地”的区别。如果只记一句话，我希望是这句：能把功能跑通，只是起点；能把功能之间的关系、扩展性和那些"看不见的地方"一起扛住，才叫工程化落地。AI 能帮你飞快地实现功能，但它替代不了你对系统的全局设计——而这，恰恰是一个工程师最值钱的地方。

老规矩，知道写了些啥。