如何将Kapa.ai集成到智能体系统中提升技术问答准确性？（附LangGraph集成示例）

引言

kapa.ai 是一款由大语言模型驱动的 AI 助手，旨在回答关于您产品的技术问题。我们通过整合知识源，利用检索增强生成（RAG）流程来处理用户疑问和支持工单，从而提供精准的答案。

kapa.ai 是一款由大语言模型驱动的 AI 助手，旨在回答关于您产品的技术问题。我们通过整合知识源，利用检索增强生成（RAG）流程来处理用户疑问和支持工单，从而提供精准的答案。

我们所做一切的核心是答案的准确性。大语言模型本身并不可靠；它们可能会编造听起来不错的内容。Kapa 的存在就是为了解决这个问题，它通过处理爬取、解析、评估、安全护栏等环节，为您和您的用户提供一个可以信赖的、专业化的 AI 助手。

我们所做一切的核心是答案的准确性。大语言模型本身并不可靠；它们可能会编造听起来不错的内容。Kapa 的存在就是为了解决这个问题，它通过处理爬取、解析、评估、安全护栏等环节，为您和您的用户提供一个可以信赖的、专业化的 AI 助手。

我们的客户及其最终用户信赖 Kapa 能提供准确的答案。因此，一个自然而然出现的问题就是：如何将 Kapa 更深入地集成到客户支持工作流中。例如：

我们的客户及其最终用户信赖 Kapa 能提供准确的答案。因此，一个自然而然出现的问题就是：如何将 Kapa 更深入地集成到客户支持工作流中。例如：

“Kapa 非常擅长回答问题——但它也能创建工单或升级给人工处理吗？”

这种希望 Kapa 处理不仅仅是问答的用例正变得越来越普遍，也与业界对智能体 AI 系统日益增长的兴趣相呼应。

这种希望 Kapa 处理不仅仅是问答的用例正变得越来越普遍，也与业界对智能体 AI 系统日益增长的兴趣相呼应。

简短的答案是：不能直接开箱即用。但 Kapa 的设计初衷是作为一个更大系统内的组件，因此您可以按照适合您业务的方式将其扩展到这些流程中。

简短的答案是：不能直接开箱即用。但 Kapa 的设计初衷是作为一个更大系统内的组件，因此您可以按照适合您业务的方式将其扩展到这些流程中。

Kapa 在智能体系统中的定位

Kapa.ai 的核心是您产品的高精度技术助手。我们整合您的知识源，通过检索增强生成流程运行它们，并提供带有引用的、基于事实的答案。易于设置，并可部署在您的用户所在的任何地方。

Kapa.ai 的核心是您产品的高精度技术助手。我们整合您的知识源，通过检索增强生成流程运行它们，并提供带有引用的、基于事实的答案。易于设置，并可部署在您的用户所在的任何地方。

那么，为什么我们没有扩展 Kapa 的能力以涵盖更多工作流，例如工单处理或计费呢？

那么，为什么我们没有扩展 Kapa 的能力以涵盖更多工作流，例如工单处理或计费呢？

我们看到了扩展工作流的真正价值，但我们的使命是构建最准确的技术助手。专注于这一点，才能确保我们提供客户所依赖的可靠性。

我们看到了扩展工作流的真正价值，但我们的使命是构建最准确的技术助手。专注于这一点，才能确保我们提供客户所依赖的可靠性。

扩展的工作流在很大程度上是业务特定的。初创公司可能使用 Zendesk，而大型企业可能使用 ServiceNow。我们自己则使用 Pylon。没有一种方案能适合所有情况。这不仅体现在所使用的系统上，也体现在特定公司希望其智能体如何行动上：

扩展的工作流在很大程度上是业务特定的。初创公司可能使用 Zendesk，而大型企业可能使用 ServiceNow。我们自己则使用 Pylon。没有一种方案能适合所有情况。这不仅体现在所使用的系统上，也体现在特定公司希望其智能体如何行动上：

