胖头鱼的技术专栏-457 Agent 上线之后，谁来负责它（20260810）

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

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

在前面的几篇文章中，我写过一些与“川序” AI Agent 管理平台相关的理念以及数据库 AI 原生能力的几篇文章，内容比较零碎。为了更好的系统介绍“川序”，接下来我会用 若干期的篇幅，从生命周期、安全边界、身份管理、记忆治理、人机协作、运行时隔离等不同角度，聊聊“川序”这套基于数据库的 AI Agent 管理平台——为什么要做，做的时候在想什么，以及我认为企业级 Agent 该往哪个方向走。

说实话，一个 Agent 能回答问题、能调用工具，拉出来演示一下，效果通常就很唬人了。

但企业真把它丢进生产环境以后，画风就突变——它是谁创建的？属于哪个部门？能读哪些数据？谁能改它？出了异常谁背锅？不用了怎么停掉？

这些问题，跟模型的"回答能力"没半毛钱关系。这是企业资产管理的事。

一、Agent 不是跑起来就完了

个人用 Agent，搞个配置文件、配个 API Key，甚至直接在本机起个进程，基本就够用了。

但企业环境完全不一样。Agent 手里攥着知识、记忆、Skill、工具、任务和各种外部系统的访问权限。它的每一次调用，都可能直接动到业务数据甚至生产系统。说白了，这东西跟一个正式员工差不多——不能让它"来无影去无踪"。

所以 Agent 至少得走完一条完整生命周期：申请 → 审批 → 注册 → 归属 → 配置 → 部署 → 激活 → 运行 → 审计 → 暂停 → 回收 → 复核。

是不是觉得眼熟？对，跟员工入职到离职的流程几乎一模一样（申请→面试→入职→定岗→发工牌→领设备→上岗→打卡→考勤→停职→离职→交接）。

如果系统只记录“它在不在线”，却不记录"为什么存在、谁对它负责、它能干什么"，那企业看到的只是一个进程列表，而不是可治理的生产资产。

二、数据库为什么适合干这件事

Agent 的身份、负责人、权限、当前状态、部署记录、审计证据——这些东西本质上都是结构化事实，而且需要一致性更新。

数据库天生就擅长这个。事务、约束、角色、有效期、历史表、审计记录，一把全揽，放在同一个管理边界里，谁也别想“忘了更新”。

“川序”里，我把平台原生管理 Agent 和业务 Agent 分开。平台初始化时可以直接创建 Platform Admin Agent（使用平台原生 Agent 以外，也支持通过其他 Agent 承载 Admin 这一身份，业务 Agent 同样）；企业版 还能初始化一个受限的 Compliance Admin Agent 用于对平台中的 Agent 进行持续的合规检查。业务 Agent 则由授权人员申请，走职责分离的审批流程，批了之后才创建独立身份和部署记录。

源自于外部 Agent 也可以通过 Skill-first 方式注册接入。但企业可以控制这个开关——关掉、仅审批、或者开启都行。接入方式是开放的，但边界由平台说了算。（这个话题后面文章会专门展开）

三、一条生命周期怎么落到数据库

从实现角度看，生命周期不是一个  status 字段就能搞定的。

至少得分开记录这些东西：Agent Principal 记录“谁在运行”；申请单记录“为什么创建”；能力配置记录“能做什么”；部署目标记录“在哪里运行”；运行实例记录“当前状态”；凭证状态记录“拿什么证明身份”；审计事件记录“发生过什么”。

这些记录通过稳定的内部 ID 关联，而不是靠 Agent 名称或进程名去猜关系。展示名字可以改，但审计记录不能因此找不到原始主体。负责人可以换，但前后的生效时间和批准原因得留着。

创建业务 Agent 的时候，服务端得在一个事务里完成一整套操作：校验申请人权限、校验目标组织、校验数据分类和模板约束、生成审批任务。批了之后才创建独立 Principal 和部署记录。任何一步挂了，不能留下一个“看起来存在、实际没有完整授权"的半成品。

Agent 相关状态的变化还要带版本号——防止多个管理员同时改，后者把前者给覆盖了。

外部 Agent 注册走另一条路。一次性 Enrollment Token 只用于建立初始归属，而且要绑定到申请主体、有效期、使用次数和目标范围。Token 用完即失效，后续调用走 Agent 自己的短期凭证。这样注册工具拿到的 Token 不会变成一个“永 久管理员通行证”。

四、管理页面该展示什么

管理页面不能只显示在线/离线。一个完整的 Agent 详情，至少得让管理员看到这些：负责人、组织、安全域、当前状态、最近心跳、最近 Skill 调用、部署目标、模型配置摘要、权限变更、待处理审批、最近异常。

敏感配置不能直接展示明文。页面显示配置版本、摘要、来源和状态就够了，真正的密钥由加密存储和服务端受控读取流程保护。

列表查询也得由服务端根据当前登录主体过滤——不能先把全量 Agent 拉到浏览器再靠前端“藏”起来。（这不是安全，这是自欺欺人）

五、怎么验证生命周期是不是真能用

当真正开始管理 Agent 的时候，比如使用我做的“川序”，别只测正常路径。选一个真实业务 Agent，验证这么一圈：由普通授权人员申请 → 由不同人员审批 → 生成独立身份 → 限制一个 Skill → 启动一次任务 → 查看审计证据 → 暂停 Agent → 撤销凭证 → 再拿旧凭证试试调不调得通。

然后还得验证异常路径：审批被拒绝时不能生成可用凭证；申请过期后不能继续部署；删除或停用负责人时 Agent 应进入待复核而不是自动甩给某个管理员；同一请求重复提交时不能生出两个 Agent；服务重启时只能回收本节点的本地实例，不能误伤协作节点。

还得模拟进程异常——确认 Agent 状态和未完成任务仍然能从数据库里读出来。这就是“可恢复”的含义：Agent 核心状态能从数据库重建，而不是说数据库集群的故障切换有多快。（这个会在后面的文章里会专门聊）

六、从台账到日常运营

生命周期不是上线时填一次表就完事的。

日常运营中，Agent 的模型、Skill、负责人、数据范围、运行目标都可能变。每一次变化都得搞清楚：是新配置版本？运行时临时变更？还是应急处置？不同类型的变化对应不同审批和回滚规则。

企业可以每月做一轮复核：长期未使用的 Agent、即将过期的凭证、没有负责人的历史 Agent、未完成整改的异常、长期停在审批状态的申请。

这样 Agent 台账才能随业务变化保持可信，而不是上线后变成一份没人管的“死亡名单”。

七、企业需要的不是更多 Agent

说到底，企业需要的不是“再多创建一个 Agent”，而是一份可信的 Agent 台账——以及围绕台账建起来的责任、权限和处置流程。

数量只是起点。更重要的是知道每个 Agent 的数据范围、能力范围和责任主体。

当 Agent 具备明确身份，运行状态能被观察，执行过程可以被审计，异常可以被暂停，核心状态能被恢复——它才真正具备进生产环境的基础。

总结

“川序”想解决的问题是：不是“再创建一个 Agent”，而是让企业能管住已经存在以及即将出现的所有 Agent。

老规矩，知道写了些啥。