@zhiman_innies/innies-codex-win32-x64

v0.122.65-win32-x64

Published

5 days ago

0High
0Medium
0Low

mcgrapeng

速览

[!NOTE] 把官方 Codex CLI 的"大脑"换成知满自研模型 qwen35_35b，骨架（Agent 编排、TUI、MCP、沙箱、SDK）原样保留。

| 维度 | 内容 | | :--- | :--- | | 为什么换 | 数据不出境 · 无需 ChatGPT 账号 · 可私有化部署到客户机房 · 与原版 Codex 配置完全隔离 | | 核心取舍 | qwen35_35b 综合推理弱于 GPT-5 · 不支持并行工具调用 · 长链路重构需更多人工拆解 | | 谁该用 | 合规优先、内网部署、可接受"能力换主权"的团队 | | 谁不该用 | 追求最强模型能力、复杂长链路推理、不要求数据驻留的场景——请继续用官方 Codex / Claude Code |

安装

npm install -g @zhiman_innies/innies-codex@latest
innies --version

要求：Node.js ≥ 16 · macOS 12+ / Windows 10/11（Linux 不支持，启动时编译期强制退出）
源码构建参见 docs/install.md。

First-Run Setup (重要 · N20)

[!WARNING] 首次跑 innies 之前,必须先配置 base_url 和 api key,否则会立即报:
ERROR: Missing environment variable: ZHIMAN_BASE_URL (or [model_providers.zhiman_35b].base_url)
这是 N20 fresh-install 阻断 — 因为模板里 base_url 是注释占位符,而 Rust provider resolver 会在 env_key 缺失时静默回退到 api.openai.com/v1(见 docs/n20-fresh-install-base-url-fail.md)。

三种配置方式任选其一(优先级从高到低):

1. 环境变量 (推荐用于 CI / 无交互场景)

# 私有部署 (zhiman_35b / zhiman_27b 共享 ZHIMAN_API_KEY,见模板注释)
export ZHIMAN_API_KEY="sk-..."
export ZHIMAN_BASE_URL="http://your-private-deployment/v1"  # 可选,覆盖 config.toml

# 阿里云 dashscope 公网
export DASHSCOPE_API_KEY="sk-..."
export DASHSCOPE_BASE_URL="https://dashscope.aliyuncs.com/compatible-mode/v1"  # 可选

export 到 ~/.zshrc 或 ~/.bashrc 后 source 一下即持久化。

2. 编辑 `~/.inniescoder/config.toml`

# 第一次跑会自动创建 config.toml
innies 2>&1 | head -5   # 看到 [innies-onboarding] 横幅后 Ctrl+C 中断
# 然后编辑 ~/.inniescoder/config.toml,取消下面这种行的 # 号:
#   # base_url = "http://your-private-deployment/v1"   # FILL IN: ...
#   # env_key  = "ZHIMAN_API_KEY"                      # FILL IN: ...
# 取消注释 + 填值后保存。env_key 是"环境变量名"(不是 key 本身),然后确保那个
# env var 已经在你的 shell 里 export 过(或写在 rc 文件里)。

3. Interactive 引导 (默认首次跑触发)

innies   # 不要 pipe,保持 stdin 是 TTY

首次跑会打印:

=============================================================================
[innies-onboarding] 首次运行检测 (N20 fresh-install 阻断防护)
config.toml: /Users/you/.inniescoder/config.toml

检测到以下 provider 块的 base_url 仍是占位符(注释状态):
  - [model_providers.zhiman_35b] base_url = "http://your-private-deployment/v1"
  - [model_providers.zhiman_27b] base_url = "http://your-private-deployment/v1"
  - [model_providers.dashscope]   base_url = "https://dashscope.aliyuncs.com/compatible-mode/v1"

请选择配置方式:
  1. 现在交互式填入 base_url 和 api key (推荐) — 写回 config.toml
  2. 跳过,我会自己编辑 /Users/you/.inniescoder/config.toml
  3. 退出 innies
>

