在大语言模型应用开发中，对工具调用（Tool Use）链路的可观测性需求日益增强。无论是调试工具参数传递、审计外部 API 调用的安全性，还是复现生产环境中的异常行为，一种直观的方案是部署流量代理。MitM（Man-in-the-Middle，中间人）代理通过在客户端与目标服务之间插入监听层，能够完整捕获明文请求与响应内容。本文将从工程实践角度剖析该架构的核心组件，重点阐述证书注入机制、TLS 解密原理、请求拦截与重放策略，以及隐私隔离的关键设计决策。
证书注入与本地 CA 信任链
TLS 加密的核心目标是防止第三方窃听或篡改通信内容，而 MitM 代理的介入必然涉及对这一安全边界的主动突破。其技术本质在于让代理服务器同时与客户端和服务端建立两段独立的 TLS 连接：一段代理与客户端之间使用代理动态生成的伪造证书，另一段代理与真实服务端之间保持标准 TLS 通道。要使这一机制生效，必须解决客户端的证书信任问题。
主流实现方案要求用户显式安装代理的自签名 CA 证书至系统或应用程序的信任存储。以 mitmproxy 为例，首次启动时会生成名为 mitmproxy-ca-cert.pem 的根证书及其私钥，用户需将此证书添加至操作系统的信任根证书列表或特定浏览器的证书存储。对于 LLM 工具的代理场景，这一过程通常需要自动化脚本辅助完成，因为手动信任配置难以规模化部署。部分企业环境还会通过移动设备管理（MDM）或组策略强制推送代理 CA，从而降低终端用户的操作门槛。
值得注意的设计要点是证书的动态生成策略。代理在捕获到新的目标域名时，应当即时签发对应域名的伪造证书，而非预先生成所有可能域名的证书。这要求代理内置轻量级 CA 功能，支持按需签发证书并维护签发记录以供审计。同时，伪造证书的密钥长度、签名算法应与原始证书保持一致，避免因密码学参数差异触发现代客户端的安全警告。某些严格的应用还会校验证书链的完整性与颁发机构，代理必须模拟完整的中间证书路径才能蒙混过关。
TLS 解密流水线的技术实现
当客户端信任代理 CA 之后，真正的解密工作才刚刚开始。整个流水线可划分为连接建立、证书伪造、数据解密、请求处理、响应加密五个阶段，每个阶段都涉及网络层与加密层的精细协作。
在连接建立阶段，代理监听指定端口（通常是 8080 或 8899），等待客户端发起 HTTPS 连接。代理首先与客户端完成 TLS 握手，呈现伪造的目标域名证书；与此同时，代理以客户端身份向真实服务端发起第二个 TLS 连接，完成服务端的证书验证。这一双连接模式是 MitM 架构的核心，也是性能开销的主要来源 —— 每个请求都需要代理进行两倍的加密运算。
数据解密阶段依赖于代理对双方握手的完整控制。由于代理持有伪造证书的私钥，能够解封客户端发送的应用层数据；同样，代理使用与服务端协商的会话密钥解密响应数据。此时，代理获得了完整的明文流量，包括 HTTP 请求头、请求体、响应头与响应体。对于 LLM 工具场景，这意味工具名称、参数 JSON、模型返回的流式片段等敏感信息均可被捕获。
部分现代客户端启用了证书透明度（Certificate Transparency）日志校验或域名安全策略（HPKP），会主动拒绝伪造证书。应对这些场景需要更高级的技术手段，例如通过启动参数禁用特定安全特性、或在代理层实施 HTTP CONNECT 隧道模式让客户端直接处理 TLS 而代理仅转发字节流。后者虽然失去了解密能力，但能够兼容更严格的客户端环境，牺牲可观测性换取连通性。
请求拦截、修改与重放机制
流量捕获只是代理的基础功能，真正体现工程价值的是对请求的动态拦截与修改能力。mitmproxy 提供了基于 Python 的脚本扩展接口，开发者可以注册 request 与 response 钩子函数，在流量经过时执行任意逻辑。这种机制常用于以下场景：自动脱敏敏感字段、注入调试标识、模拟异常响应、或按条件阻断请求。
对于 LLM 工具审计场景，常见的拦截策略包括：将工具调用参数中的 API Key 替换为占位符，防止日志泄露；为每个请求生成唯一追踪标识，便于关联分布式调用链；在响应返回后校验是否符合预期 schema，不符合则记录告警。这些逻辑若由应用程序自行实现，往往需要侵入式代码修改；而代理层实现则保持了业务代码的纯净性。
请求重放（Replay）是调试工作流的另一核心能力。代理可以录制特定请求的完整上下文（不仅包括 URL 与 body，还包含原始的 TCP 连接属性、时序信息），并在后续按需重发。重放时支持修改任意字段，例如替换模型名称观察不同引擎的行为差异，或调整温度参数测试输出的稳定性。mitmproxy 的 replay 功能还支持从 HAR 文件导入外部流量，实现跨环境的问题回放。
高阶的重放设计还会引入流量回放（Playback）模式，即代理持续向服务端发送录制的请求序列，用于模拟真实流量负载进行压测或混沌实验。这在 LLM 系统的容量规划与故障注入测试中具有显著价值，但需注意回放速率与服务端限流策略的协调。
隐私隔离与审计日志的安全设计
引入流量代理必然带来隐私风险：代理节点接触了本应端到端加密的敏感数据。如何在获取可观测性的同时控制泄露面，是架构设计的关键考量。
第一层隔离是进程级别的权限控制。代理服务应当以最小权限操作系统账号运行，禁止访问非必要的文件系统与网络资源；日志写入目录应设置严格的访问控制列表（ACL），仅允许审计组件读取。
第二层隔离是数据处理层面的分级策略。代理应当支持配置化的字段过滤规则，例如自动检测并替换请求体中的信用卡号、认证令牌等高敏感字段，或在捕获时直接丢弃特定路径的流量。过滤规则建议以声明式配置维护，便于合规审计与版本追溯。对于 LLM 工具场景，还应考虑 Prompt 内容的隐私 —— 某些应用可能在工具参数中嵌入用户隐私信息，代理层需具备模式匹配能力进行识别与脱敏。
第三层隔离是存储与销毁机制。审计日志应当加密存储，并设定合理的保留期限。短期保留（如 7 天）适用于问题排查场景；长期保留（如 1 年）则需满足合规要求并增加访问审批流程。日志删除应采用安全擦除标准，防止数据残留。
部分企业还会要求代理支持多租户隔离，即不同业务线的流量由独立的代理实例处理，审计日志物理分离。这种架构增加了运维复杂度，但能够有效防止跨业务的数据越权访问。
部署拓扑与生产环境考量
在生产环境中部署 LLM 工具流量代理需要权衡可观测性需求与系统稳定性。一种常见的折中方案是采用选择性代理：仅对特定工具或特定环境（ staging 、 testing ）启用代理捕获，production 环境保持直连。这一策略可以通过环境变量动态控制，避免代理配置错误导致生产流量异常。
代理实例的高可用设计同样重要。考虑到 TLS 解密的计算开销，单一代理实例可能成为性能瓶颈。水平扩展方案需要解决会话亲和性（Session Affinity）问题：由于 TLS 握手无法共享解密密钥，不同请求必须路由至同一代理实例才能正确解密。解决方案包括使用 IP 哈希负载均衡、或在代理集群中共享会话密钥存储（通常实现复杂且引入额外延迟）。更稳妥的方案是部署代理集群处理不同业务域的流量，避免跨域流量混部。
健康检查与熔断机制不可缺失。代理应当监控自身连接数、内存占用、解密失败率等指标，当指标异常时主动从负载均衡池摘除，避免影响上游业务。同时应配置告警规则，当解密失败率突增时通知运维团队排查证书配置或客户端变更。
结语
LLM 工具流量的 MitM 代理架构是一项系统工程，涉及证书信任、TLS 协议、流量操控与数据安全等多个技术域。其核心价值在于提供对工具调用链路的深度可见性，支撑调试、审计、测试等多场景需求。然而，代理的引入也带来了额外的性能开销与隐私风险，需要通过分级处理、权限隔离、最小化日志等策略加以缓解。对于计划在生产环境部署此类代理的团队，建议从非关键环境起步，逐步验证稳定性与安全性后再推广至更大范围。
参考资料
- mitmproxy 官方文档：https://docs.mitmproxy.org/
- GitHub jmuncor 项目仓库：https://github.com/jmuncor
- Hacker News 讨论帖：https://news.ycombinator.com/item?id=43567890