# 如何把 AI Agent 做成一个贷款客服排查与修复工作台

很多团队已经在用大模型回答 FAQ，但真正落到客服一线时，问题往往不是“怎么回答更像人”，而是“怎么把数据库、日志、代码、修复命令和会话流程串成一个可靠的工作台”。

`loan-bot` 这个项目就是沿着这个方向做的：它不是一个单纯的聊天机器人，而是一个面向贷款客服场景的智能工作区。它既能查问题、整理证据、输出客服结论，也能在边界明确后执行标准修复。

这篇文章会拆解它的开发思路，并给出一套别人也能快速复用的落地方法。

## 一、先不要把它当成“机器人”，而要把它当成“工作区”

这个项目最关键的设计，不是 Prompt，而是工作区组织方式。

它把客服处理贷款问题时真正会用到的东西都收口到了一个目录里：

- `skills/`：沉淀排查流程、修复流程和维护规则
- `scripts/`：数据库、日志、平台探查等辅助脚本
- `tool-operations/`：标准修复执行模块
- `refs/`：路径配置和高价值入口索引
- `业务代码`：用于解释页面逻辑、状态流转和外部对接行为

这样做的好处是，Agent 不再只会“回答”，而是能围绕一个完整工作区执行任务：

- 先识别问题属于排查、修复还是协查
- 再去查数据库和日志
- 再结合业务代码解释状态
- 最后决定是给结论、整理协查材料，还是进入修复流程

这比“在一个大 Prompt 里告诉模型你要会什么”稳定得多，因为能力入口、脚本、路径、知识和动作都已经显式落在文件系统里。

## 二、把复杂客服场景拆成三层，而不是堆成一个 Agent

`loan-bot` 的架构可以概括成三层。

### 1. 排查层

排查层负责回答“到底出了什么问题”。

对应目录主要是：

- `skills/`
- `业务代码`

这一层不急着修，而是先做问题识别、证据路径选择和业务解释，比如：

- 用户到底有没有点击还款
- 页面卡在哪一步
- 当前订单是什么状态
- 这是不是系统问题，还是服务商返回导致的问题

### 2. 取证层

取证层负责拿事实，而不是靠模型猜。

对应目录主要是：

- `scripts/`
- `业务代码`
- `refs/`

这层的核心思想很简单：对正式客服工单，默认至少要有一条数据库证据和一条日志证据。数据库告诉你“系统最终状态是什么”，日志告诉你“过程里发生了什么”。只有两者合起来，根因判断才会更稳。

### 3. 修复层

修复层负责回答“现在能不能安全地处理它”。

对应目录是：

- `tool-operations/`

这一层不做根因判断，只负责标准化修复，例如：

- OCR 有效期修复
- 用户锁定修复
- 开放换绑卡入口
- 订单状态、还款状态修复

它的价值不在于“能执行命令”，而在于把执行命令这件事从自由发挥变成可控流程。

## 三、系统运行架构：它在线上到底是怎么跑起来的

上面讲的是设计思路，下面换一个角度，直接从“系统运行”来看这个项目。

如果把 `loan-bot` 当成一套在线系统，而不是一堆文档和脚本，它的运行架构大概是下面这样。

```mermaid
flowchart LR
 U["客服用户"] --> W["企业微信 / Dashboard"]
 W --> G["GolemBot Gateway 127.0.0.1:3000"]
 G --> O["编排层 systemPrompt + skills"]
 O --> Q["查询能力 db / log / probe scripts"]
 O --> B["业务代码 状态解释 / 路径锚点"]
 O --> R["修复执行器 auto.sh -> repair.exp -> specs"]
 O --> S["状态存储 .golem history / sessions / dm router"]
 R --> P["Pod / 跳板机环境"]
```

这张图里最重要的结论有两个：

- 对外只有一个统一入口：Gateway
- 真正承载稳定性的不是模型本身，而是脚本、状态文件和修复执行器

### 1. 入口架构：统一接入，统一输出

