mini-SWE-agent 与 Claude Code：工作流、模型与总成本

mini-SWE-agent 和 Claude Code 不是同一产品的两个版本：mini 是一个免费的 MIT 许可 Python agent，只有一个工具——bash——并通过 LiteLLM 访问任意模型；Claude Code 则是 Anthropic 的专有 agent，只支持 Anthropic 形状的协议。 这一点差异决定了大多数迁移，因为它是协议边界，而不是偏好。想要足够小、便于阅读的执行框架以及自由选择提供商时，选择 mini；想要编辑器、桌面端和 CI 界面、权限模式及订阅路径，并且会继续使用 Claude 模型时，选择 Claude Code。

mini-SWE-agent 由 SWE-agent GitHub 组织维护，并将自身描述为“由 Princeton & Stanford 团队构建，该团队也是 SWE-bench、SWE-agent 等项目的幕后团队”。首先需要更正一点，因为关于它被引用最多的事实已经过时。其 v2 迁移指南说明“v2.0 默认使用原生工具调用（而不是基于正则表达式的文本解析）”，而项目自己的 FAQ 仍表示“它甚至不使用 LMs 的工具调用接口”，并称“操作会从三个反引号代码块中解析”。这两个页面均于 2026 年 9 月 19 日阅读。迁移指南和随附配置应优先采信：mini.yaml 告诉模型，“每个响应都必须至少使用一次‘bash’工具来执行命令。”任何基于不调用工具的说法，或基于已移除的 MSWEA_MODEL_API_KEY 变量的教程，都早于 v2。

应该选哪一个

如果你的工作具有批处理或提供商导向的特点，请选择 mini-SWE-agent：例如对许多问题运行相同提示、比较模型，或在沙箱中工作，在这种场景下，一个小到可以审计的 agent 比无法检查的功能集更有价值。其执行模型是决定性特征：mini 的 FAQ 说明操作通过 subprocess.run 执行，“每个操作都完全独立（而不是保持一个有状态的 shell 会话运行）”，因此“agent 无法切换目录或导出环境变量；不过可以为每个操作设置环境变量”。随附的 mini.yaml 也向模型说明了同一点——“目录或环境变量更改不会持久化。每个操作都会在新的子 shell 中执行”——并要求使用带前缀的命令。这使运行可复现，也能轻松容器化，但会让长时间的有状态 shell 工作变得不便。迁移成本只需一个下午：pip install mini-swe-agent、一个 YAML 文件和一个密钥。

如果价值在于界面和防护机制，请选择 Claude Code。Anthropic 将其描述为可在“终端、IDE、桌面应用和浏览器中”使用，并指出“Terminal CLI、VS Code 和 JetBrains 也支持第三方提供商”——因此网关路由只存在于其中一部分界面。它提供权限模式、子 agent、MCP 服务器、钩子和计划模式；使用 Pro 或 Max 订阅时，消耗的是套餐额度，而不是按 token 计费。代价是特定类型的锁定：你不能让它脱离 Claude 模型，且 Anthropic 的网关文档说明它“不支持通过任何网关将 Claude Code 路由到非 Claude 模型”。

从 Claude Code 切换到 mini意味着放弃权限系统，换取 mini 的三种模式；完全放弃 IDE 和桌面端界面；并自行负责支出核算——mini 的每次运行预算只有在 LiteLLM 能为你的模型 ID 定价时才有效。从 mini 切换到 Claude Code意味着放弃自由选择模型，并从一个可以阅读的执行框架转向打包的二进制文件：claude-code 仓库是一个分发点，其许可证文件只有一行声明——“© Anthropic PBC. All rights reserved”——且使用受 Anthropic《商业服务条款》约束。

两个 agent 并列比较

于 2026 年 9 月 19 日阅读的来源：mini 的 PyPI 元数据、Claude Code 的 npm 注册表文档、mini 的 CLI 页面、mini 随附的 mini.yaml，以及 Anthropic 的 CLI 参考和概览。

为什么“mini 击败 Claude Code”并不是结论

mini 的主页上有一条新闻写着“mini-swe-agent 在 DeepSWE 上击败 Claude Code 和 Codex”，值得看看 DeepSWE 实际测量了什么。其说明写道：“每次运行都使用 mini-swe-agent，即 SWE-bench 作者构建的执行框架。我们在每个模型上保持它不变，因此排行榜反映的是模型能力，而不是周围的脚手架。”因此，该排行榜是 mini 内部模型的排名，而不是 mini 与其他 agent 之间的排名。

该工作中唯一的执行框架对执行框架比较，是针对“相同的 10 个 SWE-Bench Pro 任务”进行的试点；在相近 token 成本下，标准化执行框架与原生执行框架持平或更优——作者还立即提醒：“其中一部分差距很可能来自提示调优，而不是能力。”在少数模型上测试 10 个任务，不足以对两个 agent 进行排名；研究本页面时也没有找到其他规模可用且可信的正面对比。因此，本指南不为它们评分，而是比较可核查的内容：协议、权限、支出控制和迁移成本。

