AI 智能体回答简单工单，需要工程师处理的谁来管？

在 Gleap，四分之三的客服请求现在都由 AI 代理处理。但这并不是重点。真正有意思的是它处理的是哪些请求：不是重置密码，而是那些过去会落到我们五位开发人员手上的工单。At Gleap, three out of four support requests are now handled by an AI agent. That’s not the interesting part. The interesting part is which ones: not password resets, but tickets that used to land on one of our five developers.

每家软件公司在其反馈闭环中都存在同样的漏洞。客户报告说某个功能出了问题。支持团队无法复现。工程团队忙得不可开交。工单就这样搁置着。几周后，有人顺手在一项无关的改动中修复了这个 bug，却没有人告知客户。Every software company has the same leak in its feedback loop. A customer reports that something is broken. Support can't reproduce it. Engineering is busy. The ticket sits. Weeks later, someone fixes the bug as part of an unrelated change, and nobody tells the customer.

AI 客服代理在这一流程的开端已经做得相当出色。问它“如何重置密码？”或“我需要将哪些 URL 加入白名单？”，经过你的文档训练的代理就能在几秒内给出回答，无论何时都一样。这部分的问题基本已经解决。AI support agents have gotten very good at the start of that loop. Ask "how do I reset my password?" or "which URLs do I need to whitelist?" and an agent trained on your docs will answer in seconds, at any hour. That part is close to solved.

但真正让人头疼的工单，并不是那些能从文档中找到答案的工单，而是那些你只能诚实地回答“我去跟工程团队确认一下”的工单。这不是知识问题，而是调试问题。而大多数 AI 客服工具恰恰就止步于此。But the tickets that actually hurt aren't the ones your docs can answer. They're the ones where the honest reply is "let me check with engineering." Those tickets aren't a knowledge problem. They're a debugging problem. And most AI support tools stop exactly there.

这篇文章讲的是一线客服代理放弃处理后会发生什么：我们如何打造 Kai Resolve——一款像二线支持工程师一样调查棘手工单的 AI 代理，以及它如何将确认的 bug 交给 Kai Code，由后者编写修复方案。This post is about what happens after the first-level agent gives up: how we built Kai Resolve, an AI agent that investigates hard tickets like a second-level support engineer, and how it hands confirmed bugs to Kai Code, which writes the fix.

需要工程师处理的工单The tickets that need an engineer

以下是一个典型示例，摘自我们的产品演示：Here's a typical one, taken from our product walkthrough:

CSV 导出在 1,000 行处停止了。我们的细分群体有 4,200 个联系人，所以文件不完整。"The CSV export stops at 1,000 rows. Our segment has 4,200 contacts, so the file is incomplete."

没有任何帮助文章能回答这个问题。要如实回复，就必须有人查看导出日志、检查客户账户，并阅读负责对导出结果进行分页的代码。这涉及三个不同的系统，而在大多数公司里，至少还需要两个人分别处理。No help article answers that. To reply honestly, someone has to look at the export logs, check the customer's account, and read the code that paginates the export. That's three different systems and, in most companies, at least two different people.

接下来通常会陷入一场接力赛：支持团队索要截图，工程团队要求提供复现步骤，每转一手就多耽搁一天。客户只看到一片沉默。What usually happens next is a relay race: support asks for screenshots, engineering asks for steps to reproduce, and every hop adds a day. The customer just sees silence.

当我们审视这条链路时，发现成本最高的部分并不是编写修复方案，而是排查问题：收集证据、复现问题，以及找出相关代码行。所以，我们构建了一个代理来做这些事。When we looked at that chain, the expensive part wasn't writing the fix. It was the digging: collecting evidence, reproducing the issue, and finding the line of code responsible. So that's what we built an agent to do.

将二线支持视为调查，而不是对话。Treat second-level support as an investigation, not a conversation

一级支持代理是为对话而构建的：理解问题、找到答案并作出回复。二级代理则需要采用不同的模式。它必须收集证据、提出假设、对照代码进行验证，最后给出答案，或提供可供他人采取行动的诊断结果。A first-level support agent is built for conversation: understand the question, find the answer, reply. A second-level agent needs a different shape. It has to gather evidence, form a hypothesis, check it against the code, and come back with either an answer or a diagnosis that someone can act on.

Kai Resolve 会让每个需要工程师处理的工单都经过相同的四个步骤。Kai Resolve runs every ticket that needs an engineer through the same four steps.

1. 从证据出发，而不是从客户的记忆出发1. Start from the evidence, not from the customer's memory

二线支持响应缓慢的最大原因是缺少上下文。因此，调查应从报告提交时记录的证据入手，而不是等待后续邮件。The biggest reason second-level support is slow is missing context. So the investigation starts from evidence captured at the moment of the report, not from a follow-up email.

