当AI能看到你整个系统:一个工程师把公司所有数据装进一张图

Matt Jones · Adyen 资深工程师 · 2026-10-07
听中文精华AI 合成朗读00:00
因为当我们每秒处理 700 万个 span 的时候,我们会在乎两个 web 应用之间漏掉一两个调用吗?
— Matt Jones

关联

人物 Matt Jones

公司 Adyen

概念 Architect · Neo4j · Flink · Kafka · 智能体 · 服务图 · Atrium · Git worktree · MCP · Sentinel

Matt Jones 是支付公司 Adyen 的资深工程师。过去几个月,他和同事 Rafael 造了一个叫 Architect 的内部系统:

把整个公司——服务调用、代码、数据库结构、基础设施、DNS、组织架构——全部装进一个 Neo4j 图数据库,再接上AI智能体。

结果不只是排查故障变快了,整个开发和发布流程都被改写。以下是他在这期 Beyond Coding 播客里讲的故事。

一个让人半夜崩溃的问题:没人说得清系统是怎么连的

Adyen 是一家 20 年历史的公司,代码仓库也有 20 年历史。

Matt 的团队想搞清楚平台到底是怎么拼起来的:谁在调用谁,有哪些藏起来的依赖,哪些查询特别忙。

他们去问各个团队,拿回来一些 Figma 图和日志查询。能回答一部分问题,但一旦问到细处就卡住。

比如服务器上有个吵闹的邻居,到底影响哪些服务?能查出来,但要 45 分钟,开一堆浏览器标签来回切。

对于凌晨 3 点被报警电话叫醒的工程师,这不可行。Architect 就是为解决这个问题而生的 。

Architect 是什么:9 个数据库拼成一张大图

简单说,Architect 是一个特别大的图数据库,里面装着 9 类数据 :

  • 服务图:从每个应用的调用链路追踪里提炼出谁调用谁;
  • 代码图:每次代码提交后自动重建,精确到方法级别的依赖关系;
  • DNS 图、数据存储拓扑、数据表结构、基础设施硬件,甚至组织架构图——用来知道出了问题该找谁。

关键在于这些图是连起来的。服务图里的一台主机,能对应到基础设施图里的具体机房、具体机架。

Matt 说:「作为人类,我们能看到的多了很多,而智能体能看到的远得多。这很疯狂,也有点吓人。」

第一次上生产环境:全面崩溃

最初的技术选型很随意,用的是 Kafka Connect。测试环境和预发布环境数据量小,一切正常。

一指向生产环境,每秒 700 万条追踪数据涌进来,Kafka Connect 直接积压放弃。「我从没见过一个应用像 Kafka 这样这么快就撂挑子。」

Matt 慌了,和 Rafael 坐下来重想。同事 Santosh 建议试试大数据框架 Flink。他们写了个快速验证,觉得有戏,接下来几周一直在调优。

一个偷懒决定:干脆不做检查点

Flink 有一套 checkpoint 机制,记录处理进度,出故障后能从断点恢复。但它本身带来大量写入开销。

团队算了笔账:每秒 700 万条数据,漏掉一两个服务间调用有什么关系?反正几小时内大概率还会再出现。

于是他们干脆关掉了检查点 。

事后看,没什么遗憾——至今没发现明显的数据缺失,而且有后台任务对照代码图来区分“新变化”和“丢数据”。

更重要的是省下来算力干正事:700 万条追踪数据里,真正需要的只有约 30%,过滤聚合之后,实际写入 Neo4j 的只有每秒约 4000 条记录 。

从 7 个月到 4 个月:AI 智能体是真正的加速器

整个服务图从零到跑满生产流量,只花了 3 到 4 个月,主力就是 Matt 和 Rafael 两个人,外加大量 AI token 。

Matt 的工作方式是:两块显示器并排开五六个智能体,一个写规格,一个执行,互不干扰。

为此他还造了个内部工具 Atrium,让智能体之间能互相通信——各自声明自己在改哪些文件,发现冲突就互相打招呼,等对方改完再动手 。

Atrium 还用 Neo4j 做了智能体记忆,新智能体上线时能直接拿到前面工作的全部上下文。

团队后来定下了清晰的 Java 框架和代码规范,智能体看一眼现有实现就能照抄扩展。

加一种新的数据接入,大概 4 个小时就能建好 。

这张图反过来改变了发布流程

知道了一切之后,可以做以前做不到的事:

工程师提交代码时,系统自动追溯这段代码牵涉哪些关键业务流程。

如果碰到关键流程,测试覆盖率要求就更高;不碰关键流程的小改动,即使在支付行业高峰期的代码冻结期也能放行 。

他们还做了个子产品 Sentinel,每 20 分钟跑一次反模式检查——比如有没有应用跨数据中心去查主库。

发现问题的团队点一个“自动修复”按钮,后台智能体就会克隆仓库、改代码、提合并请求,人只需要审核批准 。

