用途
pythia-autopilot 用于开发者希望智能体自主工作、不必逐条批准每次写入的场景。它把重复的逐条审批替换为一次性的“租约”（lease）：开发者阅读一张卡片，卡片列明连接、语句分组、时长和写入预算，批准一次后，在租约有效期内，被覆盖的语句可以直接 apply 和 deploy，无需逐条询问。
该技能强调：租约属于开发者，其限制不由智能体自行扩大。
主要能力
- 一次性授权：用一次范围明确的租约替代大量重复审批。
- 覆盖范围内的写入可直接落地：在租约有效期内，被覆盖的语句通过 pythia apply <file> / pythia deploy <files> 直接执行。
- 全程可追溯：每次写入仍会被快照、记录日志并验证。
- 状态查询：pythia autopilot status 可随时查看租约状态，会话启动状态行也会显示。
- 汇报与撤销：pythia autopilot report 汇报每次写入及其判定结果和撤销命令（先列失败的），随后 pythia autopilot off 关闭。撤销始终允许，且只会收紧权限。
租约不覆盖的内容
- 受保护连接：connections.json 中 "protected": true 或 "env": "prod" 的连接，直接拒绝。
- 破坏性语句：DROP、TRUNCATE、ALTER ... DROP、重命名、SET UNUSED、REVOKE、无 WHERE 的 UPDATE/DELETE——除非卡片写明“DESTRUCTIVE statements INCLUDED”。
- 卡片未命名的分组。
- 存在 lint 错误的文件。
- GRANT ... TO PUBLIC、ANY 权限或授权选项。
- 影响超过 1,000 行的 DML——这些会先展示给开发者。
此外，出现以下情况后租约会暂停：其他对象变为 INVALID，或连续五次写入失败；或超过时限、超出预算、autopilot 被关闭。
使用方式
- 先确定规格（pythia-spec）。自主模式取消的是逐条写入询问，不是规格询问——在租约开始前，一次性批量提出所有待定决策。
- 提出最窄的适用范围：默认使用开发连接；默认分组为 plsql_source、comments；仅当任务涉及表时才使用 structural；仅在被要求时使用 data_dml；仅当开发者明确指定时才使用 destructive；时长和写入次数按任务规模设定。
- 请求租约：pythia autopilot request --groups ... --hours ... --note "<the task>" 会打印卡片和一个 8 位十六进制令牌。通过正规入口请求：pythia_approve 工具，或使用 AskUserQuestion 并原样给出 pythia approve --card <token>，或由开发者自己的终端执行。autopilot on 是开发者的控制台命令，永远不由智能体执行。
- 使用常规技能工作：每次变更前仍要执行 pythia-impact；然后用 pythia apply <file> / pythia deploy <files> 直接落地被覆盖的语句。读取每个结果：
- exit 0——已落地，继续。
- exit 3 且是自身对象的编译错误——在租约范围内向前修复。
- exit 3 且其他对象新变为 INVALID——租约自行暂停。停止并展示给开发者；不要为继续而请求新租约。
- 未被覆盖时：预览会说明原因（! autopilot: not covered — ...）。修复属于你的问题（如 lint 错误），或通过常规审批入口单独请求该语句。绝不要为了绕过破坏性检查而改写语句。
- 结束：pythia autopilot report——汇报每次写入及其判定结果和撤销命令（先列失败的）；然后 pythia autopilot off。
适用场景
- 开发者明确要求“完全自动”“全都做了吧”“不要一步步问”“work autonomously”等自主工作方式。
- 任务范围清晰、需要连续执行多次写入，且开发者愿意一次性授予范围明确的租约。
限制与注意事项
- 受保护连接永不授予租约，每次写入仍需单独批准。
- 破坏性语句默认不在覆盖范围内，除非卡片明确包含。
- 租约暂停意味着需要人工查看，不应自行请求新租约继续。
- 存在 lint 错误的文件不会被自动落地。
- 智能体不能自行开启 autopilot，CLI 在没有控制台的情况下会拒绝。
- 汇报必须列出每一次写入，先列失败的，并附上各自的撤销命令。
- 若开发者希望审查每次变更，应使用常规 pythia-apply 流程，不要请求其未要求的租约。
- 单一变更场景下，一次审批比租约更简单。