我这几周一直在运行一个多智能体（multi-agent）的 LangGraph 流水线，但始终遇到同样两个核心问题：重复的 API 调用不断推高成本，以及只要上游服务稍微不稳定，agent 就会直接崩溃。
我的系统包含 4 个 agent，它们调用的工具有重叠。在真实负载下，每次运行会产生 100 多次 API 请求，而这些接口在 30 分钟的窗口内返回的数据其实是相同的。我还复制粘贴了熔断（circuit breaker）逻辑，但在不同工具之间并不一致。可观测性几乎为零——一旦出问题，我没有任何结构化信号可以用来排查。
后来我发现了 ToolOps，它的核心理念是合理的：把每一次工具调用当作基础设施工程师处理微服务通信的方式来对待。
其中 @readonly / @sideeffect 的装饰器拆分非常有“主见”，但这是好事——它强迫你明确一个工具调用是否具备幂等性（idempotent）。当你决定哪些请求可以被缓存或重试时，这一点非常关键。
几个让我印象深刻的点：
- 请求合并（Request coalescing） ：在他们文档的一个 50 并发测试中，50 个请求最终被合并成 1 个上游请求。我自己做了一个较小规模的测试，也观察到了类似行为——缓存未命中时的“惊群问题”确实存在，而这个机制处理得很好。
- 语义缓存（Semantic caching） ：一开始我很怀疑，但对 NLP 工具输入的意图匹配确实有效。“查询发票 #442 状态”和“这个 442 发票付款了吗？”最终命中同一个缓存条目，明显降低了 LLM token 消耗。
- toolops doctor：一个 CLI 命令，可以检查所有后端服务并返回熔断器状态。看起来很小，但非常适合接入健康检查（health check）接口。
整个集成方式非常简单：每个函数加一个装饰器即可，完全不需要修改业务逻辑。并且可以原生支持 LangGraph、CrewAI、LlamaIndex 和 MCP。
目前还比较早期——Web dashboard 和预算控制功能仍在 roadmap 上——但核心的稳定性层已经很扎实。Apache 2.0 协议，由 Hedi Manai 构建。
GitHub：github.com/hedimanai-p…
文档：hedimanai.vercel.app/projects/to…