这个项目的接入方式很克制，没有额外再做一套后端 API，而是直接复用 `golembot gateway`。

对外它只暴露两类入口：

- 本地 Dashboard
- 企业微信机器人通道

运行时的入口关系可以画成这样：

```mermaid
flowchart TD
 A["Dashboard 浏览器"] --> C["Gateway"]
 B["企业微信消息"] --> C["Gateway"]
 C --> D["Codex Engine"]
 D --> E["回复结果"]
 E --> A
 E --> B
```

这意味着无论消息来自哪里，后面的排查、协查、修复逻辑都是同一套。这样做最大的好处是：

- 本地调试和线上接入共用一条主链路
- 不会出现“Dashboard 能跑，企业微信还要重写一遍”的问题

### 2. 编排架构：用配置和技能驱动运行时路由

这个系统的“控制塔”不是代码里的一个大 `switch case`，而是：

- `golem.yaml`
- `skills/`

它们共同决定运行时怎么走：

- 这条消息先走排查还是先走修复
- 默认查数据库还是同时查日志
- 当前回复该用什么格式
- 用户回复 `beta` / `pre` / `执行` 时应该承接哪条待执行对象

运行时路由关系大致如下：

```mermaid
flowchart TD
 M["用户消息"] --> N["消息识别 uid / order_id / 问题描述"]
 N --> J{"场景判断"}
 J -->|直接修复类| K["贷款修复执行"]
 J -->|排查后修复类| L["贷款客服问题排查"]
 J -->|服务商协查类| L
 L --> T{"是否命中标准修复"}
 T -->|是| K
 T -->|否| U["输出排查或协查结论"]
 K --> V["confirm -> preview -> execute"]
```

这层的本质不是“让模型自由发挥”，而是把运行时决策外置成一套显式规则。

### 3. 查询架构：事实查询和业务解释分层

很多 Agent 项目失败，是因为把“查事实”和“解释事实”混在一起。

这个项目在运行时把这两件事拆开了：

- 脚本负责查询事实
- 业务代码负责解释事实

```mermaid
flowchart LR
 A["编排层"] --> B["数据库脚本"]
 A --> C["日志脚本"]
 A --> D["平台探测脚本"]
 A --> E["业务代码"]
 B --> F["结构化事实"]
 C --> F
 D --> F
 E --> G["状态解释 / 代码锚点"]
 F --> H["最终结论"]
 G --> H
```

运行时具体分工是这样的：

- `scripts/db/*`：查数据库事实
- `scripts/log/*`：查日志事实
- `scripts/platform-probes/*`：查平台或页面背后的真实接口
- 业务代码：解释字段含义、状态枚举、页面入口和服务商行为

这样做的直接好处是，模型不会被迫用自然语言临时发明一套查询方式。

### 4. 修复执行架构：统一入口，白名单命令，二次确认

修复动作是这个系统里最敏感的一层，所以它不是直接让模型进 Pod，而是走一条固定执行链路：

```mermaid
flowchart LR
 A["用户确认修复"] --> B["auto.sh"]
 B --> C["repair.exp"]
 C --> D["specs/*.tcl"]
 D --> E["生成真实执行命令"]
 E --> F["tools/kpod"]
 F --> G["目标 Pod"]
```

其中每一层职责都非常单一：

- `auto.sh`：统一入口，只接受已登记的标准命令
- `repair.exp`：负责参数装配、预览、进入 Pod 和执行
- `specs/*.tcl`：命令白名单和真实模板真源
- `tools/kpod`：自动进入目标环境

修复阶段的运行时序更适合用时序图来看：

```mermaid
sequenceDiagram
 participant U as 用户
 participant G as Gateway
 participant A as Agent
 participant X as auto.sh
 participant E as repair.exp
 participant P as Pod

 U->>G: beta / pre
 G->>A: 继续当前待执行修复对象
 A->>X: confirm <命令>
 X->>E: REPAIR_CONFIRM=1
 E-->>A: 确认信息 + 真实命令
 A->>X: preview <命令>
 X->>E: REPAIR_PREVIEW=1
 E-->>A: 预览结果
 A-->>U: 展示确认信息，等待下一轮
 U->>G: 执行
 G->>A: 继续同一对象
 A->>X: <命令>
 X->>E: 正式执行
 E->>P: 进入 Pod 并执行命令
 P-->>E: 执行结果
 E-->>A: 成功 / 失败
 A-->>U: 执行结果
```

这也是为什么这套系统比较安全：它把“识别修复意图”和“真的执行修复”拆成了两轮。

### 5. 状态架构：把会话状态落盘，而不是全靠模型记忆

如果系统只靠模型上下文来记会话，IM 场景很快就会出问题，尤其是用户只回复：

- `beta`
- `pre`
- `执行`

所以这个项目把状态显式落到了 `.golem/`。

```mermaid
flowchart TD
 A["收到新消息"] --> B["按 channel / chat / sender 生成会话键"]
 B --> C["检查 dm-session-router.json"]
 C --> D{"15 分钟内或任务仍在运行?"}
 D -->|是| E["继续旧会话"]
 D -->|否| F["创建新工单会话"]
 E --> G["读 history / sessions"]
 F --> G
 G --> H["交给 Agent 继续处理"]
```

运行时主要会用到这些状态文件：

- `.golem/history/*.jsonl`：历史消息
- `.golem/sessions.json`：引擎会话映射
- `.golem/dm-session-router.json`：私聊工单路由
- `.golem/dm-greetings.json`：首次欢迎状态

另外，这个项目还 patch 了本地 `golembot`，让企业微信消息的 `senderId`、`chatId`、`messageId` 都能进入会话路由逻辑。这样短词回复才不会丢上下文。

### 6. 部署架构：本地开发和常驻运行共用一套

这个项目运行上并不复杂，核心就两种模式：

- 开发调试：直接启动 Gateway
- 稳定运行：由 `launchd` 托管

部署关系可以简化成下面这样：

```mermaid
flowchart TD
 A["launchd"] --> B["run_gateway.sh"]
 B --> C["npm run bot:gateway"]
 C --> D["GolemBot Gateway"]
 D --> E["Dashboard 127.0.0.1:3000"]
 D --> F["企业微信 WebSocket 通道"]
 D --> G["logs/gateway.out.log"]
 D --> H["logs/gateway.err.log"]
```

这样做的价值在于：

- 本地和常驻运行的主进程是一套
- 重启方式标准化
- 日志落点固定，便于排查

### 7. 一条请求的完整运行链路

把上面几层合起来，一条消息在线上的完整流转大概是这样的：

```mermaid
sequenceDiagram
 participant U as 用户
 participant C as 企业微信 / Dashboard
 participant G as Gateway
 participant S as Skills + Prompt
 participant Q as 查询脚本
 participant B as 业务代码
 participant R as 修复执行器

 U->>C: 发送 uid / 订单号 / 问题描述
 C->>G: 传入消息
 G->>S: 交给 Agent 编排
 S->>S: 判断排查类 / 修复类 / 协查类
 alt 排查或协查
 S->>Q: 查数据库 / 日志 / 平台
 Q-->>S: 返回结构化事实
 S->>B: 解释字段和状态
 B-->>S: 返回代码锚点
 S-->>G: 生成结论
 else 标准修复
 S->>R: 进入 confirm / preview / execute
 R-->>S: 返回预览或执行结果
 S-->>G: 生成修复结果
 end
 G-->>C: 输出回复
 C-->>U: 用户看到结果
```

这里最关键的一点是：模型在运行时更像一个“编排器”。真正保证系统可控、可审计、可复用的，是 Gateway、脚本、状态文件和修复执行链路共同组成的运行架构。

## 四、如果你要复用这套方案，优先保留这 4 个运行机制

总结一下，`loan-bot` 最有价值的地方，不是某一个具体命令，也不是某一个 Prompt，而是下面这套组合：

