每一个多Agent框架都在做同一件事：给每个Agent尽可能多的上下文。更长的对话历史、更大的记忆库、更复杂的工具链——期望AI从海量信息中找到答案。

NTK 做相反的事。

军事情报领域有一个原则叫 "Need-to-Know Basis"——即使你有最高安全权限，你也只会被告知完成任务所必须知道的最小信息集。NTK 把这个原则带进了多Agent系统：

每个Agent只收到它完成任务所需的最少信息，一个字都不多给。

这不是限制，这是优势。认知科学告诉我们，选择性注意力才是实现专注的本质——不是看到更多，而是忽略更多。LLM 同理：短上下文比长上下文更精确、更遵循指令、更不容易幻觉。给得越少，做得越好。

• 自适应复杂度路由 (Adaptive Complexity Routing) — 通过正则快速路径 + 轻量 LLM 分类器自动评估任务复杂度，将复杂任务分配给多阶段管线，简单任务一步直出。不同复杂度的任务走不同的处理通道。
• 选择性遗忘 (Selective Forgetting) — Agent 间不传递原始上下文，而是经过信息密度压缩后按需投递。每个 Agent 只看到经过裁剪的最小充分信息集。
• 零开销分级 (Zero-Overhead Classification) — 在内部测试集中约 63% 的任务通过正则快速路径在微秒级完成分级，完全绕过 LLM 分类器，实现零额外 token 消耗。
• 渐进式管线深度 (Progressive Pipeline Depth) — 四级深度自适应：direct → light → standard → full，像 TCP 慢启动一样，只在必要时才升级复杂度。
• 双模型成本分离 (Dual-Model Cost Isolation) — 95%+ token 走廉价模型，仅 2-5% 高信息密度决策使用强模型，实现类似混合精度训练的成本结构。

大多数"智能"框架对所有任务走同一个复杂管道。写一个斐波那契函数？也要经过规划→调研→执行→验证四步。

NTK 不这样做。它先用零开销正则分类器（在测试集中处理约 63% 的任务）判断复杂度，只在必要时才启动更深的管道：

写斐波那契和设计微服务架构不该花一样的钱。NTK 正是为此设计。

NTK 的核心策略是双模型成本分离：绝大多数工作交给廉价模型，只有真正需要深度推理的规划步骤才用强模型。

实测数据（9 类任务，每配置 3 次运行取均值）：

⚠️ NTK vs 全强模型的成本差异主要来自模型单价差（廉价模型约为强模型 1/10~1/20 价格）。vs 裸调廉价模型，NTK 的 token 节省约 7-80%（因任务复杂度而异）。

NTK 经过了 50+ 次内部系统性实验（样本有限，持续扩展中），包括：

• 6 种配置 × 多复杂度任务 的优化矩阵
• 手动代码审查 的质量验证（逐行检查 bug 和需求完成度）
• 消融实验 证明每个模块的必要性
• 对比发现：复杂管道处理简单任务时反而引入 bug（过度分解问题）

6 类生产级任务，6/6 全部通过（gpt-5.4-mini 为主，单次运行）：

平均 4,061 tok/任务。5/6 任务全程廉价模型，仅最复杂的 full 深度任务使用了 13.9% 强模型 token。 使用 npx tsx src/cli.ts test:real 复现。

同一个函数（mergeIntervals, 6 项需求），三种深度：

Direct 用了 Full 1/20 的 token，零 bug。Full 因为过度分解反而引入了 1 个 bug。越简单的任务越不该用复杂管道——这正是自适应路由存在的意义。

NTK 用更少的 token + 全廉价模型 = vs 全强模型方案综合成本节省 90%+（主要来自模型单价差异）。 vs 裸调廉价模型，token 节省 7-80%。智能验证跳过使 light 深度 token 减少 76%，耗时减少 65%。

git clone https://github.com/kobolingfeng/ntk.git
cd ntk && npm install
cp .env.example .env  # 填入你的 API Key

npx tsx src/cli.ts run "用Python写一个LRU缓存"

NTK 原生支持 MCP 协议，可直接接入 VS Code Copilot、Claude Desktop、OpenClaw 等任何支持 MCP 的客户端。

