Kotaemon支持工具调用，让AI助手真正‘能做事’

最新推荐文章于 2025-12-17 16:42:13 发布

原创最新推荐文章于 2025-12-17 16:42:13 发布 · 448 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#Kotaemon # 工具调用 # RAG

部署运行你感兴趣的模型镜像

Kotaemon支持工具调用，让AI助手真正“能做事”

在企业级智能对话系统的发展浪潮中，一个核心矛盾日益凸显：用户期望的不再是只会“回答问题”的聊天机器人，而是能够“解决问题”的智能代理。然而，大多数现有的AI助手仍停留在信息检索和文本生成层面，面对“帮我查一下订单状态”或“预约下周的技术支持”这类具体任务时，往往束手无策。

正是在这种背景下，Kotaemon作为一款专注于生产落地的开源对话框架，提出了一个清晰的技术路径——通过原生支持工具调用（Tool Calling），结合检索增强生成（RAG） 与模块化架构设计，打通从“理解意图”到“执行动作”的完整闭环。它不只让AI“能说”，更让它“能做”。

让知识可更新，也让答案有依据

很多企业部署AI客服时最先想到的是“把产品手册喂给模型”。但现实很快就会打脸：模型记不住动态政策、无法处理个性化数据，甚至会一本正经地胡说八道。这就是典型的“幻觉”问题。

Kotaemon选择了一条更稳健的路线：不依赖模型的记忆，而是构建实时的知识获取能力。这背后的核心技术就是RAG（Retrieval-Augmented Generation）。

想象这样一个场景：员工问“今年年假怎么休？”传统做法是预设答案，一旦政策调整就得人工修改。而在Kotaemon中，系统会自动从最新的《人力资源制度》文档库中检索相关内容，再交由大模型组织语言输出。这意味着，只要知识库更新了，AI的回答自然就变了——无需重新训练，也不用改代码。

更重要的是，这种机制带来了前所未有的可追溯性。每一次回答都可以附带引用来源，比如某份PDF的第几页、哪个章节。这对于金融、医疗等强合规行业来说，不是加分项，而是必需品。

下面是一个典型的RAG实现流程：

from langchain.retrievers import VectorStoreRetriever
from langchain.chains import RetrievalQA
from langchain.llms import HuggingFacePipeline

# 初始化向量数据库检索器
retriever = VectorStoreRetriever(vectorstore=db)

# 构建RAG链
rag_chain = RetrievalQA.from_chain_type(
    llm=HuggingFacePipeline(pipeline=llm_pipeline),
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True
)

# 执行查询
result = rag_chain({"query": "公司年假政策是什么？"})
print("答案:", result["result"])
print("来源:", [doc.metadata for doc in result["source_documents"]])

这段代码看似简单，却体现了工程上的深思熟虑。return_source_documents=True这一行，正是为了满足企业审计需求而存在的关键配置。你可以把它看作是一种“责任留痕”机制——AI不再是一个黑箱，它的每一个判断都有据可依。

不过也要注意，RAG并非万能。如果底层知识库质量差、切分不合理，或者向量模型对专业术语理解不准，照样会导致检索偏差。因此，在实际项目中，我们通常建议投入至少30%的精力用于知识清洗与索引优化，而不是一味追求更大的模型。

工具调用：从“话务员”到“办事员”的跃迁

如果说RAG解决了“说什么”的问题，那么工具调用解决的就是“做什么”的问题。

试想一位客户说：“我昨天买的那件外套还没发货，怎么回事？”
一个普通的问答系统可能会回复：“您可以登录账号查看物流信息。”
而一个具备工具调用能力的AI，则可以直接行动：
1. 解析出“昨天”对应的时间范围；
2. 调用用户认证接口确认身份；
3. 查询订单系统获取最近一笔服装类订单；
4. 调取物流API检查配送状态；
5. 返回：“您于3月20日购买的黑色夹克（订单号ORD123456）目前处于‘已打包’状态，预计24小时内发出。”

整个过程完全自动化，用户体验天差地别。

如何让AI学会“调工具”？

本质上，工具调用是一种结构化决策过程。我们需要告诉模型三件事：
- 有哪些工具可用？
- 每个工具是干什么的？
- 什么时候该用哪个？

Kotaemon采用的是函数描述+运行时调度的方式。开发者先以JSON Schema的形式定义工具接口，然后将这些描述注入提示词（prompt），让模型自行判断是否需要调用以及如何传参。

