小型团队协作方案：OpenClaw+GLM-4.7-Flash构建内部知识问答机器人

1. 为什么我们需要一个内部知识机器人？

上周三下午，团队新成员小李在飞书群里连续发了五个关于项目规范的问题。这些问题在去年的会议纪要、产品文档和代码注释里都有明确答案，但散落在十几个不同位置。当我看着群里被刷屏的聊天记录时，突然意识到：我们缺的不是文档，而是一个能快速定位知识的"活地图"。

传统解决方案要么需要购买昂贵的SaaS服务，要么得搭建复杂的企业级系统。但对于我们这样5人以下的轻量级团队，更需要的是一种零成本、易维护且完全可控的方案。这就是为什么我选择用OpenClaw+GLM-4.7-Flash搭建内部问答机器人的原因。

2. 技术选型与核心优势

2.1 为什么是OpenClaw+GLM-4.7-Flash？

OpenClaw作为本地化智能体框架，完美契合了小团队的三个核心需求：

• 数据不出本地：所有文档处理和问答都在内网完成，敏感信息不会泄露
• 无缝对接现有工具：通过飞书机器人直接嵌入日常工作流
• 零边际成本：部署后只需支付模型调用的Token费用

而GLM-4.7-Flash作为轻量级模型，在知识问答场景表现出两个关键特性：

• 响应速度快：平均响应时间在1.5秒内，适合即时对话场景
• 精准片段提取：能准确定位文档中的相关段落，而非生成新内容

2.2 与传统方案的对比

我们曾尝试过几种替代方案：

• 飞书文档搜索：需要人工筛选结果，无法直接回答问题
• 商业知识库系统：年费超过2万元，功能冗余严重
• 自建Elasticsearch：维护成本高，需要专人管理

当前方案的成本对比表：

方案类型	部署成本	维护难度	响应速度	数据安全性
商业SaaS	高	低	快	依赖厂商
自建搜索引擎	中	高	中	高
本方案	零	低	快	极高

3. 零成本部署实战

3.1 基础环境准备

首先在团队服务器或任意成员的开发机上执行（推荐Linux/macOS）：

# 安装OpenClaw核心组件
curl -fsSL https://openclaw.ai/install.sh | bash

# 部署GLM-4.7-Flash模型服务
docker run -d -p 11434:11434 ollama/glm-4.7-flash

这个过程约消耗5分钟，主要时间花费在下载约4GB的模型文件。完成后可以通过curl测试模型服务：

curl http://localhost:11434/api/generate -d '{
  "model": "glm-4.7-flash",
  "prompt": "你好"
}'

3.2 OpenClaw关键配置

编辑~/.openclaw/openclaw.json配置文件，重点修改以下部分：

{
  "models": {
    "providers": {
      "local-glm": {
        "baseUrl": "http://localhost:11434",
        "api": "openai-completions",
        "models": [{
          "id": "glm-4.7-flash",
          "name": "Local GLM",
          "contextWindow": 8192
        }]
      }
    }
  },
  "channels": {
    "feishu": {
      "enabled": true,
      "appId": "你的飞书AppID",
      "appSecret": "你的飞书AppSecret"
    }
  }
}

配置完成后重启网关服务：

openclaw gateway restart

3.3 飞书机器人配置技巧

在飞书开放平台创建应用时，有两个关键设置需要注意：

1. 权限配置：只需勾选"获取群组消息"和"发送消息"权限
2. 安全设置：将部署服务器的公网IP加入IP白名单（通过curl ifconfig.me获取）

测试阶段可以先创建一个测试群组，避免干扰正式工作群。机器人接入后，@它发送"帮助"应该能收到基础功能说明。

4. 知识库构建与管理

4.1 文档接入方案

我们采用"三层文档接入"策略：

1. 核心文档：项目规范、API文档等Markdown文件，直接放在~/team_knowledge目录
2. 会议纪要：通过飞书妙记自动转存为文本文件
3. 代码知识：重要代码段的注释说明，定期导出为.md文件

OpenClaw会自动监控这些目录的变化。新增文档时，只需执行：

openclaw knowledge refresh

4.2 知识边界控制方法

为了防止机器人"胡言乱语"，我们通过prompt engineering设置了严格的知识边界：

你是一个专业的技术支持助手，必须严格遵守以下规则：
1. 只回答来自已录入知识库的内容
2. 当问题超出知识范围时，必须回复："该问题不在当前知识库中，请联系人工支持"
3. 引用文档时必须注明来源文件名和大致位置

这个提示词被保存在~/team_knowledge/system_prompt.txt中，会在每次问答时自动预置。

5. 实际效果与优化经验

5.1 典型问答场景

当有人在飞书群里提问："项目部署时遇到'端口冲突'错误怎么办？"，机器人会：

1. 在知识库中找到deployment_guide.md和troubleshooting.md
2. 提取相关段落并组合成结构化回答：

   根据 troubleshooting.md 第42-45行：
   - 检查8080端口占用：`lsof -i :8080`
   - 停止占用进程：`kill -9 <PID>`
   - 或修改config.yaml中的server.port值
   
   更多细节参考 deployment_guide.md 的"生产环境部署"章节
   

5.2 我们踩过的三个坑

问题1：文档更新后答案滞后

• 现象：修改了API文档但机器人仍返回旧参数
• 解决方案：设置定时任务每小时自动刷新知识库

crontab -e
# 添加：
0 * * * * /usr/local/bin/openclaw knowledge refresh

问题2：飞书消息偶尔丢失

• 现象：机器人有时不响应群聊@
• 解决方案：检查发现是websocket连接不稳定，改为轮询模式

{
  "channels": {
    "feishu": {
      "connectionMode": "polling"
    }
  }
}

问题3：长文档响应超时

• 现象：超过200KB的文档处理经常失败
• 解决方案：用split -l 100命令将大文档拆分为多个小文件

6. 进阶：自定义技能开发

当基础问答不能满足需求时，可以通过开发简单Skill来扩展功能。比如我们开发了一个会议纪要查询技能：

1. 创建meeting_skill目录结构：

meeting_skill/
├── index.js
└── package.json

2. 核心查询逻辑（index.js片段）：

module.exports = async ({ question, knowledge }) => {
  const meetings = await knowledge.search('会议');
  return meetings.map(m => `[${m.date}] ${m.title}`).join('\n');
}

3. 安装技能：

clawhub install ./meeting_skill

现在可以通过"查询上周会议"这样的自然语言指令获取会议列表了。

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。