prabhakaran-jm/failuredna
GitHub: prabhakaran-jm/failuredna
FailureDNA 是一个为事件响应智能体设计的故障感知记忆系统,通过记录并校验过往修复经验,防止智能体重复失败操作或复用过时方案。
Stars: 0 | Forks: 0
# FailureDNA
[](https://www.python.org/)
[](https://fastapi.tiangolo.com/)
[](https://github.com/pgvector/pgvector)
[](https://www.sqlalchemy.org/)
[](https://www.docker.com/)
[](https://www.alibabacloud.com/product/dashscope)
[](https://www.alibabacloud.com/product/functioncompute)
[](LICENSE)
FailureDNA 是一个为事件响应智能体设计的持久化经验记忆系统。它记录过去事件中成功和失败的修复操作,并在未来发生类似事件推荐该操作之前,检查每个已存储的操作是否仍然适用。
**在线演示:** [控制台](https://prabhakaran-jm.github.io/failuredna/) · **API:** [health/ready](https://prabhakaran-jm.github.io/failuredna/api) · **仓库:** [github.com/prabhakaran-jm/failuredna](https://github.com/prabhakaran-jm/failuredna)
## 为什么这很重要
事件响应智能体会重复犯错。当某个故障看起来很眼熟时,一个简单(naive)的智能体会检索出最*相似*的过往事件,并直接复用当时采取的操作——即使该操作**上次失败了**,或者**仅仅在后来已经发生变更的不同环境**(如数据库驱动、拓扑结构、配置)中成功过。重复失败的修复操作会浪费故障中最宝贵的时间;复用过时的修复方案可能会让情况变得更糟。
FailureDNA 赋予了智能体一种能够**积累真实结果**,并**推断过往经验是否仍然适用**的记忆能力。每个已解决的事件都会被作为一个片段(包含症状、环境指纹、采取的操作和结果)持久化保存。在下一次事件发生时,FailureDNA 会通过语义与关键词混合相似度来检索候选记忆,随后应用确定性的有效性验证门控,在 Qwen 智能体看到这些记忆之前,将每条记忆标记为 **use**(使用)、**inspect**(检查)或 **avoid**(避免)。最终的结果是,智能体会随着其经历的每一次事件在可衡量的程度上变得更好——并且能切实停止重复已知的错误操作。
## 技术栈
| 功能 | 服务 | 位置 |
|------------|---------|-------|
| 操作选择(已验证的 JSON) | 通过 Qwen Cloud / DashScope(兼容 OpenAI)的 Qwen 对话补全 | [app/qwen_client.py](app/qwen_client.py) |
| 用于语义召回的记忆 embeddings | Qwen `text-embedding-v3` | [app/embedding_client.py](app/embedding_client.py) |
| Serverless 后端 | 阿里云 Function Compute(自定义容器,端口 9000) | [docs/alibaba-cloud-deployment.md](docs/alibaba-cloud-deployment.md) |
| 持久化向量记忆 | ApsaraDB RDS for PostgreSQL + pgvector (HNSW) | [app/postgres_memory_store.py](app/postgres_memory_store.py) |
| 容器镜像 | ACR 个人版(用于 Function Compute 的自定义容器) | [Dockerfile](Dockerfile) |
智能体负责**选择**操作;它绝不决定某条记忆是否有效,也不决定操作的结果是什么。这些都是确定性的([app/retrieval.py](app/retrieval.py)),这也是保持系统安全和可审计的关键。
## 为什么仅靠向量相似度是不够的
症状相似度可以挖掘出相关的过往事件,但仅靠相似度无法告诉智能体一个以前成功的修复方案是否仍然适用,或者一个以前失败的操作是否应该被避免。在一个部署环境中有效增加连接池的操作,在数据库驱动或拓扑结构改变后可能就不再安全了。仅仅因为症状看起来相似,就不应该将曾经失败的“重启”操作给予高排名。FailureDNA 将症状重合度与基于操作结果和环境指纹的确定性有效性检查相结合,使智能体能够有针对性地 **use**(使用)、**inspect**(检查)或 **avoid**(避免)过往记忆。
## 架构概述
```
Incident -> Retrieval -> RetrievedMemory (use | inspect | avoid)
^
|
JsonlMemoryStore (episodes.jsonl)
^
|
Past episodes (symptoms, environment, action, outcome)
```
核心组件:
- `app/models.py` — 用于事件、环境、片段和检索结果的 Pydantic 模型
- `app/memory_store.py` — 片段的 JSONL 持久化
- `app/postgres_memory_store.py` — PostgreSQL + pgvector 持久化
- `app/retrieval.py` — 关键词检索和确定性处置
- `app/hybrid_retrieval.py` — 语义 + 关键词混合检索
- `app/embedding_client.py` — Qwen embedding 生成
- `app/factories.py` — 记忆存储和检索器工厂
- `app/simulator.py` — 用于演示和测试的确定性 `connection_pool_exhaustion` 场景
- `app/qwen_client.py` — 兼容 OpenAI 并带有验证的 Qwen 操作选择
- `app/decision_policies.py` — 确定性和实时决策策略
- `app/incident_runner.py` — 已验证的事件决策循环
- `app/main.py` — FastAPI HTTP API
- `scripts/run_demo.py` — 朴素检索与 FailureDNA 检索的端到端演示
- `scripts/run_comparison.py` — 对比 no_memory、naive 和 failuredna 模式
- `scripts/smoke_qwen.py` — 验证实时 Qwen 的连通性和延迟
FailureDNA 检索中的处置规则:
| 过往结果 | 环境匹配 | 处置方式 |
|---------------|-------------------|-------------|
| failure(失败) | any(任意) | avoid(避免) |
| success(成功) | full match(完全匹配) | use(使用) |
| success(成功) | 版本/驱动/拓扑/配置哈希已更改 | inspect(检查) |
## 设置
### Windows (Git Bash)
```
python -m venv .venv
source .venv/Scripts/activate
pip install -e .
cp .env.example .env
```
### Windows (PowerShell)
```
python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -e .
Copy-Item .env.example .env
```
### macOS
```
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
cp .env.example .env
```
### Linux
```
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
cp .env.example .env
```
如果你打算使用 Qwen 客户端,请编辑 `.env`。`QWEN_MODEL` 没有默认值,必须显式设置。
## 运行测试
```
pytest
```
单元测试会忽略本地的 `.env` 文件(`conftest.py` 会禁用 `load_dotenv`),因此开发凭据不会泄漏到测试流程中。在运行集成测试时,请显式 export 相关变量(见下文)。
## 运行演示
```
python -m scripts.run_demo
```
或者:
```
failuredna-demo
```
## 运行对比
在相同的预置历史记录上比较这三种记忆模式:
```
python -m scripts.run_comparison
```
使用实时的 Qwen 代替确定性策略:
```
python -m scripts.run_comparison --live-qwen
```
预期的确定性输出:
```
mode | actions selected | final success | repeated failed | stale successes | total actions | memory IDs used
------------+------------------------------------------+---------------+-----------------+-----------------+---------------+----------------
no_memory | restart_service -> inspect_downstream | True | 1 | 0 | 2 | -
naive | increase_connection_pool -> inspect_downstream | True | 0 | 1 | 2 |
failuredna | inspect_downstream | True | 0 | 0 | 1 |
```
## 事件决策循环
FailureDNA 可以运行一个完整的事件循环,其中决策策略选择修复操作,由模拟器决定结果。
### 记忆模式
| 模式 | 智能体看到的内容 | 行为 |
|------|---------------------|----------|
| `no_memory` | 没有历史片段 | 没有先前证据进行操作 |
| `naive` | 症状匹配的记忆,未经验证 | 仅依靠相似度;没有有效性过滤 |
| `failuredna` | 带有处置结果的症状匹配记忆 | 先前失败标记为 avoid;过时的成功标记为 inspect |
### Qwen 决策流程
1. 为选定的模式检索记忆。
2. 将症状、环境、候选操作和记忆发送给 Qwen。
3. 验证 JSON 响应(操作白名单、记忆 ID、置信度、理由)。
4. 输出格式错误时重试一次。
5. 仅通过模拟器执行已验证的操作。
6. 将模拟器的实际结果作为新片段进行持久化。
Qwen **不**决定模拟器的结果或记忆的有效性。FailureDNA 的检索规则保持确定性。
### 确定性本地模式
在 API 请求中设置 `use_live_qwen: false` 或在不加 `--live-qwen` 的情况下运行 `scripts/run_comparison`。不需要 Qwen API key。
### 实时 Qwen 模式
设置 `use_live_qwen: true` 并配置:
```
DASHSCOPE_API_KEY=
QWEN_BASE_URL=https://dashscope-intl.aliyuncs.com/compatible-mode/v1
QWEN_MODEL=
```
`QWEN_MODEL` 没有默认值,必须显式设置。
在运行实时比较之前验证连通性:
```
python -m scripts.smoke_qwen
```
预期输出:
```
Qwen connection successful
model: qwen3.5-plus
response: FailureDNA online
latency_ms:
```
实时的 Qwen 请求使用明确的 HTTP 超时设置(10秒 连接/写入/池,45秒 读取),并且 `max_retries=1`。思考模式已禁用(`enable_thinking: false`),因此操作决策会立即以 JSON 格式返回。决策补全使用 `temperature=0`,`max_tokens=256`,以及 `stream=false`。
**安全提示**
- 切勿粘贴包含真实 bearer token 的详细 `curl` 输出。
- 如果 API key 在日志、聊天或截图中暴露,请立即在 DashScope 控制台中对其进行轮换并更新 `.env`。
### 通过 API 运行事件
```
curl -X POST http://127.0.0.1:8000/api/run \
-H "Content-Type: application/json" \
-d '{
"scenario": "connection_pool_exhaustion",
"environment_version": "v2",
"mode": "failuredna",
"maximum_actions": 3,
"use_live_qwen": false
}'
```
## 启动 FastAPI
```
uvicorn app.main:app --reload
```
打开 http://127.0.0.1:8000/ 查看服务信息,或打开 http://127.0.0.1:8000/docs 查看交互式 API 文档。
### 实时控制台
**重要提示:** 阿里云 Function Compute 默认的 `*.fcapp.run` URL 会强制浏览器**下载** HTML 响应(`Content-Disposition: attachment`)。这是平台行为,而不是应用 Bug。在浏览器演示时,请使用以下方式之一:
| 选项 | URL |
|--------|-----|
| **GitHub Pages**(推荐) | 从 `docs/` 文件夹启用 Pages → `https://prabhakaran-jm.github.io/failuredna/` |
| FC HTTP 触发器上的**自定义域名** | 你的域名 → `/ui` 将内联呈现 |
| **本地** | `http://127.0.0.1:8000/ui` |
GitHub Pages 提供 `docs/index.html`(控制台的副本,内置了 Function Compute 后端 URL),因此裸 Pages URL 不需要任何查询字符串即可工作。来自 Pages 的跨域调用无需任何 CORS 环境变量即可工作:FC 网关会注入 `Access-Control-*` 头部,并且应用对 OPTIONS 预检请求返回 200。在演示时,将你的 `DEMO_API_TOKEN` 粘贴到控制台的 token 字段中(切勿将其提交到代码库)。要将页面指向不同的后端,请追加 `?api=https://your-fc-url`。
`https://failuredna-api-tdzfxzvevr.ap-southeast-1.fcapp.run` 上的 API 对于 `curl` 和 `scripts.smoke_deployed` 仍然有效;仅影响在默认 FC 域名上直接浏览导航至 `/ui`。
健康检查:
```
curl http://127.0.0.1:8000/health
```
## 预期的演示输出
```
Running incident 1 in environment v1...
symptoms: ['connection pool exhausted', 'database connection timeout errors', 'requests waiting for available connections']
Saved failed restart episode: restart_service (failure)
Saved successful pool episode: increase_connection_pool (success)
Running incident 2 with changed driver and topology...
driver: psycopg2 -> asyncpg
topology: single-region -> multi-region
Naive retrieval results
=======================
1. action=restart_service
baseline_status=unchecked
similarity=1.00
environment_score=0.67
outcome=failure
- Symptom keyword overlap score: 1.00
- Retrieved without outcome or environment validity checks
- Outcome was not used to filter or classify this memory
- Environment changes were not used to validate applicability
- unchecked means retrieved without safety or validity evaluation
2. action=increase_connection_pool
baseline_status=unchecked
similarity=1.00
environment_score=0.67
outcome=success
- Symptom keyword overlap score: 1.00
- Retrieved without outcome or environment validity checks
- Outcome was not used to filter or classify this memory
- Environment changes were not used to validate applicability
- unchecked means retrieved without safety or validity evaluation
FailureDNA retrieval results
============================
1. action=restart_service
disposition=avoid
similarity=1.00
environment_score=0.67
outcome=failure
- Symptom keyword overlap score: 1.00
- Environment match score: 0.67
- Prior attempt of 'restart_service' failed in a similar incident
- Evidence: Service restarted but connection pool exhaustion persisted
2. action=increase_connection_pool
disposition=inspect
similarity=1.00
environment_score=0.67
outcome=success
- Symptom keyword overlap score: 1.00
- Environment match score: 0.67
- Environment changed since the successful action: database_driver, topology
- Verify the prior success still applies before reusing this action
Key takeaways
=============
- Naive retrieval returns both episodes as UNCHECKED.
- FailureDNA marks restart_service as AVOID because it failed previously.
- FailureDNA marks increase_connection_pool as INSPECT because the environment changed.
```
## API 接口
| 方法 | 路径 | 描述 |
|--------|------|-------------|
| GET | `/` | 服务信息和接口列表 |
| GET | `/ui` | 实时交互式控制台 |
| GET | `/health` | 服务健康检查 |
| GET | `/api/memories` | 列出已存储的片段 |
| POST | `/api/memories` | 追加新片段 |
| POST | `/api/retrieve/naive` | 仅根据症状相似度对记忆进行排名 |
| POST | `/api/retrieve/failuredna` | 根据 use/inspect/avoid 处置方式对记忆进行排名 |
| POST | `/api/run` | 通过已验证的决策循环运行事件 |
| GET | `/api/benchmark/cases` | 列出基准测试用例元数据 |
| POST | `/api/benchmark/run` | 运行基准测试套件并写入产物 |
## 基准测试评估
FailureDNA 包含一个可重复的基准测试,它在多个事件历史和环境变化中对比了 `no_memory`、`naive` 和 `failuredna`。
### 基准测试目的
基准测试旨在衡量 FailureDNA 是否能在以下情况下改善修复决策:
- 应当避免过去的失败操作
- 过去的成功操作仍然有效
- 过去的成功操作在环境漂移后变得过时
- 历史记忆缺失、过期、失效或被取代
### 基准测试用例设计
用例定义在 `app/benchmark_cases.py` 中,涵盖了五种模拟器场景:
- `connection_pool_exhaustion`
- `expired_service_credentials`
- `downstream_dependency_latency`
- `database_driver_regression`
- `topology_routing_failure`
每个用例都会预置历史片段,定义当前环境,并包含仅供评估器使用的安全和不安全首次操作标签。决策策略永远不会看到这些标签。
### 智能体可见的证据与评估器标签的对比
智能体会接收症状、环境指纹、候选操作和检索到的。预期的安全和不安全的首次操作标签仅在一次运行完成后由基准测试评分器使用。
### 基准测试配置
| 配置 | 操作预算 | 目的 |
|---------|---------------|---------|
| `standard`(默认) | 所有候选操作(4) | 首要公平性基准测试 |
| `constrained` | 3 个操作 | 有限预算压力测试 |
```
python -m scripts.run_benchmark --profile standard
python -m scripts.run_benchmark --profile constrained
```
**Standard** 是 README 和摘要表中报告的主要基准测试。每种模式都可以尝试每一个候选操作,因此没有哪种模式会在结构上被阻碍达到 `inspect_downstream`。
**Constrained** 明确测量在三个操作预算下的行为。Constrained 的结果会单独标记,不会混入 Standard 的汇总数据中。
### 指标定义
| 指标 | 含义 |
|--------|---------|
| `resolution_rate` | 以模拟器成功结束的试验比例 |
| `eventual_resolution_rate` | 给定全部操作预算时该模式能否解决 |
| `first_action_resolution_rate` | 在第一个操作即解决的比例 |
| `correct_first_action_rate` | 第一个操作符合评估器“安全”标签 |
| `unsafe_first_action_rate` | 第一个操作符合评估器“不安全”标签 |
| `average_actions_executed` | 所有试验(包括失败试验)中执行的平均操作数 |
| `average_actions_to_success` | 仅在成功试验中执行的平均操作数(如果均未成功则为 `null`) |
| `median_actions_executed` | 所有试验中执行的操作数中位数 |
| `median_actions_to_success` | 在成功试验中的操作数中位数(如果均未成功则为 `null`) |
| `action_budget_exhausted_count` | 用尽全部预算仍未成功的试验数 |
| `historical_failed_action_repeated_count` | 选择的操作在本次运行之前的预置历史中曾失败过 |
| `stale_success_selected_count` | 选择的操作在预置历史中曾成功,但其有效性关键的环境字段现已不匹配 |
| `invalid_decision_count` | 无效或格式错误的决策错误 |
`/api/run` 响应中的 `repeated_failed_action_count` 已弃用,是 `historical_failed_action_repeated_count` 的别名。
### 确定性基准测试
```
python -m scripts.run_benchmark
python -m scripts.run_benchmark --profile standard
python -m scripts.run_benchmark --profile constrained
python -m scripts.run_benchmark --trials 5
python -m scripts.run_benchmark --case pool-stale-driver-01
python -m scripts.run_benchmark --mode naive --mode failuredna
```
不需要 Qwen API key。
### 实时 Qwen 基准测试
```
python -m scripts.run_benchmark --live-qwen --trials 3
```
需要 `DASHSCOPE_API_KEY`、`QWEN_BASE_URL` 和 `QWEN_MODEL`。
### 生成的产物
每次运行都会写入 `benchmark_results//`:
- `records.jsonl` — 每个用例、模式或快捷基线以及试验对应一条记录
- `summary.json` — 模式摘要和快捷基线摘要
- `summary.csv` — 主要模式的汇总行
- `case_audit.json` — 仅限评估器使用的操作分布审计
- `integrity_report.json` — 基准测试完整性检查
- `README.md` — 运行元数据、审计和汇总表
生成的基准测试目录已在 gitignore 中忽略。
### 快捷基线审计
四个仅限评估器使用的静态基线会与主要的三模式表格分开报告:
- `always_restart_service`
- `always_rotate_credentials`
- `always_increase_connection_pool`
- `always_inspect_downstream`
它们从不访问记忆或预期标签。它们的存在是为了证明 FailureDNA 并不是仅仅因为某一个操作通常是正确的而获胜。
### 确定性与实时 Qwen 的隔离
确定性记录和实时 Qwen 记录永远不会合并在一起。摘要按 `execution_type` 分组,而实时摘要可能还会按 `model_name` 分组。
### 如何解读结果
一个表现强劲的 FailureDNA 结果应该显示:
- 最终解决率与其他模式相似或更好
- 更高的首个操作解决率
- 平均执行的操作更少
- 重复的历史失败更少
- 选择的过时成功更少
- 不依赖于某个普遍成功的操作
比较 `average_actions_executed`(所有试验)和 `average_actions_to_success`(仅成功试验)。即使一种模式最终能够解决问题,它仍可能将操作浪费在不安全的首次选择上。
### 为什么基准测试是公平的
- 所有三种模式都从完全相同的事件历史开始。
- 模拟器结果对所有决策策略都是隐藏的。
- 预期的安全和不安全操作是仅供评估器使用的标签。
- 每种模式都有一个独立的记忆存储。
- 确定性和实时 Qwen 结果分开报告。
- 没有任何模式能看到另一种模式生成的片段。
## 记忆后端与混合检索
FailureDNA 支持两种持久化记忆后端和两种检索引擎。
### 后端
| 设置 | 后端 | 用例 |
|---------|---------|----------|
| `MEMORY_BACKEND=jsonl`(默认) | JSONL 文件 | 本地开发、测试、演示 |
| `MEMORY_BACKEND=postgres` | PostgreSQL + pgvector | 生产部署 |
### 检索引擎
| 设置 | 引擎 | 行为 |
|---------|--------|----------|
| `RETRIEVAL_ENGINE=keyword`(默认) | 关键词重合度 | 现有的朴素/FailureDNA 行为 |
| `RETRIEVAL_ENGINE=hybrid` | 语义 + 关键词 | 需要 PostgreSQL 和 embedding 配置 |
混合检索结合了:
- **语义相似度**(默认权重 `0.70`),来自 pgvector 余弦搜索
- **关键词重合度**(默认权重 `0.30`),来自症状 token 重合
对于关键词模式:
- `semantic_similarity` 为 `null`
- `combined_similarity` 等于 `keyword_similarity`
对于混合模式:
- `combined_similarity = 0.70 * semantic + 0.30 * keyword`
在候选记忆排名之后,FailureDNA 仍会应用确定性的生命周期、结果和环境规则。Qwen 绝不决定记忆是否有效。
### 架构:从混合检索到操作决策
```
Incident
-> query embedding
-> pgvector candidate search
-> keyword and semantic score fusion
-> deterministic lifecycle and validity gate
-> bounded context allocation
-> Qwen action decision
```
向量相似度可以找到潜在相关的经验。FailureDNA 决定该经验是应该被使用、检查还是避免。仅靠相似度绝不能覆盖失败的结果或过时的环境。
### 环境变量
```
MEMORY_BACKEND=jsonl
DATABASE_URL=
RETRIEVAL_ENGINE=keyword
QWEN_EMBEDDING_MODEL=text-embedding-v3
QWEN_EMBEDDING_DIMENSIONS=1024
EMBEDDING_TIMEOUT_SECONDS=30
MAX_RETRIEVED_MEMORIES=8
```
`RETRIEVAL_ENGINE=hybrid` 需要 `MEMORY_BACKEND=postgres`、`DATABASE_URL` 以及 Qwen embedding 配置。应用程序在启动时不会创建数据库表;请使用 Alembic 迁移。
### 本地 pgvector PostgreSQL
```
docker compose up -d postgres
cp .env.docker.example .env
alembic upgrade head
```
开发凭据仅存在于 `.env.docker.example` 和 `docker-compose.yml` 中。切勿提交生产凭据或 API key。
### Alembic 迁移
```
alembic upgrade head
alembic downgrade -1
```
`DATABASE_URL` 从环境中读取。Alembic 配置不存储凭据。
### 将 JSONL 迁移到 PostgreSQL
```
python -m scripts.migrate_jsonl_to_postgres --source data/episodes.jsonl --dry-run
python -m scripts.migrate_jsonl_to_postgres --source data/episodes.jsonl --yes
python -m scripts.migrate_jsonl_to_postgres --source data/episodes.jsonl --yes --generate-embeddings
```
迁移脚本绝不会删除源 JSONL 文件。使用 `--skip-existing` 可忽略重复的片段 ID。
### 健康检查端点
`GET /health` 返回:
- `status`(`ok` 或 `degraded`)
- `memory_backend`
- `retrieval_engine`
- `database_reachable`
- `embedding_configured`
- `qwen_configured`
响应中绝不包含数据库 URL、凭据、API key 或原始异常堆栈。
### 集成测试
默认的 `pytest` 不需要 Docker 或 PostgreSQL。要在本地 pgvector 实例上运行集成测试:
```
docker compose up -d postgres
export DATABASE_URL=postgresql+psycopg://failuredna:failuredna@localhost:5433/failuredna
export MEMORY_BACKEND=postgres
alembic upgrade head
pytest -m integration
```
## 生产容器
构建用于阿里云 FC 的 Linux AMD64 生产镜像(`BUILDX_NO_DEFAULT_ATTESTATIONS` 可避免生成 FC 拒绝的证明清单):
```
export BUILDX_NO_DEFAULT_ATTESTATIONS=1
docker buildx build --platform linux/amd64 --provenance=false --sbom=false -t failuredna:local --load .
```
在端口 9000 上本地运行:
```
docker run --rm -p 9000:9000 --env-file .env failuredna:local
```
端口参考:
| 目标 | 端口 |
|--------|------|
| 本地 Docker Compose PostgreSQL 主机映射 | 5433 |
| Docker Compose PostgreSQL 服务内部端口 | 5432 |
| 阿里云 RDS PostgreSQL | 5432 |
| FailureDNA 应用容器 | 9000 |
### 健康检查接口
| 接口 | 用途 |
|----------|---------|
| `GET /health/live` | 仅检查进程存活状态 |
| `GET /health/ready` | 依赖项就绪状态及安全的检查详情 |
| `GET /health` | 向后兼容的摘要健康状态 |
就绪检查会验证 PostgreSQL、pgvector schema、Alembic 版本以及 Qwen 或 embedding 配置,且不会产生付费的模型调用。
### 演示令牌认证
设置 `DEMO_API_TOKEN` 后,受保护的接口需要 `X-Demo-Token` 请求头:
- `POST /api/run`
- `POST /api/benchmark/run`
- `POST /api/memories`
诸如 `/health/live`、`/health/ready` 和 `GET /api/benchmark/cases` 等公共接口仍可正常访问。
### 云端预检和部署的冒烟测试
```
python -m scripts.preflight_cloud
python -m scripts.preflight_cloud --skip-database
python -m scripts.preflight_cloud --json
python -m scripts.smoke_deployed --base-url http://127.0.0.1:9000
python -m scripts.smoke_deployed --base-url https://example-function-url --demo-token "$DEMO_API_TOKEN"
```
### 部署文档
- [docs/architecture.md](docs/architecture.md)
- [docs/alibaba-cloud-deployment.md](docs/alibaba-cloud-deployment.md)
- [deploy/alibaba/function-compute.env.example](deploy/alibaba/function-compute.env.example)
- [deploy/alibaba/s.yaml.example](deploy/alibaba/s.yaml.example)
## 许可证
请参阅仓库根目录下的 `LICENSE` 文件。
标签:AI智能体, AV绕过, FastAPI, PostgreSQL, Python, 无后门, 测试用例, 记忆系统, 请求拦截, 运维, 逆向工具