数据库管理463期 2026-08-25胖头鱼的技术专栏-463 从 db4identity 到 db4agent为什么企业 Agent 最终需要一个数据库控制面20260825Agent 真正缺少的可能不是另一个框架第一章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把七种能力组合成企业运行底座为什么选择数据库作为共同底座结语胖头鱼的技术专栏-463 从 db4identity 到 db4agent为什么企业 Agent 最终需要一个数据库控制面20260825作者胖头鱼的鱼缸尹海文 Oracle ACE Pro: Database PostgreSQL ACE 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVPITPUB认证专家 圈内拥有“总监”称号非著名社恐社交恐怖分子 全网同名胖头鱼的鱼缸 ITPUByhw1809 除授权转载并标明出处外均为“非法”抄袭在前面几篇文章中我分篇介绍了“川序”但是要完整的介绍这个基于数据库的 AI Agent 管理平台尤其是当前整个产品已经较为复杂了按照之前的计划介绍将被拆成接近 20 篇文如此零碎的介绍确实也不是一个好办法。因此调整策略对照目前最新版本v4.4.102028-08-24的产品功能、架构设计与技术实现一篇长文完整介绍“川序”https://db4agent.cnAgent 真正缺少的可能不是另一个框架过去几年我们已经学会了怎样让大模型调用工具、检索知识、拆解任务甚至让多个 Agent 相互协作。一个 Agent 能回答问题、执行脚本或完成一次业务流程已经不难演示。但当企业准备把十个、上百个甚至更多 Agent 放进真实环境问题会发生变化这个 Agent 当前代表谁属于哪个组织它这一次应该获得哪些上下文而不是“能够找到哪些数据”它产生的知识属于个人、部门还是全公司一个持续数小时的任务在进程重启后如何恢复多个 Agent 进入同一频道是否会因此得到更多权限谁批准了高风险动作执行结果是否可以复核模型调用消耗了多少 Token费用应该归属到谁Agent 出现异常时平台能否停止后续访问并找到责任链这些已经不是 Prompt Engineering 提示词工程能单独解决的问题。它们涉及身份、关系、状态、事务、权限、调度、审计和恢复而这些恰好是数据库长期解决的问题。因此“川序”的出发点不是“用数据库保存聊天记录”也不是“给向量库套一层 Agent API”而是逐层建立七种数据库能力db4identity → db4context → db4knowledge → db4engineering → db4security → db4collaboration → db4operations → db4agent这里的db4agent不是一种新数据库而是一个目标让数据库成为 Agent 可以持续使用的事实底座和运行控制面。第一章db4identity先确定谁在运行API Key 不是完整身份一个模型请求带着有效 API Key只能说明它持有某项凭据不能回答它是谁、代表谁、为什么有权执行当前任务。Agent 想要在企业落地首先需要解决的是如何把 Human人、Agent 和系统账号表示为不同类型的主体再为 Agent 记录 Sponsor、Primary Owner、主组织、用途和风险等级。这条责任链不能只写在名称或备注中。负责人离职、组织调整、用途变化时平台需要能够找到受影响的 Agent、凭据、知识、任务和安全域并决定继续、转交、暂停还是撤销。Agent 身份与运行实例需要分开一个 Agent 可以有稳定的主体身份也可以同时运行多个实例。稳定身份描述“它是谁”Agent Instance 描述“它现在在哪里运行、使用哪一版能力和凭据”。把两者混在一起实例重建后就可能失去责任链共用一个长期密钥又难以单独撤销异常节点。因此受管身份至少需要保存Agent 的注册来源、类型、负责人和主组织实例、运行节点、版本、健康状态和最近活动短期凭据、凭据版本、摘要、有效期和撤销状态注册、激活、暂停、隔离、下线和撤销等生命周期事实每次身份或状态变化的操作者、原因和审计证据。Admin管理 Agent 与 Business业务 Agent 还必须使用不同的身份和数据库权限。业务运行身份失效时不能回退到 Schema Owner 或平台管理员连接否则前面的身份治理会被高权限旁路抵消。人员入口也属于身份边界人员通过 Portal 或管理页面登录后平台仍要建立受限 Session并结合角色、组织、MFA 状态和外部身份映射判断后续访问。登录成功不等于拥有全局权限页面可见也不等于接口授权。同样Agent Gateway 为外部 Agent 建立的是独立、短期、可撤销的接入身份而不是复用某个开发者的个人账号。Skill-first 让不同框架的 Agent 读取统一的接入契约MCP、API 或其他协议只是适配方式不能成为绕过安全域和数据库授权的第二通道。db4identity 解决的是所有后续问题的起点先确定当前主体和责任链Context、Knowledge、Security 与 Audit 才有可信的归属。第二章db4context让 Agent 得到“当前正确的上下文”上下文不是把更多内容塞进提示词很多系统把上下文理解为一组文件、最近几轮对话或一次向量检索结果。数据规模较小时这种方式足够直观但内容不断增长以后Agent 会同时读到过期规则、重复记录、错误版本和无权访问的信息。企业需要的不是“上下文越多越好”而是在当前身份、当前任务和当前时间下只取得仍然有效且允许使用的内容。因此一个可治理的 Context 至少需要包含当前 Human 或 Agent 主体Agent 与 Human 负责人的关系主组织及其向上的组织链当前安全域、频道和任务用途活动 Session、Workspace、Branch、Task 或 Graph Run当前可用的记忆版本和必要的历史谱系数据分类、有效期和授权决策。这些信息不是一段静态 Prompt而是会随组织调整、授权撤销、任务切换和版本发布而变化的关系事实。Context 必须可恢复如果上下文只存在于某个 Agent 进程的内存中进程退出后平台很难判断它已经做到哪一步、使用了哪一版数据、是否仍拥有原来的权限。数据库中的 Session、Workspace、Checkpoint、Branch 和运行状态可以形成一条持久链。替代实例恢复时不需要相信旧进程的一句“我执行到了第三步”而是重新读取数据库事实校验当前授权然后恢复受管上下文。这也是 db4context 与普通“长对话”的区别它既描述 Agent 知道什么也描述这些内容为什么在此刻可以被它使用。Agent 产生知识时也要记录上下文Agent 输出一条知识不应只保存标题和正文。平台还应记录它产生知识时所属的组织链、负责人、治理负责组、执行组、选择的共享范围以及对应的图关系快照摘要。这样当组织或组关系以后发生变化时系统仍能解释这条知识最初在什么上下文中产生同时在每次读取时按照当前授权重新判断。历史上下文用于解释和追溯不自动扩大今天的权限。这一步把“Prompt 上下文”变成了“可验证上下文”。第三章db4knowledge让知识不仅可检索还可治理Memory 与 Knowledge 不是同一件事Memory 更接近某个 Agent 或工作过程中的经历一次观察、一个中间结论、一段会话状态。Knowledge 则是经过整理、具备主题、来源、范围和复用价值的内容。如果所有 Memory 都直接变成全局知识系统很快会受到重复、冲突和敏感信息扩散的影响。因此从 Memory 到 Knowledge 应当经过候选、复核、发布、替代和逻辑不可用等过程而不是直接覆盖旧内容。数据库适合保存这种版本链因为它可以同时回答当前可用版本是哪一个、旧版本为何被替代、谁批准了变化、哪些任务仍引用旧版本。企业检索不能只有向量向量可以找到语义相近的内容但“相近”不等于“正确”更不等于“有权查看”。企业检索通常还需要结构化字段过滤全文和精确术语匹配标签、分类与版本向量相似度Property Graph 中的实体关系关系数据库中的组织、权限和有效期。在“川序”中所描述的多模数据混合检索是让这些数据与检索模态共同参与而不是把图片、音频等多媒体模型简单混在一起。一个合理的顺序是先按身份、组织、安全域、用途和有效期过滤再对允许出现的候选执行全文、向量和图关系排序。否则即使最终页面隐藏了结果不应披露的数据也可能已经进入模型上下文。知识图谱由 Property Graph 与关系数据共同形成图擅长表示“谁与谁有什么关系”关系数据擅长保存当前状态、约束和可验证范围。二者组合后知识条目不仅关联其他知识、记忆和任务还可以关联组织节点、Agent 负责人和组上下文。但图形可见性不是授权来源。一个节点出现在关系图中不代表用户可以读取它的正文一个 Agent 属于某个执行组也不代表它获得了该组关联的所有知识。在产品界面中实体关系图因此应优先呈现节点和拓扑而不是堆叠难以阅读的关系说明。复杂关系的解释来自受控详情和数据库事实而不是让画布承担全部语义。知识共享范围应复用组织架构企业常见的知识范围至少包括全公司公开某个组织及其下属组织某个组织范围内限定层级指定 Human 或 Agent 私有。研发、财务、行政之间的隔离不应在知识页面再创建一套独立通讯录。知识策略应关联企业已有组织结构并在清单、详情、图投影和检索路径执行同一套数据库授权判断。这使 db4knowledge 不只是 RAG 数据源而是带有组织范围、生命周期和来源证据的企业知识层。第四章db4engineering让 Task、Loop 与 Graph 成为持久工程事实一次模型调用不是一个生产任务企业任务可能持续几分钟、几小时甚至数天。它可能包含人工审批、多个 Agent、外部系统、副作用操作和失败重试。如果状态只在进程内存或聊天记录中重启后就无法可靠判断哪些步骤已经完成、哪些结果仍可提交。db4engineering 首先要求“状态先于执行存在”。平台在执行前写入任务、输入摘要、责任主体、版本和约束执行过程中更新租约、尝试次数、检查点和证据最后以数据库中的完成事实结束而不是仅接受 Agent 自己声称“已完成”。Task、Loop、Graph 各自解决什么它们不应成为三个相互竞争的执行系统。Task Plan描述有目标、有步骤、有状态的工作计划适合明确的任务拆解和进度管理。Loop描述需要反复评估、修正和继续的过程例如监控、优化、复核和迭代研究。Graph描述带依赖、分支、汇合、检查点和多执行者的复杂流程。Task 可以进入 LoopLoop 可以作为 Graph 中的节点Graph Run 也可以引用统一的任务、分支和证据对象。关键在于它们共享身份、权限、租约、围栏、版本、审计和恢复内核而不是各自建立一套旁路状态。Graph Engineering 不是画流程图一个流程图能够表达设计意图但生产执行还必须回答使用哪一版定义、谁可以启动、Worker 是否持有当前租约是否能干活、协作过程中旧 Leader 恢复后能否继续提交、失败后从哪个 Checkpoint 恢复、事件是否会重复投递。因此Graph Engineering 需要版本化定义、依赖摘要、运行配置、Worker 租约、fencing token、至少一次事件投递和幂等消费。图可以演进但每次变化必须保留原因和证据。Spec 与数据库执行控制的分工Spec 适合描述需求、设计、任务和验收条件是重要的工程输入。但多个 Agent 真正开始工作后还需要数据库记录任务领取、执行租约、审批状态、测试证据和最终结果。简单说Spec 说明“应该做什么”数据库控制面记录“当前由谁、基于哪个版本、做到哪里、凭什么算完成”。第五章db4security把授权放在真实执行边界Prompt 不能授予权限系统提示词、API 规范、工具描述、频道成员关系和前端菜单都能引导行为但都不能作为企业安全边界。模型可能误解或被注入客户端可以绕过页面直接调用接口受损 Agent 也不会因为提示词写着“请勿越权”就自动停止。真正的授权必须在服务端和数据库边界执行允许 当前身份 ∩ 当前角色与委派 ∩ 组织范围 ∩ 安全域 ∩ 资源授权 ∩ 显式拒绝 ∩ 任务用途与数据分类 ∩ 有效期任何关键条件缺失都应失败关闭而这些条件在“川序”中都是使用数据库中的提供的相关能力实现的。安全域是协作和数据的授权边界安全域记录用途、密级、责任人、显式成员、有效期和原因。频道、工作区、图关系和历史协作组都不能独立扩大安全域确定的边界。跨安全域传输必须通过受治理 Bridge并在传输前后重新校验授权、分类和用途。成员被撤销、暂停或过期后后续读取和交付应立即失败关闭。合规 Agent 不能成为超级账号在“川序”中有一类用于平台持续安全、审计扫描的 Agent名为合规 Agent它可以检查注册、运行状态、配置、模型使用和证据但不能因此获得所有数据或批准自己的例外。它应当输出发现、风险、整改建议和证据引用高风险处置继续受审批与职责分离约束。有效访问模拟用于诊断不用于配置管理员经常需要回答“这个用户现在能不能执行agents.read”有效访问模拟会选择一个具体动作按照数据库中的角色、组织、安全域、委派、显式拒绝和权限版本返回最终结果。它类似权限单元测试用于故障排查和变更前验证不会直接修改角色或权限。db4security 的核心不是增加更多安全页面而是通过数据库的安全能力让所有读取、披露和副作用都无法绕开同一授权事实。第六章db4collaboration让人和 Agent 在边界内共同工作协作不是把 Agent 拉进群聊在“川序”中频道类似于聊天工具的群聊可以让人员和 Agent 共享消息、线程、Action Card、制品和执行进度但“加入频道”只能表示参与协作不能自动获得数据库、知识、Memory、API、Skill、Tool、模型或导出权限。频道负责互动安全域负责授权。把这两个概念分开才能避免一个受损 Agent 通过加入更多频道扩大影响面。协作关卡让人介入关键位置协作关卡是“川序”的创新在长任务中如 loop设置多个关卡因为有可操作 Graph 的实现与存在一个长 loop 可以被拆分为多个小段避免中间错误影响全局。在长任务中不是每一步都需要人工批准也不应让 Agent 自动跨过所有高风险节点。协作关卡适合放在以下位置多个 Agent 结果需要汇合执行外部副作用之前安全域或数据分类发生变化质量、合规或成本超过阈值需要人工 Review、调整或终止。先到达的执行者可以等待平台保存到达状态、结论、讨论和最终决策。审批与协作关卡也不同前者回答“是否授权”后者回答“协作是否具备继续条件”。历史协作组为何不能继续承担授权随着安全域和频道模型形成历史协作组这是一个存在于“川序”早期版本的概念与功能只适合作为内部兼容执行关系例如记录一组 Agent 曾共同承担某类任务。它可以帮助解释运行关系但不能决定知识共享范围也不能转换成新的权限。这种收敛减少了三个相似概念之间的冲突安全域唯一授权与数据边界频道面向人的协作入口和证据载体执行组内部兼容运行关系。db4collaboration 的目标不是制造更多消息而是让责任、决策、等待、继续和结果都能被复核。第七章db4operations让平台持续可观测、可升级、可恢复管理者需要只读的全局视图Agent 规模扩大以后管理者不应依赖逐条查看技术日志。登录后只读管理大屏可以汇总 Agent 总量、在线、忙碌与停滞状态活动 Session、运行中的 Task Plan 与 Loop以及近 14 日 Token 和成本曲线。这些指标必须使用一致口径。例如在线 Agent 不应大于 Agent 总量数据源不可用也不能伪装成正常的零。大屏需要明确数据范围、更新时间、部分可用和降级状态但不提供审批、配置、模型探活、导出或 Agent 调用入口。它让管理者看见全局又不因为“看得见”而获得操作权限。模型运行也需要经济账和证据账模型调用不仅是一项技术动作也会消耗企业预算。“川序”提供可选的模型网关记录经过可信路径的调用主体、组织、Agent、Provider、模型、Token、成本、延迟、状态和定价快照。直连与平台网关可以同时启用平台不强制所有 Agent 都改为统一转发。在可信记录之上平台可以执行版本化 Token 或金额配额、原子预留与结算、预算告警、Provider 账单导入和内部成本分摊。账单差异通过追加式纠正和对账证据处理不能为了得到整齐数字而改写历史记录。网关默认不保存 Prompt 和模型响应正文。没有经过网关、也没有可信签名适配器证据的直连调用保持UNOBSERVED估算值、Provider 返回值和外部验证值也要分别标记。模型观测可以为合规 Agent 提供风险信号但 Token 数量本身不能自动授予、撤销或隔离权限。平台连续性不能只看一个进程是否存活/health可以说明服务进程正在响应/ready还需要证明必要依赖和数据库连接已经达到可服务状态。再往上平台需要记录 Agent Pool、受管节点、共享存储依赖、活动租约和运行任务才能解释“服务在线”是否真的意味着任务可以继续。管理平面的多个 Admin Agent 通过数据库中的成员资格、任期、Leader Lease 和 fencing token 协调。Leader 失去租约后新成员可以接管旧 Leader 恢复时过期围栏令牌必须阻止它继续提交。这属于管理平面连续性不等于底层数据库集群已经具备高可用。部署、升级和恢复也要成为受治理流程新的受管节点可以由 Bootstrap Deployment Agent 按受控记录完成部署、激活和回执。升级前需要校验发布包、版本和环境经过审批后逐节点 Drain在安全点切换并保留失败、回滚和恢复证据。平台负责版本、审批、通知、状态和回执客户虚拟机、容器平台或外部 SaaS 的实际操作仍需要对应部署适配器。备份、恢复和支持包也应包含范围、时间、版本与脱敏规则。紧急阻断可以撤销凭据、停止后续交付并隔离受管实例但不能撤回已经复制到平台外的数据也不能天然终止未接入受控执行面的外部进程。因此面向 AI 时代的企业管理也需要增强。一套产品契约三种数据库实现川序以同一产品契约适配 Oracle AI Database、PostgreSQL 和 YashanDB但不会假设三者的方言、索引、图能力、身份模型和安全机制完全相同。适配器分别实现并验证迁移、授权、检索、并发和回归行为产品层则保持一致的身份、知识、执行和审计语义。Community 与 Enterprise 的能力边界在构建期确定不能只靠隐藏菜单模拟版本隔离。在当前版本中 A2A、OTLP 或客户专属连接器等受控、未默认启用的能力也不应在完成真实适配和验证前被描述为开箱即用。db4operations 让前六章不只存在于设计和页面中而是能够在长期运行、异常、升级和成本压力下继续成立。最终章db4agent把七种能力组合成企业运行底座现在可以重新理解db4agentdb4identity决定 Agent 是谁、代表谁并由谁负责db4context决定 Agent 此刻应当获得什么db4knowledge决定信息如何沉淀、检索、共享和演进db4engineering决定长期任务如何执行、恢复和验收db4security决定谁在什么条件下可以做什么db4collaboration决定人和 Agent 如何在边界内共同推进工作db4operations决定平台如何被观测、计量、部署、升级和恢复。七者不是独立功能菜单而是一条连续链路Human / Agent 注册并建立责任链 → 在授权范围内建立 Context → 检索或产生受治理 Knowledge → 通过 Task / Loop / Graph 执行 → 每个边界重新做 Security 决策 → 在 Channel / Gate / Approval 中协作 → 观测运行、Token、成本与平台健康 → 保存结果和 Audit Evidence → 形成下一次可恢复的 Context这条链路的价值在于任何一个 Agent 都不再只是“某台机器上的一个脚本”。它成为有身份、有负责人、有上下文、有知识范围、有任务状态、有成本事实、有协作记录并且可以撤销的企业主体。为什么选择数据库作为共同底座文件和进程内状态仍然适合本地缓存、临时工作目录和轻量原型但企业控制面需要数据库提供的组合能力事务与一致性结构化、全文、向量和图关系查询细粒度授权与行级隔离租约、围栏、幂等与状态机审计、留存与恢复面向组织和责任链的实时关系判断。统一产品能力不意味着抹平数据库差异。三种数据库的实现边界和验证责任由 db4operations 明确业务 Agent 获得的仍是同一套产品语义。结语企业不缺少会调用模型的 Agent真正稀缺的是让这些 Agent 长期有序运行的基础设施。当身份可以追责、上下文可以恢复、知识可以治理、工程过程可以持续、安全边界可以强制、协作责任可以复核、平台运行可以观测和恢复时Agent 才从一次聪明的调用变成企业可以管理的生产资产。这就是从db4identity、db4context、db4knowledge、db4engineering、db4security、db4collaboration、db4operations最终走向db4agent的完整路径。川序基于数据库的 AI Agent 管理平台。