Kilo Code 与 Linear 集成指南：在 Issue 中用 @kilo 直接驱动云端 Agent 实现修复与跨仓库变更-平芜编程栈

Kilo Code 与 Linear 集成指南：在 Issue 中用 @kilo 直接驱动云端 Agent 实现修复与跨仓库变更

【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode

本指南围绕 Kilo Code 的 Linear 集成（Kilo for Linear）展开，讲解如何把项目管理的线性工作流与代码实现打通：在任意 Linear issue 评论区@kilo提及机器人，即可让云端 Agent 读取 issue 上下文、分析根因、实现修复并自动回链 Pull Request。读完本文，你将掌握该集成的能力边界、完整设置流程、典型使用场景、计费机制与排障方法。

一、Kilo for Linear 能做什么

Kilo for Linear将 Kilo Code 连接到你的 Linear 工作区，使你无需切换到编码工具，就能直接从项目管理平台触发实现、调试问题、调查 Bug。在任意 issue 上提及@kilo，机器人即开始工作。

Kilo Connect 是这一系列集成的总入口——它在 Kilo Connect 总览中被描述为"把 Kilo Code 带入团队已在使用的工具"的方案，Linear 与 Slack、GitHub 并列为其支持的三种聊天/工单入口，对应的触发方式分别是@kilo（任意 issue）、@Kilo（频道或私聊）与@kilocode-bot（issue 与 PR）。所有集成均从 app.kilo.ai 的Integrations页面配置。

1. 从 Linear 直接修复 issue

在任意 Linear issue 上标记机器人并让它实现修复：

@kilo please fix

机器人收到指令后会依次完成：

读取 issue 的标题、描述与全部评论；
启动一个 Cloud Agent 来实现解决方案；
在 Linear 中显示思考/处理中的动画（processing animation），让你看到它在工作；
将最终生成的 Pull Request 回链到该 issue，保持工单与代码的完整闭环。

2. 一次性跨多个仓库应用变更

当一次修复或升级需要同时落在多个仓库时，直接在一条指令中列明仓库名：

@kilo please fix this in the cloud, landing, and handbook repos

机器人会独立处理每个仓库：为每个仓库分别创建独立分支与独立 Pull Request，互不干扰，也便于分别评审与合并。

3. 请求机器人帮助理解 issue

在动手修复之前，可以先让机器人分析问题本身：

@kilo what could be the cause of this issue?

机器人会审视 issue 上下文，并在已连接的代码库中搜索，列出可能的原因。这一步尤其适合根因不明确、描述含糊的 Bug 报告——先诊断、后修复，能显著减少"修错地方"的返工。

二、工作原理：从 @kilo 到 Pull Request 的完整链路

Kilo for Linear 的执行流程可以拆解为四个阶段：

提及触发：在某个 Linear issue 的评论中提及@kilo；
上下文读取：Kilo 读取 issue 的标题、描述、标签以及整条评论线程；
云端 Agent 启动：一个 Cloud Agent 被拉起处理请求（处理期间 Linear 中会显示思考动画）；
结果回写：Kilo 给出回答，或打开一个包含实现的 Pull Request。

Kilo 创建 Pull Request 时，会将其回链到对应 Linear issue，保证工单、分析与代码修改始终可追溯。

从仓库文档结构看，这一"提及 → 读取上下文 → Cloud Agent 启动 → 产出回答或 PR"的机制与 GitHub 集成完全同源：GitHub 集成文档描述了相同的四步流程，并补充说明"对于实现类请求，机器人会创建新分支、提交变更并打开指向仓库的 PR"——在 Linear 场景下行为一致，只是入口从 GitHub issue 评论换成了 Linear issue 评论。这也是为何两类集成都要求预先连接 Git 提供商（GitHub 或 GitLab）：Cloud Agent 需要凭此克隆代码、创建分支并推送 PR。

三、前置条件

使用 Kilo for Linear 前，需要满足以下条件：

条件	说明
Kilo Code 账户	需要有可用 credits 的 Kilo Code 账户（credits 的获取与充值见下文"成本"一节）
Git 提供商集成	在 app.kilo.ai 的Integrations页面配置好 GitHub 或 GitLab 集成
Linear 工作区权限	拥有一个可以安装集成的 Linear 工作区访问权限

Git 提供商（GitHub/GitLab）集成之所以是硬性前置条件，是因为 Cloud Agent 的仓库操作（读代码、建分支、开 PR）全部依赖它完成；缺少该集成时机器人即使能读到 issue，也无法产出真正的实现类结果。

四、设置步骤

打开 app.kilo.ai，进入Integrations页面；
找到并设置Linear集成；
授权 Kilo 访问你的 Linear 工作区。

连接成功后，@kilo就会出现在你 Linear 工作区中任意 issue 的提及（mention）列表里，无需逐仓库、逐 issue 单独配置。

需要说明的是：如果你使用的是KiloClaw产品线，Linear 接入方式略有不同——KiloClaw 通过在工作区设置中粘贴 LinearAPI Key完成集成，且配置后需要重新部署实例才能生效，详见 KiloClaw Linear 集成文档。本文讨论的 Kilo for Linear（面向 Kilo Code）采用 OAuth 授权方式，两者入口与凭证管理方式不同，请按产品线选择对应配置。

五、典型使用场景

1. Sprint 收尾清理（Sprint Cleanup）

如果 backlog 里积压了一批描述清晰的 Bug，可以逐个 issue 标记机器人，让它按顺序处理，而你专注更高优先级的工作。适合"描述完整、验收标准明确"的缺陷清单批量消化。

2. 跨仓库升级（Cross-Repo Upgrades）

当需要升级某个框架版本、或在多个服务间统一应用某项配置变更时，只需创建一个描述清楚变更内容的 Linear issue，然后在评论中告诉机器人要更新哪些仓库。机器人会为每个仓库分别开 PR，评审人可以逐仓合并、逐仓验证，避免大爆炸式（big-bang）变更带来的风险。

3. 问题调查（Issue Investigation）

当 Bug 报告含糊不清、根因不明时，先让机器人分析 issue、搜索代码库并圈出可疑区域，再决定是否投入修复。这与 GitHub 集成文档中"先诊断、后修复"的推荐做法一致：诊断类请求消耗的上下文更少、目标更明确，也更容易得到高质量回答。

六、成本

Kilo Code credits 的消耗方式与任何其他 Kilo 界面一致，即该功能不额外收取订阅费用，而是复用账户 credits。具体消耗取决于：

所选模型：不同模型单价不同；
任务复杂度：跨仓库变更、大规模实现类任务消耗更多 tokens。

关于 credits 的获取，Kilo Code Provider 文档说明：注册 Kilo Code 后即可用免费模型起步，也可在账户中充值 credits 以解锁高级模型；内置 provider 由 Kilo Gateway 负责模型访问、用量跟踪与组织管控。实际消耗以所选模型的用量为准。

七、获得最佳效果的建议

写清楚 issue 描述：机器人效果最好的前提是 issue 标题与描述提供了足够上下文，让它可以理解问题本身和期望结果；
需要多仓库时明确点名仓库：如果变更需要落在多个仓库，务必在指令中列出具体仓库名，避免机器人只处理默认仓库或猜错范围；
模糊问题先诊断再修复：对根因不明的 issue，先请求分析（@kilo what could be the cause of this issue?），拿到结论后再请求实现（@kilo please fix），成功率更高。