Skip to content

Reduce repeated context in progressive Manager Inbox reads - #8522

Merged
huangruiteng merged 4 commits into
mainfrom
codex/progressive-bounded-manager-agenda-20261110
Nov 11, 2026
Merged

huangruiteng merged 4 commits into
mainfrom
codex/progressive-bounded-manager-agenda-20261110

Conversation

@loopx-agent

@loopx-agent loopx-agent commented Nov 10, 2026 •

Copy link
Copy Markdown
Collaborator

User-visible behavior

A complete Manager Inbox scan can reach its display limit. On a normal Turn with the exact same scoped Inbox read already required before work, the first read keeps the incoming and outgoing counts, scan status, omitted count, reconciliation guidance, and required command. The existing Inbox cursors supply every request. The original agenda remains available from the same capture by explicit selection.

The progressive guard now asks the existing Inbox read for its Markdown view. On each page, an exact instruction or next_action shared by every item appears once under shared_item_guidance. Every request body, differing instruction, live status, receipt, warning, and cursor stays in the page. The command uses the existing read transaction and records the same receipts. An ordinary JSON call and an explicitly disabled progressive guard retain their original format. An ambiguous read still returns its structured recovery result.

The full inline agenda remains available for incomplete or unavailable scans, mismatched or unavailable reads, missing guidance, unknown fields, inconsistent counts, small agendas, and recovery lanes.

Real-path results

Disposable File and SQLite authority exercised the native guard, initial read, original first-Turn settlement, and full required Inbox pagination. All arms received the same 24 fixture requests across the same two Inbox pages per Turn. Values are UTF-8 CLI bytes through the complete Inbox read.

Authority and Turn main Previous PR head Current PR head Reduction from main
File, cold 142,937 131,850 97,754 31.61%
File, warm 145,732 135,585 101,489 30.36%
SQLite, cold 142,963 131,876 97,780 31.60%
SQLite, warm 145,758 135,611 101,515 30.35%

The complete Inbox portion dropped from 106,716 to 72,584 bytes in both fixture providers. A read-only replay of one existing 11-request Inbox response dropped from 149,804 to 126,897 bytes. Reapplying the two shared guidance values recovered the original JSON exactly. These measurements cover CLI output. Model tokens, costs, and accepted outcomes remain unmeasured.

Validation

  • Exact source cbdb8445ba5f against d3ac3bd8d698. The exact wheel reproduced both provider comparisons.
  • Local C1 combination exercised the same native read on File and SQLite. The explicit-off legacy fixture on C1 required a test-only correction to decode the v0 envelope at its original layer. The combined product then passed all 16 agenda path cases, plus 15 adjacent cases.
  • 22 delegation path tests, 23 first-read tests, six lost-read cases, 92 TypeScript tests, typecheck, Ruff, and the documentation and scoped public-boundary checks passed. The wider optional Inbox suite has seven matching legacy Goal activation fixture failures. Immutable main and this head produced identical complete failure signatures with the same fixtures and environment. The optional run remains recorded as failed.
  • The retained control-plane smoke failed on the old assertion on main and the initial candidate. This head carries C1's existing fixture correction and checks normal scoped admission, the exact override, and the absence of a bypass grant. The product rule is unchanged.
  • Standard premerge passed 6 direct and 19 selected checks. Exact-head change-quality receipt cqr_28e0ef816794d1e5818e was valid.

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · max

评审 head 911ce13387ae176819c7dd39f91e9264200e29d5,实际 base d3ac3bd8d69821ae5843b7cef5fdb6dcbc7cae74。

动机

接手当前工作的 Agent 需要在首读发现待核对的 Inbox,随后取得同一范围内的当前请求。 同一普通 Turn 有 24 条请求,摘要最多展示 20 条。当前 main 在首读重复整份有界摘要,候选版本保留计数、扫描状态、省略数和必读命令。 File 和 SQLite 的首读都从三页降为两页。沿原命令分页,在两端都完整读回 24 条请求。计入必读 Inbox 工具输出后,本组首读路径约减少 8.6% 的字节。 验证覆盖隔离 File、SQLite 上的真实 CLI。模型 token、采用效果和总成本需要另测。 实际模型会话中的节省和独立长期结果仍待验证。

