作为写 Agent 的工程师，我最怕两件事：一是产品说"就仿照竞品做个智能客服"；二是采购拿着一张"一个 Agent 5 万"的合同让我签字确认范围。前者是需求黑洞，后者是背锅陷阱。这篇从工程师视角，讲清楚怎么把"Agent 不是交付单位"翻译成白纸黑字的验收条款，让你上线后不被甩锅。
反共识：Agent 交付单位是个危险的计价错觉
结论先放：Agent 不是交付单位，是运行时界面（runtime interface）。可计价的是能力边界——读什么事实、调什么工具、谁接管、错怎么撤。把壳当单位去买，等于用组织图当架构图，这是企业 AI 里最危险的计价错觉。你作为写代码的人，最清楚一件事：一个"客服 Agent"文件夹里，真正要干活的代码，可能只占 20%，剩下 80% 都在和那二十几个系统的脏数据、烂接口、模糊权限搏斗。这部分成本，供应商的"5 万"里根本没有。
岗位名不能直接变模块名
"客服"岗位背后是二十几个系统、4 级权限、6 个群的政策文档。岗位靠人脑揉，软件靠显式线。翻译成合同条款就是：合同里不能写"交付一个客服 Agent"，要写"交付 N 张能力卡"。一张卡 = 一个可验证的任务，这才是对工程师友好、对采购也公平的最小单位。
五个隐藏变量，决定工作量差十倍
同一个"客服 Agent"，为什么 A 报 8 万、B 报 80 万？因为五个隐藏变量的默认范围不一样：
- 数据质量：字段干净，还是一半靠人工对齐？
- 系统接口成熟度：有现成 API，还是挂只读副本甚至爬？
- 权限粒度：只读，还是分级写带审批？
- 风险敞口：答 FAQ，还是能发起退款、改地址？
- 评估与运营：上线完事，还是持续评测监控？
五个全中，5 万变 50 万。工程师在写范围文档时，必须逐条确认供应商含了哪几个——否则上线后每多一个变量，都是你加班背锅。
能力卡的机器可读 spec：别只写在 PPT 上
能力卡最怕写成 PPT 上的漂亮表格，验收时供应商说"我们理解的任务和你们不一样"。我们把它落成 JSON Schema，附在合同附件，双方签字：
{
"capability": "order_logistics_status",
"target_result": "准确告知订单当前物流状态",
"samples": ["我的货到哪了", "为什么还没发"],
"fact_source": {"system": "read_replica", "freshness": "T+5min"},
"tool": "logistics_api",
"human_handoff": ["查不到", "用户情绪激动"],
"metric": {"accuracy": ">=0.95", "handoff_rate": "<=0.20"},
"change_freq": "quarterly"
}
这张卡既是需求文档，也是测试用例，还是验收门槛。工程师最爱它，因为不用再猜产品要什么；采购最爱它，因为对不上就能拒付。它直接回答了"Agent 交付单位"该怎么拆——一个 Agent 不是单位，N 张卡才是。
回滚演练：别等出事才第一次撤
我见过最惊险的一次，是上线后第一次真出写失败，团队才发现回滚脚本没权限执行。从那以后，我们要求每个写动作交付时附一份回滚演练记录：故意注入一次 PartialFailure，看审计 ID 是否成功撤销已写部分，录屏留证。这部分进合同附件四，没有就不算交付。你作为工程师，别嫌麻烦——演练一次，比你上线后半夜被叫起来救火省十倍精力。
SLA 违约条款，要写具体数字
变更响应 SLA 最怕写"及时响应"这种废话。我们用的模板是：
因 Amazon 政策或接口变更导致评测集失效，乙方须在变更生效后 5 个工作日内完成适配并跑通回归；每延迟 1 个工作日，按持续服务月费的 5% 扣减。
把"及时"换成"5 个工作日"和"5% 扣减"，供应商的态度立刻不一样。这也是把"Agent 不是交付单位"这个判断，翻译成合同语言的关键一步：边界在变，服务就得跟着变，变慢了要罚。
六层报价模型：把隐性成本摊在桌面上
| 层 | 你能验收的产出 | 计价方式 |
|---|---|---|
| ① 诊断 | 边界梳理报告、可行性结论 | 固定价 |
| ② 数据 | 接口对接代码 + 数据对齐脚本 | 固定价（按系统数） |
| ③ 工具 | Agent 编排 + 工具调用 + UI | 固定价或按模块 |
| ④ 治理 | 权限/审批/回滚/审计实现 | 固定价 + 留存 |
| ⑤ 评估 | 离线评测集 + 接管率基线 + 回归 | 持续服务 |
| ⑥ 运营 | 监控/告警/变更响应/演练 | 持续服务 |
第 5、6 层依赖外部数据与政策变更——Amazon 的 Buy Box 规则一改，评测集得跟着改。它们天然是持续服务，不能一次性买断。你作为工程师，最该坚持的是：评估与运营单列成持续服务，别被塞进"含 3 个月运维"的模糊条款里。否则三个月后规则一变，改不改？改了算不算 scope creep？扯皮的又是你。
能力卡 Capability Card：把"一个 Agent"写成可验收的 spec
这是工程师最该推动的文档。一张卡对应一个可验证任务，字段必须齐：
| 字段 | 含义 | 工程落点举例 |
|---|---|---|
| 目标结果 | 交付什么可验证结果 | 准确告知订单当前物流状态 |
| 样本任务 | 真实用户问法 | 10 条标注语料 |
| 事实来源 | 读哪个系统、是否实时 | read replica，T+5min |
| 工具 | 调用什么 | 物流查询 API |
| 人工接管 | 什么情况转人 | 查不到 / 用户情绪激动 |
| 审计 | 留哪些痕 | 会话 ID + 查询时间 + 返回码 |
| 指标 | 怎么算达标 | 准确率 ≥ 95%，接管率 ≤ 20% |
| 变更频率 | 多久会变 | 物流接口季度升级 |
第一阶段只为可验证的建议型任务（读 + 建议）报价。 比如"读订单、给退货建议"，风险低，进固定价。凡是系统写动作（退款、改地址），按接口与风险另计，绝不打包进 Agent 单价。这张卡，本质上就是你的验收测试用例清单——它写清楚了，你上线就有据可依，不用和采购扯"这算不算交付了"。
采购应要的五种验收证据：写成合同条款
我现在审 AI 合同，必看这五样，而且必须写成合同附件，不是口头承诺：
- 可验证任务清单 → 合同附件一，逐条对应能力卡；
- 离线评测集 → 附仓库地址，CI 里每次迭代跑分，门槛写死（如准确率 ≥ 95%）；
- 人工接管率基线 → 上线前压测报告，明确"多少问题必须转人"；
- 回滚演练记录 → 故意触发写失败，留撤销成功日志/录屏；
- 变更响应 SLA → 外部接口/政策变了，X 个工作日内改完，违约有罚则。
下面是你可以直接贴进合同的条款模板（节选）：
乙方交付的每一张能力卡，须随附离线评测集与标准答案，准确率不低于 95%；上线前须提供人工接管率基线报告及至少一次回滚演练记录。自上线之日起，因外部平台（如 Amazon）政策或接口变更导致的评测集/拒答策略调整，纳入持续服务范围，乙方须在变更生效后 5 个工作日内完成适配，否则按 SLA 违约条款处理。
把这段写进去，供应商再也不敢用"一个 Agent 5 万"糊弄你。
固定价 vs 持续服务：怎么分
- 适合固定价的：范围明确、接口稳定、风险可控——典型是「诊断 + 边界清晰的 PoC」。交付物确定（报告、能力卡、跑通的只读 Agent），价格锁死。
- 必须持续服务的：依赖外部数据、政策多变、需持续评测运营——典型是「上线后的评测与监控」。按周期买，天经地义。
混报一个"总价"，是供应商最爱玩的模糊术。你作为工程师，要帮采购把这两类拆开——让不确定性显性化，也是帮你自己少背锅。
我的独家观察
采购经理想要"价格带"没有错，谁花钱不想有个区间？错的是供应商用看似精确的"一个 Agent X 万"去掩盖不确定性。 5 万精确得像"这顿饭 5 万"——没说几个人吃、吃什么。专业报价反过来：把五个变量摊开，告诉采购"数据干净就这价，数据脏加这个，要写动作加那个"。敢把不确定性显性化的供应商，比报出漂亮整数的值钱十倍——也更能让你睡得着觉。
一个被"按个报价"坑过的真实合同
说个我朋友的真实经历。他们采购拿"一个 Agent 5 万"找三家比价，选了最便宜的。验收时供应商交了一个会聊天的 Bot，十张能力卡一张没交，离线评测集说"在训练里跑过但不便提供"，回滚演练记录根本没有。朋友作为工程师被拉去"确认能上线"，他拒签，被老板骂拖延。后来 Bot 上线答错率 40%，用户骂到群里，才回头补能力卡，供应商却说"补卡要加钱，不在原合同"。
这事教会我两点。第一，工程师必须参与验收条款的起草，不能等采购签完让你"确认"——那时候你只有背锅的份。第二，"Agent 交付单位"这种计价，天然让供应商有动机把最贵的边界工作往外推，因为边界看不见、壳看得见。把能力卡写进合同附件一，评测集写进附件二，回滚演练写进附件四，朋友那 5 万就不会买到一个聊天玩具。一个敢把能力卡摊在合同里的供应商，才值得你把项目交出去。
把这篇文章变成你的验收清单
如果你只记住一件事，记住这条：下次合同里出现"一个 Agent X 万"，就要求它拆成 N 张能力卡 + 一个离线评测集 + 一份回滚演练记录。 这三样齐了，"Agent 交付单位"才从幻觉变成可验收的边界。工程师的价值，恰恰在帮采购把这句话写进合同——你越早介入验收条款，上线后夜里被叫起来救火的概率就越低。
Pangolinfo：补的是「外部 Amazon 数据层」
内部表（ERP/工单/CRM）你们自己接，这是数据主权。但做 Amazon 生意的 Agent，还缺一层外部 Amazon 实时事实：评论情绪、广告位、Buy Box 归属、竞品价。这些不在你 ERP 里，却在投诉时反复被问到。
你作为工程师，有几种接法：Pangolinfo 的 Amazon 数据采集 API 拉结构化数据进你的事实表；或用 Amazon Data MCP直接把数据变成 Agent 可调的工具；也可装 Pangolinfo Amazon Scraper Skill 做定时采集；再配 AMZ Data Tracker持续盯排名和评论异动。定位要清醒：Pangolinfo 不碰你的内部写操作，只补外部 Amazon 数据层；"Agent 交付单位"的红线，永远在你自己手里。
写在最后
下次采购拿着"一个 Agent 5 万"的合同来找你签字，别急着签。把这篇文章拍给他，也拍给供应商：请先交 N 张能力卡、一个离线评测集、一份回滚演练记录。Agent 不是交付单位，能力边界才是。 把边界写进合同，你上线的每一个 Agent，才睡得着觉。
