半夜刷 arXiv，cs.MA 分类下出来一篇，《Agentic Societies Need a Social Harness》，9 月 15 号收的。摘要里有句话：即使诚实且有能力的代理也常常无法取得满意结果。
我不困了。不是因为激动。
这话我上个月刚在电话里说过一遍。区别是他们在实验环境，跑失败重跑一次就行；我这边跑失败，pager 响，起来的是我。
说对了什么
先把公道话讲在前面：多 agent 跨信任边界协作，每个都是诚实的，能力也都够，但在现有的 harness 和通信原语下面还是跑不出令人满意的结果。再往里塞一个坏的、或者干脆是残的，它能顺着通信层的缝把整场协作拖住，顺便把结果带偏。
这需要论证吗。
我接过的那些电话，一半以上不是因为哪个环节不会做，是因为两个都会做的环节对不上。这句话我在 runbook 里写过、在复盘会上念过、在上线评审会上拍过桌子——没用。工具一换，大家又觉得这次不一样了。
论文真正说的是件旧事：每个组件单独测都及格，不代表凑一块不打架。分布式系统里这道理老得掉牙。现在只是把组件从服务换成了 agent，把 RPC 换成了消息原语，然后重新惊讶了一遍。
我本来是带着偏见看的
看到 social harness 这个词就有火。每次有人给老问题起新名字，我默认是换皮。更别说 harness 本来就指给被测对象兜底的那套脚手架，现在要给"agent 之间怎么打交道"也造一套。
往下翻，我改了一半口风。
他们说的三层目标，翻成我这边的话：拦掉几类明摆着的失败；消息在路上时就能判出这条无效；事后能查能追责。翻完你会发现，这不就是准入控制、可观测性、审计日志。
老配方。老配方不代表可以不做——我们这边 agent 到 agent 的通信现在是裸的。没有 trace，没有 message 级的日志。出了事只能把两边的日志拉出来对时间戳，对不上就靠猜。这个我得认，论文戳到的位置是准的。
我不认的是它默认的那个解
再加一层。
这是我这些年最怕听到的一句话。每加一层，你拦住一类故障，同时给未来埋一类新的。护栏本身也是系统，是系统就会挂，会挂就得有人接电话。论文没写的那半句是：这套 social harness 谁运维、谁 on-call、谁写 runbook、谁在凌晨三点判断"这条消息是垃圾还是我配置写错了"。
那个冤种，还是我。
说句实话，我到现在也没想明白这类中间层该由谁来签字放行。它拦消息，拦多了协作效率掉，拦少了等于没装。这个阈值不是调出来的，是踩出来的。
扯远了，回到故障本身
论文写得最实的是这一半：agent 社会里有故障或恶意的一方，能利用通信漏洞拖延协作、影响结果、顺便去追别的目标。搁在人身上就是——你那些代理背后坐着的是目标只部分一致的多个委托人。
这不是新问题，这是代理人问题，外包时代就有了。甲方乙方目标从来不完全对齐，中间那个对接的人就是夹心饼干。现在只是把对接的人换成了消息管道，把扯皮换成了 token。
换成模型以后的区别在哪？人类乙方至少怕丢合同，会自己收着点；agent 不会。它没有利益要维护，也没有脸要顾及，所以对护栏的要求只会更高。这不是我替他们说话，是算完账发现更麻烦。
真正的问题不在多一层，而在这层里装什么、谁来填。论文提的那些目标，翻译过来是"需要研究"。那就按"现在还没有"来用。
留两句能落地的
也给自己和还在值班的同行留两句。别让 agent 之间的通道不落痕迹地上生产——上之前先答这三个：这条路上有没有 trace；出事能不能按消息粒度对齐时间线；被拦下的消息有没有地方落盘。三条答不上来的，别让它自己去找它自己。
至于论文本身，我给它留个位置。不是因为它发现了什么，是因为它把一件我讲了很多年、同龄人已经听腻的事，用新名词重新包了一遍。
换皮。但这次的皮下面，包的是真货。