借助应用内错误报告功能，这些证据会自动收集：With in-app bug reporting, that evidence is collected automatically:

• 工单及完整对话记录
  the ticket and the full conversation thread
• 设备、浏览器和 SDK 版本
  device, browser and SDK versions
• 控制台和网络日志
  console and network logs
• 导致该问题的点击路径
  the click trail leading up to the issue
• 屏幕录制和截图
  the screen recording and screenshot

此外，团队还可以让智能体访问其代码仓库，并通过 MCP 访问 Postgres 数据库等数据源。这两项功能都需要主动选择启用，而且都仅限只读。On top of that, teams can give the agent access to their repositories and, via MCP, to data sources such as a Postgres database. Both are opt-in, and both are read-only.

2. 阅读代码：沙盒隔离且只读2. Read the code: sandboxed and read-only

这正是 Kai Resolve 与客服聊天机器人不同的地方。代码仓库会被克隆到沙箱中，智能体会通过实际源代码追查问题报告。它不会提交更改，也不会推送代码。通过 MCP 访问数据库也仅限只读，破坏性数据库操作和账单操作都会被禁止。This is where Kai Resolve differs from a support chatbot. Repositories are cloned into a sandbox, and the agent traces the report through the actual source. It doesn't commit and it doesn't push. Database access through MCP is read-only too, and destructive database operations and billing operations are blocked.

我们有意将这条界限设得很严格。调查绝不能演变成事故。负责诊断问题的代理也不应有权更改生产环境。如果你曾经为了“暂时方便”而给脚本授予超出其所需的权限，就会明白其中的原因。We made this a hard boundary on purpose. An investigation should never be able to turn into an incident. The agent that diagnoses a problem shouldn't also be able to change production. If you've ever given a script more permissions than it needed "just for now", you know why.

Repositories and data are read-only inside the sandbox; writes and pushes are blocked

设置是指安装 Gleap SDK（用于捕获日志、会话回放和点击轨迹），并连接来自 GitHub、GitLab、Bitbucket 或 Azure DevOps 的代码仓库。整个过程大约需要十分钟。智能代理会直接读取源代码，因此不受编程语言限制；对于大型单体仓库，你可以将其范围限制在相关文件夹，这样只会下载这些文件。Setup means installing the Gleap SDK, which captures the logs, replays and click trails, and connecting your repositories from GitHub, GitLab, Bitbucket or Azure DevOps. It takes about ten minutes. The agent reads the source directly, so it works regardless of language, and in large monorepos you can limit it to the folders that matter, so only those files are downloaded.

3. 展示过程3. Show the work

只有工程师能够快速核查，诊断才有用。因此，调查结果会注明代理实际读取过的文件和行号。下面是我们产品演示中一个示例故障的情况：调查通知始终无法送达已退出登录的访客，但聊天通知却可以：A diagnosis is only useful if an engineer can check it quickly. So findings cite the files and lines the agent actually read. Here's what that looks like on a sample bug from our product walkthrough, where survey notifications never reach signed-out visitors but chat notifications do:

在 pushGate.ts:142 发现一个可能的 bug：当联系人没有电子邮件地址时，问卷推送会提前返回。Found a likely bug in pushGate.ts:142: survey pushes return early when the contact has no email.

聊天推送会跳过 pushGate.ts:128 处的检查，因此能够送达。Chat pushes skip that check at pushGate.ts:128, which is why they arrive.

Kai Resolve traces a customer report to the exact line of code

这就是“通知可能存在问题”和工程师打开一个文件就能确认的问题之间的区别。这也解释了 bug 为什么会发生：代理把可正常工作的路径和无法正常工作的路径进行了比较。That's the difference between "there might be a problem with notifications" and something an engineer can confirm by opening one file. It also explains why the bug happens: the agent compared the path that works with the path that doesn't.

4.“无法得出结论”表示未知，而不是“没有问题”4. "Inconclusive" means unknown, not "no issue"

对于支持场景中的 AI 智能体来说，最危险的失效模式不是给出错误答案，而是自信满满地给出错误答案。智能体找不到 bug 却报告“未发现问题”，就会悄无声息地关闭工单，而客户遇到的问题依然没有解决。The most dangerous failure mode for an AI agent in support isn't a wrong answer. It's a confident one. An agent that can't find a bug and reports "no issue found" quietly closes a ticket that's still broken for the customer.

因此，Kai Resolve 遵循一条严格规则：调查结果不明确时，绝不会将其判定为“没有问题”。系统会重新调查一次。如果结果仍不明确，智能体就会询问团队。So Kai Resolve follows a strict rule: an inconclusive investigation is never turned into "no issue". It gets one re-investigation. If it's still inconclusive, the agent asks the team.

