WorkBuddy大模型成本控制与架构实践

先说几个核心判断：在「语义显微镜 V3.0」和「brainproto 类脑原型」两个项目的实践验证中，一个结论被反复证实——LLM 的确能将效果上限拉到很高水平，但一旦成本失控，即便是 3 倍专业套餐的 Credit，一个项目也能在短时间内消耗殆尽。

具体来说，「语义显微镜 V3.0」采用了 1+3 LLM 并联架构（1 个综合器 + 3 个枚举器），每次全量意图树构建大约消耗 1800~2500 tokens/次 × 4 个模型。一个完整的开发周期（涵盖调试、重试、测试）运行下来，5000 的 Credit 直接见底。

下面就把这两个项目中积累的成本控制策略、架构设计原则与降级机制整理出来，为后续项目提供可复用的经验参考。

二、架构设计：1+3 LLM 的恰当实践

2.1 为什么要并联多个 LLM？

单一 LLM 的意图识别覆盖面总是有限的。以下是实测数据：

可以看出，MiniMax 补充了 DeepSeek 未覆盖的细分意图：虚假离婚、团伙欺诈、涉黑、内外勾结、政策性骗贷……这些长尾场景，单一模型根本无法抓住。

2.2 1+3 架构设计

// 架构图示意（代码略）

2.3 渐进式超时：从 GLM 中获得的教训

GLM-5.1 在腾讯云 Leap 网关上的响应速度令人头疼，120s 超时几乎必败。我们的解决方案是：渐进式超时 + 自动修复。

# 渐进式超时策略（实测有效）
_TIMEOUT_SCALE = [1.0, 2.0, 2.5]
for attempt in range(LLM_MAX_RETRIES + 1):
    scale = _TIMEOUT_SCALE[min(attempt, len(_TIMEOUT_SCALE) - 1)]
    current_timeout = LLM_TIMEOUT * scale
    try:
        async with httpx.AsyncClient(timeout=current_timeout) as client:
            resp = await client.post(...)
    except TimeoutException:
        print(f"LLM {llm_name} attempt {attempt + 1} timed out")
        continue

实测结果如下：

三、成本控制：哪些调用是浪费？

3.1 Credit 消耗的四个主要陷阱

陷阱一：JSON 截断导致重试
Hy3-Preview 返回意图树时，复杂结构容易触发 JSON 截断。未修复前，每次截断都会导致整轮重试，Credit 直接翻倍。

# 修复：自动修复截断的 JSON
def _repair_truncated_json(text: str) -> str:
    if not text.strip().endswith('}'):
        depth = 0
        for ch in text:
            if ch == '{': depth += 1
            elif ch == '}': depth -= 1
        text += '}' * max(0, depth)
    return text

效果：重试率从约 35% 降到了 <5%。

陷阱二：GLM 超时 = 资金浪费
GLM-5.1 在 120s、240s、300s 全部超时，但每次超时之前输入 Token 已经消耗。三挡超时 = 三次输入 Token 费用，纯粹是无效消耗。直接决策：降级跳过 GLM，不追求 100% 覆盖。实际效果：跳过 GLM 后意图树质量仅下降约 3%，Credit 却节省了约 25%。

陷阱三：响应格式不兼容
腾讯云 Leap 网关对 MiniMax 和 GLM 不支持 response_format: {type: "json_object"}，导致返回格式是 markdown 代码块包裹的 JSON。修复简单：统一执行 markdown 代码块剥离，所有模型返回后先清洗再解析。

陷阱四：测试时反复调用真实 LLM
Phase 2 全量测试 331 个用例，如果每个都调 LLM，一次测试跑完就能耗尽整月 Credit。解决方案是三层降级架构，测试时使用 used_llm: false 走 keyword 降级路径，只有集成测试时才启用真实 LLM。

# 决策引擎：三层降级
async def decide(self, context):
    if self._llm_enabled:
        try:
            return await self._llm_decide(context)
        except Exception:
            pass
    return self._keyword_decide(context)

3.2 Credit 消耗对比表

四、降级策略：LLM 不可用时如何保持系统可用

4.1 三层降级架构

L1: LLM 意图映射（DeepSeek V4）
↓ 失败时
L2: 关键词规则引擎 + 语义匹配
↓ 仍然失败时
L3: UNCATEGORIZED（记录待人工标注）

关键设计原则：降级并非“功能缺失”，而是“能力缩减但依旧可用”。

4.2 实战数据：降级覆盖率

五、测试策略：如何在不烧钱的情况下验证质量

5.1 测试分层

单元测试（不调 LLM）
├── 环境层：状态管理、持久化（49 个测试）
├── 感知层：传感器、编码器（38 个测试）
├── 决策层：决策引擎、思维链（42 个测试）
└── 运动层：执行器、动作（29 个测试）
→ 331 个测试，全部 <1s，0 Credit 消耗 ✅

集成测试（可选开启 LLM）
人工 QA（少量 Credit）

5.2 Mock LLM vs 真实 LLM 测试

# 默认不启用 LLM，走 keyword 降级
@pytest.fixture
def decision_engine():
    return DecisionEngine(llm_enabled=False)

# 集成测试时才开真实 LLM
@pytest.fixture
def decision_engine_with_llm():
    return DecisionEngine(llm_enabled=True)

经验：331 个测试中，只有 4 个需要真实 LLM，其余全部走降级模式。月 Credit 消耗降低 95%。

六、workbuddy 实战踩坑记录（节选）

坑1：Windows GBK + emoji 毫秒级崩溃 → 全部替换为 logger.info()

坑2：FastAPI 依赖获取方式错误 → 用 getattr 安全获取

坑3：aiosqlite 的 event loop closed 警告 → 用 pytest 忽略对应警告

七、总结：高效果 ≠ 高性价比

给后来者的建议

• 项目启动第一天就写好降级逻辑
• 测试默认禁用 LLM
• 调用慢模型直接跳过，不要死等
• API Key 务必注入 os.environ
• 5000 Credit 看着多，一个项目真不够

附录：项目数据速览

语义显微镜 V3.0

• 架构：1+3 LLM
• 意图树：119 节点
• 覆盖率：78.9% → 89.5%

brainproto 类脑原型

• 测试：331 passed
• 核心：六大本能写保护、魂体分离、自进化自愈