Agent 开发框架
认识主流框架，再决定要不要用
最早最全的 Agent 工具链——封装多、学习曲线陡、风评两极。
LangChain 团队推的图式 Agent 框架——更适合复杂多 Agent 编排。
数据接入和 RAG 见长，更聚焦"喂给模型的数据"这一侧。
微软推出的多 Agent 对话框架。
上手轻快的多 Agent 协作框架，角色 + 任务的心智模型清晰。
模型厂商自己提供的 Agent 抽象；OpenAI 新项目应优先用 Responses API。
把 Prompt 当代码来"编译"——用数据自动优化提示词。
LangChain 更像一组 LLM 应用开发组件,LangGraph 更偏向用图来编排有状态、多步骤、可回退的 Agent 流程。简单链路或工具封装用 LangChain 就够,复杂 Agent 循环、多角色协作、状态机和人工介入更适合 LangGraph。
- +LangGraph 的优势是显式状态和节点边关系,比隐式循环更容易调试
- +复杂度不高时不要为了框架而框架,原生代码更直观
- +选框架要看团队维护成本、可观测性、生态和部署约束
我会先看任务复杂度、团队熟悉度、生态集成和上线后的可维护性。框架能省掉工具封装、链路编排和观测接入成本,但也可能带来抽象层、版本升级和调试困难。
- +Demo 阶段可以快速用框架验证,生产阶段要评估是否需要剥离关键链路
- +高可控业务更适合少抽象、显式代码;探索型 Agent 更能受益于框架
- +不要只比较 star 数,要看是否解决当前项目的核心痛点
LlamaIndex 更偏向数据连接、索引构建和 RAG 工作流,适合围绕文档、知识库、数据库做问答和检索增强。它的强项不是通用 Agent 编排,而是把外部数据更好地接进模型上下文。
- +如果项目核心是知识库问答,LlamaIndex 的数据连接器和索引抽象很有价值
- +复杂业务流程仍可能需要自己写编排层或结合其他框架
- +评估时要看文档解析质量、权限过滤、增量更新和可观测性
它们适合把任务拆成多个角色协作,例如研究、规划、执行、审查分工。真正有价值的场景是角色能力差异明显、需要互相校验或并行探索,而不是把一个任务硬拆成很多聊天机器人。
- +多 Agent 会放大 token 成本和不确定性,需要明确停止条件
- +角色之间传递的信息要结构化,否则容易重复劳动和误解
- +生产系统常把关键路径收敛成确定流程,只在开放环节用多 Agent
官方托管方案通常把线程、工具、文件、运行状态等能力打包好,上手快、集成稳。自己搭框架更灵活,能深度控制状态、权限、成本和观测,但需要承担更多工程复杂度。
- +OpenAI Responses API、Anthropic SDK 等都能做工具调用,但接口和控制方式不同
- +Anthropic 侧工具选择要按 `tool_choice` 等机制设计,不要套用别家字段
- +如果有严格合规、私有部署或特殊状态机需求,自建通常更可控
DSPy 关注的是把 Prompt 和调用流程变成可优化的程序,通过数据和指标自动寻找更好的提示策略。手写 Prompt 靠经验迭代,DSPy 更像把提示词工程拉向可评估、可搜索、可复现实验。
- +DSPy 适合有训练/验证样本和明确指标的任务,不是所有聊天场景都适合
- +它能减少人工调 prompt 的随机性,但需要建设数据集和评估流程
- +生产使用仍要关注可解释性、版本管理和成本