更新内容
现在，/api/auto endpoint 是为任意 URL 获取有效 response 的最短路径。只需将其指向目标。Auto 会自动选择是通过 Single、Proxy Finder 还是 Browser 运行 request，在遇到反爬验证时自动处理，并返回一个可供下次调用复用的 session。
一个 endpoint。支持任意目标。无需你在客户端切换模式。
这就是其核心设计。本文接下来的部分将介绍它的工作原理、计费方式以及需要注意的边界情况。
工作原理
Auto 底层采用阶梯式策略（先低成本，后高成本）。在每次请求中，Auto 会逐级向上尝试，直到某一级别返回符合你 validate 规则的 response。
具体级别顺序如下：
- 缓存的 session。 如果 Auto 保留了来自上一次调用的同 host 热 session，会首先通过该 session 重放。这是成本最低的路径。
- Proxy Finder。 轮换 proxy request。适用于主要依赖 IP 声誉进行防护的站点。
- Browser。 完整的页面渲染，执行 JavaScript，解决反爬验证，并收集站点下发的 cookie。
一旦某个级别请求成功，Auto 会保存找到的 session：包括使用的 proxy id、站点下发的 cookie 以及 User-Agent。下次对同一 host 发起调用时，Auto 会首先尝试该 session。如果仍然有效，你只需支付低成本级别的费用，无需承担高成本。
最简调用示例：
curl -X POST "https://api.foura.ai/api/auto" \
-H "X-API-Key: pk_live_..." \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/data",
"validate": { "status": { "accept": [200] } }
}'
精简后的 response：
{
"status": 200,
"data": "...",
"headers": [...],
"meta": {
"rung": "cache",
"solved": false,
"attempts": 1,
"credits": 2
},
"session": {
"proxy": "CLN1B8",
"cookies": [{ "name": "cf_clearance", "value": "..." }],
"userAgent": "..."
}
}
有两个字段对后续构建至关重要。meta.rung 会标明哪个路径胜出。session 是一个三元组，可以直接传入 /api/single 调用，以便自行重放同一个出口。proxy 字段是一个不透明的 base36 ID（不包含原始 IP），可以安全记录在日志中，也便于在不同系统间传递。
实际效果
这里有两个核心指标。
对受保护站点的首次调用会运行 Browser 梯级：渲染、解题、收集 cookie 并返回页面。这大约消耗 10 个积分。一旦 Auto 为该主机缓存了可用会话，后续调用就会直接重放：通过 Single 仅需 2 个积分；如果该会话的 cookie 支持任意地址，则通过 Proxy Finder 消耗 4 个积分。因此第二次调用的成本最高可降低 5 倍，且只要会话有效，后续每次调用都维持低费率。我们在上线期间的生产环境中对此进行了实测：无需 cookie 的出口一旦确定，每次重放调用精确消耗 2 个积分，而此前每次请求走 Proxy Finder 时都需要 10 个积分。
第二个指标：失败的梯级不计费。如果 Auto 尝试了三个代理且均返回 403，直到第四个代理成功返回内容，系统仅对第四次调用计费。你只需为成功交付的内容付费，无需为搜索过程买单。
这就是核心价值所在。高成本梯级仅运行一次，后续持续运行低成本梯级，而且你无需自行编写缓存逻辑。
另外两项特性同样值得关注，它们解决了生产环境中的实际痛点：
受地理限制的目标不再浪费出口。 当某个站点对大多数出口返回 451（或法律限制拦截页）时，Auto 会学习哪些国家能够成功交付内容。在下一次调用中，它会优先从这些国家拉取新的出口，并在这些出口之间分散并发负载。这样可以避免单个幸运出口被过度请求而触发 rate limit。
Validate 会在每个梯级运行。 内容错误的页面（例如返回 200 状态码但正文为法律声明的地理限制拦截页）绝不会被计为成功。如果你的 validate.data.fail 包含 "legal reasons"，Auto 会持续尝试，直到某个梯级通过校验。无论是缓存梯级还是其他任何梯级都必须通过验证。如果全部未通过，你将收到包含真实原因的明确失败响应。
进阶配置
在大规模使用 Auto 时，以下几个配置参数非常重要。
timeout_ms 是整个操作的总预算，而非针对单个梯级。默认值为 120 秒。Auto 会自动分配该预算：每个子调用的超时时间为 min(自身原生超时时间, 剩余预算)，当剩余时间不足时梯级链将停止启动新梯级。对于交互式低延迟场景，建议设置为 20,000。对于容忍较长尾部延迟的大规模抓取，保持默认值即可。
forceProxy 默认开启。除非设置了 forceProxy: false，否则 Auto 绝不会从 FourA 的源 IP 访问目标。需要注意：某些站点（例如带有 IP 信任门控的交互式 Cloudflare）在干净的数据中心 IP 下的表现实际上优于低信任度的住宅出口。因此 forceProxy: false 可能会让特定目标的访问变得更容易，而不是更难。如果你发现特定主机频繁出现质询，可以尝试关闭该选项。
ignoreProxies 是一个客户端规避列表。传入已知失效的 proxy id（例如来自先前在你方触发 rate limit 的 session.proxy），Auto 将在所有环节跳过它们：热 session 复用、出口节点检索以及对 Proxy Finder 的子调用。这样 Auto 就不会重新选取你明确要求规避的出口节点。
meta 还支持在其基础上构建自定义仪表盘：监控哪些主机当天触发了浏览器层级、每次成功交付的平均重试次数，以及通过 challenge 的抓取与正常抓取的比例。如果某个主机的消耗突然从 2 credits 飙升到 10 credits，这就是 session 失效的信号，你可以在账单超支前及时处理。
组合全部四项特性的示例：
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"X-API-Key": "pk_live_..."},
json={
"url": "https://example.com/product/9876",
"timeout_ms": 30000,
"forceProxy": True,
"ignoreProxies": ["CLN1B8", "K7X9AB"],
"validate": {
"status": {"accept": [200]},
"data": {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
}
}
).json()
# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
session = r["session"] # {proxy, cookies, userAgent}
print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])
关于 validate schema 本身，请参阅 《验证规则现已决定何为成功请求》 中的前期详解。
后续规划
目前 Auto 的路线图上有两项重点内容。
首先是 Dashboard 将支持 Session 检查功能。目前 Auto 针对每个 host 保持的 session 仅存储在服务内部，当你在本地调试异常消耗时无法进行排查。我们正在开发基于 host 的 session 视图，方便你查看缓存的 session、存活时间、剩余有效期以及每个 session 的梯级切换历史记录。此外还会提供手动丢弃 session 的按钮，便于在目标站点发生变化且确认缓存失效时进行清理。
接下来是更严格的成本控制机制。包括单次 request 的 credit 硬性上限（单次调用绝不超过 X，超额即明确报错）以及针对无需浏览器梯级场景的“仅单次模式”。这两项功能目前均处于特性开关控制阶段。
Auto 的核心价值在于免去选择调用哪款产品的负担。但这并不意味着黑盒运行。每个 response 都会返回实际采用的梯级和建立的 session。查阅这两个字段，即可准确掌握每次调用的成本构成。