LLMTrace 代理流量检查

要解决的问题

当 Agent 通过 OpenAI 兼容接口调用模型时，请求通常直达模型服务：提示词内容、Token 消耗、错误信息都散落在客户端日志里。运维侧很难回答几个基本问题——Agent 到底发了什么 prompt？一次任务烧掉了多少预算？流式响应的首字延迟（TTFT）是否正常？更棘手的是成本失控这类风险：API 调用失控、Token 使用低效，往往要等到对账时才被发现。

工作原理

llmtrace 的思路是把流量收进一层代理：

• 代理转发：以 Proxy 方式拦截 OpenAI 兼容的模型请求，客户端 SDK 的 base URL 指向代理即可，业务代码基本不改；
• 内容检查：记录流经代理的 prompt 与响应，运营人员可以直接检视 Agent 实际发出的请求内容；
• 风险识别：针对成本失控（uncontrolled API spend、低效 token 使用）做检测；
• 性能监控：采集延迟、Token 用量、流式指标（如 TTFT）以及错误追踪；
• 策略执行：在代理层落实预算或 policy 控制，把治理点从各客户端收敛到单一入口。

支撑运行时是 Rust 或 Docker，配套 OpenAI 兼容的客户端或 SDK（Python 与 Node.js 均有示例）。

适用边界与注意点

• 只适用于 OpenAI 兼容协议的流量，非兼容协议不经过这层代理；
• 需要预先准备 Rust 或 Docker 运行时环境，并把客户端指向代理地址，属于有侵入的接入方式；
• 预算与 policy 控制依赖上游 llmtrace 的实现能力，本技能主要负责接入与文档指引；
• 代理本身会引入额外一跳，延迟基线需要考虑这一层开销。