选项 1: 逐步输入每个 provider 的 base_url 和 env_key 名,自动写回 config.toml,然后继续启动 innies。
选项 2: 跳过(接受 N20 会 fail)。之后自己编辑 ~/.inniescoder/config.toml 填值。
选项 3: 退出 innies(process.exit(0)),让你先手动配。

跳过引导: 设 export INNIES_SKIP_ONBOARDING=1 后跑 innies,永远不弹引导横幅。CI / smoke 测试用。

详见 ~/.inniescoder/config.toml 顶部的 ⚠️ FIRST-RUN SETUP REQUIRED 横幅注释(模板在 codex-cli/bin/innies-config.js 的 defaultInniesConfig 里,首次 innies 启动时会写入)。

Provider 配置

[!IMPORTANT] 首次安装的硬约束（2026-06-10 起）：npm install -g 写入 ~/.inniescoder/config.toml 时，会自动创建 zhiman 与 bailian 两个 provider 块且每个必要 key 都存在，但 base_url 与 env_key 一律留空 —— 由你或实施团队事后填值。一旦你或任何工具写入非空值，npm install、innies 启动、模型切换都不会再覆盖它们。

首次运行 innies 会在 ~/.inniescoder/config.toml（Windows: %USERPROFILE%\.inniescoder\config.toml，或环境变量 INNIES_HOME 指向的目录）写入默认配置：

model_provider = "zhiman"          # 私有化部署 / 评估（知满网关）
model = "qwen35_35b"               # 模型 slug，可切换 qwen36_27b / qwen3.6-27b

[model_providers.zhiman]
name = "zhiman"
base_url = ""                      # ← 由用户填值；空串 = 启动器会失败并提示
wire_api = "responses"
env_key = "ZHIMAN_API_KEY"

[model_providers.bailian]
name = "bailian"
base_url = ""                      # ← 由用户填值（dashscope 公网 URL）
wire_api = "responses"
env_key = "BAILIAN_API_KEY"

两个 provider 块的语义

切换模型只需要改根字段：

# 私有化 · 35B（默认）
export INNIES_MODEL='model = "qwen35_35b"'     # + model_provider = "zhiman"

# 私有化 · 27B
export INNIES_MODEL='model = "qwen36_27b"'     # + model_provider = "zhiman"

# 公网 · 27B
export INNIES_MODEL='model = "qwen3.6-27b"'    # + model_provider = "bailian"

填 base_url：

# 私有化生产（你客户机房内网地址）
[model_providers.zhiman]
base_url = "https://<your-host>/v1"

# 公网
[model_providers.bailian]
base_url = "https://dashscope.aliyuncs.com/compatible-mode/v1"

API Key 通过环境变量注入，不要写进 config.toml：

export ZHIMAN_API_KEY="..."      # 私有化
export BAILIAN_API_KEY="..."     # 公网 dashscope
# 写入 ~/.zshrc 或 ~/.bashrc 后持久化

不覆盖用户值（核心约束）

normalizeProviderBlock 的语义（截至 v0.122.46）：

对 name / base_url / wire_api / env_key / model_slug 这五个 key：
若用户已写入非空值，保留；仅当值为空 / 全空白时才写入占位。
stripReservedProviderBlocks 改为 noop（即便你写了 [model_providers.openai] 等块，npm install 也不会删除）。
stripManagedRootSettings 同样只 strip 空值：根 model_provider / model 一旦被你填过，启动器永不触碰。

可执行 scripts/innies-isolation-validate.sh 验证 7 轮不变量：首次安装 / 用户 base_url 保留 / 缺失整块自动补齐 / 幂等 / INNIES_HOME 覆写 / ~/.codex 严格隔离 / 用户自定义 key 保留。

与原生 Codex 的隔离