• 如果用户报告了一个错误，我们应该在 Jira 中为工程团队创建工单，还是在 Zendesk 中为支持团队创建案例？ (If a user reports a bug, should we create a ticket in Jira for engineering, or a case in Zendesk for support?)
• 付费客户与免费层用户的升级规则是否应该不同？ (Should escalation rules differ for paying customers vs free-tier users?)
• 如果问题与账户相关（计费、权限、安全），是否应该始终绕过 Kapa 直接转给人工支持？ (If the question is account-related (billing, permissions, security), should it always bypass Kapa and go straight to human support?)

相反，我们希望 Kapa 成为一个模块化组件：一个您可以放入任何对您公司有意义的智能体系统中的工具。这样，您就能获得两全其美的效果：Kapa 提供准确的答案，而您的系统则处理您工作流中特有的操作。

相反，我们希望 Kapa 成为一个模块化组件：一个您可以放入任何对您公司有意义的智能体系统中的工具。这样，您就能获得两全其美的效果：Kapa 提供准确的答案，而您的系统则处理您工作流中特有的操作。

为何 Kapa 应成为智能体系统的一部分

如果您正在构建一个没有 Kapa 的智能体工具或系统，您有两个选择：

如果您正在构建一个没有 Kapa 的智能体工具或系统，您有两个选择：

1. 构建并维护您自己的 RAG 流程，包括所有随之而来的复杂功能。 (Build and maintain your own RAG pipeline, including all the bells and whistles that that entails.)
2. 依赖一个通用 LLM 来尝试解释用户（或另一个智能体）的问题，听天由命。 (Live life at the mercy of a generic LLM trying to interpret the user's (or another agent's) question.)

有了 Kapa，您可以让智能体将技术问题路由给 Kapa，并获得带有来源的准确响应，或者一个真正的“我不知道”。其他问题（计费、错误、访问请求、工单创建）则可以流向其他工具，无论是直接流转还是先经过 Kapa。

有了 Kapa，您可以让智能体将技术问题路由给 Kapa，并获得带有来源的准确响应，或者一个真正的“我不知道”。其他问题（计费、错误、访问请求、工单创建）则可以流向其他工具，无论是直接流转还是先经过 Kapa。

最终的结果是一个保持灵活性但绝不牺牲正确性的智能体。

最终的结果是一个保持灵活性但绝不牺牲正确性的智能体。

示例：使用 LangGraph 构建支持智能体

为了让这个概念更具体，让我们看看我们使用 LangGraph 构建的一个小型原型。

为了让这个概念更具体，让我们看看我们使用 LangGraph 构建的一个小型原型。

我们的支持智能体包含三个活动部分：

我们的支持智能体包含三个活动部分：

