基于上下文图谱的智能 AIOps：Neocarta、Neo4j、LangGraph 与 Gemini

当某个平台或SRE团队出现故障时，同样的情况会反复出现：一名工程师追踪Dynatrace的追踪数据，另一名工程师在GitHub的部署记录中查找变化内容，还有一名工程师修改ServiceNow中的工单，以便管理层不再要求更新进展。由于这些信息并未集中存储在某个特定地方，因此没有人能掌握全貌，它们分散在三种甚至十种不同的工具中。

正是这种分散状态，而非漏洞或错误的部署，往往成为导致恢复缓慢的原因。延迟的产生是因为人们不得不重新整理那些其实早已存在于系统各处、只是没有集中存放的上下文信息。

解决此问题的方案是将三种选定技术整合为一个智能 AIOps 平台。Neocarta 负责自动将数据导入 Neo4j 图数据库，并通过 MCP 将该图结构暴露给各类 AI 工具。LangGraph 负责对智能体进行确定性调度，而带有 Gemini 的 Google Gen AI SDK 则提供推理功能。该平台无需数据湖屋、批量 ETL 过程，也不存在手工构建的 webhook 接口或过时指标的仪表板。最终形成的是一个实时的、可查询的运营现状图谱，智能体可直接访问并据此采取行动。

用上下文图替代仪表板

许多AIOps工具在原本为商业智能设计的分析数据存储基础上添加了智能功能，而非用于实时推理，而这本就是错误的基础。该设计将运行状态视为图结构问题：每个服务、部署、事件、团队及修复措施都成为节点，而它们之间的关联，如DEPLOYED_TO、ALERTS_ON、TRIGGERED_BY和OWNER_OF，则是一级边。

一旦基础设施事件形成连通的图结构而非孤立的日志，根本原因分析的性质就会发生变化。它不再需要人工逐一排查，而是转变为图遍历操作，即通过Graph RAG让大语言模型能够直接对多跳查询进行推理。

实现闭环的四个层次

每层承担一项职责，由于智能体的自身行为会被写回图中，因此形成了闭环。这样一来，它处理下一个事件时就能知晓此前已尝试过的方法。

1. 使用 Neocarta ingestion CLI 进行自动化数据收集。 无需为每个工具编写 webhook 接收器，Neocarta 连接器可直接从 ServiceNow、Dynatrace 和 GitHub 获取元数据及日志，并将其加载到图中。无需为每个数据源维护自定义的数据收集服务。

Neo4j中的系统化上下文，由Neocarta MCP服务器提供支持。这是整个系统的核心运作部分。仓库、服务、部署、事件、团队以及修复措施均为节点，而每一种关联则表现为带类型的定向边。Neocarta在图数据结构前端部署了MCP服务器，因此任何支持MCP的工具，包括LangGraph代理，都无需编写自定义数据库代码即可对其进行查询。

利用LangGraph与Gemini进行推理。LangGraph状态机会执行观察、定位、决策、行动的循环流程。它通过MCP获取相关的子图数据，将其整理成提示语，然后让Gemini在两种选项中做出选择：要么解决问题，要么将任务转交给人类处理。

修复与回写。如果代理决定采取行动，它会启动修复操作，例如通过GitHub Actions进行回滚，然后将结果作为新节点记录在图中。大多数AIOps演示都会跳过这一步，而正是这一步使得流程形成闭环而非一次性操作。

Neocarta负责替代自定义的数据导入服务以及直接的数据库驱动调用。其CLI可自动将数据导入Neo4j，而MCP服务器则是代理获取图结构上下文时实际交互的对象。

第1层与第2层：通过Neocarta进行数据导入

模式是首要的，因为它是整个平台所依赖的本体。节点标签和关系类型正是每个连接器以及每条Cypher查询最终读取和写入的内容。每一个实体都是带类型的节点，而所有的依赖关系、所有权链接及警报则都是带类型的定向边。正是这种结构使得跨工具的调查能够转化为遍历操作。

过去，数据导入意味着需要为每个数据源配置一个webhook接收器，并为每种数据格式手动编写Cypher代码。Neocarta则将这一过程简化为配置操作——只需将其CLI指向ServiceNow、Dynatrace和GitHub，它就能自动完成模式发现、增量加载以及将数据映射到图中的节点和关系类型中。

# Register each source once — Neocarta handles auth, schema inference, and scheduling
neocarta connect servicenow --instance your-org.service-now.com --scope incident
neocarta connect dynatrace --tenant your-tenant-id --scope metrics,problems
neocarta connect github --org your-org --scope deployments,repos

# Point the loader at your graph and let it run
neocarta load --target neo4j://your-instance:7687 --database aiops-graph

在底层，使用的是与手工编写的相同 MERGE 和 CREATE 模式。诸如仓库、服务及团队之类的持久化实体会被合并，因此不会出现重复节点。与特定时刻相关的事件，如部署或故障，每次都会作为新节点被插入，这样既能保证时间线的真实性，又能保留早期的历史记录。不同之处在于，无需有人去维护那些会按各自时间表改变数据格式的三个 API 之间的映射代码。

