2026-03-27-daily-llm-routing-and-loop-prevention

今日变更速览

今天对 Agent 服务做了几处小修，核心围绕两个目标：降低成本和防止死循环。

1. LLM 路由重构 (cli.ts)

移除了 DeepSeek 和 Ark 相关代码，新增两条路径：

• 本地 Qwen (LM Studio)：用于简单逻辑任务，走 localhost:1234
• GLM-5 (OpenAI 兼容端点)：用于复杂逻辑，默认走 OPENAI_BASE_URL

这波操作很直接——既然本地跑得动就不调贵的 API。但问题也随之而来：本地模型能不能撑起复杂任务？目前看来是做了 fallback 降级策略：glm-5 是默认项，qwen 则是可选加速层。

2. 评估结果增强 (evaluate/handler.ts)

新增 loopable 字段：分数 >=55 就允许循环重试，低于 55 则不允许。

这个阈值定得有点随意。55 分怎么来的？依据是什么？没有人解释。

3. Executor 智能跳过 (executor/handler.ts)

新增 checkRepoHasTests() 函数：如果仓库没有测试文件，就跳过 testCommand。

这个优化看起来合理，但有个隐患：如果有人故意不放测试文件是不是就能绕过验证？目前看来只是"跳过"，不是"报错"，风险可控但不够严谨。

4. Reflect 循环检测 (reflect/handler.ts)

改进 suggestImprovements()：统计 actionResults 中的重复错误，超过 2 次就返回"停止循环，需人工介入"。

这是今天最有价值的改动。之前的版本只会给建议，现在直接打断循环，防止 Agent 在同一个坑里反复跌倒。

5. Triage 优化 (triage/handler.ts)

Fallback 路径：如果 LLM 调用失败且类别是 "testing"，直接 skip 而不是 proceed_to_plan。

---

反思：过度优化还是合理收敛？

这一轮的改动总体偏"防守"——不是进攻型功能，而是止血和省钱。

但有几个问题值得问：

1. 55 分阈值：谁定的？为什么不是 50 或 60？没有 A/B 测试支撑的阈值就是拍脑袋。
2. 本地 Qwen：在真实生产环境中，本地模型的稳定性如何保障？断电、OOM、模型加载失败这些情况考虑了吗？
3. 跳过测试的逻辑：有没有可能误判？比如一个仓库有测试但路径不标准就被跳过了？

---

English Summary

Today's changes focus on cost reduction and loop prevention:

1. LLM Routing: Removed DeepSeek/Ark, added local Qwen + GLM-5 as new defaults
2. Evaluation: Added loopable field (>=55 points enables retry)
3. Executor: Added checkRepoHasTests() to skip testCommand for repos without tests
4. Reflect: Added repeat-error detection to stop infinite loops after 2+ failures
5. Triage: Skip "testing" category on fallback

The overall direction is defensive—cutting costs and preventing wasted cycles. But some thresholds (like 55 points) feel arbitrary without solid justification.