看得太清楚,也成了新的风险

现在每个工程师的AI智能体都能查到所有这些数据。好处是排查问题极快;

坏处是大家开始看到以前看不到的东西——别的团队服务的流量、DNS 链路多绕了两跳、到某个存储集群的延迟涨了 5 毫秒。

基础设施团队收到的问题比以前多得多 。

更严肃的问题是安全:恶意的人如果拿到这些查询能力,能摸清整个平台。

团队正在做权限体系,比如安全漏洞(CVE)数据只对安全团队开放。

智能体靠提示词吃饭:具体就灵,含糊就完蛋

最后聊到一个现实问题:MCP 工具越装越多,反而撑大上下文、让智能体犯晕。Matt 自己关掉了公司 AI 网关里 90% 的工具 。

他的判断是:结构化、输入输出明确的需求,用 API;还不知道要问什么、需要灵活探索的场景,才用 MCP。

对事故响应也一样。如果问题很具体——比如“阿姆斯特丹机房淹了,帮我们查”——智能体很强,能同时查多个数据源。

但如果含糊地问“好像有点不对劲,帮我看看”,它会给你列出 20 个问题,而且全是错的 。

本集带走

  • 把服务调用、代码、基础设施等数据连成一张图,能让AI智能体看到人类看不到的全局,但透明度本身也会变成新的安全和管理问题。
  • 服务图是最值得起步的一张图——它回答“什么在发生”;代码图回答“怎么发生、为什么”;其他图都是锦上添花 。
  • 数据量大到一定程度,可以大胆舍弃一些工程上的“正确”——比如不做检查点——来换性能。
  • 让多个智能体并行干活,前提是给它们通信机制、清晰框架和统一规范,否则会互相踩脚。
  • 智能体的表现高度依赖问题是否具体:具体的问题得到快速准确的答案,含糊的问题只会得到噪音。
全部金句 12 条

因为当我们每秒处理 700 万个 span 的时候,我们会在乎两个 web 应用之间漏掉一两个调用吗?
Because when we’re processing 7 million spans a second, do we care if we missed one or two calls between two web apps?
—— Matt Jones · [26:49]

所以尽管我们每秒读取 700 万个 span,我们每秒写入 Neo4j 的大约只有 4000 条记录。
So even though we’re reading 7 million spans, we’re writing something like 4,000 records a second to Neo4j.
—— Matt Jones · [21:36]

我们总是可以这样拆解:服务图是正在发生什么,代码图是它如何发生以及为什么发生,基础设施图是它在哪里发生。
So we can always break it down as saying, you know, the service graph is what is happening. The code graph is how and why it’s happening. The infograph is where it’s happening.
—— Matt Jones · [46:34]

你基本上是在依据代码自己怎么想的来判断,而不是它实际在做什么。
You’re kind of going on what the code thinks, not what it does.
—— Matt Jones · [46:31]

以至于当人们在集成时,默认方式就是通过 MCP,而我必须真的去问:你是不是其实只需要一个 API?
Like, to the point that when people are integrating, the default is via MCP and I have to go, and I have to literally go, Chua, it’s like, do you just need an API for this, really?
—— Matt Jones · [13:55]

我当时是想在一个有 20 年历史的公司、有 20 年历史的代码库里找出那些见不得人的秘密。
I was trying to find the skeletons in the closet in a 20-year-old company in a 20-year-old repo.
—— Matt Jones · [17:25]

说实话,我从没见过一个应用像 Kafka 那样放弃得那么快。
Honestly, it’s like I’ve never seen an application give up as quick as Kafka could.
—— Matt Jones · [24:51]

所以你知道,如果是一次挥棒落空,那么好吧,我们损失了三四个月,但我们没有损失一年。
So it was, you know, if it was a swing and a miss, then, okay, sure, we’ve lost three or four months, but we haven’t lost a year.
—— Matt Jones · [67:33]

但如果你一开始就模糊,我觉得结果永远会是模糊的。
But if you start vague, I think it’s always going to be vague.
—— Matt Jones · [77:44]

而如果我们真的写出精心打造的、非常具体的提示词,向智能体提出具体的问题、给它们具体的方向,我们就能非常快地得到答案,而且它们似乎不会被带偏。
Whereas if we actually write well-crafted prompts, very specific prompts, we’re asking the agents specific questions and giving them specific ways on where to go, We can get answers very, very quickly, and they don’t seem to get misled.
—— Matt Jones · [78:31]

因为人们在用智能体写作,所以我得以智能体对抗智能体。
Because people are writing with agents, so I have to combat agents with agents.
—— 嘉宾 · [58:48]

但我注意到,如果我不使用智能体,作为一个单独的个体,我已经跟不上了。
But I have noticed that if I don’t use agents, I can’t keep up as a single individual anymore.
—— 嘉宾 · [59:00]

接着看

顺着「智能体」挖下去