DevTrends开发者趋势
主题色

yubinbin32-ops /

contextos

我用 Codex 改中型项目时,最消耗上下文的经常不是“写当前函数”,而是三件事: 每轮都要重新理解项目结构 为了定位一个方法,读进来一堆无关文件 模型说完成了,但测试没有证据,后面反复返工 ContextOS 做的事,是把这些重复的上下文消耗从 Codex 的对话里拿出去。 使用方式 从仓库 Releases 下载 macOS App 后,App 会自动完成 MCP 安装和配置,把 ContextOS 注册到 Codex 等客户端里。…

语言JavaScriptDT软件开发DTAgent 能力扩展DTAgent 可观测性DT命令行工具DTMCP 服务DTLinuxDTmacOSDT终端DTCodexDTCursor原始agent-memory原始ai-coding

产品配图

关于

我用 Codex 改中型项目时,最消耗上下文的经常不是“写当前函数”,而是三件事: 每轮都要重新理解项目结构 为了定位一个方法,读进来一堆无关文件 模型说完成了,但测试没有证据,后面反复返工 ContextOS 做的事,是把这些重复的上下文消耗从 Codex 的对话里拿出去。 使用方式 从仓库 Releases 下载 macOS App 后,App 会自动完成 MCP 安装和配置,把 ContextOS 注册到 Codex 等客户端里。 打开 Codex,ContextOS 就已经启用,不需要手动改 mcp.json。 核心流程 1. 项目结构先写入 ContextOS 在图形界面里整理模块、依赖链路、影响路径和检查点。这些内容会保存成 .contextos/graph.json,由 Git 追踪。Codex 不用每轮重新扫描目录,而是读取项目结构和相关任务上下文。 2. Codex 按任务读取上下文 任务开始时,ContextOS 返回紧凑的项目地图、相关 Block、Chain、Plan 和检查点,而不是把整个仓库塞进去。 3. AST 只提供精准定位 ContextOS 给 Codex 的是 path::symbol、函数签名和行号范围,不是完整实现代码。编辑器打开的是具体目标方法,不是整个文件。 4. runcommand 压缩命令输出 命令执行结果会经过 ContextOS 的终端网关,过滤 ANSI、进度条、本地路径和重复日志,只保留结构化诊断信息。 5. 测试回执决定完成状态 完成状态绑定测试执行结果和检查点。源码改过以后,相关检查点会变成 retestrequired,模型不能只靠“我觉得完成了”过关。 对比 | 环节 | 不使用 ContextOS | 使用 ContextOS | 实测结果 | | :--- | :--- | :--- | :--- | | 项目结构理解 | 每轮读目录和文件 | 读取 Git 追踪的项目图 | 不重复扫描 | | 代码定位 | 读取整个源码文件 | path::symbol + 行号 | 单任务上下文降低 99.4% | | 执行链上下文 | 返回多模块实现内容 | 只返回定位信息 | 执行链上下文降低 98.5% | | 命令输出 | 原始终端日志进入上下文 | runcommand 过滤和压缩 | 日志压缩 94.8% | | 完成状态 | 模型自我判断 | 测试回执 + 检查点门禁 | 目标模块召回 100% | 表格里的 99.4%、98.5%、94.8% 来自 npm run benchmark 的可复现实测;标题里的“综合减少 60%”是我长时间任务用下来的体感。 欢迎实际试一下,尤其是已经用 Codex 跑过中大型项目的人。

收录记录

  1. 阮一峰周刊·用户投稿

    2026年9月11日 · 1 次收录

  2. HelloGitHub·用户投稿

    2026年9月15日 · 1 次收录

讨论这个产品