AI 编程助手终于能「动手改文件」了:LangChain 全面接入 Open apply

AI 编程助手终于能「动手改文件」了:LangChain 全面接入 Open apply_patch 内置工具

apply_patch · Responses API · langchain-core 1.4.3 · langchain-openai 1.3.0 —— LangChain 在这一波更新中完整接入了 OpenAI 的 apply_patch 内置工具，让代码编辑 Agent 的补丁操作不再被框架丢弃。

从编排框架到 Agent 工程平台

LangChain（GitHub 138k+ stars）是目前生态最丰富的 LLM 应用开发框架。它起家于链式编排，如今已演变为覆盖模型抽象、工具调用、多 Agent 编排（LangGraph）、可观测性（LangSmith）的 Agent 工程平台。核心库 langchain-core 提供模型、消息、工具等底层抽象； langchain-openai 则封装 OpenAI 系列模型与 API 的接入适配。整个框架按功能拆分为十余个子包，各自独立版本号、统一发布节奏，每月推进从核心到各集成包的迭代。其用户覆盖个体开发者到企业团队，在 Agent 构建、RAG 应用、自动化工作流等场景中都有广泛使用。

2026 年以来，LangChain 加速融入 OpenAI Responses API 的生态。继支持 web_search_preview、computer_use_preview 等内置工具后，本次 apply_patch 的补位，使工具链进一步覆盖代码编辑场景。配合 langchain-core 1.4.2 中废弃有问题的 dict() 方法等清理动作，整个生态在持续向稳健方向演进。

Agent 写代码却丢了补丁

用 AI 编辑代码的场景已足够常见：让模型生成一个新文件、修改某处逻辑、或者批量重构。OpenAI 在 Responses API 中为此设计了 apply_patch 内置工具——模型可以输出结构化的文件操作指令，包括 create_file（新建文件）与文件级增量修改等，并附上完整的 diff 内容。这意味着 Agent 不再需要手动拼接工具调用参数，而是由 API 原生产出标准化的 patch 操作。

然而在此之前，LangChain 的 OpenAI 适配层并没有识别 apply_patch。当模型返回 {"type": "apply_patch_call"} 时，LangChain 将其视为未知类型直接丢弃，最终 AIMessage.content 变为空列表， tool_calls 也为空。用户在 bind_tools 中传入 {"type": "apply_patch"} 也无法通过工具校验。结果就是：一个明明能写补丁的模型，经过 LangChain 转发后补丁消失了，Agent 接收到的是一条空消息。

开发调试时尤其令人困惑——API 原始响应中清清楚楚的 patch 指令，到框架的消息体里就人间蒸发。这个问题在 GitHub issue #37031 中被正式报告，来自一位正在构建代码编辑 Agent 的开发者。该 issue 指出了两个具体痛点：非流式返回中 content 被清空，流式模式中 apply_patch_call 事件未被累积到最终消息。这两个问題实质上指向同一个根因：框架缺少对 Responses API 新增输出类型的透传处理。

三个层面补上缺失的拼图

本次 langchain-core 1.4.3 与 langchain-openai 1.3.0 协同发布（2026 年 6 月 9 日），在三个层次上补全了 apply_patch 的支持链路：

工具注册。 apply_patch 被加入两份 well-known tools 白名单— 一份在 langchain-core 的 convert_to_openai_tool 函数，一份在 langchain-openai 的 ChatOpenAI 模型。此后 bind_tools([{"type": "apply_patch"}]) 不再报错，而是直接透传给 OpenAI API 处理。

输出保留。 模型返回的 apply_patch_call 和 apply_patch_call_output 两种输出类型被加入响应转换分支。现在它们会以原始字典形式保留在 AIMessage.content 列表中。用户可以直接从 message.content 取到完整的 patch 结构，包含 type、call_id、operation（含 path 与 diff）、status 等字段，无需从原始 API 响应中手动提取。

流式透传。 Responses API 的 SSE 流式模式中，如果模型在推理过程中产生 apply_patch_call，原来的流式处理分支同样会丢弃它。本次更新在 response.output_item.done 事件分支中新增了识别与透传，确保流式 chunk 也能承载补丁操作。

Round-trip 输入。 消息历史中的 apply_patch_call 和 apply_patch_call_output 可在后续对话中被重新作为输入发送给模型，支持多轮对话中的补丁引用与修正。

对应到代码层面，用法极其简洁：

model = ChatOpenAI(
    model="gpt-5.2",
    output_version="responses/v1"
)
model_with_tools = model.bind_tools(
    [{"type": "apply_patch"}]
)
response = model_with_tools.invoke("Create hello.txt")
response.content  # 现在包含 apply_patch_call 条目

无需自定义 tool 类，无需手动解析 diff。框架接住，开发者只管使用。

well-known 机制与消息透传

apply_patch 的接入逻辑并不复杂，但涉及 LangChain 两条关键代码路径：

工具白名单机制。 LangChain 维护了一份 _WellKnownOpenAITools 元组，列出不需要框架解释、直接透传的 OpenAI 内置工具类型。当用户传入的工具字典 type 命中白名单时，convert_to_openai_tool 直接原样返回，不做 schema 转换。该元组此前已覆盖 file_search、 web_search_preview、computer_use_preview 等工具， apply_patch 加入后，列表扩展至 12 项。用户无需关心内部细节，照常使用 bind_tools 即可。

Responses API 转换层。 LangChain 的 _construct_lc_result_from_responses_api 函数负责将 OpenAI Responses API 的原始响应映射为 LangChain 的 AIMessage。它对 output.type 做多路分支判断：已知类型如 message、function_call 有专门处理逻辑，未知类型原本被静默忽略。apply_patch_call 的加入本质就是在这一多路分支中新增一条 case，直接将原始 dict 追加到 content_blocks，不做二次转换。

流式处理的 _convert_responses_chunk_to_generation_chunk 函数同理，在 response.output_item.done 事件中新增对 apply_patch_call 的识别。

两条路径都遵循「透传不解释」的设计原则——LangChain 不需要理解 diff 的格式或操作语义，只需确保结构化信息无损通过即可。这套机制也为后续 OpenAI 新增的其它 built-in 工具提供了可复用的接入模式。

小结：Agent 链路上的数据完整性

从更广的视角看，本次更新虽然只是一个工具类型的适配，却切中了 Agent 编程场景的核心痛点：工具调用链中的数据完整性。当模型有能力生成结构化补丁时，框架若在中间层丢弃这些信息，Agent 的上层逻辑就会做出错误决策。 LangChain 的补位让 apply_patch 从「模型能输出」到「Agent 能收到」的链路真正闭合。

对于构建代码编辑 Agent 的团队，这意味着无需自行解析 API 原始响应、无需写胶水代码来重建丢失的消息字段。一个 bind_tools 加上升级依赖，即可获得完整的 apply_patch 体验。