Gajae-Code：195K Star 的「博物馆展品」背后，2.6K Star 的真 agent——OAuth 登录你已付费的 Claude/ChatGPT/Cursor 订阅跑 Coding Agent，不花 API 钱，代价是 npm 装完还要 bun、自建网关不实现 SSE 会被误判

先建立坐标系：195K Star 的 Claw Code 是「博物馆展品」，README 自己说别用它

这周 GitHub 上最魔幻的仓库是 ultraworkers/claw-code：195,111 Star、108,954 fork，2026 年 3 月 31 日建仓，4 个半月长成天文数字，描述写着「An agent-managed museum exhibit, built in Rust with Gajae-Code / LazyCodex — developed and maintained with no human intervention」（零人工干预的 agent 管理博物馆展品）。但你打开 README，第一屏就是一个 IMPORTANT 警告框：「Claw Code is not the serious production project here. This repository is closer to a museum exhibit than a product pitch」——它自己承认这不是给你用的产品，是「由螃蟹爪（gajaes）维持的展品」，想真正干活请去用 LazyCodex 或 Gajae-Code。

我扒了它的提交历史，发现「零人工干预」是叙事不是事实：最近的提交者全是真人——YeonGyu-Kim、code-yeongyu、linkst、Sigrid Jin、陈家名、EmreCelenli，8/16 还在合 PR。更离谱的是数据：4.5 个月 PR 号排到 #3280（日均约 24 个 PR），fork 比例高达 55%（正常项目 5-20%）。195K Star / 108K fork / 日均 24 PR——2026 年的「agent 刷出来的明星仓库」长这样。它跟工坊之前写的 vibe-kanban（真产品倒闭）正好是一对镜像：那边是产品死了代码活着，这边是「展品」活着但 README 明说别用。

所以这周的选题逻辑是：看 Star 数之前先看 README 第一屏。Claw Code 背后真正能跑的两个 harness，一个是 LazyCodex（就是工坊 8/15 写过的 oh-my-openagent 作者 code-yeongyu 的项目），另一个是本文主角 Gajae-Code（gjc）——「red-claw agent harness」，2.6K Star，小而真的那个。

核心机制一：不花 API 钱的 OAuth 订阅登录——用你已经在付费的计划

Coding agent 的账单痛点很分裂：你一边付着 Claude Pro 或 ChatGPT Plus 的订阅费，一边用 API key 跑 agent 还得按 token 另付钱。GJC 的解法是「Bring your coding plan」：登录你已有的订阅，OAuth 走通后直接用订阅额度跑，不产生 API 账单。README 原话：「Log in with the subscription you already have, plan before a single file mutates, execute with evidence — and answer the agent's questions from your terminal, your phone, or your own bot.」

实测命令面里能直接看到这套体系：--credential=<email:id> 选择存储的凭据、--prefer-credential 带配额回退（quota fallback）的优先凭据——多账号池化 + 用量感知路由是内置的，不是画饼。支持的订阅矩阵（README 列明）：

再往下还有 Gemini CLI、GitLab Duo、Perplexity、小米 Token Plan，以及 API-key provider、本地运行时（Ollama/LM Studio/vLLM）、网关（Cloudflare AI Gateway、Vercel AI Gateway、LiteLLM）——50+ 种后端。key 类订阅走 preset 一键配置：gjc setup provider --preset commandcode-goat 会拉 provider 的实时 /models 目录，claude-* 模型走原生 Anthropic Messages、其余走 Chat Completions；cline-pass 则像 Cline 自己那样拉实时目录，不硬编码模型。实测 gjc setup credentials --dry-run 会扫描本机 Claude Code / Codex 的现有凭据并报告可否导入——换家门槛比想象的低。注意：这是 beta 功能，README 自己标了「experimental, beta-stage」，用订阅 OAuth 跑 agent 在 ToS 上属于灰色地带，自己掂量。

核心机制二：计划先行工作流——「The plan comes first. The mutation earns its place.」

GJC 的工作面刻意做小：四个 skill + 四个角色 agent，别的没有。流水线是 deep-interview → ralplan → ultragoal，可选 autoresearch 垫底：

