YGG臻星科技

AI 问答库

做 AI Agent 要不要用 LangChain 这类框架？

一句话回答

多数企业场景不需要。一个支持工具调用的模型 SDK 加几百行自己写的胶水代码，就能覆盖绝大部分「读输入 → 调工具 → 出结果」的需求，出错时调用栈是你自己的，好查。重框架的价值在多团队复用抽象和现成集成，代价是调试要穿过好几层封装，这部分成本常被低估。建议先用裸 SDK 跑通一个真实场景，出现明确重复再引框架。

关键要点

01Agent 的核心循环很短：给模型工具定义 → 模型返回要调哪个 → 你执行并把结果喂回去 → 循环直到结束。这段逻辑自己写通常不超过两百行。
02框架的成本主要在调试。业务出错时你要判断问题在 prompt、在工具定义、在框架的重试逻辑还是在模型本身，封装层数越多这个判断越慢。
03多 agent 编排在多数场景是浪费。把一个任务拆给五个角色互相对话，通常只是把一次可控的调用变成五次不可控的调用，先怀疑自己是不是把简单问题复杂化了。
04真正决定 Agent 好不好用的是工具设计，不是编排框架。工具边界清楚、参数明确、返回结构稳定，模型就少犯错；这件事没有框架能替你做。
05无论用不用框架，权限边界都要在工具定义层写死，不能靠 prompt 里写「请不要删数据」。

三种做法的取舍

把选择分成三档更容易判断：裸 SDK 加自己写的胶水代码；轻量框架（只提供工具调用循环、结构化输出、少量重试与追踪）；重框架（编排、记忆、检索、多 agent、可视化一整套）。绝大多数企业内部项目落在前两档。下表按「一个团队维护一到三个 Agent 应用」的常见规模对比，团队规模再大结论会向框架侧移动。

维度	裸 SDK + 胶水代码	轻框架	重框架（全家桶）
跑通第一个版本	快，核心循环几十行就能跑	快，样板代码更少	看着快，但要先学它的概念体系
调试与排障	最好，栈是你自己的，逐行可读	尚可，抽象层薄	最难，要穿过多层封装定位问题
依赖与升级风险	低，只依赖模型 SDK	中，跟随框架版本节奏	高，破坏性变更会波及整条链路
换模型 / 换厂商	需自己抽象一层，但完全可控	通常已抽象好，切换成本低	抽象好但可能被框架的假设限制
团队复用价值	低，各项目容易各写一套	中，约定统一但不重	高，多团队多应用时才体现
适合谁	单个明确场景、要求可控与可审计	多个相似场景、想少写样板	平台化建设、多团队共用一套基建

什么时候框架确实值回票价

有几种情况值得引入。一是你要维护的不是一个 Agent 而是十几个，且它们的工具注册、追踪日志、错误重试逻辑高度相似 —— 这时统一抽象能省下真实的重复劳动。二是你需要现成的生态集成，比如几十种数据源连接器、可观测性接入、评测工具链，自己写这些确实不划算。三是团队里有多个开发者并行做 Agent，需要一套共同语言避免各写各的。四是你要给非工程同事提供可视化编排界面，这类能力自建成本很高。反过来，如果你现在只有一个场景、一个开发者、五六个工具，那引框架带来的抽象收益还抵不过学习和调试成本。

多 agent 编排的常见误用

「让规划 Agent 拆任务，交给执行 Agent，再让评审 Agent 打分」这类架构在演示里很好看，在生产里往往是最难维护的部分。原因很直接：每多一个 agent，就多一次模型不确定性、多一份 token 开销、多一处失败可能，而收益经常只是把原本一个 prompt 能表达的逻辑分散到了几处。更实际的判断方法是问三个问题 —— 这些角色之间真的需要来回对话，还是顺序执行就够？拆开之后每一步是否都能单独评测？出错时你能不能一眼看出是哪一步错的？三个都答不上来，就先用单 agent 加清晰的工具集实现，把复杂度留到确有必要时再引入。确实需要多 agent 的场景通常有明确特征：子任务可以并行、彼此不共享状态、且各自有独立的成功判据。

适用边界

什么情况下本答案不成立

本文针对企业内部业务型 Agent（工单分诊、文档处理、跨系统查询）。研究型探索、开放式长链任务对编排能力的要求不同，结论不能直接套用。
「裸 SDK 更好调试」的前提是你的团队能读懂并维护这段循环代码。如果开发同事完全没有相关经验，一个约定良好的框架反而更稳。
框架生态变化很快，具体项目的成熟度、破坏性变更频率和文档质量都在变。选型前应看当前版本的实际情况，不要依据过往印象。
无论选哪种，都要先建评测集。没有一批带标准答案的真实任务，换框架、改 prompt、换模型之后你都无法判断是变好还是变坏。

同义问法

不用框架能做 Agent 吗
Agent 开发框架怎么选
LangChain 值得用吗
多智能体编排框架有必要吗
企业做智能体应该用什么技术栈