我们对20个生产代理场景进行了MCP与文件系统访问的基准测试。文件系统设置将LLM成本降低了27%,延迟降低了32%

Reddit r/AI_Agents 新闻

摘要

一项比较MCP和文件系统访问在20个生产场景中针对AI代理的基准研究发现,文件系统访问将LLM成本降低了27%,延迟降低了32%,同时提高了答案质量。

我们使用两种不同的设置让同一个代理执行20个跨应用任务:官方的Slack、Notion和Linear MCP集成。相同的应用数据使用Locality同步并挂载为文件,这是我参与的项目。我们保持代理框架、模型、提示和机器相同。我们每个场景运行三次,并对结果答案进行了180次盲法随机比较。与MCP相比,文件系统设置:在70%的盲评中产生了更高质量的答案。将LLM成本降低了27%。将延迟降低了32%。减少了61%的工具调用。使用了大约少40%的令牌。跟踪显示,大部分收益来自收集上下文,而不是推理差异。在一个场景中,代理需要通过比较Slack、Linear、Notion和Git仓库中的证据来识别产品发布风险。文件系统代理使用一组并行的rg和文件操作在这些来源中进行搜索。在一个证据收集阶段,这些操作大约耗时0.3秒。MCP代理在相同阶段花费了大约一分钟,进行了21次调用,工具调用时间约为30秒,同时迭代收集上下文。代理在推理上花费了相似的时间。主要区别在于它们如何找到和检查推理所需的证据。我们的结论是,文件系统为代理提供了一个可组合的接口,用于跨来源搜索、过滤和阅读。这使得上下文的发现变得容易,并且可以大规模检索。MCP为它们提供了多个特定应用的接口,这可能会为上下文密集型工作创建更长的检索链。这项基准测试专注于跨应用研究和合成,因此它并未涵盖所有MCP用例。MCP可能仍然是单个操作和轻量级集成的更好接口。完整分析、跟踪和场景级结果链接如下。如果你在生产中运行代理,你是通过工具在运行时获取应用程序上下文,还是预先同步到环境中?你在哪里看到过这种方法失效?
查看原文

相似文章

基于文件系统的LLM Agent记忆:组织、演化与可持续性

arXiv cs.CL

本文首次系统性地探索了基于文件系统的LLM Agent记忆,将管理、搜索和执行Agent的角色规范化,使其围绕一个共享的记忆存储。研究发现,组织主要降低了检索成本,但尚未提升答案质量,并且工具选择对存储形态的影响与模型选择一样大。

到2026年,哪些MCP服务器能让AI代理具备真正的业务能力?

Reddit r/AI_Agents

一位实践者分享了他们在业务工作中使用MCP(模型上下文协议)服务器的经验,详细介绍了哪些服务器提供真正的读写能力(例如Postgres MCP、HubSpot MCP、PostFast)以及哪些令人失望(例如Slack MCP、Google Ads MCP),同时强调了主要的安全问题,如OAuth采用率低和漏洞率高。

25 个 Agent、50 个 MCP 服务器、1 个应用:你会选什么技术栈?

Reddit r/AI_Agents

一位从业者向社区征求建议:如何在 AWS 上构建一个生产级 Agent 平台,包含约 20 个 Agent 和 50 个 MCP 服务器,并在 Bedrock AgentCore、Claude Agent SDK、Strands、LangGraph、A2A、LiteLLM 和 Langfuse 等方案之间权衡取舍,同时要求完整保留 Claude 的全部功能和可用的提示词缓存。文章就框架选择、Agent 间通信、MCP 托管和代码仓库策略寻求推荐。