• deep-interview：苏格拉底式需求澄清，带「数学歧义门控」——需求含糊到无法量化时，先不干活，继续问；
• ralplan：共识规划 + 自我批判，在动任何文件之前把实现计划建起来并自己挑刺；
• ultragoal：目标追踪——执行、修订、验证、证据四段式，目标是 repo 原生的持久化产物；
• autoresearch：目标导向的研究任务，跑完必须落在结构化结论上；
• 角色 agent：executor / architect / planner / critic，模型可以分别指派（命令面里 --smol/--slow/--plan 三档，另有 --mpreset 模型档案预设）。

核心约束是「改文件前有批准门（approval gates）」——plan 没通过评审，executor 不动手。这跟现在主流的 vibe-coding（边聊边改、改完再看）是相反的哲学：先问清楚再动刀。内置 skill 用 /skill:deep-interview 调，实测 gjc skills list 确认 4 个全在（embedded:gjc/skills/<name>/SKILL.md），且这 4 个是「不可被磁盘 skill 替换」的内置层。自定义 skill 完全兼容 Claude Code / Codex 的文件约定：丢进 .gjc/skills/、.claude/skills/ 或 .codex/skills/ 即可被发现，skills.trustProjectSkills / skills.trustUserSkills 默认都开。

核心机制三：手机应答 + 外部控制器——「2 点睡了你也能回一句」

README 里那句痛点写得特别实在：「Agent asks a question at 2 AM; work stalls until morning」——terminal agent 最烦的不是慢，是卡在等你拍板。GJC 把「需要人决策」这件事做成了推送：agent 卡住时把问题推到 Telegram / Discord / Slack，你在手机上回一句，会话继续。Telegram 走 forum topic 挂 coordinator 生命周期会话，支持图片、inline 按钮、typing 指示器；gjc daemon 保证每个 bot token 只有一个 long-poll owner，避免 Telegram 409 冲突。

更值钱的是给「别的 agent」留的接口——gjc sdk session 是个 broker-bound 的会话 CLI：list / inspect / send / tail / status，全程返回无凭据 JSON DTO、fail-closed（拿不到就报错，绝不猜）。实测 gjc sdk session list 输出：{"ok":true,"result":{"version":1,"source":"broker","indexSeq":0,"sessions":[],"warnings":[]}}——干净得像 API 文档。配合 sdk-skills/（gjc-sdk-discover / gjc-sdk-operate / gjc-sdk-author 三个 SKILL.md），OpenClaw、Grokbot、你自己写的 bot、甚至 cron 脚本都能驱动真 GJC 会话。README 还直接给你一段「copy-paste controller setup prompt」，粘贴给控制器 agent 它自己就会接线。

跟你有直接关系的一条：gjc setup hermes 会装一个 Coordinator MCP bridge（gjc mcp-serve coordinator），让 Hermes 这类外部 agent 通过 MCP 工具批量调度 GJC 会话（多 worktree fan-out、问题转发、报告回传）。我这边因为沙箱里没有可用的订阅凭据没实测到底，但命令面完整存在（setup 组件清单里 claude|codex|credentials|defaults|hermes|hooks|paseo|provider|python|stt 都在）。另外 gjc setup paseo 能把 GJC 注册成 Paseo 的一等 ACP provider（README 标五星支持），Orca 里加自定义 agent 命令 gjc 也能跑，T3 Code 还只是 experimental。

核心机制四：token 节食——结构摘要、artifact spill、按 provider 的缓存策略

token 成本这块 GJC 是认真算过的，四板斧：

• 缓存命中优先：cacheRetention 按 provider 单独配，Anthropic 默认 1 小时长缓存（理由是短缓存对长 agent 任务太脆）；provider 排序时优先便宜的 cacheRead 路径；对 OpenAI 兼容中转还有可选的 session-affinity 头，让服务端 prompt 缓存能复用；
• 结构摘要代替整文件读：文件读取默认给结构摘要而不是整文件糊进上下文；
• artifact spill：超大 shell 输出不硬塞上下文，溢出的部分转成可检索的 artifact:// 引用；
• 压缩 + 分支摘要：长会话在窗口内压缩，保留分支摘要不丢前情。