除了数据摄取功能外，Neocarta 还集成了 MCP 服务器。一旦图结构被构建完成，它就会作为一个 MCP 接口对外提供，而支持 MCP 协议的客户端（如 LangGraph）就可以像调用普通工具一样发起多跳图查询。相应的代理代码也无需任何数据库驱动层来进行写入或维护。

# LangGraph's context-fetching node talks to Neocarta over MCP,
# not to a Neo4j driver directly
from langchain_mcp_adapters.client import MCPClient

neocarta_client = MCPClient(server_url="http://neocarta-mcp:8080")
tools = await neocarta_client.get_tools()   # graph_query, graph_traverse, etc.

模式控制仍由工程师掌控。约束条件和索引始终直接在 Neo4j 中定义。

CREATE CONSTRAINT unique_service_id IF NOT EXISTS
FOR (s:Service) REQUIRE s.id IS UNIQUE;

CREATE INDEX incident_state_index IF NOT EXISTS
FOR (i:Incident) ON (i.state);

第三层：LangGraph循环

这一层被称为“代理型”结构。它并非通过一次大型语言模型调用来完成推理，而是以状态机的方式运行，具有明确的节点和边，因此每条决策路径都可以被检查、测试和深入分析，这与许多代理系统中不透明的循环结构截然不同。

状态是一个类型化的字典，会在图中不断流转。

class AIOpsAgentState(TypedDict):
    incident_id: str
    failing_service_id: str
    graph_context_summary: Optional[str] = None
    safety_gate_passed: Optional[bool] = None
    chosen_action: Optional[str] = None
    target_repository: Optional[str] = None
    execution_result: Optional[str] = None

四个节点驱动着这个循环：

• FetchGraphContext会调用Neocarta的MCP服务器中的graph_traverse工具，追踪某个问题直至其对应的服务，再进一步定位到修改了该服务的部署版本、相关代码仓库以及负责该项目的团队。代理代码从不直接建立数据库连接。
• VerifySafetyGate通过相同的MCP查询接口检查过去一小时内是否已针对该服务执行过修复操作。这种断路机制可防止代理在出现不稳定问题的服务上无限循环处理。
• GeminiReasoning仅在安全检查通过后才会运行。Gemini 2.5 Pro会收到图形化上下文摘要以及具体的系统指令，而其唯一可接受的回复是两个固定预定义的标记之一。

ExecuteRemediationTool会启动修复流程，并通过Neocarta将一个RemediationAction节点写回Neo4j，从而完成循环。

如果要说哪个组件最值得关注，那就是安全门控机制。此处它被实现为MCP工具调用，而非直接的驱动程序会话。

async def evaluate_remediation_safety_gate(state: AIOpsAgentState) -> Dict:
    result = await neocarta_client.call_tool(
        "graph_query",
        cypher="""
            MATCH (s:Service {id: $service_id})<-[:EXECUTED_AGAINST]-(a:RemediationAction)
            WHERE a.timestamp >= datetime() - duration('PT1H')
            RETURN count(a) as active_actions
        """,
        params={"service_id": state["failing_service_id"]},
    )
    return {"safety_gate_passed": (result["active_actions"] == 0)}

没有安全机制的自主行动循环绝不应被投入使用。正是这个安全机制防止了智能体因底层异常尚未消除而每隔三十秒就重新触发回滚操作。

Gemini节点刻意设计得较为简单，而这正是它的优点所在。

system_instruction = (
    "You are an automated Agentic AIOps architect. "
    "Analyze the provided graph context summary. "
    "If a deployment recently modified the service state, "
    "output EXACTLY the word TRIGGER_ROLLBACK. "
    "If the context is clear but safe guidelines are violated, "
    "output HALT_ESCALATE. Do not append any other characters."
)

将模型的输出限制为两个精确的标记，能使该调用更像一个带参数的函数而非聊天回复，而当结果触发生产环境回滚时，这正是所需的特性。

第4层：闭环处理

最后一个节点要么通过GitHub Actions API发起回滚操作，要么仅记录停止状态而不采取其他动作。无论哪种情况，该图结构都会通过与其他内容相同的MCP写入路径进行更新，因此无需额外的数据库凭证即可完成回写操作。

await neocarta_client.call_tool(
    "graph_write",
    cypher="""
        MATCH (s:Service {id: $service_id}), (i:Incident {id: $incident_id})
        CREATE (a:RemediationAction {id: $action_id, timestamp: datetime(), status: 'SUCCESS_ROLLBACK'})
        CREATE (a)-[:EXECUTED_AGAINST]->(s)
        CREATE (a)-[:ATTEMPTED_TO_FIX]->(i)
    """,
    params={"service_id": service_id, "incident_id": incident_id, "action_id": action_id},
)

让这成为一个闭环系统而非一次性使用的自动化脚本的，是一个简单的细节：智能体自身行动的结果会成为其评估下一个问题时的上下文，因此该平台会随着时间推移对各种情况有更深入的了解，而非越来越不了解。

