我在 20 年的支持工单前部署了一个 AI Agent
我们有一个拥有 100 万张工单的帮助台系统。我们有 2,400 份手册和两个庞大的代码库。
当开发人员询问我们以前是否解决过某个问题时，答案总是肯定的。只是数据被埋没了。资深员工在搜索上浪费数小时，初级员工则会浪费数周。
我构建了一个 AI agent 来处理所有这些数据。它现在已经投入生产。以下是实际发生的情况。
数据并不是难点。难点在于知道去哪里查找。让 agent 停止胡编乱造则更难。
工作原理：
- 一个支持自然语言输入的 agent。
- 它读取帮助台数据库、项目工具、GitLab 和 SVN。
- 它对手册和旧工单进行向量搜索。
- 它可以生成 .xlsx 或 .docx 等文件。
- 它会自主选择工具并并行运行。
架构很简单。它运行在一个与主应用分离的 Node 容器中。我这样做是为了实现故障隔离。如果 AI 失败了，帮助台仍能继续运行。
最大的教训在于 Prompt（提示词）。我最初使用了一大段文本，长达 40,000 个 token。这很难维护，而且 agent 会失去焦点。
我改变了方法。我将 prompt 拆分为小的技能文件（skill files）。
- 工单搜索是一个文件。
- 代码历史是另一个。
- 项目管理是第三个。
主 prompt 起到路由器的作用。它仅在需要时才加载特定的技能。这使我们的每次请求 token 数从 40,000 降到了 8,000。agent 能专注于任务，且代码易于更新。
我还添加了用户画像（user profiles）。开发人员会得到代码路径，项目经理会得到状态摘要。agent 无需被告知就能知道是谁在提问。
它并不完美。我们遇到了真实的失败：
- 幻觉（Hallucinations）：agent 编造了虚假的 URL。修复方法：固定精确模式或强制进行查询。
- 记忆丢失：agent 在长对话中忘记了规则。修复方法：在每一轮对话中注入结构化的待办事项列表。
- 无限循环：agent 调用了过多的工具。修复方法：为每次请求设置严格的预算（budget）。
- 安全性：用户试图诱导它。修复方法：不要依赖 prompt 来保证安全性。在基础设施中使用只读数据库凭据。
真正的工作是一个每周循环。我阅读日志，为会话评分，调整技能，更新用户画像。
如果你跳过这个循环，你得到的只是一个 Demo。如果你坚持做，你得到的才是一个产品。
目标不仅仅是更快的回答。目标是将机构知识（institutional knowledge）留在公司内部。当员工离职时，他们的知识会留在对话记录中。
构建指南总结：
- 从基于自身历史数据的 RAG 开始。
- 使用延迟加载的技能文件，而不是一个巨大的 prompt。
- 使用用户画像来提供个性化上下文。
- 将 AI 隔离在独立的容器中。
- 通过基础设施而非指令来确保安全性。
- 每周阅读你的日志。
Optional learning community: https://t.me/GyaanSetuAi