大模型应用从单轮对话走向复杂任务执行，企业级 Agent 需要怎样的技术底座？
大模型这两年进化太快，单轮问答、写文案、补代码……真正的坎出现在模型需要参与真实业务的时候。一份投标文件，从下载、解析、摘要提取，到数据填报、邮件发送，全链路要跑通。一个客服问题，得检索政策文档、核对客户画像、判断风险等级，再给出能直接执行的操作建议。这种任务链条长，分支多，上下文不能断，对底层架构的考验完全上了一个量级。
仅凭一个对话界面加一个向量库的简单组合，已经扛不住这种复杂场景了。企业级 Agent 需要的是多个子系统深度咬合，把大模型从对话工具推到业务执行体的位置。
企业级 Agent 的三大核心技术支柱
观察那些真正跑在生产环境里的 Agent 系统，你会发现它们几乎都依赖三种基础能力。
动态编排引擎，负责流程控制、状态流转和任务调度。一个任务走哪条路径，哪个节点调用模型，哪个节点直接走规则，什么时候并行，什么时候停下来等待人工确认，全部由它决策。编排能力缺席，Agent 就只能执行单步动作。
向量检索系统，负责精准语义匹配，给大模型提供准确的上下文片段。大模型自身的参数记忆天然模糊、有损耗，精确到某一份合同的具体条款、某一个版本的工艺参数，它做不到。检索系统在正确的时间把正确的信息送到模型面前，这是降低幻觉最基础的手段。
知识图谱系统，负责实体关系推理，专门补检索系统够不到的深层逻辑。很多业务问题不能靠一段相似文本来回答。“A 供应商是否具备承接 B 项目的资质”，相关证据可能散落在供应商证照、历史履约记录、项目准入条件等多个文档里，得顺着实体之间的关联一路推导下去才能得出结论。图谱把这个推理过程结构化了。
三者的协同方式，直接决定了 Agent 的能力上限。
核心引擎：基于 LangGraph 的动态 Agent 编排设计
编排引擎选什么？早期方案多数用静态 DAG 描述任务流程，简单场景能用。一旦需求里出现循环、条件分支、多轮交互和长期运行，维护成本就会快速膨胀。
LangGraph 在这个背景下进入了主流视野。它专门针对大模型应用设计，底层用有向图组织逻辑，原生支持复杂状态流转。最关键的差异在于对“记忆”和“断点续跑”的处理。一个文档处理和审核任务可能要跑好几个小时，中间经历文件解压、模型调用、等待外部 API、人工审批节点，任何一个环节中断，上下文都会丢失。有过这种经历的人都知道那种崩溃感——跑了半天的任务因为网络抖动白干了。LangGraph 的 Checkpointer 机制把每一步状态持久化下来，中断恢复后从断点继续，不用从头再来。
它对长任务中断恢复的处理尤其关键。开发团队可以用 JSON 或 YAML 文件定义工作流，每个节点代表一个功能单元，节点之间的连线表达路由规则。内置节点覆盖了起点、大模型调用、条件分支、REST API 交互、数据提取、技能调用、文本摘要等多种类型。if/else 分支让流程根据运行时结果动态选择路径，并行执行节点显著压缩复杂任务的端到端耗时，节点之间状态自动传递，前面的输出后面可以直接引用，胶水代码省掉一大半。
检索增强：向量检索与全文检索的混合架构
单纯依靠向量检索的 RAG 方案在严格匹配的场景容易出问题。型号代码、条款编号、日期范围，语义层面的接近没有意义，必须精准命中。反过来，纯关键词的全文检索又搞不定同义词、改写表达和跨文档的语义关联。
企业级场景需要两套索引混合调度。选 Milvus 当向量引擎有几个维度的考虑。它的索引算法可以灵活配置，IVF_FLAT 适合百万级以下的中等规模，追高召回；HNSW 在大规模数据集上提供更快的查询速度。这种弹性对企业从试点扩展到全量数据的过程很友好，不必在早期就背负沉重的性能调优压力。Milvus 的分布式架构还允许存储和计算独立扩展，匹配微服务体系中向量服务弹性伸缩的需求。
Embedding 模型的选择同样重要。BGE-M3 在 1024 维上取得了语义效果与推理效率的平衡，这个维度不会让索引膨胀到难以维护，又保留了足够的语义区分度，对多语言混合的业务文档兼容性也比较好。
混合检索的逻辑很直接：同一个查询同时发给 Milvus 向量检索和 Elasticsearch 全文检索，两路结果按权重融合后重新排序。权重可以根据场景灵活调整，法规合规类场景可以调高关键词匹配的权重，培训资料查询类场景则更多依赖语义覆盖。这种灵活性让同一套检索底座可以同时服务企业内部多条业务线。
深度增强：知识图谱的推理补全能力
检索能解决“找到相关内容”的问题，但“A 与 B 之间是什么关系”这类问题，它很难直接回答。
Neo4j 作为原生图数据库，和业务世界的实体、关系、属性描述直接对应。实体和关系直接映射为图的节点和边，Cypher 查询语言可以表达多层关联，比如“找出过去三年与同一个甲方合作超过两次、且其中至少一次项目评估为优秀的供应商”。这种查询如果拆成多步检索再人工拼凑结果，流程很长，遗漏风险也高。
图谱构建真正的难点在实体识别和关系抽取的自动化。企业文档格式繁杂，合同、标书、技术规范、会议纪要，实体类型和关系模式各不相同。系统需要先自动抽取文档中的关键实体——公司名称、人名、产品型号、项目编号等，再识别它们之间的语义关联，比如“供应商-供应-物料”“项目-依赖-资质”。抽取结果组织成可视化知识网络后，业务专家可以介入校验和修正，修正的过程又反过来优化抽取规则，形成一个持续改进的闭环。
在 RAG 链路里，图谱查询和向量检索并行执行。向量路召回语义匹配的文档片段，图谱路拉取与问题实体关联的子图——通常包含实体属性和一跳、两跳的关系路径。两路结果打包送入大模型，模型拿文档片段做事实依据，拿子图做关系推导的逻辑框架。在多条件约束、合规判定、供应链溯源场景下，引入图谱的准确率提升明显高于单纯依赖文档检索的方案。
三者协同：小艾智能体的全链路技术流转
把编排引擎、混合检索和知识图谱放在一条任务里审视，协作关系会更清晰：
任务进入，编排引擎调度文档处理节点，文本向量化存入 Milvus，实体关系对写入 Neo4j。分析阶段，并行启动混合检索和图谱查询，两路结果汇聚后送入大模型完成生成，最终触发输出节点。
小艾智能体是这套思路的工程落地版本，定位在企业知识管理的全链路处理。多格式文档自动解析、语义切分、向量化、索引构建走完整流水线。工作流引擎基于 LangGraph，用 JSON/YAML 声明图结构。模型层可切换主流大模型，Milvus、Neo4j、Elasticsearch 分别承接向量检索、图关系推理和全文检索。部署走微服务架构，各组件按负载独立扩缩。自学习机制持续收集反馈，把高质量问答自动转成知识条目，人工修正纳入学习体系。
大模型的简单封装构不成企业级 Agent，多技术栈的深度协同才是关键路径。LangGraph 提供可恢复的图执行能力，混合检索在语义和关键词两条路上并行召回，知识图谱用图查询补上跨文档关系推导的缺口，自学习机制把人的修正变成系统的长期记忆。