Rajeev-Shyam/Quellgeist
GitHub: Rajeev-Shyam/Quellgeist
Quellgeist 是一个模型无关的生产事故分诊 AI Agent，通过结构化证据引用和确定性伪造检查，输出可验证的根因假设或在证据不足时诚实弃权。
Stars: 1 | Forks: 0
# Quellgeist
[](https://github.com/Rajeev-Shyam/Quellgeist/actions/workflows/ci.yml)
[](https://github.com/Rajeev-Shyam/Quellgeist/actions/workflows/security.yml)
[](docs/case-studies/wave4-qwen-finetune.md)
[](LICENSE)
[](https://www.python.org/downloads/)
Quellgeist 是一个用于生产事故一线分诊的模型无关 AI agent。
它在只读工具（结构化日志 + 近期部署 + 指标时间序列）上运行可读的 JSON-action ReAct 循环，然后输出结构化的 **Diagnosis**：按置信度排序的根因假设，每个假设都有智能体实际看到的结构化证据 handle（`LogRef.id` / `CommitRef.sha` / `MetricRef.id`）作为支持——绝不使用自由文本。有两个理念让它与众不同：
- **结构化 handle 引用。** 证据是一个可检查的 handle，而不是一句话，因此伪造的引用是*可衡量的*，并且会被无密钥的伪造检查**确定性地拒绝**——而不是模糊字符串匹配的问题。
- **弃权优于幻觉。** 自信地陈述错误的原因是最糟糕的答案，因此*“证据不足”*是一等结果。
## 为什么与众不同
| | |
|---|---|
| **证据是 handle** | 每个假设都会引用日志行的源稳定 `id` 或提交的 `sha`，完全照抄自工具结果——这是确定性伪造检查所查询单元。散文形式的文字仅存在于仅用于展示的 `note` 中。(DR-0009) |
| **弃权是一项功能** | 当信号微弱时，agent 会返回带有原因和空假设列表的 `abstained=true`——这是由 schema 强制执行的。 |
| **构造上模型无关** | 该循环从纯聊天文本中解析 JSON 动作，因此无论是在 Gemini 免费层还是本地 4-bit Qwen 上运行都是相同的——不依赖于任何后端的原生函数调用。只需更改一个配置即可交换模型。(DR-0008, DR-0010) |
| **可靠性是受控的，而非声称的** | 无密钥、确定性的 CI 门控（ruff + black + `pytest`，包括基于 fixture 的评估工具）在每次推送时运行。 |
### 它是什么 / 它不是什么
- **它是：** 一线*分诊* agent——通过在托管的前沿模型**或**本地 4B 模型上运行的模型无关循环，从只读日志/部署/指标中得出排好序的、有证据支持的根因假设（或诚实的弃权）。
- **它不是：** 一个自动修复器（它从不修改生产环境——解决方案的验证是推迟的、优先切割的 wave）；一个经过生产强化的服务（该演示是一个刻意为之的玩具）；或一个通用 agent。衡量它的留出集是*词汇表外但结构内*的——并不是对未见过的事故形态或真实生产数据的声明。
## 快速开始（约 30 秒即可获得损坏的服务 + 结构化日志）
需要 [uv](https://docs.astral.sh/uv/) 和 Python 3.12+。
**在一个无密钥命令中查看真实形态的诊断**（无需模型，无需 API key）：
```
uv sync && uv run quellgeist diagnose --demo # renders the demo incident's cited postmortem
```
然后针对实时玩具服务运行完整循环：
```
uv run uvicorn demo.app.main:app # 1. start the toy service (leave running)
# --- 在第二个 shell 中，从 repo 根目录执行 ---
uv run python -m demo.chaos.bad_deploy # 2. inject a simulated bad deploy
curl -s localhost:8000/login # 3. trip /login -> 500s + structured error logs
uv run quellgeist diagnose --show-trace # 4. diagnose live (needs a model; see below)
uv run python -m demo.chaos.reset # back to a green slate
```
实时步骤需要一个推理器——请参阅[运行模型](#running-the-model)。
在没有 key 的情况下，`quellgeist diagnose` 会以退出码 1 退出并带有一行错误提示（绝不会出现 traceback）；`--demo` 始终在无密钥情况下工作，并根据 gold 数据确定性地渲染相同的输出结构。
## 架构
一个定制且易读的循环作为编排层；三个只读工具作为证据接口；`Diagnosis` schema 是事后分析渲染器和评估判断器都会读取的契约。
```
flowchart TD
trigger(["incident trigger - CLI"]) --> loop
model["reasoner via LiteLLM
(Gemini or local Qwen, swappable)"] -. "chat completion" .-> loop subgraph loopbox["model-agnostic JSON-action ReAct loop"] loop["run_loop()
decide, call tool, observe, repeat"] end loop -- "query_logs" --> logs["logs tool
structured JSONL, stable ids"] loop -- "get_recent_commits" --> commits["commits tool
deploy_log.json, shas"] loop -- "query_metrics" --> metrics["metrics tool
time-series, named series"] logs -- "rows + ids" --> loop commits -- "commits + shas" --> loop metrics -- "series + names" --> loop loop --> diag["Diagnosis (schema.py)
ranked hypotheses citing
LogRef.id / CommitRef.sha / MetricRef.id, or abstains"] diag --> pm["postmortem renderer
deterministic Markdown"] diag --> judge["eval judge
fixture scenarios, CI gate"] ``` 这三个工具也都作为 **MCP server** 通过 stdio 公开 （`python -m quellgeist.servers.logs_mcp`、`…commits_mcp`、`…metrics_mcp`）。该 agent 目前在进程内复用 `ToolSpec` 注册表背后的相同工具*函数*；stdio MCP-*client* 路径（即 agent 通过网络驱动服务器）已列入路线图 (DR-0010)。 服务器会在每次标记的发布时发布到 **Official MCP Registry**（参见 [`docs/publishing.md`](docs/publishing.md)）；一旦发布，每个服务器都可以使用 `uvx --from quellgeist quellgeist-logs-mcp`（或 `…-commits-mcp` / `…-metrics-mcp`）运行。 ## 示例会话 注入错误部署——它会丢弃一个标记，将 `verify_token` 翻转为 NoneType 回归，并写入一个 `deploy_log.json`，其违规提交恰好在错误发生之前落地（说明性 `stdout`——时间戳反映您运行它的时间；路径相对于仓库根目录显示）： ``` $ uv run python -m demo.chaos.bad_deploy injected bad deploy a1b2c3d (touched demo/app/auth.py) at 2026-06-24T12:22:43Z marker: demo/.bad_deploy deploy log: demo/deploy_log.json next: hit /login to generate the 500s, then `quellgeist diagnose` ``` 在配置了推理器的情况下，`quellgeist diagnose` 会读取日志 + 部署并输出事后分析。CI 环境没有经过验证的模型 key (DR-0012)，因此下面的诊断是**从 gold 渲染**的——通过 `render_postmortem` 从 fixture 的标记原因和证据 handle 确定性地构建，*而不是*实时模型输出： ``` # Incident Postmortem (从 gold 渲染) ## Root-cause 假设 ### 1. Bad deploy a1b2c3d (10:01:50Z) 重构了 auth.py 并在 verify_token 中引入了 NoneType error；随后约 20 秒，/login 在 10:02:12Z 开始返回 500s。(confidence: 1.00) Evidence: - log #2 - commit a1b2c3d ``` 亲自重现该渲染（无需模型）： ``` uv run python - <<'PY' from evals.scenarios.generator import load_scenario from quellgeist.agent.schema import Diagnosis, Hypothesis from quellgeist.output.postmortem import render_postmortem s = load_scenario("evals/scenarios/fixtures/bad_deploy_0001.json") gold = Diagnosis(hypotheses=[ Hypothesis(cause=s.gold_cause, confidence=1.0, evidence=s.gold_evidence_refs) ]) print(render_postmortem(gold, title="Incident Postmortem (rendered from gold)")) PY ``` 重点不在于散文形式的文字——而在于 **`log #2`** 和 **`commit a1b2c3d`** 是指向真实信号的精确 handle，而不是复述。实时运行还会填充一行总结和建议操作，并在证据太弱而无法确定确切原因时直接弃权。 使用 `--out postmortem.md` 将事后分析写入文件，或者使用 `--out postmortem.html`（或 `--format html`）将其作为自包含的 HTML 页面——同样是确定性的渲染，无需外部资源。 ## 运行模型 推理器是任何 [LiteLLM](https://docs.litellm.ai/) 模型字符串，通过 `--model` 或 `QG_MODEL` 环境变量进行选择（默认为 `gemini/gemini-3.5-flash`）。Provider 的 key 由 LiteLLM 从环境中读取；不会在 repo 中存储任何内容。 ``` export QG_MODEL="gemini/gemini-3.5-flash" export GEMINI_API_KEY="…" uv run quellgeist diagnose --show-trace ``` 或者通过 [Ollama](https://ollama.com) 完全本地和离线运行——这是预期的家庭默认设置（DR-0008；确切的 artifact 固定在 DR-0019 中），无需 API key： ``` ollama pull qwen3:4b-instruct-2507-q4_K_M export QG_MODEL="ollama_chat/qwen3:4b-instruct-2507-q4_K_M" uv run quellgeist diagnose --show-trace ``` 注意 (DR-0012)：在未经验证、无计费项目上的 Gemini key 在当前模型上会返回 `429 limit: 0`，因此发布的 CI 门控被刻意设计为**无密钥**，而模型驱动的评估则受密钥控制并在**带外**运行 (DR-0015)。在家庭环境中，预期的默认推理器是通过 Ollama 运行的本地 **Qwen3-4B** (DR-0008)。 ### 运行评估（推理器 + verifier + LLM-judge） Fixture 评估使用确定性的关键词判断器 + 零伪造检查（无密钥门控）对推理器进行评分，并且还可以额外运行两个模型层 (DR-0016)：一个确认引用的证据是否支持每个假设的 **verifier**（否则强制弃权）和一个咨询性的 **LLM-judge** 评分标准。 ``` export GEMINI_API_KEY="…" export QG_MODEL="gemini/gemini-3.5-flash" QG_VERIFY=1 QG_JUDGE_LLM=1 \ QG_MIN_CALL_INTERVAL_S=6 \ # pace calls under the free-tier RPM (avoids 429 bursts) uv run python -m evals.run_evals ``` `QG_VERIFIER_MODEL` / `QG_JUDGE_MODEL` 会覆盖每一层的模型（默认为 `QG_MODEL`）。无法访问的后端（配额/503/超时）**或**被拒绝的凭证（缺失/无效/过期的 key）将被报告为 **skip**，而不是失败 (DR-0015/DR-0017)，因此带外评估绝不会因为免费层的短暂故障而变红。 LLM-judge 的分数是**咨询性的**（它们永远不会作为门控）。在带有真人标注的 gold 子集上，它使用独立的判断器（`groq/llama-3.1-8b-instant` ≠ 推理器）与真人达成了 **Cohen's kappa 0.81** 的一致性——已在该子集上验证 (DR-0018)；当 `QG_JUDGE_MODEL` 等于推理器时，它仍然是自我评分。 ## 在您的真实数据上使用它 该演示处理三个规范文件；您的生产信号看起来并非如此。`quellgeist ingest` 就是适配器——将其指向真实源，它就会写入工具读取的规范文件： ``` quellgeist ingest \ --logs /var/log/myapp/ # file or directory; JSONL, JSON, plain text, or mixed --deploys deploys.json # JSON array, GitHub payload, or `git log` text --metrics prom.json # a Prometheus response or a canonical array --out-dir ./signals # 打印 `export QG_*` 行；然后： quellgeist diagnose --show-trace --strict-citations # add --model / a provider key ``` 它能容忍混乱的真实数据（将外部字段名映射到 schema 上，将时间戳标准化为 UTC，强制转换格式错误的行而不是导致运行崩溃），并且 `query_logs` 限制了单次观察返回的行数（`QG_MAX_ROWS`，默认为 200），因此大型日志不会撑爆 context 窗口。确定性的引用或弃权保证在**实际使用时**运行：`diagnose` 会针对您的真实信号验证每个被引用的 handle，并在出现伪造时发出警告（`--strict-citations` 会以非零退出码退出供 CI 使用）。完整指南：[`docs/ingestion.md`](docs/ingestion.md)。 ## 状态与路线图 以**滚动 wave** 方式构建——只有当前的 wave 是详细实现的 （参见 [`docs/quellgeist-plan-rolling-wave.md`](docs/quellgeist-plan-rolling-wave.md)）。 完整的决策历史记录在 [**ADR log**](docs/quellgeist-adr-log.md) 中。 | Wave | 范围 | 状态 | |---|---|---| | 0 | 降低模型风险（4B 可以编排循环） | ✅ 完成 — 默认 = Qwen3-4B (DR-0008) | | 1 | 错误部署切片：演示 → 破坏 → 诊断 → 事后分析；评估工具 + CI | ✅ 完成 — 核心骨架已构建并经过单元测试 | | 2 | 可靠性核心：verifier 通过，确定性伪造检查，弃权，LLM-as-judge | ✅ 已构建 — 无密钥确定性门控 + 可选 verifier/judge；首次真实运行通过且零伪造 (DR-0016/DR-0017)。判断器验证 + 可靠性*比率*延续至 Wave 3 | | 3 | 广度：config/env + 资源耗尽类，指标，约 50 个场景 | ✅ 完成 — 跨越 65 个场景套件的 3 个类别；首次完整运行 **61/65，0 伪造**；判断器已验证 (kappa 0.81)。请参阅 [可靠性](docs/case-studies/wave3-reliability-rate.md) + [判断器](docs/case-studies/wave3-judge-validation.md) 案例研究 | | **4** | **成本 / 微调：QLoRA Qwen3-4B vs 基座模型 vs 前沿模型，带/不带 verifier** | ✅ **完成** — 基座 **0/16 → 微调后 12/16** 留出集（0 伪造，0 投机过滤器，比基座便宜）；与前沿模型相比具有竞争力，对比 Gemma-4-31B（在能力上以 10/16 胜出，在弃权上以 6/12 打平）；`resource_exhaustion` 遗忘 + 对抗性弃权是一个共同的 6/12 上限（[案例研究](docs/case-studies/wave4-qwen-finetune.md)，DR-0019/DR-0020） | | **5** | 打磨与发布：HTML 渲染，安全检查，MCP registry，发布 | 🚧 **工程完成 — 受发布门控**（HTML 渲染 + 安全扫描器 + 威胁模型 + registry/OIDC 基础架构已完成；发布标签 + 发布是剩余步骤） | | 6 | 解决方案验证循环 | ⤳ 合并至 v2 (Wave 9) | | **v2 (7+)** | 实时事故响应服务（webhook → 并发 worker → 持久化运行 → HITL 审查 → Slack/HTML → 沙盒解决方案重新检查）+ 可靠性轨道（时间感知 verifier，结构外泛化） | 🚧 已规划范围 — [DR-0023](docs/quellgeist-adr-log.md)，[spec](docs/quellgeist-v2-spec.md) | Wave 的边界是刻意为之的，并非未完成：只有 wave 是详细构建的，而后续的 wave 虽已规划范围，但刻意未实现。**v2 是在经过验证的 v1 核心之上的附加物——冻结的微调测量面永远不会被触及（[DR-0023](docs/quellgeist-adr-log.md)；由 `tests/frozen/` 保护）。** ## 可靠性门控 确定性的 CI 门控是可靠性契约：**247 个测试**（通过 pre-commit 使用 ruff + black，然后是 `pytest`——涵盖循环的永不崩溃 / 优雅弃权行为、确定性伪造检查和基于引用的判断器门控、verifier 和咨询性 LLM-judge、参数化场景生成、判断器验证工具、服务器过滤器、事后分析渲染器、基于 fixture 的评估工具、真实数据摄取 + 健壮性层，以及端到端的真实事故工具），在 Python 3.12 和 3.13 上运行。 在带外，**模型驱动的评估**在 65 个场景套件上运行推理器。最新的完整运行得分为 **61/65 通过，0 伪造证据** (Cerebras Gemma-4-31B)——分类细分 + 失败分析见 [可靠性案例研究](docs/case-studies/wave3-reliability-rate.md)。 ``` uv run pytest tests/ -q uv run pre-commit run --all-files ``` ## 开发与贡献 有关开发设置、约定和 wave 模型，请参阅 [CONTRIBUTING.md](CONTRIBUTING.md)；有关报告和无密钥 / 玩具演示策略的信息，请参阅 [SECURITY.md](SECURITY.md)；有关社区期望，请参阅 [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md)。Bug 报告和功能请求使用 [issue templates](.github/ISSUE_TEMPLATE)；PR 遵循 [PR template](.github/PULL_REQUEST_TEMPLATE.md)。 ## License [MIT](LICENSE) © Rajeev Shyam Kumar.
(Gemini or local Qwen, swappable)"] -. "chat completion" .-> loop subgraph loopbox["model-agnostic JSON-action ReAct loop"] loop["run_loop()
decide, call tool, observe, repeat"] end loop -- "query_logs" --> logs["logs tool
structured JSONL, stable ids"] loop -- "get_recent_commits" --> commits["commits tool
deploy_log.json, shas"] loop -- "query_metrics" --> metrics["metrics tool
time-series, named series"] logs -- "rows + ids" --> loop commits -- "commits + shas" --> loop metrics -- "series + names" --> loop loop --> diag["Diagnosis (schema.py)
ranked hypotheses citing
LogRef.id / CommitRef.sha / MetricRef.id, or abstains"] diag --> pm["postmortem renderer
deterministic Markdown"] diag --> judge["eval judge
fixture scenarios, CI gate"] ``` 这三个工具也都作为 **MCP server** 通过 stdio 公开 （`python -m quellgeist.servers.logs_mcp`、`…commits_mcp`、`…metrics_mcp`）。该 agent 目前在进程内复用 `ToolSpec` 注册表背后的相同工具*函数*；stdio MCP-*client* 路径（即 agent 通过网络驱动服务器）已列入路线图 (DR-0010)。 服务器会在每次标记的发布时发布到 **Official MCP Registry**（参见 [`docs/publishing.md`](docs/publishing.md)）；一旦发布，每个服务器都可以使用 `uvx --from quellgeist quellgeist-logs-mcp`（或 `…-commits-mcp` / `…-metrics-mcp`）运行。 ## 示例会话 注入错误部署——它会丢弃一个标记，将 `verify_token` 翻转为 NoneType 回归，并写入一个 `deploy_log.json`，其违规提交恰好在错误发生之前落地（说明性 `stdout`——时间戳反映您运行它的时间；路径相对于仓库根目录显示）： ``` $ uv run python -m demo.chaos.bad_deploy injected bad deploy a1b2c3d (touched demo/app/auth.py) at 2026-06-24T12:22:43Z marker: demo/.bad_deploy deploy log: demo/deploy_log.json next: hit /login to generate the 500s, then `quellgeist diagnose` ``` 在配置了推理器的情况下，`quellgeist diagnose` 会读取日志 + 部署并输出事后分析。CI 环境没有经过验证的模型 key (DR-0012)，因此下面的诊断是**从 gold 渲染**的——通过 `render_postmortem` 从 fixture 的标记原因和证据 handle 确定性地构建，*而不是*实时模型输出： ``` # Incident Postmortem (从 gold 渲染) ## Root-cause 假设 ### 1. Bad deploy a1b2c3d (10:01:50Z) 重构了 auth.py 并在 verify_token 中引入了 NoneType error；随后约 20 秒，/login 在 10:02:12Z 开始返回 500s。(confidence: 1.00) Evidence: - log #2 - commit a1b2c3d ``` 亲自重现该渲染（无需模型）： ``` uv run python - <<'PY' from evals.scenarios.generator import load_scenario from quellgeist.agent.schema import Diagnosis, Hypothesis from quellgeist.output.postmortem import render_postmortem s = load_scenario("evals/scenarios/fixtures/bad_deploy_0001.json") gold = Diagnosis(hypotheses=[ Hypothesis(cause=s.gold_cause, confidence=1.0, evidence=s.gold_evidence_refs) ]) print(render_postmortem(gold, title="Incident Postmortem (rendered from gold)")) PY ``` 重点不在于散文形式的文字——而在于 **`log #2`** 和 **`commit a1b2c3d`** 是指向真实信号的精确 handle，而不是复述。实时运行还会填充一行总结和建议操作，并在证据太弱而无法确定确切原因时直接弃权。 使用 `--out postmortem.md` 将事后分析写入文件，或者使用 `--out postmortem.html`（或 `--format html`）将其作为自包含的 HTML 页面——同样是确定性的渲染，无需外部资源。 ## 运行模型 推理器是任何 [LiteLLM](https://docs.litellm.ai/) 模型字符串，通过 `--model` 或 `QG_MODEL` 环境变量进行选择（默认为 `gemini/gemini-3.5-flash`）。Provider 的 key 由 LiteLLM 从环境中读取；不会在 repo 中存储任何内容。 ``` export QG_MODEL="gemini/gemini-3.5-flash" export GEMINI_API_KEY="…" uv run quellgeist diagnose --show-trace ``` 或者通过 [Ollama](https://ollama.com) 完全本地和离线运行——这是预期的家庭默认设置（DR-0008；确切的 artifact 固定在 DR-0019 中），无需 API key： ``` ollama pull qwen3:4b-instruct-2507-q4_K_M export QG_MODEL="ollama_chat/qwen3:4b-instruct-2507-q4_K_M" uv run quellgeist diagnose --show-trace ``` 注意 (DR-0012)：在未经验证、无计费项目上的 Gemini key 在当前模型上会返回 `429 limit: 0`，因此发布的 CI 门控被刻意设计为**无密钥**，而模型驱动的评估则受密钥控制并在**带外**运行 (DR-0015)。在家庭环境中，预期的默认推理器是通过 Ollama 运行的本地 **Qwen3-4B** (DR-0008)。 ### 运行评估（推理器 + verifier + LLM-judge） Fixture 评估使用确定性的关键词判断器 + 零伪造检查（无密钥门控）对推理器进行评分，并且还可以额外运行两个模型层 (DR-0016)：一个确认引用的证据是否支持每个假设的 **verifier**（否则强制弃权）和一个咨询性的 **LLM-judge** 评分标准。 ``` export GEMINI_API_KEY="…" export QG_MODEL="gemini/gemini-3.5-flash" QG_VERIFY=1 QG_JUDGE_LLM=1 \ QG_MIN_CALL_INTERVAL_S=6 \ # pace calls under the free-tier RPM (avoids 429 bursts) uv run python -m evals.run_evals ``` `QG_VERIFIER_MODEL` / `QG_JUDGE_MODEL` 会覆盖每一层的模型（默认为 `QG_MODEL`）。无法访问的后端（配额/503/超时）**或**被拒绝的凭证（缺失/无效/过期的 key）将被报告为 **skip**，而不是失败 (DR-0015/DR-0017)，因此带外评估绝不会因为免费层的短暂故障而变红。 LLM-judge 的分数是**咨询性的**（它们永远不会作为门控）。在带有真人标注的 gold 子集上，它使用独立的判断器（`groq/llama-3.1-8b-instant` ≠ 推理器）与真人达成了 **Cohen's kappa 0.81** 的一致性——已在该子集上验证 (DR-0018)；当 `QG_JUDGE_MODEL` 等于推理器时，它仍然是自我评分。 ## 在您的真实数据上使用它 该演示处理三个规范文件；您的生产信号看起来并非如此。`quellgeist ingest` 就是适配器——将其指向真实源，它就会写入工具读取的规范文件： ``` quellgeist ingest \ --logs /var/log/myapp/ # file or directory; JSONL, JSON, plain text, or mixed --deploys deploys.json # JSON array, GitHub payload, or `git log` text --metrics prom.json # a Prometheus response or a canonical array --out-dir ./signals # 打印 `export QG_*` 行；然后： quellgeist diagnose --show-trace --strict-citations # add --model / a provider key ``` 它能容忍混乱的真实数据（将外部字段名映射到 schema 上，将时间戳标准化为 UTC，强制转换格式错误的行而不是导致运行崩溃），并且 `query_logs` 限制了单次观察返回的行数（`QG_MAX_ROWS`，默认为 200），因此大型日志不会撑爆 context 窗口。确定性的引用或弃权保证在**实际使用时**运行：`diagnose` 会针对您的真实信号验证每个被引用的 handle，并在出现伪造时发出警告（`--strict-citations` 会以非零退出码退出供 CI 使用）。完整指南：[`docs/ingestion.md`](docs/ingestion.md)。 ## 状态与路线图 以**滚动 wave** 方式构建——只有当前的 wave 是详细实现的 （参见 [`docs/quellgeist-plan-rolling-wave.md`](docs/quellgeist-plan-rolling-wave.md)）。 完整的决策历史记录在 [**ADR log**](docs/quellgeist-adr-log.md) 中。 | Wave | 范围 | 状态 | |---|---|---| | 0 | 降低模型风险（4B 可以编排循环） | ✅ 完成 — 默认 = Qwen3-4B (DR-0008) | | 1 | 错误部署切片：演示 → 破坏 → 诊断 → 事后分析；评估工具 + CI | ✅ 完成 — 核心骨架已构建并经过单元测试 | | 2 | 可靠性核心：verifier 通过，确定性伪造检查，弃权，LLM-as-judge | ✅ 已构建 — 无密钥确定性门控 + 可选 verifier/judge；首次真实运行通过且零伪造 (DR-0016/DR-0017)。判断器验证 + 可靠性*比率*延续至 Wave 3 | | 3 | 广度：config/env + 资源耗尽类，指标，约 50 个场景 | ✅ 完成 — 跨越 65 个场景套件的 3 个类别；首次完整运行 **61/65，0 伪造**；判断器已验证 (kappa 0.81)。请参阅 [可靠性](docs/case-studies/wave3-reliability-rate.md) + [判断器](docs/case-studies/wave3-judge-validation.md) 案例研究 | | **4** | **成本 / 微调：QLoRA Qwen3-4B vs 基座模型 vs 前沿模型，带/不带 verifier** | ✅ **完成** — 基座 **0/16 → 微调后 12/16** 留出集（0 伪造，0 投机过滤器，比基座便宜）；与前沿模型相比具有竞争力，对比 Gemma-4-31B（在能力上以 10/16 胜出，在弃权上以 6/12 打平）；`resource_exhaustion` 遗忘 + 对抗性弃权是一个共同的 6/12 上限（[案例研究](docs/case-studies/wave4-qwen-finetune.md)，DR-0019/DR-0020） | | **5** | 打磨与发布：HTML 渲染，安全检查，MCP registry，发布 | 🚧 **工程完成 — 受发布门控**（HTML 渲染 + 安全扫描器 + 威胁模型 + registry/OIDC 基础架构已完成；发布标签 + 发布是剩余步骤） | | 6 | 解决方案验证循环 | ⤳ 合并至 v2 (Wave 9) | | **v2 (7+)** | 实时事故响应服务（webhook → 并发 worker → 持久化运行 → HITL 审查 → Slack/HTML → 沙盒解决方案重新检查）+ 可靠性轨道（时间感知 verifier，结构外泛化） | 🚧 已规划范围 — [DR-0023](docs/quellgeist-adr-log.md)，[spec](docs/quellgeist-v2-spec.md) | Wave 的边界是刻意为之的，并非未完成：只有 wave 是详细构建的，而后续的 wave 虽已规划范围，但刻意未实现。**v2 是在经过验证的 v1 核心之上的附加物——冻结的微调测量面永远不会被触及（[DR-0023](docs/quellgeist-adr-log.md)；由 `tests/frozen/` 保护）。** ## 可靠性门控 确定性的 CI 门控是可靠性契约：**247 个测试**（通过 pre-commit 使用 ruff + black，然后是 `pytest`——涵盖循环的永不崩溃 / 优雅弃权行为、确定性伪造检查和基于引用的判断器门控、verifier 和咨询性 LLM-judge、参数化场景生成、判断器验证工具、服务器过滤器、事后分析渲染器、基于 fixture 的评估工具、真实数据摄取 + 健壮性层，以及端到端的真实事故工具），在 Python 3.12 和 3.13 上运行。 在带外，**模型驱动的评估**在 65 个场景套件上运行推理器。最新的完整运行得分为 **61/65 通过，0 伪造证据** (Cerebras Gemma-4-31B)——分类细分 + 失败分析见 [可靠性案例研究](docs/case-studies/wave3-reliability-rate.md)。 ``` uv run pytest tests/ -q uv run pre-commit run --all-files ``` ## 开发与贡献 有关开发设置、约定和 wave 模型，请参阅 [CONTRIBUTING.md](CONTRIBUTING.md)；有关报告和无密钥 / 玩具演示策略的信息，请参阅 [SECURITY.md](SECURITY.md)；有关社区期望，请参阅 [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md)。Bug 报告和功能请求使用 [issue templates](.github/ISSUE_TEMPLATE)；PR 遵循 [PR template](.github/PULL_REQUEST_TEMPLATE.md)。 ## License [MIT](LICENSE) © Rajeev Shyam Kumar.
标签：AI智能体, AI风险缓解, DLL 劫持, MCP, 大语言模型, 安全规则引擎, 故障诊断, 运维监控, 逆向工具