关键问题：它们各自能访问哪些端点

这是两者差异最大的地方，也是决定网关是否可用的部分。

Claude Code 受协议锁定。 Anthropic 的网关兼容性指南列出了三种格式：由 ANTHROPIC_BASE_URL 选择并调用 /v1/messages 以及可选的 /v1/messages/count_tokens 的 Anthropic Messages；Amazon Bedrock InvokeModel；以及 Google Cloud 的 Agent Platform rawPredict。没有 chat-completions 模式。基础 URL 是 origin，因为 Claude Code 会追加路由——Kunavo 自己的 ANTHROPIC_BASE_URL 页面也遵循同一规则。

# Claude Code speaks the Anthropic Messages format and appends the route
# itself, so the variable is the ORIGIN — not the /v1 URL mini wants.
export ANTHROPIC_BASE_URL=https://api.kunavo.com   # origin, no /v1
export ANTHROPIC_AUTH_TOKEN=sk-kn-...              # sent as Authorization: Bearer

# Pin models Kunavo serves. Claude Code's default and its opus alias are the
# newest Opus — pinned here to Opus 5.5, which needs Claude Code v2.1.280 or
# later (run `claude update`). The sonnet alias asks for Sonnet 5.5, which
# Kunavo does not serve: unpinned, /model sonnet, opusplan's execution phase
# and sonnet subagents 404.
export ANTHROPIC_MODEL=claude-sonnet-5
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-5-5
export ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-5
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5

claude

有三个后果值得纳入预算。凭据变量决定请求头：Anthropic 的连接页面说明，“ANTHROPIC_AUTH_TOKEN 位于 Authorization: Bearer 中，ANTHROPIC_API_KEY 位于 x-api-key 中，而 apiKeyHelper 位于二者中”，并且错误变量中的凭据“会以网关不读取的请求头到达网关，导致请求以 401 失败”。提示缓存没有 beta 配对，会静默失败：Anthropic 的指南称，网关丢弃 cache_control 后会产生“没有错误：每一轮对话都会按未缓存输入计费”。除非设置 CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1，否则模型发现处于关闭状态；设置后，Claude Code 只保留包含“claude”或“anthropic”的 ID。

mini 不受协议限制，但配置较为繁琐。 它完全没有基础 URL 环境变量；其本地模型页面说明，model_kwargs 会直接作为 litellm.completion(model=model_name, messages=messages, **model_kwargs) 传入。这里要保留 /v1 后缀——这与上文 Claude Code 的规则相反。同一页面的示例在未加前缀的模型名称上设置了 custom_llm_provider: "openai"，因此下面的 openai/ 前缀属于稳妥做法而非要求；页面明确要求的是，如果使用其中任一项，“它还必须与配置中的 litellm_provider 匹配”。

# mini has no base-URL environment variable. The endpoint goes in a config
# file, because model_kwargs is splatted straight into litellm.completion().
model:
  model_name: "openai/claude-sonnet-5"        # prefix and provider must agree
  model_kwargs:
    custom_llm_provider: "openai"
    api_base: "https://api.kunavo.com/v1"    # keep /v1 here
    drop_params: true                        # the shipped mini.yaml sets this too
  # set_cache_control is already "default_end" for a name containing "claude"

将密钥作为 OPENAI_API_KEY 提供，可以通过环境变量提供，也可以通过 mini-extra config set 提供；后者会写入 mini 的 .env。mini 的全局配置页面指出，“环境变量优先于 .env 文件中设置的变量。”使用 mini -c kunavo.yaml 选择文件，或使用 MSWEA_MINI_CONFIG_PATH 将其设为默认文件。

有一种不易察觉的失败模式值得单独修复。mini 的每次运行预算依赖 LiteLLM 的费用跟踪，而费用跟踪需要识别模型 ID——本页面未检查 Kunavo 的 ID 是否已在 LiteLLM 注册表中定价。请假定它们没有，并自行提供费率，而不是使用 MSWEA_COST_TRACKING="ignore_errors"；后者会移除保护，而不是修复问题。将 LITELLM_MODEL_REGISTRY_PATH 指向 LiteLLM 模型价格格式的文件。mini 的工作示例以不含提供商前缀的模型名称作为条目键，并通过 litellm_provider 声明提供商；这里复制的就是这种格式：

{
  "claude-sonnet-5": {
    "input_cost_per_token": 0.0000014000,
    "output_cost_per_token": 0.0000070000,
    "litellm_provider": "openai",
    "mode": "chat"
  }
}

有两个需要如实说明的空白点。Kunavo 尚未针对其端点对任一客户端进行运行时测试，而发布配置参考并不等于兼容性测试。具体尚未验证的是：LiteLLM 的 openai/ 路径是否会针对 Kunavo 的 chat-completions 端点协商原生工具调用——这是 mini v2 的默认行为。如果不行，mini 仍会通过 model_class: litellm_textbased 提供旧版文本解析路径，并随默认配置附带 mini_textbased.yaml 配置。尝试任一客户端时，请保留一条可用路由，并查看账户对受限任务实际记录的内容。

