报价 Agent 的真实边界

01核心判断CORE JUDGMENT

报价涉及成本、利润、运输、交期、数量和付款条件，最终落成一个数字发给对方。这个数字是承诺：报出去就进入对方的决策和记录。所以第一版报价 Agent 应该检查字段、识别风险、整理假设、生成草稿，而不是直接承诺价格。

报价场景里真正难的不是把价格算出来——公式和价格表早就存在——而是判断这一单能不能按常规报：条件齐不齐、客户要的东西和他写的东西是不是一回事、哪些假设需要先确认。这部分判断恰恰是最消耗有经验的人的时间的部分，也是 Agent 最该去减负的部分。

这个判断和 N-001 的邮件场景同构：生成能力不等于承诺权。邮件的"发送"和报价的"报出"，都是把候选输出变成组织承诺的那个动作，都应该在第一版里留给人。

报价错误的成本是不对称的。报低了，要么亏本履行，要么违约反悔——两条路都伤钱或伤信誉；报高了，单子无声无息地丢掉，你甚至不知道自己错过了什么。这种不对称意味着报价不能只看平均正确率：一次大单上的错误，能抵消一百次小单上的正确。

报价的上下文还天然分散。成本在一个系统里，库存在另一个系统里，运费随时在变，客户的历史折扣在某个人的记忆里，特殊条款在三个月前的邮件里。模型拿到的输入很难完整，而报价恰恰对"缺了哪一块"高度敏感——缺的那块常常就是亏损的来源。

最后，报价往往还是谈判的开局。第一个数字锚定整场谈判的区间，报价里的措辞、有效期、附带条件都有策略含义。这些是业务判断，不是文本生成——系统可以准备弹药，开枪的决定应该是人的。

常见误区是把表格计算和语言生成拼起来，就认为系统能自动报价：价格表查得到，句子写得顺，看起来只差一个"发送"按钮。真实业务里，缺失条件和边界判断比生成报价句子重要得多——难的从来不是把数字放进句子，而是确认这个数字站得住。

另一个误区是用"大多数单子都能报对"论证自动化。如 02 节所说，报价风险集中在尾部：低频、复杂、金额大的单子。恰恰是这些单子最需要被系统识别出来拦下，而不是被一视同仁地自动处理。

还有一个更隐蔽的误区：把报价 Agent 当成组织引入 Agent 的第一个试点。N-008 讨论过起点流程的选择标准——高重复、已数字化、失败可容忍、责任人明确。报价在"失败可容忍"这条上先天不合格，它属于对外承诺类流程，不该打头阵；如果业务核心就是报价，那第一版更要收在建议态。

更好的第一版是一个报价前检查台。系统读取询盘，逐项核对：数量、型号、包装、目的地、交期、成本来源、付款条件——哪些字段齐了，哪些缺失，哪些互相矛盾。然后输出一个候选判断："可以继续报价 / 需要补信息 / 风险过高需升级"，并列出理由。

在这个基础上，系统可以整理假设（"按标准包装计""按当前汇率计"）、标注风险（新客户、超常规数量、非标条款）、生成一版待确认的报价草稿。草稿默认不发送，人确认假设、修订数字、决定报或不报。每一次确认都被记录，成为下一次同类判断的参考。

这个第一版看起来保守，但它的价值可以立刻度量：漏项少了没有、高风险单被拦住了没有、有经验的人花在整理上的时间省了没有。这些指标不需要系统承诺价格就能兑现——而且它们本身就是说服业务方走向下一步的证据。

系统边界：承诺权在人。Agent 可以检查、整理、标注、起草，但"这个价格报出去"必须是一个由人执行、被记录的动作。任何演进都不改变这一条，只改变人需要亲手处理的比例。

内容边界：若项目涉及真实报价、成本、供应链细节、合同或订单，公开页面一律不展示，只展示抽象字段与脱敏后的流程结构。这是此类项目的通用规则，与具体项目无关——报价数据的敏感度不因为它被用于演示而降低。

可落地的下一步，按顺序：报价缺失项检查器（最小闭环，先证明"整理"有价值）；风险标签（新客户、异常数量、非标条款的显式标注）；草稿模板与假设清单（让人的确认有固定的落点）；人工确认记录（谁确认了什么假设、修改了哪个数字）。

自动承诺价格不应该是早期目标。如果未来要放开部分自动化，依据应该是确认记录的分层——哪类单子的草稿几乎从不被修改——而不是上线时长或整体准确率。这个演进逻辑与 N-008 的审核闭环一致：先成为可靠的流程节点，再谈减少人的动作。