我构建了一个开源代理，其推理核心融合了多个LLM（面板、裁判、合成器），而不是路由到单一模型

Reddit r/AI_Agents 工具
open-source agent multi-model fusion reasoning llm governance

摘要

作者构建了一个开源代理，它使用一组不同的LLM（包括裁判和合成器）来处理困难的推理步骤，同时具备成本感知路由、分层记忆、治理和子代理支持。该软件处于alpha阶段，关于融合效果的基准测试结果不一。

大多数代理框架每次调用只选择一个模型。我想测试一个不同的想法：对于困难的步骤，对同一提示运行一组不同的模型，让一个裁判模型对它们进行交叉检查（共识/矛盾/盲点），然后由一个合成器写出最终答案。一个成本感知路由器将简单和工具调用留在单个快速模型上，仅在值得时才进行融合。围绕这个核心，我构建了一个完整代理的其余部分：规划 -> 执行 -> 验证或回退（可执行证据是事实依据，因此严格的审查者无法丢弃已验证正确的工作）、分层记忆（全文回忆 + 跨会话用户档案 + LLM对事实集群的整合）、治理内核（允许/警告/阻止/审查 + 用于自我修改的静态验证器）、定时任务和主动任务、MCP客户端 + OpenAPI到工具的导入，以及一个隔离的子代理/合作层，该层在并行git工作树中运行工作者，每个工作者都有验证门。诚实状态：这是alpha版本——Apache-2.0许可，可自行托管，463个测试，mypy --strict干净——因此它能够构建并经过了大量测试，但尚未经过生产环境检验。我真正不确定且希望得到本版块意见的是：与仅仅调用一个强大模型相比，融合（面板 -> 裁判 -> 合成器）是否真的值得额外的令牌和延迟？我自己的基准测试结果不一——它在模糊、开放式推理上明显有帮助，但在范围明确的编码任务上，单个顶级模型通常能以极低的成本达到同样的效果。您发现多模型设置在哪里真正能带来回报？（仓库链接在评论中，遵循规则3。）
查看原文

相似文章

法律中多智能体协商研究

arXiv cs.AI

本文研究了使用LLM进行法律推理任务的多智能体协商方法，引入了两种受法庭程序启发的新框架。实验表明，多智能体系统在整体性能上与单一LLM相当，但能产生截然不同的答案，并能解决基线模型无法处理的案例，突显了多智能体方法在法律AI中的潜力。

混合推理Agent：在潜空间中思考、通过文本行动的LLM Agent

Hacker News Top

本文提出了一种LLM Agent架构HybridAgents，它通过轻量级的HybridLink在潜空间推理与文本驱动的行动之间动态切换，并结合HybridSFT与HybridRL后训练，在11个基准测试上实现了10.4%的性能提升，同时显著降低了token消耗、延迟和成本。