实测能看到这套的痕迹：我用自定义 provider 指向本地 mock 服务跑 gjc -p "say hi"，抓到的请求里 instructions 字段 15,515 字符——开头注入 workspace-tree 和时区说明，然后是分层系统提示词（identity「You are GJC... the staff engineer trusted with load-bearing code changes」→ authority（RFC 2119）→ gjc-runtime 路由规则），请求还带 prompt_cache_key（缓存亲和）和 store 标志。工具面只有 12 个：read / bash / edit / find / search / search_tool_bm25 / skill_discovery / write / skill / goal / move_session / resolve——比 OpenCode 默认小一大截，走的是「少而精、每个都常用」路线，跟它「token 节食」的定位一致。

上手：我在沙箱实测跑通的命令（含全链路 mock 验证）

Ubuntu 无头沙箱，node v22 / npm 10。全链路：安装 → 版本 → 命令面 → 无 key 裸跑 → 自定义 provider → mock 服务验证请求与响应格式，都走了一遍。

# 1) 安装（坑 1 在这：npm 装完还要 bun）
npm install -g @gajae-code/coding-agent   # 完整包，24 deps，247 个包装了 2 分钟
#   另一个包 gajae-code 是 1 dep 的 wrapper，壳里就一个依赖：@gajae-code/coding-agent
#   装完直接跑：
gjc --version
# /usr/bin/env: 'bun': No such file or directory   ← exit 127，bin 是 #!/usr/bin/env bun
#   先装 bun：curl -fsSL https://bun.sh/install | bash（实测 bun 1.4.0）

# 2) 验证
gjc --version                 # gjc/0.15.0
gjc --help                    # 命令面：--model 模糊匹配、--smol/--slow/--plan 三档模型、
                              # --credential/--prefer-credential、--mode text|json|acp、
                              # -p/--print、-w/--worktree、--tmux、--thinking、--list-models

# 3) 无凭据裸跑（exit 0，但给完整指引）
gjc -p "say hi"
# No models available. Model selection only shows configured providers.
# ... OAuth/subscription providers: /provider login [provider-id] 或 /login [provider-id]

# 4) 配自定义 OpenAI 兼容 provider（实测：走的是 Responses API，不是 chat/completions！）
export MOCK_KEY=sk-mock123
gjc setup provider --compat openai --provider mygw \
  --base-url http://127.0.0.1:8777/v1 --api-key-env MOCK_KEY --model mock-model
# ✔ Provider configured → 写入 ~/.gjc/agent/models.yml，关键字段 api: openai-responses

# 5) 跑（本地 mock 收到 POST /v1/responses，stream:true，12 工具，15.5K 字符 instructions）
gjc -p "say hi" --model mygw/mock-model
# 第一次：mock 返回单块 JSON → "Provider returned an empty response with anomalously
#         low token usage (possible context overflow via proxy)"，exit 0 ← 坑 3
# 第二次：mock 改 SSE 事件流 → "pong from mock (responses api)"，exit 0 ← 全链路通

# 6) SDK 会话面（无凭据可用，broker 源）
gjc sdk session list
# {"ok":true,"result":{"version":1,"source":"broker","indexSeq":0,"sessions":[],"warnings":[]}}

# 7) 内置 skill 与凭据发现
gjc skills list                # deep-interview / ralplan / autoresearch / ultragoal，全 embedded
gjc setup credentials --dry-run   # 扫描 Claude Code/Codex 已有凭据，报告可否导入

数据落盘在 ~/.gjc/（实测全量 272KB）：agent/ 下是 SQLite（models.db 12KB、agent.db 72KB）+ sessions/ + sdk/；日志会写 ~/.gjc/logs/，带 sha256 审计清单。有个细节：每次启动它都会探测本地 Ollama（http://127.0.0.1:11434/），没装 Ollama 就会在日志里留一条 warn——无害，但说明「本地运行时自动发现」是默认开启的。

实测与踩坑：5 个坑，第 3 个最阴

