在企业自动化场景中，大量遗留系统、内部仪表盘和第三方平台并不提供公开接口，却承担着核心业务流程。传统方案依赖浏览器自动化或计算机视觉驱动的 Agent，但这类方案存在速度慢、确定性差、容易受界面变更影响等根本性问题。Kampala 作为 YC W26 周期入孵项目，提供了一种截然不同的技术路径：通过中间人（MITM）代理直接拦截应用层网络通信，将人类操作转化为结构化的 API 调用。本文将从技术架构、核心实现和工程实践三个维度，剖析这一「API 工厂」模式的工作机制。
工作原理：从人类操作到网络请求的映射
Kampala 的核心思路并非对二进制进行动态插桩，而是充当一个具备 TLS 指纹保留能力的 MITM 代理，运行于目标设备或网络流量转发的关键节点上。当用户通过正常浏览器或应用完成一次工作流时，Kampala 会完整记录下所有 HTTP/HTTPS 请求及其上下文信息，包括请求头、请求体、会话 Cookie、CSRF 令牌等。与传统代理工具的关键差异在于，Kampala 在进行证书替换时不会修改 TLS 握手阶段的各种扩展参数和 HTTP/2 指纹，从而使得被拦截的请求在重新发送时能够通过目标服务器的指纹检测和反爬虫机制。
具体而言，Kampala 内部集成了修改版的 tls-client 库，能够逐字节还原真实的 TLS 连接特征，包括支持的密码套件列表、扩展字段顺序、ALPN 协议协商结果等。这一设计直接回应了此前 MITM 工具在应对严格反爬系统时的失效问题 —— 当目标服务检测到 TLS 握手指纹异常时，会直接断开连接或返回验证码挑战，而 Kampala 的方案使得自动化请求在网络层面与真实浏览器流量几乎无法区分。
MCP 集成与 Agent 驱动的脚本生成
单纯的流量捕获并不足以解决自动化问题。Kampala 的核心竞争力在于将捕获的请求序列与模型上下文协议（MCP）深度集成，使得 AI Agent 能够理解请求之间的依赖关系并生成可执行的脚本或 API 端点。工作流程通常分为三个阶段：首先是观察阶段，人类用户在目标应用中完成一次完整操作，Kampala 在后台记录完整的请求链路；其次是建模阶段，AI 分析请求之间的参数传递和数据依赖，识别认证令牌的刷新时机以及业务请求的顺序约束；最后是导出阶段，系统生成可直接调用的 Python、JavaScript 或 OpenAPI 规范文档。
这一过程的关键挑战在于请求参数的上下文关联。例如，某些表单提交请求需要携带前一次列表查询返回的分页令牌，而某些内部系统会基于时间戳或 UUID 生成一次性请求签名。Kampala 通过维护请求级别的状态机，自动追踪这些隐式依赖，并将其编码为可重放的脚本逻辑。用户既可以使用内置的 Agent 提示词直接描述期望的操作（如「查询过去三十天的订单并导出为 CSV」），也可以通过 MCP 接口与 Claude Code 等编程 Agent 配合，由 AI 根据捕获的流量样本自主构建完整的自动化脚本。
与传统工具的差异化定位
从功能边界来看，Kampala 与 Burp Suite、Proxyman、Charles 等传统代理工具存在本质区别。传统工具的设计目标是安全审计和渗透测试，侧重于请求的查看、修改和重放，缺乏面向自动化的脚本生成能力和 AI 层面的上下文理解。而 Kampala 从第一天起就将自身定位为「面向 AI 的代理基础设施」，每个界面操作背后都对应着可通过 API 调用的原子能力。创始人 Alex 在 Hacker News 的讨论中明确表示，他们的目标是成为「AI-native 的 Burp Suite」，在保留专业级代理功能的同时大幅降低自动化集成的门槛。
在协议支持方面，Kampala 不仅处理常规的 HTTP/1.1 和 HTTP/2 流量，还能够解析 gRPC 和 WebSocket 场景。gRPC 由于采用 Protocol Buffers 进行二进制序列化，传统的流量分析工具往往难以直接理解其负载内容。Kampala 的方案是先解析元数据层的 JSON 描述，结合请求上下文中出现的字段名称和类型暗示，由 AI 推断消息结构。虽然没有 Proto 定义文件的情况下无法做到完全精确的字段映射，但在多数企业内部 API 场景中已经足以支撑基本的自动化需求。
局限性与工程边界
尽管 Kampala 解决了 TLS 指纹和脚本生成两大核心难题，其实用仍受到若干工程约束。最主要的限制在于 SSL 证书固定（Certificate Pinning）场景。当移动应用在代码中硬编码了服务端证书公钥或自建 CA 时，MITM 代理的证书替换会导致应用拒绝建立连接。目前 Kampala 官方表示尚未完整支持此类场景，建议用户配合 Frida 脚本手动 patch 常见的 pinning 实现，或在 Android 虚拟设备环境中绕过证书验证。
另一个工程挑战是会话刷新与认证续期。长时间运行的自动化任务必然面临令牌过期问题，而不同系统的认证刷新机制差异巨大 —— 有些仅需简单调用刷新端点，有些则需要完整重新走一遍登录流程并处理验证码。Kampala 当前通过 AI Agent 主动探测认证刷新路径来缓解这一问题，但在某些多因素认证场景下仍可能需要人工介入。此外，由于 MITM 代理本身需要部署在网络路径上，企业内网环境的部署复杂度通常高于个人桌面场景。
应用场景与实践建议
从真实使用案例来看，Kampala 最适合以下几类场景：一是遗留系统的 API 化改造，许多企业运行着只有 Web 界面的内部工具，通过 Kampala 可以快速生成稳定的 API 供下游系统调用；二是跨平台数据汇总，当数据分散在多个无公开接口的 SaaS 仪表盘时，可以统一通过请求拦截层实现自动化抓取；三是 AI Agent 的执行底层，相比让 Agent 直接操作浏览器页面，基于 API 的调用在速度和确定性上都有数量级的提升。
需要强调的是，任何形式的自动化都应遵守目标服务的使用条款和当地法律法规。Kampala 官方也多次声明其产品定位是帮助用户自动化自己已有权限访问的工作流，而非大规模爬取或绕过访问控制。在技术选型时，建议团队首先评估是否存在官方 API 或官方合作伙伴计划，仅在确无替代方案时再考虑 MITM 代理方案，并将自动化范围限制在最小必要集合内。
资料来源：本文技术细节主要参考 Kampala 创始人在 Hacker News 的 Launch 帖子（https://news.ycombinator.com/item?id=47794514）以及 Zatanna 官方产品页面（https://zatanna.ai）。