企业官网建设流程全解析

1. 项目概述：hindsight 不是“事后诸葛亮”，而是一套可落地的 LLM 应用观测与调试基础设施

“hindsight”这个词在日常语境里常被译作“后见之明”——事情发生之后才看清楚来龙去脉。但放在当前 LLM 工程实践的语境下，它早已脱离了哲学隐喻，演变成一个具体、务实、带工具链的技术概念。我第一次在 GitHub 上看到hindsight这个仓库名时，也以为是个教学 demo 或者哲学向的实验项目；直到把它 clone 下来、跑通本地 pipeline、又在生产环境里连续追踪了三周 API 调用链路后，我才真正理解：hindsight 的核心价值，不是帮你“复盘错误”，而是让你在 LLM 请求发出的毫秒级窗口内，就同步捕获完整的上下文快照——包括原始 query、模型选择逻辑、token 分配细节、系统 prompt 注入点、tool call 的 schema 验证过程、甚至 response 流式 chunk 的逐帧耗时分布。它不替代日志系统，也不取代 tracing 工具，而是专为 LLM 应用设计的“请求显微镜”。你不需要改一行业务代码，只要在 OpenAI 兼容 API 网关层或 SDK 初始化时加几行配置，所有经过的请求就会自动被结构化归档、可检索、可回放、可比对。这直接解决了我在做 LLM Wiki 知识库项目时最头疼的问题：当用户反馈“为什么这个回答不准确”，我们过去只能靠人工翻查日志、拼凑 timestamp、再手动重放 prompt——平均要花 22 分钟才能定位到是 system prompt 被意外截断，还是 tool call payload 校验失败被静默丢弃。而用了 hindsight 后，整个过程压缩到 47 秒，且 93% 的 case 可以直接通过 Web UI 点击回放确认。它特别适合正在搭建 LLM 网关、构建企业级 LLM 应用中台、或者需要对第三方 LLM 服务（如 OpenRouter、DeepSeek、智谱）做统一可观测性的团队。哪怕你只是用 Python 调用讯飞星火 API 做一个内部小工具，hindsight 提供的轻量 CLI 模式也能让你在终端里实时看到每个 token 的生成延迟曲线。这不是一个“锦上添花”的玩具，而是把 LLM 从黑盒调用升级为白盒工程的必要基础设施。

2. 整体架构设计与选型逻辑：为什么必须绕开传统 APM，自建 LLM 专用观测层

2.1 传统监控方案在 LLM 场景下的三大结构性失效

很多团队第一反应是：“我们已经有 Datadog / New Relic / Prometheus + Grafana，为什么还要搞 hindsight？”这个问题我问过自己不下二十次，也带着团队实测对比过四套主流方案。结论很明确：现有 APM 工具在 LLM 请求层面存在不可修复的语义鸿沟。它们能抓到 HTTP 200/401/400 状态码，能统计 P95 延迟，能画出 QPS 曲线，但它们完全无法理解 LLM 请求的内在结构。举三个真实案例：

• 案例一：401 Unauthorized 的误判陷阱
  当你看到unexpected status 401 unauthorized: incorrect api key provided: sk-svcac****这类报错时，传统监控只会标记“认证失败”，但不会告诉你：这个 key 实际上是有效的，问题出在请求 header 中混入了X-Forwarded-For导致网关做了二次鉴权；或者更隐蔽的情况——OpenAI 的/v1/chat/completions接口在特定 region 下会对user字段做额外校验，而你的前端 SDK 把用户邮箱直接塞进了user，触发了风控拦截。hindsight 会完整记录原始 request body、所有 headers、以及服务端返回的完整 error response JSON，让你一眼看到"error": {"message": "Invalid user field format"}这样的关键线索。

• 案例二：400 Bad Request 的语义模糊性
  api error: 400 this model's maximum context length is 1048576 tokens. however...这类报错看似明确，但实际排查时你会发现：客户端上报的max_tokens是 2048，messages数组长度是 5，按常规 token 估算应该远低于上限。真相是——你用的minifier工具在预处理时把\n\n合并成了\n，导致 tokenizer 实际计数多出 173 个 token；而传统监控只记录最终状态码，不会保存预处理前后的 message 内容 diff。hindsight 默认开启 content snapshot，每次请求都会存两份：raw input 和 normalized input，并自动计算 token 差值。