运行它们各自需要多少费用

软件价格无法比较，因为只有其中一个有价格。

价格卡和支持文章对 Max 层级的描述不同——前者将其合并为一个“起始价”，后者则分别列出两个层级。制定预算前，请在结账时确认层级和总额。这里有意省略 Team 和 Enterprise 席位价格：它们是组织的席位决策，而不是本页面所讨论的单个开发者选择。

对于按用量计费的使用，Anthropic 发布的是一个范围，而不是每项任务的数字：“在企业部署中，平均成本约为每位开发者每个活跃日 $13、每位开发者每月 $150-250，并且 90% 的用户每个活跃日的成本低于 $30”（成本管理文档）。这是 Anthropic 自有部署的汇总数据，不是对任一 agent 进行相互比较的测量；mini 没有对应数据。

一个令牌估算示例

这是用于说明的 token 计算，不是经过测量的任务成本，也不是账单上限。两个 agent 都会在每一轮重新发送对话——Anthropic 自己的文档说明，“Claude Code 会在每次请求中发送完整对话，而每次 Claude 使用工具时，它还会发送一个携带该批工具结果的新请求”——因此输入占主导。假设一个受限任务在各轮中总计包含 600k 个未缓存输入 token，以及 25k 个输出 token。费率是实时的、按每百万 token 计价的 Kunavo 目录价格。

请将其视为比率，而不是预测。在这些假设下，Claude Haiku 4.5 与 Claude Opus 5 之间的差距约为 5.0×，这比客户端选择更具影响力。还要注意，列出的最低费率与完成任务的最低成本是不同的说法：需要三次尝试的更便宜模型，成本可能高于一次成功的模型；而 mini 的独立子进程循环会在步骤失败时重新发送更多上下文。缓存会再次改变结果，而且方向并不像大多数文章假设的那样。Claude Code 会自行附加 cache_control 标记。mini 也会自行设置 set_cache_control: "default_end"，但只针对部分模型名称：其模型选择代码会在解析后的模型名称包含 anthropic、claude、sonnet 或 opus，且配置尚未设置该键时应用默认值。因此，Claude 名称的 ID——包括上文带前缀的 openai/claude-sonnet-5——无需请求即可获得标记；Gemini 名称的 ID 则不会。chat-completions 端点是否会处理这些标记，本页面未进行测试。参见提示缓存。

Kunavo 目录中的金额是计费下限而不是上限：上游报告费用后，账单取目录成本与上游成本乘以适用加价二者中的较高者。缓存费用和外部工具不包含在此示例中。最低充值额是预付额度中的 $10——这是资金最低要求，而不是任务费用或订阅费用。参见计费详情；另请注意，Claude Code 自己的 /usage 数值“根据 token 数量和标价在本地计算”，并明确是“估算值”，因此应与提供商的账本核对，而不是依赖客户端读数。

还需要澄清一点：SWE-agent 不等于 mini-SWE-agent

这个较早的兄弟项目仍会出现在这些查询的排名中，也共享一个组织、README 系列和基准测试渊源——但它的配置语法、文档都不同，也不属于 mini 教程。其维护者已经转向其他方向：SWE-agent README说明，“我们当前的大部分开发工作都集中在 mini-swe-agent 上，后者已经取代了 SWE-agent”，并建议今后使用 mini（阅读于 2026 年 9 月 19 日）。它并未归档，项目也采用 MIT 许可证，因此应将其视为“仍在维护但已被取代”，而不是已停止的项目——新工作应从 mini 开始。

设置其中任一个

Kunavo 为 Claude Code 发布了配置参考，但没有为 mini-SWE-agent 发布；这里没有对任一客户端进行运行时测试，而发布设置页面并不等于兼容性测试。如果 Claude Code 是你的客户端，请从 Claude Code 集成指南开始，并在准备为密钥充值时创建 Kunavo 账户。如果你要先在订阅和按量计费 token 之间做选择，Claude Code 价格和无订阅使用 Claude Code会介绍这一决策，适用于 Claude Code 的最佳 API则比较不同路由。对于 mini，模式就是 OpenAI 兼容 API中介绍的通用模式。要比较其他终端 agent？OpenCode 与 Claude Code 对比和Aider 价格还介绍了另外两个客户端，它们同样将免费执行框架与按量计费的模型账单分开。

常见问题

于 2026 年 9 月 19 日直接获取并检查每个来源：mini-SWE-agent 的 PyPI 元数据、主页、v2 迁移指南、FAQ、CLI、全局配置和本地模型页面，主分支上的随附 mini.yaml、run/mini.py 和 models/__init__.py；Claude Code 的 npm 注册表文档、仓库许可证文件，以及其概览、网关、网关协议、网关连接、成本和 CLI 参考文档；claude.com/pricing 和 Max 套餐支持文章；SWE-agent README；以及 DeepSWE 说明。未对任一客户端针对 Kunavo 执行运行时测试，也未复现本页面中的任何基准测试结果。Kunavo token 费率来自实时目录，本页面的所有美元示例均为说明性的 token 计算。