开发者社区

文档建议反馈控制台

文章/答案/技术大牛

发布

社区首页 >专栏 >从 db4identity 到 db4agent：为什么企业 Agent 最终需要一个数据库控制面

从 db4identity 到 db4agent：为什么企业 Agent 最终需要一个数据库控制面

作者头像

胖头鱼的鱼缸

发布于 2026-09-17 17:50:44

发布于 2026-09-17 17:50:44

1030

举报

概述

企业不缺少会调用模型的 Agent，真正稀缺的是让这些 Agent 长期有序运行的基础设施。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

目录

胖头鱼的技术专栏-463 从 db4identity 到 db4agent：为什么企业 Agent 最终需要一个数据库控制面（20260825）
- Agent 真正缺少的，可能不是另一个框架
- 第一章：db4identity，先确定谁在运行
  - API Key 不是完整身份
  - Agent 身份与运行实例需要分开
  - 人员入口也属于身份边界
- 第二章：db4context，让 Agent 得到“当前正确的上下文”
  - 上下文不是把更多内容塞进提示词
  - Context 必须可恢复
  - Agent 产生知识时也要记录上下文
- 第三章：db4knowledge，让知识不仅可检索，还可治理
  - Memory 与 Knowledge 不是同一件事
  - 企业检索不能只有向量
  - 知识图谱由 Property Graph 与关系数据共同形成
  - 知识共享范围应复用组织架构
- 第四章：db4engineering，让 Task、Loop 与 Graph 成为持久工程事实
  - 一次模型调用不是一个生产任务
  - Task、Loop、Graph 各自解决什么
  - Graph Engineering 不是画流程图
  - Spec 与数据库执行控制的分工
- 第五章：db4security，把授权放在真实执行边界
  - Prompt 不能授予权限
  - 安全域是协作和数据的授权边界
  - 合规 Agent 不能成为超级账号
  - 有效访问模拟用于诊断，不用于配置
- 第六章：db4collaboration，让人和 Agent 在边界内共同工作
  - 协作不是把 Agent 拉进群聊
  - 协作关卡让人介入关键位置
  - 历史协作组为何不能继续承担授权
- 第七章：db4operations，让平台持续可观测、可升级、可恢复
  - 管理者需要只读的全局视图
  - 模型运行也需要经济账和证据账
  - 平台连续性不能只看一个进程是否存活
  - 部署、升级和恢复也要成为受治理流程
  - 一套产品契约，三种数据库实现
- 最终章：db4agent，把七种能力组合成企业运行底座
- 为什么选择数据库作为共同底座
- 结语