机器学习团队里最枯燥的活大概就是调参跑一轮实验看曲线改学习率再跑一轮。网格搜索、Optuna 这类工具解决了一部分自动化问题但它们只看指标数字看不懂日志里loss 震荡但验证集在涨这种信息。现在有人想用大模型干这件事——让 LLM 读日志、分析指标、自己提出下一轮配置。AgentHPOBench 这个新基准就是来测这种能力的。基准测的是迭代过程不是单次答案这个基准包含 30 个可执行的机器学习任务覆盖七个研究领域。每个任务从一个已验证的基线运行开始然后由代理进行多轮干预每一轮干预前代理需要分析当前配置、指标和日志提出新的方案执行后继续下一轮。注意这里的设定——它不是让模型直接给出最优参数这种一次性答案而是要求模型在一个真实的实验循环里持续工作。这个设计本身就说明了问题。过去的评估基准只测静态的代码生成或者最终答案正确性不涉及实验迭代过程。而调参这件事的本质是过程你看到的永远是不完整的训练日志需要在不确定中决定下一步怎么走。AgentHPOBench 把过程变成了可测量的对象。结果单轮可以持续迭代不行测试结果表明当前主流代理在实验优化方面具备一定能力但在三个地方暴露了明显局限持续迭代优化、复杂日志诊断、稳定逼近目标性能。单轮干预表现尚可说明模型确实能根据当前状态提出合理的配置调整。但把任务拉长到多轮问题就出来了模型很难持续地逼近目标性能在复杂日志诊断上容易被干扰信息带偏稳定收敛的能力明显不足。对做机器学习平台的人来说这个结果不算意外但值得重视。调参之所以难自动化难点从来不在根据指标选参数这一步——这一步 Optuna 早就做得不错了——而在理解日志背后发生了什么。训练日志里的信息密度很高早期 loss 下降、梯度消失、过拟合信号混杂在一起模型容易抓住表面特征而错过真正的问题。那恰恰是 LLM 理论上最擅长、实际测试中最不稳定的部分。谁会被这个基准影响短期看这个基准影响的是 HPO 工具链的评估方式。过去衡量一个自动调参工具看最终指标就够了现在多了一个维度它能不能在真实实验循环里持续优化。这对 AutoML 平台、MLOps 工具的设计者是个直接信号——如果代理的持续迭代能力不达标把调参完全交给 LLM 的方案就要重新评估。但也有个反方向的问题值得注意这个基准里目标性能如何量化、代理是否真的稳定逼近还是只在部分任务上表现好论文里没有给出明确标准。也就是说基准测出了持续迭代是短板这个结论但短板到底多短还缺乏更细的度量。对企业团队而言比较务实的用法是把它当作选型参考如果你的工作流里有大量需要人工看日志的调参环节可以先拿这个基准的设定去验证候选模型的多轮表现而不是只看它单轮调参的演示效果。目前没有任何公开信息说明主流代理在真实业务日志上的持续优化表现这类数据大概率要等基准被更多团队使用之后才会出现。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版