在搭建企业级 AI 助手时，开发者常会面对一个看似简单的问题：LangChain、LangGraph、LlamaIndex 都能参与完成任务，到底该选哪一个？掘金近日发布的一篇技术文章以「公司制度查询助手」为例指出，最终回答只是系统终点，真正需要拆开的是模型如何调用工具、任务如何保存与推进、资料如何变成可用上下文。文章强调，框架选型不是比较谁更能回答，而是先识别工程缺口，再选择能补齐缺口且维护成本可接受的组件。
该案例设定为：用户询问「这笔出差交通费能不能报销？」，助手需要查询公司制度，返回相关条款及文档出处。初始范围只包含查询，不提交报销申请。成功标准也不是生成一段文字，而是找到适用条款、回答没有曲解条款，并且出处能够对应原文。文章指出，如果现有系统已经可以按固定顺序完成「检索制度 → 交给模型 → 生成带来源的回答」，就没有必要为了使用 Agent 名称，让模型重新决定每一步。
先拆三类职责：调用组织、状态控制、数据处理
文章将 Agent 系统拆成三类职责。第一类是「调用组织」。模型输出一段「调用查询工具」的描述，并不等于查询已经发生，应用必须校验并执行函数，再将结果交回模型。第二类是「状态与执行控制」。当工具结果为空时，系统要决定重查、回答资料不足，还是继续提交，这些不能依靠最终回答文本可靠记录「已重查几次」「是否批准」。第三类是「数据处理与检索」。即使函数调用正常，也可能取回无关条款，文档解析、切分、来源保存、检索与可选重排，决定最终送给模型的资料质量。
文章强调，这三个层次是分析维度，而不是三个产品互斥的功能清单。框架只是复用这些工作的实现集合。对于工程团队而言，更重要的是判断当前任务缺少哪一层能力，而不是先给框架贴上固定标签。
LangChain、LangGraph、LlamaIndex 的边界并非互斥
在框架关系上，文章指出，当前 Python 版 LangChain Agent 建立在 LangGraph 运行基础上：前者提供已组织的模型和工具交互方式，后者提供状态和执行调度。因此，不能简单判断「LangChain 不能做暂停恢复」，也不能把所有 LangChain 组件都等同为一个 Agent。开发者可以先检查现成 Agent 的扩展点能否表达需求；确实需要更细的节点、状态和路由控制时，再考虑直接定制 LangGraph，但这也意味着要自行维护更多流程代码。LangGraph 也可独立使用，并不要求同时采用 LangChain。
对于 LlamaIndex，文章认为其提供资料处理、索引、查询等组件，也具备 Agent 和工作流能力；同时，LangChain 同样能组织检索。选型依据应是具体资料上的效果、开发与排查收益，而不是「只能做某事」的刻板印象。
重查、审批与幂等：真正的难点在流程控制
文章进一步加入独立需求：助手可以代提交申请，但必须先获批准；首次检索之外，最多再查两次。在这一规则下，系统需要判断依据是否充分：充分则等待人工确认；不足则在允许次数内重查；超过限制则停止并提示资料不足。文章指出，等待确认不代表持续忙循环，实际实现可以暂停执行并等待外部事件；拒绝与尚未响应也必须区分。节点读取当前状态，完成工作后更新相关字段，路由再根据新状态判断下一步。仅在提示词里写「不要超过次数」，无法替代程序条件；模型建议提交，也不能替代批准结果。
文章还提醒，重试与幂等是不同层级的问题。若外层最多尝试 2 次，内层每次最多尝试 2 次，在所有尝试都触发的假设下，底层调用最多会变成 2 × 2 = 4 次，而不是 2 次。这里的「尝试」包含首次调用，不能把「两次重试」与「两次尝试」混用。对于业务提交场景，响应丢失时调用方只能知道「超时、结果未知」，不能直接认定业务失败。若重试生成新的业务操作号，服务端可能将其当成第二笔申请；复用同一操作号，并由接收方可靠识别同一操作、返回原结果，才能避免重复产生业务结果。仅在请求里加一个 UUID，并不构成完整保障。
选型建议：从任务出发，而不是从框架名词出发
文章给出三个判断示例：如果助手只按固定顺序查制度并给出处，不必须让模型决定下一步；如果系统恢复到等待确认状态，但用户从未批准，不能为了避免卡住而自动提交；如果换用 LlamaIndex 后仍引用错条款，也不应立即换模型，而应先看中间结果——解析文本已错就修解析，相关片段未入候选就查切分和检索，正确条款已交给模型但解释错误，才进一步检查生成环节。
作者总结的选型路径是：从具体任务出发，拆分调用、控制、数据职责，检查现有能力缺口，选择最小增量方案，再用同样输入验证结果与异常，最后计入维护与运行成本。文章同时说明，该案例是教学模型，不是框架性能测试；真正比较框架还需要固定模型、资料、工具和任务，分别检查答案、引用、失败定位、等待确认时重启后的状态，以及延迟、调用量和维护成本。
对于 AI 应用开发者而言，这类拆解的价值在于把「Agent」从概念拉回工程问题：框架不是越多越好，功能也不是越全越好。能否把结果不足表达为可检查状态、能否把审批与执行分离、能否让检查点与业务幂等分别保护执行进度和业务结果，才是决定系统可靠性的关键。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-agent-kuang-jia-xuan-xing-bu-zhi-kan-hui-da-zhi-du-cha
