Graph Engineering Isn’t About More Connections — It’s About Which Ones Get Used

图工程不在于连接更多——而在于哪些连接被真正使用

Machine Learning Graph Engineering Isn’t About More Connections — It’s About Which Ones Get Used. I expected adding more communication pathways between agents to dramatically change network performance. It didn’t. Figuring out why turned into a more useful article than the one I set out to write. 机器学习图工程不在于连接更多——而在于哪些连接被真正使用。我曾预期增加智能体之间的通信路径会显著改变网络性能，但事实并非如此。探究其原因，最终写出了一篇比我最初计划更有价值的文章。

Emmimal P Alexander | Aug 18, 2026 | 15 min read Emmimal P Alexander | 2026年8月18日 | 15分钟阅读

TL;DR: This article shows a full working implementation in pure Python, with real benchmark numbers. What I did: built a controlled experiment that isolates one variable, relationship density, from everything usually confounded with it, using a fully deterministic agent policy instead of live model calls. 简而言之：本文展示了一个纯 Python 实现的完整方案，并附带了真实的基准测试数据。我所做的是：构建了一个受控实验，将“关系密度”这一变量从通常与之混淆的因素中剥离出来，并使用完全确定性的智能体策略，而非实时模型调用。

What I found: more communication pathways between agents did not automatically mean better multi-agent performance. Recovery stayed flat across the whole density sweep. But the pathways themselves didn’t stay flat — as density rose, the network used a shrinking fraction of the edges it had. The more useful engineering question isn’t simply how many connections exist. It’s how many of them actually carry information. 我的发现：智能体之间更多的通信路径并不自动意味着更好的多智能体性能。在整个密度扫描过程中，恢复率保持平稳。但路径本身并未保持平稳——随着密度的增加，网络所使用的边占比反而下降了。更有意义的工程问题不是简单地看存在多少连接，而是看其中有多少连接真正承载了信息。

This is not just a conceptual proposal. It is a working system with measurable, reproducible behavior. The experiment is reproducible; timing numbers are reported only where actually measured. 这不仅仅是一个概念性提议，而是一个具有可测量、可复现行为的工作系统。该实验是可复现的；计时数据仅在实际测量处报告。

The Assumption I Went In With

我最初的假设

Most people assume a failing multi-agent system has a prompt problem. You build a team of specialized agents, hook them up in a loose mesh, and run the pipeline. Instead of a finished result, you get endless loops, context drift, and a burnt-through token budget. The immediate knee-jerk reaction is to rewrite the system prompts or swap in a larger LLM. 大多数人认为多智能体系统失败是因为提示词（Prompt）问题。你构建了一个专业智能体团队，将它们连接成一个松散的网格，然后运行流程。结果得到的不是成品，而是无尽的循环、上下文漂移以及耗尽的 Token 预算。最直接的反应通常是重写系统提示词或更换更大的大语言模型（LLM）。

I suspected the real culprit was structural: the actual ratio of open communication channels between agents versus the total channels possible. In graph theory, that ratio is relationship density. For a directed graph with N nodes and E edges: D = E / (N * (N - 1)). 我怀疑真正的罪魁祸首是结构性的：智能体之间开放的通信通道与可能存在的总通道数之比。在图论中，这个比率就是关系密度。对于一个拥有 N 个节点和 E 条边的有向图：D = E / (N * (N - 1))。

Take an 8-agent setup: you have 56 possible directed communication paths. Density is simply the dial that controls how many of those 56 paths are actually open. I wanted to see if adjusting that single structural lever fundamentally changes how a network performs and whether more connectivity is actually better. 以 8 个智能体的设置为例：你有 56 条可能的有向通信路径。密度就是控制这 56 条路径中实际开启数量的“旋钮”。我想看看调整这个单一的结构杠杆是否会从根本上改变网络的性能，以及更多的连接是否真的更好。

A quick note on the setup: all the data below comes straight from real benchmark runs executing locally (Python 3.12, CPU-only, zero external API calls), unless explicitly noted as a design-phase calculation. 关于设置的简要说明：除非明确注明为设计阶段的计算，否则以下所有数据均直接来自本地执行的真实基准测试（Python 3.12，仅 CPU，无外部 API 调用）。

Who This Is For

本文适用人群

This experiment design is worth adapting if you are currently picking multi-agent topologies by gut feeling: defaulting to a fully connected mesh because it feels safer, or building a linear chain because it is easy to trace. It is also a solid template if you need to run controlled, reproducible experiments on agent architectures without blowing through your API budget on every iteration. 如果你目前仅凭直觉选择多智能体拓扑结构——例如因为感觉更安全而默认使用全连接网格，或者因为易于追踪而构建线性链——那么这个实验设计值得借鉴。如果你需要在不耗尽每次迭代 API 预算的情况下，对智能体架构进行受控、可复现的实验，这也是一个可靠的模板。

