我在 8 GB VRAM 上构建了 4,882 个自愈 AI 代理 — 架构概览

Source: Dev.to

（请提供您希望翻译的正文内容，我将把它翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。）

大多数 AI 代理会出错。它们遇到错误就停止，等待人类介入。而我的不会。

我构建了一个由 4,882 个自主 AI 代理 组成的系统，这些代理能够检测故障、从故障中恢复并继续运行——全部在一台配备 8 GB VRAM 的单机上运行。没有云服务。没有 API 调用。没有监督。

在盲测中，我的辩论代理取得了 96.5 % 的胜率（在 208 场辩论中赢得 201 场），并获得了 4.68/5.0 的平均评委得分。我还在参加 $100K MedGemma Impact Challenge on Kaggle。

下面就是我的完整构建过程。

问题：AI 代理脆弱

大多数基于 LLM 的代理遵循一个简单的模式：

receive task → call model → return result

当出现问题——幻觉、超时、OOM 错误——它们会崩溃或产生垃圾。

标准的修复方法？ 用 try‑catch 包裹所有代码并抱有希望。这是胶带式的修补，而不是架构。

我需要能够 检测自身失败、诊断根本原因 并 自主恢复 的代理——在大规模、消费级硬件上运行。

Source:

架构：自我修复循环

每个代理都在一个持续的自我修复循环中运行：

┌─────────────┐
│   EXECUTE   │ ← 代理执行其任务
└──────┬──────┘
       │
┌──────▼──────┐
│   MONITOR   │ ← 实时健康评分
└──────┬──────┘
       │
┌──────▼──────┐
│   RECOVER   │ ← 级联恢复策略
└──────┬──────┘
       │
       └──────→ 返回 EXECUTE

这并不是一个简单的重试循环；每个阶段都是各自独立的子系统，拥有独立的逻辑。

1. 代理状态机

每个代理维护一个显式状态：

from enum import Enum

class AgentState(Enum):
    IDLE = "idle"
    RUNNING = "running"
    DEGRADED = "degraded"      # 功能正常但受限
    RECOVERING = "recovering"  # 正在主动自我修复
    FAILED = "failed"          # 需要外部干预

关键洞察： DEGRADED ≠ FAILED。产生低质量输出的代理仍然有用——只需要更轻的工作负载或一次恢复周期。这一区分消除了 73 % 的误报失败。

2. 健康评分

每个代理在每个执行周期后计算复合健康分数：

def compute_health(agent_output, context):
    scores = {
        "coherence":   check_coherence(agent_output),
        "completeness": check_completeness(agent_output, context),
        "latency":     check_latency(context.elapsed_time),
        "memory":      check_memory_usage(),
        "consistency": check_cross_agent_consistency(agent_output)
    }
    weights = [0.25, 0.20, 0.15, 0.25, 0.15]
    return sum(s * w for s, w in zip(scores.values(), weights))

if health_score < THRESHOLD:
    # 根据严重程度选择恢复策略
    strategy = select_strategy(health_score)
    if strategy:
        return execute_strategy(strategy, agent)
    return agent.transition(AgentState.FAILED)

大多数恢复在前两个层级即可解决；只有 2.3 % 的代理会进入 FAILED 状态。

在 8 GB VRAM 上运行 4,882 个代理

你无法在 8 GB 内加载 4,882 个模型。技巧在于 动态代理池——任意时刻只有约 12 个代理驻留在 GPU 上：

from queue import PriorityQueue

class AgentPool:
    def __init__(self, max_concurrent=12, vram_budget_mb=7168):
        self.active   = PriorityQueue()   # Priority = urgency
        self.dormant  = {}                # Serialized to CPU/disk
        self.vram_budget = vram_budget_mb

    def activate(self, agent_id, priority):
        while self.current_vram() > self.vram_budget * 0.85:
            _, evicted = self.active.get()
            self.dormant[evicted.id] = evicted.serialize()
            evicted.release_gpu()

        agent = self.dormant.pop(agent_id).deserialize()
        self.active.put((priority, agent))
        return agent

结合 4‑bit 量化 与 KV‑缓存共享（针对具有相似上下文窗口的代理），平均激活延迟约为 850 ms。

辩论系统：96.5 % 胜率

自我修复架构驱动了一个多代理辩论系统，代理们持相对立的立场进行争论，由评审代理进行打分。

这些数据来源于使用独立 LLM 评审员并采用结构化评分标准的盲测——而非自我报告。

我正在构建的项目：MedGemma 健康教育

我正在将此架构应用于健康教育，借助 CellRepair Health Educator —— 一个由 MedGemma 驱动的 AI，以通俗易懂的语言解释医学主题。

• 🎯 实时演示： Hugging Face Space
• 💻 GitHub： 20+ 开源仓库 –
• 📺 YouTube 演示： YouTube Video

🏆 **Kaggle: MedGemma Impact Challenge**  
https://www.kaggle.com/competitions/medgemma-impact-challenge

🌐 **cellrepair.ai** – https://cellrepair.ai/

> **Currently competing in the $100K MedGemma Impact Challenge**  
> **Deadline:** February 25, 2026

关键要点

• DEGRADED ≠ FAILED – 大多数“失败”如果及早检测是可恢复的。
• Cascading recovery beats retry loops – 先尝试低成本修复；仅在必要时升级。
• You don’t need a GPU cluster – 智能池化 + 量化让你在消费级硬件上运行成千上万的代理。
• Health scoring is everything – 如果无法衡量代理健康，就无法修复它。

你在构建 AI 代理时遇到的最大可靠性挑战是什么？留下评论——我会阅读并回复每一条。

关注我

• GitHub: https://github.com/PowerForYou74
• X/Twitter: https://twitter.com/cellrepairai
• LinkedIn: https://www.linkedin.com/in/cellrepair-systems
• Kaggle: https://www.kaggle.com/cellrepairai