为什么 Agent 不是交付单位：「Agent 交付单位」这个错觉害惨了数据对齐

你如果写过企业内部的 Agent，大概率被一句话卡死过：“我们 ERP 没接口。” 我去年在一个项目里，光"让 Agent 能读准订单状态"这一件事，就干了六个星期。这篇不讲虚的，我把那六周里踩的坑、写的对齐脚本、定的字段契约，连同"为什么 Agent 不能按个计价"这个判断，一起摊开讲。

反共识：Agent 交付单位是个危险的计价错觉

先说结论：Agent 不是交付单位。它只是运行时界面——某段逻辑在某个界面上调一堆东西。企业里真正稳定、可计价的是"能力边界"：读什么事实、调什么工具、谁接管、错怎么撤。把壳当单位去买，等于用组织图当架构图。我在项目里见过最危险的计价错觉，就是采购拿着"一个 Agent 5 万"的报价单，以为买到了确定性。

（系列 子篇 #2：客服 Agent 端到端集成 讲的是怎么把边界用四张表立起来，建议先看。）

岗位名 ≠ 模块名：一个"客服"背后的二十几个系统

把"客服"当成一个模块，是技术债的开始。我扒过客户后台：ERP（无 API）、3 家物流、2 套工单、1 套 CRM（半截在 Excel）、4 级退款权限、6 个群的政策文档。这些不是"接一个 Agent"能吞下的，每一根线都得显式接入。岗位靠人脑揉，软件靠显式线，二者成本结构完全不同。 这也解释了为什么"一个 Agent 5 万"在工程师耳朵里像个笑话——5 万连把数据接顺都远远不够。

为什么同一个 Agent 差十倍：五个隐藏变量

变量	它对工作量的影响	我的实战表现
数据质量	脏数据要清洗对齐，工作量 ×2~×3	6 周里 4 周在対齐
接口成熟度	无 API 要挂副本/爬，×2	ERP 十年老系统，零接口
权限粒度	分级写+审批，×1.5	退款超 500 必须财务批
风险敞口	能改地址/退款，×2	写动作要回滚方案
评估运营	持续评测，×1.5（持续）	上线后 Buy Box 规则月月变

我那个项目，五个全中。供应商报"一个 Agent 5 万"，隐性工作量翻十倍。下面说最硬核的一块：数据对齐到底怎么干。

实战：老 ERP 无接口，怎么起步

我们没重做中台（一年起步不现实），而是用三级接入把第一阶段的只读价值先跑出来：

第一级：只读副本查。 在 ERP 库旁挂 read replica，Agent 只查不写。这一步先把"订单到哪了"这类重复查询吃掉 60%。注意，Agent 一句话没"改"过系统，价值已经发生。

-- 给 Agent 的只读视图，从根上屏蔽写权限
CREATE VIEW v_agent_order_status AS
SELECT order_id, status, ship_time, invoice_no
FROM erp.orders
WHERE status != 'DELETED';
-- Agent 账号仅授 GRANT SELECT ON v_agent_order_status

第二级：草稿 + 人工审批。 Agent 出退款草稿，带完整证据链，推人批。写风险转给人，但 Agent 把最耗时的判断做完了。

第三级：低额自动 + 留痕。 5 美元内补偿自动跑，审计日志写满。金额阈值由责任表定。

数据对齐：字段契约怎么定

"读准状态"最难的点，是 ERP 的"已发货"和物流接口的"已发货"不是一回事。我们定的字段契约长这样：

业务字段	ERP 源	物流源	合并规则	时效
order_status	erp.orders.status	waybill.state	ERP 为主，物流补运单号	T+5min
ship_time	erp.ship_time	waybill.depart	取非空较早值	T+5min

对齐后还要做两件事：幂等和回滚。写操作必须带幂等键（idempotency_key）和审计 ID，失败按 ID 撤销。我们的铁律是——没有回滚方案的动作，不准上线。 下面是一段最小可用的回滚思路：

def execute_write(action, payload):
    audit_id = new_uuid()
    log_start(audit_id, action, payload)
    try:
        result = downstream.call(action, payload, idempotency_key=audit_id)
        log_success(audit_id, result)
        return result
    except PartialFailure as e:
        rollback(audit_id)   # 按 audit_id 撤销已写部分
        log_rollback(audit_id, e)
        raise

这套东西看着朴素，却是"Agent 交付单位"能不能上线的分水岭——没有它，写动作就是裸奔。

可观测性：上线后怎么证明 Agent 没作妖

挂了只读副本、写了回滚，不等于高枕无忧。Agent 最阴险的问题是"静默退化"——准确率从 95% 悄悄滑到 80%，用户没投诉、老板没看报表，等到发现时已经赔了几单。我们给 Agent 加了三层可观测：

1. 每条读操作记录 source、latency、返回码，异常率超阈值自动告警；
2. 准确率按周在离线评测集上回归，跌 2 个点就拉群报警；
3. 人工接管率每天出基线，突然飙升说明某个数据源坏了。

这部分天然对应六层模型的第 5、6 层，必须持续服务，绝不能"交付即结束"。我在多个项目里见过，省掉可观测，前三个月省了小钱，第四季度一把资损全吐回去。这也是为什么"Agent 交付单位"这种一次性买卖，在技术上根本站不住——你买的不是一次性交付，是一套要长期盯着的运行时。

字段契约的机器可读版本

前面那张字段契约，最终要落进代码，而不是停在文档里。我们把它存成 JSON，进 CI 校验：

{
  "field": "order_status",
  "sources": [
    {"system": "erp", "path": "erp.orders.status"},
    {"system": "waybill", "path": "waybill.state"}
  ],
  "merge": "erp_primary_with_waybill_tracking",
  "freshness": "T+5min"
}

有了这个契约，新增一个数据源不用改 Agent 主逻辑，只改契约文件。我见过一个团队，契约没进代码，全在工程师脑子里，人一离职，三个数据源的合并规则没人说得清，Agent 答错率一夜翻倍。把契约机器化，是防单点故障的最低成本动作。这也是"Agent 不是交付单位"的工程注脚：真正值钱的资产是这些契约和边界定义，Agent 只是跑在上面的壳。供应商报"一个 Agent 5 万"时，你该问的是"这 5 万里含了几张这样的契约"。

六层报价模型：把隐性成本显性化

层	内容	计价方式	说明
① 诊断	现状/边界梳理	固定价	产出是报告，范围明确
② 数据	接口/对齐/清洗	固定价（按系统数）	清单定下后范围锁死
③ 工具	编排/调用/UI	固定价或按模块	功能边界可定义
④ 治理	权限/审批/回滚	固定价 + 留存	红线工程，一次建好
⑤ 评估	评测集/接管率/回归	持续服务	依赖外部数据/政策，会变
⑥ 运营	监控/告警/变更 SLA	持续服务	上线后才发生，按周期

第 5、6 层是技术人最容易低估的。很多供应商把"评估"和"运营"塞进一次性交付，写句"含 3 个月运维"就过。可评估与运营天然依赖外部数据与政策变更——Amazon 的 Buy Box 规则一改，你的离线评测集得跟着改；新广告法出来，你的拒答策略得跟着调。这些不是"交付时一次性做"能解决的，必须按持续服务单列。

能力卡 Capability Card：让"一个 Agent"变成可验收的 spec

采购最该逼供应商交的，是能力卡。一张卡对应一个可验证任务，字段必须齐：

字段	含义	技术落点
目标结果	可验证结果	准确报物流状态
样本任务	真实问法	10 条语料
事实来源	读哪/实时	read replica，T+5
工具	调什么	物流查询 API
人工接管	转人条件	查不到/情绪激动
审计	留痕	会话 ID + 返回码
指标	达标线	准确率 ≥ 95%
变更频率	多久变	物流季度升级

关键原则：第一阶段只为可验证的建议型任务（读 + 建议）报价。 比如"读订单、给退货建议"——这是读，风险低，可以进固定价。凡是系统写动作（发起退款、改地址），一律按接口与风险另计，绝不打包进 Agent 单价。否则供应商用 5 万的"读"价，把你 195 万的"写"风险悄悄背走。

采购要的五种验收证据（技术视角）

1. 可验证任务清单：能力卡级的任务，不是"提升效率"废话；
2. 离线评测集：固定样本 + 标准答案，CI 里每次迭代都跑，看分数涨跌；
3. 人工接管率基线：上线前压测测出"多少问题必须转人"；
4. 回滚演练记录：故意让写失败，看撤销是否成功，留日志；
5. 变更响应 SLA：外部接口/政策变了，几天内改完，写进合同。

这五样，是你能不能睡得着觉的全部底气。

固定价 vs 持续服务：怎么分

• 适合固定价的：范围明确、接口稳定、风险可控——典型是「诊断 + 边界清晰的 PoC」。交付物确定（报告、能力卡、跑通的只读 Agent），价格锁死。
• 必须持续服务的：依赖外部数据、政策多变、需持续评测运营——典型是「上线后的评测与监控」。Amazon 规则月月变，评测集和拒答策略就得月月调，按周期买，天经地义。

把两类混报一个"总价"，是供应商最爱玩的模糊术。拆开，固定价归固定价，持续服务归持续服务，让不确定性显性化。

我的独家观察

采购经理想要"价格带"没有错——谁花钱不想有个区间？错的是供应商用看似精确的"一个 Agent X 万"去掩盖背后的不确定性。 5 万这个数精确得像"这顿饭 5 万"——没说几个人吃、吃什么。专业报价反过来：把五个隐藏变量摊开，告诉采购"数据干净就这价，数据脏加这个，要写动作加那个"。一个敢把不确定性显性化的供应商，比报出漂亮整数的值钱十倍。

我踩过的一个对齐坑：ship_time 的两种"已发货"

讲个真事。有次 Agent 老答错"怎么还没发货"，查日志发现：ERP 的 ship_time 是"仓库出库时间"，物流的 waybill.depart 是"揽收时间"，中间差一天。按前面"取非空较早值"的规则，Agent 取了 ERP 出库时间，告诉用户"已发货"，但用户看物流还是"待揽收"，觉得我们骗人。后来改成"展示两个时间 + 状态说明"，投诉立刻降了。

这个坑花了我两天，但它不在任何"一个 Agent 5 万"的报价里——它属于第 ② 层数据对齐，必须单列、必须有人做。这个故事说明：Agent 的"聪明"不在模型，在边界定义。你在数据对齐上省掉，就等着在客诉里加倍还。也正因为此，"Agent 交付单位"这种计价，永远算不清这笔隐性账——它把最贵的那块，藏进了最便宜的那个壳里。

Pangolinfo：补的是「外部 Amazon 数据层」

内部表（ERP/工单/CRM）你们自己接，这是数据主权，不该外包。但做 Amazon 生意的 Agent，还缺一层外部 Amazon 实时事实：评论情绪、广告位、Buy Box 归属、竞品价。这些不在你 ERP 里，却在投诉时反复被问到（“为什么搜不到你们家了”“是不是你们降价了”）。

Pangolinfo 的 Amazon 数据采集 API补的就是这块——把 Amazon 侧事实拉成结构化数据，喂给你的事实表当外部源。也可以直接用 Amazon Data MCP把数据接进 Agent 工具层，或装 Pangolinfo Amazon Scraper Skill做定时采集；再配 AMZ Data Tracker持续盯排名和评论异动。定位要清醒：Pangolinfo 不碰你的内部写操作，只补外部 Amazon 数据层；"Agent 交付单位"的红线，永远在你自己手里。

写在最后

回到开头那六个星期。“让 Agent 读准订单状态"之所以贵，不是因为 Agent 本身，而是因为二十几个系统的数据要被显式对齐、要带权限、要能回滚。下次有人报"一个 Agent 5 万”，请记住：Agent 不是交付单位，能力边界才是。 先把字段契约和回滚方案写明白，再谈单价。