什么是 LangChain Agent
- 标签：大模型、AI、Agent、LangChain
🏛 业务架构师
LangChain Agent 是让大模型从"回答者"升级为"执行者"的机制：模型拿到任务后自主规划步骤，决定调用哪些工具（搜索、数据库查询、API）、观察执行结果、循环往复直到完成任务，AgentExecutor 就是驱动这个循环的引擎。
和普通调用的本质区别在业务上体现为：普通调用（Chain）是"我问你答"，适合确定性流程——用户问知识库，检索后回答；Agent 是"你替我办事"，适合开放性任务——"帮我查一下这个客户的 overdue 订单并发一封催款邮件草稿"，需要模型自己拆步骤、选工具、处理异常。
典型应用场景：内部运营助手（跨系统查数、生成报表）、智能客服的工单自动处理、数据分析 Agent（自然语言转查询再执行）。这些场景的共同点是步骤不可预先穷举，硬编码流程会碎成一地 if-else，交给模型自主编排反而更省。
我的业务提醒：Agent 的自主性是把双刃剑——可靠性和成本都不可控。落地原则是"能流程化就流程化（用 Chain/Graph），确需自主决策才用 Agent"，并且给 Agent 的工具清单做减法：工具越多，选错工具的概率越高。先在低风险内部场景验证，再考虑对外。
🏗 系统架构师
LangChain Agent = LLM 作为决策核心 + 工具集 + 执行循环：模型根据任务动态决定调用哪个工具、传什么参数，工具结果回填后继续推理，循环直到产出最终答案。Chain 是静态编排（人写死流程），Agent 是动态编排（模型选路径）。
架构三要素：
- 工具定义：name + description + args_schema（JSON Schema），描述质量直接决定选择准确率——工具描述就是给模型的 API 文档；
- 决策循环：观察（工具结果）→ 思考 → 行动 → 再观察，即 ReAct 范式；
- 终止条件：模型输出无工具调用的最终回答，或步数/token/时长熔断。
和 Chain 的选型逻辑（这是架构师视角的关键）：确定性优先——能用 Chain（固定流程）就不要用 Agent。Agent 灵活性换来了三样代价：延迟乘数（每步一次 LLM 调用，N 步任务延迟 ×N）、成本不可预测（一个任务烧 10 万 token 很常见）、行为不确定性（同一输入不同路径）。所以我的原则：流程已知用 Chain/Workflow，路径真的需要模型判断（先查哪个数据源、是否需要补充检索）才用 Agent，且必须加循环上限和预算熔断。
💻 全栈开发专家
LangChain Agent 就是「LLM 当大脑做决策 + 框架执行工具 + 结果反馈循环」的封装。模型根据问题和工具列表，自主决定调哪个工具、传什么参数，拿到观察结果后继续推理，直到给出最终答案。
最小实现（新版 API）：
python
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.tools import tool
@tool
def query_order(order_id: str) -> str:
"""根据订单号查询订单状态"""
return db.lookup(order_id)
agent = create_tool_calling_agent(llm, [query_order], prompt)
executor = AgentExecutor(agent=agent, tools=[query_order],
max_iterations=8, handle_parsing_errors=True)
executor.invoke({"input": "订单 A10086 发货了吗"})适合 Agent 的场景：问题无法预知要几步、要动态组合工具（查订单→查物流→算时效）。不适合的：固定流程（一次检索一次生成）直接用 Chain，上 Agent 纯属浪费 token 和延迟。
生产参数心得：max_iterations 必设（防死循环）；工具的 docstring 是模型选工具的唯一依据，要写清楚「什么时候用、参数什么含义」——工具描述没写好是 Agent 效果差的第一原因。