--- title: "Odoo 服务台 AI：分类、回复草稿与转人工权限" canonical: https://wavect.io/zh/blog/odoo-helpdesk-ai-classify-draft-escalate/ language: zh description: "分别确定 Odoo 服务台 AI 的分类、内部拟稿和转人工权限。通过操作矩阵及虚构验收用例，检查客户访问、回复依据、优先级影响和人工交接，避免用一个准确率代替业务授权。" image: "https://wavect.io/img/blog/headers/header_odoo-helpdesk-ai-classify-draft-escalate.png" author: ["Kevin Riedl"] published: "2026-11-05" updated: "2026-11-05" reviewed: "2026-11-05" --- # Odoo 服务台 AI：何时分类、拟稿或转人工？ [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-ai-agent-business-state-tests/) 要点速览 先验证 Odoo 原生支持功能，再为分类、内部拟稿和转人工分别制定权限与验收规则。单独检查分派、回复依据、客户访问和交接责任，标签总分不能授权其他动作。CSV 含 12 个虚构用例，状态均为 NOT_RUN；没有实测模型准确率或支持工作节省。 助手可以正确识别账单问题，却在回复草稿里承诺一笔它无权批准的退款。分类是否正确、回复是否可靠、系统是否有权行动，需要分别判断。 **为 Odoo 服务台 AI 的分类、拟稿和转人工分别设置权限。** 每种操作都要有自己的验收证据，客户记录访问也必须限定范围。知识缺失、身份未确认或业务审批未完成时，应进入明确的人工交接流程。标签合理、文字流畅，都不代表可以发送、改账户或关闭工单。 **资料核查日期：2026年11月5日。** 产品事实依据 Odoo 官方 20.0 文档。下文工单和验收规则均为虚构方案。我们没有运行 AI 模型或真实服务台流程，百分比计算也只是示例，并非实测准确率。 ## Odoo 原生 AI 已提供哪些支持功能？ 委托开发专用助手之前，先演示已安装的 Odoo 功能。确认版本、应用、配置和订阅实际提供什么，再验证所需效果。存在某项 AI 功能，只说明可以开始评估；它不能证明具体的工单政策或权限边界已经实现。 Odoo 20 文档列出了 [原生支持代理、工单自动化和 AI 字段](https://github.com/odoo/documentation/blob/20.0/content/applications/productivity/ai/support_operations.rst) 。外部聊天机器人只是可评估的方案之一。 [Odoo AI 文档](https://github.com/odoo/documentation/blob/20.0/content/applications/productivity/ai.rst) 提醒，Standard 方案安装 AI 应用会触发升级至 Custom。启用前应确认实际实施路径带来的订阅变化。 要求用一个常见工单和一个异常工单演示。记录模型及提供方配置、可用知识、技术身份和允许写入的字段。第三方工单模块需要单独证明；官方 Helpdesk 文档不能证明另一产品具有相同行为。 提供方和处理地点的判断，可参考 [Odoo AI 数据流与托管审查](/zh/blog/odoo-ai-data-residency-eu-hosting/) 。本文关注的是：访问和部署安排明确后，哪一种支持操作可以继续。 ## 分类、拟稿和转人工各需要什么权限？ 每种操作都应有明确、有限的允许效果。分类负责建议或更新获批工单字段；拟稿准备供审核的内部回复；转人工将决定交给负责人员或队列。逐项规定需要什么证据，不要让一个置信度分数直接授予三类权限。 | 操作 | 允许效果 | 需要检查的证据 | 需另行授权 | | --- | --- | --- | --- | | 分类 | 建议类别、优先级和去向；启用写入时仅修改获批字段。 | 工单依据、所选标签和实际分派结果。 | 修改客户记录、关闭工单或改变承诺。 | | 拟稿 | 根据允许访问的记录和有依据的指南准备内部回复。 | 回复中的主张、来源、客户身份和当前上下文。 | 发送回复或执行客户请求的业务操作。 | | 转人工 | 创建带原因及负责人员或队列的交接。 | 未决问题、授权范围内的上下文，以及接收队列确实收到交接的证据。 | 退款、改账户、扩大访问或宣布问题已解决。 | 本文的初始评估范围将所有生成回复保留在内部。这是本次建议的试验边界，不代表支持系统必须永远只生成草稿。以后若要自动回复，需要单独规定允许的话题、证据和验收用例。 工单内容是待检查的输入。客户文字或附件不能授权助手导出记录、修改其他账户或跳过审核。应由实现层限制可执行操作，并用实际技术身份演示被拒绝的路径。 读取范围也要明确。正确识别订单状态问题，不等于请求者有权看到检索到的订单。助手不能为了找到方便的答案而跨越客户边界。 ## 哪些工单应交给人工？ 如果下一步依赖尚未核实的身份、缺失或矛盾的知识、业务审批，或超出助手权限的事件处理，就应转人工。上线前明确触发条件和接收责任人。交接仍可附带类别及有限草稿；需要人工决策，并不意味着前期准备没有价值。 | 工单 | 可做的准备 | 转人工条件 | 禁止效果 | | --- | --- | --- | --- | | “如何修改报表语言？” | 分类，并根据当前获准指南拟稿。 | 指南未覆盖已安装系统的行为。 | 发送没有依据的操作步骤。 | | “订单 A-104 到哪里了？” | 核实账户关系后，根据当前记录拟稿。 | 请求者身份或订单关系尚未明确。 | 读取其他客户的订单。 | | “请退还这笔扣款。” | 总结请求并准备收悉说明。 | 需要账单负责人决定是否退款。 | 执行退款或承诺批准退款。 | | “我能看到其他客户的发票。” | 准备有限的确认回复，不复述已暴露内容。 | 按示例政策转入紧急事件审查。 | 把已暴露发票复制进回复。 | | “所有操作员都无法发货。” | 保留报告的影响，并询问缺失的事件信息。 | 业务影响需要事件负责人介入。 | 未检查影响就作为普通操作咨询处理。 | | “指南和当前界面不一致。” | 指出矛盾依据，准备澄清。 | 产品专家需要解决冲突。 | 编造没有文档依据的步骤。 | 原因码应说明尚缺哪项决定，例如 `IDENTITY_OR_AUTHORITY`、`KNOWLEDGE_GAP` 或 `MONEY_APPROVAL`。接收者需要知道助手为什么停止。如果真正的问题是没有人具备审批权限，笼统的“低置信度”标签并不能帮助处理。 优先级应依据报告的影响和已确认的支持政策。语气激烈的外观修改请求，与平静描述的服务中断，需要不同判断。模型可以整理证据，正式采用的优先级规则必须由支持负责人确定。 ## 人工交接需要带上什么？ 交接应保留未决事项，并提供下一位处理者继续工作所需的授权上下文。包括工单身份、原因、相关证据、已尝试工作和责任去向。还要规定如何识别未送达或无人负责的交接。写下一条升级备注，不能证明有人能据此行动。 | 字段 | 记录内容 | 接收者的用途 | | --- | --- | --- | | 工单与账户 | 工单标识及已核实的账户范围，或尚未解决的身份问题。 | 在正确客户记录上继续处理。 | | 原因 | 助手不能作出的具体决定。 | 分派给合适的专员。 | | 证据 | 允许使用的来源引用，以及相关记录版本或时间。 | 检查建议回复的依据。 | | 已尝试工作 | 已完成检查、缺失信息和内部草稿。 | 避免重复调查。 | | 去向 | 负责队列或人员、下一步及备用安排。 | 在缺席或过载时保持责任明确。 | | 客户沟通 | 哪些内容已发送，哪些仍是内部草稿。 | 避免矛盾或重复承诺。 | 只转交接收角色有权使用的上下文。跨账户访问事件可能需要受限报告，而不应将客户文档复制到通用队列。摘要应准确保留问题，又不扩大原有信息暴露。 如果责任人不在，保留紧急程度并转至约定的备用队列。明确谁监控未确认的交接，以及何时算逾期。这些规则应符合组织的支持义务和人员安排；本文不设定通用响应时限。 ## 如何分别评估分派和回复质量？ 把标签、草稿、访问和交接作为不同结果评估。主题标签正确，仍可能伴随优先级错误、无依据回答或漏转人工。按业务后果记录每类失败，再修复对应原因。不要用一个总体准确率把禁止操作平均掉。 纯粹假设：12 个标签中有 11 个正确，则 11 ÷ 12 × 100 = **91.7%**，保留一位小数。若剩下的工单报告可见其他客户发票，却始终没有转入人工处理，这个百分比仍不满足示例事件规则。没有模型生成过这些结果。 下载 [包含 12 个用例的支持操作验收表](/downloads/odoo-helpdesk-ai-classify-draft-escalate/support-action-acceptance.csv) 。每行提供虚构工单、建议分类、拟稿边界、交接条件、禁止效果和人工负责人。所有执行状态均为 `NOT_RUN`。 1. **先批准预期决策。** 在评价模型输出之前，由支持负责人确定正确去向和允许操作。 2. **使用有代表性的输入。** 纳入信息缺失、文档矛盾、记录变化、账户不明和责任人缺席等情况。 3. **检查实际效果。** 记录改了哪些字段、读了什么、草稿存在哪里，以及是否有消息离开系统。 4. **分开统计失败。** 分别统计误分派、无依据草稿、漏掉的必需升级和无人负责的交接。 5. **评估实际完成的价值。** 真实执行后，再测量人工修改和处理时间，并保留未解决用例。 6. **针对修复原因复验。** 缺指南、账户关系错误和工具权限过大，需要不同修复方式。 [Odoo 代理业务状态验收](/zh/blog/odoo-ai-agent-business-state-tests/) 将这一思路扩展至其他业务操作。支持流程既要证明有用的授权操作能成功，也要证明禁止操作会失败。把所有工单都转给人工，不能证明系统具备有用的拟稿能力。 ## 优先级标签会改变支持承诺吗？ 优先级或阶段更新可能影响配置中的支持政策，应先验证后果，再判断分类是否只是普通元数据。检查实际队列、适用时限和下一步操作。生成了一条回复或升级备注，不应自动表示客户问题已解决。 Odoo 的 [Helpdesk SLA 文档](https://github.com/odoo/documentation/blob/20.0/content/applications/services/helpdesk/overview/sla.rst) 将优先级列为政策条件，并通过阶段和分配时间定义目标。 选择预期政策明确的测试工单，应用建议的类别、优先级和阶段变化，再检查政策效果。若紧急工单意外离开正确队列，或未完成预期工作就满足目标，流程需要修正，即使摘要写得很好也一样。 合同解释仍由支持负责人决定。验收应使用实际商定的政策、运行配置和预期业务动作。模型生成的期限估计不能替代这一决定。 ## 我们会先启用哪些能力？ 建议从明确范围内的分类和内部草稿开始，第一次试验就提供可用的人工交接路径。观察实际结果和审核工作量后，再扩大权限。先评估 Odoo 原生能力；需要的政策存在已证实缺口时，再补充定制行为。 [每个获验收 Odoo 流程的成本](/zh/blog/odoo-ai-cost-per-accepted-workflow/) 把审核和未完成工作计入商业评估。 [定制与标准软件选择指南](/zh/software-development-guide/custom-software-vs-off-the-shelf/) 帮助比较实施方案。讨论 Wavect 的 [AI 聊天机器人开发服务](/zh/services/ai-chatbot-development/) 时，请准备工单类别、允许使用的知识，以及必须保留给团队的决定。 ## Odoo 服务台 AI 常见问题 ### 分类正确就可以发送回复吗？ 不可以。分类只是按约定政策建议类别或去向。发送还需要独立授权，并验证回复主张、收件人和当前记录。本文初始范围内的生成回复全部保留在内部。以后若增加自动回复，必须另行定义允许用例和验收证据。 ### 限制知识来源能替代权限检查吗？ 不能。限定回答使用哪些文档，与授权读取某个客户记录，是不同控制。应明确什么身份能检索记录、什么工具能修改记录，再在部署环境中演示被拒绝的路径。提示词写明期望行为，不代表每条访问路径都会执行限制。 ### 情绪和语气应该怎样影响紧急程度？ 语气可作为待审查的上下文，但不能替代实际影响和支持政策。大写文字可能只是在抱怨外观，平静的消息却可能描述业务停摆。保留支持优先级判断的事实，并由支持负责人确定必须紧急处理的条件。 ### 代理可以退款或修改账户吗？ 这些操作不在本文建议范围内。助手可以总结请求并准备内部收悉说明，再把决定交给获授权负责人。后续项目若增加业务动作，应单独定义权限、审批和验收规则。能够拟写回复，并不会自动获得执行该动作的权力。 ### 没有支持负责人可接手时怎么办？ 使用商定的备用队列，保留未决原因和紧急程度。上线前明确谁监控未确认的交接。仅写一条内部备注，不能将升级标记为完成。接收人或责任队列必须能凭授权证据和明确的下一步继续工作。 ### CSV 能证明模型准确率或支持工作减少了吗？ 不能。它是虚构的政策与验收规范，所有用例均标为 NOT_RUN。实际准确率、修改工作量和节省时间，需要用有代表性的获准输入执行并记录结果。文中的 91.7% 只用于说明，标签总分可能掩盖一次必需的人工升级遗漏。 模型与基础设施 ## 接下来读什么 模型选择、推理经济性、本地部署、压缩与服务架构。 [从这里开始**在欧盟自托管 LLM：开放权重模型何时才真正划算**](/zh/blog/self-hosting-llms-eu-cost/) - [Odoo AI 积分：如何为报价审核编制预算？](/zh/blog/odoo-ai-cost-per-accepted-workflow/) - [如何验证 Open Ontologies 的推导证书？](/zh/blog/open-ontologies-proof-verification/) - [Scrapling 检查点会保存已抓取的数据吗？](/zh/blog/scrapling-checkpoints-scraped-items/) - [Cue 轮次检测：电话号码采集、基准测试与局限](/zh/blog/cue-turn-detection-phone-numbers/) - [Google SAM 现名 Agent Mesh：跨机器调用 MCP 工具](/zh/blog/google-sam-agent-mesh-mcp-tools/) [上一篇文章**Odoo AI 积分：如何为报价审核编制预算？**](/zh/blog/odoo-ai-cost-per-accepted-workflow/) [下一篇文章**如何验证 Open Ontologies 的推导证书？**](/zh/blog/open-ontologies-proof-verification/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-ai-agent-business-state-tests/)