Agent-in-the-Loop Recording：让录制过程反向借力 Agent 的智能

Agent-in-the-Loop Recording：让录制过程反向借力 Agent 的智能

顺着这个 issue「让录制产物更智能」的方向，补充一个发散的想法。

背景

目前的录制（Trace v2）遵循一条很干净的约定：录制期间不运行任何 LLM，产出的 trace 是纯粹的用户行为客观记录。变量还是常量、每步的真实意图、哪个定位器最稳健，全部留给执行时的 Agent 现场推断。

这保证了简单和可预测，但也把录制时刻最宝贵的东西丢掉了——录制时是意图最明确的时刻：用户就在场、操作上下文最全、真实取值可见。等执行时再推断，这些地面真相已经不在了。

这个方案想做什么

让录制从「被动记录」变成一次「Agent 参与的协作式编译」：录制过程中和录制结束后，bsk 把歧义点主动暴露给调用它的 Agent，由 Agent 结合上下文（必要时转问用户）给出判断——哪些值是变量、这步操作的意图是什么、哪个候选定位器语义最稳、哪个值应该被 redact。

意义在于：变量绑定有了录制时刻的地面真相，选择器在页面还在眼前时就敲定，敏感值当场处理而不是事后补救，最终产出一个更丰富、可静态审计的录制工件。同时坚持一条底线：Agent 只参与创作期，回放保持确定性——智能沉淀为可审计的工件，不成为运行时的依赖。

技术方向（不打破现有调用模式）

关键约束：bsk 永远是被 Agent 调用的 CLI，不能反过来去调 Agent。

好在反向借力并不需要反向调用。Agent 使用 bsk 时本来就阻塞在等待录制结果的调用上，bsk 只需把问题作为这次调用的返回值交还给调用方，Agent 思考后再通过下一次调用作答——调用方向不变，信息流变成了双向：

sequenceDiagram
    participant U as 用户
    participant A as Agent
    participant B as bsk

    A->>B: record_start --assist
    A->>B: record_await（长阻塞）
    U->>B: 在 Agent Window 中操作
    B-->>A: needs_agent + 结构化问题
    Note over A: 思考，必要时转问用户
    A->>B: record_respond（作答）
    A->>B: record_await（继续等待）
    U->>B: 操作完成
    B-->>A: finished + trace + 剩余开放问题
    A->>B: trace_annotate（增强层落盘，raw trace 不可变）
    Note over B: 全程不发起任何对外的主动调用

对 bsk 进程而言依然是零模型、零凭证、零出网；对存量 harness 完全不可见，新能力通过 opt-in 参数和 skill 文件自然分发。

具体的问题类型、增强工件的 schema、问询发生在录制中还是录制后，都有多种合理取舍，留给大家讨论。

Originally posted by @BB-fat in #90