LangChain create_agent：官方 Agent 框架是什么、为什么值得用

上一篇文章聊了 LangGraph—— 那个把 Agent 执行流程画成一张图的低层编排框架。这篇接着往下走一层， 讲 LangChain 官方对"Agent 到底是什么、怎么写"给出的最直白的答案：LangChain 的 create_agent。 如果说 LangGraph 是"执行引擎"，那 create_agent 就是站在它上面的"最简 Agent 入口"：一段十行不到的代码，就能得到一个能调工具、带系统提示词、 并且可以随时换成任意大模型的 Agent。

一、它是什么：Agent = Model + Harness

官方对 create_agent 的定义很克制："一个最小、高度可配置的 agent harness"。 并且给了一个至今仍是最清晰的 Agent 公式：

Agent = Model + Harness

模型就是那个大模型本体；而 harness（运行环境） 包着模型循环转—— 提示词、工具、以及一切塑造 Agent 行为的东西。官方原话：harness 是 "the prompt, the tools, and any middleware that shapes behavior"。 换句话说，写 Agent 这件事，重点从来不在"选哪个模型"，而在"给模型配一个怎样的 harness"。

最直接的体验方式，是看官方最小示例——一个能查天气的 Agent，完整代码：

# pip install -qU langchain "langchain[openai]"
from langchain.agents import create_agent

def get_weather(city: str) -> str:
    """Get weather for a given city."""
    return f"It's always sunny in {city}!"

agent = create_agent(
    model="openai:gpt-5.5",
    tools=[get_weather],
    system_prompt="You are a helpful assistant",
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "What's the weather in San Francisco?"}]}
)
print(result["messages"][-1].content_blocks)

值得注意三个细节：

• 工具就是一个普通 Python 函数——带个 docstring 就行，不用继承任何基类； Agent 需要时会自动调用它，不需要你手写"该不该调、怎么调"的逻辑；
• 系统提示词是显式参数——system_prompt=，一眼可见；
• 输入输出都是消息——进的是 {"messages": [...]}， 出的是带 content_blocks 的消息对象，保持了聊天接口的延续性。

二、为什么需要它：一个接口，换遍所有模型

create_agent 背后最有价值的，是 LangChain 的标准模型接口：所有 provider 的聊天模型和 embedding 共用同一套接口，换模型只改一行字符串。官方文档给了一张 provider 表，同一个 Agent，你只需要改 model= 那一个参数：

注意模型字符串的格式是 provider:model，而 Claude 的claude-sonnet-4-6 前面没有前缀——官方设计成"无前缀时按默认 provider 解析"。 个别 provider 有特殊参数，比如 Azure 要用 init_chat_model 加部署名， Bedrock 的跨区域推理配置可以选 global. 前缀做全球路由—— 但整体上，"换模型只改一行"不是口号，是真做到了。

三、它怎么工作：从最小到可扩展的"增量配置"

create_agent 的设计哲学是从最小开始，按需加能力。 官方明确说：你可以通过 middleware（中间件） 增量地加功能——护栏（guardrails）、重试（retries）、路由（routing）、自定义工具策略，都是中间件。

这意味着你的 Agent 可以这样长大：

• 最小形态：模型 + 系统提示词 + 几个工具，十行代码就能跑；
• 加护栏：中间件约束输出格式、拦住危险请求；
• 加重试：模型超时、tool 调用失败时自动重试；
• 加路由：按意图把请求分发到不同的子流程或模型；
• 加自定义工具策略：控制 Agent 何时、如何、以什么权限调用工具。

更关键的是，LangChain 的 Agent 是构建在 LangGraph 之上的—— 所以你写的是"高层、简单"的 create_agent，继承的却是低层的硬实力：durable execution（持久执行）、human-in-the-loop（人工介入）、persistence（持久化）全都自动可用。当简单形态不够、需要手绘控制流时，你再下潜到 LangGraph 那一层—— 这就是上一篇讲的"从高层入口到低层引擎"的完整路径。

四、它在生态里的位置：Deep Agents / LangChain / LangGraph 三层

官方文档把整套 LangChain 生态画成三层，这次看更清楚了：

和上一篇合起来看，一条完整的技术栈是这样的：想开箱即用 → Deep Agents；想掌控 agent 行为又不折腾 → create_agent； 想手绘控制流、持久化、人机协同 → LangGraph。再往上，LangSmith 负责可观测性——开 LANGSMITH_TRACING=true 加个 API key， 就能 trace 每次请求、调试 Agent 行为、评估输出。

我的收获

1. "Agent = Model + Harness"是最值得记住的一句话——它把 Agent 从玄学拉回工程：模型可以随时换，你真正要打磨的是 harness（提示词、工具、中间件）。
2. "换模型只改一行"的价值被低估了——不是省那几行代码，而是它让你敢做模型对比：同一套业务逻辑，Claude / GPT / 本地模型轮着测，成本极低。这是把"选模型"变成"调参"的能力。
3. "工具就是普通函数"是降低心智负担的关键设计——不用学框架的类体系，业务代码保持干净，Agent 自动决定调用时机。门槛低到难以置信。
4. 中间件是 Agent 长大的方式——从最小到生产，靠的不是重写，而是增量地挂护栏、重试、路由。这和我们前几篇聊的"给 Agent 配工作环境"是同一个思路，只是这次是官方给的原生机制。

想深入了解，官方文档在docs.langchain.com/oss/python/langchain/overview， 和上一篇 LangGraph 的文档配着读，能把 LangChain 这套"高层入口 + 低层引擎"的架构看得更完整。