Agent的SQL起草循环放在托管免费模型还是自有免费服务器上？

一个Agent为了起草一份报表查询，反复尝试了四十一次，每一次单独看都算不上慢。真正的开销只有在把尝试次数与墙钟时间、每次重试的prompt token数画在同一张图上时才显现出来。真正令人在意的是：决定这种波动的是起草步骤的部署位置，而非模型质量本身。这个观察引出了一场与同事反复争论的讨论：Agent的SQL起草循环，到底该跑在共享托管端点上，还是跑在一台自己控制的免费服务器上。

rss source: Hosted Free Models or a Free Server: Where an Agent's SQL Drafting Loop Should Run

为什么部署位置比模型质量更关键

任务本身很普通：Agent读取schema摘要、起草SQL、以只读方式执行、读取错误、再修订。每一次修订都会把不断增长的对话历史重新发送，于是第十二次尝试携带的prompt token远多于第一次。

当起草步骤跑在共享的托管端点上，重试延迟和配额压力是别人的调度问题；当它跑在自己控制的机器上，延迟是你的问题，但重试风暴的形状由你决定。作者坦言并没有一个能替所有人一锤定音的benchmark，因此给出的是一个可复现的harness、它采集的四个信号，以及一条团队可以用自己的数据去争论的决策规则。

据原文披露，MonkeyCode宣传免费模型访问和一个免费服务器选项，这恰好对应本文讨论的分叉点。作者声明本文为该产品外联的一部分，以免费层用户而非benchmark权威的身份描述，并把免费token额度（运营方声明注册即送一千万token）与免费服务器视为写作时的宣称，建议读者去项目页面自行核实。

什么是 prompt token 与上下文膨胀？

在 LLM 调用中，prompt token 指发送给模型的输入部分所包含的 token 数量，包括系统提示、schema 摘要、历史对话与当前指令；completion token 则是模型生成的输出部分。Agent 的 SQL 起草循环之所以成本会随时间攀升，正是因为每一轮修订都要把此前所有尝试的对话历史原样重发——历史越长，prompt token 越多，单次重试的开销就越大。这就是所谓的“上下文膨胀”（context bloat）：当历史积累到几十轮后，真正起作用的指令在总 token 中的占比被稀释，既拉高了延迟与费用，也可能让模型对最新错误的关注度下降。理解 prompt 与 completion 的比例，是判断一个循环究竟是被历史重发拖累、还是被生成本身拖累的关键。

立场A：借用托管免费模型层

第一种立场是：Agent的起草循环应默认走托管免费层，因为起步成本是分钟级而不是天级。认证、把循环指向端点，schema摘要、prompt组装和重试逻辑都留在原处。对单个开发者验证Agent能否产出可用查询而言，这是通往证据的最短路径。

第二个论点是运维层面的：不需要任何人去打补丁、重启或监控。如果端点退化，你已经写好的重试逻辑会吸收它，明天可以重跑同一套任务。

反方论点（作者本人倾向这一方）是：共享免费层不给重试上限的控制权，所以失控循环在停摆之前都是不可见的。

立场B：在免费服务器上自持起草步骤

第二种立场是：起草步骤应属于一台自己控制的机器，哪怕这台机器是免费获得的。一旦模型与数据库相邻运行，schema摘要永不跨越你的边界，并发、重试和上下文增长都由你自己设上限。对于受监管的schema或触碰生产元数据的循环，这条边界往往就是全部论据。

自持同样让失败模式变得可读。当重试风暴开始，你看到的是自己仪表盘上的内存、队列深度和单请求延迟，而不是别人状态页上的数字。代价也是真实的：必须有人负责镜像、模型权重、重启策略和容量上限。

一个可以真正运行的部署位置harness

作者给出的是一份提议中的harness而非已验证的benchmark。它每次起草尝试写一行JSONL，让部署决策建立在你的数据而非作者的观点上。token计数器只是廉价代理，后端是dry-run回声，因此不依赖任何虚构的供应商数字。

# bench_placement.py — 提议中的harness；作者尚未对MonkeyCode执行过。
import argparse, hashlib, json, statistics, time
from dataclasses import asdict, dataclass

@dataclass
class Attempt:
    task_id: str
    placement: str      # "hosted-free" | "free-server"
    attempt_no: int
    prompt_tokens: int
    completion_tokens: int
    wall_ms: int
    ok: bool
    error_class: str | None
    sql_sha256: str | None