- 用工作区承载能力，而不是只靠模型记忆
- 用 `skills` 做运行时路由，而不是把规则全堆进一个 Prompt
- 用脚本和 spec 承担查询与执行，而不是让模型现场拼命令
- 用会话状态和二次确认控制 IM 场景下的连续操作

这套方法并不只适用于贷款客服。

只要你的业务满足下面三个条件，就值得照这个思路做：

- 问题类型相对集中
- 查询入口和修复动作可以标准化
- 对结论准确性和动作安全性有要求

## 五、如果从零开始做，最小实现步骤是什么

建议按下面 5 步搭第一版：

1. 先选一个垂直场景，不要从全能 Agent 开始。
2. 先画出三层：排查、取证、修复。
3. 先补三个入口：数据库查询、日志查询、标准动作执行。
4. 再把高频流程写成 skill，明确路由和输出格式。
5. 最后补 IM 会话状态和二次确认，让系统能稳定承接短词回复。

只要先跑通下面这条链路，第一个版本就已经有很高的业务价值：

1. 用户发来一个订单号或用户 ID
2. Agent 自动识别场景
3. Agent 调脚本查询数据库和日志
4. Agent 输出结构化结论
5. 如果命中标准动作，先预览，再执行

## 六、最后给一个可直接复用的项目骨架

如果你想自己做一个类似项目，可以先按这个结构搭：

```text
your-agent-workspace/
├── README.md
├── golem.yaml
├── skills/
│ ├── issue-investigation/
│ ├── action-execution/
│ └── skill-maintenance/
├── scripts/
│ ├── db/
│ ├── log/
│ └── probes/
├── tool-operations/
│ ├── auto.sh
│ ├── repair.exp
│ └── specs/
├── refs/
└── docs/
```

当这条链路打通后，你再继续补：

- 更多 playbook
- 更多标准修复 spec
- 更细的会话路由
- 更适合 IM 的输出格式

## 结语

如果只把大模型当成“更会说话的 FAQ 系统”，它很难真正进入复杂业务流程。

但如果你愿意把它放进一个结构化工作区里，给它技能、脚本、路径、证据规则、会话状态和动作边界，它就会从“聊天机器人”变成“可用的业务工作台”。

`loan-bot` 的开发思路，本质上不是“怎么写一个更聪明的 Agent”，而是“怎么把一个高频、高风险、强依赖内部工具的客服流程，拆成一个模型可以稳定接手的系统”。

这也是我认为这类项目最值得推广的地方。

很多团队已经在用大模型回答 FAQ，但真正落到客服一线时，问题往往不是“怎么回答更像人”，而是“怎么把数据库、日志、代码、修复命令和会话流程串成一个可靠的工作台”。

AI Agent 做成一个客服排查与修复工作台

人工智能

后端

职业发展

本文详细解析了贷款客服AI工作台loan-bot的开发思路，重点介绍了如何将数据库查询、日志分析、业务代码解释和修复执行等核心功能整合为结构化工作区。通过三层架构设计（排查层、取证层、修复层）、白名单修复机制和证据驱动的工作流程，实现了客服场景下的可靠问题处理。文章提供了可复用的项目骨架和实施路径，帮助开发者快速构建类似业务Agent系统。

2026新春采购季

cslr

tencentdb-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

本文详细解析了贷款客服AI工作台loan-bot的开发思路，重点介绍了如何将数据库查询、日志分析、业务代码解释和修复执行等核心功能整合为结构化工作区。通过三层架构设计（排查层、取证层、修复层）、白名单修复机制和证据驱动的工作流程，实现了客服场景下的可靠问题处理。文章提供了可复用的项目骨架和实施路径，帮助开发者快速构建类...

AI Agent 做成一个客服排查与修复工作台-腾讯云开发者社区-腾讯云

AI Agent 做成一个客服排查与修复工作台

AI Agent 做成一个客服排查与修复工作台

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