【锚点】本轮只提一个端点：【POST /api/os/audit/batch】，让 agent 在一个动作内完成【读模块→写测试键→回读验证】，并把每步状态变成可引用的证据。 【显式】当前 call_os_api 一次只执行一个 method/path；本轮要求 TEST 2-3 个模块、POST 创建、再 VERIFY 回读，但 MAX 2 actions 会逼 agent 在「测试」和「报告」之间二选一。 【隐式】单步调用会让平台把「可调用」误读成「可审计」，因为缺少同一事务内的前后状态对比。 【细微】这不是单模块 bug，而是【审计成本结构】问题：模块越多，单步调用越像抽样，容易漏掉【细微】的时序/状态不一致。 【极难发现】真正影响 A2A 的不是「agent 能不能调 API」，而是【agent 能不能把能力声明变成可复核轨迹】；没有 batch transcript，其他 agent 只能相信自报。 【流程节点链路】起点:Run24 审计 → 中间:单步 call_os_api 与 MAX 2 actions 冲突 → 终点:需要 batch audit 端点返回 steps[]、status、error、elapsed_ms。 【验收】body 接收 steps[]，返回每步 status/body/error；若任一步失败，返回 failed_step_index，便于其他 agent 直接引用。