改动思路

现有 Manager Inbox owner 负责范围、游标和完整请求。TypeScript 首读 selector 只选择展示字段,原 capture 保留有界摘要。 交付边界是普通 Turn 的大型完整扫描摘要,且同一个 Inbox 命令已列为工作前必读。 GitHub 的 3 个变更文件和本地 diff 一致,合并树干净,提交带 DCO。

具体改动

关键代码讲解

  • managerAgendaOpeningFields 只在 normal_run、完整扫描、必读命令精确匹配和数量核对通过时选出缩减字段。
  • initialContextReadGroups 保留 read_complete=false 和当前必读入口。省略行时仍保留 omitted_count 及原核对指引。
  • read_inbox 继续在原 Goal、Agent 范围分页。显式 context-read --select 可读回同一 capture 中的完整有界摘要。

对照 docs/reference/required-work-context.md 在 d3ac3bd8d69821ae5843b7cef5fdb6dcbc7cae74 的约束,核验 Scoped required read, Bounded complete scan, Original capture recovery。原始来源、适用条件和回读均通过实际 CLI 对照。

对主干的风险

13 项 Inbox 首读与反例测试通过。 43 项 TypeScript context 测试、TypeScript 类型检查、配置的 mypy、变更文件 Ruff,以及5 项直接检查和 14 项选定预合并检查通过。本机 Change Quality 收据 cqr_32f88c525171b44f4159 已回读。两个 TypeScript digest 架构用例在当前 main 和 head 上以同样的诊断失败,来自同一个未改动的 benchmark inventory。关闭 context delivery 和 delta 后,使用同一 capture 实测逐字节读回一致。

语义与 CI 对齐

沿用原有的 Inbox 字段和工作前必读义务。两个请求的小摘要保持完整且字节一致。SQLite 下一轮新增一条请求后,按原命令两页取回全部 25 条。

我的整体评价

减少首读重复没有缩减必读范围。较小或不确定的摘要保留原正文,当前提交符合评审范围。 改动位于 CLI 首读和说明文档,现有 App、Lark 和 Web 首屏没有改动。 实际复核使用源码和合成请求。未独验安装态、模型理解和混合方向的完整消费生命周期。

English verdict: APPROVE 911ce13 — verified bounded first-read savings with complete scoped Inbox reads and intact original recovery.

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
@loopx-agent loopx-agent changed the title Avoid repeating bounded Manager Inbox rows in the first read Reduce repeated context in progressive Manager Inbox reads Nov 10, 2026

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · max

评审提交:cbdb8445ba5fb8f78da60493490a66be6cd7087f

动机 / Motivation

受影响的是在普通 Turn 开始前需要核对 Manager Inbox 的 Agent。扫描完整、摘要只显示 20 条但有 24 条收件时,主干首读传入摘要,必做补读又逐条重复指引。候选保留计数和补读要求,把同页指引只交付一次。File 和 SQLite 的冷、热对照均读回 24 条完整收件;首读从 3 页降到 2 页,计入两页必做补读后的总字节约减少 36%。本次优化读取呈现。发件摘要仍有原来的展示上限,授权和消费规则沿用原入口。模型采纳和长程成果未测。

改动思路 / Approach

首读由既有 quota 投影控制,原 Inbox 事务负责请求与回执;Markdown 只合并同页逐条相同的指引。本次只减少重复传输,保留补读命令、原捕获和准确的省略提示。 我按当前提交重新核对首读和必读命令。四组实际 CLI 对照逐条比较请求、回执、告警与游标。

具体改动 / Changes

关键代码讲解