方式一：npm 全局安装（推荐）

npm install -g ntk

{
  "mcpServers": {
    "ntk": {
      "command": "ntk",
      "args": ["mcp"]
    }
  }
}

方式二：从源码运行

git clone https://github.com/kobolingfeng/ntk.git
cd ntk && npm install

{
  "mcpServers": {
    "ntk": {
      "command": "npx",
      "args": ["tsx", "src/mcp/server.ts"],
      "cwd": "/path/to/ntk"
    }
  }
}

接入后获得 3 个工具：

• ntk_run — 自适应管线（自动选择最优深度）
• ntk_run_fast — 极速模式（直接执行，最低开销）
• ntk_compress — 信息密度压缩

{
  "servers": {
    "ntk": {
      "command": "npx",
      "args": ["tsx", "src/mcp/server.ts"],
      "cwd": "/path/to/ntk"
    }
  }
}

{
  "mcpServers": {
    "ntk": {
      "command": "ntk",
      "args": ["mcp"]
    }
  }
}

{
  "mcpServers": {
    "ntk": {
      "command": "ntk",
      "args": ["mcp"],
      "env": {
        "API_ENDPOINT_1_KEY": "sk-your-key",
        "API_ENDPOINT_1_URL": "https://your-api.com/v1"
      }
    }
  }
}

接入 MCP 后，在任意 AI 客户端中可以这样使用：

// 自适应执行 —— 自动选择最优深度
ntk_run({ task: "用Python写一个支持TTL的LRU缓存" })

// 极速执行 —— 简单任务一步直出
ntk_run_fast({ task: "写一个合并区间的函数" })

// 强制指定深度
ntk_run({ task: "设计微服务架构", forceDepth: "full" })

// 信息压缩
ntk_compress({ text: "很长的文本...", level: "aggressive" })

NTK 可以帮助 OpenClaw 用户降低 token 消耗。通过 MCP 接入后，在部分任务上 token 用量可减少 20-50%（因任务类型而异）：

以上数据来自实测（gpt-5.4-mini，2026.3.31，单次运行）。NTK 全程使用廉价模型，vs 全强模型方案加权成本节省 90%+；vs 裸调同款廉价模型，token 节省因任务而异（-7% ~ 52%）。 9/9 任务均走 direct/light 深度，无需强模型参与。

一行接入：

{
  "mcpServers": {
    "ntk": { "command": "ntk", "args": ["mcp"] }
  }
}

接入后在 OpenClaw 对话中直接使用 ntk_run 和 ntk_run_fast，自动选择最省 token 的执行路径。

npx tsx src/cli.ts interactive                # 交互模式
npx tsx src/cli.ts serve --port 3210          # HTTP API 服务
npx tsx src/cli.ts mcp                        # MCP stdio 服务

NTK 需要你自备 OpenAI 兼容的 API 端点。不内置任何 API Key，你需要提供自己的。

复制示例文件并编辑：

cp .env.example .env

最简配置（单端点 + 单模型）：

API_ENDPOINT_1_KEY=sk-your-api-key
API_ENDPOINT_1_URL=https://api.openai.com/v1
API_ENDPOINT_1_NAME=openai
MODEL=gpt-5.4-mini

设置 MODEL 会让所有 Agent 使用同一模型。如需更低成本可用 gpt-5.4-nano。

NTK 的核心优势是只让规划使用强模型，其余全部用廉价模型：

API_ENDPOINT_1_KEY=sk-your-api-key
API_ENDPOINT_1_URL=https://api.openai.com/v1
API_ENDPOINT_1_NAME=openai

PLANNER_MODEL=gpt-5.4          # 强模型 — 仅 full 深度规划使用
COMPRESSOR_MODEL=gpt-5.4-mini  # 廉价模型 — Scout/Executor/Verifier 全用这个

在测试集中约 63% 的任务走 Direct 路径，不触发 Planner，因此多数请求仅使用廉价模型。

API_ENDPOINT_1_KEY=sk-key-a
API_ENDPOINT_1_URL=https://api.openai.com/v1
API_ENDPOINT_1_NAME=openai