例如，定义一个查询订单状态的工具：

import json
from typing import Dict, Any

class Tool:
    def __init__(self, name: str, description: str, parameters: Dict):
        self.name = name
        self.description = description
        self.parameters = parameters

    def call(self, args: Dict[str, Any]) -> str:
        raise NotImplementedError

class OrderStatusTool(Tool):
    def __init__(self):
        super().__init__(
            name="get_order_status",
            description="根据订单ID查询订单当前状态",
            parameters={
                "order_id": {"type": "string", "description": "订单编号"}
            }
        )

    def call(self, args: Dict[str, Any]) -> str:
        order_id = args.get("order_id")
        # 模拟API调用
        status_data = {
            "ORD123456": "已发货，正在派送途中",
            "ORD987654": "已签收"
        }
        return status_data.get(order_id, "未找到该订单")

# 注册工具集
tools = [OrderStatusTool()]

当LLM识别到用户意图后，会输出类似如下的结构化指令：

{
  "action": "CALL_TOOL",
  "tool_name": "get_order_status",
  "parameters": {
    "order_id": "ORD123456"
  }
}

运行时系统解析这段JSON，查找对应的工具实例并执行方法。这种方式实现了声明式定义与动态调度的分离，既保证了灵活性，又便于管理和监控。

值得一提的是，这种模式对模型的要求其实并不高。即使是一些中小尺寸的开源模型（如Qwen、Llama3），只要经过适当的提示工程训练，也能稳定输出符合规范的调用指令。相比之下，反而是运行时的错误处理机制更为关键——比如参数缺失时要不要追问？API超时是否尝试重试？这些细节决定了系统的鲁棒性。

模块化设计：为复杂业务留出扩展空间

在真实的企业环境中，没有两个客服系统的需求是完全相同的。有的要对接ERP查库存，有的要集成OA走审批，还有的需要在敏感操作前加入风控校验。如果框架本身是封闭的，每加一个功能就得动核心代码，那根本没法长期维护。

Kotaemon的做法是：把整个对话流程拆成可插拔的组件链。

你可以把它想象成一条流水线，每个环节负责一件事：
- 输入解析 → 意图识别 → 分支路由 → 知识检索 / 工具调用 → 回复生成

这些组件之间通过标准接口通信，彼此独立。更重要的是，它们可以通过配置文件来组装，而不必写死在代码里。

比如这个YAML配置：

# config/pipeline.yaml
pipeline:
  - component: InputParser
    config:
      language: zh

  - component: IntentClassifier
    model_path: ./models/intent_bert_v3

  - component: ConditionalRouter
    routes:
      question: 
        next: KnowledgeRetriever
      task:
        next: ToolExecutor

  - component: KnowledgeRetriever
    retriever_type: vector
    index_name: company_policy_index

  - component: ToolExecutor
    allowed_tools:
      - get_order_status
      - create_ticket
      - search_faq

非技术人员也能看懂这条流程：如果是提问类问题，走知识库检索；如果是任务型请求，则进入工具执行器。未来要增加新分支，只需修改配置即可，无需重新部署服务。

同时，Kotaemon还支持真正的插件机制：

# plugin_system.py
import importlib

class PluginManager:
    def __init__(self):
        self.plugins = {}

    def register(self, name: str, module_path: str, class_name: str):
        module = importlib.import_module(module_path)
        cls = getattr(module, class_name)
        instance = cls()
        self.plugins[name] = instance
        print(f"插件注册成功: {name} -> {cls.__name__}")

# 使用示例
pm = PluginManager()
pm.register("weather_tool", "tools.external", "WeatherQueryTool")

这种设计特别适合需要频繁迭代的场景。比如电商大促期间临时接入促销规则引擎，活动结束后再卸载，整个过程对主系统零侵入。

实际落地中的那些“坑”与应对策略

理论很美好，但真正上线时总会遇到各种挑战。我们在多个客户现场实施过程中总结了几条关键经验：

1. 工具粒度要适中

太细碎会导致调用链过长，增加延迟和失败概率；太宽泛又难以复用。我们的建议是遵循“单一职责”原则。比如不要写一个handle_customer_service_flow大函数，而是拆分为verify_user_identity、fetch_order_history、submit_refund_request三个独立工具。