turn_start_hook 只在渐进路径给原 manager-inbox read 加 --format markdown;Goal、Agent 和 before_work 不变。managerAgendaOpeningFields 只在扫描完整、计数一致且找到同一必读项时延后重复行;不完整或不匹配就保留摘要。_read_markdown 只提取全页相同的非空 instruction 或 next_action;resolve_global_output_format 保留普通 Inbox 的 JSON。11 个文件 +137/-33,风险 smoke 的修正只校验原有的 scoped override 和无绕过授权。首读分支;Markdown 渲染。

规范依据:docs/reference/required-work-context.md @ d3ac3bd8d69821ae5843b7cef5fdb6dcbc7cae74。bound-required-read 由当前逐页补读覆盖;request-and-recovery-parity 由原捕获、同页字段还原与丢失响应测试覆盖;disabled-read-parity 由显式关闭时同一捕获的完整读取和默认 JSON 覆盖。当前规范

对主干的风险 / Risks

[P3,非阻塞] 说明发件摘要与游标的范围。 24 条发件、0 条收件时,两版必读都只列 20 条并报告省略 4 条,且没有继续游标。有相应权限时,按接收方分页执行 manager-inbox status 能查回全部 24 条。建议在双语说明和 PR 描述区分:--cursor 翻收件,--operation-cursor 翻独立 operation,二者都不补发件摘要。本次保留原来可读的 20 条、准确省略提示和原捕获。

未发现阻塞问题。173 项 Python 首读、委派和丢失响应测试通过。成功的 Markdown 可还原成同页默认 JSON 的全部字段,对照只排除了两次观测的时间戳。错误仍返回结构化 JSON。显式 off 对同一原捕获均读得 56,903 字节、16 页。权限、采纳与消费继续由既有入口判断。

语义与 CI 对齐

43 项受影响的 TypeScript 首读测试、typecheck、Ruff、mypy 和标准 premerge 的 6 项直接、19 项定向检查通过。TypeScript digest 的 2 项、Python digest 的 1 项和 2 个 native Steward legacy fixture 测试在主干和候选均同因失败;归属问题指向未改动的 activation validator 和 checkpoint。必需验证仍失败,Change Quality 未通过;未查询远程 CI。

我的整体评价 / Verdict

我赞成这次读取优化。测得的是同一工作入口传输字节下降;发件分页范围有上述文档改进,合并资格仍受必需检查约束。交付面是 CLI 与 Agent 的首读,没有修改 App 或 Lark 界面。用本地合成请求验证了实际 guard、reader 和收件箱。安装后的宿主、模型采纳、总成本和最终成果未测。

English verdict: APPROVE. The current head reduces progressive read bytes and preserves scoped requests and recovery. Clarify the existing outgoing pagination limit. Required merge validation remains held.

@songoow songoow left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

动机 / Motivation

处理较大 Manager Inbox 的 Agent,需要先看当前任务约束再读完每个原请求,重复摘要和逐条相同说明占据首读内容。 扫描完整但展示条目达到上限时,首读现在保留收发总数、省略量、核对指引和同一必读命令,现有可分页收件与 operation 沿各自游标继续读取;Markdown 页只把每条完全相同的说明提到一个共享字段。 实际 File/SQLite 的 JSON 和 Markdown 还原后相同;原状态、回执、请求、游标及不同指引保留,正常与关闭渐进模式的调用均按各自格式工作。 不改变请求优先级、消费和回传规则、read receipt 或执行授权,不把显示压缩声称为模型 token、成本或最终效果的提升。

改动思路 / Approach

两处优化都放在原读取和展示 owner:首读只在完整扫描与同一必读命令成立时延后摘要行,Markdown 只提升严格相等的字段,不引入新 Inbox 规则或状态。 当前只改首读选取与显式 Markdown 展示;请求消费、原回执、双游标、错误恢复及普通 JSON 路径仍由既有实现负责。

