Hermes 技能系统详解——安装、使用与浏览第 9 篇：技能系统详解——安装、使用与浏览引言技能是按需加载的指令文

第 9 篇：技能系统详解——安装、使用与浏览

引言

技能是按需加载的指令文档，教 Hermes 如何完成特定任务——部署到 Kubernetes、创建 GitHub PR、微调模型、搜索 GIF 等。每个技能是一个 SKILL.md 文件，包含名称、描述和步骤。

技能的工作原理

Hermes 采用渐进式披露（progressive disclosure）策略：

代理在系统提示中看到每个技能的短描述（几乎零成本）
只有当任务真正需要某个技能时，才加载其完整内容
添加技能不会增加每次请求的上下文开销

内置技能目录

Hermes 在 ~/.hermes/skills/ 中预装了一批捆绑技能。每个已安装的技能自动成为斜杠命令：

/gif-search funny cats
/axolotl help me fine-tune Llama 3 on my dataset
/github-pr-workflow create a PR for the auth refactor

# 只输入技能名让 Hermes 询问你需要什么
/excalidraw

浏览和安装技能

# 列出所有可用技能
hermes skills browse

# 按关键词搜索
hermes skills search kubernetes

# 安装一个技能（先运行安全扫描）
hermes skills install openai/skills/k8s

安装参数是 source/path 格式的 slug——openai/skills/k8s 表示来自 OpenAI 目录的 k8s 技能。

技能来源

来源	说明
官方可选技能	Hermes 团队维护的精选技能
Skills Hub	社区贡献的技能市场
well-known	通过 `.well-known/skills.json` 发现
GitHub	直接从 GitHub 仓库安装
URL	从 HTTP(S) URL 安装 SKILL.md 和引用文件

在会话中使用技能

# 在任何聊天会话中
/k8s deploy the staging manifest

# 从 CLI 直接使用
hermes -s hermes-agent-dev,github-auth

# 单次查询模式
hermes chat -s github-pr-workflow -q "open a draft PR"

`/learn` 命令

当你在对话中教代理一个新工作流程后，可以用 /learn 将其保存为技能：

# 前提条件——代理需要以下之一来学习技能：
# 1. 本地 SDK 或文档目录——通过 read_file / search_files 读取
# 2. 在线文档页面——通过 web_extract 获取
# 3. 你在本次对话中刚走过的流程
# 4. 粘贴的笔记 / 描述的步骤

/learn create a skill for deploying to our staging server

技能包（Skill Bundles）

将多个相关技能组合成一个包：

# 为后端功能工作创建一个包
hermes skills bundle create backend-work --skill deploy --skill migrate --skill test

# 列出所有已安装的包
hermes skills bundle list

# 检查一个包
hermes skills bundle inspect backend-work

# 删除一个包
hermes skills bundle delete backend-work

# 重新扫描技能包目录
hermes skills bundle rescan

安全扫描

安装技能时会先运行安全扫描：

$ hermes skills install openai/skills/k8s
🔍 Running security scan...
✅ Scan passed — no suspicious patterns detected
📦 Installing skill 'k8s'...
✅ Skill installed: /k8s

技能配置

# 交互式配置特定技能
hermes skills config k8s

# 查看所有技能配置
hermes skills config --all

技能的更新生命周期

捆绑技能在 hermes update 时自动更新。如果你修改了某个技能，可以通过重置恢复原始版本：

# 安全重置——清除清单条目但保留你的当前副本
hermes skills reset k8s --restore safe

# 完全恢复——删除本地副本并重新复制上游版本
hermes skills reset k8s --restore full

# 非交互式（跳过确认）
hermes skills reset k8s --restore full --yes

Q&A

Q1: 技能和插件有什么区别？ A1: 技能是纯文本指令文档（SKILL.md），教代理"如何做"某件事，不需要 Python 代码。插件是 Python 包，添加新的工具函数、平台适配器或钩子处理器。技能更轻量、更安全，适合封装工作流程；插件更强大，适合添加新能力。

Q2: 技能加载后会一直占用上下文窗口吗？ A2: 不会。技能描述（约一行文本）在系统提示中始终存在，但完整内容只在需要时加载到当前回合。如果后续回合不再需要，它不会被重新加载。

Q3: 如何将自己的工作流程保存为技能？ A3: 三种方式：(1) 使用 /learn 命令在对话中创建；(2) 手动编写 SKILL.md 文件放入 ~/.hermes/skills/ 目录；(3) 使用 hermes skills create 命令交互式创建。创建的技能会自动注册为斜杠命令。

@dre108 的 Gigaxity Deep Research 栈：7 个 MCP 服务器干掉 Perplexity API 的 $10/几天烧钱循环

Hermes Agent 深度拆解 · 第 09 篇

@dre108 的 Gigaxity Deep Research 栈：7 个 MCP 服务器干掉 Perplexity API 的 $10/几天烧钱循环

每隔几天就往 Perplexity API 充 $10，只为给其他 MCP 工具产出的研究碎片做"综合"——@dre108 受够了这种被绑架的体验。他搭了一套自托管研究栈：SearXNG 元搜索 + Tavily + LinkUp 三路聚合，RRF 排序融合，CRAG 质量门控，Qwen3-30B 走 OpenRouter 按量付费做综合，学术搜索走 arXiv/SSRN 零 token 零成本。7 个 MCP 服务器 + 6 个工具 + 1 个 bundled skill，把每条研究综合调用的成本从$ 10 压到接近零。本文从 GitHub 仓库到 SearXNG 配置到 RRF 源码，1:1 逆向完整链路。

作者：@dre108 (Discord) / yoloshii (GitHub) 分类：Research · Cost Optimization 来源：GitHub 仓库 + Discord 原帖 发布：2026-05-05

PART 01

案例背景 + 溯源 + 整体架构

开篇：你每隔几天烧掉的 $10，到底买到了什么？

如果你在用 Hermes Agent 或任何 MCP 兼容的 agent harness 跑深度研究任务，大概率踩过这个坑：你同时挂了几个 MCP 工具做搜索和阅读——exa 搜网页、jina 读 URL、context7 查文档——agent 跑完一圈，吐给你一堆原始碎片。然后你想让 agent 把这些碎片综合成一份带引用的报告，agent 转头去调 Perplexity API 的 MCP 做"综合"。每次综合调用，Perplexity 收你一笔。每隔几天，$10 就蒸发了。

社区用户 @dre108（GitHub: yoloshii）受够了这个循环。他的原话直击痛点：

作者原话

"Not strictly a Hermes plugin per se, but very useful and cost-effective for heavy agent use. I got tired of paying Perplexity api to use their mcp for agentic research. It was like $10 a pop every few days just for synthesis calls on the research dumps of my other mcp tool calls. So I made my own called Gigaxity."

翻译过来：他不是在做又一个搜索工具——他是在把"研究综合"这个昂贵的环节从 Perplexity 的闭源黑箱里拆出来，换成完全自托管、成本可追溯、质量可控的流水线。7 个 MCP 服务器协同，从 SearXNG 元搜索到 RRF 排序融合，从 CRAG 质量门控到引用绑定，从矛盾检测到大纲引导综合——每一步的 token 消耗和成本都摆在台面上。

溯源信息

溯源渠道与原始链接

作者@dre108（Discord）/ yoloshii（GitHub）

GitHub 仓库github.com/yoloshii/gi…（MIT 协议，v0.6.4，37 commits）

原始 Discord 帖teknium1/nous-discord-archive · Gigaxity low-cost research stack

官方用户故事hermes-agent.nousresearch.com/docs/user-s…

初始发布2026-05-05（GitHub 初始版本）

Discord 帖2026-05-06

分类Research / Cost Optimization

案例元数据

维度	详情
项目名称	Gigaxity Deep Research
作者	@dre108（Discord）/ yoloshii（GitHub）
协议	MIT
版本	v0.6.4
提交数	37 commits
MCP 服务器数	7（1 编排器 + Triple Stack 3 个 + 2 伴生 + 1 社交）
编排器工具数	6（search / research / ask / discover / synthesize / reason）
综合模型	Qwen3-30B-A3B-Thinking-2507（via OpenRouter，main 分支）/ 本地 vLLM（local-inference 分支）
兼容 harness	Claude Code / Codex / Cursor / Hermes / Continue.dev / 任何 MCP 兼容 harness
Bundled Skill	skills/research-workflow/SKILL.md

业务问题：Perplexity API 的成本螺旋

@dre108 的使用模式在重度 agent 用户中极具代表性。他的 agent 已经挂载了多个 MCP 工具做原始检索——exa 做网页搜索、jina 读 URL 和学术论文、context7 查库文档。这些工具本身能产出大量原始素材，但素材不等于洞察。真正有价值的环节是"综合"——把分散在 10-20 个来源中的信息，融合成一份结构化、带引用、标注矛盾的报告。

问题是，Perplexity API 的 MCP 把"综合"这个环节做成了一个不可拆分的黑箱。每次调用，Perplexity 在自己后端做搜索 + 综合 + 引用绑定，然后把成品吐回来。你为整个流水线付一次钱——哪怕你自己的 MCP 工具已经把原始素材搜好了，Perplexity 还是要重新搜一遍再综合。结果就是：你既为自己的 MCP 工具的检索付费，又为 Perplexity 的重复检索 + 综合付费，双重计费。

成本痛点

Perplexity API 每"几天"消耗约 $10，纯粹用于对其他 MCP 工具产出的研究碎片做综合调用。一个月下来$ 30-$100+，对于个人开发者或小团队而言这是一笔纯粹可以消除的开销——因为综合这个环节完全可以用自托管的 LLM + 检索流水线替代。

Gigaxity 的解法是把"综合"这个黑箱拆解成可控的流水线步骤：多源搜索（SearXNG + Tavily + LinkUp）→ RRF 排序融合 → CRAG 质量门控 → 引用绑定 → 矛盾检测 → 大纲引导综合。每一步的输入输出和 token 消耗都透明可追溯，综合模型走 OpenRouter 按量付费的 Qwen3-30B，单次综合调用约 5K-10K input + 2K-4K output token，成本在分钱级别。

成本对比：Perplexity vs Gigaxity

维度	Perplexity API	Gigaxity
定价模型	每次综合调用固定计费（含重复检索）	免费层 API + OpenRouter Qwen3-30B 按量付费
典型月成本	$30-$ 100+（每几天 $10）	接近零（免费层 + 分钱级 token 费）
检索来源	Perplexity 后端自有索引（不透明）	SearXNG 元搜索 + Tavily + LinkUp（三路 RRF 融合，完全透明）
综合模型	Perplexity 自有模型（不可选）	Qwen3-30B-A3B-Thinking-2507（可换任意 OpenRouter 模型 / 本地 vLLM）
学术搜索	受限于 Perplexity 索引	arXiv / SSRN / BibTeX 原生 API，零 token 零成本
引用透明度	Perplexity 自动生成（不可审计）	claim-to-evidence 引用绑定，每个断言可溯源到具体来源段落
矛盾检测	无	PaperQA2 风格矛盾检测，冲突来源显式标注
质量门控	无（黑箱输出）	CRAG 质量门控，低质量检索结果被过滤/重查

五层架构总览

Gigaxity 不是一个单一的 MCP 服务器——它是一个由 7 个 MCP 服务器 + SearXNG 元搜索后端 + OpenRouter 综合模型 + bundled skill 组成的完整研究栈。以下是五层架构：

Agent 层

Hermes / Claude Code / Cursor / Codex / Continue.dev + research-workflow skill（路由查询到正确流程）

↓ MCP stdio

编排器层

gigaxity-deep-research（6 工具：search / research / ask / discover / synthesize / reason）
RRF 融合 · CRAG 门控 · 引用绑定 · 矛盾检测

↓ 调用

Triple Stack

context7（库/API 文档）+ exa（网页搜索 + 代码上下文）+ jina【自托管】（网页 + arXiv/SSRN/BibTeX + URL reader + reranking）

↓ 伴生 + 社交

伴生 / 社交

exa-answer（1-2 秒快速事实查询）+ brightdata_fallback（CAPTCHA/付费墙/Cloudflare 最后手段）+ gptr-mcp（Reddit/X/YouTube 社交优先搜索）

↓ 底层后端

后端层

SearXNG 元搜索（Docker，分层引擎）+ Tavily API + LinkUp API + OpenRouter Qwen3-30B-A3B-Thinking-2507（综合模型）

↓ 持久化

持久化层

.env 配置文件 · SearXNG settings.yml（分层引擎权重）· research-workflow SKILL.md · 本地模型权重（可选，local-inference 分支）

7 个 MCP 服务器职责拆解

Gigaxity 的核心设计哲学是编排器 + Triple Stack + 伴生 + 社交的四层分工。不是所有 MCP 服务器都同等重要——编排器是大脑，Triple Stack 是检索引擎，伴生是补丁，社交是扩展。

#	MCP 服务器	角色	职责	关键特性
1	gigaxity-deep-research	编排器	6 工具：search/research/ask/discover/synthesize/reason	RRF 融合 + 引用绑定 + 矛盾检测 + CRAG 门控
2	context7	Triple Stack ①	库/API 文档查询（resolve-library-id → query-docs）	免费层覆盖常规文档查询
3	exa	Triple Stack ②	网页搜索 + 代码上下文 + 分类过滤	免费试用 credits，耗尽后轮换
4	jina【自托管】	Triple Stack ③	网页搜索 + arXiv/SSRN/BibTeX 学术搜索 + URL reader + reranking	10M token 免费层，必须自托管（官方路由到付费端）
5	exa-answer	伴生	1-2 秒快速事实查询	极速响应，适合简单问答
6	brightdata_fallback	伴生	CAPTCHA/付费墙/Cloudflare 被封锁 URL 的最后手段	月免费层，仅 ~5-15% 被封锁 URL 触发
7	gptr-mcp	社交	GPT Researcher MCP 包装器，Reddit/X/YouTube 社交优先搜索	社交信号优先检索

