面向全领域场景的智能协作中枢
用一个目标，调度模型、Agent、Skill、MCP、工具、知识与专家，交付可验证结果。
九门赛博提督是面向全领域场景的智能协作中枢，以目标驱动内外部 Agent、模型、工具、知识与专家协同执行，交付可验证的业务结果。平台位于用户目标与 AI 能力之间，负责能力组织、执行约束、故障恢复与结果验证。
| 业务问题 | 平台能力 |
|---|---|
| 模型额度耗尽，换模型却丢失能力 | 动态回退，必要时仅调用专家模型补齐缺口 |
| Agent、Skill、MCP 和知识分散在不同宿主 | 一个核心、多个入口，按目标装配最小能力集 |
| 自动执行快，但费用、风险和结果不可控 | 预算、审批、策略、检查点和验收条件共同限制执行 |
| 企业想统一治理，个人又需要自主选择 | 强制策略与辅助策略分层，企业和个人资源可并存 |
| 完整会话和工具输出导致存储失控 | 完整历史留在宿主，核心只保留最大 256 KB 的恢复胶囊 |
需要 Node.js 22.14 或更高版本。 安装前先确认版本：
node --version如果版本低于 22.14，可使用已安装的 Node 版本管理器切换。以 NVM 为例：
nvm install 22
nvm use 22Node 版本满足要求后，安装并启动配置中心：
npm install -g @skillnull/tidu
tidu setup
tidu start打开终端输出的配置中心。页面会引导完成部署识别、入口命名、模型接入、点击保存草稿、启用和客户端接入。
Note
npm 安装命令不会替用户安装或切换 Node.js。请先在当前终端切换到兼容版本，再安装 AI-Tidu9。
服务器无法打开页面时，使用同一套终端向导：
tidu start --cli已启动后，用两个命令确认状态：
tidu doctor # 检查运行时、配置 API 和页面
tidu setup verify # 验证连接器，不修改配置Tip
所有高级命令都支持 --help。完整参数见 CLI 命令参考。
这条链路有三个不可替换的责任：
- 模型做推理：理解目标、生成计划、评估结果。
- 内核管边界：执行预算、风险审批、状态转移、失败恢复。
- 证据决定是否完成：测试通过不代表业务目标已达成，验收条件必须独立判定。
| 机制 | 作用 | 最重要的边界 |
|---|---|---|
| 多入口、单核心 | Codex、Cursor、CLI 和 OpenAI 兼容客户端共享策略与能力池 | 不读取或复制宿主私有 Token |
| 动态路由 | 按能力、已知成本、可证隐私、实测延迟、可用性和明确失败信号选择模型 | 未知价格或未接入的额度数据不驱动替换 |
| 跨模型协作 | 配置的副模型可因能力缺口、更低的价格加权 Token 成本、更低延迟、更高可用性或故障切换参与执行 | 模型池、次数、费用和隐私边界均必须显式配置 |
| Runtime Secret Gate | 出站前识别、阻断或替换敏感信息 | 真实值只在当前任务的私有内存作用域恢复 |
| 可恢复执行 | 任务胶囊、检查点和已验证配置支持恢复与回滚 | 结果不确定时，非幂等操作不自动重放 |
实现细节与可复现案例见 核心调度与门禁。
| 我想要…… | 从这里开始 | 数据层 |
|---|---|---|
| 在本机统一个人模型、Skill 和 MCP | tidu start |
SQLite，默认只监听回环地址 |
| 在服务器集中管理策略、额度和能力 | 远程部署文档 | 企业控制平面 |
| 保留 IDE 本地能力，同时经过企业出口 | 远程部署文档 | 服务端状态 + 本地私有边界 |
| 开发模型、Agent、存储或历史 Provider | @skillnull/tidu/ecosystem 或 Python SDK |
通过平台 API 访问，不复制控制平面 |
默认自动使用已登录的 Codex 或 Cursor 宿主当前模型，不需要填写模型名或密钥。通过官方宿主进程调用，AI-Tidu9 不读取或复制宿主凭据。下面的命令用于主动覆盖默认模型。
Codex 桥通过官方 app-server 原生转发文本、远程图像和本地图像输入，并复用官方账号提供的推理、命令、文件、搜索与工具能力；不会再把多模态请求压成自定义纯文本，也不会在输出末尾追加九门摘要。Cursor 纯文本请求先通过 ACP 确认配置模型，再映射到同一官方 Agent CLI 的等价无头模型，并以只读 ask 模式通过 stream-json 执行，以回传真实过程和 Token；含图像请求保留 ACP 多模态通道。各宿主仍只发布自身桥接协议已经验证的能力，未适配请求会明确失败。
OpenAI 兼容服务：
TIDU_PROVIDER=openai-compatible \
TIDU_PROVIDER_BASE_URL='https://<service>/v1' \
TIDU_PROVIDER_MODEL=gpt-4.1-mini \
TIDU_PROVIDER_API_KEY='<runtime-key>' \
tidu start本机 Ollama：
TIDU_PROVIDER=ollama \
TIDU_PROVIDER_MODEL=qwen3:8b \
tidu startImportant
覆盖服务的密钥只从当前进程环境读取，不进入 SQLite、页面返回或日志。若没有可复用的宿主模型且未设置覆盖供应商，推理会明确返回 model_provider_not_configured。
tidu setup # 自动配置九门并按提示重启宿主
tidu clients # 查看本机客户端兼容情况
tidu account # 查看可复用的宿主登录状态
tidu channel list # 查看九门、官方宿主与厂商通道
tidu doctor --json # 生成不含私密数据的诊断摘要
tidu uninstall # 清理全部 AI-Tidu9 自有内容完整卸载会保留宿主账号、会话、无关插件、无关配置和自定义数据库路径。
通用客户端通过同一基址使用 /v1/models、/v1/chat/completions 和 /v1/responses。普通推理请求默认走单模型快速路径：完成策略与能力检查、动态路由、一次模型执行和响应完整性检查，不为制造“协作感”额外串行调用模型。需要目标分解、检查点或独立业务验收时，使用完整任务流程或显式配置的能力补全。
流式请求遵循调用方协议和所选宿主的原生流程。每个宿主适配器根据实时协商和收到的官方事件，动态转译公开过程、回答与终态；新增的消息阶段不会因九门本地枚举未更新而被拒绝或丢弃。通用 OpenAI 客户端仍按其请求的 Responses 或 Chat Completions 事件返回。Codex 请求声明工具时，通过 app-server dynamicTools 生成真实调用，再交回调用方的原生工具执行。读取、搜索、编辑和运行进入原生活动列表，运行中事件保留原生状态，不再把执行描述写成 reasoning。思考摘要和 commentary 消息保留各自类型与阶段。九门不会注入“正在处理请求”等占位进度。请求完成后，终态保留过程项、创建与完成时间以及宿主实际回传的 Token 用量，取消记录独立标记，失败终态仍保留已上报用量；缺失用量显示“未获取到”，明确为零的消耗不显示。客户端恢复接入只读官方会话记录，补齐取消命令、底部 Token 和实际耗时，覆盖实时显示、重新打开和分页读取。不会新增九门会话数据库或副本；单次最多读取官方会话尾部 8 MiB，并仅缓存一个文件的必要元数据。官方宿主的实际取消、进程重启、会话恢复与本机原生耗时组件渲染均有回归验证。Codex 成功与可返回的失败结果附带 Token 统计；缺失用量标注“未获取到”，明确为零的消耗不显示，多轮工具调用只累计一次各轮已上报用量。完成时按当前协议发送标准终态事件。模型等待期间只发送协议心跳，九门不设置本地推理超时，以宿主官方接口的完成、失败或取消终态为准。承担必需能力的副模型正式失败或取消时整次请求失败关闭，不会改用缺少该能力的主模型冒充成功；失败响应同步发送可见错误文本和失败终态。
配置中心的“能力互补”栏目统一展示本地、个人和企业运行时的生效开关、各宿主优先主模型、跨宿主副模型池、公司发布能力、价格证据、实测表现与最近路由记录。每次记录分别展示配置模型和宿主确认的实际执行模型；未取得宿主回执时不会把配置值当成执行成功。Codex、Cursor、Ollama 和兼容服务共享同一 Agent 内核，但分别保存自己的动态路由策略；副模型只能从其他宿主选择并由对应 Provider 执行，可用于能力补位，也可在价格加权耗用、可证隐私、实测延迟、可用性或明确失败规则下成为本次请求的执行模型。未知价格和未接入的额度数据不驱动替换。
主模型和副模型只展示对应宿主模型目录实际返回、且九门路由契约支持的能力，并默认勾选这些真实能力。切换模型时能力列表会同步刷新，旧配置中超出当前模型目录的能力会被移除；用户在真实能力范围内主动取消后的精确集合会保存，也允许某个模型全部不勾。路由按能力逐项分配：主模型未勾选、但副模型勾选的能力只交给副模型；同一请求中的其他能力仍由勾选了对应能力的主模型执行。混合能力请求按依赖顺序共享同一协作上下文：前序模型的可见过程和正式结果会交给后续模型，最终由拥有 text 能力的模型汇总回答；纯文本请求仍只调用拥有 text 能力的模型。零能力模型不会被调用；主副模型能力并集仍无法覆盖请求时，路由会在调用前失败关闭。向导存在未保存修改时，“保存并进入下一步”会先保存；保存失败不会跳到下一步。草稿保存仍不等于启用。全局强度只在当前宿主为 Codex、且强度会真实传给宿主时显示；其他宿主不会展示无效开关。
tidu setup 会生成一个可回滚的 Codex 九门配置，但不会自动切走官方配置。Codex 使用互斥的原生双模式：九门模式只显示一个 AI-Tidu9 Agent，本地 Provider 显示为 AI-Tidu9 (local)；官方模式只显示官方模型。两套提供方与模型目录不混用。本地 Provider 关闭 Codex 的请求与流重试；服务不可达时不会连续刷出多轮 Reconnecting。配置页可在宿主、公司和自定义上游之间互斥选择；公司模型不会成为独立 Codex 模型项。服务页按当前运行形态二选一展示开发服务或本地安装服务，并提供状态刷新与可用操作。九门只保留首次安装基线与最新回滚点两份自有快照。
双通道入口使用 tidu channel run <channel>。tidu 进入九门 Agent 内核，codex 与 cursor 作为可调度的官方宿主能力；CI可使用 openai、deepseek、qwen、glm、kimi、doubao、hunyuan 或 custom 厂商通道。Cursor 等只支持连接器协议的宿主也必须经过同一套策略、路由、执行生命周期和终态检查，不能绕过内核边界。
- 普通草稿、专家草稿和生效快照相互隔离；保存不会自动启用。
- 写入和外部工具默认需要确认；必须策略不能被插件或专家模式绕过。
- 不可信扩展没有外部隔离执行器时默认拒绝；Node
vm和普通 Worker 不属于安全沙箱。 - 企业跨设备访问必须使用 HTTPS 反向代理和身份控制，不得直接暴露管理端口。
Warning
项目已进入实际使用与持续维护。生产关键任务仍应先在目标环境完成容量、权限、安全、升级和回滚验证。
| 文档 | 回答的问题 |
|---|---|
| 系统架构 | 一次任务如何流动，模块、数据和部署边界在哪里？ |
| 核心调度与门禁 | 动态路由、能力补全和 Secret Gate 如何工作？ |
| CLI 命令参考 | 如何安装、配置、诊断、恢复和卸载？ |
| 使用实例 | 如何完成本地模型、客户端、企业部署和 Provider 接入？ |
| 开放能力生态 | 如何安全地接入 Provider 和第三方 Agent？ |
| Python SDK | 如何从 Python 调用 AI-Tidu9 Provider API？ |
| 贡献指南 | 分支、提交、版本、维护线和发布规则是什么？ |
| 远程部署 | 如何部署服务器运行时并隔离跨设备访问？ |
| 本地开发 | 如何启动、验证并停止仓库开发环境？ |
| 商标与署名 | 修改名称或商业部署时，如何正确说明来源？ |
| 变更记录 | 每个已发布版本实际改变了什么？ |
仓库开发的启动、Codex 配置验收、检查和停止流程统一放在本地开发文档。主文档不混入开发环境操作细节。
问题反馈请附上经审查的 tidu doctor --json 输出：
项目使用 GNU AGPL-3.0-only。品牌与署名规则见 商标政策 和 NOTICE。