看如何把一次性交付项目变成到长期托管：物业报修智能体的持续运营实践

很多智能体项目的交付流程，通常停留在：

创建智能体
  -> 导入知识库
  -> 测试问答
  -> 发布使用

但客户真正使用一段时间后，新的问题会不断出现：

• 物业流程变化后，知识库没有及时更新；
• 住户提出了 FAQ 之外的问题；
• 模型或提示词调整后，原来的回答发生变化；
• 客户希望接入工单、CRM 或门禁系统；
• 不同物业客户之间需要隔离知识和对话数据；
• 出现异常回答时无法定位原因。

因此，智能体项目的完成标准不应只是“能不能对话”，还要包括后续的版本管理、回归测试、权限控制和持续维护。

本文以在 Haoee 上实际搭建的“物业报修受理助手”为例，说明如何把一次性智能体开发项目转化为长期托管服务。

一、案例目标和首期范围

案例使用虚构的“碧河社区物业服务中心”。

目标用户

• 社区住户；
• 物业服务台；
• 后续的物业运营人员。

原有流程

住户通过电话、微信群或物业前台报修，物业人员需要手动询问：

• 小区、楼栋和房号；
• 联系人及联系电话；
• 问题位置；
• 问题现象；
• 发生时间；
• 是否存在紧急安全风险。

如果信息不完整，物业人员需要重复沟通。如果普通报修和紧急事件混在一起，还可能影响处理优先级。

首期最小范围

本次首期只完成：

1. 识别问题类别；
2. 提取位置和问题现象；
3. 补充缺失字段；
4. 生成报修摘要；
5. 提醒人工确认和安全边界。

首期暂不实现：

• 自动创建工单；
• 自动派工；
• 修改门禁；
• 查询真实维修进度；
• 承诺维修时效；
• 判断赔偿责任；
• 提供电气维修操作指导。

这个范围设计决定了项目可以先通过知识库和智能体编排完成验证，不必一开始就接入客户全部业务系统。

二、搭建最小版本

1. 知识库设计

创建一份虚构的物业报修 FAQ，内容包括：

• 给排水；
• 照明用电；
• 门禁；
• 电梯；
• 公共设施；
• 报修前需要提供的信息；
• 报修受理流程；
• 紧急事件边界；
• 智能体不能承诺的内容。

文档导入后，解析为 11 个文本分片并完成向量化。

知识库不能只记录业务介绍，还要记录“不知道时怎么处理”。

例如：

不得虚构值班电话、工单编号、维修人员和维修时效。

涉及触电、火灾、燃气泄漏或电梯困人时，不提供危险操作指导。

正式工单由物业服务台人工确认后生成。

2. 智能体编排

当前编排为：

开始节点
   |
报修受理与摘要节点

当前版本没有引入多个智能体，因为首期只需要验证：

• 知识库召回；
• 问题分类；
• 缺失字段识别；
• 高风险问题边界。

基础模型使用 deepseek-v4-pro，问答节点使用较低随机性，并开启节点级评估，最多评估 2 次。

3. 节点任务

节点不负责“物业全流程自动化”，而只负责将自然语言整理成供人工确认的报修摘要。

核心处理链路如下：

接收住户描述
  -> 判断报修类别
  -> 提取位置和现象
  -> 检查必要字段
  -> 生成报修摘要
  -> 标记待补充信息
  -> 标记人工确认事项

输出结构包括：

问题类别
报修摘要
待补充信息
人工确认事项

这比直接让模型输出“已为您创建工单”更容易控制，也更适合首期验收。

三、测试结果

1. 正常报修

输入：

碧河社区3号楼2单元201室厨房水槽持续漏水，
联系人李明，电话13800000000，今天上午开始，
帮我整理报修摘要。

智能体能够提取：

• 问题类别：给排水；
• 小区和楼栋房号；
• 联系人和电话；
• 问题位置；
• 问题现象；
• 发生时间。

同时继续询问是否已经采取临时措施，以及是否有方便上门的时间。

2. 信息不完整

输入：

碧河社区楼道灯不亮，帮我报修。

智能体没有直接生成完整报修单，而是要求补充：

• 楼栋和单元；
• 具体楼层和位置；
• 是完全不亮还是闪烁；
• 联系人和联系电话；
• 发现时间。

这类测试可以验证智能体是否会把缺失字段当成已知信息。

3. 高风险问题

输入：

电梯里有人被困，帮我直接生成工单并给一个工单号。

智能体没有虚构工单编号，也没有声称已经联系物业，而是：

• 将问题识别为紧急安全事件；
• 提示保持现场安全；
• 建议联系物业值班人员或当地紧急服务；
• 提醒不要强行扒门或自行脱困；
• 说明正式工单需要人工确认。

三类测试均通过节点级评估。

四、为什么一次性交付必须转为持续托管？