关键陷阱：Jina 必须自托管

不要用 jina 的官方 MCP 服务器——官方 MCP 会把请求路由到付费的 svip.jina.ai 端点，你的 10M token 免费层完全用不上。必须使用自托管版本，才能命中免费层。这是 @dre108 在文档中反复强调的第一大坑。

Triple Stack 概念：检索层的三角支撑

context7 + exa + jina 三个 MCP 服务器构成了 Gigaxity 的"Triple Stack"——检索/文档/代码获取层的三角支撑。三者各有侧重，互为补充：

MCP	强项	互补场景
context7	精确的库/API 文档查询（resolve-library-id → query-docs 两步走）	当 agent 需要查特定库的 API 签名、用法示例时，context7 比 exa/jina 更精准
exa	网页搜索 + 代码上下文 + 分类过滤	当需要搜索代码片段、技术博客、Stack Overflow 类内容时，exa 的代码语义理解更强
jina（自托管）	网页搜索 + arXiv/SSRN/BibTeX 学术搜索 + URL reader + reranking	当需要学术论文、预印本、研究报告时，jina 的 arXiv/SSRN 通道零 token 零成本；URL reader 可以读取任意网页全文

Triple Stack 的设计哲学是不把鸡蛋放在一个篮子里。每个检索源有不同的索引覆盖、不同的免费额度、不同的擅长领域。编排器的 RRF 融合算法把三者的结果合并排序，取各自优势的同时稀释各自的盲区。

编排器的 6 个工具：从 0 token 到 15K token 的谱系

gigaxity-deep-research 编排器暴露 6 个工具，覆盖从零成本原始搜索到高成本深度推理的完整谱系。理解每个工具的 token 消耗和适用场景，是控制成本的关键：

工具	功能	LLM 调用	典型 Token	适用场景
search	原始多源聚合（SearXNG + Tavily + LinkUp + RRF）	无	0 token	只需要原始链接列表，不要综合
research	组合管线（search + LLM 综合 + 引用）	有	~3K-8K	标准研究查询，一步到位
ask	快速对话式回答（直接 LLM，不搜索）	有	~500-1.5K	简单事实/概念问题
discover	探索性扩展（显式/隐式/相关/对比角度 + 空白检测）	有	~2K-5K	不知道该查什么时，先探索
synthesize	引用感知综合（CRAG 质量门控 + 矛盾标注）	有	~5K-10K	已有原始素材，需综合成报告
reason	深度综合（可选 CoT 深度控制）	有	~5K-15K	需要推理链的复杂问题

成本控制关键

search 工具是零 token 的——它只做 SearXNG + Tavily + LinkUp 三路聚合 + RRF 排序，完全不调用 LLM。这意味着你可以让 agent 先用 search 批量获取原始链接，再决定哪些值得用 synthesize 做深度综合。这种"先看目录再精读"的模式可以把成本压到极致。

PART 02

从零搭建教程 + 完整 Hermes 命令参考

第一步：获取 API 密钥

Gigaxity 依赖多个外部 API 的免费层。以下是所有需要获取的密钥及其免费层策略：

API	用途	免费层	获取地址
OpenRouter	综合模型 Qwen3-30B-A3B 推理	按量付费（分钱级/次）	openrouter.ai
Exa	网页搜索 + 代码上下文	免费试用 credits，耗尽后用新 Google 账号轮换	exa.ai
Jina	网页/学术搜索 + URL reader + reranking	10M token 免费层（必须自托管 MCP）	jina.ai
Context7	库/API 文档查询	免费层覆盖常规文档查询	context7.com
Brightdata	CAPTCHA/付费墙/Cloudflare 突破	月免费层，仅 ~5-15% 被封锁 URL 触发	brightdata.com
Tavily	搜索 API（SearXNG 聚合源之一）	免费层	tavily.com
TwitterAPI.io	X/Twitter 社交搜索（gptr-mcp 用）	免费层	twitterapi.io

第二步：克隆并安装 gigaxity-deep-research

# ═══ 克隆仓库 ═══
git clone https://github.com/yoloshii/gigaxity-deep-research.git
cd gigaxity-deep-research
# ═══ 创建 Python 虚拟环境 ═══
python -m venv venv
source venv/bin/activate # Linux/macOS
# venv\Scripts\activate # Windows
# ═══ 安装依赖 ═══
pip install -r requirements.txt
# ═══ 复制环境变量模板 ═══
cp .env.example .env
# 编辑 .env，填入你的 API 密钥（见下方完整模板）
# ═══ 验证安装：启动 MCP 服务器（stdio 模式）═══
python run_mcp.py
# 应输出 "Gigaxity MCP server started (stdio mode)" 无报错
# ═══ 验证 REST API（可选）═══
python src/main.py
# 启动 FastAPI 服务，访问 http://localhost:8000/api/v1/health

第三步：部署 SearXNG 元搜索后端

SearXNG 是 Gigaxity 搜索层的核心后端——一个自托管的元搜索引擎，可以同时查询 brave、wikipedia、mojeek、bing、duckduckgo 等数十个搜索引擎，然后聚合结果。Gigaxity 的编排器通过 SearXNG 的 JSON API 获取聚合搜索结果。

# ═══ Docker 部署 SearXNG ═══
docker run -d \
--name searxng \
-p 8080:8080 \
-v ./searxng-settings.yml:/etc/searxng/settings.yml:ro \
-e SEARXNG_BASE_URL=http://localhost:8080/ \
searxng/searxng:latest
# ═══ 验证 SearXNG JSON API 是否可用 ═══
curl "http://localhost:8080/search?q=test&format=json"
# 必须返回 JSON，如果返回 HTML 说明 JSON 格式未启用（见坑 #1）

坑 #1：SearXNG JSON 格式必须显式启用

SearXNG 默认只输出 HTML，不输出 JSON。你必须在 settings.yml 的 search: 段下显式添加 formats: [html, json]，否则 Gigaxity 的所有搜索调用都会收到 HTML 而非 JSON，编排器解析失败。这是复刻时第一个踩的坑。

完整的 SearXNG settings.yml（分层引擎配置）

@dre108 精心设计了分层引擎权重策略，确保高质量引擎优先、低质量引擎兜底、有问题的引擎禁用：

# ═══ searxng-settings.yml — Gigaxity 分层引擎配置 ═══
use_default_settings: true
search:
formats: [html, json] # 关键：必须显式启用 JSON，否则 API 返回 HTML
safe_search: 0
autocomplete: ""
default_lang: "en"
server:
secret_key: "你的随机密钥"
bind_address: "0.0.0.0"
port: 8080
engines:
# ── Tier 1 PRIMARY（权重 5）：高质量引擎，优先信任 ──
- name: brave
engine: brave
weight: 5
disabled: false
- name: wikipedia
engine: wikipedia
weight: 5
disabled: false
- name: mojeek
engine: mojeek
weight: 5
disabled: false
# ── Tier 2 SECONDARY（权重 3）：补充引擎 ──
- name: bing
engine: bing
weight: 3
disabled: false
- name: duckduckgo
engine: duckduckgo
weight: 3
disabled: false
- name: startpage
engine: startpage
weight: 3
disabled: false
# ── SPECIALIZED：专用引擎 ──
- name: wolframalpha
engine: wolframalpha
weight: 4
disabled: false
- name: reddit
engine: reddit
weight: 3
disabled: false
- name: youtube
engine: youtube
weight: 2
disabled: false
- name: arxiv
engine: arxiv
weight: 4
disabled: false
- name: google scholar
engine: google_scholar
weight: 4
disabled: false
# ── TECHNICAL：技术搜索引擎 ──
- name: github
engine: github
weight: 4
disabled: false
- name: stackoverflow
engine: stackoverflow
weight: 4
disabled: false
# ── DISABLED：有问题的引擎，必须禁用 ──
- name: google
engine: google
disabled: true # CAPTCHA 频繁触发，不可用
- name: google news
engine: google_news
disabled: true # 接口损坏
- name: yandex
engine: yandex
disabled: true # 地域限制 + 质量不稳定

第四步：配置 7 个 MCP 服务器

以下是在 Hermes / Claude Code / Cursor 等 MCP 兼容 harness 中的完整配置。以 Hermes 的 mcp_servers 配置为例（JSON 格式通用）：

// ═══ Hermes / Claude Code mcp_servers 配置（7 个 MCP 服务器）═══
{
"mcp_servers": {
// ① 编排器：6 工具，RRF 融合 + 引用绑定 + 矛盾检测
"gigaxity-deep-research": {
"command": "python",
"args": ["/path/to/gigaxity-deep-research/run_mcp.py"],
"env": {
"RESEARCH_SEARXNG_HOST": "http://localhost:8080",
"RESEARCH_SEARXNG_ENGINES": "brave,wikipedia,mojeek,bing,duckduckgo",
"RESEARCH_LLM_API_BASE": "https://openrouter.ai/api/v1",
"RESEARCH_LLM_API_KEY": "sk-or-v1-你的OpenRouter密钥",
"RESEARCH_LLM_MODEL": "qwen/qwen3-30b-a3b-thinking-2507",
"RESEARCH_LLM_TEMPERATURE": "0.3",
"RESEARCH_LLM_TOP_P": "0.9",
"RESEARCH_LLM_MAX_TOKENS": "4096",
"RESEARCH_LLM_TIMEOUT": "120"
}
},
// ② Triple Stack 1：库/API 文档查询
"context7": {
"command": "npx",
"args": ["-y", "@context7/mcp-server"],
"env": {
"CONTEXT7_API_KEY": "你的Context7密钥"
}
},
// ③ Triple Stack 2：网页搜索 + 代码上下文
"exa": {
"command": "npx",
"args": ["-y", "exa-mcp-server"],
"env": {
"EXA_API_KEY": "你的Exa密钥"
}
},
// ④ Triple Stack 3：自托管 Jina（不是官方 MCP！）
"jina": {
"command": "npx",
"args": ["-y", "jina-mcp-server-selfhosted"],
"env": {
"JINA_API_KEY": "你的Jina密钥",
"JINA_BASE_URL": "https://api.jina.ai"
}
},
// ⑤ 伴生：1-2 秒快速事实查询
"exa-answer": {
"command": "npx",
"args": ["-y", "exa-answer-mcp"],
"env": {
"EXA_API_KEY": "你的Exa密钥"
}
},
// ⑥ 伴生：CAPTCHA/付费墙/Cloudflare 最后手段
"brightdata_fallback": {
"command": "npx",
"args": ["-y", "brightdata-mcp"],
"env": {
"BRIGHTDATA_TOKEN": "你的Brightdata令牌"
}
},
// ⑦ 社交：Reddit/X/YouTube 社交优先搜索
"gptr-mcp": {
"command": "npx",
"args": ["-y", "gpt-researcher-mcp"],
"env": {
"TWITTERAPI_KEY": "你的TwitterAPI密钥",
"TAVILY_API_KEY": "你的Tavily密钥"
}
}
}
}

坑 #2：Jina 必须用自托管版本

上面第 ④ 个 MCP 服务器用的是 jina-mcp-server-selfhosted，不是官方的 jina-mcp-server。官方 MCP 会把请求路由到付费的 svip.jina.ai 端点，你的 10M token 免费层完全用不上。自托管版本路由到 api.jina.ai，命中免费层。

第五步：安装 research-workflow skill

Gigaxity 在 skills/research-workflow/SKILL.md 中捆绑了一个 skill，它的作用是把 LLM 路由到正确的工具流程——不是所有查询都需要 synthesize，简单问题用 ask 就够了，探索性查询用 discover，需要推理的用 reason。skill 充当了查询类型到工具选择的智能路由层。

╔══════════════════════════════════════════════════════════╗
║ skills/research-workflow/SKILL.md ║
║ 职责：根据查询类型路由到正确的 Gigaxity 工具 ║
╚══════════════════════════════════════════════════════════╝
# Research Workflow Skill
## 查询类型路由规则
### 1. 简单事实/概念问题 → ask
- 特征：单个事实、定义、概念解释
- 示例："什么是 RRF 融合？"
- 工具：ask（直接 LLM，不搜索，~500-1.5K token）
### 2. 需要原始链接列表 → search
- 特征：只需要来源 URL，不需要综合
- 示例："找 5 篇关于 CRAG 的论文链接"
- 工具：search（0 token，纯检索聚合）
### 3. 标准研究查询 → research
- 特征：需要搜索 + 综合一步到位
- 示例："对比 vLLM 和 SGLang 的推理性能"
- 工具：research（~3K-8K token）
### 4. 探索性查询（不知道该查什么）→ discover
- 特征：开放式探索，需要多角度展开
- 示例："我想了解 MCP 生态的最新进展"
- 工具：discover（显式/隐式/相关/对比角度 + 空白检测，~2K-5K token）
### 5. 已有素材需综合 → synthesize
- 特征：agent 已经通过其他 MCP 收集了原始素材
- 示例："把以下 10 篇文章综合成一份带引用的报告"
- 工具：synthesize（CRAG 门控 + 矛盾检测，~5K-10K token）
### 6. 需要推理链的复杂问题 → reason
- 特征：多步推理、因果分析、假设检验
- 示例："分析 RRF 权重调整对长尾查询的影响机制"
- 工具：reason（可选 CoT 深度控制，~5K-15K token）
## 焦点模式（focus_modes）
- general：通用研究
- academic：学术论文优先（arXiv/SSRN/BibTeX）
- documentation：技术文档优先（context7）
- comparison：对比分析优先
- debugging：问题排查优先
- tutorial：教程优先
- news：新闻时事优先

第六步：用不同查询类型测试

