先说一个你大概率遇到过的场景。
你有一批 Agent 在跑。可能是十几个，可能是几百个。某天上游一个 API 改了返回结构——多了一层嵌套，或者某个字段从字符串变成了对象。没有大新闻，对方甚至在更新日志里提过。
然后你的 Agent 全挂了。不是一个，是所有调用这个接口的都挂了，在同一分钟。
你去查日志、改解析逻辑、重新部署。两小时后恢复。团队松一口气，把这件事记成一次"上游变更导致的故障"。
我想说的是：这不是故障。这是架构的正常输出。
一、被冻结的边界
绝大多数 Agent 系统的能力，是在部署那一刻确定的。
你写好 prompt、挂好工具列表、定好输出契约，然后发布。从这一秒开始，这个 Agent 能做什么、怎么理解外部世界，就固定了。它可以很聪明——它可以推理、可以规划、可以调用二十个工具——但它对外部世界的假设是硬编码的。
上游一变，假设就错了。而 Agent 自己没有任何机制发现这件事、更没有机制修正它。它会继续用错误的假设自信地执行下去，直到有人看见告警。
所以真正的问题不是"API 变了"，而是：
能力边界在部署时被冻结，而环境不会为你冻结。
这句话听起来像废话，但它的推论很不舒服：你的系统能不能活下去，取决于人类修补的速度能不能跟上环境变化的速度。
二、为什么打补丁这条路会断
我们算一下这个赛跑（数量级估算，不求精确）。
设你有 n 个 Agent，它们依赖 m 个会变的外部条件——API 格式、端点地址、认证方式、数据协议、模型的输出习惯、第三方页面的 DOM 结构。每一个 (agent, 条件) 组合都是一个潜在的断裂点。
维护成本大致是 O(n × m)。
n=10, m=10：100 个断裂点。一个人盯得住。n=100, m=50：5,000 个。需要一个小组，加一套监控。n=1000, m=100：100,000 个。这时候你需要的不是工程师，是运气。
这里要先接一个明显的反驳："变更是同质的，一次修能覆盖一大片。" 对，很多时候确实如此——一个共享的 SDK 封装层能把一次上游变更的影响收敛成一处改动。这会大幅压低常数项，但它压不掉复杂度里的那个乘号：封装层本身也是一个会过期的假设，而且它一旦错了，错的是全部 n 个 Agent，不是一个。你把断裂点变少了，同时把每个断裂点的爆炸半径变大了。
而且这条曲线有个恶劣的性质：它不是平滑退化的。在断裂点数量超过团队反应能力之前，一切看起来都很好——直到某天你同时收到七个告警，而它们的根因是三件不同的事。
更关键的是：这个成本增长是结构性的，不是能力问题。 不管你雇多强的人、写多好的监控，只要"发现—诊断—修补—重新部署"这条链上有人类，复杂度就还是 O(n × m)，你只是把常数项压小了一点。
三、现有的三个答案，都没解决这件事
答案一：用更强的模型。
更强的模型能更好地推理，但它改变不了集成边界。一个前沿模型驱动的 Agent，如果它的工具描述里写着"这个接口返回一个字符串数组"，而接口现在返回的是对象数组，它一样会失败。智能不等于适应性——尤其当假设被写死在它的上下文里、而它没有权限改写自己的时候。
答案二：接更多的工具，上 MCP。
MCP 解决了"Agent 怎么发现和调用工具"这个真问题，而且解决得很干净。
值得先说清现状：MCP 生态的质量评估已经相当成熟——Scale 的 MCP-Atlas 排行榜、MCPToolBench++（arXiv:2508.07575）、给上百个 MCP 客户端算综合质量分的 MCPCrawler，以及安全侧的工具投毒基准 MCPTox（arXiv:2508.14925）等，构成了一套快速成熟中的评测体系。
但把这套体系看清楚之后，问题反而更清晰了：
它们全是离线基准，产出的是给人看的排名。它们不能让一个正在运行的 Agent，在半夜自己换掉一个刚刚坏掉的能力。
评测 ≠ 运行时选择。一个跑在生产里的 Agent，在上游变更发生的那一刻，手里没有任何机制去问"我这个工具还有效吗"、更没有机制去执行"换一个"。基准告诉研究者哪个工具在测试集上更好；它不改变部署之后那条链上依然站着一个人类。
MCPTox 还顺手证明了另一件事：工具投毒是已被系统性记录的真实攻击面，不是假想。这一条待会儿会回来。
答案三：更勤快地打补丁。
这就是 O(n × m)。它能撑很久，撑到撑不住的那天，而且失效是突然的。
四、真正的矛盾
三个答案都不奏效，是因为它们都在同一个前提下工作：
我们在用静态的、集中式的方法论，运营一个本质上动态的、分布式的系统。
"部署"这个动作本身，假设了世界是稳定的：你把一份确定的逻辑放到一个确定的环境里，然后它就该一直工作。这个假设在单体软件时代基本成立，在 Agent 时代不成立——因为 Agent 的价值恰恰在于它和一个不断变化的外部世界打交道。
所以出路不是"管理得更好"，而是换个东西来管：
放弃"管理"的幻觉，去建"进化"的基础设施。
五、一个能进化的系统需要什么
如果承认上面这个判断，那么答案的形状就被约束死了。它至少需要四件事：
1. 能力必须是可替换的单元，而不是被编译进 Agent 的一部分。 如果修一个能力需要重新部署整个 Agent，你就还在 O(n × m) 里。能力得能在运行时热替换。
2. 替换必须经过验证，不能直接上。 可热替换 = 可被污染。一个能自己更新能力的 Agent，如果没有准入检查，就是一个自动化的安全事故。上一节那个 MCPTox 不是理论顾虑——工具投毒已经有专门的攻击基准了。新能力必须先在隔离环境里跑过静态分析和沙箱模拟，再小比例灰度，才能进主序列。
3. 系统必须知道哪个版本更好——这需要一个可计算的分数。 "更好"不能是人的判断，否则又回到人类瓶颈。你需要一个能持续评估的适应度函数，以及一条硬性的安全门槛：分数不够的，进不来。
4. 一个 Agent 学到的东西，必须能传给其他 Agent。 否则一千个 Agent 就要把同一个坑踩一千遍。个体的失败经验必须能变成全网的免疫记忆。
注意这四条不是我发明的功能列表，它们是从"环境会变而人跟不上"这个前提里推出来的。任何想解决这个问题的方案，都绕不开它们。
六、别人做到哪了
这个问题不是我发现的。自演化 Agent 的综述（arXiv:2508.07407）开篇的判断和本文第一节如出一辙：多数 Agent 系统依赖手工配置，部署之后保持静态，因而限制了适应能力。2025 年以来，这是个相当活跃的方向。
差异确实存在，而且可以说清楚。 离我最近的一个工作是 Agent libOS（arXiv:2606.03895）：它做能力控制层、静态验证、沙箱执行——上面第 1、2 条它都覆盖了，而且做得比我扎实。但它明确不做适应度评分，也不做竞争性选择，走的是"确定性策略执行 + 形式化验证"的路线。换句话说，它保证 Agent 不做坏事，但不回答"哪个版本更好"。
在竞争这一侧，CATArena（arXiv:2510.26852）用迭代锦标赛评测代码 Agent 的进化能力，是最接近"竞技场"概念的先例。
所以我的第 3、4 条——可计算的适应度分数 + 能力在个体之间横向转移——是少数派路线，但不是无人提过的路线。这是下面这个项目该被放进去比较的坐标系。
七、我的尝试
过去一年我在做的东西叫 Rotifer Protocol，就是照着上面那四条建的。
名字来自蛭态轮虫，一种极端环境下的生存专家：干旱来了就近乎完全脱水进入休眠，能从真菌和细菌那里横向获取基因，还有种群层面的集体抗性。映射到软件上就是三件事：状态压缩与恢复、能力的横向转移、把个体故障转化为集体防御。
核心公理只有一条：代码即基因（Code as Gene）——逻辑单元必须是模块化的、可转移的、并且它的适应度可被评估。
架构分五层，从内核（唯一不参与进化的一层，负责执行不可违反的安全约束）、合成层、校准层、竞争与交换层，到集体免疫层。适应度用一个双指标函数 F(g) 持续评估，安全分 V(g) 作为硬门控，默认阈值 τ=0.3、V_min=0.7，另有一个多样性因子防止整个网络收敛到单一实现——这个机制借自种群遗传学里的频率依赖选择。
这个项目现在走到哪了
可以核验的（你可以自己去查，不用信我）：
- 协议规范已公开发布，CC BY-SA 4.0：rotifer-spec
- 开发环境
@rotifer/playground已发布到 npm，带 macOS arm64/x64、Linux x64、Windows x64 四个平台的原生二进制 - MCP 服务端
@rotifer/mcp-server已发布，让 Agent 可以搜索、比较、排序 Gene - 五层架构、适应度与安全门控的完整定义，都在公开规范里，可以逐条对着读
采用规模我不给数字：下载量不等于生产使用，等有第三方可核验的部署案例，再讲这一段。
关于自主等级。 参考实现目前跑在自适应级（AL2）：排名、评测、比较是自动的；任何会改变你机器或公共状态的操作——安装、发布、覆盖、回滚——都停下来等人批准。
这是个刻意的设计选择，也会招来一个合理的追问："停在 AL2 等人批准，那不还是人类瓶颈吗？"
一半是。AL2 没有取消人类，它把人类从"发现问题、诊断、写补丁、重新部署"这条长链，压缩到"批准或拒绝一个已经被评过分的候选"这一个动作。断裂点数量没变，变的是每个断裂点上人要做的事的体量——这是常数项优化。要真正打掉 O(n × m) 里那个乘号，需要更高的自主等级，协议里已经定义好了。我不在安全门经过第三方验证之前开它，因为一个能自己安装和发布的系统，装错一次的代价是不可逆的。
所以这不是一篇"我解决了这个问题"的文章：问题我认为分析清楚了，方案在验证中。 如果你觉得那四条推导有错，或者你有更好的第五条，我想听。
尾注
如果你也在跑 Agent 舰队、也在被上游变更反复打脸，去 playground 折腾一下，或者直接来找我聊：dev@rotifer.dev。
上面这些坑，大多是在给别人交付真东西的时候踩出来的。想看那些交付本身，去作品档案。