真实工具环境不是函数列表
很多工具调用评测把工具当作独立函数。输入清楚，输出稳定，失败少见。真实商业软件不是这样。
ComplexMCP 把问题推进一步：工具是有状态的，彼此依赖，环境会变化，还可能出现噪声和 API 失败。它构建了 7 个 stateful sandboxes，覆盖办公套件到金融系统，包含 300 多个工具。
这更接近企业 agent 会遇到的“最后一公里”：不是会不会调用一个 API，而是在一堆互相影响的系统里能否完成任务。
60% 成功率说明差距仍然很大
论文报告，即使顶级模型也难以超过 60% 成功率，而人类表现约 90%。这个差距很有现实意义。
如果一个 agent 在复杂工具沙箱里每十次失败四次，它就很难被企业直接放进核心流程。尤其当任务涉及金融、审批、客户数据或生产系统时，失败不是“再试一次”这么简单。
这类结果也提醒产品宣传要克制。会用工具和能可靠完成互相依赖的工作流，是两件不同的事。
三个瓶颈都很工程化
论文指出的三类瓶颈很具体。第一是 tool retrieval saturation：工具规模一大，agent 找对工具就变难。第二是 over-confidence：agent 跳过必要的环境验证。第三是 strategic defeatism：遇到失败后倾向于解释失败，而不是恢复。
这三个问题都不是单纯换更大模型就一定解决。工具检索需要更好的工具目录和上下文压缩，环境验证需要强制检查点，失败恢复需要工作流和策略设计。
换句话说，agent 可靠性是模型、工具系统和运行时共同的问题。
对 MCP 生态的启发
MCP 让工具接入更标准，但标准化协议不等于标准化可靠性。工具描述质量、权限设计、错误返回、状态同步和 observability 都会影响 agent 表现。
ComplexMCP 的价值，是把评测压力放到工具生态本身。未来平台不能只统计接了多少 MCP server，还要看 agent 在这些 server 上能否稳定完成多步任务。
真正成熟的 MCP 工具链，应该内置测试、模拟环境、失败注入和轨迹审计。否则工具越多，agent 可能越容易迷路。
还没有评论，你可以写下第一条。