• 案例三：流式响应的“幽灵延迟”
  用户抱怨“回答卡顿”，监控显示 end-to-end 延迟只有 1.2s，P95 也很健康。但 hindsight 的 stream profiler 显示：前 3 个 chunk 在 200ms 内发出，第 4 个 chunk 却卡了 840ms 才来，之后恢复流畅。这指向模型服务端的 speculative decoding 策略切换，或是 GPU 显存碎片化导致的 kernel launch stall——这种细粒度的流式行为，APM 的采样机制根本捕获不到。

提示：不要试图用修改 OpenTelemetry SDK 的方式强行注入 LLM 语义。我试过给llm_requestspan 添加prompt_length,completion_tokens等 attribute，但很快发现——LLM 的输入输出是动态 schema，tool_calls可能嵌套三层 JSON，function_call可能返回 binary blob，OTel 的 flat key-value 模型会丢失结构信息。hindsight 采用 JSON Schema-first 设计，所有字段定义在schema/v1.json中，支持任意深度嵌套和 union type。

2.2 Docker 作为部署底座的刚性需求与避坑要点

hindsight 的官方推荐部署方式是 Docker，这不是为了“赶时髦”，而是由其运行时特性决定的硬性约束。它需要同时满足三个条件：隔离的 Python 环境（避免与业务服务冲突）、确定性的网络命名空间（精准捕获 localhost 流量）、以及可声明式的资源限制（防止日志爆炸拖垮宿主机）。我们曾尝试在裸机上用 systemd 管理，结果因为日志轮转配置失误，单日生成 47GB 的未压缩 JSONL 文件，直接撑爆根分区。Docker Desktop 在 Windows/Mac 上的 WSL2 backend 或 HyperKit VM，天然提供了这些保障。

但 Docker 部署绝非docker run -p 8000:8000 hindsight一行命令就能搞定。最关键的三个配置点：

1. 网络模式必须为host或自定义 bridge：默认的bridge模式会导致容器无法捕获宿主机127.0.0.1的流量（这是绝大多数本地开发场景）。正确做法是创建自定义网络docker network create hindsight-net，然后让 hindsight 容器和你的 LLM 应用容器都接入该网络，并通过容器名通信（如http://my-llm-app:8000/v1/chat/completions）。这样既安全又可控。

2. 存储卷必须绑定到 SSD 路径：hindsight 的写入是高 IOPS 的随机小文件操作（每个请求一个 JSONL 行）。如果绑定到机械硬盘或网络存储（如 NFS），写入延迟会飙升到 200ms+，导致请求队列堆积。我们实测过：在 NVMe SSD 上，单实例可持续处理 1200 RPS；而在 SATA SSD 上，RPS 会跌到 680 并开始丢请求。

3. 内存限制必须显式设置：hindsight 的内存占用与并发请求数呈线性关系（每个 active stream 占用约 8MB）。如果你不限制--memory=2g，它会在高负载时吃光宿主机内存，触发 OOM Killer 杀掉其他关键进程。我们的生产配置是--memory=4g --memory-reservation=2g，留出缓冲空间。

注意：Windows 用户遇到virtualization support not detected docker desktop failed to start because v错误，99% 是 BIOS 中的 SVM/VT-x 未开启，或 Windows Hypervisor Platform (WHP) 服务被禁用。不要尝试用 Docker Toolbox（已废弃），直接进 BIOS 开启虚拟化，然后在 Windows 功能中启用“Windows Subsystem for Linux”和“Virtual Machine Platform”。

2.3 为什么选择 OpenAI 兼容协议作为事实标准

hindsight 的核心设计哲学是：不做 LLM 服务商的绑定，只做协议层的忠实观察者。它不关心你调用的是 OpenAI、DeepSeek 还是本地部署的 Qwen2-72B，只要你的网关或 SDK 遵循 OpenAI 的 REST API 规范（即/v1/chat/completionsendpoint，messages数组，tools字段等），hindsight 就能无缝工作。这背后是深刻的工程判断：OpenAI API 已成为事实上的 LLM 交互 ABI（Application Binary Interface）。你看最近的热词——cline openai compatible 配置、openrouter api key、heapjack openai——全在印证这一点。连智谱的 GLM-4 API 都提供了/v1/chat/completions兼容模式，DeepSeek 的文档里也明确写着 “OpenAI-compatible endpoint”。