When to skip this: 何时可以跳过：

• If you just want a single magic density number to drop into production: The metrics here are tied to one specific task, one topology family, an 8-agent layout, and a deterministic messaging policy. They will not copy-paste cleanly into your codebase, and I am not claiming these exact thresholds hold for stochastic LLM runs. 如果你只是想要一个可以直接投入生产的“魔法密度数字”： 这里的指标与特定的任务、特定的拓扑族、8 智能体布局以及确定性消息传递策略绑定。它们无法直接复制到你的代码库中，我也不认为这些确切的阈值适用于随机性 LLM 运行。
• If your bottleneck is individual model performance: If a single agent is failing at basic task execution, structural routing adjustments will not save it. 如果你的瓶颈在于单个模型性能： 如果单个智能体在基础任务执行上就失败了，结构性的路由调整也无法挽救它。
• If your research requires true model non-determinism: This setup intentionally trades away LLM stochasticity to guarantee exact reproducibility across runs. 如果你的研究需要真正的模型非确定性： 本设置有意牺牲了 LLM 的随机性，以确保运行过程中的精确可复现性。

The complete code and the pre-specified test protocol are available in the repository: https://github.com/Emmimal/graph-density-engine/ 完整代码和预设的测试协议可在仓库中获取：https://github.com/Emmimal/graph-density-engine/

Building the Experiment

构建实验

Most comparisons that look at network topology make a fundamental mistake: they change two variables at once. They compare a chain to a mesh to a fully connected graph, which changes both the visual shape of the network and the actual edge count at the same time. When performance shifts, there is no way to know if the driver was relationship density or the specific layout of the graph. 大多数关于网络拓扑的比较都犯了一个根本性错误：它们同时改变了两个变量。它们将链式、网格和全连接图进行比较，这同时改变了网络的视觉形状和实际边数。当性能发生变化时，无法判断驱动因素是关系密度还是图的具体布局。

To isolate the real cause, this design keeps every other factor static and sweeps a single variable. Here is the pipeline, end to end: 为了隔离真正的原因，本设计保持所有其他因素不变，仅扫描单一变量。以下是端到端的流程：

[System architecture pipeline for network simulation, highlighting the agent routing protocol, shared state accumulation, and diagnostic evaluation.] [网络模拟的系统架构流程，重点展示了智能体路由协议、共享状态累积和诊断评估。]

The test plan evaluates five distinct density levels: 20%, 40%, 60%, 80%, and 100%. The system uses a fixed count of eight agents throughout the entire benchmark. Each density level undergoes ten independent trials, totaling fifty runs. Every run uses a unique random seed, with all seeds locked before executing the test suite. 测试计划评估了五个不同的密度水平：20%、40%、60%、80% 和 100%。整个基准测试中，系统始终使用固定的 8 个智能体。每个密度水平进行 10 次独立试验，总计 50 次运行。每次运行使用唯一的随机种子，所有种子在执行测试套件前均已锁定。

Component 1: The Topology Generator

组件 1：拓扑生成器

The network topology family is strictly locked to connected Erdős–Rényi random graphs [1]. Edges are sampled uniformly at random until reaching the target density level. Any disconnected graph samples are immediately rejected and resampled until a fully connected path exists across all nodes. 网络拓扑族严格锁定为连通的 Erdős–Rényi 随机图 [1]。边被均匀随机采样，直到达到目标密度水平。任何不连通的图样本都会被立即拒绝并重新采样，直到所有节点之间存在连通路径。

This generation process represents the only graph construction pipeline in the entire project. There are no hidden central hubs, star topologies, or hand-tuned structural rules that could quietly confuse graph shape with pure edge density. 这个生成过程是整个项目中唯一的图构建流程。没有隐藏的中心枢纽、星型拓扑或人工调整的结构规则，这些规则可能会悄悄地将图的形状与纯粹的边密度混淆。

Here is how a 20% density graph compares to a 100% density graph for the exact same 8-agent setup. Each row represents an individual agent, and each indicator highlights an active, outbound communication path to another node: 以下是针对完全相同的 8 智能体设置，20% 密度图与 100% 密度图的对比。每一行代表一个智能体，每个指示器突出显示了通往另一个节点的活跃出站通信路径：

[Adjacency matrices comparing sparse (20%) and fully connected (100%) network topologies for an 8-agent system.] [对比 8 智能体系统中稀疏 (20%) 和全连接 (100%) 网络拓扑的邻接矩阵。]

def generate_connected_erdos_renyi(num_agents, target_density, rng, max_attempts=20000):
    edges = all_possible_directed_edges(num_agents)
    target_edge_count = round(target_density * len(edges))
    for _ in range(max_attempts):
        chosen = rng.sample(edges, target_edge_count)
        adjacency = build_adjacency(chosen, num_agents)
        if is_strongly_connected(adjacency):
            return adjacency