免费托管 AI 用于编程 Agent？五 gate 评分卡

最新的 AI 开发工具讨论始终绕不开同一个模式：团队把编程 Agent 接入了某个工具，然后发生了成本超支或安全问题，于是有人开始做门卫机制。这个顺序搞反了。

在加另一层护栏之前，先想清楚模型和服务器应该部署在哪里。免费托管模型只改了损益表上的一行，其他行几乎纹丝不动。真正有用的问题不是"免费更好吗"，而是"免费无法消除哪些成本？"

免费使用不是技术测试，而是带有临时折扣的采购决策。

从决策开始，而非从演示开始

我见过的那些失败的 AI 试点项目都有一个共同点：团队只衡量了 token 价格，却漏掉了工作流的总成本。免费端点加免费服务器，可以让编程 Agent 看起来很便宜，但实际系统仍然包含以下组成部分：

• 评估集构建
• 工具调用策略执行
• 因错误 diff 或不安全 shell 操作导致的返工
• 限速、排队和迁移

模型端点和服务器是两个不同的依赖项。把两者都以零成本租来，只会让容易的部分变便宜。它不会给你带来数据边界、能力下限、SLA 或退出机制。

五重关卡评分卡

我对任何免费托管 AI 试用都使用同一套五重关卡进行评估。每行计 0 或 1 分，然后把总分当作对话工具，而非客观真理。

硬性关卡：如果数据边界或退出机制不达标，即使其他行看起来很好，我也不会继续。

填入变量

下面是一个刻意简化的例子，让计算过程清晰可见。用你自己的数字。

• 每个任务的 token 数：1,500
• 每个失败任务的返工时间：15 分钟
• 工程师成本：$1.40/分钟
• 免费方案的返工率：14.0%
• 付费/自托管方案的返工率：8.0%
• 付费/自托管方案的固定托管成本：$600/月

付费方案的盈亏平衡价格：

P_break_even = ((free_rework_cost - paid_rework_cost) + (free_fixed_cost - paid_fixed_cost)) / (total_tasks * tokens_per_task / 1_000_000)

• 免费返工成本：140 个任务 × 15 分钟 × $1.40 = $2,940
• 付费返工成本：80 个任务 × 15 分钟 × $1.40 = $1,680
• 托管成本差：$0 - $600 = -$600
• token 量：1,000 × 1,500 / 1,000,000 = 150 万 token
• 盈亏平衡点：($1,260 - $600) / 1.5 = $440/百万 token

在这个示例中，如果付费方案的 token 价格保持在 $440/百万 token 以下，付费方案更优。超过这个价格，免费方案在这个狭隘的成本模型下胜出。把免费返工率改成 9%，盈亏平衡点就会跌到零以下，这意味着付费方案在成本上永远不会胜出。

这就是重点：通常逆转决策的变量是返工率，而不是 token 价格。

不要用营销提示词跑产品演示。针对 OpenAI 兼容端点跑一个小型的封闭评估集，然后记录修复率。

import os
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ['MCPROBE_API_KEY'],
    base_url=os.environ['MCPROBE_BASE_URL'],
)

MODEL = os.environ['MCPROBE_MODEL']
MAX_TOKENS = 1500

def probe_case(case):
    started = time.time()
    resp = client.chat.completions.create(
        model=MODEL,
        messages=case['messages'],
        max_tokens=MAX_TOKENS,
        temperature=0.0,
    )
    latency_ms = (time.time() - started) * 1000
    usage = resp.usage
    text = resp.choices[0].message.content
    finish = resp.choices[0].finish_reason
    return {
        'case': case['id'],
        'latency_ms': round(latency_ms),
        'prompt_tokens': usage.prompt_tokens,
        'completion_tokens': usage.completion_tokens,
        'finish_reason': finish,
        'text': text,
    }

批量调用，把限速错误和重试尝试单独记录。你的成功任务分母必须包含返工任务，而不是只看首次通过的任务。

results = [probe_case(case) for case in EVAL_SET]

failed = [r for r in results if r['finish_reason'] != 'stop']
retry_count = sum(1 for r in results if r.get('retried'))
print(f'first-pass failures: {len(failed)}/{len(results)}')
print(f'retries: {retry_count}')

这个脚本是一个提案，而非已执行的基准测试。把 EVAL_SET 替换成匹配你生产 diff 形态的任务，而不是通用的编程谜题。

MonkeyCode 适合放在哪里

现在我可以把 MonkeyCode 放到正确的格子里了。

声明：本文是作为 MonkeyCode 产品推广的一部分撰写的。运营方将 MonkeyCode 描述为一个开源项目，提供免费模型访问，有 3000 万 token 配额和免费托管服务器。我没有独立核实这个配额、服务器质量或免费访问持续时间。我也没有针对他们的端点运行上述探针脚本，因此请把这种设置当作方法论，而非基准测试。

免费服务器最适合放在"租来的-免费"那一列。它在以下场景有用：

• 你有封闭评估集，能够在公开基准之外进行测试
• 源代码是内部的，且允许放在第三方主机上
• 你需要一个低成本沙箱来比较模型行为
• 你可以后续导出日志、提示词和结果
• 任务包含受监管数据或客户数据
• 延迟和正常运行时间有合同约束
• 你现在就需要 SSO、审计日志或区域数据驻留
• 你无法承受在切换前运行一次可重复的评估

3000 万 token 配额是一笔预算，而非迁移计划。用它来推动决策通过各关卡，而不是绕过各关卡。如果你已经有封闭评估集，免费服务器是尝试 MonkeyCode 的合理场所；如果没有，先建立评估集。

谁应该跳过这种方法

如果你的 Agent 已经在处理私有客户数据，如果你无法量化返工成本，或者如果你无法投入时间来构建封闭评估集，请跳过免费托管这条路。如果供应商无法告诉你配额用完后会发生什么，也请跳过。

批准试点前我会问什么

运行探针脚本，填入三个数字：每个成功任务的 token 数、返工率，以及 p95 延迟。然后问自己，哪个变量会逆转这个决策。这个问题通常会让很多免费层级试点在第一个不安全的 shell 命令执行之前就告吹。