Agent 交付单位，是我在企业 AI 项目里见过最危险的一个计价错觉。一个采购经理问”做一个客服 Agent 多少钱”，和一个老板问”买几辆卡车运货”在结构上是同一类问题——都用”个数”去套一个本质上由复杂度决定的东西。把 Agent 当成稳定的业务边界来报价，等于用组织图当架构图，最后不是超支，就是上线即烂尾。
这篇文章写给正在被”智能体项目”报价单逼疯的技术负责人和采购：前两篇我们讲了客服 Agent 最该先学会的是说「不知道」（见 客服 Agent 拒答能力），以及信任建立之后怎么把事真办了（见 客服 Agent 端到端集成）。这一篇往更上游走一步：在写第一行代码之前，你怎么判断一个 Agent 项目的报价是不是在骗你？我会先拆穿”岗位名 = 软件模块”这个最常见的认知陷阱，再给你一套六层报价模型和一张”能力卡”，让你把不确定性摊在桌面上谈，而不是等变更单来付。
岗位名称不能直接变成软件模块：Agent 是运行时界面，不是业务边界
“我们想做一个客服 Agent。”——这句话我已经听过几百遍，但它几乎从来说不清楚要做什么。问题出在”客服”这两个字。在组织里，”客服”是一个岗位，背后是订单系统、ERP、工单、退款、物流、风控、知识库、质检、合规……二十几个异构系统，每一个都有不同的权限粒度、数据质量和变更频率。把一个岗位名直接变成软件模块，等于用一张组织图去当架构图——看上去都对，落地全错。
所以我给团队的第一条铁律：Agent 是运行时界面，不是稳定的业务边界。界面可以今天长这样、明天长那样；业务边界（谁能改什么、改错了谁担、数据从哪来、多久变一次）才是真正值钱、也真正决定成本的东西。当你用”一个 Agent”去计价时，你计的是皮，不是骨。骨，是下面这六层。
同一个客服 Agent 为什么可能相差十倍工作量？
我见过两个都叫”售后 Agent”的项目，报价一个 8 万，一个 80 万，功能列表看着差不多。差距不在模型，在五个被藏在”需求”二字背后的隐藏成本：
① 数据质量：订单状态散在三个系统、字段还对不上，光做对齐就要一个月；数据干净，三天。
② 系统接口成熟度：有开放 API 和只读副本，接起来顺；十年老 ERP 没接口，得先造一个中间层。
③ 权限粒度：只”读”和能”退款”是两种法律意义上的项目，后者的审批、留痕、回滚全是隐形工作量。
④ 风险敞口：动钱的、动账号的，要有人工接管和审计，成本指数级上升。
⑤ 评估与运营：上线不是终点，模型漂移、政策变更、新类目，需要持续评测——这部分几乎从不被报价，却吃掉大部分长期成本。
独家判断：“Agent 交付单位”最毒的地方，是它用一个貌似精确的单价，把上述五种不确定性一次性吞掉。供应商报”一个 Agent 5 万”，你以为买的是成品，其实买的是个毛坯，还得自己补数据治理、接口维护、上线后评估。等变更单一张张来，总价早翻了几倍。
六层报价模型：把”Agent 交付单位”这个错觉拆成可验收的成本结构
与其问”一个 Agent 多少钱”，不如按业务结果闭环的复杂度逐层计价。这是我们给客户做立项时的默认框架，从诊断到运营一共六层，缺哪层，哪层就是日后的变更单：
| 层 | 在计什么 | 常见漏项 | 该不该固定价 |
|---|---|---|---|
| 1 诊断 | 现状梳理、可行性、边界定义 | 直接跳过，凭感觉立项 | 可固定价 |
| 2 数据 | 事实来源对接、清洗、对齐 | 以为”接个 API 就行” | 按接口与质量另计 |
| 3 工具 | 可调用动作（查/写）的封装 | 忽略权限与回滚 | 按动作风险另计 |
| 4 治理 | 版本、审批、责任、审计 | 后两张表根本不画 | 按规则复杂度另计 |
| 5 评估 | 离线评测集、人工接管率 | 只上线不评测 | 持续服务 |
| 6 运营 | 监控、漂移、政策变更响应 | 默认为零，实际最贵 | 持续服务 |
看这张表你会明白：真正该担心的不是”Agent 单价”，而是第 5、6 层——评估与运营——它们永远不会出现在”做一个 Agent 5 万”的报价里，却决定了这个项目半年后是资产还是负债。把六层写进合同，供应商就没法用”单价”掩盖不确定性。
采购文件应要求哪些验收证据？
“Agent 交付单位”模式下，验收往往只有一句话：”能跑通 demo 就算交付。”这是灾难。demo 跑通和真实可用之间，差的是一整套验收证据。我们在采购文件里硬性要求供应商提供五样：
① 可验证的建议型任务清单：不是”能回答问题”，而是”在样本集 X 上的准确率 ≥ Y”。
② 离线评测集：带标注的真实样例，且要随业务更新，不能一次性。
③ 人工接管率基线：哪些场景必须转人、转人比例多少，写死。
④ 回滚演练记录：每个写动作演示过”怎么撤销”，没演练不许上线。
⑤ 变更响应 SLA：政策变了、类目加了，供应商多久跟得上。
这五样里，前两项是”有没有做对”，后三项是”出事了怎么办、变了怎么办”。只验收前两项的项目，上线后一定在第三、四项上暴雷。把验收证据写进合同附件，比在 PPT 上看 demo 靠谱十倍。
怎么把一次性项目改成分阶段决策？用”能力卡”取代 Agent 数量
采购经理想要一个价格带，这没有错。错的是把一个模糊的”Agent”当成计价单元。我们的做法是把每个场景落成一张能力卡（Capability Card），用卡片数量和复杂度矩阵取代”Agent 个数”：
| 能力卡字段 | 回答什么问题 |
|---|---|
| 目标结果 | 这个 Agent 到底要交付什么真实状态变更？ |
| 样本任务 | 抽 20 个真实 case，难到能暴露边界 |
| 事实来源 | 数据从哪来、实时还是隔夜、谁维护 |
| 工具 | 能调用哪些读/写，权限边界在哪 |
| 人工接管 | 哪些情况必须转人、SLA 多少 |
| 审计 | 六字段日志是否全落、能否回滚 |
| 指标 | 接管率、准确率、时效怎么量 |
| 变更频率 | 政策/类目多久变一次，谁跟 |
落地建议：第一阶段只为可验证的建议型任务报价——也就是”读 + 给建议”，不涉及动钱动账号。系统写动作按接口成熟度和风险另计，绝不打包进”Agent 单价”。这样你先用最低风险拿到价值，再逐级放开写权限。卡片越多、复杂度越高，价格越贵——但贵得清清楚楚，不像”一个 Agent 5 万”那样贵得不明不白。
哪些工作适合固定价格，哪些必须按持续服务？
把六层反过来归纳，报价方式就清晰了：
适合固定价格：范围明确、接口稳定、风险可控的交付。典型是诊断（第 1 层）和一个边界清晰的 PoC——你能在合同里写死”交付物是什么”。
必须按持续服务：依赖外部数据、政策多变、需要持续评估与运营的部分（第 5、6 层）。典型是”上线后的评测与监控”——你没法在签合同时承诺”模型永远不漂”，只能承诺”漂移了我多久发现、多久修”。
坑在于：很多供应商把第 5、6 层偷偷塞进固定价，然后上线即失联。专业做法是把它们单列成持续服务，按月或按调用量计费。短期看总价高了，长期看你买的是”一直能用”，不是”交付那天能用”。
Pangolinfo 在这一层能补什么
六层里的”数据”层（第 2 层），做 Amazon 生意的团队往往卡在最外部那一环——商品评论情绪、广告位排名、Buy Box 归属、竞品价格，这些事实不在你的 ERP 里，却在用户投诉时反复被问到。Pangolinfo 补的就是这层外部 Amazon 数据，让 Agent 的事实表有稳定的外部真相源。
通过 Amazon Scraper API，可以稳定拿到商品、搜索、榜单、类目、评论和广告位等结构化事实；通过 Amazon Data MCP，让 Agent 直接以工具方式取数，不必每个项目重写抓取与解析；Amazon Scraper Skill 把常用亚马逊数据任务放进对话式工作流；AMZ Data Tracker 适合做可视化监控。企业内部那几张表（订单、ERP、工单）还是得你们自己接，但把 Amazon 这层做短做稳，能力卡里的”事实来源”字段就好填得多。
把 Amazon 数据层接进客服 Agent 后，你可以在 Pangolinfo 控制台 实时监控取数调用、配额与成功率——先让外部数据稳下来，再谈六层报价里的”数据”那一层。
结论：Agent 交付单位是个计价错觉，业务结果闭环才是
回到开头那个问题——”做一个 Agent 多少钱”。下次有人这么问，你可以把这句话递回去：Agent 不是交付单位，业务结果闭环的复杂度才是。用六层报价模型把数据、系统、权限、风险、评估、运营摊开，用能力卡把每个场景的边界、接管、审计、变更写死，让不确定性显性化，而不是等它变成一张张变更单。采购想要价格带没错，错的是用一个貌似精确的 Agent 单价去掩盖你根本还没定义清楚的复杂度。
这一篇是企业 AI 转型系列的采购视角，和前两篇一脉相承：先让 Agent 诚实（拒答） → 再定义交付边界（端到端集成） → 最后才谈怎么计价（本篇）。更上层的整体框架，见我们的 企业 AI 转型不应从买几个 Agent 开始。
常见问题
为什么岗位名称不能直接变成软件模块？
一个岗位（如”客服”）背后是二十几个异构系统、不同权限粒度、数据质量和变更频率。把岗位名直接当软件模块，等于用组织图当架构图。Agent 是运行时界面，不是稳定的业务边界；真正决定成本和风险的，是数据、系统、权限、风险、评估与运营这些底层结构，而不是”一个 Agent”的个数。
Agent 交付单位为什么会导致报价差十倍？
因为”一个 Agent”掩盖了五个隐藏变量：数据质量、系统接口成熟度、权限粒度、风险敞口、评估与运营。两个功能列表相似的 Agent，光数据对齐或老 ERP 无接口就可能差出十倍隐性工作量。用”Agent 单价”计价，等于用皮的价格卖骨头的项目。
企业 AI 项目应该怎么报价才合理？
用六层报价模型替代 Agent 单价：诊断、数据、工具、治理、评估、运营。前两层范围明确可固定价，后两层（评估、运营）依赖外部数据和政策变更，必须按持续服务单列。采购文件要硬性要求五种验收证据：可验证任务清单、离线评测集、人工接管率基线、回滚演练记录、变更响应 SLA。
采购文件应要求哪些验收证据？
五样：①可验证的建议型任务清单（样本集准确率≥阈值）；②随业务更新的离线评测集；③人工接管率基线（哪些必转人、比例多少）；④每个写动作的回滚演练记录；⑤变更响应 SLA（政策/类目变了多久跟上）。只验收”能跑 demo”的项目，上线后必然在接管、回滚、变更上暴雷。
哪些 AI 工作适合固定价格，哪些必须按持续服务？
范围明确、接口稳定、风险可控的（诊断 + 边界清晰的 PoC）适合固定价格，能在合同写死交付物。依赖外部数据、政策多变、需持续评估与运营的（上线后评测与监控）必须按持续服务，按月或按调用量计费——这部分塞进固定价，供应商往往上线即失联。
外部参考：UiPath Agentic Orchestration、Salesforce Agentforce Implementation Guide。本文为 Pangolinfo 企业 AI 转型系列的子篇，支柱文章见 亚马逊企业 AI 转型，前篇见 客服 Agent 拒答能力 与 客服 Agent 端到端集成。
