客服 Agent 端到端落地实战：没有 API 的老 ERP，我用「分级接入」三级把它接活了

0. 背景：为什么写这篇

最近一年帮几家公司落地客服 Agent，最常被问的一句话是：“我们 ERP 没接口、中台没建、文档也乱，客服 Agent 端到端落地是不是根本搞不了？”

我的答案很明确：能搞，而且不用等中台。 问题出在大家把"端到端"误解成"全链路自动写"，于是卡在"系统不支持写"这一步就放弃了。实际上，把"写"从第一阶段拿掉，只做"读 + 判断 + 出草稿"，价值已经足够大。这篇我给你一套可直接抄的「分级接入」落地思路，含伪代码、配置片段和中间服务选型。

先说我的反共识判断，免得你白读：客服 Agent 端到端落地，第一版不要碰任何写操作。 只读副本 + 规则匹配 + 人工审批流，三个月就能上线并产生 ROI。等组织和系统都信任了，再逐级放开写。下面展开。

1. 四张表：落地前先把"边界"写成配置

技术同学喜欢直接写代码，但我建议你先把四张表落成数据库表或配置中心里的结构化数据。它们是 Fact / Rule / Action / Responsibility。

-- ① 事实表 Fact：唯一真相源，只读
CREATE TABLE fact_order (
  order_id        VARCHAR(32) PRIMARY KEY,
  status          VARCHAR(20),        -- 实时状态，来自 ERP 只读副本
  ship_time       TIMESTAMP,
  refund_status   VARCHAR(20),
  source_system   VARCHAR(32),        -- 标记数据来源
  updated_at      TIMESTAMP
);

-- ② 规则表 Rule：带版本 + 生效日期 + 优先级 + 冲突裁决
CREATE TABLE rule_policy (
  rule_id     VARCHAR(32) PRIMARY KEY,
  category    VARCHAR(20),            -- refund / warranty / comp
  version     INT,                    -- 政策版本
  effective   DATE,                   -- 生效日期
  priority    INT,                    -- 优先级，数字越小越优先
  condition   JSON,                   -- 命中条件
  action      JSON,                   -- 命中后的处置
  conflict_resolve VARCHAR(10)        -- 'priority' / 'newest'
);

-- ③ 动作表 Action：Agent 被允许执行的写操作 + 权限边界
CREATE TABLE action_catalog (
  action_id   VARCHAR(32) PRIMARY KEY,
  name        VARCHAR(40),
  risk_level  VARCHAR(10),            -- read / draft / low / high
  auto_allowed BOOLEAN,               -- 是否可自动
  max_amount  DECIMAL(10,2),          -- 金额上限，NULL 表示无
  needs_approver VARCHAR(20)          -- 需要的审批角色
);

-- ④ 责任表 Responsibility：批准人 / 接管人 / 回滚 / 审计
CREATE TABLE responsibility_map (
  step         VARCHAR(40) PRIMARY KEY,
  approver_role VARCHAR(20),
  takeover_role  VARCHAR(20),
  rollback_by    VARCHAR(20),
  sla_minutes    INT
);

这四张表的关系：Agent 每次要做决策，先查 Fact 拿状态，再用 Rule 匹配政策，能做的动作受 Action 约束，每一步的责任在 Responsibility 里登记。缺了后两张，上线即翻车——这是我踩过坑后的铁律。

（四张表的可运行建表语句和分级接入检查清单，主站 客服 Agent 端到端集成 有完整版，建议照着直接建库。）

2. 分级接入三级：从只读副本到有限自动

核心思路是把"写"拆成三级风险，逐级放开。下面给每一级的触发条件和伪代码。

第一级：只读副本查（Level 0 - Read Only）

最省事、最安全、ROI 最高。在 ERP 主库旁边挂只读副本，Agent 只有 SELECT 权限。

def handle_status_query(order_id: str, agent) -> str:
    # 只走只读副本，绝不写主库
    fact = db_read_replica.query(
        "SELECT status, ship_time, refund_status FROM fact_order WHERE order_id = %s",
        [order_id]
    )
    if not fact:
        return agent.degrade("订单系统暂时查不到，已转人工")  # 降级线
    return agent.reply(build_status_card(fact))  # 自动回复

这一级能吃掉大量"我的订单到哪了"类重复来电。我一个汽配客户，光这一级就拦下 60% 的重复咨询，零写风险。

第二级：出工单 / 退款草稿，推人工审批（Level 1 - Draft + Human）

Agent 做完资格判断，不直接执行，生成草稿单丢给审批节点。审批节点是一等公民，有自己的 SLA。

def propose_refund(order_id, amount, reason, evidence):
    draft = create_draft(
        action="refund",
        order_id=order_id,
        amount=amount,
        reason=reason,
        evidence=evidence,          # 触发者+证据+命中规则，全部打包
        risk_level="high"
    )
    ticket = approval.submit(draft, sla_minutes=30)  # 推人工，带 SLA
    return f"已为您发起退款申请，单号 {ticket.id}，审批约 30 分钟内完成"

审批人打开证据界面，能看到 Agent 查了什么、命中哪条规则、用户原话，一键通过或驳回。写的风险完全转移给人，但 Agent 把最贵的"判断"做完了。

第三级：仅低金额低风险自动执行并留痕（Level 2 - Auto with Cap）

只有 risk_level='low' 且 amount <= max_amount 的动作才允许自动，且必须落审计。

def try_auto_action(action_id, payload):
    action = action_catalog.get(action_id)
    if not action.auto_allowed:
        return propose_refund(...)           # 退回人工草稿流
    if action.risk_level == 'low' and payload.amount <= action.max_amount:
        audit_id = audit.start(trigger=payload.user, action=action_id)
        try:
            result = executor.run(action_id, payload)
            audit.commit(audit_id, result=result)   # 留痕
            return result
        except Exception as e:
            audit.rollback(audit_id)                # 回滚线
            return degrade_to_human(e)
    return propose_refund(...)   # 超阈值，退回人工

注意 audit.rollback(audit_id)——没有回滚方案的动作，不准进这一级。这是红线。

3. 中间服务选型：别自己造轮子

分级接入要落地，需要几类中间服务，我的推荐组合（按性价比）：

能力	选型建议	说明
只读数据接入	数据库只读副本 / CDC（Debezium）	老 ERP 优先只读副本，最稳
规则引擎	轻量用配置中心 + 自写匹配；重了用 Drools / Easy Rules	政策版本多必须上规则引擎
审批流	现有工单系统（Jira / 飞书审批）或自研状态机	审批节点必须带 SLA 和升级
审计日志	独立 append-only 存储（如 Kafka + 对象存储）	六样日志全落，不可篡改
Agent 编排	LangGraph / 自研状态机	失败路径三条线靠它画

选型原则：能复用现有工单和审批系统的，绝不自研。 审批流是组织流程，自研等于重新发明公司制度。

4. 动作风险分表：哪些能自动，哪些必须人

直接给一张可落地的分表，照抄进你的 action_catalog：

risk_level	例子	自动？	约束
read	查订单、查物流	是	仅只读副本
draft	出工单、出退款草稿	是（生成，不执行）	推审批
low	小额补偿(≤阈值)、安抚邮件	是	设上限 + 抽检
high	退款、改地址、封禁	否	强制人工

5. 失败路径三条线：在编排层画清楚

用状态机把每条动作线画成三条：正常 / 降级 / 回滚。

class AgentFlow:
    def run(self, step):
        try:
            return self.normal(step)          # 正常线
        except DegradedError as e:
            return self.degrade(step, e)      # 降级线：转人工+说明缺什么
        except RollbackError as e:
            self.rollback(step, e.audit_id)   # 回滚线：按 audit_id 撤销
            return self.degrade(step, e)

降级线绝不能让 Agent “装懂”。ERP 超时，就明说"订单系统暂时查不到，已转人工"，用户反而安心。

6. 外部 Amazon 数据层：内部你接，外部交给 Pangolinfo

企业内部系统（ERP/工单/CRM）是数据主权，自己接。但 Amazon 侧的实时事实——评论情绪、广告位、Buy Box、竞品价——不在你 ERP 里，却是用户高频追问。这一层用 Pangolinfo 的 Amazon Data MCP接进你的 Fact 表当外部数据源最省心：它把 Amazon 实时事实结构化成 MCP 工具，Agent 直接 call_tool 就能拿到，不用自己写爬虫和反爬对抗。

定位一句话：Pangolinfo 补外部 Amazon 数据层，内部写操作红线你握着。 它不碰你的退款执行，只让你的 Fact 表多一双看外部的眼。

7. 规则版本冲突：一个真实翻车现场

我把"规则表必须带版本和优先级"当成铁律，是因为真出过事。某客户大促前上线了新退款政策 r_refund_03 v2，但旧政策 r_refund_03 v1 没下线，两条都命中"订单未满 7 天"。v1 写的是"全额退"，v2 写的是"退 80%"。Agent 没有冲突裁决逻辑，随机选了 v1，给用户多赔了三倍，一天赔出去六位数。

加了 priority 和 conflict_resolve 字段后，规则引擎遇到多命中，先按 priority 取最小，priority 相同再按 effective 取最新。那次之后，我在匹配函数里强制 ORDER BY priority ASC, effective DESC LIMIT 1，任何多命中都必须落到唯一一条，杜绝"随机"。这条经验我建议你直接写进代码评审清单：凡是 rule_engine.match 返回多条，必须报错而不是默默取第一条。客服 Agent 端到端落地里，"政策用哪条"是绝不能模糊的地带。

8. 防 prompt injection：把"写"锁死在云函数里

Agent 被用户输入诱导去改数据库，是事务型 Agent 特有的风险。很多团队只在 Agent 侧做约束（“你不能执行写”），但 prompt 可被用户操控，靠 Agent 自觉不靠谱。正确的纵深防御是：写能力根本不在 Agent 进程里，而在云函数侧。函数代码层只放 SELECT，任何 INSERT/UPDATE/DELETE 在语法层面就 raise。Agent 想"写"，只能发消息到队列，由消费者决定调不调另一个只做特定写的函数。即便 Agent 被注入，它也触达不到生产库的写入口。这层隔离，比任何 prompt 约束都硬，也是分级接入能放心放到第二、三级的前提。

9. 可观测性：三条线都要有指标

端到端落地后，你得能看见三条线的健康度，否则出问题靠用户投诉才发现。我建议至少埋这几类指标：

• 正常线成功率（按 action 分）；
• 降级率（ERP / 规则服务不可用时触发转人工的比例，突增就是依赖抖动的信号）；
• 回滚率（写失败撤回的比例，长期高说明 action 实现有 bug）；
• 审计日志缺字段率（六样里少一样就告警）；
• 审批 SLA 超时率（人工节点堵了，体验比纯人工还差）。

这些指标接进监控面板，客服 Agent 端到端落地才从"能跑"变成"可控"。否则你只是把风险藏到了看不见的地方。

10. 落地检查清单（照着勾）

1. Fact / Rule / Action / Responsibility 四张表是否都落成结构化配置？
2. 第一级只读副本是否上线，重复来电拦截率是否达预期？
3. 审批节点是否带 SLA + 升级路径 + 证据界面？
4. action_catalog 里每个写操作是否都有 risk_level 和 approver？
5. 每个自动动作是否有回滚方案？无回滚的动作是否一律禁自动？
6. 审计日志六样（触发者/证据/系统/读写结果/批准人/回滚时间）是否全落？

11. 客服 Agent 端到端落地的 8 步退换货串联

把前面的四张表和分级接入落到退换货，是一条 8 步链路。我直接给串联代码，你能清楚看到"读"和"写"在哪一环被分开：

def return_flow(user_msg, order_id):
    intent = nlu.classify(user_msg)             # 1 用户问题 + 2 商品识别
    fact = fact_store.read(order_id)            # 3 订单查询：只读副本，自动
    rule = rule_engine.match(fact, intent)      # 4 政策匹配：Rule 表带版本，自动
    eligible = judge(fact, rule)                # 5 资格判断：Fact+Rule 联合，只读
    if not eligible:
        return human.takeover(...)              # 人工接管
    draft = make_draft(action=rule.action, amount=rule.amount, evidence=...)
    return approval.submit(draft, sla=30)       # 6 退款/工单：写，卡人
    # 7 通知：自动   8 审计：自动落六样

注意第 6 步：凡是"写"，无论代码多简单，都经过 approval 这道关口（人工审批，或带阈值的低额自动）。真正自动的只有第 3 步（查订单）和第 7 步（发通知）。第 1、2、4、5 步都是只读的判断，不产生任何状态变更。

这正是我反复强调的——客服 Agent 端到端落地里，读和通知可以放心自动，写永远卡在人。我们把这条链画给老板看，他一眼就懂为什么"全自动退换货"是伪命题：自动化吃掉的是最贵的"查"和"判断"，而不是最危险的"改"。第一级只读接入上线后，光"我的订单到哪了"这类重复来电就能拦掉六成，ROI 在动笔写之前就已经发生。很多团队卡在"系统不支持写"就停滞不前，其实是没想清楚——你根本不需要先写，先把读做透，价值就回来了。

客服 Agent 端到端落地前的四张表体检

上线前用四张表做体检，比任何模型评测都实在：Fact 是否唯一真相源、Rule 是否带版本与优先级、Action 是否列全写操作与边界、Responsibility 是否每一步有批准人与回滚。四项里缺 Responsibility，是最危险的信号——意味着出事没人担。我把它做成上线前必过的门禁，过不了就退回人工，宁可慢，不能裸奔上线。很多团队急着证明价值，跳过这步，最后翻车付出的代价远超那几天工期。顺便说一句，体检不是一次性动作，每次新增一个写动作，都要回到这四张表重新定档、定 SLA、定回滚，流程上堵住工程师的临场发挥。

12. 小结

客服 Agent 端到端落地，技术上没有银弹，但"分级接入"是性价比最高的路径：只读起步 → 出草稿推人工 → 低额自动留痕。别一上来追求全自动，那是用公司资金和用户体验赌运气。把边界写成四张表，把人工审批当一等公民，把回滚当上线门槛，你的 Agent 才敢真上线。规则冲突要裁决、写能力要锁死在函数里、三条线要可观测、读和写要分清楚——这四件工程细节，决定它是不是真能扛住生产。

最后补一句：分级接入不是妥协，是纪律。它让第一版就敢上线，让价值先发生，让组织在信任建立后再逐级放开写。这恰恰是客服 Agent 端到端落地能长期活着、而不是上线两周就被关掉的根本。