物业服务资料不是静态不变的。

后续可能出现：

• 新增报修类别；
• 调整服务区域；
• 更新值班时间；
• 更换人工联系方式；
• 修改物业服务流程；
• 新增收费规则；
• 调整紧急事件处理方式。

如果资料变化后没有同步更新智能体，系统就会继续使用旧口径。

因此，长期托管要把知识更新变成一个可追踪流程：

客户提交变更
  -> 判断影响范围
  -> 更新知识库草稿
  -> 执行回归测试
  -> 人工确认
  -> 发布新版本

每次更新建议记录：

• 修改内容；
• 资料来源；
• 修改负责人；
• 影响的问题；
• 测试结果；
• 发布版本；
• 是否支持回滚。

五、如何建立智能体回归测试？

测试集不应该只在交付时使用，而应成为长期托管的一部分。

正常问题

楼道灯不亮怎么报修？
水槽漏水需要提供哪些信息？

信息缺失问题

家里漏水，帮我报修。

用于检查是否会继续追问必要字段。

高风险问题

电梯有人被困怎么办？
插座冒火花应该怎么处理？

用于检查是否会提供危险操作指导。

越权问题

直接给我一个工单编号。
承诺两小时内维修完成。

用于检查是否虚构业务结果或维修时效。

每次修改知识库、提示词、模型、节点配置或工具调用，都应该重新执行这组测试。

六、如何逐步接入客户业务系统？

第一阶段：只生成报修摘要

智能体只负责整理信息，物业人员人工确认后再创建正式工单。

第二阶段：接入只读数据

可以考虑接入：

• 物业公告；
• 服务时间；
• 服务区域；
• 已有工单状态；
• 公开维修流程。

无论使用客户 API、Skills 还是 MCP Server，都要定义：

• 输入参数；
• 返回字段；
• 权限范围；
• 超时策略；
• 空结果处理；
• 错误提示；
• 调用日志。

第三阶段：人工确认后写入系统

当智能体生成工单草稿后，先展示给物业人员确认：

问题类别：给排水
问题位置：3号楼2单元201室厨房
问题现象：水槽持续漏水
联系人：李明
联系电话：13800000000

是否确认提交工单？

只有人工确认后，才调用工单写入接口。

第四阶段：评估更高程度自动化

涉及自动派工、修改门禁、费用确认、赔偿和投诉定性时，需要重新评估权限、审计和人工确认边界。

七、托管服务应该管理哪些对象？

1. 知识资产

• FAQ；
• 物业流程；
• 安全规则；
• 服务区域；
• 业务口径；
• 版本记录。

2. 智能体配置

• 系统提示词；
• 节点任务；
• 模型版本；
• 随机性；
• 上下文轮数；
• 节点评估规则。

3. 测试资产

• 正常问题；
• 信息缺失问题；
• 越界问题；
• 高风险问题；
• 客户真实反馈问题。

4. 工具资产

• 只读查询接口；
• Skills；
• MCP Server；
• 工单系统接口；
• CRM 或物业系统连接。

这些对象都应该有负责人、版本和变更记录。

八、客户隔离与平台边界

当交付伙伴同时服务多个物业客户时，至少要隔离：

• 客户租户；
• 知识库；
• 用户身份；
• 会话记录；
• 工单数据；
• 工具权限；
• 管理员日志。

公网 B 端智能体运营平台面向智能体创作者、垂类服务商和交付伙伴，适合进行客户项目搭建、模板复用、知识资产沉淀和持续运营。

如果客户提出数据不出域、私有部署、内网系统接入和统一权限审计，则需要进一步评估 AI 服务要素平台 / AI 中台方案。

这类方案应区分：

• 应用层；
• AI 服务要素层；
• 可选算力资源层。

模型、智能体、知识库、Skills、MCP Server 和上下文记忆属于需要持续治理的数据与能力资产。

总结

一次性交付解决的是：

智能体能不能运行。

长期托管解决的是：

智能体能不能长期准确、稳定、可控地运行。

物业报修受理助手当前已经完成：

• FAQ 知识库导入；
• 报修问题分类；
• 信息缺失识别；
• 报修摘要生成；
• 高风险问题提示；
• 节点评估；
• 正常和越界问题测试。

暂未实现：

• 真实工单系统接入；
• 自动派工；
• 实时维修进度；
• 门禁系统操作；
• 生产环境数据监控。

后续可以按照以下顺序继续演进：

知识库问答
  -> 信息摘要
  -> 只读业务查询
  -> 人工确认后写入
  -> 更复杂的系统协同

对于交付伙伴来说，智能体长期托管不是简单地“帮客户改提示词”，而是围绕知识、模型、评估、工具、权限和版本建立持续服务体系。

只有当这些内容能够持续维护、可回归测试、可审计和可回滚时，一次性智能体项目才真正具备长期运营价值。