什么是 LangChain 中的 Agent?它和 Chain 有什么区别?
- 标签:LangChain、Agent 智能体
🏛 业务架构师
LangChain 中 Agent 与 Chain 的区别,我用"谁决定流程"一句话概括:Chain 的流程由开发者写死,Agent 的流程由模型临场决定。
- Chain:预定义的组件序列(检索→提示→模型→解析),数据单向流过,每步执行什么在编码时就确定。特点:可预测(同样输入走同样路径)、成本与时延可控、易于调试。业务定位:确定性任务流水线——RAG 问答、固定步骤的内容加工。
- Agent:模型拿到目标和工具清单,自主决定调用顺序、是否重试、何时结束(ReAct 循环,AgentExecutor 或 LangGraph 驱动)。特点:能处理不可预知路径的任务,但步数不定、成本不定、行为有方差。业务定位:开放式任务——数据分析(查什么表取决于上一步结果)、跨系统办事。
选型的业务判断(回答的加分部分):
- 流程可穷举、追求 SLA → Chain;路径依赖上下文、需要"见机行事" → Agent;
- 生产中最佳实践是混合:LangGraph 定义主干流程(可控可审计),特定节点内放 Agent 自主决策(灵活)——"框架管方向、模型管细节";
- 一个反直觉经验:多数团队高估了对 Agent 的需求——80% 的"看起来需要 Agent"的场景,Chain+条件分支就够了,先把流程确定性做满,剩余不确定性再交给模型。
一句话:Chain 是流水线上的机械臂,Agent 是拿到任务单的员工;企业架构里前者保交付,后者提上限。
🏗 系统架构师
LangChain 的 Agent = LLM 决策 + 工具集 + 执行循环;Chain = 开发者预定义的静态流水线。区别在控制流归属:
Agent(动态决策):
- 模型运行时决定调哪个工具、传什么参数、几步完成——ReAct 循环(推理→行动→观察→再推理);
- 适合:路径无法预知的任务("查这个客户的工单并给处理建议"——可能要查订单、查工单、查政策,顺序不定);
- 代价:延迟与成本方差大(每步一次 LLM 调用)、行为不确定性(需要熔断与重试治理)、可测试性弱。
Chain(静态编排):
- 开发者写死流程(检索→组装→生成→解析),LCEL 管道串联;
- 适合:流程已知的任务(RAG 问答、抽取、翻译摘要);
- 优点:延迟/成本可预估、易测试、易并行优化——工程美德全占。
我的决策规则(架构师纪律):能 Chain 不 Agent——确定性、可测性、成本可控性优先;只有"下一步做什么必须由模型根据中间结果判断"时才用 Agent,且必须配:步数上限、token 预算熔断、工具白名单、高危工具审批。
生产形态是混合体:外层 Chain 编排阶段(路由、检索、生成分层),局部环节(工具选择、异常分支)交给 Agent。1.x 后 Agent 执行收敛到 LangGraph(create_agent/react 图),Chain 用 LCEL——两者在图状态机里统一:Chain 是无环子图,Agent 是带循环的子图。
💻 全栈开发专家
LangChain 里的 Agent = LLM 动态决策 + 工具循环;Chain = 开发者预定义的固定流水线。
区别本质:控制流在谁手里。
- Chain:路径写死(检索→生成),确定执行、可预估成本延迟;
- Agent:模型看着工具列表和当前状态,自己决定下一步调什么、要不要继续——有循环、有不确定性。
适用场景:
- Chain:流程可预知。RAG 问答(固定两步)、摘要(map-reduce)、抽取翻译流水线——快、稳、便宜;
- Agent:步骤无法预知、需要动态组合工具。运维排障(先查日志还是先看监控看情况)、数据分析(模型自己决定先看 schema 再写 SQL)、多源信息汇总。
用 Chain 思路写 Agent 场景的失败样例:客服系统把「查订单→查物流→查政策」写死成 Chain,结果用户上来就问政策,Chain 还是先跑两个无用查询——换成 Agent(工具自选),省 60% token 且更快。
反过来用 Agent 干 Chain 的活的问题:简单 RAG 上 Agent,多一轮决策调用(贵+慢),还引入「选错工具」风险——大材小用。
现代实践(2026):界线在模糊化——LangGraph 里 Chain 和 Agent 都是图:固定边=Chain 行为,条件边+循环=Agent 行为,按节点粒度混搭。我的项目通常是混合体:主干 Chain 固定(可控),个别需要灵活性的节点嵌 Agent 循环(带步数预算)。选型口诀:路径能预写就用 Chain,需要模型看情况办事才上 Agent。