1. query_kapa – 一个调用 Kapa API 的工具。 (query_kapa – a tool that calls Kapa's API.)
2. create_support_ticket – 一个提交工单的工具（我们连接了 Pylon，但您可以换成 Zendesk/ServiceNow 等）。 (create_support_ticket – a tool that files a ticket (we wired Pylon, but you could swap Zendesk/ServiceNow/etc.).)
3. 推理器节点 – 一个由 Claude 驱动的 LLM，根据用户消息决定调用哪个工具。 (Reasoner node – a Claude-powered LLM that decides which tool to call based on the user's message.)

这基本上就是整个循环：推理器查看用户的问题并决定适当的操作（工具）。

这基本上就是整个循环：推理器查看用户的问题并决定适当的操作（工具）。

为了测试，您可以将其作为一个简单的 CLI 运行；对于更广泛的测试，您可能需要考虑将其连接到聊天界面（如 Slack）。您可能还希望用更多工具来扩展它。限制由您决定，而这正是我们认为智能体工具需要且应具备的灵活性，以便发挥作用。

为了测试，您可以将其作为一个简单的 CLI 运行；对于更广泛的测试，您可能需要考虑将其连接到聊天界面（如 Slack）。您可能还希望用更多工具来扩展它。限制由您决定，而这正是我们认为智能体工具需要且应具备的灵活性，以便发挥作用。

以下部分展示了每个部分可能样子的简化代码片段。

以下部分展示了每个部分可能样子的简化代码片段。

1. Kapa 作为工具

在这个例子中，query_kapa 是一个工具，它接收一个自然语言问题，调用 Kapa 的 API，并返回一个基于事实的答案。

在这个例子中，query_kapa 是一个工具，它接收一个自然语言问题，调用 Kapa 的 API，并返回一个基于事实的答案。

2. 您自己的操作工具

业务特定的操作工具。在我们的案例中，它提交 Pylon 工单，但您可以换成 Zendesk 或 ServiceNow。

业务特定的操作工具。在我们的案例中，它提交 Pylon 工单，但您可以换成 Zendesk 或 ServiceNow。

3. 推理器的策略提示词

这是指导推理器的策略提示词。它只是文本，但编码了您的路由逻辑。

这是指导推理器的策略提示词。它只是文本，但编码了您的路由逻辑。

4. 在 LangGraph 中将所有部分组合起来

最后，我们使用 LangGraph 将所有部分连接起来。循环是：推理 → （可能）使用工具 → 推理。

最后，我们使用 LangGraph 将所有部分连接起来。循环是：推理 → （可能）使用工具 → 推理。

实践考量

如果您正在试验这种模式，有几件事需要记住：

如果您正在试验这种模式，有几件事需要记住：

• 智能体内的 Kapa 查询与任何其他 Kapa 查询同等计费。 (Kapa queries inside your agent count the same as any other Kapa queries.)
• Kapa 优先考虑准确性，因此查询通常需要几秒钟。 (Kapa prioritizes accuracy, so queries typically take a few seconds.)
• 智能体系统功能强大但可能脆弱；路由逻辑和工具定义非常重要。 (Agentic systems are powerful but can be brittle; routing logic and tool definitions matter a lot.)
• 在本文提供的示例中，工具返回纯文本字符串。在生产环境中，您可能更倾向于返回结构化的 JSON（例如 {answer, sources, uncertain}），以便智能体能够精确决定何时升级或如何呈现结果。 (In the examples provided here, tools return plaintext strings. In production, you may prefer to return structured JSON (e.g. {answer, sources, uncertain}) so the agent can make precise decisions about when to escalate or how to render results.)

总结

我们对智能体 AI 的兴起感到兴奋，更期待看到客户如何在这些系统中试验 Kapa。

我们对智能体 AI 的兴起感到兴奋，更期待看到客户如何在这些系统中试验 Kapa。

如果您正在构建相关应用，我们很乐意听取您的想法！您将 Kapa 与哪些工具结合使用？哪些方面有效，哪些方面还有不足？虽然我们的立场是 Kapa 并不试图成为一个全能智能体，但我们希望确保它是一个您可以信赖并插入的模块。任何帮助我们改进此体验的产品反馈都极具价值。

如果您正在构建相关应用，我们很乐意听取您的想法！您将 Kapa 与哪些工具结合使用？哪些方面有效，哪些方面还有不足？虽然我们的立场是 Kapa 并不试图成为一个全能智能体，但我们希望确保它是一个您可以信赖并插入的模块。任何帮助我们改进此体验的产品反馈都极具价值。

我们的重点是使 Kapa 成为最准确的问答智能体——我们期待看到客户如何将其组合到他们自己的智能体工作流中，并且我们将持续改进开发者体验，使其变得更加容易。

我们的重点是使 Kapa 成为最准确的问答智能体——我们期待看到客户如何将其组合到他们自己的智能体工作流中，并且我们将持续改进开发者体验，使其变得更加容易。

实用链接：

实用链接：

常见问题（FAQ）

Kapa.ai 如何保证在智能体系统中的答案准确性？

Kapa.ai 通过检索增强生成（RAG）流程整合知识源，提供带有引用的、基于事实的答案。其核心使命是专注于构建最准确的技术助手，确保可靠性。

在 LangGraph 中如何将 Kapa.ai 作为工具集成？

在 LangGraph 中，可将 Kapa.ai 封装为 query_kapa 工具，由推理器节点根据用户问题调用。这样智能体可将技术问题路由给 Kapa，获得准确响应。

为什么 Kapa.ai 适合作为模块化组件集成到智能体系统？

Kapa.ai 设计为模块化组件，可专注于提供准确答案，而其他业务特定工作流（如工单处理）由智能体系统的其他工具处理，实现灵活性与正确性的结合。