Agent 协议之争这周有个很妙的注脚：Claude Code 一个请求支持 AGENTS.md 的 issue 拿到了 375 分。协议还没定出胜负，但战场已经下沉到一个 markdown 文件的命名约定上了。我的判断：现在选边站是赌博，把协议封装成适配器层才稳——但反面也成立，抽象层有成本，别不加思考地加。
AGENTS.md 是个信号，不是答案
AGENTS.md 连标准都算不上，就是个文件名。但它正被越来越多的 agent 工具读起——大家都需要在一个仓库里告诉 agent"这里该怎么做"。这跟 robots.txt 之于爬虫年代很像：没人给它立法，它靠"大家都不反对"成了事实接口。
这恰好说明了协议之争的真实处境。那篇 Software 3.0 的论文 讲架构正从三件套转向 storage / models / agents 三层。agent 成了软件的一层，agent 之间怎么互相读懂就是基础设施问题。而现实是，连一个约定文件都没统一——更别提什么消息总线了。这个礼拜还有篇论文在盯 coding agent 到底查哪些文档、怎么查，研究者已经在把文档当成协议来研究了。
别押注，加适配器
现在市面上在跑的有几套：MCP 算半个事实标准，A2A 还在找生态位。我的判断是：外面在打，你别下场。
内部用自己的消息结构，对外挂适配器。你想接别人的 MCP server，就写一个 mcp→internal 的翻译层；你想让别的 agent 调度你，就写一个 internal→他们协议的序列化器。这是 JDBC 年代就验证过的玩法：你写 JDBC 不是因为喜欢它，是因为换数据库不用重写业务代码。
我最近在看 Seed 这种 self-modifying 的 agent harness——这类小项目每周都有两三个，但大多只在自己的协议里打转。真要长期干，把对外接口做成薄薄一层适配器，标准换了，你改 50 行而不是重构整个 agent 循环。
适配器不是免费的
反面我也认：多一层抽象就多一层调试成本。报错栈里多一道"翻译层到底改了什么"的谜。如果你的 agent 只在内部跑，两个 agent 之间就直接传消息结构，别在内部发明协议——定义一个 dataclass 传就是了，抽象多了是负担。
值得加适配器的时机只有一个：你要真的对接外部生态。比如你的 agent 要去消费第三方工具，或者你要发布一个 agent 让别人来调。这时候没有适配器，你就被锁死在某个协议上。内部两个 agent 通信，不值得。
现在大部分团队连一个 agent 都没跑顺。为"agent 之间的协议"提前设计和押注，不如先把对外边界封住，内部怎么朴素怎么来。
标准是沉淀出来的
回头看 AGENTS.md：它就是那个"虽然丑但足够简单、没人反对"的东西。协议之争的答案大概率不会来自某个更聪明的协议设计，而是一个足够低门槛、大家懒得反对的约定。
也许 6 个月后这个判断会被打脸，到时候我改口。