推文

@fireandstart · 2026-10-12 18:15

这条设计击中了工具型代理一个常被低估的成本：可用工具越多，不代表每次都把全部 schema 塞进上下文。用少量元工具承接搜索与调用，能把“工具目录规模”和“单轮决策负担”拆开；按需发现也让同一套客户端有机会连接不断扩展的 MCP 与 REST 服务，而不必为每个接入重做提示词。这里真正要验证的，是找到工具是否足够准、调用边界是否清楚，以及节省下来的上下文能否转化为更稳定的任务完成率，而不仅是目录看起来更小。特别是网关把调用集中起来后，熔断、限流和健康检查解决的是服务可用性，重试则还要区分只读查询与有副作用的操作：超时后结果未知时，盲目重试可能重复发送邮件或创建记录。把幂等键、执行状态查询、权限范围和必要的人审做成调用契约，才能让“按需调用”既省上下文也可恢复。自托管和非商业许可的界线同样应在接入前说清楚。相比堆更多工具，我更看重这类网关能否把发现、权限、失败恢复和审计统一成可观察的运行层；否则代理只是更容易找到工具，却未必更可靠地完成工作。

曝光 30 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 1.6798417150105827