选 Agent 框架，先看客户卡在哪，别看热度

Anthropic 在 2024 年 12 月 19 日发布的 Agent 构建指南中，给出了一条与许多开发者本能做法相反的建议：从直接调用 LLM API 开始。理由很实际：很多模式只需几行代码。

与此同时，每个框架都有自己的承诺。Haystack 自称是用于构建生产级 Agent 的开源框架。LangChain 承诺能用任意模型提供商快速跑起 Agent。LlamaIndex 则邀请你基于组织自己的数据构建 Agent。

对前线部署工程师（FDE）来说，选框架不是个人口味问题。你写的代码在你离场后仍留在客户的代码库里，凌晨两点排查问题的是客户自己的团队。

因此，正确的问题不是“哪个框架最好”，而是“客户卡在哪里，这一部分该不该交给别人的库？”

每个工具解决的是不同环节

仔细读各家的自我介绍，就会发现它们并不在同一个点上竞争。LangChain 主打快速起步、兼容任意模型提供商。需要具备一定确定性的生产级 Agent 时，它会把你引向另一款产品 LangGraph，后者提供底层控制。

LangChain 还有 LangSmith，一个用于观测、评测和部署 Agent 的平台。这个细节对 FDE 很重要：这个生态中有一部分是客户可能需要付费的产品，而不只是开源库。推荐 LangChain 时，要讲清楚客户用的是哪些部分，哪些部分日后可能产生费用。

LlamaIndex 从数据出发：它是一个 Python 工具包，用于构建运行在客户自有数据上的 LLM Agent。它的 workflow 是事件驱动的多步骤流程，组合了 Agent、数据连接器和工具。检索增强生成（RAG）只是其中一个工具，而不是整个系统。

Haystack 不把逻辑藏在自动化的层后面。根据 deepset 的文档，管道是一张由你亲手连接的图，因此每次运行方式都相同。它强调对检索、路由、记忆和生成的显式控制，并承诺更换模型或基础设施时无需重写系统。

RAGFlow 则是另一类东西：不是用来拼装代码的库，而是现成的 RAG 引擎。它的强项是深度理解格式复杂的非结构化文档。它还能让用户直观看到文档如何切块，方便人工介入。

下表把各个工具对应到客户现场的常见情形：

工具	擅长	适合客户需要	引入前要问的问题
LangChain + LangGraph	快速起步，兼容多家提供商；LangGraph 用于需要确定性的生产环境	先做快速演示争取决策者，再转向可控流程	客户会用 LangSmith 吗，谁来付费？
LlamaIndex	基于私有数据的 Agent、事件驱动的 workflow、大量数据连接器	数据分散在多个来源	哪些连接器真正需要，哪些暂时用不上？
Haystack	开发者亲手连接的管道、运行结果一致、可替换模型和基础设施	可审计、结果可复现、担心被锁定	客户团队有人手维护这张图吗？
RAGFlow	现成引擎，理解复杂文档，切块可查看、可编辑	PDF 档案杂乱，需要业务人员检查检索质量	能否接受单独运行一套系统，而不是一个库？
直接调用 API	中间层最少，提示词完全可见	简单流程、快速调试	你在重写的哪些部分，框架其实已经解决得很好？

客户卡在哪里？

看一个假设案例：一家物流公司想要一个内部 Agent，回答有关运输合同的问题。数据是几千份含表格的扫描 PDF，多年来按不同模板制作。你有两周时间。

第一周，你直接调用 API，把文档切成固定长度的块，并在每次请求前打印完整提示词。用户问海防—河内线路的仓储费，模型答错了。打印出的提示词（数字仅为示意，原文为越南语）如下：

Context:
[Chunk 15] Hai Phong – Ha Noi | 4.200.000 | 350.000
[Chunk 31] Storage fees are charged monthly, payable at the end of the period...
Question: What is the storage fee for the Hai Phong – Ha Noi route?

大意是：“上下文：[第 15 块] 海防—河内 | 4,200,000 | 350,000。[第 31 块] 仓储费按月收取，期末支付……问题：海防—河内线路的仓储费是多少？”

问题一眼就能看出来。表头“线路 | 运费 | 仓储费”落在了第 14 块，而这一块没有被检索到，于是模型看到两个没有列名的数字，选了第一个。问题出在文档读取和切块，而不在 Agent 编排。

这时就该引入一个擅长文档理解的工具，比如 RAGFlow。借助它的切块视图，运营侧的同事能看到费用表和表头被拆开了，并把整张表修正到同一个块里。再次打印提示词，上下文已带上列名，模型选出了正确的数字 350,000。

客户现场第一天的教训：讨论框架之前，先打印提示词，问一句：检索到的块所含信息，是否足以让一个人类读者答对？

其他情形会指向其他工具。如果文档很干净，但分散在 SharePoint、数据库和邮件里，LlamaIndex 的数据层能帮你省力。

假如客户是一家接受审计的企业，要求每个回答都可复现，那么 Haystack 亲手连接、每次运行方式都相同的图，在合规部门面前更容易站得住。

如果客户老板只需要三天内看到演示来批预算，用 LangChain 快速起步是合理的，前提是你事先说明，生产版本需要 LangGraph 或其他方案。

你会离场，抽象层却留给了客户

Anthropic 指出了最大的风险：框架常常增加抽象层，掩盖底层真实的提示词，使调试更难。对做内部产品的开发者来说，这只是小麻烦；对 FDE 来说，这是留给客户团队的债。

Anthropic 的第二条建议更直接：如果使用框架，就要理解底层代码。它指出，对框架内部行为的错误假设是客户出错的常见原因。换句话说，故障往往不出在模型上，而是用户以为框架在做一件事，实际上它在做另一件事。

所以，每个框架在交付前都要通过一项检验。你能否像上面运输合同的例子那样，打印出发给模型的确切最终提示词？客户团队能否把一个错误回答追溯到导致它的具体块和路由步骤？

如果答案是否定的，那么框架为你省下的时间，就是让客户日后买单。

自己写不等于全部重写

把 Anthropic 的建议理解成“永远不用框架”是误读。它说的是很多模式只需几行代码，而不是所有模式。工具调用循环、摘要步骤或简单路由，几十行代码就能写完，客户团队的任何人都看得懂。

但自己为含表格的 PDF 写解析器，或者为十个数据源写连接器，等于重做 RAGFlow 或 LlamaIndex 已大量投入的工作。Haystack“换模型无需重写”的承诺，也只有在客户确实可能换模型时才有价值。

如果不会换，自己写一层薄适配层就足以降低锁定风险。

因此，客户现场比较稳妥的做法通常是混合方案。编排保持手写，并且足够薄，能打印每一条提示词。只在一个承担重活的层引入框架，让它干真正的工作。交付时附上一页说明，解释为什么这一层用库、其他层不用。

该练什么

这里真正有价值的技能，不是背下四个工具的 API，而是能在客户的工程师面前讲清楚：为什么这一环节选这个工具。练习方法是用两种方式解决同一个问题，一种直接调用 API，一种使用框架，然后记下框架在哪里帮了忙、在哪里掩盖了提示词。

岗位描述里的框架名称也是线索：提到 LangGraph 和可观测性的岗位，多半在找能把 Agent 可控地推向生产环境的人。描述自己的经验时，要让雇主看到你会权衡为什么用或不用某个工具，而不是罗列库的名字。

框架会改名、合并产品、调整定位。先直接调用 API、找准客户卡在哪里、再选工具，这个习惯会比任何一个框架都活得久。