用途与实际影响
这项功能怎样使用
为什么需要它
提交以后原文件可能被修改，旧结果也可能误当成新结果；执行进程若已死，还需要明确结束并清掉当次临时输入。
举个实际例子
我把一份公开说明交给模型后先做另一件事；回来只看进展，不想触发清理。需要中止时明确说“停止这一个任务”，工具发出请求并检查进程和显卡释放；未确认时会如实显示仍待清理，不让我误以为可以安全重跑。
最后我会得到什么
拿到任务编号、当前进度、最终回答和完整文件位置。提出取消后还会分别确认程序是否停下、显卡是否释放；没确认就说仍待清理。
正常时
任务使用的是提交时固定的材料，结果文件完整、清理也已确认。
发现问题时
原文件后来变了或任务中断时留出原因，不拿旧回答套新材料。
入口不可用或证据不足时
无法证明进程已结束或材料与任务对应时停下后续执行，不贸然清理或重试。
从哪里开始
在已接入 Toolkit 的 AI 对话中提交明确工作，保留返回的 job_id；随后用同一任务号查状态。
需要准备什么
- 固定的文件与问题
- 期望产物
- 要等待还是后台处理
从开始到拿到结果
- 1
提交一件任务
工具为本次输入与执行建立任务号，并固定外部文件内容。
- 2
回来查或精确取消
只看进度时读状态；需要结果时点名任务号，取消后核对进程和资源是否真的停。
- 3
收取可信结果
交回输出和清理状态；输入后来改变、执行中断或清理未确认时不复用旧结果或盲重跑。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
离线回归通过关键规则与设计选择
submit 异步返回；invoke 也走受管任务，只是调用方等待结果。
要求结构化结果时，工具会指出空答复、JSON 格式错误或缺少指定字段；检查通过仍不证明内容正确，主 AI 继续验收。
未提供文件声明的旧请求仍可捕获执行，但标为未验证，不当成缓存命中依据。
明确需要重跑时 submit --force，不把旧结果包装成一次新执行。
本模块用到的名词
- 输入声明
- 我明确指定文件的摘要与字节数，工具在真正消费前核对。
- 结果缓存
- 只在真实内容和模型等条件相同且允许复用时，返回既有成功结果。
专业定义
可以交出去、只读看进展，也能准确要求停止
解决什么
超期任务会停止建议轮询；只有确认 worker 已死亡才回收，不能因为一段时间没输出就误清活任务。
当前怎样实现
- JobStore保存请求、lease（执行记录）、状态、事件和完整结果。新jobs/inspect不创建目录、不变更计数、不恢复死worker、不清输入，也不启动观察台；列表只含有界元数据，结果需显式请求，损坏单条不会掩盖其他记录。兼容get/job/cleanup_inputs才可能确认死亡并维护状态。
- expected_sha256 与 expected_bytes 必须成对。流式复制时检查原件读取期间变化、摘要、长度和副本回读；Windows 从创建副本起持有 FILE_SHARE_READ 句柄，贯穿实际消费，并验证 canonical containment（规范路径包含关系）。
- 缺声明的引用继续标记captured_unverified/spooled_unverified；带声明却缺平台等价不可变绑定时拒绝。终态清理本次spool与prepared request并留回执；活动取消先保留精确AICLI运行句柄，清理未证时不得销毁恢复所需依据。
- 无外部引用的相同请求默认复用成功结果；workspace / source / media 默认不缓存。execution.cache_key 仅由调用方提供真实内容与派生版本身份，仍绑定已解析 backend（模型后端）、model、route（处理路线）/profile、privacy、reasoning、媒体和输出协议。
- v2 只公开 caller_cache_key_hash，使用 stdlib-json-sort-compact-utf8-v1 规范化；v1 历史仍能按 ID 查询，但不成为新缓存证明。失败和取消不命中。长结果只回短预览与 hash（内容指纹），--full-result 可取完整输出。
- Toolkit._check_output 核对 nonempty_output；请求 JSON 时继续核对 valid_json 与 required_keys。返回这些确定性检查，不证明答案事实正确、内容完整或代码符合用户目标，仍需调用者验收。
- recommended_check_utc和monitor_until_utc给出建议时机，兼容job（任务记录）仍可维护轮询计数；所有计数更新在同一任务锁下重读，不能把较旧状态覆盖成已终止任务。纯只读jobs/inspect不变更这些计数。stale不自动换模型，也不要求永久等待。
- cancel --id使用模型执行前已经写入的不可变aicli.run-control.v1，固定同一已验证AICLI入口和确切run id发送一次run abort。accepted只表示请求送达；完整进程树清理与GPU会话释放后才终止。模型身份产生前的取消保留not_observed_cancelled/null模型，清理通过不等于模型验收通过；旧runner/direct调用继续协作到真实结束，不另建守护服务。
执行流程
- 1
建立任务编号
- 2
认领执行并固定输入
- 3
完成模型/专项处理
- 4
保存结果与回执
- 5
结束后保存清理证据并取回结果；中途取消必须另核对准确执行已经停止。
边界
- 本地任务材料不进入 PUBLIC（公开） Git 或网站。
- 文件锁和校验不代表整个工作区属于该 worker 独占。
失败与恢复
- 输入摘要、长度或路径不对应
- 在 provider 消费和发布结果缓存前失败。
- worker 死亡
- 确认进程身份后结束任务，清掉私有输入并留下清理记录。
真实入口
src/llm_backend_toolkit/jobs.py任务和缓存
src/llm_backend_toolkit/input_integrity.py输入校验
src/llm_backend_toolkit/input_lifecycle.py占用与清理
如何验证
- 370 项回归包含输入变动、并发打开、缓存边界、活 worker 保全与终态清理。
与其他模块的关系
文本、媒体、direct 和 Agent 共用同一结果生命周期。