API_ENDPOINT_2_KEY=sk-key-b
API_ENDPOINT_2_URL=https://your-backup.com/v1
API_ENDPOINT_2_NAME=backup

PLANNER_MODEL=gpt-5.4
COMPRESSOR_MODEL=gpt-5.4-mini

{
  "mcpServers": {
    "ntk": {
      "command": "ntk",
      "args": ["mcp"],
      "env": {
        "API_ENDPOINT_1_KEY": "sk-your-key",
        "API_ENDPOINT_1_URL": "https://api.openai.com/v1",
        "API_ENDPOINT_1_NAME": "openai",
        "PLANNER_MODEL": "gpt-5.4",
        "COMPRESSOR_MODEL": "gpt-5.4-mini"
      }
    }
  }
}

DEBUG=true  # 开启详细日志，显示路由决策和 Agent 调用链

使用 --verbose（或 -v）标志查看完整的管线追踪信息，包括路由决策路径、压缩统计、token 分布和耗时：

npx tsx src/cli.ts run "你的任务" --verbose

追踪信息包含：

• 路由路径：正则快速路径 vs LLM 分类器、推测执行命中/未命中
• 压缩统计：预过滤移除字符数、LLM 压缩调用次数、Tee 存储/恢复次数
• Token 分布：按 Agent 和模型类型（廉价/强）的 token 使用明细
• 耗时：端到端执行时间

编程使用时，PipelineResult.trace 字段提供结构化的 PipelineTrace 对象，可用于自定义监控和分析。

用户请求
  ↓
🔀 自适应分类器 (正则快速路径 / LLM)
  │
  ├── direct  →  🔧 Executor → 结果       ← 63%的任务走这里
  ├── light   →  🔧 Executor → 结果
  ├── standard → 🔍 Scout → 🔧 Executor → 结果
  └── full    →  🧠 Planner(强模型) → 🔧 Executor×N → ✅ Verifier → 结果

5 类 Agent，按信息密度分工：

• Planner — 唯一使用强模型，处理高密度决策（仅 full 深度触发）
• Scout / Summarizer — 廉价模型，信息收集与压缩
• Executor — 廉价模型，核心任务执行
• Verifier — 廉价模型，结果校验

NTK 在 LLM 压缩之前，先用零 token 成本的确定性策略过滤结构化噪声。这一层与语义压缩和路由隔离深度集成，实现两阶段信息压缩。

7 种过滤策略 + 智能输出类型检测：

输出类型自动检测：pre-filter 会自动识别输入是 test/json/log/build 中的哪种，只应用相关策略。

# 查看累计节省统计
npx tsx src/cli.ts gain

压缩是有损的。NTK 的 Tee 机制在压缩时保存原始文本副本，当验证失败时可恢复完整内容，避免关键信息丢失。

压缩阶段:  原文(500 tok) → teeStore → 压缩文(80 tok) 传递给下游 Agent
验证失败:  Verifier 报告缺少关键细节 → teeRetrieve → 恢复原文(500 tok) 重新执行
验证通过:  teeClear → 释放存储

这使得 NTK 可以大胆压缩而不怕丢信息——最坏情况下回退到完整内容，而不是带着残缺信息反复重试。

npx tsx src/cli.ts test       # 9任务回归测试
npx tsx src/cli.ts test:real  # 6类真实场景测试
npx tsx src/cli.ts benchmark  # 多次运行基准测试（3×，均值±标准差）
npx tsx src/cli.ts baseline   # NTK vs 直接LLM对比
npx tsx src/cli.ts compare    # RTK vs Traditional vs NTK 三方对比
npx tsx src/cli.ts gain       # 累计节省统计
npx tsx src/cli.ts ablation   # 消融实验（各模块贡献）
npx tsx src/cli.ts optimize   # 6配置优化矩阵

感谢 LINUX DO 社区提供的支持。

如果 NTK 对你有帮助，欢迎支持一下：

微信赞赏	链动小铺	PayPal
		paypal.me/koboling

AGPL-3.0 — 你可以自由使用、修改和分发，但任何修改版本或基于本项目的网络服务都必须以相同协议开源。