无人值守的定时任务 Agent
老陈是财务共享中心的负责人，每天早上八点前要拿到昨日对账结果：支付渠道流水、订单系统、总账，三方核对。团队做了一个对账 Agent，每天凌晨三点自己跑——没有人在场，没有人交办，跑完把差异报告放进老陈的收件箱。老陈用得很顺，直到内审来问了一句：凌晨三点那个账号，是谁授权它看支付流水的？
老陈答不上来。无人值守的老办法就是一个 cron 任务加一个服务账号：密码写在配置文件里，写它的工程师去年已经离职，密码还是那个密码；权限是当年"先跑起来再说"时开的，比实际需要宽得多；出了错没人第一时间认领，审计问"这个账号为什么有权限"，答案是一段口口相传的传说。凌晨三点没有人，可以接受；责任没有人，不能接受。
流程
对账 Agent 走的是自主模式：它以自己的名义行动，不代表任何一个具体的人。注意下图——没有 User 泳道，这正是本场景的定义特征：没有逐次委托人。取而代之的是两道"在场证明"：注册审批时由组织级授权确认（Consent）划定的权限边界，和台账上白纸黑字的责任人。图中跳号与一次委托的完整旅程同体系，本页截取 ①⑤⑥，⑤⑥ 的消息按自主模式适配：
无委托人，但有责任人
委托模式回答"以谁的身份"；自主模式必须回答另一个问题——算谁的账。每个 Agent 注册时必须登记两个责任人：**技术负责人（Owner）**管技术——配置、凭证轮换、升级，凌晨三点出故障找他；**业务归属人（Sponsor）**管归属——这个 Agent 为哪个业务存在、成本与风险记在谁头上。责任人离职时归属自动转移，不再出现"没有主人的服务账号"。详见 Agent 的身份模型。
三个关键时刻
- 授权确认（Consent）——发生在审批时刻：没有逐次委托人，不代表没有人说了算。对账 Agent 注册入台账时，申请的权限边界——只读支付流水与订单数据、只写对账报告——连同用途说明和两位责任人一起提交审批，管理员以组织名义确认。此后每个凌晨三点的运行都框定在这个边界内；要扩边界，就要重新走一次审批。授权从"当年谁开的口子"变成"哪次审批批的边界"。
- 审计记录：每一次凌晨跑批都带 audit_id 落进审计链：谁授权——组织（审批记录可回溯到具体审批人）；以谁身份——Agent 自己（自主模式，不冒用任何人的身份）；做了什么——读了哪些数据源、写了哪份报告。内审再来问，老陈翻记录就行：凌晨三点的每一步，早上八点都查得到。
- 吊销：对账逻辑出错开始写脏数据？技术负责人或管理员可随时吊销授权、停用该 Agent，之后新的令牌申请不再被受理；已签发令牌的失效时效见吊销与应急处置。自主模式的令牌本身就是短时签发、按需领取——停掉源头，尾巴很短。
本场景用到的能力
| 能力 | 在本场景中的作用 | 深入阅读 |
|---|---|---|
| 自主模式 | Agent 以自己的名义行动，令牌主体是 Agent 自身 | 三种访问模式 |
| 一等身份与责任人 | 技术负责人 + 业务归属人强制在册，离职自动接续 | Agent 的身份模型 |
| 组织级授权确认（Consent） | 审批划定边界，代替逐次委托 | Consent 与审批 |
| 审计链 | 无人值守的每一步都可追溯到审批与责任人 | 审计与追责链 |
| 注册与生命周期管理 | 从入册到停用，Agent 全程有档案 | 注册和管理你的 Agent |
下一步
- 场景：企业 Agent 舰队治理——从一个无人值守 Agent，到全公司几十个
- 上手：注册和管理你的 Agent——把责任人与权限边界登记进台账
- 概念：三种访问模式——委托、自主、多跳，主体各是谁