@auroraflow/code-linux-x64

v0.0.6

Published

9 days ago

Aurora 编程 Agent 是基于 OpenAI Codex CLI 二开的 Aurora 自有编程代理。它的目标是提供类似 Codex 的本地编程体验，但身份、模型目录、API Key 与运行时路由都接入 Aurora 体系。

0High
0Medium
0Low

auroraflow

Aurora 编程 Agent

这个仓库不是一次性改造项目，而是一个需要长期跟随上游 Codex 演进的下游 fork。实现时应尽量保留 Codex 的核心代码结构，把 Aurora 专属逻辑收敛到小而清晰的适配层，降低后续合并上游更新时的冲突成本。

文档语言

本项目的文档系统主要使用中文。

面向产品、架构、运行规则、二开策略、发布流程的文档应优先使用中文。
代码中的协议字段、第三方接口名、命令、错误码、包名和配置键保持其原始英文形式。
引用上游 Codex、OpenAI API、Rust/Node 生态文档时，可以保留英文专有名词，必要时补充中文解释。
面向国际化发布的用户文案可以单独维护英文版本，但中文文档是项目内部事实源。

文档入口

Aurora 专属维护文档位于 aurora-docs/。

aurora-docs/BOUNDARIES.md — 长期二开边界。
aurora-docs/DECISIONS.md — 架构与产品决策记录。
aurora-docs/CHANGES.md — Aurora patch 变更记录。
aurora-docs/UPSTREAM.md — 跟随上游 Codex 的合并流程。
aurora-docs/UPSTREAM_CLEANUP.md — 上游遗留文件与口径的清理矩阵。

上游 Codex 原 README 已保存在 README.codex.md。上游 docs/ 目录尽量保持接近 upstream，避免承载 Aurora 专属产品文档。

项目定位

Aurora 编程 Agent 面向希望使用 Aurora 基础设施完成本地编程工作的开发者：

使用 Aurora 账号体系替换 Codex/OpenAI 登录授权。
使用 Aurora 模型目录替换 Codex 原模型选择器。
使用 Aurora API Key 选择器决定请求进入哪个运行时资源池。
尽量继续继承 Codex 的核心 agent 能力、TUI 工作流、工具调用、MCP、沙箱和执行能力。

首期范围

第一阶段聚焦三个替换面。

1. 身份体系

替换 Codex 原有登录与鉴权存储，改为 Aurora 账号登录。CLI 应通过 Aurora control-plane endpoint 完成认证，并只保存后续 Aurora 请求所需的凭证。

2. 模型选择

替换 Codex 原来的扁平模型选择器，改为 Aurora 两级选择器：

先选择 provider 分类。
再选择该 provider 下的具体模型。
运行时请求发送 Aurora 后端要求的 alias / model id。

3. Aurora Key 选择

新增 Aurora API Key 选择器：

先选择 key 类型：personal、platform、org、market。
再选择或创建具体 key。
持久化已选 key 的必要元数据，供后续运行时请求使用。

上游跟随策略

本项目应持续跟随 openai/codex，把它作为核心 agent 能力的上游来源。

推荐规则：

尽量保留上游 Codex 的文件布局和 crate/module 名称，除非包分发确实需要改名。
避免在核心代码里做大范围品牌替换。
Aurora 专属逻辑放到清晰命名的 adapter / integration 模块。
保持 Aurora patch 小、集中、可 review，便于上游更新后重新合并。
模型目录和 key 选择使用结构化字段，不把 Aurora 元数据塞进展示文本再解析。

长期二开边界

本项目的长期维护基线是：

Codex core + Aurora identity/model/key/runtime adapter + Aurora distribution。

也就是说，本仓库不是“全仓改名版 Codex”，而是在尽量保留 Codex 核心结构的前提下，把 Aurora 必须拥有的产品接入面替换掉。

必须二开的范围

以下范围属于 Aurora 产品边界，应由本项目长期维护。

