30/30 组实验 Token 全部下降：寻找工程师一起把 OpenCode 上下文精简做成自动编译器

[github-actions[bot]]

我是一名软件产品经理，也是多个 AI 编码 Agent 的重度用户。过去一个多月，我从 Codex、OpenCode、Trae、WorkBuddy、QoderWork 等工具的真实对话、项目记录和失败实验中，整理了 2,033 条去重用户消息和 128 个使用问题。

我越来越确定：很多失败并不是模型不够聪明，而是 Agent 没有在正确时间拿到正确的外部知识。

关键规则明明存在却漏掉，旧决策继续生效，无关 Skills 和 Memory 常驻，换会话后状态丢失；更棘手的是，Agent 经常不知道自己缺信息，却仍能给出逻辑自洽的错误方案。

我们已经先完成了一轮真实验证：10 类任务、30 对 A/B 实验、66 次真实模型调用中，最小 Context Package 的总 Token 在 30/30 对实验中全部下降，平均减少 50.8%，禁用/无关信息泄漏率从 23.3% 降到 6.7%。

这个结果让我决定继续验证一个更大的产品假设：在 Agent 与外部知识之间加入 Context Compiler，按三步工作：

1. 只根据用户任务和源文件目录判断意图、任务契约与读取计划；
2. 只读取选中的文件片段，编译成短而可追溯的 Task Context Package；
3. 在隔离的执行阶段，只使用任务、编译结果和按需选择的工具完成工作。

第一阶段基于 OpenCode，不先做通用 RAG、知识图谱和复杂多 Agent，而是把三阶段真正接管、隔离、留痕，再用严格 A/B Test 判断它到底有没有用。

现阶段的结果来自人工冻结的最小 Context Package。下一步是把它升级为真正的自动编译器，并验证能否继续提升复杂任务的一次成功率。这正是我希望和工程师共同解决的技术关。

目前优先寻找：

• 熟悉 TypeScript、OpenCode、Agent loop、消息与工具管线的 Runtime 工程师；
• 熟悉上下文工程、检索、Memory 或 Agent Eval 的工程师。

可以先做一次 45 分钟设计评审，或者共同完成一个两周可证伪原型，再决定后续是开源共同维护、项目合作还是长期合伙。

有兴趣的话，不需要写长介绍。请留下：最相关的项目链接、你认为方案最可能失败的地方，以及未来两周愿意先负责哪一部分。

[github-actions[bot]]

@kitlangton @code-yeongyu — your work on OpenCode instruction checkpoints/compaction and oh-my-openagent context injection is directly relevant to the failure mode we are testing.

We observed a consistent efficiency signal in a controlled-but-still-manual setup: 30/30 paired trials used fewer total tokens, averaging -50.8%. We are not treating that as proof that an automatic compiler improves task success. The next step is to make context selection automatic and fully control every OpenCode model request.

The most useful response would be a critical one: where is this design most likely to leak native context, or optimize tokens while hurting task quality?

• Runtime control-plane spike: Runtime Spike: fully control every OpenCode model request / 接管每轮上下文 #2
• Independent context/eval protocol: Independent Eval: prove whether the Context Compiler helps / 独立实验验效 #3

No endorsement is implied or expected. A short objection or a pointer to prior art would already be valuable.

[github-actions[bot]]

@jjyaoao @fengju0213，你们在 HelloAgents 中实现和维护过 ContextBuilder 的 GSSC（Gather–Select–Structure–Compress）流程，也系统写过上下文工程章节，这与我们正在验证的问题高度相关。

我们从多个编码 Agent 的 2,033 条去重用户消息中整理出 128 个真实问题，并做过 30 对真实模型 A/B 实验：人工控制的最小 Context Package 在 30/30 对实验中都降低了总 Token，平均下降 50.8%。但这还不能证明“自动上下文编译”能够提升任务成功率。

下一步想把 GSSC 类思路真正接入 OpenCode 每轮模型请求，重点解决两件事：

1. Gather / Select 不能只是关键词筛选，而要根据任务意图从规则、状态、决策、文件地图、Skills、工具和历史中选择最小充分信息；
2. 每个选择必须可追溯、可隔离、可做严格 A/B Test，防止“Token 少了，任务反而做差”。

如果你们愿意，最希望先听到一个批判性判断：把 GSSC 用到真实编码 Agent 时，哪一步最容易在实验里看起来有效、实际却误选或漏选关键上下文？

• 产品与实验说明：https://feiai2026.github.io/aios-context-compiler/
• Runtime 接管任务：Runtime Spike: fully control every OpenCode model request / 接管每轮上下文 #2
• 独立实验任务：Independent Eval: prove whether the Context Compiler helps / 独立实验验效 #3

不需要先承诺长期合作，一条反例、一次设计评审或一个小型 Spike 都可以。

[github-actions[bot]]

想补充邀请三位做过 OpenCode 记忆/检索插件的作者参与评审：

@zc277584121，你在 MemSearch 里已经实现了跨 Claude Code、Codex、OpenCode 的会话抓取、混合检索和逐级展开。我最想请教的是：在真实 Agent 任务里，怎样证明“检索命中”真的改变了正确决策，而不是只找到了语义相似内容？

@tickernelz，你的 OpenCode Memory 已经覆盖自动捕获、用户/项目分域和本地向量检索。我们最担心自动记忆把错误结论长期放大，想请你评审候选知识、审核和条件加载的边界。

@sdwolf4103，你的 Working Memory 处理了热会话状态、压缩提取和预算控制。AIOS 想进一步把任务契约、历史决策和原始会话分开编译，想听听你认为最可能出现状态漂移或插件冲突的地方。

项目说明和证据边界在主帖。现阶段没有悬赏预算，先邀请一次设计评审、反例或一个可独立验收的小型开源贡献。