Repository navigation
Reduce optional quota context RPC payloads - #8413
loopx-agent wants to merge 1 commit into
Conversation
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · max
Request changes conclusion (author-owned PR; GitHub blocks formal self-review)
[P2] 拒绝压缩来源中的尾随字节。 候选在合法流后追加含相反 Stop 的第二个 zlib 流或普通字节,两个真实 RPC 都返回成功。校验所得绑定摘要等于只传第一条来源。 decodeTurnSource
动机 / Motivation
使用 Codex App 继续已有 Goal 的人,在每次唤醒时都依赖 LoopX 先读当前任务、权限和停止条件。
基线在可选记忆检查中来回传整份决策。一个约 53 KiB 的合成约束就会在同一轮重复传输。候选缩小了这部分流量,仍用完整来源校验能否附加记忆。
正常路径下,File 和 SQLite 的整轮 socket 流量都约少 32%,改写 Stop 后两边均拒绝使用旧贡献。候选的压缩读取仍会接受附加内容的畸形请求。 本轮只评审本机 RPC 和原 guard;C1 的调用方切换、已安装态以及模型采用效果由现有 #8266 继续验收。
改动思路 / Approach
记忆开关只需要 capability 标志。Python 请求仍携带原始决策,TypeScript 通过现有 projection 决定能力,回包只返回 Goal、Agent 和能力。完整来源进入贡献校验,最终仍由原 action signature 检查 Stop。只缩小 gate 的回包能省掉一部分流量。贡献验证仍需绑定完整决策,直接删去 Stop 等字段会失去原校验。
能力标志是完整 quota 决策的派生读。可选记忆可以少读回内容,但接收端必须先确认压缩请求恰好包含一个完整来源。 保持两个入口共用 Turn 解码与原有绑定校验,把修复限制在压缩帧的完整消费检查。
具体改动 / Changes
评审提交为 014d01571f1e256706a66163215fb636d12e8fff。以 main 的 71190b6b4ef4e146f3bf4a10d31ce61ac42fd021 固定比较基线,本地与远端 6 个路径的改动一致。采用基线的 docs/architecture/rfcs/controller-executor-unified-contract-v0.md。 基线规范
C1-one-bound-action已验证合法 inline 与 packed 绑定一致,替换 Stop 后拒绝旧贡献。C1-explicit-off已验证无记忆配置时仍无贡献,每轮只有一份原回执。C1-single-valid-source未通过。共享解码接受串接流和尾随字节。C1-caller-cutover留给 #8266,按原 quota baseline 验证调用方替换与长期成本。
关键代码讲解
pack_turn_source按同一 JSON 编码计算收益,在 16 KiB 到 1 MiB 的原始输入范围内只在确实更小时压缩。源码evaluateTurnEnvelope仍用现有 quota action projection 检查输入,只返回可选能力所需的字段。源码decodeTurnSource共用 Base64、膨胀上限和 UTF-8/JSON 检查。它接受首条合法流后,漏掉了后续输入。源码validateTurnContextContribution解码后复用原绑定,readback-only 会拒绝来源。带有原 Stop 的合法贡献可读回,改变 Stop 后被拒。源码
对主干的风险 / Risks
向本机任一新增 packed source 消费入口送入一条合法 zlib 流,后接第二条流或任意字节,再将整个输入编码成合法 base64。 基线两个入口都拒绝两种 packed-only 畸形输入;正常 inline 接受。 候选在合法流后追加含相反 Stop 的第二个 zlib 流或普通字节,两个真实 RPC 都返回成功。校验所得绑定摘要等于只传第一条来源。 同机 Node 24.21.0 对一条 27 字节流消费 27 字节,拼接后输入为 53 或 31 字节时仍只消费 27。用 inflateSync 的 info 返回值核对已消费字节是可行的局部修复。在共享解码处校验 inflater 已消费整个压缩缓冲区;保留体积上限和既有 inline 路径。 在 turn_capability_context.test.ts 用两个实际入口分别验证合法单流、串流和尾部字节,并在 Node Effect RPC 重跑相同四组坏帧。
合成 memory 启用且 progressive off,File 总帧字节 490,963 → 335,049,SQLite 489,099 → 333,151。调用数各保持 81/78,原回执各 1。 记忆未配置,File/SQLite 皆 75 次 RPC,socket 分别 248,356 / 248,600 字节,两端相同;没有贡献。合成 SQLite CLI JSON 相差 2 字节,未把原始文本长度当作语义相等。 这是等输入的合成 wire 读数。独立运行的 Node 聚焦集为 85/86 通过,Python 为两端各 107 通过。快速预合并 6 项直接检查与 3 项所选检查通过,真实 socket 尾部反例仍失败。CI 未查询。
语义与 CI 对齐
压缩标签复用 Todo frontier 的编码名;此次只为本机 Turn 请求限定 1 MiB 的封装,旧 inline 仍进入同一个来源校验。能力资格、Stop、回执与 Agent 指令沿用既有语义。
我的整体评价 / Verdict
单轮能力门的既有调用、输出贡献与 Stop 拒绝保持。故障帧不再明确拒绝,这会让重试端误认提交的完整来源已校验。 现有 File/SQLite 调用方的正常步骤与所需人工操作相同。只有源代码模式的真实本机 CLI/RPC 和合成记忆已独立运行。样本未证实延迟下降、真实记忆采用、安装态或单会话长期净收益。 修复后应对这两个入口复跑合法单流及两种尾部反例。
English verdict: REQUEST_CHANGES at 014d015. Both local RPC paths accept trailing data after a valid zlib source.
| } | ||
| let source: unknown; | ||
| try { | ||
| const decoded = inflateSync(Buffer.from(data, "base64"), {maxOutputLength: maxSourceBytes}); |
There was a problem hiding this comment.
[P2] 候选在合法流后追加含相反 Stop 的第二个 zlib 流或普通字节,两个真实 RPC 都返回成功。校验所得绑定摘要等于只传第一条来源。 inflateSync 只读取首条 zlib 流,两个调用方都把它当作完整来源。在共享解码处校验 inflater 已消费整个压缩缓冲区;保留体积上限和既有 inline 路径。 在 turn_capability_context.test.ts 用两个实际入口分别验证合法单流、串流和尾部字节,并在 Node Effect RPC 重跑相同四组坏帧。
Goal And Delivered Outcome
mainat71190b6b4ef4e146f3bf4a10d31ce61ac42fd021. Related to C1: unify work sources and validate recovery #8266.Author Declaration
Scope And Continuation
The five runtime files and one focused test apply directly to main, independently of #8266 and #8396. The scope is local RPC framing. Revert this commit to restore the previous framing. After mainline adoption, reconcile #8266 to the shared codec and keep its remaining caller cutover and real single-session outcome qualification open.
Validation
014d01571f1e256706a66163215fb636d12e8fffagainst71190b6b4ef4e146f3bf4a10d31ce61ac42fd021.finished. Input classessynthetic,public_fixture.staticpassedunitpassedreal_entrypointpassedreal_backendpassedregression_paritypassedintegrationpassedmanualpassedintegrationpassedThe measurement sums request and reply frames across the CLI guard. Three alternating uninstrumented timing pairs used equal-length fixture paths. Wall times were mixed. For File with progressive delivery off, first-guard medians were 434.3 → 458.4 ms, and the three pair deltas ranged from +6.7 to +26.4 ms. SQLite's first-guard results varied by mode. Model tokens, live adoption and long-horizon net benefit remain to qualify. The paired wire and timing harness is local synthetic evidence. The focused tests and budget smoke are available in the repository.
Frontend / Visual Evidence
none. This changes the local transport used by the existing guard.Type Of Change
LoopX Area
Shared-authority RFC Fixture Impact
N/A. The File and SQLite storage code, provider routing and authority schemas are unchanged.
Boundary Checklist