AgenticPay：用自然语言谈生意，大模型议价能力全面测评

📋 论文信息

• • 标题: AgenticPay: A Multi-Agent LLM Negotiation System for Buyer-Seller Transactions
• • 作者: Xianyang Liu, Shangding Gu, Dawn Song
• • 单位: UC Berkeley
• • 发表时间: 2026年2月
• • 论文链接: https://arxiv.org/abs/2602.06008
• • 开源代码: https://github.com/SafeRL-Lab/AgenticPay

导读 👁️

想象一下，未来的电商平台上，AI代理代替你去议价砍价——从二手手机到企业软件采购，从度假租房到商业并购，统统交给智能体去谈判。这听起来很美好，但问题是：当前的大语言模型真的具备这种商业谈判能力吗？ 伯克利团队最新发布的AgenticPay基准测试给出了答案，结果既令人兴奋又发人深省。

核心观点 💡

1. 首个语言驱动的多智能体交易测评框架 AgenticPay不是简单的数字竞价，而是让买卖双方通过多轮自然语言对话进行谈判，模拟真实商业场景中的策略博弈、信息隐藏和动态决策。

2. 顶级模型表现优异，但开源模型严重落后 Claude Opus 4.5、GPT-5.2等顶级模型达成交易率100%，综合得分超过80分；而开源模型Llama-3.1-8B有近50%谈判超时失败，暴露出长期战略推理能力的严重不足。

3. 买方劣势普遍存在 所有模型都表现出系统性的"卖方优势"——作为卖家时表现更好，作为买家时得分明显偏低。这可能反映了训练数据中销售话术占主导的偏差。

4. 金融资产谈判是最大挑战 涉及奢侈手表、企业并购等高价值资产的谈判场景中，所有模型得分都显著下降，说明复杂市场动态和风险评估仍是LLM的薄弱环节。

5. 接近成功的失败最令人惋惜 超过40%的失败案例中，买卖双方价格差距仅在5美元以内——只需一次让步就能达成协议，但开源模型缺乏"临门一脚"的战略耐心。

突破性设计：从双边讨价到多方市场 🔧

AgenticPay的核心创新在于构建了一个可扩展的语言驱动市场仿真环境。与传统拍卖机制只关注数字出价不同，这个框架强调通过自然语言进行多轮战略性谈判。

图1: AgenticPay系统架构展示了三种谈判模式——1对1双边议价、1对多竞争性市场、多对多匹配市场，以及完整的谈判流程和评估体系

三大核心组件：

环境（Environment）：定义谈判协议和场景设定。每个场景包含产品描述、市场背景和私密保留价格（买方最高愿付价、卖方最低接受价）。系统支持10个真实业务场景，涵盖日常消费（二手手机、汽车、度假租赁）、专业服务（网站开发、摄影、装修）、企业采购（SaaS软件、原材料）和金融资产（奢侈手表、企业并购）四大领域。

任务（Task）：定义市场结构的复杂度。AgenticPay包含8种任务类型、超过110个具体任务，沿着三个维度逐步提升难度：买方数量、卖方数量、产品种类。从最简单的1对1单品谈判，到多买家竞争、多卖家竞争、多产品选择，再到最复杂的多对多全市场匹配。

智能体（Agent）：实现买卖双方角色。每个智能体拥有公开信息（产品描述、市场背景）和私密信息（保留价格、谈判风格）。系统通过结构化提示词让LLM在每轮谈判中必须提出具体价格（如### BUYER PRICE($120) ###），并在双方价格一致且位于可行集时达成交易。

图2: AgenticPay任务设计涵盖10个真实商业场景（左），并通过买方数、卖方数、产品数三个维度构建8种渐进式复杂度的任务类型（右）

评分机制：系统采用三维评估体系——全局得分（GlobalScore）奖励买卖双方剩余价值均衡的交易，买方得分（BuyerScore）和卖方得分（SellerScore）分别衡量各自获得的剩余价值。所有得分都引入折扣因子，激励更快达成协议。失败的谈判（超时或价格冲突）会受到适度惩罚。

实验揭示：顶级模型的领先与开源模型的困境 📊

研究团队在AgenticPay基准上评估了5个代表性LLM：GPT-5.2、Claude Opus 4.5、Gemini-3-Flash（闭源前沿模型），以及Qwen3-14B、Llama-3.1-8B（开源模型）。所有模型采用相同的提示词模板和确定性解码（温度0），确保公平比较。

顶级模型主导谈判表现

三个闭源前沿模型均达成100%交易，零超时，Claude Opus 4.5以86.9的全局得分领先。这些模型能在平均4轮内快速找到共识价格。

相比之下，开源模型表现差距显著：Qwen3-14B有20.7%的谈判因超时失败，Llama-3.1-8B更是近半数谈判（48.6%）无法收敛，且需要15轮对话才能完成交易。更糟糕的是，Llama-3.1-8B有10.8%的出价超出可接受范围（overflow），说明其对谈判约束的理解存在问题。

