人工智能大模型AI Agent代码智能体【免费下载链接】mini-swe-agentThe 100 line AI agent that solves GitHub issues or helps you in your command line. Radically simple, no huge configs, no giant monorepo—but scores 74% on SWE-bench verified!项目地址https://gitcode.com/gh_mirrors/mi/mini-swe-agent点击查看免费下载导读本文聚焦 mini-SWE-agent 中专门对接 OpenAIResponses API/response端点的模型类LitellmResponseModel它由litellm_response快捷名注册、通过 LiteLLM 统一网关驱动支持原生 tool calling并针对 GPT-5 等具备扩展推理reasoning能力的模型做了优化适配。读完本文你将掌握何时应选用该模型而非默认的litellmChat Completions模型、如何通过 YAML 配置或命令行启用它、Responses API 与 Chat Completions 在消息结构与工具调用解析上的核心差异以及其底层解析与成本核算的实现原理。该模型类是 mini-SWE-agent 模型家族中面向 Responses API 的代表实现与OpenRouterResponseModel、PortkeyResponseAPIModel共享同一套解析工具函数。本文以 docs/reference/models/litellm_response_toolcall.md 为骨架结合 src/minisweagent/models/litellm_response_model.py 及 src/minisweagent/models/utils/actions_toolcall_response.py 等源码展开讲解。一、什么是 Responses API 模型类定位与适用场景在 mini-SWE-agent 的模型体系中LitellmResponseModel快捷名litellm_response是官方文档明确列出的 Responses API 模型之一。根据 docs/reference/models/overview.md 的模型总览表它与默认litellmChat Completions/completion并列专门用于 OpenAI 的 Responses API快捷名端点工具调用说明litellm/completion✅默认模型经 LiteLLM 支持 OpenAI、Anthropic 及 100 提供商litellm_response/response✅LiteLLM OpenAI Responses API原生工具调用官方文档 docs/reference/models/litellm_response_toolcall.md 给出了三个明确的选型要点使用 Responses API 并需要原生工具调用时选择本模型类对 GPT-5 等模型尤其有利因为 Responses API 提供了扩展思考/推理extended thinking/reasoning能力该模型通过previous_response_id在轮次之间维护会话状态——这是 Responses API 相比 Chat Completions 的显著特性之一。值得注意的是从源码看mini-SWE-agent 的 Responses API 实现既有状态性接口的潜力又在实际请求中采用扁平化展开的无状态调用方式详见下文消息结构与无状态化一节这与文档强调的previous_response_id能力相辅相成API 层面支持基于previous_response_id的状态延续而框架层则选择将完整历史显式传入以保证确定性。二、如何启用YAML 配置与命令行两种方式2.1 通过 Agent 配置启用官方文档给出了最直接的 YAML 配置方式。在 agent 配置中指定model_class: litellm_response即可让 mini-SWE-agent 使用 Responses API 驱动该模型model: model_class: litellm_response model_name: openai/gpt-5.2 model_kwargs: drop_params: true reasoning: effort: high参数说明model_class模型类快捷名必须为litellm_response。从 src/minisweagent/models/__init__.py 的_MODEL_CLASS_MAPPING可知该快捷名被解析为minisweagent.models.litellm_response_model.LitellmResponseModelget_model_class()也支持直接传入完整导入路径如minisweagent.models.litellm_response_model.LitellmResponseModel作为model_class的值。model_name模型名强烈建议带提供商前缀LiteLLM 规范例如openai/gpt-5.2。model_kwargs透传给 API 的附加参数drop_params: true让 LiteLLM 丢弃模型不支持的参数reasoning.effort: high则是 Responses API 特有的推理强度控制这正是文档强调GPT-5 受益于扩展思考能力的配置落点。2.2 通过命令行启用不写配置文件时可在mini命令中直接用参数指定mini -m openai/gpt-5.2 --model-class litellm_response其中-m指定模型名--model-class指定模型类快捷名。这与get_model()/get_model_class()的解析逻辑一致model_class优先于model_name决定实例化哪个类src/minisweagent/models/__init__.py。三、核心实现从继承到 Responses API 专用查询LitellmResponseModel定义在 src/minisweagent/models/litellm_response_model.py其类层次为class LitellmResponseModelConfig(LitellmModelConfig): pass class LitellmResponseModel(LitellmModel): ...它直接继承自 src/minisweagent/models/litellm_model.py 中的LitellmModel与LitellmModelConfig因此自动继承了父类全部配置项与基础设施配置项来自LitellmModelConfigmodel_name、model_kwargs、litellm_model_registry成本与模型元数据注册表默认读LITELLM_MODEL_REGISTRY_PATH环境变量、set_cache_control如 Anthropic 模型的显式缓存控制标记、cost_trackingdefault或ignore_errors默认取MSWEA_COST_TRACKING环境变量、format_error_template模型输出格式不符时的错误模板默认{{ error }}、observation_template动作执行后的观察渲染模板、multimodal_regex多模态内容提取正则空串表示禁用。重试机制query()中通过retry(logger..., abort_exceptionsself.abort_exceptions)循环调用abort_exceptions列表包含AuthenticationError、ContextWindowExceededError、PermissionDeniedError、NotFoundError、UnsupportedParamsError等遇到这些异常直接中止而非重试。成本核算_calculate_cost()调用litellm.cost_calculator.completion_cost成本为 0 或计算失败时除非配置cost_tracking: ignore_errors否则抛错成功后将成本累加进全局统计GLOBAL_MODEL_STATSsrc/minisweagent/models/__init__.py支持MSWEA_GLOBAL_COST_LIMIT/MSWEA_GLOBAL_CALL_LIMIT全局限额。序列化serialize()输出model_type与完整配置的 JSON 快照便于运行结果中追溯所用模型。而子类真正差异化的是三处请求入口_query、消息预处理_prepare_messages_for_api、动作解析_parse_actions与观察格式化。3.1 请求入口从completion到responses父类LitellmModel._query调用litellm.completion(model..., messages..., tools[BASH_TOOL], ...)子类则改为def _query(self, messages, **kwargs): try: return litellm.responses( modelself.config.model_name, inputmessages, # 注意Responses API 使用 input 而非 messages tools[BASH_TOOL_RESPONSE_API], **(self.config.model_kwargs | kwargs), ) except litellm.exceptions.AuthenticationError as e: e.message You can permanently set your API key with mini-extra config set KEY VALUE. raise e关键差异端点不同litellm.completion走 Chat Completionslitellm.responses走 Responses API。参数名不同Responses API 的输入参数是input而非messages。认证失败提示抛出的AuthenticationError会附带提示——可用mini-extra config set KEY VALUE永久写入 API Keymini-extra config的具体用法见 docs/usage/config.md。tools[BASH_TOOL_RESPONSE_API]注册给模型的工具是 Responses API 扁平结构版的 bash 工具定义见下文。3.2 工具定义Responses API 的扁平函数结构Responses API 使用扁平结构无嵌套function键。定义在 src/minisweagent/models/utils/actions_toolcall_response.pyBASH_TOOL_RESPONSE_API { type: function, name: bash, description: Execute a bash command, parameters: { type: object, properties: { command: {type: string, description: The bash command to execute}, }, required: [command], }, }对比 Chat Completions 版BASH_TOOL见 src/minisweagent/models/utils/actions_toolcall.py的{type: function, function: {...}}嵌套结构Responses API 版把name、description、parameters直接放在顶层。这让 mini-SWE-agent 能借助bash工具让模型在执行 GitHub 任务或命令行任务时自由运行 Shell 命令。四、消息结构与无状态化previous_response_id与扁平化展开4.1 文档承诺的状态延续官方文档指出本模型通过previous_response_id在轮次间维护会话状态。这是 Responses API 相对 Chat Completions 的架构级差异Chat Completions 每次请求必须携带完整messages历史而 Responses API 可以只传previous_response_id引用此前响应。4.2 源码中的扁平化展开stateless 实现不过从 src/minisweagent/models/litellm_response_model.py 的_prepare_messages_for_api可以看到mini-SWE-agent 的实际做法是将历史中的 response 对象展开为其 output 条目再以完整历史发起无状态请求def _prepare_messages_for_api(self, messages): Flatten response objects into their output items for stateless API calls. result [] for msg in messages: if msg.get(object) response: for item in msg.get(output, []): result.append({k: v for k, v in item.items() if k ! extra}) else: result.append({k: v for k, v in msg.items() if k ! extra}) return result行为要点凡是object: response的旧消息会将其output列表function_call等条目逐项摊平追加到请求序列同时剥离内部extra字段成本、动作解析结果、时间戳等运行时元数据不上送 API普通消息message、function_call_output等原样保留但同样剔除extra这样每一轮请求都携带完整、自洽的会话历史保证多轮 agent 运行中工具调用链的确定性同时与format_toolcall_observation_messages产出的function_call_output消息见 4.3形成闭环。测试 tests/models/test_portkey_response_model.pyPortkey 版 Responses API 模型与LitellmResponseModel共享同一工具函数验证了该行为test_response_api_model_stateless_flattens_response断言展开后的input中历史 response 对象被替换为{type: function_call, call_id: call_1, ...}与{type: function_call_output, call_id: call_1, ...}且所有extra均被剥离。4.3 观察消息的 Responses 格式format_observation_messages复用工具模块中的format_toolcall_observation_messagessrc/minisweagent/models/utils/actions_toolcall_response.py将动作执行结果渲染为两类消息工具结果{type: function_call_output, call_id: 工具调用ID, output: 渲染后的观察}并通过call_id与模型发起的function_call一一对应人工指令无tool_call_id的动作如用户直接输入的命令{type: message, role: user, content: [{type: input_text, text: ...}]}。每个观察消息的extra中会保留raw_output、returncode、exception_info、timestamp等原始执行信息供后续格式错误处理与调试使用。未执行的动作用{output: , returncode: -1, exception_info: action was not executed}占位避免消息数不匹配padded_outputs逻辑。五、动作解析从function_call到可执行动作5.1 解析流程LitellmResponseModel._parse_actions调用parse_toolcall_actions_response(response.output, ...)该函数位于 src/minisweagent/models/utils/actions_toolcall_response.py遍历output列表筛选type function_call的条目。Responses API 的条目结构为{type: function_call, call_id: ..., name: bash, arguments: ...}——name/arguments在顶层与 Chat Completions 的message.tool_calls[].function.name嵌套结构不同若没有任何function_call抛出FormatError错误文案由format_error_template渲染默认{{ error }}完整默认模板见 src/minisweagent/config/default.yaml 中的format_error_template其中针对finish_reason为length/tool_calls的情况有专门的截断提示分支对每个function_call校验arguments必须能json.loads成 dict、name必须为bash、且必须含command键任一失败即构造带具体原因的FormatError通过校验后产出动作列表[{command: args[command], tool_call_id: call_id}]供上层 agent 执行。5.2 finish_reason 的兼容映射finish_reason_from_responses_apisrc/minisweagent/models/utils/actions_toolcall_response.py负责把 Responses API 的完成状态映射为与 Chat Completions 兼容的finish_reason字符串供format_error_template使用Responses API 用statusincompleteincomplete_details.reasonmax_output_tokens表示达到max_tokens截断该函数将其映射为length使既有的finish_reason length错误模板分支输出被截断请更简洁地回复无需改动即可复用其他情况下返回原始status。这意味着同一套format_error_template如 src/minisweagent/config/default.yaml 中针对截断和格式错误的完整提示文案可以同时服务于 Chat Completions 与 Responses API 两类模型。5.3 错误响应持久化query()在解析失败时会把成本与原始响应一并写入FormatError.messages[0][extra]优先response.model_dump(modejson)pydantic 对象否则回退dict(response)若序列化本身失败则用repr(response)兜底保证 response MUST be persisted 契约无条件成立。测试 tests/models/test_format_error_response_persistence.py 对此契约进行了专门验证。六、运行结果中的成本与追踪无论查询成功与否query()都会执行cost_output self._calculate_cost(response) GLOBAL_MODEL_STATS.add(cost_output[cost])随后把actions、cost、timestamp组装进消息的extra字段返回解析成功时还会调用response.model_dump()pydantic 对象或dict(response)测试注入的普通 dict序列化完整响应。这些信息会被上层 agent 记录进运行结果参见 docs/usage/output_files.md使得每次 Responses API 调用的工具动作、成本与时间戳都可追溯。若模型未在 LiteLLM 成本注册表中登记导致成本计算失败会给出明确指引可在配置中设置cost_tracking: ignore_errors或全局export MSWEA_COST_TRACKINGignore_errors。七、同族模型对比与选型建议根据 docs/reference/models/overview.mdResponses API 家族还有两个近亲OpenRouterResponseModel快捷名openrouter_response经 OpenRouter 网关访问 Responses API同样支持原生工具调用见 docs/reference/models/openrouter.mdPortkeyResponseAPIModel快捷名portkey_response经 Portkey AI 网关访问 Responses API见 docs/reference/models/portkey_response.md其实现src/minisweagent/models/portkey_response_model.py与LitellmResponseModel共享BASH_TOOL_RESPONSE_API、parse_toolcall_actions_response、finish_reason_from_responses_api、format_toolcall_observation_messages等全部工具函数差异仅在客户端Portkey SDK 的client.responses.create与配置项额外的litellm_model_name_override、PORTKEY_API_KEY/PORTKEY_VIRTUAL_KEY环境变量。选型建议如果你直接使用 OpenAI 系模型且希望借助 Responses API 的扩展推理能力如 GPT-5 系列选择litellm_response如果流量需要经过 OpenRouter 或 Portkey 网关如企业代理、成本治理、多供应商路由则分别选择openrouter_response或portkey_response。三者在 mini-SWE-agent 内的行为一致均以bash原生工具调用驱动 agent 执行命令。八、快速上手指南安装依赖确保环境中已安装litellm及对应提供商 SDK并配置 API Key例如通过mini-extra config set OPENAI_API_KEY YOUR_KEY用法见 docs/usage/config.md选模型命令行直接运行mini -m openai/gpt-5.2 --model-class litellm_response或在 agent 配置 YAML 中设置model_class: litellm_response与model_name调推理强度可选在model_kwargs.reasoning.effort中设low/medium/high平衡推理深度与耗时验证效果运行mini后观察输出文件中记录的actionsbash 命令及call_id、cost与timestamp确认多轮工具调用链正常闭合function_call→ 执行 →function_call_output→ 下一轮。结语LitellmResponseModel是 mini-SWE-agent 面向 Responses API 时代的适配层它复用LitellmModel的配置、重试、成本核算与序列化基础设施仅在三处关键路径上做了差异化——请求入口改用litellm.responses、消息按 Responses 扁平结构展开并剥离去内部extra、动作解析按function_call顶层结构完成。配合finish_reason兼容映射与错误响应持久化它让同一套 agent 模板与错误处理逻辑无缝覆盖 Chat Completions 与 Responses API 两种协议是理解 mini-SWE-agent 模型抽象层的最佳切入点之一。参考文件官方文档docs/reference/models/litellm_response_toolcall.md、docs/reference/models/overview.md、docs/usage/config.md核心实现src/minisweagent/models/litellm_response_model.py、src/minisweagent/models/litellm_model.py、src/minisweagent/models/utils/actions_toolcall_response.py模型路由src/minisweagent/models/__init__.py默认模板src/minisweagent/config/default.yaml测试佐证tests/models/test_portkey_response_model.py、tests/models/test_format_error_response_persistence.py赞分享人工智能大模型AI Agent代码智能体【免费下载链接】mini-swe-agentThe 100 line AI agent that solves GitHub issues or helps you in your command line. Radically simple, no huge configs, no giant monorepo—but scores 74% on SWE-bench verified!项目地址https://gitcode.com/gh_mirrors/mi/mini-swe-agent点击查看免费下载相关推荐OGX 内置 Responses Provider 深度解析OpenAI Responses API 的 Agent 化实现与运行原理OGX 内置 Responses Provider 深度解析OpenAI Responses API 的 Agent 化实现与运行原理 导读 本文围绕 OGXAI应用API网关后端模型推理服务mini-swe-agent v2.0 迁移指南从正则文本解析到原生工具调用的完整升级路线mini swe agent v2.0 迁移指南从正则文本解析到原生工具调用的完整升级路线 本篇指南以 mini swe agent v2.0 的破坏性变更为人工智能大模型AI Agent代码智能体OGX Responses API 完全指南生产可用的 OpenAI 兼容服务端 Agent 编排OGX Responses API 完全指南生产可用的 OpenAI 兼容服务端 Agent 编排 OGXOpen GenAI Stack将 OpenAIAI应用API网关后端模型推理服务上一篇3个实际场景告诉你为什么OBS RTSP服务器插件是你需要的视频分发利器下一篇AssetRipper终极指南从游戏文件中提取Unity资源的完整解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考