JetBrains AI

Mellum2 从零开始训练，专为实际部署而设计，旨在用于软件工程系统中的路由、问答、子智能体和私有 AI。 今天，我们将开放 Mellum2 的源代码，它是一个 120 亿参数的模型，专为解决生产 AI 中的延迟、吞吐量和成本这三大最棘手的挑战而设计。Mellum2 从零开始构建，基于 Apache 2.0 许可证发布，为您的基础架构提供高性能、高性价比的替代方案。 Mellum 最初用于代码补全；如今已演进为可以同时处理自然语言和代码。它现在是一款多功能工具，能够为现代 AI 工作流中的路由、总结和中间推理步骤提供支持。 无论您想要试验、微调还是大规模部署，Mellum2 都可以随时在您自…

本系列的前几篇文章： 使用 Kotlin 构建 AI 智能体 – 第 1 部分：极简编码智能体 使用 Kotlin 构建 AI 智能体 – 第 2 部分：深入探讨工具 使用 Kotlin 构建 AI 智能体 – 第 3 部分：受到密切观察 使用 Kotlin 构建 AI 智能体 – 第 4 部分：委托和子智能体 智能体最终会耗尽上下文。这种情况发生时，智能体会崩溃，你会在任务进行到一半时丢失所有数据。 从第 1 部分以来，我们运行的都是 GPT-5 Codex 。它在 SWE-bench Verified 上的得分为 0.58。接下来我们尝试了 Claude Sonnet 4.5，它的得分…

构建智能体很奇妙。你不是在编写执行任务的代码， 而是在编写让 LLM 有能力执行任务的代码，LLM 决定该做什么。 什么是智能体？ 智能体就是一个 LLM，它会循环调用你的函数，直至确定任务已完成。 这种转变需要一些时间来适应。你赋予智能体读取文件的能力，智能体决定要读取的文件和读取时间。你可能预计智能体会最先读取主文件， 但智能体却先读取三个测试文件，以了解相关模式。你没有告诉智能体这样做， 但它就是这样做了。 那么，你应该赋予智能体哪些能力呢？ 赋予智能体的能力过多，它将无法做出正确选择。赋予智能体的能力过少，它将无法完成任务。找到平衡点意味着不断尝试，观察哪里出了问题，然后再进行调整…

在上一篇文章中，我们了解了如何构建具有列表、读取、写入和编辑能力的基本编码智能体。今天，我们将深入探讨如何通过在 Koog 框架内创建附加工具来扩展智能体的能力。我们将以构建 ExecuteShellCommandTool 为例，教会智能体运行代码，并形成实际工程所依赖的反馈回路：运行代码、观察失败，并根据实际输出改进代码。 尽管 LLM 通常擅长避免语法错误，但在处理集成问题时仍存在困难。例如，它们有可能会调用不存在的方法、遗漏导入，或仅部分实现接口。编译和运行代码的传统方式会立即暴露这些问题。但有了少量的额外提示，我们可以促使 LLM 运行小规模测试来验证此类行为。 那么，我们如何构建这类…

本系列的前几篇文章： 使用 Kotlin 构建 AI 智能体 – 第 1 部分：极简编码智能体 使用 Kotlin 构建 AI 智能体 – 第 2 部分：深入探讨工具 读完两篇文章，我们知道，我们的编码智能体已经能做很多事情了。它可以探索项目、读写代码、执行 shell 命令和运行测试。我们在上一篇文章中添加了一个完成定义 (DoD)，使其拥有所需的反馈循环，现在，智能体会进行迭代，直至所有测试都通过，而不是由它自己决定何时完成。 我们应该庆祝一下，对吧？ 是，也不是。 随着智能体能力越来越强，调试变得更具挑战性。每个工具都会增加难度。DoD 循环增加了更多的调用和 token。可能需要…

本系列的前几篇文章： 使用 Kotlin 构建 AI 智能体 – 第 1 部分：极简编码智能体 使用 Kotlin 构建 AI 智能体 – 第 2 部分：深入探讨工具 使用 Kotlin 构建 AI 智能体 – 第 3 部分：密切观察 在上一篇文章中，我们了解了如何设置跟踪，这给我们提出了两个新问题：根据此工具提供的信息，我们应该进行哪些尝试？ 我们可以利用智能体的观察结果改进智能体的哪些部分？ 我们最初的想法是试验子智能体，或者更具体地说，使用 find 子智能体。这将让我们有机会了解，Koog 如何使实现子智能体等常见模式变得更加容易。我们的假设是，find 子智能体可以在保持甚至提升…

