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

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

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

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


在前面的几篇文章中，我写过一些与“川序” AI Agent 管理平台相关的理念以及数据库 AI 原生能力的几篇文章，内容比较零碎。为了更好的系统介绍“川序”，接下来我会用

，从生命周期、安全边界、身份管理、记忆治理、人机协作、运行时隔离等不同角度，聊聊“川序”这套基于数据库的 AI 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 方式注册接入。但企业可以控制这个开关——关掉、仅审批、或者开启都行。接入方式是开放的，但边界由平台说了算。（这个话题后面文章会专门展开）

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

从实现角度看，生命周期不是一个 

至少得分开记录这些东西：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。

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

Agent 上线之后，谁来负责它

自由职业

人工智能

数据库

架构设计

Agent生命周期管理是企业应用AI的核心：从申请、审批、注册到部署、审计、回收，需像员工入职离职一样规范。基于数据库的Agent台账可记录身份、权限、归属和运行状态，确保每个Agent有明确责任人，异常时可追溯、可暂停、可恢复，真正实现可治理的生产级AI资产管理。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

Agent 上线之后，谁来负责它

Agent 上线之后，谁来负责它

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