“ 从“会聊天”到“会思考”：我用 LangChain 1.0 + Qwen 做了一个旅游 Agent，一个真正能“思考”的旅游规划 Agent。
在这个过程中，我顺手把“深度思考（reasoning）”这一套，从 模型 → API → LangChain 1.0 → 中间件，走了一遍闭环，也踩了不少坑。这篇文章就借这个项目，聊聊 Reasoning 到底怎么开、怎么控、怎么落地。”
关注微信公众号及时获取更多技术资讯
往期内容链接:
LoRA 微调实战：手把手教你打造专属领域 AI（附代码)
MCP应用开发实战：把大模型接到现实世界" data-itemshowtype="0" linktype="text" data-linktype="2">MCP应用开发实战：把大模型接到现实世界
......
本期代码运行实例详见github：https://github.com/SWUSTcyt/langchain-travel-agent.git
01 为什么要关心 LangChain 1.0？
在 0.x 时代，我们做 Agent 差不多是这么个流程：
能跑，但有几个老问题：
Prompt、裁剪、Guardrails 分散：逻辑散落在各种链和回调里，难维护；
想要“先自评再重写”“先检索再回答”，得自己手搓一堆链；
工程化之后，逻辑越来越多，全是 if-else 拼命长。
LangChain 1.0 做了一件很关键的小事：
把这些“前后处理、反思、限流、审计”的能力，系统化收拢到了 Middleware（中间件） 里。
简单一句话：
Agent = 一条生产线，Middleware = 插在生产线各个路口的“小工位”。
有了它，我们可以更优雅地回答这三个问题：
这个模型什么时候开始深度思考？
它的思考预算谁来控制？
出来的结果谁来质检和纠偏？
02 模型层：先把“深度思考”开起来
在这个 Demo 里我用的是 Qwen-Turbo，它本身支持“深度思考 + 流式输出”。模型初始化放在 agent.py 中，核心配置大概长这样：
from langchain_community.chat_models.tongyi import ChatTongyifrom tools import tools
qwen = ChatTongyi( dashscope_api_key=DASHSCOPE_API_KEY, model="qwen-turbo-latest", streaming=True, model_kwargs={ "enable_thinking": True, "incremental_output": True, "temperature": 0.7, "top_p": 0.8, "max_output_tokens": 1500, },)
qwen = qwen.bind_tools(tools)
这一层你可以理解为：
“告诉模型：你可以多想一会儿，但最长只能说这么多。”
剩下的就交给 LangChain 1.0 的 Middleware 去“管住它”。
03 把 Agent 想成一条生产线：Middleware 就是闸口
官方文档会画一张循环图：
模型调用 →（可能）工具调用 → 再次模型调用 → …… → 结束
LangChain 1.0 提供了几个关键钩子（hook）：
before_model：模型调用之前，适合改 Prompt、抽取结构化信息、打系统提示；
wrap_model_call：像给 model.invoke() 加一层代理，适合控参数、做“自评→重写”等多段推理；
wrap_tool_call：在工具真正被调用前拦一下，适合修参数、加权限、做预算限制；
after_model：模型调用之后，适合做结果质检、串城检查、命中关键词再触发纠偏；
after_agent：整轮 Agent 结束后的收尾工作。
在我的旅游 Agent 里，我只重点做了三件事：
在 before_model 里：自动解析城市 + 注入强约束；
在 wrap_model_call 里：控制 Reasoning 的“成本”；
在 wrap_tool_call + after_model 里：强制工具对齐城市，并在最后做一次“串城质检”。
下面就用几个关键中间件快速过一遍。
04 三段关键中间件：一张“深思链路骨架”
4.1 城市解析 & 系统提示：before_model
用户说的每一句话里，其实都隐藏着一些重要变量，比如“城市”。
在旅游场景下，城市就是一切的“坐标系”。
所以我在 middleware.py 里写了一个 pin_cities_and_adcodes：
核心逻辑大致是这样的（只保留关键部分）：
from langchain.agents.middleware import before_modelfrom langchain_core.messages import SystemMessage, HumanMessagefrom .utils import extract_cities, msg_text
@before_modeldef pin_cities_and_adcodes(state, runtime): messages = state.get("messages", []) human_msgs = [m for m in messages if isinstance(m, HumanMessage)] query = msg_text(human_msgs[-1]) if human_msgs else ""
cities = extract_cities(query) runtime.state["target_cities"] = set(cities) runtime.state["target_cities_source_text"] = query
if cities: city_tips = ( f"\n【强制约束】本轮用户指定城市：{', '.join(cities)}。" "仅在这些城市范围内规划；所有 MCP 工具调用必须携带匹配的 city/cityd。" ) else: city_tips = "\n【强制约束】请从用户问题中判断目标城市；禁止跨城或引入未出现的城市。"
sys_msg = SystemMessage( content=( "你是旅行规划助手。需要本地信息时优先使用 MCP(amap-maps) 的工具：" "searchPOI / getRoute / getWeather。风格：\"轻松不赶\"。" + city_tips ) )
new_messages = [sys_msg] + [ m for m in messages if not isinstance(m, SystemMessage) ] return {"messages": new_messages}
这一段做的是语义层的预处理：
“先帮模型把城市这个‘关键条件’想清楚，再让它进入 reasoning 模式。”
4.2 成本护栏：wrap_model_call
第二个关键点，是控制“模型思考的成本”。
在项目里，我统一用一个 cost_guard 来兜底：
核心代码简化后大概是这样：
from langchain.agents.middleware import wrap_model_call
@wrap_model_calldef cost_guard(req, handler): ...
guarded = req.override( model_settings={ "max_output_tokens": 1200, "incremental_output": True, "enable_thinking": True, } ) return handler(guarded)
这就相当于在 API 层把：
reasoning 开关、
输出 token 上限，
都集中放到 一个地方统一管理。以后要调参，只改这个中间件就行。
4.3 工具护栏：预算 + 城市对齐 + 串城质检
第三块，是整个项目比较“工程化”的部分：
我们希望：工具调用既要节制，又要绝对不“串城市”。
我这里拆成三个小环节：
4.3.1 工具预算（轮次）计数：track_tool_budget
from langchain.agents.middleware import wrap_tool_callfrom langchain_core.messages import ToolMessage
@wrap_tool_calldef track_tool_budget(req, handler): MAX_TOOL_ROUNDS = 2 ... if current_round > MAX_TOOL_ROUNDS: return ToolMessage( tool_call_id=call_id or "call_budget_exceeded", content='{"error":"预算已耗尽","message":"工具调用已达到上限，请直接给出最终答案。"}', name="budget_guard", ) return handler(req)
4.3.2 城市对齐：enforce_city_on_tools
@wrap_tool_calldef enforce_city_on_tools(req, handler): if not tool_name_contains_map_or_weather(req): return handler(req)
cities = set(req.runtime.state.get("target_cities") or []) if not cities: return handler(req) pinned_city = next(iter(cities))
params = dict(getattr(req, "tool_input", {}) or {}) params["city"] = pinned_city params["cityd"] = pinned_city if "adcode" in params: params["adcode"] = ""
return handler(req.override(tool_input=params))
4.3.3 串城质检：strip_unasked_cities（after_model）
最后一道小保险放在 after_model：
这样，整个“城市约束链路”就闭合了：
before_model 抽城市 →
wrap_tool_call 强制对齐工具参数 →
after_model 最终文本再做一次检查。
05 实际体验：一个“会思考”的旅游助手
从用户视角看，这个小项目有两层体验：
1. 正常用户模式
2. 开发者模式
06 Reasoning 的三个层次：不只是“让模型多想一会儿”
用这个项目小结一下，我现在会把 Reasoning 分成三个层次来看：
模型层 Reasoning
选支持深度思考的模型（例如 Qwen 的 enable_thinking）；
在模型参数里打开“思考模式”，给出一个大致的 token 预算。
API / Middleware 层 Reasoning
用 cost_guard 统一控制输出长度、thinking 开关；
用 before_model 把城市、约束条件、行为准则提前抽出来；
用 wrap_tool_call 管住工具预算 & 参数合理性；
用 after_model 做结果质检、自动修正与提示。
结构层 Reasoning（工程级）
如果以后需要走到更重的业务，比如电价预测报告、合规文书生成、金融风控决策，可以再叠加 LangGraph + interrupt/checkpoint 做“长事务 + 人审”，但底层这条 Middleware 生产线不需要推翻重来。
07 结语：你可以直接复用哪些东西？
这篇文章本质上只是用一个旅游 Agent，把这几个思路串了一遍：
如果你也在做 Agent / RAG / 报告生成类应用，可以直接照抄下面这几个套路：
一个 before_model，负责：抽取关键变量 + 重写 System Prompt；
一个 wrap_model_call，负责：统一模型参数 & 成本护栏；
一到两个 wrap_tool_call，负责：工具预算、参数对齐、权限检查；
一个 after_model，负责：结果质检 + 轻量纠偏。
剩下的，就抽时间跑一跑仓库里的 Demo，把旅游场景换成你自己的业务即可。
粤ICP备14082021号
免费POC，
零成本试错
