JetBrains AI

向企业后端添加 AI 智能体不应以破坏架构为代价。如果您的核心系统是使用 Java 构建的，编排 LLM 并不需要您引入单独的 Python 微服务或重写技术栈。 今天，我们正式发布 Koog for Java。Koog 最初是为了满足 JetBrains 自身活动扩展需求而构建的，它使用结构化、可观测且具备容错能力的工作流取代了不可预测、临时的提示更改方法。 如今，JVM 最强大的智能体框架之一拥有了完全符合 Java 惯用风格的 API。您的 Java 团队可以直接在现有后端中构建可靠的 AI 智能体，借助流畅的构建器风格 API、线程池执行器和原生 Java 抽象，完全不需要担心任何与 …

Tracy 是一款开源 Kotlin 库，可以在几分钟内为 AI 赋能的应用程序添加生产级可观测性。它可以帮助您调试故障、测算执行时间，并跟踪模型调用、工具调用和您的自定义应用程序逻辑中的 LLM 使用情况。归根结底，全面的可观测性确保您可以获取了解真实应用程序行为的准确数据，从宏观趋势到细粒度跟踪分析性能，为全面的在线和离线评估提供支持。 Tracy 与常用的 Kotlin/LLM 技术栈（包括 OkHttp 和 Ktor 客户端，以及 OpenAI、Anthropic 和 Gemini 服务）无缝协作，它的底层基于 OpenTelemetry 构建。此架构可以确保开发者全面灵活掌控跟踪数据…

随着 AI 技术的飞速演进，开发者对智能编程工具的需求已不再局限于单一的助手，而是一个能够深度集成、灵活切换，且符合本地使用环境的协作空间。JetBrains 现已携手 Qoder、TRAE 和 CodeBuddy，一起构建一个开放的 AI 编程新生态，更有 ACP（Agent Client Protocol） 带来的全新智能体的自由选择。 访问专属页面了解更多 一站式体验不同工具带来的卓越 AI 代码体验 凭借深厚的 IDE 积淀，JetBrains 现已将“深度集成”从代码扩展至 AI 生态。通过 JetBrains 插件市场，开发者可一键启用 Qoder、TRA…

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 都有上下文大小上限（可以同时处理的文本总量）。 当智能体的对话历史记录接近上限时，你需要想办法压缩。 单纯截断旧消息会丢失关键信息，粗略的总结往往又会…