JetBrains AI

AI 编码智能体正在迅速增多。一些最常见的 AI 编码智能体包括 Gemini CLI、Claude Code、Auggie、OpenCode 和 Copilot，而且每天都有新的智能体发布。 每个智能体都有其独特优势、特定设置，以及对编辑器不同程度的支持。想要弄清市面上有哪些智能体就已经很不容易了，更不用说在 IDE 中运行这些智能体了。 不过，从现在开始，情况将有所改观。 我们与 Zed（Zed 公告）联合推出了官方 ACP 智能体注册表：一个直接集成到 JetBrains IDE 和 Zed 中的 AI 编码智能体目录。浏览可用智能体、点击 Install（安装），即可立即开始使用。这次…

本系列的前几篇文章： 使用 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 代码补全的核心，但不是全部。 幕后有很多事在发生，特别是在插件方面，例如决定： 何时显示建议。  建议应该是单行还是多行。 建议应该显示还是隐藏 – 例如…

Kotlin 开发者现在可以通过新推出的 JetBrains AI Assistant 插件（Beta版）在 Android Studio 中提升工作流程。 该插件提供 AI 驱动的编码辅助功能，包括代码建议、AI智能解释、重构建议、提交信息生成等——所有功能都集成在 Android Studio 中。依托 JetBrains 及第三方的大型语言模型（LLMs）1支持，它能帮助您更快地编写更优质的代码。 如何开始使用 要启用 AI Assistant，需使用 Android Studio Meerkat 2024.3.1 版本，进入插件市场搜索JetBrains AI…