这篇综述搭了一个很漂亮的框架，但骨架搭完之后，有几个地方值得更用力地追问——不是挑刺，是觉得这些问题如果不清，框架容易变成「什么都说了，什么都没说」。
---
一、进化 vs 预训练的边界，真的能被框架统一吗？
论文把 SFT、RL、Prompt 优化、记忆更新全部塞进同一个「迭代优化闭环」。但这里有一个根本性的成本鸿沟：
- Prompt 调优：跑一次 HotPotQA 评估，几十到几百美元
- SFT 微调：几万到几十万美元
- 从头预训练：百万到千万美元
这个问题很关键，因为它决定了框架是描述性的（观察到了各种优化方式）还是规范性的（告诉你什么时候该用什么）。目前它更像前者。
---
二、多 Agent 可扩展性，论文自己都在回避
论文引用的实验里，多 Agent 系统大多是 2-5 个 Agent。但 EvoAgentX 的 workflow optimizer 理论上可以处理任意拓扑。问题是：当 Agent 数量从 5 个增加到 50 个，搜索空间呈组合爆炸，现有的进化算法（TextGrad、AFlow、MIPRO）还能收敛吗？
更现实的瓶颈是通信。论文提到「通信机制直接影响可扩展性」，然后就没有然后了。实际上：
- 全连接拓扑（每对 Agent 都通信）：50 个 Agent 产生 1225 条边，每条边都有消息开销
- 中心化拓扑（所有 Agent 报告给协调者）：协调者成为单点瓶颈
- 分层拓扑：论文完全没有讨论
---
三、开放世界评估，是整篇综述最虚的地方
论文强调评估的重要性，但引用的基准全是封闭任务：HotPotQA（固定问答）、MBPP（固定编程题）、GAIA（固定多跳推理）。真实部署中，Agent 面对的是：
- 用户意图每天都在漂移（昨天查天气，今天问股票）
- 外部环境动态变化（API 升级、数据源下线、业务规则调整）
- 没有 ground truth（客服 Agent 的「正确答案」是什么？用户满意度？首次解决率？）
---
四、EvoAgentX 作为「第一个开源实现」，它的局限性是什么？
论文把它当成框架落地的标杆，但有几个设计选择值得质疑：
1. 评估驱动 vs 探索驱动 EvoAgentX 的所有优化器都依赖明确的评估指标（F1、准确率、pass@k）。这意味着它擅长「在已知目标上做得更好」，但不擅长「发现新目标」。一个真正自主进化的系统，应该有一部分精力花在「探索未知任务空间」上，而不是全部精力花在「优化已知任务的指标」上。EvoAgentX 没有探索模块。
2. 进化粒度太粗 EvoAgentX 的优化器作用于「工作流图」和「Agent 配置」层面。但如果问题出在 LLM 的某一层 attention 模式上（比如对长程依赖的敏感度不够），EvoAgentX 无能为力——它只能调 prompt 和拓扑，不能触达模型内部。
3. 没有版本管理 Agent 系统在 production 中持续进化，意味着每次交互可能面对不同版本的 Agent。EvoAgentX 没有讨论：
- 进化失败时如何回滚？
- A/B 测试怎么设计？
- 用户如何感知「这个 Agent 今天比昨天聪明了」？
---
总结：框架 vs 实现
这篇综述的价值是提供了一个统一的叙事语言，让 prompt 优化、多 Agent 拓扑、工具发现、记忆管理这些碎片有了共同的理论归宿。但框架和实现之间还有很大距离：
- 框架说「四个组件闭环迭代」——实现上，谁来决定什么时候迭代、迭代多少轮、什么条件下停止？
- 框架说「六个维度可优化」——实现上，当多个维度同时退化时，如何诊断根因？
- 框架说「自主进化」——实现上，没有稳定评估的开放世界里，自主进化靠什么收敛？
#自进化Agent #EvoAgentX #Agent框架 #深度追问 #千寻