从开始到结束的整个事件过程

该蓝图包含一个模拟运行，展示各组件如何协同工作，其中的部分内容具有很好的参考价值。

1. 14:00:00. 支付网关服务完成部署，由此新增了一个与该服务相连的“部署节点”。
2. 14:05:00. Dynatrace在该服务上检测到严重异常。
3. 14:06:00. ServiceNow中出现P1级事件，该事件成为一个“事件节点”，并通过“ALERTS_ON”边与相关服务关联起来。

LangGraph智能体在新的事件节点上被激活。FetchGraphContext从事件节点依次遍历到服务、部署、仓库和团队节点，发现该部署发生在异常发生前五分钟。

VerifySafetyGate检查后发现过去一小时内没有更早的修复操作，因此路径畅通。

Gemini收到上下文摘要后，识别出是该部署导致了此次事件，于是返回TRIGGER_ROLLBACK指令。

工具执行器在GitHub Actions中启动回滚工作流，随后在Neo4j中存储一个新的RemediationAction节点。

从异常出现到问题解决仅需几分钟，无需召开紧急会议。整个推理过程都会以图结构的形式被记录下来，因此可以查询智能体为何会采取特定行动。

一旦完成映射，该事件就会形成一个贯穿团队、代码、部署、服务、事件以及处理人员自身修复措施的单一连通结构。这正是 Gemini 所分析的子图，用一个连通结构替代三个独立的控制面板，使得处理人员能够追踪 P1 级事件直至其背后的代码提交记录。

这一过程可以拆分为构建该图的三个阶段：部署、崩溃和修复。每个阶段都是独立的数据库写入操作，但它们共同构成了一个连续的时间线——从 Git 合并开始，经过生产环境警报，最终在七分钟内实现闭环修复。

为工程师提供图表视图

工程师无法查看的自动化系统会带来风险。因此，该方案还包括一个基于 pyvis 构建的 Streamlit 控制面板，用于实时展示图表拓扑结构以及操作记录的动态清单。

net = Network(height="600px", width="100%", bgcolor="#1a1c1e", directed=True)
color_map = {
    "Team": "#5f3dc4", "Repository": "#24292e", "Deployment": "#007acc",
    "Service": "#11a685", "Incident": "#c41c1c", "RemediationAction": "#cc0088"
}

工程师可以查看从 Git 合并到生产环境问题出现再到自动修复的整个流程，该视图支持平移和缩放；同时还有一个侧边栏记录着代理执行的每一项操作及其顺序。透明度是让自主系统足以在生产环境中可靠运行的关键，因为它的所有操作都是透明的。

不会影响生产环境的部署方式

推荐的方案较为保守，分为三个阶段逐步实施，而非一次性启用。

• 第1周：数据导入与验证。将 Neocarta 连接器指向每个数据源的沙箱副本，设定图结构约束，并在涉及任何生产数据之前确认节点能够正确映射和关联。

第2周，进行干运行测试。在只读的测试数据库上构建LangGraph调度器，关闭实际执行功能，观察Gemini的决策过程。此时会暴露出提示词或上下文方面的问题。

第3周，实现闭环自动化。将第4层与实际的测试API端点连接起来，确认写回事务能够完成整个循环，从而使安全机制拥有可参考的真实历史数据。

只有当这三个阶段都测试通过后，修复工具才能用于处理生产环境中的端点。

该设计为何可行

有一些设计决策决定了某个演示版本与可用于生产环境的可靠系统之间的区别。

• 状态机优于自由形式的智能体循环。LangGraph使每条决策路径都清晰可见且可被检查，不存在任何无法复现的隐藏推理过程。
• 在每次可能触发操作的LLM调用之前，都会先有一道安全门进行检测。如果最近已执行了补救措施，智能体就无法访问推理节点。该检查由确定性代码实现，而非通过提示词完成。
• 输出结果有严格限制。不会要求Gemini生成散文式内容，将其限制在两个令牌数之内，这样其输出结果就能像函数返回值一样可靠。
• 该图结构既充当内存也承担存储功能。补救措施会被写入智能体读取的同一图结构中，因此它的情境意识会不断积累，不会因每次事件而重置。
• MCP是智能体与图结构之间的接口。由于Neocarta的MCP服务器位于LangGraph与Neo4j之间，智能体无需持有数据库驱动程序或管理连接池，只需调用相关工具即可。这一接口还使得可以在不改动数据接入层或图结构层的情况下，用其他模型替换Gemini，或用其他协调器替换LangGraph。

图结构中固有的上下文信息、具有固定步骤的推理循环，以及编码在代码中的断路器机制，共同使得自主修复功能能够真正落地应用，而不仅仅停留在演示文稿中的美好设想。合理的后续措施还包括使用Docker Compose部署整个技术栈，并通过第4层路由器发送Slack通知，这样即便无需任何人干预，大家也能及时了解到每一次自主执行的操作。