这些问题会以带有具体选项的决策卡片形式出现，而不是开放式聊天。例如：“这个账户使用哪家推送服务提供商？OneSignal 还是 Firebase？”或者“团队成员应该能够打开 Reports 吗？是，这是个 bug / 否，仅限管理员。”团队成员点击一个答案，调查便会结合这一背景继续进行。人只需花几秒钟做出决定，而不是花一小时重现问题。Those questions arrive as a decision card with concrete options, not as an open-ended chat. For example, "Which push provider does this account use? OneSignal or Firebase?" or "Should teammates be able to open Reports? Yes, it's a bug / No, admins only." A teammate clicks an answer, and the investigation resumes with that context. A human spends a few seconds on a decision instead of an hour on reproduction.

An inconclusive result goes to the team as a decision card, never as "no issue"

一次调查，三种结果Three outcomes from one investigation

并非每个需要工程师介入的工单最终都会发现是 bug。调查结果通常有三种：Not every ticket that needs an engineer turns out to be a bug. An investigation ends in one of three places:

• 说明原因。如果这是由某项设置导致的，或属于预期行为，客服回复时应以实际查明的情况为依据，并解释原因。
  Explain the cause. If it's a setting or expected behavior, the customer gets a reply grounded in what the agent actually found, with the cause explained.
• 关联功能请求。如果客户提出的需求尚不存在，系统会将工单与现有请求关联，并为客户订阅更新。
  Link the feature request. If the customer is asking for something that doesn't exist yet, the ticket is matched to the existing request and the customer is subscribed to updates.
• 创建一个编码任务。如果这是已确认的 bug，就将其转为附有所有证据的编码任务。
  Prepare a coding task. If it's a confirmed bug, it becomes a coding task with all the evidence attached.

收到新的错误报告时，调查会自动启动；当一级客服无法回答时，调查会作为升级处理启动；也可以从任何工单手动启动。Investigations start automatically when a new bug report comes in, as an escalation when the first-level agent can't answer, or manually from any ticket.

关于成本：每次调查平均约为 0.49 美元，按代理实际完成的工作计费。On cost: an investigation averages about $0.49, billed for the work the agent actually does.

闭环：从诊断到拉取请求，再到回复客户Closing the loop: from diagnosis to pull request to customer reply

仅有诊断仍无法闭环。还得有人编写修复方案、将其交付，并告知客户。这正是大多数团队容易忽略的环节。A diagnosis on its own still leaves the loop open. Someone has to write the fix, ship it, and tell the customer. That's the part most teams lose track of.

当 Kai Resolve 确认某个缺陷后，编码任务会连同相关证据一起添加到工单中。接下来，团队会决定：When Kai Resolve confirms a bug, the coding task lands in the ticket with the evidence attached. From there, the team decides:

• 使用 Kai Code 修复问题。Kai Code 会规划变更、编辑代码、运行测试，并创建与工单关联的拉取请求。
  Fix it with Kai Code. Kai Code plans the change, edits the code, runs the tests and opens a pull request linked to the ticket.
• 使用你自己的工具。在 Claude Code、Codex 或 Cursor 中打开该任务。
  Use your own tools. Open the task in Claude Code, Codex or Cursor.
• 如果诊断需要重新审查，请附上备注后退回。
  Send it back with notes if the diagnosis needs another look.

Kai Code 不会合并或部署代码。你们的工程师会像审查同事提交的代码一样，审查并合并拉取请求。Kai Code doesn't merge or deploy. Your engineers review and merge the pull request, the same way they would review a colleague's.

接下来是容易被忘记的一步：合并并不等于发布。在默认的后续处理设置下，队友会确认修复确实已经上线。只有在那之后，客户才会在原工单中收到回复，告知问题已修复。Then comes the step that's easy to forget: a merge isn't a release. With the default follow-up setting, a teammate confirms the fix is actually live. Only then does the customer get a reply, in the original ticket, saying their issue is fixed.

A merge isn't a release: the customer hears back once the fix is live

这就是一个 bug 的循环：That's the loop for a bug:

客户提交报告 → Kai Support 回答或转交 → Kai Resolve 展开调查 → Kai Code 创建 PR → 你的团队审核并发布 → 客户收到回复。Customer report → Kai Support answers or routes → Kai Resolve investigates → Kai Code opens the PR → your team reviews and ships → the customer hears back.

许多需要工程师处理的工单其实根本不是 bug。客户想要的是产品目前还不具备的功能。Kai Resolve 会将工单匹配到已有的功能请求，并让客户订阅相关更新，这样工单关闭后，请求也不会随之消失。接下来由 Kai PM 接手，将各项请求与客户需求、收入和你的目标进行对比，并推荐下一步要开发什么。最终由你的团队做决定，获批的请求会像 bug 修复一样交给 Kai Code。以下是功能开发的流程：Plenty of tickets that need an engineer aren't bugs at all. The customer wants something the product doesn't do yet. Kai Resolve matches the ticket to an existing feature request and subscribes the customer to updates, so the request doesn't disappear with the closed ticket. Kai PM picks it up from there. It compares requests against customer demand, revenue and your goals, and recommends what to build next. Your team makes the call, and an approved request goes to Kai Code just like a bug fix. Here's the loop for a feature:

客户提交报告 → Kai Resolve 关联功能请求 → Kai PM 建议优先级 → 你的团队批准 → Kai Code 创建 PR → 你的团队审查并发布。Customer report → Kai Resolve links the feature request → Kai PM recommends priorities → your team approves → Kai Code opens the PR → your team reviews and ships.

它在我们自己的队列中是什么样子What it looks like on our own queue

我们通过 Gleap 处理 Gleap 自身的支持请求。如今，Kai Resolve 负责处理其中 75% 的请求。剩下的 25% 则会转交给 Kai Code 作为编码任务，或由我们团队的成员处理。We run Gleap's own support on Gleap. Today, Kai Resolve handles 75% of our support requests. The remaining 25% are either handed over to Kai Code as a coding task or handled by someone on our team.

对于小团队来说，这会改变工程时间的投入方向。我们不再根据不完整的报告复现漏洞，而是审查诊断结果和拉取请求。For a small team, that changes what engineering time is spent on. Instead of reproducing bugs from half-complete reports, we review diagnoses and pull requests.

在我们的欧盟客户中，Kai Resolve 在过去 30 天内进行了 1,368 次调查。在我们人工评估的样本中，70% 得出了正确结果，28% 部分正确，2% 错误；其中 80% 无需人工介入即可完成。根据团队是否已接入智能体所需核查的数据，调查结果为无法定论的比例为 2% 到 13%。Across our EU customers, Kai Resolve ran 1,368 investigations in the last 30 days. In a sample we graded by hand, 70% ended in a correct result, 28% were partly right and 2% were wrong, and 80% were finished without a human having to step in. Between 2% and 13% of investigations end as inconclusive, depending mostly on whether the team has connected the data the agent needs to check.

客户也能感受到这一点。从电子邮件支持迁移到 Gleap 后，Gather 团队能够将技术问题连同调查所需的背景信息一起转交给工程团队，响应时间也从约 30 分钟缩短至约 5 分钟。Customers see it too. After moving from email support to Gleap, Gather's team passes technical issues to engineering with the context needed to investigate, and response times dropped from around 30 minutes to about five.

“Gleap 为我们节省了大量时间，用户也觉得它非常实用。”——Gather 产品专员 Sasha King"Gleap saves us a lot of time and our users find it incredibly useful." Sasha King, Product Specialist, Gather

出了什么问题，还有哪些依然棘手的地方What went wrong, and what's still hard

我们最糟糕的一周源于一次依赖项更新，而不是糟糕的提示词。一次针对 coding-agent 适配器的更新，让它的只读模式真正变成了只读，因此智能体无法再写入自己的报告。连续两天，每次调查都一无所获。存疑规则发挥了作用：Kai 没有说“没有问题”，而是向团队提问，这类问题占工单的比例也从 18% 飙升到 53%。我们就是这样发现问题的。现在，空报告会被视为运行失败并触发警报，而且每次更新适配器之前，都会先进行一次线上测试。它目前仍难以应对数据缺失的情况：如果团队尚未连接数据库，智能体就无法检查客户记录；而那些从未出现在日志中的基础设施问题，也仍然很难诊断。Our worst week came from a dependency update, not a bad prompt. An update to the coding-agent adapter made its read-only mode truly read-only, so the agent could no longer write its own report. For two days, every investigation came back empty. The inconclusive rule did its job: instead of saying "no issue", Kai asked the team, and those questions jumped from 18% to 53% of tickets. That's how we noticed. Now an empty report counts as a failed run and triggers an alert, and every adapter update gets a live test first. Where it still struggles is missing data: if a team hasn't connected its database, the agent can't check the customer's records, and infrastructure problems that never show up in logs stay hard to diagnose.

在你自己的队列中试试Try it on your own queue

Kai Resolve 是 Gleap 的一部分。Gleap 是面向软件团队的 AI 原生帮助台，已有 4,500 多个团队在使用。从 Team 套餐起即可使用 Kai Resolve；你可以通过 7 天免费试用，在自己队列中的工单上开展首次调查，无需提供信用卡。Kai Resolve is part of Gleap, the AI-native help desk for software teams, used by more than 4,500 teams. It's included from the Team plan, and you can run your first investigation on a ticket from your own queue with a 7-day free trial, no credit card required.

AI 代理已经能够处理简单的工单。如今真正值得关注的是，如何闭环处理那些需要工程师介入的工单。AI agents already answer the easy tickets. The interesting work now is closing the loop on the ones that need an engineer.