买卖双方角色不对称

所有模型都呈现出"卖方得分高于买方得分"的模式。GPT-5.2的卖方得分81.1，而买方得分仅58.5，差距达22.6分。Qwen3-14B的差距为11.3分。这种系统性偏差可能源于训练数据中销售话术和说服性内容占主导，而战略性采购指导相对稀缺。

市场复杂度的意外影响

反直觉的是，更复杂的多方市场反而产生更好的谈判结果。从单买单卖（1B1S）到多买多卖（MBMS），Claude Opus 4.5的全局得分从83.4提升到89.8（提升6.4分），Qwen3-14B从63.2跃升至77.6（提升14.4分）。

这一现象可以用市场流动性解释：当有多个备选交易对手时，智能体有更多机会找到兼容的伙伴，竞争压力也促使双方提出更合理的价格，加速收敛。

场景难度揭示推理短板

按业务场景分类，金融资产谈判（奢侈手表、企业并购）得分最低。Gemini-3-Flash在专业服务场景得88.3分，但在金融资产场景仅68.1分，下降20.2分。研究者认为，金融谈判需要对风险、市场动态和对手策略进行复杂推理，当前LLM在对抗性压力下难以维持这种深度策略思考。

"临门一脚"的战略耐心缺失

针对失败案例的分析发现，43.5%的Qwen3-14B失败、46.3%的Llama-3.1-8B失败发生在价格差距小于5美元时——此时双方已非常接近协议区间，只需一次小让步即可达成交易。但开源模型缺乏识别这种"最后一英里"时机的能力，无法在关键时刻做出战略性让步。

启示与应用 🚀

AI商业代理的现实差距

AgenticPay的测评结果表明，虽然顶级LLM在受控谈判环境中表现出色，但开源模型与前沿模型之间存在巨大鸿沟。这意味着在实际部署AI商业代理时，模型选择至关重要——依赖较弱模型可能导致大量交易失败或不利结果。

训练数据偏见的警示

所有模型的"买方劣势"现象提醒我们，LLM的谈判能力深受训练数据分布影响。如果训练语料中销售话术、营销文案占主导，模型自然会在卖方角色中表现更好。要培养真正平衡的谈判能力，需要刻意构建包含买方战略、采购技巧和消费者保护内容的训练数据。

长期战略推理的挑战

开源模型的高超时率和"接近成功的失败"现象，揭示了当前LLM在长期战略规划方面的不足。谈判不仅需要语言生成能力，更需要：

• • 对对手意图的建模（心智理论）
• • 多步骤后果的前瞻推理
• • 在探索（试探底线）和利用（达成交易）之间平衡
• • 识别关键时机并做出战略性让步

这些能力的提升可能需要新的训练范式，如强化学习、自我博弈或专门的经济推理预训练。

应用场景展望

尽管存在挑战，AgenticPay展示的前沿模型能力已经足以支撑一些实际应用：

• • 个人消费助手：在二手交易平台（闲鱼、eBay）上自动帮用户议价
• • 企业采购优化：在SaaS订阅、原材料采购中批量谈判，获取批量折扣
• • 房产租赁代理：根据用户预算和偏好，自动与房东协商租金和条款
• • 服务外包谈判：为自由职业者和企业客户自动协商项目报价和交付条件

安全与伦理考量

论文作者在影响声明中明确指出潜在风险：自动化谈判系统可能对不够精明的人类对手造成不公平优势。未来部署此类技术需要：

• • 透明告知对方正在与AI代理交互
• • 为弱势群体提供保护机制（如价格合理性审查）
• • 建立AI代理行为的伦理规范和监管框架

下一步研究方向

AgenticPay为智能体商业研究奠定了基础，但仍有许多问题待探索：

1. 1. 如何通过强化学习或自我博弈提升模型的长期战略推理能力？
2. 2. 能否设计更公平的谈判协议，减少买卖不对称？
3. 3. 如何处理多智能体谈判中的欺骗、虚假信息和信任问题？
4. 4. 跨文化、跨语言的谈判风格差异如何影响AI代理表现？

扩展阅读 📚

相关研究：

• • DeepMind团队的拍卖机制设计研究（Duetting et al., 2024）探索了LLM在结构化竞价环境中的战略行为
• • NegotiationArena基准（Bianchi et al., 2024）聚焦于双边对话谈判，但场景和任务规模较小
• • 关于LLM博弈能力的系统性研究（Fan et al., 2024; Akata et al., 2025）分析了模型在经典博弈论游戏中的表现

技术工具：

• • vLLM[1] - 高性能LLM推理引擎，论文实验使用
• • SGLang[2] - 结构化生成语言，支持复杂多智能体交互

关键词: #大语言模型 #多智能体系统 #商业谈判 #议价能力 #基准测试 #经济推理 #自主代理 #AgenticPay

引用链接

[1] vLLM: https://github.com/vllm-project/vllm [2] SGLang: https://github.com/sgl-project/sglang