更新内容
/api/auto endpoint 现在是获取任意 URL 可用 response 的最简路径。直接传入目标地址。Auto 会自动决定是通过 Single、Proxy Finder 还是 Browser 执行 request，在遇到页面验证时自动处理，并返回可供下次调用复用的 session。
单个 endpoint。支持任意目标。无需由你手动切换模式。
这就是核心逻辑。本文接下来将介绍其运作机制、计费方式以及需要注意的边界情况。
工作原理
Auto 底层采用阶梯式策略（成本由低到高）。每次发起 request 时，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 调用中的三元组，用于自行重放相同的 exit。proxy 字段是一个不透明的 base36 ID（不含原始 IP），可安全记录到日志中，也可在系统之间安全传递。
影响
这里有两个关键数字。
对受保护站点的首次调用会运行 Browser 层级：渲染、解题、收集 cookie 并向你交付页面。这大约消耗 10 个 credits。一旦 Auto 为该主机缓存了可用的会话，后续调用就会直接重放：通过 Single 消耗 2 个 credits，或者在会话的 cookie 可从任意地址使用时通过 Proxy Finder 消耗 4 个 credits。因此，第二次调用的成本最高可比第一次便宜 5 倍，并且只要会话有效，之后的每一次调用都会保持这一低廉费率。我们在灰度发布期间在生产环境中测量了这一表现：无 cookie 的 exit（一旦找到）重放成本正好是每次调用 2 个 credits，而在所有 request 都经过 Proxy Finder 时，成本曾经是 10 个 credits。
第二个数字：失败的层级不会计费。如果 Auto 尝试了三个 proxy 且每个都在第四个 proxy 成功交付前返回 403，则仅对第四个 proxy 的 credits 计费。你只为交付的内容付费，而不是为搜索过程付费。
这就是核心价值所在。高成本的层级运行一次，低成本的层级在此后一直运行，而且你无需自行编写缓存逻辑。
另外两项行为也值得一提，因为它们解决了实际生产中的痛点：
受地理限制的目标不再浪费 exit。 当一个站点对大多数 exit 返回 451（或法律拦截插屏页面）时，Auto 会学习哪些国家确实交付了内容。在下一次调用中，它会优先从这些国家获取新的 exit，并在它们之间分配并发负载。因此，单个侥幸成功的 exit 不会被过度请求而触发 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 下的表现实际上优于低信任度的住宅 exit。因此，forceProxy: false 可能会让某些目标变得更容易处理，而不是更难。如果你在特定主机上反复遇到 challenge，尝试关闭此项是值得一试的方法。
ignoreProxies 是客户端规避列表。传入已知失效的 proxy id（例如来自先前在你方触发 rate limit 的 session.proxy），Auto 会在所有环节跳过它们：热 session 复用、出口节点检索以及对 Proxy Finder 的子调用。因此 Auto 不会重新选择你刚指定规避的出口节点。
meta 还支持在其基础上构建自定义仪表盘：今日触发浏览器层级的 host、单次交付的平均尝试次数、解决 challenge 的抓取与正常抓取的比例。如果某个特定 host 的消耗突然从 2 credits 飙升到 10 credits，这就是 session decay 信号，你可以在账单激增前及时处理。
组合这四项功能的示例：
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 本身，请参阅 Validate Rules Now Decide What Counts as Success 中的早期说明。
后续规划
Auto 目前有两项计划中的功能。
Session 检查功能即将进入 Dashboard。目前 Auto 为每个 host 保留的 session 都存放在服务内部，当你在排查额度消耗问题时无法直接查看。我们正在构建每个 host 的 session 视图，方便你查看已缓存的 session、存活时间、剩余有效期以及每次调用的梯级历史记录。此外还会提供手动清理 session 的按钮，以便在目标站点发生变化且确认缓存失效时直接丢弃。
之后是更严格的成本控制。包括单次请求积分硬顶（单次调用绝不超过 X，若超出则直接报错失败），以及面向目标站点完全不需要浏览器梯级的团队的“仅单次”模式。这两项功能目前均处于 feature flag 控制下。
Auto 的核心在于让你无需纠结该调用哪个产品。但这并不意味着你无法了解实际执行细节。每个 response 都会返回所走的梯级和构建的 session。查看这两个字段，你就能准确获知每次调用的成本来源。