Agent-Reach 生产部署中的基础设施设计：降低代理成本与 Token 使用量
makedream19 juin 2026
0
Computing/Software
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
在本地 CLI 中运行良好的 Agent-Reach 代理，一旦部署到生产服务器，往往会四处碰壁。当数万次爬取请求涌入时，它们会受到 Cloudflare 等 CDN 安全网络的阻拦，IP 陆续被封锁。然而，若一味依赖昂贵的住宅代理，带宽成本将不堪重负。若直接将原始 HTML 推送给 LLM，不仅上下文会爆满，还会面临巨大的 Token 费用支出。要解决这一问题，需要构建动态路由架构和预处理流水线。
如果不加防范地运行 Agent-Reach，仅住宅代理的费用就可能高达数千美元。在一个每天处理 100,000 次请求、平均每页大小为 150KB 的系统中，如果失败率达到 50%，每月的流量将高达 675GB。Bright Data 或 Oxylabs 等优质住宅代理的价格在每 GB 4 美元到 8 美元之间。如果所有流量都通过这些代理，月成本将飙升至 5,400 美元。
通过将开源代理聚合器 Scrapoxy 部署为基于 Docker 容器的超级代理，可以在保持单一终端节点的同时控制基础设施成本。首先，在项目根目录创建一个 docker-compose.yml 文件，定义 valkey/valkey:7.2-alpine 和 fabienvauchelles/scrapoxy:latest 镜像。在 Valkey 容器中通过指令 --appendonly yes --requirepass [密码] 确保凭证缓存的持久性。在 Scrapoxy 环境变量中设置用户名和密码后，使用 docker compose up -d 命令启动容器。通过此配置，每月可节省超过 200 美元的订阅费用。
根据目标平台的安全策略，需要将 IP 更换周期分为两种模式，以免破坏会话。对于无需认证的公开只读请求，设置 30 秒到 3 分钟的激进 TTL，并通过轮询（Round Robin）方式强制每次分配新 IP，这是规避基于阈值的封锁的必要措施。相反，对于像 X 或 Reddit 这样必须保持会话 Cookie 的认证平台，需开启 Scrapoxy 的 Cookie 注入功能，并将同一住宅 IP 节点固定 5 到 10 分钟，以防止因地理位置 IP 突然变更导致认证会话过期。
为了进一步削减成本，应在 NGINX API 网关层优化流量路由。在 NGINX 配置文件 (/etc/nginx/nginx.conf) 的 upstream 块中，分别定义每 GB 仅 1 美元左右的 DataImpulse 等低成本数据中心代理池，以及 Scrapoxy 住宅代理池。在 server 块内创建 /fetch/generic/ 路径，将 RSS 订阅或 GitHub 搜索等安全要求较低的公共 HTML 流量转发至数据中心代理。随后创建 /fetch/social/ 路径，仅将高摩擦的社交平台终端请求路由至 Scrapoxy 后端并注入头部信息。应用这种双轨路由，可以防止昂贵的住宅代理带宽浪费，并将整体代理费用降低高达 90%。
原始 HTML 数据充斥着冗余的 DOM 元素、样式表和内联脚本。如果直接输入给 LLM，不仅会消耗不必要的 Token，还会干扰推理结果。将网页原始数据转化为 Markdown 格式，而非以未处理状态注入上下文窗口，可将数据大小减少 75% 到 90%。在流水线的预处理阶段进行基于正则表达式的清洗和 Markdown 序列化，可节省 40% 以上的 LLM API Token 消耗，同时防止上下文窗口超限错误。
通过组合解析器组件 Trafilatura 和 html2text，实现一个预处理输入数据的 Python 函数。调用 trafilatura.extract() 函数时指定 favor_recall=False 选项，以排除侧边栏和广告，仅提取正文。为防止主内容块提取失败，插入 Fallback 代码，创建一个 html2text.HTML2Text() 对象并设置 ignore_images=True 和 body_width=0。在提取的 Markdown 文本中运行正则表达式 (re.sub) 去除 <script>、<style> 等残余标签，并执行压缩连续空行的清洗流程，从而降低代理的响应延迟。
在分割长文档时，应引入基于语义相似度而非简单字符数的切分算法，以保持上下文连贯性。计算句子单位文本嵌入向量之间的余弦相似度，以捕捉语义断点。
Similarity(u, v) = rac{u cdot v}{\|u\| \|v\|}计算相邻句子之间的距离，将距离差异超过整个文档 95 分位数的边界定义为语义切分点，从而生成分块列表。相比固定长度切分，应用语义切分可以防止相关信息被拆散到不同分块中导致丢失，从而提高 LLM 的信息检索准确度。
X 或 LinkedIn 等平台的速率限制非常严格，经常会遇到 HTTP 429 或 403 错误。在这种暂时性故障中，如果同步应用程序进程反复立即重试，服务器资源会耗尽，IP 被封锁的程度也会加剧。为了确保系统韧性，需要一个异步异常处理中间件，明确异常性质并动态调节目标服务器的负载。
在设计错误处理类时，必须准确区分临时错误和永久错误。如果 HTTP 状态码为 429、502、503、504，或错误消息中包含 'timeout'、'connection refused'，则归类为临时错误并列入重试对象。相反，401 或 400 等归类为永久错误，应立即将其隔离到死信队列 (DLQ) 中。对于临时错误，为防止同一时刻大量请求涌入导致的“惊群效应” (Thundering Herd)，应应用包含随机毫秒抖动的指数退避算法。等待时间的计算公式如下：
若将初始基准延迟 () 设置为 30 秒，最大限制 () 设置为 600 秒，第 3 次重试时将确保约 240 秒左右的分布等待时间，从而规避目标平台的封锁策略。
为了防止特定平台的故障或安全强化导致整个工作流瘫痪，在中间件层实现基于 Redis 的舱壁模式 (Bulkhead Pattern)。创建按目的域名划分的独立 Redis 列表 (queue:bulkhead:twitter, queue:bulkhead:reddit, queue:bulkhead:general)，而不是单一的全局队列。对各队列的消费工作者池设置差异化的并发限制，例如 Twitter 为 3，常规 Web 为 25。利用 Redis 的 Sorted Set 管理失败任务的重试计划，将恢复时间戳作为分数值注册，编写延迟处理程序。应用这种舱壁结构，即使特定社交媒体发生 API 封锁，也仅会导致相应工作者进入等待状态，从而将整体代理的研究工作成功率保持在 95% 以上。
从各种 Web 资源中随机抓取的原始数据可能包含日期不符或虚假事实，容易导致 LLM 进行扭曲的推理。在向生成式 AI 模型提供上下文之前，必须在流水线末端结合一个离散的验证层，用以计算 Markdown 文件内容的可信度并验证数值一致性，从而阻止幻觉现象。
设计一个确定性过滤器类，计算已收集元数据的时间有效性和各平台来源权重。根据系统时间，将带有未来时间戳或无效 ISO 格式日期的文档从数据集中剔除。此外，声明一个映射各平台来源可信权重的字典，赋予 GitHub 0.95、Wikipedia 0.90，而给予 Reddit (0.50) 或 Twitter (0.40) 等社交媒体较低的基础分数。只有当文档内的作者名和标题完整保存时，才通过增加 0.05 元数据权重加分的逻辑生成最终可信度分数。分数低于标准的资产将在 LLM 提示词组装阶段被源头剔除。
为最终保证输出数据的质量，启动一个将生成的候选答案与原始上下文进行比对的评分脚本。
\b\d+(?:\.\d+)?%?\b) 对原始数据集中存在的数字符号集与生成句子中的数字集进行交集运算。如果检测到源中不存在的任意数值或货币单位，则触发数值不一致标志，并通过路由中间件立即要求重试。通过联动这种多层验证层，在架构层面阻断基于爬虫的代理可能产生的数值篡改及虚假引用问题，确保最终交付给用户的是完全经过验证的研究结果。