AI 越来越强，抓包工具会消失吗？想听听大家的看法

最近在做一个 HTTP 抓包调试工具，叫 HTTPeep 。做到一半，开始有点怀疑自己。

不是因为技术难，技术部分现在有 AI ，生产不再是瓶颈，但是另一方面我又一直在问自己，我现在在做的东西，几年后还有人需要吗？就我自己的感受，抓包工具确实是打开得变少了。

根据这几个月高强度的 Agent Coding 和经历过好几次模型迭代，我感受到一个以前要用抓包才能搞清楚的 API 问题，直接问 AI ，就算上下文不足，根据已有的代码信息，多推理几轮基本上问题也能解决了。然后开始认真想这件事。有两个想法在脑子里打转...

论点 A：这个赛道会萎缩

AI 通过静态代码就能推理出大部分网络行为。随着模型越来越强，很多中低复杂度的调试场景会被直接替代。

你不再需要亲眼"看"请求，因为 AI 已经能帮你"想"出来了。随着 Claude ，Codex 模型越来越强，它们正在让开发者越来越少地打开抓包工具。

VSCode 内嵌 Browser ，Codex 出了 computer use ，本质上都是给模型增加 Context ，让 Agent 任务完成质量更高更正确

这个论点我没办法反驳，因为我自己也感受得到

论点 B：不会消失，甚至需求会变多

但我同时也在想另一种可能

长期来看，AI 让软件行业的规模在变大，从业者更多，应用更多，网络请求的总量只增不减。

更重要的是，AI 生成的代码本身会产生更多奇怪的网络行为——它不理解你的业务上下文，它会写出能跑但行为诡异的 API 调用，这些东西只有抓包才能看清楚。当然大部分情况下 Agent 都工作得很好

还有一个点就是：调试工具支持 MCP 和 CLI SKILLS 可以成为 AI Agent 的眼睛。

AI 现在推理网络问题的方式，是分析你的代码——它在猜。但如果让 AI 直接看到真实的网络请求，它就不用猜了。这是两种完全不同的能力。所以在 HTTPeep 里，我做了 SKILLS 和 CLI 集成，让 Claude Code 或者其他 AI 编码工具可以直接连上来，读取实时的请求数据。不是让 AI 替代调试工具，而是让调试工具变成 AI 的感知层。

我押注论点 B ，但不确定对不对

还有我像说一下，为什么我做这个工具，以前我是一个重度的抓包使用者，做这个工具之前，我们几乎用遍了市面上所有同类产品——Charles 、Proxyman 、Fiddler 、Reqable 、HTTP Toolkit 。它们基础功能都很扎实，但有两个问题一直没有被好好解决：

规则管理太分散。MapLocal 规则在一个面板，断点在另一个面板，规则少的时候没问题，一旦复杂起来，你会开始调试自己的调试规则。
本地和共享的矛盾。要么纯本地、换机器就丢，要么云同步、数据存在别人服务器上。没有一个好的中间方案。

HTTPeep 的做法是：规则就是文件（ JSON/YAML ），直接放进 Git ，团队拉取即用。不需要账号，不需要登录，完全离线。本地优先，但不孤立。这是我对"这类工具应该长什么样"的一个判断。

现在想听听大家的看法和不同的观点，特别是：

你现在还在用抓包工具吗？频率有没有因为 AI 变化？
"让 AI 直接读网络请求"这个方向，你觉得有实际价值吗？

HTTPeep 感兴趣的可以看看： https://httpeep.com

sentinelK

5 月 20 日

脱离楼主本身来讲。

目前缺的就是工具，而不是模型。头部的模型 Agent 能力已经基本过线了，只要提供合理的工具和技能，模型都能正确的调度和梳理。

模型能力能替代生成和统计，但无法替代“眼睛和手脚”。拿不到上下文，LLM 即便是神仙也没办法。
所以方案 B 一定是未来的方向。

但是，在 LLM 时代，抓包工具“凭什么”必须用楼主的呢？这才是最大的问题。

我观察到的趋势，LLM 的工具越来越封闭化。大模型公司逐渐的会把自己的工具生态封闭起来，因为 LLM 本身无状态，不会有迁移成本。所以通过闭源工具自身构成上下文壁垒，形成所谓的“数据飞轮”，才是 LLM 服务的核心壁垒。

之前 LLM 公司不重视工具，是因为模型公司之前基本上是再打融资战，要的是投资人能看到效果和感动世界。
现在则是实际的刺刀见红。在争夺实际的 C 端客户。