运行对比的步骤

往tasks.txt写二十个任务，把简单查询与两三个join混合，并让两种部署位置共用同一份文件。
把你的后端接进draft_sql，保持返回契约不变，这样两次运行之间的JSONL schema不会变化。
先跑python bench_placement.py --placements hosted-free --out hosted.jsonl，再用--placements free-server重复一次。
比较每任务尝试次数和p95墙钟时间，而不是平均延迟，因为重试风暴藏在尾部。
无论部署在哪，执行前都要对每条生成的语句设闸，用带超时的只读事务。

-- 廉价护栏：在只读计划之前，绝不让草稿触碰数据。
BEGIN;
SET LOCAL transaction_read_only = on;
SET LOCAL statement_timeout = '3s';
EXPLAIN (FORMAT JSON) /* 生成的语句放在这里 */;
ROLLBACK;

真正决定方向的四个信号

JSONL文件里有四个信号承担了大部分决策权重。每任务尝试次数告诉你为重发上下文付出了多少；prompt与completion token之比告诉你循环是否被对话历史而非生成主导；尾延迟告诉你共享层对你的重试模式处理得有多糟；schema的敏感级别告诉你边界论据是否会压倒上面所有数字。

信号	托管免费层胜出条件	免费服务器胜出条件
每任务尝试次数	大致四次以下	八次以上，且你能限制并发
Schema敏感度	仅公开、fixture或合成数据	内部或受监管元数据
尾延迟（p95）	你能容忍排队	你需要自己控制的稳定上限
运维能力	无人可接手一台机器	有人负责重启与容量

为什么看 p95 而不是平均延迟？

重试风暴的特征是：大多数请求很快返回，少数请求因为排队、限流或上下文超长而耗时极长。平均值会被大量“正常”请求稀释，掩盖尾部问题；p95（即 95% 请求所经历的延迟上限）则直接暴露最慢的那一小部分请求。对 Agent 起草循环来说，一次尾部超时往往触发下一轮重试，进而把更多历史塞进下一次请求，放大后续延迟，形成正反馈。因此评估部署位置时，p95 与尝试次数的组合比平均延迟更能反映真实体验，也更接近用户抱怨的那类“偶尔卡死”。

两侧各自的失败分析

托管侧最常见的失败是循环中途的静默配额耗尽：Agent不断重试，端点不断拒绝，而循环却报告为schema错误。必须把错误类别分开埋点，否则你会把限流误读为join写错。第二种是上下文膨胀，第十五次尝试携带的历史多到真正的指令变成了舍入误差。

服务器侧的失败通常是资源耗尽而非拒绝。一个热模型加三个并发Agent可能超出内存，进程在没有有用信息的情况下死去。冷启动也会扭曲早期延迟，所以每次运行要丢弃第一个任务，否则你是在拿启动成本和稳态做比较。两种部署位置都不能修复一条错误的查询，而这恰恰是人们最希望部署位置去解决的失败。

一条值得辩护的决策规则

每个新Agent循环都从托管免费层起步，并把harness跑起来，因为证据胜过架构辩论。当每任务尝试次数越过八次，或schema变得敏感，或尾延迟成为用户抱怨的约束时，就把起草步骤迁到免费服务器。无论哪种情况都让harness进版本控制，因为当初证明迁移合理的数字，将来也会证明迁回合理。

这类决策的好坏只取决于你真正试过的替代方案。如果想在同一套任务上测试两种部署位置，MonkeyCode的免费模型访问和免费服务器选项提供了两种可直接运行的配置，且无需走采购流程。

局限与谁应该跳过这个话题

这个harness衡量的是部署位置，而非正确性；token计数器只是代理而非真实tokenizer，所以应把数字视为相对值。免费token额度和免费服务器是运营方宣称的可用性，作者未独立benchmark；在免费服务器上自持仍然需要有人负责镜像。

如果你需要确定性的亚秒级p99延迟，或合规规则禁止第三方推理，那么决策在benchmark运行之前就已经做出，应当直接跳过这场辩论。同样要跳过的是：如果你的Agent从未产出过一条被评审者批准的查询，部署位置救不了一个尚未证明自己能工作的循环。