Plunger：看清你的AI Agent到底向API发送了什么

AI Agent 调用 API 已经稀松平常，但一个关键问题始终悬而未决：它到底发了什么出去？ 你的 token 去了哪里？有没有哪个变量忘了定义、被当成字面文本泄露给了服务器？事后想复盘，却发现 curl 根本不留下任何记录。

Plunger 正是冲着这个痛点来的。它是一个为人类和 AI Agent 共同设计的 HTTP 客户端——一个小程序，三种入口：给你用的图形窗口、给脚本用的命令行、给 Agent 用的 MCP 服务器。三者共享同一套已保存请求、同一套变量、同一份历史记录。

三种入口，一份数据

Plunger 的核心设计思路是「人机同源」。你在窗口里打开的请求，Agent 通过 MCP 或 CLI 也能访问；Agent 发的每一条请求，也会实时落入你看到的历史记录，并标注来源是 CLI 还是 MCP。

这意味着调试不再需要「你猜我猜」。当 Agent 的行为出现异常，你可以直接翻出它实际发出的请求、收到的响应，而不是对着一团黑箱发呆。

响应以树形结构返回，可以折叠、搜索，也能直接复制某个节点的 JSON 路径——对于嵌套很深的 API 响应，这个细节能省下大量手动扒结构的时间。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底推出的开放协议，用于让 AI 模型以标准化方式连接外部工具和数据源。在 MCP 出现之前，每个 Agent 框架（LangChain、AutoGPT 等）都用自己的方式定义「工具调用」，导致同一个 API 客户端要为不同框架分别适配。MCP 把这件事抽象为一层协议：客户端（Agent 宿主）通过 JSON-RPC 与 MCP 服务器通信，服务器暴露工具（tools）、资源（resources）和提示（prompts）三类能力。Plunger 作为 MCP 服务器运行，意味着任何支持 MCP 的 Agent——Claude Desktop、Cursor、各类 IDE 插件——都能直接调用它，而不需要 Plunger 团队为每个宿主单独写适配层。这也是「Agent 入口」在当下最通用的接入方式。

变量机制：发不出去，好过发错

Plunger 把请求中会变化的部分抽成变量。比如 base 地址和 API key 都是变量，请求本身只持有引用。

这个设计的价值在于失败模式的选择。当你忘记定义某个变量时，Plunger 拒绝发送，并明确告诉你缺哪一个——而不是把一个 {{token}} 这样的占位符原样发给服务器。后者恰恰是 Agent 调用 API 时最隐蔽也最危险的错误：请求看起来成功了，但敏感信息或占位符已经流到了不该去的地方。

保存请求用 Ctrl-S，归档到分组可以直接从菜单操作。分组支持嵌套，大型 API 项目也能保持整洁，Agent 也可以把它的请求归到同一套分组里。

模板变量未解析就发出是 API 调用中的一类经典事故。典型场景是请求体里写了 "Authorization": "Bearer {{api_key}}"，但环境变量文件路径不对或变量名拼错，客户端不做校验直接发送，服务器收到的就是字面文本 {{api_key}}。多数服务器的反应是返回 401，看起来只是「认证失败」；但有些服务器会把请求体原样记入日志，或者回显到错误响应里，占位符连同其声称要保护的字段名一起暴露。对 Agent 而言问题更严重：它不会像人类那样看到 401 就停下来检查配置，而是可能重试、换路径、把同一个错误的请求模式扩散到其他端点。Plunger 选择在客户端侧做「发送前校验」，本质上是把错误从「远端静默失败」提前到「本地显式拒绝」，这是安全设计中失败模式（fail mode）取舍的典型案例。

精准取值，而非全量返回

Agent 通过命令行或 MCP 发请求时，可以只索取它需要的字段。演示中展示了如何从一个大响应里只取出一个字段。

这对 Agent 的意义不只是「省 token」。限制返回值范围本身就是一种权限收敛——Agent 拿不到的数据，就不可能误用或泄露。配合「它使用的 token 从不展示给它自己」这一设计，敏感凭证在 Agent 侧是不可见的。

工作流：让多步调用变得可观测

当一个响应要喂给下一个请求时，Plunger 允许把步骤保存为工作流（workflow）。Agent 可以一次调用跑完整条链路，而你可以在界面上看着它像流程图一样逐级点亮。

每一步的流转值会写在连接线上——上一步交给下一步的到底是什么，一目了然。这把「Agent 连环调用 API」从一串难以追踪的独立事件，变成了一个可回放、可审查的可视化过程。

工作流（workflow） 在 API 编排语境中指的是把多个请求按依赖关系串成一条有向链路，前一步的输出作为后一步的输入。传统的做法是写脚本（Shell、Python）用变量在步骤间传递数据，可读性和可调试性都随步骤数增长而急剧下降。可视化工作流把这条链路显式画出来，每个节点是一个请求，连接线上标注传递的具体值。对 Agent 场景这尤其重要：Agent 自主编排的多步调用往往在几秒内完成，出错时人类看到的只是一个最终结果。有可视化链路后，可以逐节点回放，定位到底是哪一步的输入被污染、哪一步的过滤逻辑失效。

安全审计：篡改可验，凭证落盘前已脱敏

Plunger 宣称 Agent 的每一个动作都会写入一个防篡改日志（tamper-evident log）。请求头、查询字符串、请求体中的凭证会在接触磁盘之前被掩码处理，链式校验随时可做。

这种设计把「事后追责」和「事前防泄露」放在了同一套机制里。对于需要在合规框架下使用 AI Agent 调 API 的团队，可验证的日志链往往比功能本身更有吸引力。

防篡改日志（tamper-evident log） 与普通日志的区别在于「可验证未被修改」，而非「不可修改」。实现方式通常是链式哈希：每条日志记录包含前一条记录的哈希值，形成哈希链；任何对历史记录的修改都会导致后续所有哈希不匹配。这与区块链的 Merkle 结构同源，但不需要分布式共识，单机即可实现。配合凭证落盘前脱敏（masking），即使在日志文件被完整获取的情况下，攻击者也拿不到可用的 token。在合规场景（如 SOC 2、ISO 27001 审计）中，这种机制常用来说明「日志可信」——审计方不需要信任日志的存储方，只需要验证哈希链。

安装与授权

Plunger 是开源项目，采用 MIT 许可证。据视频介绍，可通过 pip、homebrew 或 WinRAR 安装（WinRAR 这一点大概率是演示中的玩笑），也可以直接运行 plunger install 将其接入你的 Agent。

它解决的是什么问题

把 Plunger 放回 Agent 工具链的语境里看，它补的是一个长期被忽视的环节：可观测性与凭证边界。

curl 的设计目标是一次性、无状态、用完即走，这在人类手动调试时没问题，但 Agent 会高频、批量、自动地调用 API，此时「没有记录」就变成了系统性风险。Plunger 用共享的请求/变量/历史三件套，加上脱敏日志和变量强制校验，试图把 Agent 的 API 调用纳入一个可审计的轨道。

对于正在把 Agent 接入生产环境的开发者来说，这不只是一个更方便的 HTTP 客户端——它更像是一道介于 Agent 和你后端之间的、带记录的闸门。