# 旧系统不必重建，先接出几个值得复用的操作 | EasyNet

Source: https://easynet.run/cases/problems/controlled-legacy-system-operations

[easynet.run · 全部问题场景](https://easynet.run/cases#problem-scenarios)

# 旧系统不必重建，先接出几个值得复用的操作

客服只是想知道一张维修单修到哪一步，却要退出正在使用的助手，登录旧系统，按编号查询，再把结果复制回来。讨论让助手代查时，团队很快谈到了迁移数据库、替换软件。一个每天重复的小动作，变成了整套系统改造。

先把需求缩回这张维修单：只要状态和更新时间，不需要整个客户档案，更不需要修改工单。检查原系统是否已有查询接口、可用的导出方式或现成集成。固定时间看报表，定时导出就可能够用；要随问随查，才需要稳定的查询入口。

假设原系统已有接口，开发人员可以写一小段程序，接收维修单编号，用专门的只读账号查询，只返回允许展示的字段。EasyNet 接入的是这段程序，不是替旧系统凭空创造接口。原厂许可、账号权限和访问网络都要先确认。

当客服助手、内部机器人都想使用同一个查询时，再把它作为函数接入 EasyNet。程序继续运行在能够访问旧系统的环境里，各调用方使用获准的入口，不必分别实现一套旧系统集成。程序由谁维护、设备离线时如何恢复，也要一起交代。

限制不能只写在助手提示词里。接入程序要校验编号，按调用者允许查看的范围查询，并拒绝任意 SQL 或管理员操作。需要追查时，还应把业务查询与调用记录关联起来；有运行记录不等于已经满足所有业务审计要求。

先在测试环境对照同一张维修单的结果，再试不存在的编号、无权查看的工单和旧系统不可用的情况。如果只能模拟点击，界面变化和验证码仍可能打断流程，EasyNet 不会消除这类不稳定性。

只读查询能稳定交给第二个助手后，再决定是否值得扩大范围。改状态、退款或取消订单需要另外设计审批、重复请求处理和恢复办法，不能因为查到了一条记录，就顺手开放整套系统。

01

询问维修编号

只需要进度与更新时间

02

只读适配

检查身份、编号与字段

03

保留原系统

复用已有接口，不迁移数据库

原系统继续负责业务，助手只复用维修进度查询。

只投影维修进度字段

合成记录的本地输出过滤，不连接旧系统，也不实现对象授权。真实适配器先完成权限检查再做此投影。
本地示例 · python

```
record = {"ticket": "R-17", "status": "awaiting-part",
          "updated_at": "2026-09-07T09:00:00Z",
          "customer_phone": "synthetic", "internal_note": "staff-only"}
public = {key: record[key] for key in ("ticket", "status", "updated_at")}
assert "customer_phone" not in public and "internal_note" not in public
print(public)
```

预期结果：只返回R-17的进度与时间，不含电话和内部备注。

接入时的检查项

返回值是否与原系统同一对象的结果一致。

越界参数是否不会触发通用查询。

旧系统不可用时是否明确失败且不编造缓存结果。

源码与接入资料

[函数接入指南](https://easynet.run/docs/connect/function)

[设备接入指南](https://easynet.run/docs/connect/runtime)