PysolateExplained
打开文档导航
本科生解释查看 Markdown 源文件

Semantic pre-dispatch

一句话

Semantic pre-dispatch 让 Host 在 exact Guest 找到受支持的 read-like candidate 后，重新核对 Plan、参数、身份、policy 和预算，再提前启动一次可丢弃的 physical operation；最终结果仍要等待原 Guest occurrence claim。

先看一个例子

模型已经生成：

config = sources.read("/workspace/config.json")

后面还有几百毫秒的代码正在到达。直接等完整程序再读取会浪费这段时间，但看见函数名就立即执行也不安全：路径可能是动态值，调用可能位于条件分支，当前 Run 也可能根本没有 sources.read 权限。

Semantic pre-dispatch 的做法是让分析器报告事实，让 Host 做最终资格判断。分析器不能按自己的判断发请求。

真实机制

第一步是 exact Guest analysis。Host 把精确 source 和 artifact/profile/import/Plan bindings 交给目标 Guest analyzer。Analyzer 返回 call site、span、canonical arguments、control region、dynamic occurrence 和 effect/barrier 等 body-free facts。Host 严格解码，并重新核对 source 与请求 identity。

第二步是 Host qualification。CanPreissue 或 CanPreissueStreamingPrefix 把 analysis 中的 candidate 与以下对象逐项 join：

  • sealed capability Plan 中真实存在的 spec、handler 和 grant；
  • exact capability 与 canonical arguments；
  • source、call-site 和 occurrence identity；
  • execution profile、imports、freshness、privacy 与 workspace lineage；
  • read-like pre-dispatch policy、discard disposition 与本次 Run 的独立预算。

全部通过后，Host 才构造 opaque QualifiedCall。AST、read_only 标签、schema 或 analyzer 输出本身都不能跳过这一步。

第三步是 physical pre-dispatch。Plan.PreparePreDispatch 验证 registration，PreparedPreDispatch.Call 最多执行一次 handler。结果进入 Run-private staged observation，记录 physical start、finish、outcome 和 identity；它不是 durable cache。

最后，unchanged Guest 的普通 capability call 仍通过 Broker。只有 source 已 seal，而且 capability、arguments、occurrence 和 staged identity 完全匹配，result 才能 one-shot consume：

analysis fact
  → Host qualification
  → one physical attempt
  → staged observation
  → unchanged dynamic call
  → one logical claim

Branch 没走、前面先抛异常、final source 或参数漂移、Run 失败或取消时，ready work 会 orphan/cancel/fail。Claim mismatch 不会自动再发一个 live provider request。

在新的 source-bound pass architecture 中，semantic_pre_dispatch 是 prefix_overlay stage 的 registered pass。Runtime 已提供 RecordSemanticPreDispatchPassOutcomes adapter：它能把 consumed observation 映射为 applied，把 failed/timed-out/cancelled/late/orphaned/fallback 映射为 discarded。该映射有 unit tests，但当前没有 production caller 自动调用；passpipeline 也不执行 handler 或改变 Broker/staged observation 的 owner。

为什么重要

技术上： 系统获得 source generation 与 I/O 的 overlap 机会，却保留原 Python 控制流作为 logical truth。资格、物理调用和逻辑消费各自有独立 owner 与失败状态。

产品和业务上： 对延迟较高、输入不可变且范围明确的读取，Agent 可能更早拿到数据；预测错误只造成有界、可记录的准备浪费，不会让用户程序凭空多执行一次 capability call。

不能推出什么

  • 当前机制不是任意 Python optimizer，也不允许自动提前 write、publish 或 unknown effect。
  • Exact Guest analyzer 提供事实，不持有 provider authority。
  • 受控 fixture 的 overlap 或历史 benchmark 不证明每个 workload 更快。

术语卡

  • Semantic analysis：目标 Guest 对 source 产生的 call-site 与控制流事实。
  • Host qualification：Host 将分析事实与 authority、identity、policy 和预算匹配。
  • QualifiedCall：只有 Host 能构造的 exact pre-dispatch 资格。
  • PreparedPreDispatch：一次性、受 Plan 约束的 physical capability attempt。
  • Staged observation：保存本次 Run 中 physical outcome 与 identity 的私有对象。

继续阅读