这种兼容性不是靠字符串匹配实现的。hindsight 内置了一个轻量级 protocol parser，它会解析 request body 的 JSON Schema，识别出messages、tools、tool_choice等关键字段，并根据字段存在与否，动态启用不同的解析策略。例如：当检测到tools字段时，它会自动提取function.name和function.arguments，并验证arguments是否符合parameters定义的 JSON Schema；当response_format为{ "type": "json_object" }时，它会记录模型是否真的返回了合法 JSON。这种深度协议理解，是简单 HTTP proxy 无法做到的。

3. 核心功能拆解与实操细节：从安装到深度调试的完整链路

3.1 快速启动：5 分钟完成本地验证环境搭建

别被“LLM 观测平台”这种词吓住。hindsight 的最小可行环境，只需要一台 8GB 内存的笔记本，5 分钟就能跑起来验证效果。以下是我在 M2 MacBook Pro 上实测的步骤（Windows 用户只需将docker命令替换为 Docker Desktop 的 GUI 操作）：

第一步：拉取镜像并启动服务

# 拉取官方镜像（注意：不要用 latest，用具体版本号保证可重现） docker pull ghcr.io/hindsight-ai/hindsight:v0.8.3 # 创建数据目录（SSD 路径！） mkdir -p ~/hindsight-data # 启动容器（关键参数说明见下方） docker run -d \ --name hindsight \ --restart=always \ --network=host \ -v ~/hindsight-data:/app/data \ -e HINDSIGHT_STORAGE_PATH=/app/data \ -e HINDSIGHT_LISTEN_PORT=8000 \ -e HINDSIGHT_LOG_LEVEL=INFO \ -p 8000:8000 \ ghcr.io/hindsight-ai/hindsight:v0.8.3

关键参数解释：--network=host让容器共享宿主机网络，这样才能捕获localhost流量；-v绑定到本地 SSD 路径；HINDSIGHT_STORAGE_PATH必须与 volume 路径一致；HINDSIGHT_LISTEN_PORT是 hindsight 自身的 Web UI 和 API 端口，不是你要监控的目标端口。

第二步：配置你的 LLM 应用指向 hindsight 网关
假设你有一个 Python 脚本，原本直接调用 OpenAI：

from openai import OpenAI client = OpenAI(api_key="sk-xxx") response = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": "你好"}] )

现在只需改两行，把base_url指向 hindsight：

from openai import OpenAI # 改这里：base_url 指向 hindsight 的代理端口 client = OpenAI( api_key="sk-xxx", base_url="http://localhost:8000/v1" # 注意：hindsight 默认监听 8000，/v1 是它的兼容层 ) response = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": "你好"}] )

第三步：发起请求并验证捕获效果
执行你的 Python 脚本，然后访问http://localhost:8000。你会看到一个极简的 Web UI：左侧是请求列表，点击任一请求，右侧展开详情页。重点看这几个区域：

• Request Tab：原始 curl 命令、headers、完整 body（折叠显示，点开可看）
• Response Tab：status code、headers、body（如果是 stream，则显示前 5 个 chunk 和总耗时）
• Tokens Tab：精确的 input_tokens、output_tokens、total_tokens（基于 tiktoken 计算，与 OpenAI billing 一致）
• Timeline Tab：从 DNS 解析、TCP 连接、TLS 握手、request send、first byte、last byte 的毫秒级时间轴

实操心得：第一次启动时，Web UI 可能显示 “No requests found”。别慌——这是因为你的应用还没发请求，或者base_url配错了。打开浏览器开发者工具的 Network 面板，过滤http://localhost:8000/v1，看是否有请求发出。如果看到 404，说明base_url少写了/v1；如果看到 502，说明 hindsight 容器没起来或端口冲突。

3.2 深度调试：如何用 hindsight 定位llm request failed: provider rejected the request schema or tool payload.这类报错

这类报错在 LLM 工程中极其常见，但传统日志里只有一行错误消息，毫无上下文。hindsight 的价值在此刻爆发。我们以一个真实案例演示完整排查流程：

场景还原：
团队开发了一个“合同条款智能审查”工具，使用tool_calls调用自定义 functionextract_clause。某天突然大量报错：llm request failed: provider rejected the request schema or tool payload.。OpenAI 文档里对此错误的解释只有“invalid tool payload”，没有更多线索。

hindsight 排查四步法：

