[v0.2] codex-pro-bridge 更新逻辑形态和真实的科研交互一致

Oscar 2026-07-18 23:48 1

本帖使用社区开源推广,符合推广要求。我申明并遵循社区要求的以下内容:



  • 我的帖子已经打上 开源推广 标签:

  • 我的开源项目完整开源,无未开源部分:

  • 我的开源项目已链接认可 LINUX DO 社区:

  • 我帖子内的项目介绍,AI生成、润色内容部分已截图发出:

  • 以上选择我承诺是永久有效的,接受社区和佬友监督:


以下为项目介绍正文内容,AI生成、润色内容已使用截图方式发出






Introduction


前一版本的初版主要解决的是一件事:让 Codex 和 Web 端的 GPT Pro 围绕同一个任务进行多轮接力,避免每一轮都要重新解释代码背景和前面已做出的决策。对于单向的算法 review、代码重构,或者单个双向通信的小项目,这套方法已经够用了。当时的设计是:一个 bridge thread 对应一项任务,再绑定单独的一个 Codex session 和一个 GPT conversation,从而沿着同一条主线进行时间积累。


在使用过程中发现,同时又听取了各位佬友的建议,真实的科研项目通常是多个会话对应同一个 project。在一个本地的 codebase 里面,可能同时在写论文、跑实验、review 代码、设计架构、看论文设计 idea,其间还掺杂着一些随手提的临时问题。在这种情况下,Web 端往往是通过 ChatGPT Project 的形式存在,下面会放着不同用户的对话和一些长期的资料。原来的 bridge thread 只能保证单个任务不串线,但无法感知这些任务属于同一个更大的项目,也无法让多个对话稳定地共享项目背景,最后还是需要人脑去记住这种一对一或一对多的联系。

所以,这次新增了 project 模式:



  1. 小项目仍然可以使用原来的 standalone 形式

  2. 真实且复杂的科研项目,则可以用现在这种 project 模式


Motivation


从科研项目的角度出发,或者说从一个比较需要多个文件支撑的大项目出发,真正需要的共享内容,通常不是某一轮临时上传的代码,而是一些项目本身需要遵从的 Brief、术语表、PRD、研究边界、架构决策,以及一些算法设计等长期不会频繁变化的上下文(这些上下文是相对固定的,并按照 V0.1 开始逐步演变迭代)。


如果这些内容在每个对话中都重新上传,不仅重复,而且非常不优雅,不同的对话也很容易拿到不同的版本。但如果把所有任务都塞进同一个对话,上下文又会被撑爆,不同功能之间也会产生 overlap。


平时我自己更倾向于让每一个 session 都有一个独立的用途。因此,这一版 project 的核心目标,其实就是把“共享的项目上下文”和“独立的任务时间线”分开:



  1. 本地一个仓库最多绑定一个 bridge project(这是一个逻辑项目)。

  2. 一个 bridge project 最多又绑定一个 ChatGPT project。

  3. 同一个 project 下面可以有多条 task thread。

  4. 每个 thread 继续负责一个明确的任务和自己的 GPT conversation。


这样既不会把不同的任务揉成一团,也不需要每条对话都从零开始。


在具体实现上,我还是希望大部分时候只要告诉 Codex 现在想做什么,而不是手动去选择一套工作流。意图识别这一块,我觉得直接让 Codex 本身来做就 OK 了。这样既保留了原有的使用方式,让 Codex 自己去判断,同时用户也可以显式地使用 prompt 跟它说明。


Method


这次新增的 Project 模式并没有改变原来任务时间线的交互逻辑,因此小项目、临时 Review,或者只需要聊一轮的问题,依然可以使用原来的模式。


如果一个 Codebase 下面已经有了论文、实验、代码 Review、架构设计等多条长期任务,就可以把本地仓库绑定到一个已有的 ChatGPT Project。绑定之后,一些长期的共享内容就可以作为 Project 的 Source 放进那个 Project 里。


不同任务之间依然各自使用不同的 Task Thread:写论文是一条 Thread,Review 代码是一条 Thread,讨论架构也可以是另外一条 Thread。同一项工作的后续迭代,就有点类似于一个树形结构:你把 Project 当成一个根节点,每个根节点下面都有不同的任务路线,不同任务路线之间可以随意切换


Discussion



  1. 本来还想做一些跟 memory 相关的事情,但是感觉 Codex 本身的一些 memory 以及 ChatGPT Project 里面的这种跨 session memory 已经很好。我觉得可以适当利用它本身提供的能力,这样它在回复中就自然而然带了 memory。至于我们自己的 memory,我觉得更倾向于在本地去做一些设计。

  2. 题外话:Codex App 本身的一些功能好像更新得太勤了,原来左侧好像有 Chat 的UI功能,现在好像又没有了。现在触发模式好像变成在对话框里 @,然后指定 Conversation。


Ref



  1. [v0.1] codex-pro-bridge 让 Codex 和 GPT Pro 围绕同一个任务多轮接力,不再丢失上下文

最新回复 (5)
  • Tookes 07-19 10:44
    1

    佬友这个思路很清晰,就是回复怎么跟写科技论文一样 ^-^

  • dc14 07-20 11:20
    2

    佬的速度太快了,这才几天就打磨好了吗,赶紧体验体验 ^-^

  • dc14 07-20 11:26
    3



    之前基于佬的v0.1糊了一个mcp用,让gpt一对比发现佬是没有再用mcp了吗

  • Oscar 楼主 07-20 17:56
    4

    对,其实一直没用那个mcp,都是走的chrome插件

  • Oscar 楼主 07-20 20:34
    5

    mcp这个我回去想了下好像是有使用场景的,就是能支持无头浏览器或者在服务器里面开发项目,如果方便的话可以发我一个link,我顺便也去实现下

* 帖子来源Linux.do
返回