LLM作中间件易脆，向量数据库难多跳推理。需分层治理架构，尤其上下文层（DKG）。切勿DIY，应将上下文视为采购基础设施。智能是商品，上下文非。
译自：What It Takes To Scale AI Agents in Production
作者：Raj Shukla
随着能够进行多步、测试时计算的“推理”模型的发布，解决复杂问题所需的智能可通过标准API获取。
对于企业技术领导者而言，这看起来是进步。但它引入了一个巨大的、隐藏的可扩展性上限。
陷阱在于依赖大型语言模型（LLM）充当自身的中间件。团队经常暴露现有的API端点，这些端点是为微服务的严格契约而非LLM构建的，并依赖系统提示来调用正确的API，提取正确的参数。
假设是，随着LLM的工具调用能力提高，它能理解API背后的语义或业务逻辑。这是一个谬论。在LLM驱动的智能体工作流中，你最好的“契约”是自然语言提示。这是非确定性的技术债务。你实际上是用稳定的服务接口换取了概率性猜测。
当你在数据和API之上没有共享语义层的情况下部署通用智能体时，你构建的不是可扩展的产品；你构建的是脆弱的胶水代码。
从命令式胶水到智能体协议
在分布式系统的前一个时代，“胶水代码”意味着硬编码的Python逻辑，从API A获取customer_id，转换JSON并将其发布到API B。今天，行业正在转向充当“通用适配器”的智能体，它们在运行时检查功能，而不是依赖脆弱的、预先编写的集成脚本。
但如果没有受治理的领域层，即使是这些高级功能也只会加速你生成未经验证输出的速度。试验项目和生产资产之间的区别不再是你选择的模型或智能体框架。它是你为扩展它们而构建的受治理的架构。
“向量池”的局限性
大多数企业AI试点项目都是最先进的推理引擎，但却被扁平文件拓扑或有损信息检索所扼杀。
数据团队通常使用行业标准模式来解决这个问题：使用向量数据库（通常升级为带关键词提取的混合搜索）的检索增强生成（RAG）管道。这种方法非常适用于信息检索——查找与特定查询匹配的特定段落。
然而，它在多跳推理方面表现不佳。
向量数据库依赖余弦相似度，这是一种在嵌入空间中衡量“接近度”的几何计算。这适用于语义匹配，但在传递性方面会失败。它无法可靠地跨不同文档导航逻辑链。
考虑一个工业背景下的故障场景：
- 文档A指出“泵X”给“阀门Y”供料。
- 文档B指出“阀门Y”易受“压力警告Z”影响。
如果工程师询问：“泵X有哪些风险？”，标准的向量搜索很可能会失败，因为“泵X”和“压力警告Z”从未出现在同一个上下文块中。在向量嵌入空间中，它们在拓扑上是遥远的。向量数据库看到的是两个不相关的数据簇；它无法从A“跳跃”到B再到C来综合答案。
你得到的系统可以检索事实，但无法遍历关系。
理解GraphRAG与领域知识图谱
工程师经常问：为什么不直接使用GraphRAG呢？
GraphRAG在查询时检索方面功能强大。它对实体和关系进行编码，以便模型可以遍历上下文并在生成过程中执行多跳推理。你应该用它来改进事实基础并减少问答中的幻觉。
但GraphRAG不能取代领域知识图谱（DKG）。
这样想：GraphRAG是一种检索技术，它遍历文本中发现的边。DKG是定义系统状态的基础设施。
考虑阅读手册和了解机器状态之间的区别：
- GraphRAG检索到一个安全协议，规定如果振动超过5毫米/秒，系统必须触发紧急停止。
- DKG知道“涡轮-4”目前处于“启动序列”中，此时高振动是暂时的且预料之中的。
如果没有DKG来管理这种状态，智能体就会虚构一场危机。它检索到正确的规则，但将其应用于错误的上下文，从而触发错误的关机。
对于生产规模，你需要两者：DKG用于操作上下文和状态管理，GraphRAG用于在该状态之上进行更好的检索。
为了打破“胶水代码”的循环，工程团队必须构建在一个由三层定义的受治理架构之上：
- 上下文层（DKG）： 将不同的模式统一为一个本体。
- 编排层： 管理从人工干预到完全自主的“自主性滑块”。
- 治理层：策略即代码： 充当AI决策的CI/CD门禁。
以下是该策略在实践中，在严苛的金融犯罪预防环境中的应用。
深度探究：受治理的策略（金融服务）
很少有环境像反洗钱（AML）一样严苛。在标准技术栈中，基于规则的检测模型可能会产生高达95%的误报，因为它们缺乏上下文。
受治理的架构通过引入子垂直精度来改变工作流的物理特性。
1. 上下文层：子垂直精度
泛化的“金融服务”数据模型是不够的。赌场游戏（筹码转移）的风险信号与人寿保险（受益人欺诈）的风险信号根本不同。
DKG必须解析那些特定子行业的身份。这将本体视为可重用的语义资产，将模式映射时间从数周缩短到数小时。
2. 编排层
该架构不让智能体随意游走，而是将调查视为一个受治理的多步工作流。它从完全自主的数据收集（检索KYC文档）到半自主的起草（可疑活动报告叙述），并在提交前需要人工干预的签署。
3. 治理层：策略即代码
治理不是事后审计；它是一个硬性门禁。如果智能体的叙述引用了证据日志中不存在的交易，系统将拒绝该输出。你得到的是一个可数学审计的决策轨迹，而不仅仅是聊天记录。
表1：AML工作流中的受治理AI架构
与标准RAG管道不同，此工作流在摄取阶段（步骤01）使用DKG解析实体身份，并在最终输出之前（步骤05）强制执行策略即代码。
| 阶段 | 启用AI | 角色/行动 | 结果 |
|---|---|---|---|
| 数据摄取 | 智能体 + DKG | 使用金融行业商业本体标准自动化模式映射和实体解析。 | 指标： 入职时间从数周缩短到数小时。 |
| 异常检测 | 预测性 | 使用机器学习发现风险信号并消除误报。 | 指标： 误报率降低80%以上。 |
| 警报分类 | 智能体 | L1调查员收到自动编译的案例文件（KYC、交易）。 | 指标： 手动“转椅”步骤减少80%以上。 |
| 调查 | 生成性 | L2调查员收到可能的根本原因和带有证据的叙述草稿。 | 指标： 调查时间从>100分钟缩短到<20分钟。 |
| 审计 | 智能体 | 在整个工作流中强制执行策略即代码。 | 指标： 确定性审计追踪。 |
“第二天”的现实：上下文的隐藏成本
对于许多工程领导者来说，本能是从第一性原理构建这个技术栈。架构模式似乎很清晰：启动一个像Neo4j或Amazon Neptune这样的图数据库，引入金融行业商业本体（FIBO）等开放标准，并编写摄取脚本来映射你的数据。
这是一个有效的模式。完全有可能自己构建这个技术栈。像谷歌和Meta这样的科技巨头都拥有庞大的内部工程团队来做这件事。
然而，风险不在于构建阶段。它在于“第二天”的运营。
陷阱在于假设图数据库等同于语义层。如果你选择DIY路线，请准备好承担两个与你的核心产品无关的持续工程循环：
- 集成税（模式漂移）： 每当上游API发生变化（例如，Salesforce更新一个字段）时，你的自定义ETL（提取、转换、加载）管道就会中断。你现在的工作重心是维护连接器，而不是发布功能。
- 数学上限（实体解析）： 陷阱不是编写Python脚本来映射模式。陷阱是实体解析的数学上限。确定“J. Smith”是否是1000万条记录中的“John Smith”需要二次比较。为AI智能体实时执行此操作不是脚本问题；它是一个分布式计算问题。如果你自己构建它，你不是在构建一个AI应用；你是在无意中构建一个主数据管理（MDM）平台。
构建自己的语义转换层在架构上等同于自建认证数据库。正如工程团队现在将身份管理视为一种托管平台能力而非DIY功能一样，实体解析的复杂性也要求一个托管层。
获胜的工程团队不会是那些编写最佳摄取脚本的团队。他们将是那些将上下文视为采购基础设施，而不是定制工程项目的团队。
结论：停止构建胶水代码
技术领导者的教训是明确的：智能是一种商品，但上下文不是。
你明天可以将Gemini 3替换为GPT-5，“智能”成本只会下降。但是，在智能成本下降的同时，上下文的成本却在上升。更智能的模型需要结构化、关系型数据才能有效推理。
工程领导者必须决定其团队的优势所在。如果你构建自己的语义层，你实际上是在为AI时代维护一个定制的ORM。这是一条可行的道路，但它需要专门的团队进行本体维护，而不仅仅是提示工程。
要了解此架构如何将工业维护根本原因分析从48小时压缩到10分钟，请在SymphonyAI博客上查看完整的工作流。