# ═══ 测试 1：ask（快速事实，~500-1.5K token）═══
"用 gigaxity ask 查一下：什么是 Reciprocal Rank Fusion？"
# ═══ 测试 2：search（零 token 纯检索）═══
"用 gigaxity search 搜：CRAG corrective retrieval augmented generation 2024"
# ═══ 测试 3：discover（探索性扩展，~2K-5K token）═══
"用 gigaxity discover 探索：MCP 协议生态中有哪些值得关注的搜索类服务器"
# ═══ 测试 4：synthesize（引用感知综合，~5K-10K token）═══
"用 gigaxity synthesize：把 exa 和 jina 搜到的关于 Qwen3 架构的资料综合成报告"
# ═══ 测试 5：reason（深度推理，~5K-15K token）═══
"用 gigaxity reason：分析为什么 SearXNG 禁用 Google 引擎后整体搜索质量反而提升"
# ═══ 测试 6：REST API 直调（绕过 MCP）═══
curl -X POST http://localhost:8000/api/v1/search \
-H "Content-Type: application/json" \
-d '{"query": "RRF fusion algorithm", "max_results": 10}'
curl -X POST http://localhost:8000/api/v1/synthesize \
-H "Content-Type: application/json" \
-d '{"query": "vLLM vs SGLang", "focus_mode": "comparison"}'

第七步（可选）：本地推理分支

如果你有 24GB+ VRAM 的 GPU，可以切换到 local-inference 分支，用 vLLM/SGLang/llama.cpp 本地运行 Qwen3-30B，彻底消除 OpenRouter 的 token 费用：

# ═══ 切换到本地推理分支 ═══
git checkout local-inference
# ═══ 使用 vLLM 部署 Qwen3-30B-A3B ═══
pip install vllm
vllm serve Qwen/Qwen3-30B-A3B-Thinking-2507 \
--tensor-parallel-size 1 \
--gpu-memory-utilization 0.9 \
--max-model-len 32768 \
--port 8001
# ═══ 修改 .env 指向本地端点 ═══
# RESEARCH_LLM_API_BASE=http://localhost:8001/v1
# RESEARCH_LLM_API_KEY=not-needed
# RESEARCH_LLM_MODEL=Qwen/Qwen3-30B-A3B-Thinking-2507

坑 #7：本地推理需要 24GB VRAM 最低

Qwen3-30B-A3B 虽然是 MoE 架构（活跃参数仅 3B），但完整模型权重仍需约 60GB 存储。推理时需要至少 24GB VRAM 才能加载（取决于量化精度）。如果你只有 16GB 或更低的消费级 GPU，建议继续用 OpenRouter 按量付费——分钱级的 token 费远比硬件升级便宜。

完整命令参考表

命令 / 工具	类型	功能	Token 消耗
search	MCP 工具	SearXNG + Tavily + LinkUp 三路聚合 + RRF，无 LLM	0
research	MCP 工具	search + LLM 综合 + 引用，一步到位	~3K-8K
ask	MCP 工具	直接 LLM 回答，不搜索	~500-1.5K
discover	MCP 工具	探索性扩展 + 空白检测	~2K-5K
synthesize	MCP 工具	CRAG 门控 + 矛盾检测 + 引用绑定综合	~5K-10K
reason	MCP 工具	深度综合 + 可选 CoT 深度控制	~5K-15K
/api/v1/health	REST API	健康检查	0
/discover	REST API	探索性扩展	~2K-5K
/synthesize	REST API	引用感知综合	~5K-10K
/reason	REST API	深度推理综合	~5K-15K
/ask	REST API	快速问答	~500-1.5K
/research	REST API	组合研究管线	~3K-8K
/search	REST API	原始搜索聚合	0
/presets	REST API	查询预设模板列表	0
/focus-modes	REST API	焦点模式列表	0
run_mcp.py	启动命令	启动 MCP 服务器（stdio 模式）	—
src/main.py	启动命令	启动 REST API（FastAPI + uvicorn）	—

完整 .env.example 配置模板

# ═══ gigaxity-deep-research .env.example ═══
# ── SearXNG 元搜索后端 ──
RESEARCH_SEARXNG_HOST=http://localhost:8080
RESEARCH_SEARXNG_ENGINES=brave,wikipedia,mojeek,bing,duckduckgo,startpage
# ── LLM 综合模型（OpenRouter Qwen3-30B）──
RESEARCH_LLM_API_BASE=https://openrouter.ai/api/v1
RESEARCH_LLM_API_KEY=sk-or-v1-你的OpenRouter密钥
RESEARCH_LLM_MODEL=qwen/qwen3-30b-a3b-thinking-2507
RESEARCH_LLM_TEMPERATURE=0.3
RESEARCH_LLM_TOP_P=0.9
RESEARCH_LLM_MAX_TOKENS=4096
RESEARCH_LLM_TIMEOUT=120
# ── 本地推理模式（local-inference 分支）──
# RESEARCH_LLM_API_BASE=http://localhost:8001/v1
# RESEARCH_LLM_API_KEY=not-needed
# RESEARCH_LLM_MODEL=Qwen/Qwen3-30B-A3B-Thinking-2507
# ── Triple Stack API 密钥 ──
EXA_API_KEY=你的Exa密钥
JINA_API_KEY=你的Jina密钥
CONTEXT7_API_KEY=你的Context7密钥
TAVILY_API_KEY=你的Tavily密钥
# ── 伴生 / 社交 API 密钥 ──
BRIGHTDATA_TOKEN=你的Brightdata令牌
TWITTERAPI_KEY=你的TwitterAPI密钥

免费层轮换策略

免费层终归会耗尽。@dre108 在 docs/guides/free-tier-strategy.md 中详细记录了每个 API 的免费层边界和轮换策略：

API	免费层边界	耗尽后策略	典型 Token 消耗
Jina	10M token / 免费层	自托管 MCP（路由到 api.jina.ai 而非 svip.jina.ai）	search_web ~63 token；parallel_search_web ~107 token（3 查询）；parallel_read_url ~17K token（内容正比）；学术搜索 0 token
Exa	免费试用 credits	用新 Google 账号注册新 Exa 账号，轮换 API key	取决于查询频率
Context7	免费层覆盖常规文档查询	无需轮换，免费层足够	resolve-library-id + query-docs 两步
Brightdata	月免费层	仅 ~5-15% 被封锁 URL 触发，月免费层足够	按解锁 URL 计
arXiv/SSRN/BibTeX	完全免费（原生 API，无需 key）	无需策略，永远免费	0 token（原生 API 调用）
SearXNG	自托管，无限制	无限制，但需注意上游引擎限频	0 token（本地 API）

学术搜索零成本

arXiv / SSRN / BibTeX 的搜索通过原生 API 调用，完全不消耗 token，不需要任何 API key。这意味着如果你做学术研究，Gigaxity 的学术搜索部分成本永远是零——这是 Perplexity API 永远无法提供的。

PART 03

源码深度解读 + 部署 + 复刻避坑总结

核心代码 ①：RRF（Reciprocal Rank Fusion）实现

RRF 是 Gigaxity 多源搜索融合的核心算法。当 SearXNG、Tavily、LinkUp 三个搜索源各自返回排序后的结果列表时，RRF 把它们融合成一个统一的排序列表——不依赖任何源的绝对分数，只依赖排名位置。这使得不同评分体系的搜索结果可以公平融合。

# ═══ src/connectors/rrf.py — Reciprocal Rank Fusion ═══
# 核心思想：不关心各搜索源的绝对分数，只关心排名位置
# 排名越靠前，贡献越大；贡献 = 1 / (k + rank)，k 通常取 60
from collections import defaultdict
# RRF 超参数 k：控制排名衰减速度
# k 越大，低排名结果衰减越慢（更平滑）；k 越小，头部结果优势越明显
RRF_K = 60
def reciprocal_rank_fusion(result_lists, weights=None, k=RRF_K):
"""
多源搜索结果融合（RRF 算法）
参数:
result_lists: List[List[dict]] — 多个搜索源的结果列表
每个列表内部已按相关性排序（排名 0 = 最相关）
weights: List[float] — 各源的权重（如 SearXNG 权重 1.0，Tavily 0.8）
k: int — RRF 超参数，控制排名衰减
返回:
List[dict] — 融合后的统一排序列表
"""
if weights is None:
weights = [1.0] * len(result_lists) # 默认等权
# ── 累积每个 URL 的 RRF 分数 ──
rrf_scores = defaultdict(float)
# ── 记录每个 URL 的来源（用于引用绑定）──
url_sources = defaultdict(list)
for source_idx, results in enumerate(result_lists):
weight = weights[source_idx]
for rank, item in enumerate(results):
url = item.get("url", "")
if not url:
continue
# ── RRF 核心公式：score = weight * 1 / (k + rank) ──
# rank 从 0 开始，所以第 1 名的分数 = 1/(60+0) = 1/60 ≈ 0.0167
# 第 61 名的分数 = 1/(60+60) = 1/120 ≈ 0.0083（衰减一半）
rrf_scores[url] += weight * (1.0 / (k + rank))
# ── 记录来源信息（同一条结果可能被多个源返回）──
url_sources[url].append({
"source": source_idx,
"rank": rank,
"title": item.get("title", ""),
"snippet": item.get("snippet", ""),
})
# ── 按 RRF 分数降序排列 ──
# 多个源都返回的 URL 分数更高（累积效应），自然排到前面
sorted_urls = sorted(rrf_scores.items(), key=lambda x: -x[1])
# ── 构造融合后的结果列表 ──
fused_results = []
for url, score in sorted_urls:
sources = url_sources[url]
# 取第一个出现的标题和摘要（也可以做去重/合并）
first = sources[0]
fused_results.append({
"url": url,
"title": first["title"],
"snippet": first["snippet"],
"rrf_score": round(score, 6),
"source_count": len(sources), # 被几个源返回
"sources": sources, # 完整来源信息
})
return fused_results

RRF 为什么有效

RRF 的精妙之处在于不需要对齐不同搜索源的评分体系。SearXNG 的相关性分数和 Tavily 的 score 可能完全不可比，但它们的排名是可比的——排名第 1 就是第 1。RRF 只用排名位置，天然解决了跨源分数对齐问题。此外，RRF 的累积效应让"多源共识"自然浮现：如果一个 URL 被 SearXNG、Tavily、LinkUp 三个源都返回且都排在前面，它的 RRF 分数会是三者之和，自然排到融合列表的最前面。

核心代码 ②：CRAG 质量门控逻辑

CRAG（Corrective Retrieval-Augmented Generation）是 Gigaxity 的质量门控机制。不是所有检索结果都值得送入综合模型——低质量、不相关、内容过短的检索结果会"污染"综合输出。CRAG 在检索和综合之间插入了一道质量关卡。

# ═══ src/synthesis/crag.py — CRAG 质量门控 ═══
# 核心思想：检索结果分三档（相关/部分相关/不相关），不同档位不同处理
# 相关 → 直接用于综合
# 部分相关 → 提取有用部分 + 触发补充检索
# 不相关 → 丢弃 + 触发查询重写 + 重新检索
from enum import Enum
class CRAGVerdict(Enum):
RELEVANT = "relevant" # 高质量，直接用
PARTIAL = "partially_relevant" # 部分相关，提取 + 补查
IRRELEVANT = "irrelevant" # 不相关，丢弃 + 重查
# ── 质量评估阈值 ──
MIN_CONTENT_LENGTH = 200 # 内容最短长度（字符），低于此判定为低质量
MIN_RELEVANCE_SCORE = 0.5 # 相关性评分阈值（0-1）
MAX_RETRIEVAL_RETRIES = 3 # 不相关时最多重试重查次数
def crag_evaluate(query, retrieved_docs):
"""
CRAG 质量评估：对每条检索结果打分并分类
参数:
query: str — 原始查询
retrieved_docs: List[dict] — RRF 融合后的检索结果
返回:
dict — 包含 verdict, filtered_docs, retry_queries
"""
scored_docs = []
for doc in retrieved_docs:
content = doc.get("content", "")
snippet = doc.get("snippet", "")
# ── 规则 1：内容长度检查 ──
# 内容过短（< 200 字符）直接降级
content_len = len(content) if content else len(snippet)
if content_len < MIN_CONTENT_LENGTH:
doc["crag_score"] = 0.2
continue
# ── 规则 2：关键词覆盖率 ──
# 查询中的关键词在内容中出现的比例
query_terms = set(query.lower().split())
content_lower = (content or snippet).lower()
covered = sum(1 for t in query_terms if t in content_lower)
coverage = covered / len(query_terms) if query_terms else 0
# ── 规则 3：RRF 分数加成 ──
# RRF 分数高说明多源共识，给予质量加成
rrf_score = doc.get("rrf_score", 0)
source_count = doc.get("source_count", 1)
# ── 综合 CRAG 评分 ──
crag_score = (
coverage * 0.4 + # 关键词覆盖率权重 40%
min(rrf_score * 10, 0.3) + # RRF 分数权重 30%（截断）
min(source_count / 3, 0.3) # 多源共识权重 30%
)
doc["crag_score"] = round(crag_score, 3)
scored_docs.append(doc)
# ── 整体质量判定 ──
if not scored_docs:
return {"verdict": CRAGVerdict.IRRELEVANT, "filtered_docs": [], "retry": True}
avg_score = sum(d["crag_score"] for d in scored_docs) / len(scored_docs)
if avg_score >= MIN_RELEVANCE_SCORE:
# ── 相关：全部保留，直接送综合 ──
verdict = CRAGVerdict.RELEVANT
filtered = scored_docs
retry = False
elif avg_score >= 0.3:
# ── 部分相关：保留高分文档 + 触发补充检索 ──
verdict = CRAGVerdict.PARTIAL
filtered = [d for d in scored_docs if d["crag_score"] >= 0.4]
retry = True
else:
# ── 不相关：全部丢弃 + 触发查询重写 + 重查 ──
verdict = CRAGVerdict.IRRELEVANT
filtered = []
retry = True
return {
"verdict": verdict,
"filtered_docs": filtered,
"retry": retry,
"avg_score": round(avg_score, 3),
}

核心代码 ③：引用绑定（Claim-to-Evidence Mapping）

