🚧 Roadmap — 本页描述的能力尚在路线图中，概念与设计已定型，接口与操作步骤以正式发布为准。
注册和管理你的 Agent
读完本指南，你将知道：
- 一个 Agent 从"有人想建"到"正式退役"要经过哪五个动作
- 每个动作该由谁做、卡在哪一步意味着什么
- 为什么"注册"这一步不能省——它是后面所有治理动作的挂载点
前置条件
- 一个工作空间（Agent 与访问密钥的隔离单元，见 API Reference 的工作空间端点）
- 明确的技术负责人与业务归属人人选（两个角色的分工见 Agent 的身份模型）
- 该 Agent 需要访问的资源清单——用来推导它应该拿到哪些 scope
五个动作
1. 注册：让它先有身份
注册是给 Agent 一个可识别的标识、一份说明、一对责任人。这一步产生的不是权限，只是身份——注册完的 Agent 什么都做不了，这正是设计意图。
注册时要填清楚的四件事：
| 项 | 为什么重要 |
|---|---|
| Agent 标识与用途说明 | 半年后有人问"这是干什么的"，答案要在册 |
| 技术负责人（Owner） | 配置、密钥轮换、故障处置找谁 |
| 业务归属人（Sponsor） | 它为什么存在、算谁的账、要不要续期找谁 |
| 请求的能力范围 | 后续审批的评估对象 |
业务归属人是必填项
技术负责人可能换人、可能是外包，但业务归属人必须始终有人在位。这是"任何时候都能回答'这个 Agent 谁负责'"的制度保证——归属人离职时，归属关系自动转移给其上级，不会出现无主 Agent。
2. 审批：让权限过一道人
注册之后提交能力申请，由审批人评估：这个 Agent 要的范围合理吗？和它的用途匹配吗？有没有超出业务归属人自身的职责边界？
审批通过，Agent 才从"在册"变成"可用"。审批被拒或撤回，它退回待完善状态。
审批的粒度是"能力集合"而不是"单次任务"。单次任务的授权由用户或组织在运行时给（见 Consent 与审批）——两层是叠加关系：运行时能拿到的权限，永远不超过审批批准的边界。
3. 连接资源：告诉它能碰什么
审批后把 Agent 与具体资源关联：哪些 API、哪些数据域、哪些第三方账号类型。这一步决定了后续委托的可选范围。
配置纪律：按最小集合配，不按"将来可能用到"配。扩权可以再申请，收权往往没人记得做。
4. 巡检：定期回头看
Agent 上线之后最容易发生的事是沉默地留存：业务停了、人走了，Agent 还在跑，权限还在生效。巡检要定期回答三个问题：
- 这个 Agent 最近还在用吗？
- 它的权限范围和当前实际用途还匹配吗？
- 业务归属人还在职、还认这笔账吗？
三个问题任一为否，进入退役或收窄流程。舰队级的巡检视角见 企业 Agent 舰队治理。
5. 退役：干净地关掉
退役不是删掉记录，而是让它彻底失效同时留下痕迹：停用凭证、终止在途授权、Agent 状态转为已退役、审计记录保留。
退役后台账里仍能查到这个 Agent 曾经存在、做过什么、谁负责——这是审计要求，也是事后复盘的前提。紧急情况下的即时收权见 吊销与应急处置。
五个动作，谁来做
| 动作 | 主要执行者 | 需要谁配合 |
|---|---|---|
| 注册 | 技术负责人 | 业务归属人确认归属 |
| 审批 | 审批人（安全或业务管理者） | 业务归属人说明用途 |
| 连接资源 | 技术负责人 | 资源owner确认范围 |
| 巡检 | 安全/平台团队 | 业务归属人做续期决策 |
| 退役 | 技术负责人 | 安全团队确认无在途依赖 |
常见问题
注册和审批能合并吗？ 可以合并操作界面，但不建议合并语义。注册回答"这是什么"，审批回答"允许它做什么"——前者是事实登记，后者是风险决策，混在一起会让审批流于形式。
测试用的临时 Agent 也要走全流程吗？ 建议走，但可以为测试工作空间设置更轻的审批策略。真正危险的不是流程重，而是测试 Agent 拿着宽权限跑进了生产环境却不在台账里。
一个 Agent 能同时代表多个用户吗？ 能。Agent 身份是一个，委托是每次一份——同一个 Agent 可以持有多份来自不同用户的委托，彼此隔离，各自到期。这也是为什么审计要同时记录 sub 与 act（见 审计与追责链）。
下一步
- Agent 的身份模型 —— 模板与实例、责任人、状态机的完整模型。
- 企业 Agent 舰队治理 —— 从一个 Agent 到一支舰队。
- 吊销与应急处置 —— 出事时的收权手段。