品牌与分发层
- CLI 命令名：aurora。
- npm / Python / 其他发布包名。
- 安装脚本、平台二进制包、release artifact 命名。
- 面向用户的 Aurora 产品文案。
登录与身份体系
- Aurora 账号登录。
- Aurora session / token 存储。
- Aurora API key reveal / create / select。
- 移除默认 Codex/OpenAI 登录入口；除非明确设定兼容期，不保留旧登录路径并行支持。
Aurora Key 选择
- 先选择 key 类型：personal、platform、org、market。
- 再选择或创建具体 key。
- 持久化运行时请求所需的 key 元数据。
- 客户端只做交互所需判断，资源池和权限判定以 Aurora 后端为准。
Aurora 模型目录与模型选择器
- 使用 Aurora 模型目录接口。
- 模型选择器采用 provider -> model 两级选择。
- 运行时请求发送 Aurora 后端要求的 alias / model id。
- 模型元数据必须是结构化字段，不通过解析展示文本获得业务字段。
Aurora runtime 接入
- 运行时请求走 Aurora endpoint。
- 长期优先使用 POST /v1/responses 作为标准请求入口。
- 鉴权使用已选 Aurora key。
- Codex core 产生的请求语义应通过 Aurora adapter 转换，不在 core 里散落 Aurora 特例。

尽量不动的范围

以下范围主要承接上游 Codex 能力，应尽量保持接近 upstream，只有 Aurora 接入必须触及时才改。

Agent 核心循环
- session / turn orchestration
- context 构建与压缩
- tool call 生命周期
- rollout / resume / history 机制
通用工具与执行能力
- shell / exec / sandbox
- apply_patch
- MCP server / MCP client
- skills / plugins
- file search / file watcher
通用协议模型
- Codex 内部 protocol 基础类型。
- OpenAI Responses / ChatGPT 相关结构在仍被上游 core 使用时不做无意义改名。
- 只在 Aurora 后端契约确实不同的时候新增 adapter 或结构化扩展。
TUI 通用交互
- 聊天主界面。
- 底部输入框。
- 历史、diff、审批、工具展示。
- 只替换登录、模型选择、key 选择等 Aurora 产品面。
上游测试、CI 和构建基础设施
- 除发布包名、安装路径、artifact 命名外，不主动重写 CI 结构。
- 继续使用上游测试习惯和格式化规则。

每次改动的边界判断

每个 PR 或开发任务开始前，先判断改动属于哪一类：

属于 Aurora 账号、模型、key、runtime endpoint、包分发：可以进入 Aurora patch。
属于 agent 推理循环、通用工具、MCP、sandbox、TUI 通用能力：优先保持 upstream；必须修改时先收敛为小 adapter。
属于纯品牌替换但会扩大 diff：默认不做。
属于上游 bug 或通用能力改进：优先评估是否应该以 upstream-compatible 的方式实现，避免 Aurora 私有分叉扩大。

长期目标是让 Aurora patch 面积稳定、可解释、可重放。每次合并上游 Codex 时，应优先解决这些明确边界内的冲突，避免把临时兼容逻辑扩散到 core。

Aurora 接入面

预期依赖的 Aurora 后端接口：

POST /api/v1/auth/login
GET /api/v1/aurora-cli/api-keys
POST /api/v1/aurora-cli/api-keys
POST /api/v1/aurora-cli/api-keys/{id}/reveal
GET /v1/aurora-cli/models

模型目录接口应返回结构化的 provider、model_id、alias 等字段，客户端不应通过解析展示文本获取业务字段。

非目标

不重写 Codex 核心 agent 行为。
Aurora auth 接入后，不保留旧 Codex/OpenAI 登录流程的兼容分支，除非明确需要兼容期。
不为了品牌统一而全仓重命名内部符号，如果这会显著增加上游合并成本。
不在客户端重复实现 Aurora 后端 domain 规则；客户端只保留交互所需的最小判断。

当前状态

当前仓库已经导入最新 Codex main 作为基线。下一步是在不扩大 core diff 的前提下，依次叠加 Aurora 命令入口、身份、模型选择和 key 选择适配层。