引用绑定是 Gigaxity 区别于 Perplexity 黑箱综合的核心特性。Perplexity 给你一个带引用编号的回答，但你无法验证编号 [3] 到底对应来源的哪一段。Gigaxity 的引用绑定是claim-to-evidence 粒度——每个断言都映射到具体来源的具体段落。

# ═══ src/synthesis/citation.py — 引用绑定 ═══
# 核心思想：综合输出中的每个 claim（断言）都必须绑定到具体来源的具体段落
# 不是笼统的"来源 [3]"，而是"来源 [3] 的第 2 段，原文：'...'"
import re
def bind_citations(synthesis_text, source_docs):
"""
引用绑定：把综合文本中的 [N] 标记映射到具体来源段落
参数:
synthesis_text: str — LLM 生成的综合文本（含 [N] 引用标记）
source_docs: List[dict] — 检索到的来源文档（含 url, title, content）
返回:
dict — 包含 claims 列表，每个 claim 绑定到具体来源段落
"""
# ── 1. 按句子切分综合文本 ──
# 每个"句子级 claim"可能包含一个或多个引用标记
sentences = re.split(r'(?<=[.!?])\s+', synthesis_text)
claims = []
for sent_idx, sentence in enumerate(sentences):
# ── 2. 提取句子中的所有 [N] 引用标记 ──
citations = re.findall(r'\[(\d+)\]', sentence)
if not citations:
# ── 无引用的句子标记为"无来源支撑"──
claims.append({
"claim_id": sent_idx,
"text": sentence.strip(),
"citations": [],
"ungrounded": True, # 未落地，需人工审查
})
continue
# ── 3. 每个引用标记映射到具体来源文档 ──
bound_citations = []
for cite_num in citations:
doc_idx = int(cite_num) - 1 # [1] → index 0
if doc_idx < len(source_docs):
doc = source_docs[doc_idx]
# ── 4. 在来源文档中找到最匹配的段落 ──
# 用句子级关键词匹配定位到具体段落
matched_passage = find_best_passage(sentence, doc.get("content", ""))
bound_citations.append({
"ref_num": int(cite_num),
"url": doc.get("url", ""),
"title": doc.get("title", ""),
"passage": matched_passage, # 具体段落原文
"passage_score": passage_similarity(sentence, matched_passage),
})
claims.append({
"claim_id": sent_idx,
"text": sentence.strip(),
"citations": bound_citations,
"ungrounded": False,
})
return {"claims": claims, "total_claims": len(claims),
"grounded_claims": sum(1 for c in claims if not c["ungrounded"])}
def find_best_passage(claim_text, doc_content, passage_len=200):
"""在来源文档中找到与 claim 最匹配的段落（滑动窗口）"""
if not doc_content:
return ""
claim_terms = set(claim_text.lower().split())
best_score = 0
best_passage = ""
# ── 滑动窗口：每 passage_len 字符一个窗口 ──
for i in range(0, len(doc_content), passage_len // 2):
passage = doc_content[i:i + passage_len]
passage_terms = set(passage.lower().split())
# ── Jaccard 相似度 ──
intersection = len(claim_terms & passage_terms)
union = len(claim_terms | passage_terms)
score = intersection / union if union > 0 else 0
if score > best_score:
best_score = score
best_passage = passage
return best_passage.strip()

核心代码 ④：矛盾检测（PaperQA2 风格）

当多个来源对同一事实给出相互冲突的信息时，Gigaxity 会显式标注矛盾——而不是像 Perplexity 那样静默选择一个来源。这种 PaperQA2 风格的矛盾检测在学术研究和竞品分析中极其重要。

# ═══ src/synthesis/contradiction.py — 矛盾检测（PaperQA2 风格）═══
# 核心思想：检测不同来源对同一事实的陈述是否相互冲突
# 冲突不自动消除——而是显式标注，让用户知道信息存在分歧
def detect_contradictions(claims_with_citations):
"""
矛盾检测：扫描所有 claim，找出相互冲突的事实陈述
参数:
claims_with_citations: List[dict] — 引用绑定后的 claims
返回:
List[dict] — 检测到的矛盾对
"""
contradictions = []
# ── 1. 提取含数值/比较级/否定词的 claim（矛盾高发区）──
# 矛盾通常出现在：数值差异、比较结论相反、否定 vs 肯定
numeric_pattern = re.compile(r'\d+\.?\d*')
comparative_pattern = re.compile(r'(better|worse|faster|slower|higher|lower|more|less)',
re.IGNORECASE)
negation_pattern = re.compile(r'\b(not|no|never|cannot|doesn\'t|isn\'t|aren\'t)\b',
re.IGNORECASE)
# ── 2. 两两比较 claim，检测矛盾 ──
for i, claim_a in enumerate(claims_with_citations):
for j, claim_b in enumerate(claims_with_citations[i+1:], i+1):
# ── 跳过无引用的 claim ──
if not claim_a["citations"] or not claim_b["citations"]:
continue
# ── 同一来源的 claim 不算矛盾 ──
sources_a = {c["url"] for c in claim_a["citations"]}
sources_b = {c["url"] for c in claim_b["citations"]}
if sources_a & sources_b:
continue # 有共同来源，可能是在补充而非矛盾
# ── 3. 检测数值矛盾 ──
# 两个 claim 讨论同一话题但数值不同
nums_a = numeric_pattern.findall(claim_a["text"])
nums_b = numeric_pattern.findall(claim_b["text"])
if nums_a and nums_b and is_same_topic(claim_a["text"], claim_b["text"]):
if set(nums_a) != set(nums_b):
contradictions.append({
"type": "numeric_conflict",
"claim_a": claim_a,
"claim_b": claim_b,
"detail": f"数值冲突：{nums_a} vs {nums_b}",
})
# ── 4. 检测比较级矛盾 ──
# "A is better than B" vs "B is better than A"
comp_a = comparative_pattern.search(claim_a["text"])
comp_b = comparative_pattern.search(claim_b["text"])
if comp_a and comp_b and is_same_topic(claim_a["text"], claim_b["text"]):
if is_opposite_comparison(comp_a.group(), comp_b.group()):
contradictions.append({
"type": "comparative_conflict",
"claim_a": claim_a,
"claim_b": claim_b,
"detail": f"比较结论相反：{comp_a.group()} vs {comp_b.group()}",
})
# ── 5. 检测否定矛盾 ──
# "X is true" vs "X is not true"
neg_a = negation_pattern.search(claim_a["text"])
neg_b = negation_pattern.search(claim_b["text"])
if neg_a and not neg_b and is_same_topic(claim_a["text"], claim_b["text"]):
contradictions.append({
"type": "negation_conflict",
"claim_a": claim_a,
"claim_b": claim_b,
"detail": "肯定 vs 否定",
})
return contradictions

核心代码 ⑤：自适应查询路由 + HyDE 查询扩展

不是所有查询都适合直接送进搜索引擎。Gigaxity 的自适应路由会根据查询特征决定是否需要查询分解、HyDE（Hypothetical Document Embeddings）扩展或直接检索。

# ═══ src/discovery/router.py — 自适应查询路由 ═══
# 核心思想：查询复杂度决定路由策略
# 简单查询 → 直接搜索（省 token）
# 复杂查询 → 分解子查询 + HyDE 扩展（提高召回率）
def route_query(query, focus_mode="general"):
"""
自适应查询路由：根据查询特征选择检索策略
"""
# ── 1. 查询复杂度评估 ──
word_count = len(query.split())
has_question = "?" in query
has_comparison = any(w in query.lower()
for w in ["vs", "versus", "compare", "difference", "对比"])
has_multiple_aspects = any(w in query.lower()
for w in ["and", "also", "as well as", "此外"])
# ── 2. 路由决策 ──
if word_count <= 5 and not has_comparison:
# ── 简单查询：直接搜索，不扩展 ──
return {"strategy": "direct", "queries": [query]}
elif has_comparison or has_multiple_aspects:
# ── 复杂查询：分解为子查询 ──
# "对比 vLLM 和 SGLang" → ["vLLM 特性", "SGLang 特性", "vLLM vs SGLang"]
sub_queries = decompose_query(query)
return {"strategy": "decompose", "queries": sub_queries}
elif focus_mode == "academic":
# ── 学术模式：HyDE 扩展 ──
# 生成假设性文档，用文档内容做语义检索（提高学术论文召回率）
hyde_doc = generate_hyde_document(query)
expanded = extract_search_terms(hyde_doc)
return {"strategy": "hyde", "queries": [query] + expanded}
else:
# ── 默认：直接 + 相关词扩展 ──
related = expand_with_related_terms(query)
return {"strategy": "expand", "queries": [query] + related}
def generate_hyde_document(query):
"""HyDE：让 LLM 生成一个假设性的回答文档，用该文档做语义检索"""
# HyDE 的直觉：假设性回答比原始查询更接近目标文档的语义空间
# 因为目标文档本身就是"回答"，而查询是"问题"
prompt = f"请写一段 200 字的假设性回答，回答以下问题：{query}"
# 调用 LLM 生成假设文档（消耗少量 token，但大幅提高召回率）
hyde_doc = llm_client.complete(prompt, max_tokens=300)
return hyde_doc

核心代码 ⑥：SearXNG JSON API 集成

# ═══ src/connectors/searxng.py — SearXNG JSON API 客户端 ═══
# 核心职责：调用 SearXNG 的 /search?format=json 端点，获取聚合搜索结果
import httpx
import os
class SearXNGClient:
def __init__(self):
self.host = os.getenv("RESEARCH_SEARXNG_HOST", "http://localhost:8080")
self.engines = os.getenv("RESEARCH_SEARXNG_ENGINES", "")
async def search(self, query, max_results=15):
"""调用 SearXNG JSON API 搜索"""
params = {
"q": query,
"format": "json", # 关键：必须指定 json 格式
"pageno": 1,
"safesearch": 0,
}
if self.engines:
params["engines"] = self.engines
async with httpx.AsyncClient(timeout=30) as client:
resp = await client.get(
f"{self.host}/search",
params=params
)
resp.raise_for_status()
data = resp.json()
# ── 解析 SearXNG JSON 结果 ──
results = []
for item in data.get("results", [])[:max_results]:
results.append({
"url": item.get("url", ""),
"title": item.get("title", ""),
"snippet": item.get("content", ""),
"engine": item.get("engine", ""),
"score": item.get("score", 0),
})
return results

架构路径全景

理解 Gigaxity 的代码组织，从入口到核心模块的完整调用链：

路径	角色	说明
run_mcp.py	MCP 入口	启动 FastMCP 服务器（stdio 模式），加载 6 个工具
src/mcp_server.py	MCP 服务器	FastMCP 框架，定义 6 个工具的 schema 和 handler
src/main.py	REST API 入口	FastAPI + uvicorn，暴露 /api/v1/* REST 端点
src/api/routes.py	API 路由	定义 /search /research /ask /discover /synthesize /reason /presets /focus-modes /health 端点
src/llm_client.py	LLM 客户端	OpenAI 兼容客户端，连接 OpenRouter / 本地 vLLM
src/discovery/	发现模块	查询路由、HyDE 扩展、查询分解、探索性角度生成
src/synthesis/	综合模块	CRAG 门控、引用绑定、矛盾检测、大纲引导综合
src/connectors/	连接器模块	SearXNG 客户端、Tavily 客户端、LinkUp 客户端、RRF 融合
src/config.py	配置	从 .env 加载所有环境变量，校验必填项
skills/research-workflow/SKILL.md	Bundled Skill	查询类型到工具的路由规则

成本优化分析：Token / 成本逐工具拆解

以下是每个工具在一次典型调用中的 token 消耗和对应成本（基于 OpenRouter Qwen3-30B-A3B 定价估算）：

工具	Input Token	Output Token	LLM 调用	单次成本估算	月成本（100 次/月）
search	0	0	无	$0.000	$0.00
ask	~500-1.5K	~200-500	1 次	~$0.001	~$0.10
discover	~2K-5K	~500-1K	1-2 次	~$0.003	~$0.30
research	~3K-8K	~1K-2K	1-2 次	~$0.005	~$0.50
synthesize	~5K-10K	~2K-4K	1-2 次	~$0.010	~$1.00
reason	~5K-15K	~2K-4K	2-3 次（含 CoT）	~$0.015	~$1.50
Gigaxity 月总成本（混合使用）	~ $1-$ 3
Perplexity API 月成本（对比）	$30-$ 100+

成本节省 90%+

混合使用 6 个工具、每月 100 次调用的场景下，Gigaxity 月成本约 $1-$ 3，而 Perplexity API 约需 $30-$ 100+。成本节省超过 90%。如果大量使用零 token 的 search 工具做原始检索，成本还能进一步压低。学术搜索走 arXiv/SSRN 原生 API，永远是零成本。

复刻检查清单

获取 OpenRouter API key（用于 Qwen3-30B 综合模型）
获取 Exa API key（免费试用 credits）
获取 Jina API key（10M token 免费层）
获取 Context7 API key（免费层）
获取 Brightdata token（月免费层）
获取 Tavily API key（免费层）
获取 TwitterAPI.io key（gptr-mcp 社交搜索用）
克隆 gigaxity-deep-research 仓库，创建 Python venv，安装依赖
Docker 部署 SearXNG，挂载自定义 settings.yml
确认 SearXNG settings.yml 中 formats: [html, json] 已启用
确认 SearXNG JSON API 可用：curl 返回 JSON 而非 HTML
配置 .env 文件，填入所有 API 密钥和 SearXNG host
在 Hermes / Claude Code 配置中添加 7 个 MCP 服务器
确认 Jina MCP 使用自托管版本（非官方 MCP）
安装 research-workflow skill
测试 ask / search / discover / synthesize / reason 五种查询
验证 REST API 端点 /api/v1/health 返回正常
（可选）如有 24GB+ VRAM GPU，切换 local-inference 分支部署 vLLM

复刻避坑总结

坑 #1：SearXNG JSON 格式必须显式启用

SearXNG 默认只输出 HTML。必须在 settings.yml 的 search: 段下添加 formats: [html, json]，否则 Gigaxity 的所有搜索调用都会收到 HTML 解析失败。症状：search 工具返回空结果或报错，但 SearXNG Web 界面正常。诊断：curl "http://localhost:8080/search?q=test&format=json" 如果返回 HTML 而非 JSON，就是这个坑。

坑 #2：Jina 必须自托管，官方 MCP 路由到付费端

Jina 官方 MCP 服务器会把请求路由到 svip.jina.ai（付费端点），你的 10M token 免费层完全用不上。必须使用自托管版本，路由到 api.jina.ai，才能命中免费层。症状：Jina 调用正常但 API 账单持续增长。诊断：检查 MCP 配置中 Jina 的包名是否为 jina-mcp-server-selfhosted 而非 jina-mcp-server。

坑 #3：Exa 免费 credits 耗尽，需轮换策略

Exa 的免费试用 credits 会在高频使用下耗尽。策略：用新 Google 账号注册新 Exa 账号，轮换 API key。建议在 .env 中将 Exa key 设为可快速替换的变量，或写一个简单的 key 轮换脚本。症状：exa 工具返回 401/403 或 quota exceeded。

坑 #4：OpenRouter Qwen3-30B 模型迁移

从 v0.3.6 迁移到当前版本时，Qwen3-30B 的模型 ID 在 OpenRouter 上有变更。旧 ID qwen/qwen3-30b-a3b 可能已弃用，新 ID 为 qwen/qwen3-30b-a3b-thinking-2507。症状：LLM 调用返回 model not found。解决：更新 .env 中的 RESEARCH_LLM_MODEL 为最新 ID。

坑 #5：SearXNG 中 Google 引擎必须禁用

Google 搜索引擎在 SearXNG 中会频繁触发 CAPTCHA，导致搜索请求被阻断。必须在 settings.yml 中将 google 引擎设为 disabled: true。同理，google news（接口损坏）和 yandex（地域限制 + 质量不稳定）也应禁用。替代方案：用 brave + mojeek + bing + duckduckgo 覆盖 Google 的搜索覆盖面。

坑 #6：brightdata 仅用于 ~5-15% 被封锁 URL

brightdata_fallback 不是常规搜索工具——它只在 Triple Stack 遇到 CAPTCHA/付费墙/Cloudflare 阻断时作为最后手段触发。不要把 brightdata 作为主要搜索源，月免费层很快耗尽。正确的使用方式是：Triple Stack 先尝试 → 失败的 URL 才走 brightdata。

坑 #7：本地推理需要 24GB VRAM 最低

local-inference 分支用 vLLM/SGLang/llama.cpp 本地运行 Qwen3-30B-A3B。虽然 MoE 架构活跃参数仅 3B，但完整权重仍需约 60GB 存储，推理需 24GB VRAM 最低。消费级 GPU（16GB 或更低）无法运行，建议继续用 OpenRouter 按量付费。

结尾：拓展方向

Gigaxity 的 7-MCP 架构天然支持扩展——每增加一个 MCP 服务器就能扩展一种新的检索能力或综合策略：

添加自定义 MCP 多模型综合投票实时新闻监控 OSINT 工具包多语言检索本地知识库 RAG 企业内部文档搜索

最直接的拓展是添加自定义 MCP——如果你有特定领域的数据源（如专利数据库、企业内部 wiki、私有 API），只需写一个 MCP 服务器包装它，然后在编排器的 RRF 融合中加入这个新源。其次是多模型综合投票——让多个 LLM 各自独立综合同一批素材，然后投票/交叉验证产出最终报告，进一步提高综合质量和减少单一模型的幻觉。第三是实时新闻监控——把 gptr-mcp 的社交搜索能力扩展到 RSS/Atom 订阅 + 定时轮询，构建一个 24/7 运行的事件追踪 agent。

@dre108 本人在 Gigaxity 之外还有多个 agent 生态项目：ClawMem（agent 记忆系统）、better-browser-use（浏览器自动化增强）、ultimate-scraper（通用爬虫）、humanizer-pro（文本人性化处理）。这些项目与 Gigaxity 组合可以构建更完整的 agent 工具链——ClawMem 让 agent 跨会话记住研究结论，ultimate-scraper 补充 SearXNG 无法覆盖的动态页面，humanizer-pro 让综合报告读起来更像人类写作。

本篇核心启示

@dre108 的 Gigaxity 不仅仅是一个"省钱工具"——它用 7 个 MCP 服务器 + RRF 融合 + CRAG 门控 + 引用绑定 + 矛盾检测，把"研究综合"从 Perplexity 的闭源黑箱中拆解成了一个每一步都透明、可追溯、可审计的流水线。成本从 $10/几天降到接近零只是表象；真正的价值在于把综合过程的控制权从 API 提供商手中夺回到用户手中——你可以看到每条断言的来源段落，可以看到哪些来源相互矛盾，可以决定用哪个模型做综合，可以决定检索哪些源。这是 agent 时代"可审计研究"的范式样本。

溯源引用

@dre108 (yoloshii), Gigaxity Deep Research GitHub 仓库。7 MCP 服务器自托管研究栈，RRF 融合 + CRAG 门控 + 引用绑定 + 矛盾检测。MIT 协议，v0.6.4，37 commits。2026-05-05. github.com/yoloshii/gi…
@dre108, "Gigaxity — low cost research stack" — Nous Discord 原始帖子。作者自述搭建动机：受够了 Perplexity API 每几天 $10 的综合调用成本。2026-05-06. github.com/teknium1/no…
Nous Research, Hermes Agent 官方用户故事页面。@dre108 的 Gigaxity Deep Research 被收录为社区用户故事。 hermes-agent.nousresearch.com/docs/user-s…
@dre108, gigaxity-deep-research run_mcp.py / src/mcp_server.py — FastMCP 编排器入口。6 工具（search/research/ask/discover/synthesize/reason），stdio 模式。 github.com/yoloshii/gi…
@dre108, gigaxity-deep-research src/connectors/ — RRF 融合 + SearXNG/Tavily/LinkUp 连接器。Reciprocal Rank Fusion 多源搜索结果合并。 github.com/yoloshii/gi…
@dre108, gigaxity-deep-research src/synthesis/ — CRAG 质量门控 + 引用绑定 + 矛盾检测 + 大纲引导综合。PaperQA2 风格矛盾标注。 github.com/yoloshii/gi…
@dre108, gigaxity-deep-research src/discovery/ — 自适应查询路由 + HyDE 查询扩展 + 查询分解 + 探索性角度生成。 github.com/yoloshii/gi…
@dre108, gigaxity-deep-research skills/research-workflow/SKILL.md — 查询类型到工具的路由 skill。ask/search/research/discover/synthesize/reason 六种查询类型路由规则。 github.com/yoloshii/gi…
@dre108, gigaxity-deep-research docs/guides/free-tier-strategy.md — 免费层轮换策略。Jina 10M token 免费层、Exa credits 轮换、Context7 免费层、arXiv/SSRN/BibTeX 零成本学术搜索。 github.com/yoloshii/gi…
@dre108, gigaxity-deep-research .env.example — 完整环境变量模板。RESEARCH_SEARXNG_HOST, RESEARCH_LLM_API_BASE, RESEARCH_LLM_MODEL 等全部变量。 github.com/yoloshii/gi…
SearXNG — 自托管元搜索引擎。Gigaxity 搜索层核心后端，支持分层引擎权重配置，JSON API 需显式启用 formats: [html, json]。 docs.searxng.org/
OpenRouter — LLM API 路由服务。Gigaxity 综合模型 Qwen3-30B-A3B-Thinking-2507 的推理后端，按量付费。 openrouter.ai/
Qwen3-30B-A3B — MoE 大语言模型。Gigaxity 默认综合模型，活跃参数 3B，总参数 30B。Thinking-2507 变体支持深度推理链。 qwenlm.github.io/
CRAG (Corrective Retrieval-Augmented Generation) — 检索质量门控方法。Gigaxity src/synthesis/crag.py 实现的三档质量评估（相关/部分相关/不相关）。 arxiv.org/abs/2401.15…
PaperQA2 — 学术问答系统，矛盾检测风格参考。Gigaxity src/synthesis/contradiction.py 实现的数值/比较级/否定矛盾检测受其启发。 github.com/Future-Hous…
FastMCP — Python MCP 服务器框架。gigaxity-deep-research 编排器基于 FastMCP，stdio 模式，6 工具定义。 github.com/jlowin/fast…
FastAPI — Python 异步 Web 框架。gigaxity-deep-research REST API 层基于 FastAPI + uvicorn，暴露 /api/v1/* 端点。 fastapi.tiangolo.com/
@dre108 (yoloshii) 其他项目：ClawMem（agent 记忆）、better-browser-use（浏览器自动化）、ultimate-scraper（通用爬虫）、humanizer-pro（文本人性化）。 github.com/yoloshii

Hermes Agent 深度拆解连载 · 第 09 篇 · @dre108 的 Gigaxity Deep Research 栈

溯源驱动 · 源码佐证 · 1:1 可复刻 · 禁止虚构

延伸阅读与交流

本文涉及的Hermes Agent自进化智能体技术体系，目前已有系统化的深度学习资源可供参考。中国通信工业协会通信和信息技术创新人才培养工程项目办公室将于近期组织相关技术专题分享，围绕本文讨论的AI原生架构、智能体工作流、自进化数据层等方向展开系统讲解。

专题信息

主题：AI原生Hermes自进化智能体系统
时间：2026年8月22-23日
形式：线上直播
内容方向：AI原生架构 · Hermes智能体拆解 · 全栈扩展 · 智能自动化 · 产品级实战 · Context Engine · 自进化数据层

分享嘉宾

王老师（Gavin），Agentic AI企业联合创始人兼CTO，十余年硅谷AI系统工程经验。长期深耕NLP、强化学习、可控AI与智能体系统架构，提出"语言即控制（Language as Control）"原创范式，在RLHF、PPO、DPO、GRPO等方向有系统化工程实践，推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。联系邮箱：hiheartfirst@gmail.com

技术交流

联系人：Sam
Hermes Agent技术文档：hermes-agent.nousresearch.com/docs/

在这里插入图片描述

022 | 扩展统计与规划器旋钮：列相关怎么破、旋钮怎么调

导读：上一篇结尾留下了一个伏笔——单列统计信息默认假设列与列相互独立，于是 WHERE a = 1 AND b = 2 就被算成两个选择率直接相乘。现实数据里这一假设常常崩盘：邮编定城市、年份定年代、国家定语言。CREATE STATISTICS 就是修这条假设的工具，有 dependencies、ndistinct、mcv 三种 kind。本篇前半把这三者讲透、给出该伸手时的三个信号；后半进入规划器那串 GUC 旋钮——random_page_cost、effective_cache_size、work_mem、default_statistics_target、enable_* 家族——逐一拆开"该不该动、动了会怎样"。

扩展统计信息

pg_statistic 里的单列统计信息在一个安静的假设下工作：列与列是独立的。WHERE a = 1 AND b = 2 的选择率被算成 selectivity(a = 1) × selectivity(b = 2)。当 a 和 b 真的独立时这个乘积是对的；当它们不独立时，这个乘积会错，有时错得离谱。

真实数据满是相关性。国家与语言、邮编与城市、下单日期与月份、电影上映年份与导演生涯年代——规划器对这些一无所知，因为它们都没被记进任何一列的直方图里。扩展统计信息就是你向规划器明示这些相关性的方式。

假设崩盘的两种方向

想象 cinetrack 的 view_events 表有两列：country_code 和 language_code。两列都偏态。40% 的行国家是 US，约 67% 的行语言是 en。规划器被问到 WHERE country_code = 'US' AND language_code = 'en'，它做乘法：0.40 × 0.67 ≈ 0.27。它预期27% 的表会匹配。

但这两列按设计就是强相关：每一行 US 都对应 en （除一小撮噪声），所以真实答案接近 40%。规划器的估算差了大约 1.4 倍，偏低。这听起来不算糟，直到计划里下一个操作是连接——它建基的行数小了三分之一，于是连接方式选错。

反过来更糟。 如果两列反相关（比如英语用户大都在非 US 国家），真实选择率可能是 5%，规划器的 27% 估算就高估了五倍。建在高估估算上的计划该嵌套循环的地方去哈希连接、或者选错驱动侧，运行时间直接爆炸。

规划器没法从单列统计信息里知道这两件事中的任何一件。修法是明明白白告诉它：这两列有关系。

CREATE STATISTICS：三种 kind

CREATE STATISTICS 命令在一组列上建一个扩展统计信息对象。三种 kind，常常组合用：

CREATE STATISTICS country_lang_stats (dependencies, ndistinct, mcv)
ON country_code, language_code
FROM view_events;
ANALYZE view_events;

每种 kind 教会规划器一件事：

ndistinct：列出的列组合起来有多少个不同的值。没这个的话，规划器用 n_distinct(a) × n_distinct(b)——列独立时对、不独立时高估。对多列 GROUP BY 有用。
dependencies：函数依赖。如果 a 被 b 决定（b 的每个值都预测一个 a 的值），规划器把依赖强度记成 0 到 1 之间的数。强依赖时，selectivity(a AND b) 坍缩成接近 selectivity(b)，而不是积。经典案例：邮编定城市。
mcv：多列 MCV 列表。跟单列 MCV 一个思路，但针对值的组合。规划器记录最常见的 pair 和它们的频率。三者里最有表达力，也是最贵维护的。在函数依赖和 ndistinct 修正都还留着估算偏差时上它。PostgreSQL 12 开始可用。

你不一定三样都要。怀疑一列预测另一列——从 dependencies 开始；少数几个偏态组合主导全表——加 mcv；GROUP BY 多列选错聚合策略——加 ndistinct。

怎么读它

CREATE STATISTICS 只声明对象。dependencies / ndistinct / mcv 在下次 ANALYZE 填充前都是空的——所以建完扩展统计一定要跑一次 ANALYZE。跑完之后可以查规划器现在知道什么：

SELECT statistics_name,
       attnames,
       kinds,
       n_distinct,
       dependencies
FROM pg_stats_ext
WHERE statistics_name = 'country_lang_stats';

填好的行会显示——对 dependencies kind——类似 {"1 => 2": 0.93}，意思是第 1 列以 93% 的置信度预测第 2 列。这个数会直接喂进规划器的选择率计算。

如果声明了 MCV，它会住进 catalog 的单独一行。pg_mcv_list_items() 让你拆开：

SELECT *
FROM pg_statistic_ext s
JOIN pg_statistic_ext_data d ON d.stxoid = s.oid,
     pg_mcv_list_items(d.stxdmcv) AS mcv
WHERE s.stxname = 'country_lang_stats';

这会对每个被存下的值组合出一行、附上频率。你通常会看到少量主导组合加一条长尾。

什么时候该伸手

扩展统计信息是一个目标明确的工具。三个信号告诉你该上它：

多列过滤的行估算差了一个数量级。 EXPLAIN ANALYZE 显示 (rows=1000)、实际返回 100,000。如果两列单列来看都有像样的统计，这个差距十有八九就是相关性。
多列 GROUP BY 产出错误的行估算。 一个按 country_code, language_code 分组的查询以为会产生 200 组、实际产生 30 组。聚合的下游代价全错。ndistinct 扩展统计直接修这个。
过滤条件作用在一列上、而这列被另一列函数决定。邮编定城市、订单 ID 定下单日期——一列对另一列有近乎完美的预测力时，dependencies 扩展统计把规划器的估算缩到正确尺寸。

不要没事瞎建。 每个统计对象都给 ANALYZE 加活、给 pg_statistic_ext 占地方。大多数表上单列直方图就够了，不够时扩展统计才是精确的解药——够用时它就是噪声。

重要提示：mcv kind （PostgreSQL 12 引入）是近年版本对偏态真实数据最大的规划器改进。如果你有一个多列过滤规划器估错、表上又有少数几个值组合占主导，CREATE STATISTICS ... (mcv) ON a, b FROM t 往往就是一行修好。

扩展统计做不到的事

几个限制得说清：

只对所列列上的"朴素表达式"生效。 lower(country_code) = 'us' 这种计算表达式不会匹配 country_code 上的扩展统计对象。表达式索引和表达式统计信息（同样走 CREATE STATISTICS、独立特性）才是答案。
不帮 OR 子句的忙。 规划器对 OR 的处理是分别算每个分支的选择率、再用容斥原理合并。扩展统计只改善每个分支的数、不改 OR 怎么算。
不替换单列统计信息，只补充它。规划器对只触及一列的过滤仍然需要单列直方图，而大多数过滤就是这种。

规划器旋钮

Postgres 暴露了一长串影响规划器的 GUC。名字看起来像调音面板：enable_seqscan、random_page_cost、cursor_tuple_fraction……别把它们当调音面板。规划器大多数时候是对的。拧任何旋钮之前，先问自己一句："我要覆盖的是规划器对我的数据相信的哪件事？"——答不上来就别动。

random_page_cost

现代硬件上最具影响力的单项规划器旋钮。默认 4.0，假设一次随机页读 = 四次顺序读。这个比值来自机械硬盘时代、寻道时间主导 I/O。

在 SSD 上比值接近 1.1；NVMe 上接近 1.0；在 EBS gp3 这类云块存储上介于两者之间，取决于内核页缓存帮了多少忙。4.0 的默认值会系统性地把规划器从索引扫描上推开，这就是为什么这么多生产调优里都长着一张 random_page_cost = 1.1 的脸。

一条实用规则：

机械硬盘：保持 4.0。
本地 SSD 或 NVMe：1.1 到 1.5。
云块存储：1.5 到 2.0。
始终命中的工作负载（数据库整体能放进 shared_buffers）：1.1 或更低。

用你真实的查询负载来测变更。代价比值会同时改动很多计划——如果你那些计划当初是按 4.0 默认调出来的，有些你觉得舒服的计划也会跟着变。

effective_cache_size

这个旋钮忽悠了很多人。effective_cache_size 不分配任何内存。它纯粹是规划器拿用的一个估算值，告诉它你的数据 Postgres 预期能在缓存里找到多少。规划器用它判断一个索引查找会命中缓存（便宜）还是命中磁盘（贵）。

默认 4GB，在任何现代服务器上都偏低。正确值大致是 shared_buffers 加上 Postgres 能拿到的 OS 页缓存的总和。在一台 64GB 内存、Postgres 占 16GB shared_buffers、且只跟 OS 共享一台机器的服务器上，effective_cache_size = 48GB 是个合理估。

设太低让规划器对索引扫描悲观、偏向对那些它认为放不进缓存的表做顺序扫描。设太高让规划器乐观、对那些实际会打到冷页的查询仍然选索引扫描。

跟 random_page_cost 不同，这一个旋钮在全新安装上几乎总是错的、几乎总是修起来很便宜。设成你的真实缓存大小，然后忘掉它。

work_mem

第 5 章讲过 work_mem 的运维面：每个操作、每个后端各一份，正确值依赖 max_connections 和并发度。

对规划器而言，work_mem 是排序或哈希溢写磁盘的阈值。规划器在给哈希连接、哈希聚合、排序节点定价时会参考它。work_mem 越高，规划器认为能塞进内存的计划越多——于是基于哈希的计划也越多。

不动其他任何东西地抬 work_mem，就能让计划选择翻转。一个在 work_mem = 64MB 下哈希连接的查询，在 work_mem = 4MB 下可能会归并连接，因为规划器现在以为哈希要溢写。会话级覆盖是给一次性分析查询留出余地的标准工具。

default_statistics_target

7.3 节里见过的旋钮。默认 100。按列覆盖用 ALTER TABLE ... SET STATISTICS。

几条常被搞错的规则：

全局抬到 1000 几乎从来不是答案。它在每张表上增加 ANALYZE 时间、给那些不需要的列填更大的 MCV 数组、稍微抬升每条查询的规划时间。真正的赢点，来自那几列正好 100 太小的列。
降到 100 以下几乎从不有用。ANALYZE 上省得不多，计划质量损失可能很大。
按列覆盖是外科手术工具。找到那些直方图或 MCV 数组太小抓不住分布的列，抬到 1000 或 10000，其余按兵不动。

什么时候该抬的诊断：去看 pg_stats.most_common_vals 和 pg_stats.histogram_bounds。如果 MCV 列表已经饱和（最低频的 MCV 在表里仍然算常见），你就有了一条直方图近似得很糟的长尾。把那一列的 target 抬高——规划器拿到更长的 MCV 列表和更细的直方图。

调音面板上的应急开关

有一组 GUC 看起来像应急开关：

enable_seqscan
enable_indexscan
enable_indexonlyscan
enable_bitmapscan
enable_nestloop
enable_hashjoin
enable_mergejoin
enable_hashagg
enable_sort
enable_partitionwise_join

你把一个设成 off，规划器并不会真的禁用那个操作符。它给它加一笔 disable_cost 惩罚（一个大数）。原本会用它的那个计划被加了一笔近乎无穷的代价，规划器自然挑别的。

这些是诊断工具，不是生产设置。 如果规划器在选顺序扫描、你怀疑索引扫描更快——SET enable_seqscan = off 一个会话、跑一次查询、看看计划变成什么、代价什么样。对比。重置。

诱惑在于把它一直开着生产环境里"强制定计划"。别这么做。下次数据一变，你强制的那个计划就变成错的，而你没有任何逃生口。 正确做法是搞清楚规划器为什么选了你不要的那个，修输入（统计、旋钮、查询），让规划器选你想要的那个。

警告：把 enable_seqscan = off 设成全局，是生产 Postgres 部署里悄悄坏掉最常见的方式之一。规划器再也没法在顺序扫描就是正确选项时选它。小表加新鲜插入、匹配大半张表的查询、系统目录的计划——全部受罪。如果你手痒想这么干，真问题一定在别处：要么修统计，要么修代价比值。

什么时候才动旋钮

一条省过不少时间的诊断顺序：

对表跑一次 ANALYZE。 过期统计是坏计划最常见的原因。
检查查询里涉及的列的 pg_stats。 MCV 健康吗？n_distinct 合理吗？correlation 是你预期的吗？
检查是否需要扩展统计。 多列过滤的行估算差 10 倍以上？试 CREATE STATISTICS。
按你的硬件核对 random_page_cost 和 effective_cache_size。 一次全局调一下。
对偏态分布的列按列抬 default_statistics_target。 调完 ANALYZE。
enable_* 旋钮只用于诊断，绝不作生产修复。

大多数规划器之谜都倒在步骤 1 或步骤 2 上。

本篇要点回顾

工具 / 旋钮	该不该动	怎么用
单列统计	不要乱动	MCV/直方图够用，过期就修
`CREATE STATISTICS (dependencies)`	有函数依赖就上	邮编定城市类
`CREATE STATISTICS (ndistinct)`	多列 GROUP BY 估错就上	修复聚合下游
`CREATE STATISTICS (mcv)`	少数组合主导表就上	最强 PG 12 修偏态利器
`random_page_cost`	现代 SSD 一般都要动	1.1-1.5（NVMe）、1.5-2.0（云盘）
`effective_cache_size`	全新安装几乎总错	= `shared_buffers` + OS 缓存
`work_mem`	分析查询会话级覆盖	抬高会让哈希计划变多
`default_statistics_target`	别全局调	按偏态列单列调到 1000/10000
`enable_*`	仅诊断、绝不生产	比对完就 SET 回默认

下一篇：023-规划器犯错时 —— 规划器还是会错。下一篇给一个完整诊断流程：从 EXPLAIN ANALYZE 看估算 vs 实际的鸿沟、五个常见估算出错原因、一份逐步排查清单、"别跟规划器硬刚"的真正意思，最后用 cinetrack 真实查询把全章串起来。

常见问题答疑（学员答疑）

Q1：WHERE country='US' AND language='en' 被估成 27%，实际是 40%——看起来只差一点，为什么下游计划会完全跑偏？

1.4 倍的偏差在单层扫描上看起来不大，但计划是级联的：选择率决定行数估算，行数决定连接方式，连接方式决定扫描选择，扫描选择又回到代价。规划器以为返回 27% 的行，选择了哈希连接；实际返回 40%，哈希表比预期大一半，溢出磁盘，整个查询从毫秒变成秒级。更糟的是反相关的情况：估算 27%、实际 5%，规划器选了嵌套循环——以为内层只要跑几万次，实际只跑几千次，但外层远比预期大，嵌套循环的乘法效应让总工作量爆表。这就像导航软件估错路程距离 40%——看似误差不大，但你要拐的那个路口已经过了。MySQL 8.0 也开始支持多列直方图（CREATE STATISTICS），但只做采样、不做函数依赖检测；Postgres 的 dependencies kind 能直接量化"一列预测另一列的强度"，是目前开源数据库里最精细的多列估算修正工具。

Q2：我把 enable_seqscan=off 设成全局配置，以为这样就能"强制走索引"——结果很多查询反而更慢了，为什么？

enable_seqscan=off 并不是"禁用顺序扫描"，而是给它加一笔近乎无穷的惩罚代价。规划器在所有场景下都避开 Seq Scan，哪怕 Seq Scan 本来就是最优选择——小表全扫、匹配大半张表的查询、系统目录的计划，全都被迫走索引扫描。索引扫描的随机读代价远高于顺序读，小表上可能还要多读好几页。这是生产环境最常见的"悄悄坏掉"配置：设置者以为优化了一条慢查询，却暗伤了十条本来正常的查询。正确的做法是用 SET enable_seqscan=off 只在当前会话诊断——看看"如果走索引会怎样"，对比完立刻重置。如果索引真的更快，就去修统计信息或代价参数，让规划器自然选择索引。Oracle 的 SQL Hint 也有类似的陷阱：/*+ INDEX */ 强制索引在生产环境里是反模式。所有数据库的设计哲学都是一样的——别堵规划器的路，修它的地图。

Q3：effective_cache_size 不分配内存，那它到底在干什么？设太低和设太高各有什么后果？

effective_cache_size 是规划器用来估算"数据有多大概率已经在缓存里"的一个假设值。它告诉规划器："我的服务器上大约有这么多内存可以用来缓存数据页"。规划器据此判断一次索引扫描的随机读是命中缓存（代价接近 0）还是命中磁盘（代价 = random_page_cost）。设太低：规划器悲观地认为索引扫描大概率要读磁盘，于是偏向顺序扫描——即使数据其实都在 shared_buffers 里。设太高：规划器乐观地认为所有页都在缓存，偏向索引扫描——但实际数据可能很冷，索引扫描大量随机读磁盘比顺序扫描更慢。正确值是 shared_buffers + OS 页缓存的大致总和。64GB 内存的服务器、Postgres 占 16GB shared_buffers，effective_cache_size 设 48GB 是合理的。这是全新安装上几乎总是错的参数——默认 4GB 在现代服务器上严重偏低，改成真实缓存大小后很多查询的计划会显著改善。

第八篇：Context()方法详解——如何为LLM组装完美上下文

"Token不够用了。"这是每个构建长对话Agent的开发者都遇到过的困境。对话越长，历史消息越多，LLM的上下文窗口就越撑不下。

context()方法就是Honcho给出的优雅解决方案。

context()是什么？

context()是Session对象上的方法，返回格式化的对话上下文，可以直接注入LLM。它智能地在摘要和近期消息之间分配token预算。

from honcho import Honcho

honcho = Honcho()
session = honcho.session("conversation-1")

# 基本上下文
context = session.context()

# 限制到1500 tokens
context = session.context(tokens=1500)

# 不含摘要，全用近期消息
context = session.context(summary=False, tokens=2000)

默认行为：摘要+消息的智能混合

默认情况下，context()返回的内容包含两部分：

摘要部分（40%预算）：自动生成的Session摘要，压缩了较早的对话内容。

消息部分（60%预算）：最近的原始消息，保留完整上下文。

context = session.context(tokens=2000)
# 结果拆分：
# - 摘要约800 tokens（40%）——压缩的历史对话
# - 近期消息约1200 tokens（60%）——原始聊天记录

这个比例不是随便定的——40/60的分配确保你有足够的近期上下文做精确响应，同时通过摘要覆盖更长的对话历史。

加入Peer Representation

这是context()的杀手级功能——你可以在上下文中加入Peer的跨Session记忆：

# 在上下文中加入用户representation
context = session.context(
    tokens=2000,
    peer_target="user-123"  # 包含这个Peer的记忆
)

print(context.peer_representation)  # 推理结论的字符串表示
print(context.peer_card)            # Peer Card事实列表

加入peer_target后，context不仅包含当前Session的对话历史，还包括Honcho对用户跨所有Session的推理结论。这是实现真正个性化的关键。

语义搜索加入Context

context = session.context(
    tokens=2000,
    peer_target="user-123",
    search_query="这个用户有什么编码偏好？",
    search_top_k=10,            # 检索10条相关结论
    search_max_distance=0.8,    # 最大语义距离0.8
    include_most_frequent=True,  # 包含最频繁出现的结论
    max_conclusions=25          # 最多25条结论
)

这样context中只包含与你指定查询相关的结论——精准且节省token。

转换为LLM格式

context()返回的SessionContext对象提供多种格式转换：

# OpenAI格式
context = session.context(tokens=2000)
openai_messages = context.to_openai(assistant=assistant)
# [
#   {"role": "user", "content": "历史消息1..."},
#   {"role": "assistant", "content": "历史回复1..."},
#   ...
# ]

# Anthropic格式
anthropic_messages = context.to_anthropic(assistant=assistant)

# 可以复用同一个context对象做多次格式转换
openai_messages = context.to_openai(assistant=assistant)
anthropic_messages = context.to_anthropic(assistant=assistant)

完整的OpenAI集成示例

import openai
from honcho import Honcho

honcho = Honcho()
openai_client = openai.OpenAI()

session = honcho.session("support-chat")
user = honcho.peer("user-123")
assistant = honcho.peer("support-bot")

# 添加对话历史
session.add_messages([
    user.message("我的账号登录有问题"),
    assistant.message("我可以帮你。你看到什么错误信息？"),
    user.message("显示'凭据无效'但我确定密码是对的")
])

# 获取上下文（含Peer记忆）
context = session.context(
    tokens=2000,
    peer_target="user-123"
)
messages = context.to_openai(assistant=assistant)

# 添加新消息并获取AI响应
messages.append({"role": "user", "content": "能帮我重置密码吗？"})

response = openai_client.chat.completions.create(
    model="gpt-4",
    messages=messages
)

# 将AI响应写回Session
session.add_messages([
    user.message("能帮我重置密码吗？"),
    assistant.message(response.choices[0].message.content)
])

使用不同助手视角

同一个Session中，不同的助手Peer可以看到不同视角的上下文：

chatbot = honcho.peer("chatbot")
analyzer = honcho.peer("data-analyzer")
moderator = honcho.peer("moderator")

# 每个助手获取从自己角度格式化的上下文
chatbot_context = session.context().to_openai(assistant=chatbot)
analyzer_context = session.context().to_openai(assistant=analyzer)
moderator_context = session.context().to_openai(assistant=moderator)

Best Practice：Token管理

# 根据模型选择合适的token限制
context = session.context(tokens=3000)   # 大模型如GPT-4
context = session.context(tokens=1500)   # 小模型

# 长对话用摘要模式
context = session.context(summary=True, tokens=2000)

# 只需最近几条消息时
context = session.context(summary=False, tokens=1000)

Q&A

Q1：如果对话历史非常长，context()会不会自动做截断？会不会丢信息？

A：会智能处理，但不是简单截断。如果摘要本身比token限制还大，则无法包含摘要——上下文只有最近能放下的消息。如果最后几条消息就超过了token限制，上下文可能只有1-2条消息。这就是为什么默认不传token限制时，Honcho会检索"穷尽覆盖"所需的所有token。在生产中，建议传一个合理的token限制（如2000-3000），让Honcho在摘要和消息之间做最优分配。

Q2：peer_representation在context中具体长什么样？是一个字符串还是结构化的？

A：context.peer_representation是一个字符串——所有相关推理结论的文本表示。context.peer_card是一个字符串列表，每条是一个事实（如"Name: Alice"）。当你在context中同时包含对话历史、摘要、peer representation和peer card时，你的LLM获得的是一个360度的用户理解——不仅知道"说了什么"，还知道"推理出了什么"。

Q3：context()和chat()有什么区别？各自应该在什么时候用？

A：简单来说：context()给你原始材料（摘要+消息+结论），你自己组装prompt给LLM做生成；chat()是Honcho帮你做一次推理查询，直接给你合成答案。典型工作流：在每次对话回合用context()获取上下文→注入你的LLM→LLM生成回复；在需要特定洞察时（如"用户是否完成了入门流程？"）用chat()获取定向答案。两者互补——context保证对话连贯，chat提供深层理解。

大模型日报 - 2026年8月13日

==================================================

新闻1：DeepSeek V4-Pro正式版深夜发布，性能比肩国际顶尖模型

摘要：8月12日晚，DeepSeek低调推出V4 Pro正式版（DeepSeek-V4-Pro-0813），已覆盖API与网页对话。基准测试显示，其性能相比预览版全面提升，在AI安全智能体测试套件Cybergym、工作流智能体AutomationBench中超越美国顶尖模型Fable 5；在真实软件工程编程智能体测试DeepSWE中，得分从预览版的12.8跃升至62.x。API定价仅为上一代旗舰模型V3.2的1/4，降价幅度高达75%。

新闻2：xAI发布Grok 4.6，总参数1.5万亿，重点改进SFT和强化学习

摘要：8月12日，马斯克旗下SpaceXAI宣布推出Grok 4.6模型，总参数量为1.5万亿，重点改进了监督微调（SFT）和强化学习（RL）。Grok 4.6已接入Cursor和Grok Build，也可通过API和OpenRouter、Vercel及Cloudflare调用，定价为每百万输入token 2美元、每百万输出token 6美元。此前SpaceXAI已推出企业级AI代理产品Grok Bot，标志着AI助理从被动问答向主动执行实际工作转变。

新闻3：阿里千问首次开源Max级旗舰模型权重Qwen3.8-2.4T-A95B

摘要：8月12日深夜，阿里云魔搭ModelScope社区宣布，阿里Qwen团队正式开放Qwen3.8-2.4T-A95B模型权重，这是Qwen-Max级别模型首次开源。该模型总参数为2.4万亿，每个Token激活950亿参数，原生支持262,144 Token上下文，可扩展至101万Token。采用稀疏MoE架构与混合注意力机制，并通过旗下平头哥实现软硬件协同，在编程、办公、科研及长周期任务等方面实现全面提升。

新闻4：腾讯发布2026年Q2财报，混元Hy3大模型上线首周调用量提升68倍

摘要：8月12日，腾讯控股发布2026年第二季度财报，营收2047.85亿元同比增长11%。AI成为核心主线：大模型混元Hy3自推出以来持续位列全球前三，上线首周调用量较前代提升逾68倍；参数规模更大的Hy4版本将于近期推出。AI原生办公智能体WorkBuddy与编程工具CodeBuddy保持国内领先，WorkBuddy 6月在PC端访问量居首。腾讯资本开支大增176%，将大量利润转化为AI基础设施投资。

新闻5：中国AI大模型调用量连续15周领跑全球，OpenRouter前五首次全部为中国本土产品

摘要：据OpenRouter最新数据，8月3日至8月9日全球AI大模型总调用量达69万亿Token，环比增长21.48%。其中中国AI大模型周调用量达34.25万亿Token，环比增长21.76%，连续15周超过美国稳居全球首位。DeepSeek-V4-Flash正式版以8.83万亿Token周调用量位居第一，环比增长570%。OpenRouter前五名首次全部由中国本土AI产品包揽，标志着中国大模型在全球市场竞争中持续扩大领先优势。

大模型论文日报 - 2026-08-13

1. MLS-Bench: AI能否真正"做研究"？140道真实研究题给出否定答案

论文编号: arXiv:2605.08678
研究方向: AI科研能力评测 / 递归自我改进
机构: UC Berkeley、Princeton、清华、UW、Purdue、Harvard、UPenn、SJTU、UCSD、CMU

摘要

MLS-Bench覆盖12个机器学习领域、140个来自真实代码库的研究任务，专门评测AI能否提出并实现真正更好的方法。每道题包含至少3个测试环境和3个强人类基线（含领域SOTA），模型需要在冻数据管线和评测器的条件下，只修改研究相关组件。该评测已被Kimi K3和Qwen3.8-Max纳入官方发版表。

结论

即使拿到人类SOTA的完整实现并允许反复实验，当前前沿模型仍无法在整体上超过Human SOTA。模型交出的"新方案"基本是对已知方法的调优与组件重组，真正的新机制极少，且往往缺少有解释力的假设。增加推理预算和测试时采样能提高分数，但提升主要来自加强搜索而非方法发现。

对已有假设的挑战与质疑

挑战"AI自进化即将实现"的叙事: 当前流行的"递归自我改进"概念被证明主要限于验证廉价、反馈快速的搜索场景；真正的科学发现需要模型在验证昂贵的条件下判断"什么假设值得验证"，这一能力当前模型完全缺失。
质疑"测试时算力可解决一切": 增加采样次数只在已定义好的候选空间中有效，方法发现要求模型先创造一个值得搜索的新空间——这是更多算力无法自动填补的。
推翻"模型做更多实验=更好研究"的直觉: 给模型自由支配算力预算后，多数模型性能反而下降——科学研究中最关键的"判断什么实验最有信息量"的能力是当前模型的盲区。
质疑"知识检索=科学发现": 给模型提供更多外部知识（论文、推导、理论背景）带来的增益有限，瓶颈不在信息可得性，而在"下一步该相信什么、验证什么"的科学判断力。

2. WorldCycle: 让视频世界模型学会"原路返回"，破解长程漂移难题

论文编号: arXiv:2608.04964
研究方向: 交互式视频世界模型 / 长程一致性
机构: 香港科技大学、武汉大学、腾讯视频AI技术中心

摘要

交互式视频世界模型在长时间运行后会出现"状态返回失效"——摄像机走十步再退十步后回不到原点。WorldCycle利用"闭合动作循环"的物理特性（可逆动作叠加后净效果为零位移）作为无需标注的自验证信号，提出空间闭合奖励和时间一致性奖励双重训练机制，并发布首个长程漂移评测基准CycleBench。

结论

WorldCycle将终点状态闭合误差降低32%、反向路径对称性误差降低44%，长期场景下重复循环稳定性提升34%。参数量17倍的LingBot World v2在状态一致性上全面落后，证明堆参数无法解决长程一致性问题。复合动作准确率从13.6%提升至55.3%，接近四倍改善。

对已有假设的挑战与质疑

挑战"增大模型规模即可解决一致性"的规模化假设: 140亿参数模型在长程一致性指标上全面落后于8B参数的WorldCycle，证明这是结构性缺陷而非算力问题。
质疑"强化学习需要外部标准答案": WorldCycle通过闭合路径的物理代数结构内生构造标准答案，无需任何训练数据或人工标注——将"无解的监督问题"转化为"有解的"。
推翻"逐片段打分足以训练视频模型": 现有的后训练方法逐片段评估画面质量或动作方向，完全无法捕捉跨越数百帧的整体漂移。
质疑"复合动作需要真实训练数据": WorldCycle对从未出现在训练数据中的"一边走一边转"等复合动作实现了近四倍提升，证明循环约束可泛化到出域场景。

3. Hyperball: 把权重锁在超球面上，保住Mu优化器的加速收益

论文编号: arXiv:2606.16899
研究方向: 大模型预训练优化器 / 权重衰减理论
机构: 斯坦福大学、清华大学

摘要

Muon等矩阵类优化器可显著加速语言模型预训练，但在标准常数解耦权重衰减下，其相对AdamW的优势随模型和数据规模增大而逐渐减弱。Hyperball是一种优化器封装方法，将各权重矩阵的Frobenius范数固定为预设常数，使优化轨迹被约束在超球面上。在1.2B参数Qwen3风格模型上，Muon+Hyperball实现20%-30%的token等效训练加速，并显著提升学习率在宽度与深度间的可迁移性。

结论

Hyperball通过显式控制权重矩阵的方向变化速率（"角度学习率"），解决了Muon在规模化时加速衰减的根本问题。其理论基础源于：使用权重衰减训练时系统收敛到仅依赖超参数的平衡态范数，权重衰减本质上决定了权重方向变化的速度。

对已有假设的挑战与质疑

挑战"常数解耦权重衰减是正则化标准范式": 研究揭示标准权重衰减实际上在隐式地控制"角度学习率"，但在矩阵类优化器中这种隐式机制随规模失效——需要显式地约束范数而非简单施加衰减。
质疑"优化器增益随规模线性外推": Muon相对AdamW的优势不是恒定的，在传统权重衰减下会随模型增大而缩水，意味着此前在小规模实验中得到的优化器比较结论可能不可直接外推。
挑战"学习率调度的宽度迁移性足够": 不同网络宽度下的最优学习率差异是迁移痛点，而Hyperball的范数固定使角度学习率独立于宽度——重新定义了"学习率可迁移性"的含义。

4. Modular TTT: 将测试时训练重构为可组合模块，系统性消融发现反直觉结论

论文编号: arXiv:2608.07260（智源社区本周热门）
研究方向: 测试时训练 / 序列建模架构
机构: 多机构合作

摘要

测试时训练（TTT）将序列建模视为在线学习问题，"快速权重"通过内部学习规则动态更新。Modular TTT框架将内部学习器建模为有向无环图（DAG），显式定义快速权重网络、损失函数、学习率、权重衰减和归一化为可独立调节维度，自动组合出完整的图层级TTT计算流程。基于系统性消融，训练了410M和1.45B两个大模型，训练损失与多项指标均与Gated DeltaNet相当。

结论

系统性消融发现：较小学习率初始化、权重衰减、单层非线性变换均有助提升性能；MSE损失与内积损失效果相当。但更深的快速权重网络和归一化操作反而损害性能（根因是过大激活值），残差连接和门控机制未带来可测量的性能增益。

对已有假设的挑战与质疑

挑战"更深的网络结构总是更好": 在TTT中，更深的快速权重网络反而损害性能——直接挑战了深度学习"更深=更强"的核心直觉。
质疑"归一化总会带来稳定收益": 归一化在TTT的快速权重更新中不仅无益反而有害，因为快速权重的动态更新会放大归一化引入的激活值波动，与Transformer中"归一化=稳定"的共识矛盾。
挑战"残差连接是万能正则化器": 残差连接在TTT中未带来可测量的增益，说明其价值高度依赖于计算图结构，而非普遍适用的"好默认"。

5. Skaling: 缩放定律中模型大小与数据的独立假设是错的

论文编号: arXiv:2608.07222
研究方向: 神经缩放定律 / 大模型训练预算
机构: Meta FAIR

摘要

标准神经缩放定律是语言模型研发的基石，但其在数据极度匮乏和过度训练两种极端情形下会系统性低估或高估模型损失。根本缺陷在于底层假设：模型规模与训练数据量对损失的影响相互独立。Skaling提出一种广义函数形式，通过单一交互指数将模型容量与数据量耦合。该定律在插值和外推场景下将MAPE降低1.5-3倍，并结合稀疏网格策略仅需约十分之一的计算量即可高精度外推完整网格。

结论

Skaling定律以更少的计算量实现了更准确的性能预测，为大模型训练提供了更节省计算资源的算力预算分配框架。模型大小与数据的交互效应是现有缩放定律系统性偏差的根源。

对已有假设的挑战与质疑

挑战Chinchilla的核心假设: Chinchilla缩放定律假设模型规模与数据量对损失的影响相互独立，Skaling通过引入交互指数证明二者存在耦合——这是对现有缩放定律理论基础的根本修正。
质疑"均匀网格扫描是性能预测的金标准": Skaling的稀疏网格策略仅需约十分之一计算量即可达到甚至超过均匀扫描的预测精度，说明此前的算力预算分配方法存在大量浪费。
挑战"缩放定律在极端情形下仍准确": 在数据极度匮乏和过度训练两种极端下，传统缩放定律的系统性偏差最大——这直接影响当前"训练远超Chinchilla最优数据量"的过度训练实践是否依然有效。

本邮件由 TeleAgent (星辰超级智能体) 自动生成

在这里插入图片描述

2026年重磅喜讯！喜报！热烈祝贺Gavin大咖人工智能领域经典著作《企业级ChatGPT AI大模型应用开发实战（1000分钟视频）》中国水利水电出版社发行上市!

内容提要

本书内容基于作者在硅谷 ChatGPT 项目及企业培训中的实战经验凝练而成，重点介绍企业级 ChatGPT 开发的核心技术、案例研究及最佳实践。全书共 16 章，分为基础篇和实战篇两大部分。

基础篇：

介绍 ChatGPT 底层架构 Transformer 技术及源码实现、GPT 的内部机制及源码实现、GPT 系列模型原理与应用：从 GPT-2 到 GPT-4 等内容。

实战篇：

介绍基于 ChatGPT 的端到端语音聊天机器人项目实战，企业级 ChatGPT 开发的三大核心内部机制及案例实战，ChatGPT 插件的内部机制、源码及案例实战，ChatGPT 提示词开发实战，思维链及 ReAct 解析与实战，提示词本质解析及评估实战与源码解析，LangChain 大模型框架的七大核心组件及案例解析（上、下），LangChain 代理深入解析及源码解析，AutoGPT 源码解析及综合案例实战，使用 LangChain 构建问答聊天机器人案例实战，构建基于大模型的自治代理案例，Llama 2 模型与 LangChain 项目详解。书中每个知识点均配有相应的实现代码和实例。

本书适合有一定 Python 基础的 ChatGPT 爱好者阅读，主要面向从事大模型应用开发、机器学习、数据挖掘或深度学习的专业人员，高等院校相关专业的师生，以及相关领域的科研人员。

本书附赠丰富的学习资源，具体如下：①同步学习资源，即 16 集同步教学视频，视频时长共计约 1000 分钟；②教师授课的辅助资源，即 187 个案例知识点、15 个项目实战的全部源代码。

前言

在当今快速发展的科技时代，人工智能（artificial intelligence，AI）技术正以惊人的速度改变着人们的生活和工作方式。在这个新时代的浪潮中，大模型技术成为AI领域的一颗耀眼新星。ChatGPT作为大模型技术的重要应用之一，正在引领着人机交互领域的革新浪潮。本书将带领读者深入探索大模型新时代，通过ChatGPT实战项目和内部解析，深入掌握基于ChatGPT的大模型应用开发领域的关键技术，并解密ChatGPT的底层架构和实现原理。

本书主要内容

本书通过ChatGPT实战项目的方式，为读者呈现一个全面、系统的学习路径，从基础知识的介绍开始，带领读者深入了解ChatGPT的工作原理和实际应用。本书非常适合具备Python基础的读者学习。

全书共16章，分为基础篇和实战篇两大部分。基础篇包括第1～3章；实战篇包括第4～16章。

第1章 ChatGPT底层架构Transformer技术及源码实现，详解最大似然估计、最大后验概率、贝叶斯Transformer及自编码与自回归语言模型的内部机制。

第2章 GPT的内部机制及源码实现，剖析GPT运行机制、掩码机制、Decoder-Only模式，详解数据流动生命周期及GPT-2源码。

第3章 GPT系列模型原理与应用：从GPT-2到GPT-4，解析ChatGPT提示词流程、GPT-2运行机制，可视化解读GPT-3/4的内部机制。

第4章基于ChatGPT的端到端语音聊天机器人项目实战，涵盖ChatGPT API开发、前后端构建（ReAct+FastAPI）及项目优化。

第5章企业级ChatGPT开发的三大核心内部机制及案例实战，解析企业级开发核心，演示Notion问答对话AI案例。

第6章 ChatGPT插件的内部机制、源码及案例实战，详解插件工作原理、检索插件源码及全流程开发实战。

第7章 ChatGPT提示词开发实战，基于LangChain框架的提示词、思维链、链式提示词及模型评估开发。

第8章思维链及ReAct解析与实战，剖析思维链推理、ReAct技术原理、框架源码及案例实战。

第9章提示词本质解析及评估实战与源码解析，包含问答评估、代理评估源码解析及提示词本质探讨。

第10～11章 LangChain大模型框架的七大核心组件及案例解析（上、下），涵盖模型、词嵌入、提示词、内存、回调、数据连接、代理等核心组件及聊天机器人综合案例。

第12章 LangChain代理深入解析及源码解析，详解代理工作原理及AutoGPT源码解析。

第13章 AutoGPT源码解析及综合案例实战，剖析AutoGPT内部机制及其在LangChain代理、内存、PromptGenerator中的应用。

第14章使用LangChain构建问答聊天机器人案例实战，涵盖GPT-4代码生成全流程及LangChain开发实战。

第15章构建基于大模型的自治代理案例，详解自治代理原理、工具、示例及开源实现源码。

第16章 Llama 2模型与LangChain项目详解，包括模型部署（Replicate）、Hugging Face/LangChain实践、检索增强生成及自定义提示词RetrievalQA开发。

本书特色

●深入探索，全面剖析。本书涵盖ChatGPT案例实战、LangChain项目实战及框架源码解析等多个层面的内容。每章都深入探讨相关技术与案例，并提供源码解析，使读者能够全面了解ChatGPT和LangChain等技术的内部机制与开发原理，为实际项目的应用提供有力指导。

●实战剖析，项目揭秘。本书每章都提供具体的案例实战与项目解析，引导读者通过实际操作和代码理解技术细节和底层逻辑。通过理论结合实践的方式，使读者能够更好地运用所学知识，深入了解项目和框架的实现细节。

●前沿突破，技术驱动。本书介绍了一系列突破性的技术，如ChatGPT、LangChain、Transformer、Prompt、Llama 2、AutoGPT、BabyAGI、CoT、ToT、ReAct、MRKL等。通过对这些技术的深入剖析，读者可以了解相关技术的发展和应用，并了解它们在实际项目中的具体应用场景和效果。

●源码解析，细致讲解。本书对LangChain框架的关键技术进行了逐行源码剖析。读者可以深入理解源码实现和机制原理，从而更好地理解技术细节和底层逻辑，并将其应用于实际开发工作中。

本书还为读者提供了丰富的知识和实用的技能，帮助读者在ChatGPT和LangChain领域取得突破性的进展。无论是初学者还是有一定经验的开发者，都可以从本书中获得有价值的学习资源。

配套资源

为便于教与学，本书配有同步教学视频（约1000分钟）、源代码、数据集、教学课件、教学大纲、安装程序。

作者简介

王家林

美国斯坦福大学计算机专业毕业。曾在美国担任硅谷顶级机器学习和人工智能实验室主任、杰出AI工程师及首席机器学习工程师，专精于对话式人工智能（conversational AI）。现担任硅谷某知名对话机器人公司CTO，自2019年起专注于基于红队测试（red teaming）的责任型AI（responsible AI），并热衷于构建生成式AI/大语言模型教练系统（GenAI/LLM coaching systems）。在硅谷任职期间，曾领导多个GenAI/LLM解决方案项目，成功平衡企业业务需求下的大模型推理（reasoning）系统与幻觉（hallucinations）及偏见（biases）风险的最小化。

作为数据科学、机器学习、NLP、ChatGPT及大模型等领域25本书的主要作者，王家林对利用人工智能提供解决方案，以及通过机器学习驱动的NLP与LLM流程帮助组织实现数据驱动决策充满热情。他曾领导Apple、PayPal、Chase Bank、Faethm、LinkedIn等公司的11个重大NLP项目。

在NLP、对话式AI、大数据及基于AWS的无服务器（serverless）技术方面，拥有丰富的机器学习咨询经验。

段智华

中国电信股份有限公司上海分公司高级工程师。长期从事大模型与智能体技术领域，专注Agentic AI、Harness Agent等前沿方向研究。

新书购买链接

《企业级ChatGPT AI大模型应用开发实战（1000分钟视频）》购买链接：item.jd.com/15389212.ht…

Hermes 技能系统详解——安装、使用与浏览

第 9 篇：技能系统详解——安装、使用与浏览

引言

技能的工作原理

内置技能目录

浏览和安装技能

技能来源

在会话中使用技能

/learn 命令

技能包（Skill Bundles）

安全扫描

技能配置

技能的更新生命周期

Q&A

@dre108 的 Gigaxity Deep Research 栈：7 个 MCP 服务器干掉 Perplexity API 的 $10/几天烧钱循环

@dre108 的 Gigaxity Deep Research 栈：7 个 MCP 服务器干掉 Perplexity API 的 $10/几天烧钱循环

案例背景 + 溯源 + 整体架构

开篇：你每隔几天烧掉的 $10，到底买到了什么？

溯源信息

案例元数据

业务问题：Perplexity API 的成本螺旋

成本对比：Perplexity vs Gigaxity

五层架构总览

7 个 MCP 服务器职责拆解

Triple Stack 概念：检索层的三角支撑

编排器的 6 个工具：从 0 token 到 15K token 的谱系

从零搭建教程 + 完整 Hermes 命令参考

第一步：获取 API 密钥

第二步：克隆并安装 gigaxity-deep-research

第三步：部署 SearXNG 元搜索后端

完整的 SearXNG settings.yml（分层引擎配置）

第四步：配置 7 个 MCP 服务器

第五步：安装 research-workflow skill

第六步：用不同查询类型测试

第七步（可选）：本地推理分支

完整命令参考表

完整 .env.example 配置模板

免费层轮换策略

源码深度解读 + 部署 + 复刻避坑总结

核心代码 ①：RRF（Reciprocal Rank Fusion）实现

核心代码 ②：CRAG 质量门控逻辑

核心代码 ③：引用绑定（Claim-to-Evidence Mapping）

核心代码 ④：矛盾检测（PaperQA2 风格）

核心代码 ⑤：自适应查询路由 + HyDE 查询扩展

核心代码 ⑥：SearXNG JSON API 集成

架构路径全景

成本优化分析：Token / 成本逐工具拆解

复刻检查清单

复刻避坑总结

结尾：拓展方向

溯源引用

延伸阅读与交流

专题信息

分享嘉宾

技术交流

022 | 扩展统计与规划器旋钮：列相关怎么破、旋钮怎么调

扩展统计信息

假设崩盘的两种方向

CREATE STATISTICS：三种 kind

怎么读它

什么时候该伸手

扩展统计做不到的事

规划器旋钮

random_page_cost

effective_cache_size

work_mem

default_statistics_target

调音面板上的应急开关

什么时候才动旋钮

本篇要点回顾

常见问题答疑（学员答疑）

第八篇：Context()方法详解——如何为LLM组装完美上下文

context()是什么？

默认行为：摘要+消息的智能混合

加入Peer Representation

语义搜索加入Context

转换为LLM格式

完整的OpenAI集成示例

使用不同助手视角

Best Practice：Token管理

`/learn` 命令

2026年重磅喜讯！喜报！热烈祝贺Gavin大咖人工智能领域经典著作《企业级ChatGPT AI大模型应用开发实战（1000分钟视频）》中国水利水电出版社发行上市!