先说几个核心判断：在「语义显微镜 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 的意图识别覆盖面总是有限的。以下是实测数据：
LLM 模型 |
意图节点数 |
正向 |
灰色 |
负向 |
特性 |
|---|---|---|---|---|---|
DeepSeek V4（单跑） |
110 |
40 |
29 |
41 |
基础覆盖 |
MiniMax M2.7（单跑） |
187 |
65 |
49 |
73 |
补充细分场景 |
共识后 |
119 |
44 |
31 |
44 |
互补去重 |
可以看出，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实测结果如下：
模型 |
120s |
240s |
300s |
结论 |
|---|---|---|---|---|
DeepSeek V4 |
✅ |
- |
- |
稳定 |
MiniMax M2.7 |
✅ |
- |
- |
稳定 |
GLM-5.1 |
❌ |
❌ |
❌ |
基本不可用 |
Hy3-Preview |
✅ |
- |
- |
需加大 max_tokens |
三、成本控制：哪些调用是浪费？
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 消耗对比表
场景 |
单次消耗 |
次数/天 |
日消耗 |
月消耗 |
|---|---|---|---|---|
意图树全量构建（4 LLM） |
~8000 tokens |
3 次 |
24K |
720K |
单条对话意图映射 |
~2000 tokens |
50 次 |
100K |
3M |
测试降级模式 |
0 |
- |
0 |
0 ✅ |
5000 Credit 套餐 |
- |
- |
- |
~3.7M tokens |
四、降级策略：LLM 不可用时如何保持系统可用
4.1 三层降级架构
L1: LLM 意图映射（DeepSeek V4）
↓ 失败时
L2: 关键词规则引擎 + 语义匹配
↓ 仍然失败时
L3: UNCATEGORIZED（记录待人工标注）关键设计原则：降级并非“功能缺失”，而是“能力缩减但依旧可用”。
4.2 实战数据：降级覆盖率
层级 |
覆盖率 |
备注 |
|---|---|---|
L1（LLM） |
78.9% |
需 DeepSeek API Key 注入 os.environ |
L2（keyword） |
89.5% |
关键词库 27+19+33=79 条 |
L3（UNCATEGORIZED） |
100% |
兜底 |
五、测试策略：如何在不烧钱的情况下验证质量
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 架构 |
4 模型并联 |
1 主 + 1 备 + 降级 |
超时策略 |
固定 30s |
渐进式 120s→300s |
测试策略 |
每次调真实 LLM |
Mock 优先 |
降级深度 |
无降级 |
三层降级 |
月 Credit 消耗 |
~3.7M |
~0.8M（节省 78%） |
给后来者的建议
- 项目启动第一天就写好降级逻辑
- 测试默认禁用 LLM
- 调用慢模型直接跳过，不要死等
- API Key 务必注入 os.environ
- 5000 Credit 看着多，一个项目真不够
附录：项目数据速览
语义显微镜 V3.0
- 架构：1+3 LLM
- 意图树：119 节点
- 覆盖率：78.9% → 89.5%
brainproto 类脑原型
- 测试：331 passed
- 核心：六大本能写保护、魂体分离、自进化自愈