每位开发者都深知这样一种权衡： 你可以走捷径，解燃眉之急却给未来埋雷；也可以选慢路，耗时费力但能赢得长久的稳健。 随着 AI 智能体（AI Agents）在实际工作流中的普及，这一困境愈发明显。唯快不破的诱惑固然很大，但如果缺乏信任支撑，这种“快”往往得不偿失——不仅省不了时间，反而要花更多精力去收拾烂摊子。 核心问题不在于智能体跑得有多快，而在于它们干活靠不靠谱。只有当“信任”与“速度”形成合力，生产力才会真正爆发。而在这一公式中，信任是不可或缺的起点。 AI 智能体：超越自动化，成为真正的“队友” AI 智能体不只是软件，它们是将目标转化为行动的协作伙伴。 它们之所以超越了简单的自动化脚本…

如果您曾尝试过构建由多个 AI 智能体组成的系统，很可能会遇到难题。 一开始很简单：您有一个智能体负责撰写博文，另一个智能体负责校对博文，或许还有第三个智能体负责建议或生成图像。 单独来看，它们都很高效。 但要让它们协同工作呢？ 往往这个时候就会开始出现问题。 每个智能体都有自己的一套“语言”：一个使用不同的 API 接口，另一个有自己的消息格式，而且它们可能都有特定的身份验证要求。 要让它们彼此通信，就意味着需要为每一个连接编写自定义的集成代码。 结果，您无法专注于让各个智能体变得更智能、更快速或更有用，而是被困在为它们搭建沟通桥梁上。 A2A 的作用：跨智能体通信层 这就是 Agent2A…

Koog 是 JetBrains 的开源框架，用于在 Kotlin 中构建 AI 智能体，有一天我测试了以它为基础构建的智能体。 我给智能体投喂了一个来自 SWE-bench-Verified 的任务，这是一个真实世界 GitHub 问题，测试 AI 是否真的能够编写代码。 前 100 条消息看起来一切顺利。 智能体系统地浏览代码库、识别 bug、编写测试用例，并尝试修正问题。 但随着对话的深入，它遇到一个根本性限制：上下文窗口。 每个 LLM 都有上下文大小上限（可以同时处理的文本总量）。 当智能体的对话历史记录接近上限时，你需要想办法压缩。 单纯截断旧消息会丢失关键信息，粗略的总结往往又会…

我们为 Kotlin 社区带来了一些好消息！ 在今年的 KotlinConf 上，我们将推出 Koog，这是一个创新型开源智能体框架，可以帮助开发者使用现代 Kotlin DSL 在 JVM 生态系统中构建 AI 智能体。 我们设计 Koog 是为了向开发者提供创建智能、自主代理所需的工具，并让他们能够像使用 Kotlin 一样轻松高效地进行日常开发。 这是将 Kotlin 打造成一流 AI 语言的重要里程碑，我们非常期待社区构建的成果。 尝试 Koog 我们为什么要为 Kotlin 构建智能体框架 起初，我们都对聊天助手和 LLM 的潜力感到震惊。 但随着这些模型的发展，它们的能力显然远远超…

如果您一直在跟随我们的历程，您可能已经阅读过我们最近的博文完成不可完成的补全任务：JetBrains IDE 中 AI 补全的现状。 在那篇文章中，您可能还记得这张很酷的代码补全图表。 4 月份出现了些有趣的变化：我们的接受率有所上升，显式取消率（explicit cancel rate）有所下降。 在这篇博文中，我们将分析为什么以及如何在不重新训练生成模型的情况下获得这样的结果。  不能只依靠 LLM 提供代码建议的 LLM 是 AI 代码补全的核心，但不是全部。 幕后有很多事在发生，特别是在插件方面，例如决定： 何时显示建议。  建议应该是单行还是多行。 建议应该显示还是隐藏 – 例如…

代码补全一直是 JetBrains IDE 中的突出功能，可以帮助开发者更快速、更智能地编写代码，并减少错误。 但要是它能做的更多呢？ 要是它不但可以预测下一个元素，还可以预测整行代码，甚至可以补全代码块呢？ 这就是我们一直以来努力的方向。 我们在 AI 方面投入了大量时间和精力，因此我们的代码补全功能已发展得无比强大，比以往任何时候都更精确、快速和智能。 在这篇博文中，我们决定分享 JetBrains IDE 中 AI 代码补全的原理，它的发展历程以及即将取得的激动人心的进展。 我们开始吧！ 什么是 JetBrains AI 代码补全？ JetBrains 通过两种方式提供 AI 代码补全：…