Agent 连续工作几十轮后，麻烦才出现

过去一年，我看过不少 Agent 项目。演示通常很顺：接一个模型，挂几个工具，再补上记忆，Agent 就能开始干活。

可当它真的替你改文件、发消息、部署服务，并连续工作几十轮，麻烦才出现：

程序重启后怎么接着做？ 用户突然插话会不会打乱任务？ 一次失败重试，会不会把邮件发两遍？ 网页里藏着提示注入，它会不会顺手执行？ 简单问题和复杂任务，又该怎样分配模型预算？

如果说你想自己要开发智能路由型、或者融合模式型agent，那么OpenSquilla如下设计值得学习和参考

OpenSquilla 吸引我的地方，是它把这些问题都收进了同一套 Runtime。

Web、CLI、Channel 最终汇入同一条 TurnRunner；同一会话串行执行，不同会话可以并发。Goal Mode 把目标、验收条件和证据叠加在普通会话上，完成前必须逐项核验。工具可能已经产生副作用时，失败后不会整轮自动重放。

我觉得最意外的，是它的智能路由。

OpenSquilla 随仓库打包了一个约 23MB 的 BGE-small-zh-v1.5 ONNX 模型。用户只说一句“继续”，它也会结合当前请求、最近 4 轮用户对话、上一轮回答和最近 5 次路由结果，在本机生成 390 维特征。

LightGBM 和 ONNX MLP 分别判断 R0–R3，再融合概率。之后还有一层策略裁决：概率接近时自动升档，R2 与 R3 的总概率超过 0.45 时最低升到 R2，部署、迁移、删除等高风险任务也有独立下限。

这一步省掉了每轮额外调用外部 LLM 的成本与延迟，但它无法保证每次都选对。发布包没有给出完整训练集、混淆矩阵或真实准确率，Self-learning 与本地 Calibration 也默认关闭。

推荐配置下，C0–C2 使用单模型；任务到达 C3 且启用 ensemble_enabled 后，才进入 B5（融合模式）：

DeepSeek、GLM、Kimi、Qwen 并行写出 4 份草稿，GLM 5.2 负责最终聚合。候选草稿会被标记为不可信内容，Proposer 没有真实执行权，只有 Aggregator 可以重新调用工具，避免发送、删除、部署等动作被执行 4 次。

我在固定提交 f02662d 上跑了本地探针：三条样例分别落到 C0、C3、C2，390 维特征完整生成，114 个 Router、Ensemble 和 Session 相关测试通过。这些结果能证明链路真实可运行，路由准确率仍需要更大的真实数据集验证。

但如果你正在做 Agent，OpenSquilla 很值得收藏。

因为一个能跑起来的 Agent 很常见；真正稀缺的，是它怎样维持长期状态、分配模型预算，并控制每一次真实副作用。