1. 筛选错误请求：在 Web UI 的搜索框输入status_code:400，按时间倒序，找到最近的失败请求。

2. 对比 request & response：点击进入详情页，在Request Tab中，展开body，找到tools数组：

   "tools": [{ "type": "function", "function": { "name": "extract_clause", "description": "从合同文本中提取指定条款", "parameters": { "type": "object", "properties": { "clause_type": { "type": "string", "enum": ["payment", "liability", "termination"] }, "text": { "type": "string" } }, "required": ["clause_type", "text"] } } }]

   在Response Tab中，看到完整的 error response：

   { "error": { "message": "Invalid tool call payload: 'text' must be a string, got null", "type": "invalid_request_error", "param": "tools.0.function.parameters.text" } }

3. 定位源头代码：回到你的应用代码，搜索extract_clause调用点。果然发现一处逻辑漏洞：

   # 错误写法：当 contract_text 为空时，传了 None tool_call = { "type": "function", "function": { "name": "extract_clause", "arguments": json.dumps({ "clause_type": "payment", "text": contract_text # contract_text 可能为 None！ }) } }

   正确做法是增加空值校验：

   if not contract_text: raise ValueError("contract_text cannot be empty")

4. 验证修复效果：改完代码，重新发起请求。在 hindsight 中，新请求的Tokens Tab会显示input_tokens: 128，output_tokens: 42，且Response Tab的 status code 变为200。更重要的是，你可以点击右上角的Compare按钮，把这次成功请求和之前的失败请求并排对比，直观看到arguments字段从null变成了有效字符串。

注意事项：hindsight 默认不会记录arguments字段的原始值（出于隐私考虑），但会记录其 JSON Schema 验证结果。如果你需要审计敏感字段，需在启动时添加环境变量-e HINDSIGHT_RECORD_ARGUMENTS=true，并确保你的数据合规流程允许。

3.3 高级技巧：用 hindsight 构建 LLM Wiki 知识库的 QA 质量评估流水线

hindsight 最被低估的能力，是它能把每一次 LLM 调用转化为结构化数据资产。我们团队用它驱动内部 LLM Wiki 知识库的质量闭环，效果显著。核心思路是：把 hindsight 的请求存档，当作黄金测试集，自动化评估模型输出质量。具体步骤如下：

Step 1：构建种子请求集
在 hindsight 的 Web UI 中，筛选出过去一周内model:gpt-4o且status_code:200的请求，导出为 JSONL 文件seed_requests.jsonl。这个文件包含 12,487 条真实用户 query 和对应 response。

Step 2：定义评估维度与规则
我们定义了三个核心维度，每条规则都可转化为代码：

• 准确性（Accuracy）：response 是否包含事实性错误？我们用一个轻量级 RAG 检索器，从 Wiki 知识库中召回 top-3 相关文档，然后用另一个小模型（Phi-3）判断 response 是否与召回文档矛盾。
• 完整性（Completeness）：response 是否覆盖了 query 的所有子问题？我们用正则匹配 query 中的疑问词（“如何”、“为什么”、“有哪些”），然后检查 response 是否有对应解答段落。
• 安全性（Safety）：response 是否包含违规内容？我们集成了一套开源的 LLM 安全分类器（基于 DeBERTa-v3），对每条 response 打分。

Step 3：自动化评估脚本
写一个 Python 脚本evaluate.py，读取seed_requests.jsonl，对每条记录调用上述三个评估器，生成 CSV 报告：

request_id,query,model,response,accuracy_score,completeness_score,safety_score,overall_grade req_abc123,"如何申请专利","gpt-4o","专利申请需提交...","0.92","0.85","1.0","A" req_def456,"公司注销流程","gpt-4o","先税务清算...","0.45","0.91","0.98","C"

Step 4：建立质量看板与告警
把 CSV 导入 Grafana，创建看板：

• 折线图：每日overall_grade的分布（A/B/C/D）
• 热力图：各model在不同query_category（法律/财务/IT）下的平均 accuracy
• 告警规则：当C/D grade比例连续 2 小时 > 15%，自动 Slack 通知 LLM 运维群

这套流程上线后，Wiki 知识库的用户满意度（NPS）从 32 提升到 68，最关键的是——我们终于能说清楚：“为什么这个答案不准？” 因为每一条低分记录，都能在 hindsight 中回放原始上下文，精准定位是 prompt 设计缺陷、知识库更新滞后，还是模型本身能力边界。

实操心得：不要试图一次性评估所有维度。我们第一周只做safety评估，跑通整个 pipeline；第二周加入completeness；第三周才上accuracy。每次只聚焦一个痛点，快速拿到正向反馈，团队才有持续投入的动力。

4. 常见问题与实战排障：那些文档里不会写的血泪教训

4.1 Docker 网络不通的七种可能与逐级诊断法

docker network不通是 hindsight 部署中最高频的故障，原因五花八门。我整理了一份按发生概率排序的诊断清单，每一步都有可执行的验证命令：

个人经验：超过 60% 的网络问题，根源在第 4 步——host.docker.internal解析失败。Windows 用户尤其要注意：Docker Desktop 的 “General” 设置里，“Use the Docker host from containers” 必须勾选；Mac 用户则要检查 “Docker Engine” 设置中的host.docker.internal是否被手动删除。

4.2 处理unexpected status 401 unauthorized: incorrect api key provided的三重验证法

这个报错看似简单，实则暗藏玄机。我总结出一套三重验证法，确保不漏掉任何可能性：

第一重：验证 key 本身有效性
不要相信任何第三方网站的 key 验证工具（有泄露风险）。用最原始的方式：

# 用 curl 直接调用 OpenAI 的 /models endpoint（无需 model 参数） curl https://api.openai.com/v1/models \ -H "Authorization: Bearer sk-xxx" \ -H "Content-Type: application/json"

如果返回{"object":"list","data":[...]}，说明 key 有效；如果返回{"error":{"message":"Incorrect API key provided"...}}，那确实是 key 错了。

第二重：验证 key 是否被中间件篡改
hindsight 的 Request Tab 会显示原始Authorizationheader。复制它的值，和你代码里写的api_key字符串逐字符比对。常见篡改点：

• 前后多了空格（" sk-xxx "）
• 混入了不可见字符（如零宽空格 U+200B）
• 在 IDE 中被自动格式化（如把sk-换行了）

第三重：验证 key 是否绑定了限制条件
登录 OpenAI 官网，进入API Keys页面，点击你的 key，查看Key restrictions：

• IP restrictions：如果开启了，确保你的服务器公网 IP 在白名单中（注意：Docker 容器的出口 IP 是宿主机 IP，不是容器 IP）
• Model restrictions：如果限制了只能用gpt-3.5-turbo，但你的代码请求了gpt-4o，就会返回 401
• Organization restrictions：如果你的 key 属于某个 Organization，而请求时没带上OpenAI-Organizationheader，也会 401

踩过的坑：我们曾用 Terraform 自动创建 OpenAI key，脚本里忘了加--organization参数，导致生成的 key 默认属于个人账户，而生产环境的 API 调用都指定了OpenAI-Organization: org-xxx，结果所有请求都 401。hindsight 的 Request Tab 清晰地显示了OpenAI-Organizationheader 的值，让我们 3 分钟就定位到问题。

4.3 性能瓶颈分析：当api error: 400 this model's maximum context length is 1048576 tokens频繁出现时

这个报错的字面意思是“上下文超长”，但真实原因往往更复杂。hindsight 的Tokens Tab是破局关键。我们建立了一个标准化的分析流程：

Step 1：确认 token 计数来源
hindsight 默认使用tiktoken库，模型选择cl100k_base（OpenAI 所有模型的通用 tokenizer）。但你的应用可能用了别的 tokenizer（如sentencepiece），导致计数偏差。在 Tokens Tab 中，你会看到：

• input_tokens_estimated: hindsight 用 tiktoken 计算的值
• input_tokens_actual: 如果你的 LLM 服务返回了usage.prompt_tokens，hindsight 会优先采用这个值

如果两者相差 > 5%，说明你的应用和 hindsight 使用了不同的 tokenizer，需要统一。

Step 2：分析 message 结构
展开 Request Tab 的messages，逐条检查：

• systemmessage 是否过长？我们有个客户把整本《民法典》塞进了 system prompt，占了 80 万 tokens。
• usermessage 中是否包含 base64 编码的图片？OpenAI 的 vision 模型会把 base64 解码后计数，而 tiktoken 不会。
• assistantmessage 的历史对话是否累积过多？我们建议最多保留最近 5 轮对话，超出部分用摘要压缩。

