适合本地运行时接入者
当你的本地自动化运行时正在驱动浏览器、编辑器、终端、上传器或其他应用，而你希望灵汐把它视为“正在使用中”而不是普通闲置后台时，这页会更有帮助。
AI 集成实践
本地自动化运行时集成
这页整理了一组通用接入建议，用来在本地自动化运行时仍在主动驱动某个应用时，让灵汐不要把它当成普通闲置应用过早关闭。
补充说明，不是协议正文适用于本地自动化运行时保护正在被使用的应用
什么时候看这页
这是基础接入页旁边的一页实践说明
请先把主 `AI Integration` 页面当作基线。这页适合在你已经理解基础接入流程之后，再进一步处理“本地运行时正在主动使用某个应用”这一类问题。
让基础接入页保持清晰
稳定的 socket 接入说明仍以主 `AI Integration` 页面为准。本页只补充面向自动化运行时的实践建议，避免把某个验证样例误写成长期兼容承诺。
典型症状
这些现象通常说明运行时接入还不够稳
应用启动后很快退出
应用在自动化运行中能被拉起，但还没进入稳定任务阶段就提前退出。
手动使用正常，自动化运行异常
同一个应用和任务，在用户手动操作时正常，只有在本地运行时接管后才出现异常。
长任务中途中断
长时间的导入、同步、上传或应用驱动流程起步正常，但保护状态没有持续到任务完成。
推荐做法
先建立真实应用表面，再进入 lease
- 优先让一个运行时会话拥有一条明确的应用会话。
- 在向灵汐申请 lease 之前，先把真实应用表面拉起来。
- 为目标应用实例选择尽可能具体、且有效的 app key。
- 如果识别缺口只是暂时的，先短暂重试 `lease.begin`，不要立刻调整接入实现。
- 只要真实任务还在进行，就在后台继续续租。
- 收到 close-check 后，要根据运行时是否仍在使用该应用来回应。
- 任务真正完成后，再显式结束 lease。
应用标识
如何理解 `appKey`
- 对很多应用来说，基础 `appKey` 就是 bundle identifier。
- 如果应用带有 profile 或变体区分，可能需要更具体的后缀 key。
- 优先使用最具体、已知有效的 key，只有必要时再回退。
边界
哪些内容保持稳定
- socket 路径、握手流程与 lease 动作，仍以主 `AI Integration` 页面为准。
- 本页补充的是运行时接入建议，不是另一套公开接口。
- 不同应用表面可能需要不同的启动、标识和“任务仍在进行中”的判断方式，但 lease 流程本身不需要变化。
最小实现形状
先保证时序，再考虑封装形式
关键不在语法，而在顺序：先有真实应用表面，再申请 lease，最后显式清理。
resource = launch_or_attach_to_real_app(...)
liveSurface = create_real_surface(resource)
with aion_lease(appKey):
# do the owned app work here
...
示例
已经验证过的具体例子
Playwright + Chrome
一个已经验证过的具体例子，是 Playwright 在 macOS 上驱动 Chrome。在这个场景里，更稳妥的做法是：先创建真实页面，优先使用基于 profile 推导出的 Chrome key，并在浏览器仍持有真实任务时持续续租。
其他应用表面
如果你的运行时驱动的是其他应用表面，请保持公开 lease 流程不变，只替换应用启动、应用标识和“任务仍在进行中”的判断层。
排查
先检查这些，再考虑调整接入实现
`lease.begin` 返回 `unknown_app`
先核对 app key。最稳妥的 key 通常是刚刚拉起的真实应用实例所对应的、最具体且有效的标识，而不是最宽泛的兜底值。
灵汐识别前应用已退出
优先检查顺序：先有真实应用表面，再进入 lease 流程。在很多接入里，这个顺序比后续重试更关键。
长任务中途中断
确认后台续租仍在运行，并且在应用仍被主动使用时，close-check 会把 lease 正确延长。
需要先回到基础接入页？
如果你还需要 socket 路径、握手、动作列表或响应码，请先阅读主 `AI Integration` 页面。等基础接入流程清楚之后，再回到这里处理“运行时怎样安全地持有一个应用”这个问题。