SpringForAll社区

菜单

TempGo
发布于 2025-11-04 / 4 阅读
0
0

Spring AI Agents 与 Spring AI Bench 简介

#spring-ai

我想介绍两个新项目，它们属于 Spring AI Community GitHub 组织：Spring AI Agents 和 Spring AI Bench。这两个项目聚焦于使用代理式编码工具——也就是你在企业里很可能已经具备的那些工具。

到了 2025 年，AI 编程代理已经成熟到必须认真纳入企业 Java 开发与通用 SDLC 任务的考量。像 Claude Code、Google 的 Gemini CLI、Amazon Q Developer、OpenAI 的 Assistants 等 CLI 工具，是来自大型 AI 实验室的代表，同时也有不少初创与开源选择。这些代理式编码工具能够推理架构、理解大型代码库，并有望帮助开发者更快地交付软件。它们常以“人机协作”的方式使用，但也可以被指示自主执行，直到判断目标已经完成。

Spring AI Agents 定义了一个轻量但强大的可移植抽象：AgentClient。它充当调用自主 CLI 代理的一致接口，使开发者能使用现有的代理式工具，同时保持灵活性，避免被单一厂商锁定。

然而，AgentClient 只是有效使用代理式工具所需的开发者工具箱中的一部分。Spring AI Agents 还提供以下抽象，组合使用可产生更好的效果：

  • 目标（Goals）： 代理要完成的任务，例如提升代码覆盖率、为 issue 打标签、或审查并合并拉取请求。
  • 上下文（Context）： 代理进行推理所依赖的数据与环境——源代码、日志、结构化数据集与文档。
  • 工具（Tools）： 在需要时暴露给模型可调用的自定义能力，通常通过 MCP（Model Context Protocol）提供。
  • 评审（Judges）： 依据预设标准验证结果并评估质量的评估者。可以是确定性的（如代码覆盖率数值），也可以由 AI 驱动（LLM-as-Judge 模式）。
  • 沙箱（Sandbox）： 代理安全且可复现地执行工作的抽象。目前支持本地执行与 Docker 容器。

配套项目 Spring AI Bench 是一个用于评估代理在以目标为导向的企业工作流上的基准套件。它衡量不同代理完成目标的有效性，可视作通过 Spring AI Agents 运行任何代理的测试平台。

我们做这个项目的动因来自于对现有代理式基准的调查。我发现它们主要聚焦 Python，并且只覆盖“为 GitHub 问题提供代码补丁”这一单一用例。你会在文献中看到这样的模式：SWE-bench 在其静态、精心策划的 Python 问题集上表现亮眼；然而一旦引入新的问题集，分数就会显著下滑。在 SWE-bench Verified 上，代理在静态 Python 集的得分为 60–75%；到了 SWE-bench-Live，同样的运行降至 19%——3× 的下降。在 SWE-bench-Java 上，Java 任务的成绩约为 ~7–10%，而在同一家族基准的 Python 上则约为 ~75%，显示出一个数量级的差距。对工程管理者而言，分数的剧烈波动意味着决策也会随之波动。

这并不意味着代理能力弱，而是意味着我们用来衡量的尺子已经过时。SWE-agent 是数千行的 Python 代码，但仅约 100 行的 mini-SWE-agent（一个带聊天记忆、只提供 bash 这一个工具的简单代理循环）也能取得与 SWE-bench 相当的结果。事实证明，我们缺少能够评判当下与未来“现代 CLI 代理工具”能力的基准。

早期运行结果令人鼓舞：在覆盖上百个领域特定标签的多标签 issue 分类中，得分达到或超过已发表的 F1；PR 合并代理已在 Spring AI 代码库上处理了数百个拉取请求，生成结构化报告——风险评估、架构说明、回溯分析——显著缩短了评审时间并提升了一致性。简单的代码覆盖率基准还揭示：尽管领先模型都能达到同样的覆盖率数字，但在代码质量与遵循指令的程度上，它们彼此存在差异。

接下来：两个项目目前都在 Spring AI Community 组织中孵化。快照版本已发布到 Maven Central。我们也在与 Developer Productivity AI Arena (DPAIA) 的发起人合作，该倡议正是为解决本文提出的问题而创建。

随着我们从“代理之年”迈向“有效使用代理的新纪元”，Spring AI Community 期待你的反馈。

参考资源

项目：

研究参考：

Spring AI Agents ...

评论