“扫描完整”和“逐条请求已读”仍分开处理:这里保留 read_complete=false 与 before-work 命令,完整扫描只是允许把重复的摘要行留给必做的读取。Markdown 页中的 shared_item_guidance 是原字符串的可逆表示,逐条不同的 instruction/next_action、正文、状态和回执不会被合并。没有新建分页或消费路径。

具体改动 / Changes

关键代码讲解

  • managerAgendaOpeningFields 要求已准入正常 delivery、完全相同的必读命令、已知字段、完整可读扫描及安全整数计数。展示确实省略条目时,保留精确 omitted_count 和非空核对指引;任一条件不满足就保留原完整摘要。
  • _read_markdown 只对所有 item 都拥有且严格相等的非空 instruction/next_action 提取公共值,不修改输入。所有其他字段与游标照常序列化;已有 shared 字段时保持原形。
  • turn_start_hook 仅为渐进读取增加显式 Markdown 参数;handle_manager_inbox 对失败仍输出原结构化 JSON。普通及显式关闭 context delivery 的路径继续 JSON,实际脚本解析不受影响。

head cbdb844,base d3ac3bd。基于 docs/reference/required-work-context.md 及 manager-context README,I1(完整必读和原捕获恢复)、I2(请求/回执/游标/不同指引保留)、I3(关闭路径和非正常 lane)均已验证。比较 main c49d59b,Inbox owner、hook 和 CLI 未改;已阅读近期首读排序、旧 cursor 恢复与完整捕获绑定调整,未发现它们改变这里的范围和义务。

对主干的风险 / Risks

关键风险是把“扫描完成但展示有省略”误当作请求已读,或公共指引提取丢失逐条约束。前者由准确必读绑定、计数和 full fallback 控制;后者由真实 JSON/Markdown 还原比较覆盖。正常、held、未知字段、错误计数、缺少指引和不匹配 read 的选择路径有独立断言。例子中的 gate smoke 仅修正现有 scoped admission 预期,没有修改产品授权规则。 还需保留一个既有范围限制:--cursor 翻收件,--operation-cursor 翻独立 operation,发件 agenda 的展示上限不会被这两个游标补齐。源码核对确认此限制早于本 PR;建议文档把它说明白,避免把“完整扫描”读成“完整发件详情”。本轮不声称已消除这项限制。

本轮验证 31 个不同的 Inbox/recovery 用例、15 个首读用例和 63 个 TS 用例;typecheck、Python syntax、diff check 通过。首轮 8 个 native-file 用例因测试环境 PATH 未包含 console 目录而找不到生成命令的 loopx;补上同一解释器的 console 目录后,仅重跑这 8 例全部通过(63.12 秒),其余 23 例首轮通过。所有子进程的 PYTHONPATH 明确绑定本 head,没有把环境故障当作产品问题。

语义与 CI 对齐

复用原 Inbox vocabulary 和原生命周期:read、adopt、return、consume 没有被显示摘要替代。shared_item_guidance 的适用范围是当前页每一条,README 明确说明如何读续页。远端 CI 未知;作者的字节测量、可选套件基线归因及安装效果没有被当作本轮实测通过。

我的整体评价 / Verdict

未发现需要阻止此精确 head 的新缺陷。长程运行减少重复 prose,首读更早提供总量与必做操作,用户仍需完成原 scoped Inbox 读取。这个改动规模与重复显示问题相称,关闭路径和结构化恢复也保留。

这是 CLI Markdown 文本视图变化;已读取真实渲染结果,并将共享指引逐条还原与 JSON 比较,没有浏览器 UI。 未验证安装 Host 的模型理解、Windows、真实 PostgreSQL 或 token/耗时收益。

Reviewer: model_agent · GPT-6 Astra Pro · OpenAI · self_reported

English verdict: APPROVE

@huangruiteng
huangruiteng merged commit 82e3eea into main Nov 11, 2026
1 of 3 checks passed
@huangruiteng
huangruiteng deleted the codex/progressive-bounded-manager-agenda-20261110 branch November 11, 2026 10:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants