重构一个系统给 AI Agent 用，成本高、风险大。但大部分企业面临的情况是：老系统不能动，但需要让它变"智能"。
这篇文章不讲怎么"重写一个 AI 原生应用"，而是讲怎么给存量系统加上 AI 能力，不拆不重建。
三种存量接入模式
面对一个老系统，有三种方式让 AI 能"理解"和"操作"它：
模式一：数据库直连
Agent 直接读/写数据库
优点：最直接，不需要改系统
缺点：没有业务语义，需要自己补
模式二：API 封装
给老系统的操作封装成 API
优点：有业务语义，安全可控
缺点：老系统不一定有 API
模式三：屏幕抓取（多模态）
Agent "看"系统的 UI，模拟人操作
优点：系统完全不需要改
缺点：不稳定，延迟高
三种模式从易到难，也对应了不同的"侵蚀度"。
模式一：数据库直连
最简单粗暴的方式。让 Agent 直接连接老系统的数据库，读数据、写数据。
# Agent 工具：直接查数据库
@tool
def query_sales_data(date_from: str, date_to: str, region: str = None):
"""查询指定时间范围和区域的销售数据"""
sql = """
SELECT product, SUM(amount) as total, COUNT(*) as orders
FROM orders
WHERE order_date BETWEEN ? AND ?
"""
params = [date_from, date_to]
if region:
sql += " AND region = ?"
params.append(region)
sql += " GROUP BY product ORDER BY total DESC"
return db.execute(sql, params).fetchall()
优点：
- 存量系统完全不需要改
- 数据实时，没有延迟
- Agent 可以执行任意复杂的数据分析 SQL
风险与应对：
风险 1：Agent 写操作导致数据错误
应对：只读模式（Read-Only Agent）
如确实需要写：用独立写库，再同步回主库
风险 2：复杂查询造成数据库压力
应对：设置超时（statement_timeout）
限制并发查询数
读从库 / 只读副本
风险 3：直接暴露表结构缺乏业务语义
应对：给 Agent 提供"业务视图"而非原始表
比如 orders 表对外暴露为"销售订单视图"
模式二：API 封装
对老系统的操作封装成 RESTful API，Agent 通过 API 与系统交互。
如果你的系统已经有 API，那大半的工作已经完成了——Agent 只需要知道 API 的 endpoint 和参数。如果没有，那就封装一层：
存量系统
│
▼
┌──────────────────┐
│ AI 适配层 │
│ (新写的一层) │
│ │
│ 输入：自然语言 │
│ 处理：调用老系统 │
│ 输出：标准化响应 │
└──────────────────┘
│
▼
Agent / LLM 应用
API 封装的几个关键点：
封装粒度：
太细：Agent 需要多次交互才能完成一个业务操作
- get_user_by_id
- get_user_orders
- get_order_details
太粗：Agent 无法灵活组合
- generate_full_report（做了太多事，Agent 无法只取部分数据）
适度：每个 API 完成一个业务原子操作
- search_users(keyword, page, size)
- create_order(customer_id, items)
- get_order_status(order_id)
- cancel_order(order_id, reason)
无状态 API：Agent 不维护会话状态，每个 API 调用独立完成。这样 Agent 在重试、多轮交互时不需要考虑状态恢复。
幂等性：写操作（创建、更新、删除）应该是幂等的。Agent 可能会因为超时重试同一个操作，幂等保证不会重复扣款、重复下单。
# 幂等 API 示例：用 idempotency_key 保证不重复处理
@router.post("/orders")
async def create_order(
order_data: OrderCreate,
idempotency_key: str = Header(...)
):
# 检查是否已处理过
existing = await check_idempotency(idempotency_key)
if existing:
return existing # 返回之前的结果
# 实际处理
order = await process_order(order_data)
await save_idempotency(idempotency_key, order.id)
return order
模式三：屏幕抓取（多模态）
最极端的情况——老系统没有 API、不能直连数据库、系统甚至不是 HTTP 的（桌面应用、老式终端）。
解决方案：让 Agent "看"屏幕 + 模拟操作。本质上是 RPA（机器人流程自动化）的 AI 升级版。
Agent 收到任务："导出上个月的订单报表"
步骤：
1. 截图 → VLM（视觉语言模型）识别当前界面
→ "这是一个登录页面"
2. Agent 模拟操作：输入用户名密码，点击登录
3. 截图 → VLM 识别 → "已进入系统主页"
4. Agent 模拟操作：点击"报表"菜单 → 选择"订单报表"
5. 截图 → VLM 识别 → "已进入报表页面"
6. Agent 模拟操作：设置时间范围 → 点击导出
7. 截图 → 确认导出成功
→ 通知用户：报表已生成
这个方法看着像黑科技，但在 2025-2026 年已经有不少落地案例。Claude Computer Use、GPT-4o 的屏幕理解能力，让"Agent 看屏幕操作"从实验走向了实用。
适用条件：
✅ 适合：
- 完全无法改造的老系统（20 年前的终端系统）
- 没有 API 的第三方系统
- 临时方案（后续还是要改造）
❌ 不适合：
- 需要高频操作（截图识别太慢）
- 对一致性要求极高（识别偶尔出错）
- 涉及财务/关键业务（不确定性高）
三种模式的组合使用
实际项目中，三种模式不是互斥的。
场景：一个电商存量系统
读操作（报表查询）→ 数据库直连（模式一）
快、准、实时
写操作（下单、退款）→ API 封装（模式二）
安全、可控、幂等
无法改动的第三方组件 → 屏幕抓取（模式三）
不侵入、可独立迭代
针对同一个系统，不同模块用不同的接入方式。关键在于根据操作的风险等级和实时性要求选择对应模式。
改造路径图
从零到完成存量系统 AI 化改造的路径：
评估阶段（1-2 周）
├─ 盘点存量系统的数据源和操作
├─ 决定哪些用模式一、哪些用模式二、哪些用模式三
└─ 评估风险和优先级
基础建设（2-4 周）
├─ 模式一：创建只读数据库视图、设置超时和限流
├─ 模式二：封装核心 API（优先只读 API）
└─ 模式三：搭建截图 + VLM 识别流水线
AI 接入（1-2 周）
├─ 注册工具（数据库视图/API/屏幕操作）
├─ 编写 System Prompt
└─ 测试：从简单的查询开始
渐进扩展（持续）
├─ 先覆盖非核心操作（查询、统计）
├─ 再覆盖核心操作（审批、创建）
└─ 最后覆盖高风险操作（删除、修改）
安全加固（持续）
├─ 审计日志
├─ 操作确认门
└─ 异常告警
不要一开始就想着覆盖所有功能。从 20% 最高频的操作开始，覆盖 80% 的用户需求。剩下的 20% 需求慢慢补。
风险控制
存量系统 AI 化改造中，最常见的失败原因不是技术没做好，而是风险控制没做好。
安全原则：
1. 只读优先：默认所有操作是只读的，写操作需要显式授权
2. 操作确认：删除、修改、扣款等操作需要二次确认
3. 权限隔离：Agent 使用专门的只读账号，不做写操作
4. 审计追踪：记录 Agent 的所有操作，包括查询
灰度策略：
5% 的查询 → 观察效果、补 bad case
20% 的查询 → 稳定运行 1-2 周
80% 的查询 + 少量简单写操作 → 持续观察
全量 + 所有安全操作 → 稳定运行
总结
存量系统的 AI 化改造，核心不是技术选型，而是在不改变现有系统的基础上找到 AI 的切入方式。
三个原则：
- 不动存量——能不改造老系统就不改造，加一层而非改一层
- 从读开始——只读查询是 AI 化改造最安全、最快见效的切入点
- 渐进、安全——覆盖 20% 的功能就能解决 80% 的需求，从灰度高到全量逐步放开
存量系统的 AI 化不是一场革命，而是一个渐进式的嵌入过程。最快的方案不一定是数据库直连、也不一定是 API 封装，而是先做起来的那一个。
评论