Step 3：启用动态 truncation
hindsight 支持在配置中开启自动截断：

# config.yaml truncation: enabled: true strategy: "oldest_first" # 或 "summary_first" max_input_tokens: 800000

这样，当input_tokens_estimated > 800000时，hindsight 会自动删减最老的user/assistant对话，保证请求能发出，并在 Response Tab 中记录truncated: true和truncated_messages_count: 2。

实操心得：不要盲目调高max_input_tokens。我们测试过，当 context length 超过 50 万 tokens 时，GPT-4o 的首 token 延迟会从 200ms 涨到 1.2s，且幻觉率上升 37%。与其硬扛，不如用 hindsight 的truncation功能做优雅降级。

5. 生产环境部署与扩展：从单机调试到企业级中台

5.1 高可用架构：如何用 Docker Compose 编排 hindsight 集群

单机版 hindsight 足够用于开发和中小规模验证，但生产环境必须考虑高可用。我们采用 Docker Compose + Nginx 负载均衡的方案，已在日均 200 万请求的场景下稳定运行 6 个月。核心docker-compose.yml如下：

version: '3.8' services: # hindsight 主实例（主写） hindsight-primary: image: ghcr.io/hindsight-ai/hindsight:v0.8.3 container_name: hindsight-primary restart: always networks: - hindsight-net volumes: - /ssd/hindsight-primary:/app/data environment: - HINDSIGHT_STORAGE_PATH=/app/data - HINDSIGHT_LISTEN_PORT=8000 - HINDSIGHT_LOG_LEVEL=WARNING - HINDSIGHT_REDIS_URL=redis://hindsight-redis:6379/0 deploy: resources: limits: memory: 4G cpus: '2.0' # hindsight 备实例（只读，用于 UI 查询） hindsight-replica: image: ghcr.io/hindsight-ai/hindsight:v0.8.3 container_name: hindsight-replica restart: always networks: - hindsight-net volumes: - /ssd/hindsight-replica:/app/data environment: - HINDSIGHT_STORAGE_PATH=/app/data - HINDSIGHT_LISTEN_PORT=8000 - HINDSIGHT_LOG_LEVEL=WARNING - HINDSIGHT_MODE=readonly - HINDSIGHT_REDIS_URL=redis://hindsight-redis:6379/0 deploy: resources: limits: memory: 2G cpus: '1.0' # Redis 用于主备状态同步 hindsight-redis: image: redis:7-alpine container_name: hindsight-redis restart: always networks: - hindsight-net command: redis-server --appendonly yes volumes: - /ssd/hindsight-redis:/data # Nginx 负载均衡器 nginx: image: nginx:alpine container_name: nginx restart: always ports: - "8000:80" networks: - hindsight-net volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro depends_on: - hindsight-primary - hindsight-replica networks: hindsight-net: driver: bridge

关键设计点：

• 主备分离：hindsight-primary负责写入所有请求数据，hindsight-replica通过 Redis 订阅变更，同步数据并提供只读查询服务。这样即使主实例宕机，UI 查询仍可用。
• Redis 作为状态总线：所有写入事件（request created, response received）都发布到 Redis channelhindsight:events，replica 订阅并应用。
• Nginx 路由策略：/v1/*路由到 primary，/api/*和/（Web UI）路由到 replica，实现读写分离。

注意事项：hindsight-replica的HINDSIGHT_MODE=readonly是硬性要求，否则两个实例会竞争写入同一份文件，导致数据损坏。我们曾因忘记设置此变量，导致 3 小时内 12 万条请求记录丢失。

5.2 与现有技术栈集成：如何让 hindsight 适配你的 LLM 网关

hindsight 不是一个独立的网关，而是一个可插拔的观测层。它支持三种集成模式，适配不同成熟度的技术栈：

Reverse Proxy 模式实操示例（Envoy）：
在 Envoy 的envoy.yaml中，添加一个 cluster 指向 hindsight：

clusters: - name: hindsight-proxy connect_timeout: 1s type: strict_dns lb_policy: round_robin load_assignment: cluster_name: hindsight-proxy endpoints: - lb_endpoints: - endpoint: address: socket_address: address: hindsight-primary port_value: 8000

然后在 http_filters 中插入一个envoy.filters.http.ext_authz，将所有/v1/*请求转发给hindsight-proxy。这样，所有经过 Envoy 的 LLM 请求，都会被 hindsight 捕