胖头鱼的技术专栏-463 从 db4identity 到 db4agent：为什么企业 Agent 最终需要一个数据库控制面（20260825）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE
10年+数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著 名社恐（社交恐怖分子）
全网同名：胖头鱼的鱼缸
ITPUB：yhw1809
除授权转载并标明出处外，均为“非法”抄袭

在前面几篇文章中，我分篇介绍了“川序”，但是要完整的介绍这个基于数据库的 AI Agent 管理平台，尤其是当前整个产品已经较为复杂了，按照之前的计划，介绍将被拆成接近 20 篇文，如此零碎的介绍确实也不是一个好办法。

因此调整策略，对照目前最新版本  v4.4.10 （2028-08-24）的产品功能、架构设计与技术实现，一篇长文完整介绍“川序”！

https://db4agent.cn

Agent 真正缺少的，可能不是另一个框架

过去几年，我们已经学会了怎样让大模型调用工具、检索知识、拆解任务，甚至让多个 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 属于某个执行组，也不代表它获得了该组关联的所有知识。

在产品界面中，实体关系图因此应优先呈现节点和拓扑，而不是堆叠难以阅读的关系说明。复杂关系的解释来自受控详情和数据库事实，而不是让画布承担全部语义。

知识共享范围应复用组织架构

企业常见的知识范围至少包括：

1. 全公司公开；
2. 某个组织及其下属组织；
3. 某个组织范围内限定层级；
4. 指定 Human 或 Agent 私有。

研发、财务、行政之间的隔离不应在知识页面再创建一套独立通讯录。知识策略应关联企业已有组织结构，并在清单、详情、图投影和检索路径执行同一套数据库授权判断。

这使 db4knowledge 不只是 RAG 数据源，而是带有组织范围、生命周期和来源证据的企业知识层。

第四章：db4engineering，让 Task、Loop 与 Graph 成为持久工程事实

一次模型调用不是一个生产任务

企业任务可能持续几分钟、几小时甚至数天。它可能包含人工审批、多个 Agent、外部系统、副作用操作和失败重试。如果状态只在进程内存或聊天记录中，重启后就无法可靠判断哪些步骤已经完成、哪些结果仍可提交。

db4engineering 首先要求“状态先于执行存在”。平台在执行前写入任务、输入摘要、责任主体、版本和约束，执行过程中更新租约、尝试次数、检查点和证据，最后以数据库中的完成事实结束，而不是仅接受 Agent 自己声称“已完成”。

Task、Loop、Graph 各自解决什么

它们不应成为三个相互竞争的执行系统。

• Task Plan：描述有目标、有步骤、有状态的工作计划，适合明确的任务拆解和进度管理。
• Loop：描述需要反复评估、修正和继续的过程，例如监控、优化、复核和迭代研究。
• Graph：描述带依赖、分支、汇合、检查点和多执行者的复杂流程。

Task 可以进入 Loop，Loop 可以作为 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，把七种能力组合成企业运行底座

现在可以重新理解  db4agent：

• db4identity 决定 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 管理平台。

官网： https://db4agent.cn