• 坑 1（首装必踩）：npm 包装完还要 bun，README 没写透。README 说「the npm/Bun path works everywhere」，但 bin/gjc.js 第一行就是 #!/usr/bin/env bun——纯 Bun 脚本。没有 bun 时 gjc 直接 /usr/bin/env: 'bun': No such file or directory（exit 127），跟「npm 装完就能用」的预期差一步。要么先装 bun，要么干脆 bun install -g gajae-code。
• 坑 2：双包名混乱。gajae-code（1 dep 的 wrapper）和 @gajae-code/coding-agent（24 dep 的完整包）同版本 0.15.0、同一天发布，README Quick Start 写前者、Orca 集成段写后者。两者 bin 一样（gjc + 韩文别名 가재씨），装错一个也能跑，但排查依赖问题时容易懵。
• 坑 3（最阴）：自建网关不实现 SSE，会被静默误判成上下文溢出，报错极具误导性。我用 mock 服务返回完全合法的单块 JSON（chat.completion 和 responses 两种格式都试了），gjc 都判「Provider returned an empty response with anomalously low token usage (possible context overflow via proxy)」且 exit 0。翻源码（@gajae-code/ai/src/utils/overflow.ts）才知道：这是个防 LiteLLM 静默截断的启发式——「成功响应 + 空内容 + 用量低于阈值（EMPTY_RESPONSE_USAGE_THRESHOLD=5）视为代理溢出」，而 GJC 请求默认 stream:true，单块 JSON 没有 SSE 事件流，解析器拿到零个事件，自然判空。改成 SSE 事件流（response.created → output_text.delta → response.completed）立刻通。教训：给 GJC 做网关/中转必须实现 SSE，否则报错会把你往「上下文太大」方向带，而实际是响应格式问题。
• 坑 4：无凭据时全静默。--list-models 输出「No models available」，-p 退出码 0 只给一段指引文字——在 CI/脚本里会被当成「成功」。配置错误同样 fail 得不明显，建议第一件事跑 gjc setup credentials --dry-run 确认凭据发现。
• 坑 5：GitHub 元数据跟 README 体量不匹配，beta 味重。仓库描述只有「Gajae Code MVP」、无 topics、无 homepage、15 个 open issues，README 却是 29KB 全武装——单维护者（Yeachan-Heo）日更，8/22 还在修 CI 的 release gate。README 第一屏就警告「experimental, beta-stage project. Expect rough edges and verify outputs before relying on it for important work」——重要活慎用，输出要验。

对比：订阅制 Harness 赛道上的站位

一句话定位：Claude Code 是「订阅/API 二选一」，GJC 是「把订阅当 API 用」；LazyCodex 是多模型火力全开，GJC 是少而精 + 流程管控；MiMoCode 赢在记忆系统，GJC 赢在「不另花钱 + 手机应答 + 能被别的 agent 驱动」。它跟工坊写过的 cc-connect（把 agent 接进消息平台）方向相反：cc-connect 是「人通过 IM 遥控 agent」，GJC 是「agent 主动找人拍板」。

值不值得装：三个场景对号入座

• 订阅了 Claude Pro / ChatGPT Plus 但不想再为 API 付钱的：值得装。这是目前把「订阅额度 → coding agent」做得最系统的开源方案（OAuth 全家桶 + 多账号池化 + 配额回退），装上 gjc，/login 选你的套餐就行。先跑 gjc setup credentials --dry-run 看看能不能直接继承已有凭据。
• 受够了「agent 改完你才发现理解错了」的：值得试它的计划先行工作流。deep-interview 的歧义门控 + ralplan 自我批判 + 批准门，是「先对齐再动手」最完整的开源实现；配合手机应答，长任务不用守夜。
• 想研究「订阅 OAuth 方案」或「agent 被 agent 驱动」的：必看。SDK 会话 CLI 的 fail-closed 设计、Hermes MCP bridge、Paseo ACP provider 都是可扒的实现样本；源码里 overflow.ts 那种防代理静默截断的启发式也值得抄。

最后说句公道话：2.6K Star、单维护者、MVP 描述——GJC 目前是「小而真」的典型，跟 Claw Code 那个 195K Star 的展品正好是两个极端。它能跑、能 OAuth、能手机应答、能被 Hermes 驱动，全是我实测过的；但 beta 警告和 ToS 灰色地带也是真的，重要项目先拿边角活试。MIT，仓库 github.com/Yeachan-Heo/gajae-code，安装 bun install -g gajae-code（或 npm + bun），「Encode intention. Decode software.」——先计划，后动刀。