LLM 数据分析系统

2026.04 — 2026.05 1 人

LLM Multi-Agent Python Concurrency

                  ┌── Root Agent（最终报告）
                  │
            ┌─────┴─────┐
            │           │
       Middle Agent  Middle Agent  ...
            │           │
       ┌────┴────┐  ┌──┴───┐
      Leaf    Leaf  Leaf  Leaf  ...
    （每节点 ~100 条）

问题

如何将百万级数据喂给上下文窗口有限的 LLM？直接塞进去会撑爆，切片又会丢失跨切片关联。

方案：树状多 Agent 架构

Leaf Agent：每个只处理约 100 条数据，上下文始终可控。
Middle Agent：递归压缩 Leaf 输出，保留跨切片关联。
Root Agent：收到的始终是能在单个上下文窗口内处理的摘要。

核心创新：双管线架构

高度压缩有丢失关键信息的风险。解决方案：拆成两条独立管线。

管线 A：语义理解专家

压缩和总结语义，经 Middle → Root 汇总。

管线 B：信息提取专家

逐字提取关键事实，不做任何压缩，绕过 Middle 层直接注入最终报告。

幻觉控制：Regex 海选 + LLM 打分

LLM 无法保证一字不差地提取信息。分工方案：

原始数据 → 宽泛 Regex（宁可多抓不可漏）→ LLM 逐条打分 → 高分保留

结果：零信息遗漏（Regex 保证召回率），90%+ 去噪率（LLM 负责精度）。

并发控制：三次迭代走向稳定

方案 A：自由抢占令牌 (失败)

100 个令牌，Leaf 和 Middle 自由抢占 → 持续高并发 → 上游 LLM 服务被打爆。

方案 B：加权令牌 (部分改善)

Leaf = 1 个令牌，Middle = 10 个令牌。有所改善，但上游不稳定的问题未解决。

方案 C：动态令牌 + 超时退避 (最终采用)

遇到超时立即停止派发新令牌 → 等待当前任务完成 → 单独重试超时任务（独占全部资源）→ 成功后恢复。超时任务极少（由数据本身难度导致，非并发过高），暂停影响可忽略。

核心心得

严格职责分离：LLM 负责压缩语义和打分，脚本负责精确提取，人负责去噪。需要精度的事情绝不能交给 LLM。
一个 Agent 只做一件事：和面向对象的单一职责原则一样——拆开就不会混乱。
AI Coding 让快速试错成为可能：一个下午就能测试五六种并发方案。没有 AI 辅助，这需要数周。