换掉一个 Agent,旧权限和待审提案该怎样交接?

分别处理运行入口、访问凭据、未决变更与正式记录,让接任者从可确认的版本开始。

Busabase Team
← 返回博客
换掉一个 Agent,旧权限和待审提案该怎样交接?

团队开始用Agent做事时,通常先关心它能不能完成任务。等到需要换一位Agent、换服务商,或者结束一次试用,才会发现另一个问题:工作可以交给新的执行者,旧执行者的访问权和没做完的事却不会因此自动交接。

旧Agent可能还有定时运行的任务,也可能留下等待审核的修改提案。换掉连接里的密钥,只处理了其中一种访问方式;新Agent拿到了知识库,也不代表它知道哪些工作已经完成、哪些提案还没有决定。

Busabase让正式记录、变更提案和提交历史分别可查,因此交接不必靠转发一段旧聊天。需要逐项确认的是:旧入口是否停用,新凭据能做什么,待审提案由谁处理,以及接任者应从哪些正式记录继续。把这些交代清楚,才能保留已有工作,又避免两位执行者重复修改同一份数据。

交接的不只是连接地址

换用另一位Agent或外包服务时,知识库可以继续保留;真正需要拆开的是旧执行者还能做什么、哪些提案等待决定,以及新执行者从哪个版本接手。

把交接分成四条线:运行入口、访问凭据、ChangeRequest、正式记录。停止定时任务解决后续触发;撤销凭据解决该凭据的访问;处理提案解决尚未进入正式数据的改动;保留记录和历史解决业务连续性。它们没有一个动作能代替全部其他动作。

四条生命周期

先盘点任务与身份,再切换运行入口

列出旧Agent使用的调度器、脚本部署、MCP连接及人工调用入口,同时记录账号、密钥名称或安全前缀、权限级别和到期日。不要复制完整密钥到交接表。每个入口写明谁有权停用以及哪里可以看到执行状态。

先让负责人处理旧入口的后续触发,再检查正在运行或已经交给外部系统的动作。暂停调度和取消已接受的外部任务有不同接口,按实际系统处理。Busabase中的Base或Skill不会替外部调度器自动停止运行。

凭据属于账号,空间头只是指定目标

API Keys文档说明,一个key属于账号,可以用于该账号加入的多个工作空间;请求中的x-busabase-space选择目标空间。有效权限由key级别与账号在该空间的角色共同限制。因此,给请求加一个空间头,并没有把这把key限制成只能访问那一个空间。

为接任Agent创建独立key,选择能完成工作的最低级别并设置有效期。read用于读取;changeRequest允许读和提案但不能合并;write可审核合并;manage还含管理及永久节点删除。需要人工批准知识库写入时,通常从changeRequest开始,保留真人决策路径。

旧key由有权管理账号密钥的负责人在Account → API Keys处理。删除后立即失效且不可撤销,所有共用它的调用方都会失去访问,所以必须先知道它是否被共享。MCP/OAuth连接按对应提供方的授权管理方式处理,不把删除某个API key说成撤销全部连接。

新 Agent 从最低够用权限开始

待审提案逐项决定,历史作者继续保留

先列出旧Agent提交但尚未合并的ChangeRequest,逐项看目标记录、改动字段、依据和当前状态。仍然有效的提案保留给获授权的审阅者判断;已不适用的提案由负责人按产品支持的拒绝或关闭操作处理。不要为了换Agent把全部提案都批准。

也不要假设凭据撤销会清空待审队列。它控制未来使用该凭据的请求,提案已有自己的生命周期。接任者应读正式记录和相关提案,识别哪些需求仍未完成,再决定是否需要补充或重新提出变更。需要新提案时链接原提案并解释差异,避免两个提案重复修改同一目标。原始作者和提交历史仍应可追踪,不把它们改写成新Agent的功劳。

给接任者一份可执行的交接记录

可以在现有任务Base中增加一条交接记录:标题、旧新执行身份、入口清单、凭据安全标识、待审提案链接、关联业务记录、负责人、未完成动作和验证结果。用Doc保留访问范围与审批规则,用Skill保存接任者要遵循的重复步骤;具体字段按已有schema调整。

给新Agent的第一条指令可以是:“只读指定业务记录、交接Doc和列出的待审提案。报告当前版本、未完成工作及可能重复的改动。先不要接管外部发送,也不要批准旧提案;需要修改时先展示差异,再按当前权限提出变更。”

这能把接任从一句‘继续干’变成有边界的工作。已有个人Agent数据库可以保留业务上下文;接任者仍须重新读取正式版本,而不是把旧聊天中的值当成当前事实。

旧提案不等于新任务

分别验收旧入口、新能力和提案队列

授权负责人通过提供方支持的状态或低风险测试确认旧key失效,不以真实发送、付款或删除测试权限。再验证新key能否读取指定资源,以及能否按预期提出而非自行合并改动。记录实际结果,不将计划写成测试成功。

最后核对待审提案的处置、未完成任务的接手人及正式记录仍可读取。撤权不会回滚已经合并的业务记录;如果发现旧执行者写入了错误数据,走独立的纠正流程。若多位执行者会短暂并存,参照并发更新的版本核对,避免交接时覆盖彼此的有效更新。

四条线都有明确负责人、确认结果和剩余项,才算完成交接。接任Agent拿到的是受控访问和可追溯的工作,而不是旧凭据与一堆无法判断是否已执行的指令。