详细内容或原文请订阅后点击阅览
图工程不是关于更多连接 - 而是关于使用哪些连接
在代理之间添加更多通信路径并不一定会提高多代理性能。在 50 次运行的受控、可重复实验中，回收率在 20% 至 100% 关系密度范围内保持非常稳定。但随着网络变得更加密集，实际使用的边的比例急剧下降，揭示了配置连接和行为连接之间的差距。图工程不是关于更多连接 - 而是关于哪些连接被使用首先出现在走向数据科学上。
来源:走向数据科学TL;DR
纯 Python 中的完整工作实现，具有真实的基准数据。
我做了什么：建立了一个受控实验，使用完全确定性的代理策略而不是实时模型调用，将一个变量（关系密度）与通常与之混淆的所有因素隔离开来。
我发现：代理之间更多的通信路径并不自动意味着更好的多代理性能。在整个密度范围内，复苏保持平稳。但路径本身并没有保持平坦——随着密度的增加，网络使用的边缘比例不断缩小。更有用的工程问题不仅仅是存在多少个连接。这是它们中实际携带信息的数量。
这不仅仅是一个概念性的提案。它是一个具有可测量、可重复行为的工作系统。实验具有可重复性；计时数字仅在实际测量时报告。
我的假设
大多数人认为失败的多代理系统会出现提示问题。
您建立一个专业代理团队，将它们连接到松散的网格中，然后运行管道。您得到的不是最终的结果，而是无休止的循环、上下文漂移和耗尽的代币预算。直接的本能反应是重写系统提示或换成更大的法学硕士。
我怀疑真正的罪魁祸首是结构性的：代理之间开放沟通渠道与可能渠道总数的实际比率。
在图论中，该比率就是关系密度。对于具有 N 个节点和 E 个边的有向图：
D = E / (N * (N - 1))
采用 8 代理设置：您有 56 条可能的定向通信路径。密度只是控制这 56 条路径中实际打开的数量的旋钮。我想看看调整单一结构杠杆是否会从根本上改变网络的性能，以及更多的连接是否实际上更好。
这是给谁的
何时跳过此内容：
构建实验
这是端到端的管道：