| 维度 | Innies Codex | 官方 Codex | | :--- | :--- | :--- | | 配置目录 | ~/.inniescoder/ | ~/.codex/ | | INNIES_HOME | ✅ 可改写 home 目录 | — | | 互相读取 | ❌ 完全隔离 | ❌ 完全隔离 | | npm install 时副作用 | 仅写 ~/.inniescoder/* | — |

innies-isolation-validate.sh 第 6 轮在快照前后对比 ~/.codex/ 文件清单，任何文件增减即视为隔离破坏，验证失败。

完整步骤与历史迁移指南：docs/Inniescoder用户使用手册.md · 字段参考：docs/config.md

快速上手

cd /path/to/your/project

innies                                  # 交互式 TUI
innies exec "运行所有测试并总结失败用例"   # 非交互执行，适合 CI
innies review --base main               # 代码审查
innies app-server                       # JSON-RPC + WebSocket，供 IDE/系统集成

与原生 Codex 的差异

[!TIP] 设计原则：只换大脑，不换骨架。 上游 Codex 每个 release 都会跟进，定制点仅落在模型层、品牌层、稳定性补丁层。

🛣️ 迭代路线

| 阶段 | 状态 | 内容 | | :--- | :---: | :--- | | v1 · CLI Agent | ✅ 已发布 | 稳定的 TUI / exec / review / app-server 入口，知满 qwen35_35b 适配，14 项 Superpowers 技能 | | v2 · 私有化部署套件 | 🟢 进行中 | 推理服务镜像、Helm Chart、模型权重交付、客户机房一键部署 | | v3 · InniesCoding 端到端工作流 | 🟡 内测 | 由自然语言需求自动驱动的五阶段管线，详见下文 | | v4 · IDE 插件 / Web 控制台 | ⚪ 规划中 | 基于现有 App Server 能力延伸 |

InniesCoding 端到端工作流（v3 预览）

InniesCoding 是建在 Innies Codex 之上的研发自动化管线，由 RAG（检索增强）与 KG（知识图谱）MCP server 驱动，将一个自然语言需求拆解为五个可追溯阶段：

需求分析 → 代码定位与影响评估 → Spec 生成 → 代码变更 → 测试用例补全

[!NOTE] 当前以 INNIES_CODING_STAGE 环境变量内部触发，公开版本将以 innies coding <stage> 子命令形式暴露。实现入口见 codex-cli/bin/innies-coding-runtime.js。

🧪 质量验证现状

[!NOTE] 基于 docs/innies-qwen35-* 系列报告的真实压测产出。最近一次验收：2026-05-24。

已完成

| 验证项 | 结果 | 证据 | | :--- | :---: | :--- | | 全链路功能矩阵（CLI / API / Skills / Output Schema / Spawn Agent） | ✅ | full-chain 2026-05-17 | | 单用户基线 | ✅ | single-user 2026-05-17 | | 30 并发 API 突发 | ✅ 30/30 | full-chain 2026-05-17 | | 复杂任务通过率（A 计划验收） | ✅ 118/120 = 98.3% | complex-task-fix-report 2026-05-24 | | · multi_agent_review | ✅ 40/40 = 100%（60% → 100%） | 同上 | | · system_design | ✅ 38/40 = 95%（75% → 95%） | 同上 | | · superpowers_chain | ✅ 40/40 = 100% | 同上 | | 长稳 harness + 监控脚本就绪 | ✅ | scripts/long_soak.py · scripts/long_soak_monitor.py | | 长稳预演（1h 子集） | ✅ | corpus long-soak-preflight-20260524-* | | 8 小时长稳正式跑（B 计划验收） | ✅ 302/303 = 99.67% | long-soak-report 2026-05-26 | | · superpowers_chain | ✅ 27/27 = 100% | 同上 | | · multi_agent_review | ✅ 27/27 = 100% | 同上 | | · system_design | ✅ 26/27 = 96.3%（1 次超时，无熔断） | 同上 | | · KV cache 命中率 | ✅ 83.6%（37.4M input / 31.3M cached） | 同上 | | 失败语料库（供后续 SFT/DPO） | ✅ 4 个样本 | docs/qwen35-finetune-corpus/ |

进行中 / 未完成

| 验证项 | 状态 | 说明 | | :--- | :---: | :--- | | 100+ 并发 API 突发 | ❌ 已知失败 | 43/102，45s 超时；待服务端容量整改后复跑 | | 长稳复跑（次日不同时段） | ⚪ 未启动 | B 计划首跑已验收，复跑视客户落地节奏安排 | | 24h / 7×24 持续运行 | ⚪ 未启动 | 8h 已达标，24h 验证服务长尾稳定性 | | Windows 平台行为 | ⚪ 未验证 | 当前全部测试仅在 macOS 跑过；Linux 已编译期强制禁用 | | 客户机房私有化部署后的长稳 | ⚪ 未验证 | 实施时与客户联合验证 | | 多机器分布式 agent / 故障注入 / 多租户 | ⚪ 未启动 | B 计划延伸事项 |

已落地的工程工件（A 计划，2026-05-24）

失败归因脚本 scripts/classify_complex_failures.py
output_schema 压测 scripts/schema_pressure.py
长稳 harness scripts/long_soak.py（419 行）
长稳监控 scripts/long_soak_monitor.py（含 RSS / FD / 目录大小 / 崩溃信号）
三路径修复（B1 Prompt 末尾固化 marker · B2 强制 output_schema · B3 Harness 层 re-prompt 兜底）合并进主压测 runner

⚠️ 已知限制与风险

[!WARNING] 以下内容基于代码与配置事实列出，落地前请完整阅读。

1. 模型能力差距是真实存在的

qwen35_35b 在以下维度可被代码直接证实地弱于 GPT-5 系列：

实际影响：

一次 turn 里需要"读 5 个文件 + grep 3 次"时，qwen35_35b 会串行逐个发起，整体延迟约为 GPT-5 的 2-3 倍
跨 10+ 文件的架构级重构需要更多人工拆解和多轮迭代，不要期望一次到位
不能通过 model_reasoning_effort 让模型"想久一点"——这个开关对 qwen35_35b 无效

[!TIP] 已工程化缓解：复杂任务里"指令跟随不稳定"（如 final marker 缺失）这类故障，已通过 A 计划落地的三路径修复（Prompt 末尾固化 marker + 强制 output_schema + Harness re-prompt 兜底）将 multi_agent_review 从 60% 提升到 100%、system_design 从 75% 提升到 95%。详见质量验证现状。模型本身的并行/推理档位差距仍然存在。

2. 上游跟随有滞后与冲突风险

仓库跟随官方 Codex 每个 release（最近一次 rust-v0.122.32）
上游做 breaking change 时，定制点（品牌、模型目录、隔离逻辑）需要手动 cherry-pick，预期延迟 1~2 周
上游 OpenAI 一旦移除 Responses API 或调整工具调用 schema，qwen35_35b 适配需追加工作量

3. 治理边界仅覆盖到本机

macOS 沙箱基于 Seatbelt（sandbox-exec），Windows 沙箱能力受限（仅文件系统 ACL）；Linux 不在支持范围内，启动时即报错退出
没有组织级 IAM、角色、审计后台——多人协作的合规治理需对接外部系统
API Key 是单 token、无作用域、无过期——一旦泄露需手动轮换全员

4. 许可与权属

仓库代码遵循 Apache-2.0（见 LICENSE）
qwen35_35b 模型权重不在本仓库，使用知满推理服务即受其商务条款约束；客户机房私有化部署的权重交付由知满实施团队处理
TUI 品牌字、Zhiman 商标属知满科技

5. 工具默认曝光（设计取舍）

3 个 qwen 模型在 catalog 里 experimental_supported_tools = []，意味着：

✅ 默认开：shell / exec_command / apply_patch（后者需 features.apply_patch_freeform = true，模板已开）
❌ 默认禁：list_dir、read_file 等独立工具；模型遇到目录/文件读取需求时会自动 fallback 到 shell ls / shell cat，功能等价但 token 略多

如确需 list_dir 作为独立工具暴露给模型（例如对延迟敏感的批量目录扫描场景），编辑 ~/.inniescoder/catalog.json：

{
  "slug": "qwen36_27b",
  // ... 其他字段
  "experimental_supported_tools": ["list_dir"]  // 加入想曝光的工具名
}

这是有意保留的默认取舍 — 既能维持 prompt 简洁、避免 qwen 模型在工具选择上 over-think，又给需要的用户留出 catalog-level 配置开关。

文档

· ✦ ·

问题反馈 · 定制需求 → 知满科技 Zhiman · intent in motion