Relevance AI 教程：从知识库到可审批的多 Agent Workforce

本教程要完成什么

这套教程用 Relevance AI 搭建一个“客户请求分诊 Workforce”：入口 Agent 接收客户问题，知识 Agent 检索已批准文档，政策 Agent 判断是否涉及退款、合同、安全或隐私，回复 Agent 只生成草稿，最后由人工批准后才允许发送或写入工单系统。这个例子覆盖 Agent 分工、知识、工具、交接、审批、失败处理、测试和成本控制。

目标不是追求全自动。第一版只处理脱敏测试数据，所有外部写入都强制审批。只有当准确率、引用、权限和失败恢复达到团队门槛后，才逐步开放低风险动作。

开始前准备

准备一组已批准的帮助中心文章、退款政策、服务范围、升级路径和 30–50 条脱敏历史请求。每条样本应包含理想分类、应引用的文档、允许给出的答复、必须升级的条件和不能暴露的信息。不要上传真实密码、支付卡、身份证件、医疗详情或未经授权的客户数据。

再定义成功标准：分类准确率、引用命中率、升级召回率、草稿被接受比例、平均 Actions、模型成本、人工审核时间和重复写入数。把“回复得像人”改成可测规则，例如“退款与账户安全请求必须 100% 进入人工队列”。

第一步：选择组织区域与项目边界

Relevance AI 在美国北弗吉尼亚、英国伦敦和澳大利亚悉尼等区域提供组织，创建后区域不能直接更改。先根据客户所在地、合同、数据驻留和下游系统选择，不要为了延迟随意决定。

为概念验证单独创建项目，不要直接连接生产邮箱和主 CRM。为构建者、测试者和终端用户分配不同角色。记录谁能修改 Agent、谁能更新知识、谁能批准外发，以及谁负责事故响应。

第二步：建立最小知识库

只导入本次流程需要的正式文档，并为每份资料记录所有者、版本、发布日期和复审日期。把退款、隐私、安全和产品操作分成不同知识范围，避免一个 Agent 检索所有内部内容。网页、Google Drive、SharePoint 或 Notion 同步后，要确认删除和权限变更是否及时传播。

为测试问题逐条检查检索结果。若正确文档排不到前面，先调整分段、标题、重复内容和范围，不要只靠提示词命令模型“必须正确”。知识库里互相冲突的政策会让 Agent 生成看似合理但无法执行的答案。

第三步：创建四个职责单一的 Agent

入口 Agent 只做字段检查和初步分类，输出 request_id、language、category、risk_level 和 missing_fields。知识 Agent 根据 category 检索允许范围，输出引用、版本和未找到答案的标记。政策 Agent 根据明确规则判断是否必须升级，不负责创作更友好的文案。回复 Agent 只使用结构化字段和引用生成草稿，不允许自行调用发送工具。

每个 Agent 的提示词写清输入、输出、允许工具、禁止动作和升级条件。不要复制一大段品牌故事代替规则。输出尽量采用稳定 JSON 字段，方便下一节点验证空值、枚举和引用。

第四步：把动作封装为 Tools

分别创建“读取工单”“查询批准知识”“创建内部草稿”“提交人工审批”和“批准后发送”工具。读取与写入使用不同凭据；发送工具只接受经过验证的 request_id、approved_draft 和 approver_id。为外部系统写入设置幂等键，避免超时重试产生重复回复。

先独立测试每个 Tool。覆盖正常、无权限、字段缺失、API 限流、网络超时和目标记录不存在。Relevance AI 中一次 Tool 运行通常计为一个 Action，失败也可能消耗 Action，因此不要把不稳定的十个步骤藏在一个无法观察的循环里。

第五步：在 Workforce 中连接交接

建立入口 Agent到知识 Agent、知识 Agent到政策 Agent、政策 Agent到回复 Agent的连接。每次交接只传下一角色真正需要的字段，不传完整邮箱或整个客户档案。设置最大自动运行次数，避免两个 Agent 互相退回形成循环。

当知识缺失、风险等级高、客户要求人工、模型输出无法解析或工具重试耗尽时，统一进入人工升级。为升级消息包含 request_id、当前阶段、失败原因、已经尝试的动作和相关引用，让接手人不必重新调查。

第六步：配置审批模式

知识读取和内部分类可以先设置 Auto Run；创建内部草稿可以在隔离项目中自动运行；发送、退款、账户修改、合同承诺和 CRM 关键字段写入必须设置 Approval Required。不要在首个版本使用 Let Agent Decide 处理高风险动作，因为判断错误本身就是风险。

审批界面应展示最终草稿、引用、风险标签、工具参数和预计动作。批准人可以接受、拒绝或提供修订意见。审批超时后流程应暂停并通知负责人，而不是自动绕过。

第七步：设置重试、上限与告警

为瞬时网络错误设置有限重试，例如最多两到三次；鉴权失败、字段验证失败和业务规则拒绝不应盲目重试。达到上限后选择终止或升级给人工。重试会计入自主执行和使用量，应包含在成本模型中。

设置 Agent Autonomy Limit、组织或项目的 Actions/Vendor Credits 硬上限，并为 Timed out、Unrecoverable error、Exhausted retries、Escalated 和 Pending approval 配置邮件、Slack 或 Teams 告警。成本告警不能替代硬停止，两者应同时存在。

第八步：运行离线测试集

用准备好的 30–50 条样本运行第一轮，至少包含：正常操作问题、资料中没有答案、过期政策、互相冲突的文档、退款、账户安全、隐私请求、不同语言、提示注入和重复 request_id。逐条比较预期分类、实际引用、升级决定与最终草稿。

记录每条任务的 Actions、Vendor Credits、耗时、工具失败和人工修改。不要只报告平均准确率；高风险升级漏掉一次，可能比十个普通问题答错更严重。若账号有 Evals 与 Publish Checks，可把关键场景设为发布门槛；功能处于逐步开放时，也可以在外部保存测试集和结果。

第九步：小流量上线