个人主页小年糕是糕手个人专栏《C》《数据结构》《Blender 修行笔记》《AI》你不能左右天气但你可以改变心情你不能改变过去但你可以决定未来目录1. 从生成砍价话术到替用户作出决定2. Project Deal为什么成交价之外还要留过程记录3. Project Swap优化目标本身也可能写错4. 把需求确认放进执行流程5. UCP 与 AP2 分别处理哪一段6. 评测交易 Agent不能只统计成交率7. 最后需要交给用户的是可核对的交易结果参考资料同一辆需要修理的旧折叠车AI 代理谈出了 38 美元和 65 美元两个价格。这个例子来自 Anthropic 的 Project Deal它们是平行市场中的议价结果最终只有一个市场实际结算不能理解成同一辆车真的卖了两次。[1]真正值得开发者追问的是如果把购买决策交给 Agent最后收到一张符合预算的订单就足以证明系统完成任务了吗一台预算内的二手电脑可能性能很好却重得不适合每天通勤一份已经获得授权的订单也可能漏掉了用户最在意的条件。要解释这些失败需要沿着需求、谈判和执行往回查。这篇文章结合两场交易实验讨论交易型 AI Agent 的几个设计问题如何记录用户偏好在哪里设置执行边界以及怎样评测“替人办好了事”。1. 从生成砍价话术到替用户作出决定让大模型写一句“能不能再便宜一点”用户仍然掌握着决策权发不发送、接受哪个价格、什么时候退出都由人决定。交易代理接手的范围更大。它可能要自己找交易对象、比较报价、提出条件直到达成交易。这里的“会聊天”必须接上一个能执行、能检查的工作流程。假设一个用户准备搬家要求今天卖掉旧自行车。另一个用户愿意再等一周争取更好的价格。两个代理即使卖出同样的金额也不能直接判定表现一样。前一个任务包含时间约束后一个任务允许等待。代理要优化什么取决于用户交给它的条件。只把成交金额写进评测脚本会丢掉这部分差别。2. Project Deal为什么成交价之外还要留过程记录Project Deal 在 2025 年 12 月进行报告于 2026 年 4 月发布。69 名员工委托代理买卖物品实际结算的市场完成了 186 笔交易总额超过 4,000 美元。[1]研究还设置了平行对照。混合模型市场中Opus 4.5 在多项价格指标上优于 Haiku 4.5但参与者的满意度、公平感评分没有显著体现这种差异。[1]用户通常知道自己的底线却不知道换一个谈判者能谈到多少。举个假设的例子你要求相机至少卖 800 元代理以 850 元成交。预算检查通过了用户也可能满意。但如果它没有比较其他买家的报价系统就缺少证据说明这个决定是否合理。因此我会把以下信息纳入交易记录代理接触了哪些候选对象实际拿到了哪些报价。报价中的价格、运费、交付时间等条件发生过什么变化。哪些候选被排除排除依据来自用户要求还是商品信息。达成协议时采用的是哪一版需求与授权。这些记录未必能证明“全市场最优”却能让人检查代理实际比较过的范围。对开发者来说也能区分搜索遗漏、谈判策略和执行错误。ICML 2024 的 NegotiationArena 研究还表明在其设定的场景中行为策略会改变代理的谈判收益。[3] 所以更换模型做对照时交易规则、对手和可用信息也要一起控制不能只换一个模型名称就把差异全算在模型能力上。3. Project Swap优化目标本身也可能写错Project Swap 让 201 名员工委托 AI 换书。研究者收集了其中 188 人亲自提交的书籍排序用来核对代理推测的偏好。对这些人排过序的书籍两两比较时代理与本人的排序一致率约为 61%随机猜测为 50%。这是偏好排序的一致率不是成交率或满意度。[2]报告在自身分析框架下把结果损失的大部分归因于偏好信息不准确用人类实际偏好评分时模型与市场设计之间的结果差异较小。[2]这个问题放到产品里很常见。“喜欢科幻”可能意味着喜欢严密的科学设定也可能意味着喜欢太空背景下的人物关系。把一句话直接压成标签后续检索和谈判就可能一直朝错误的方向走。我更倾向于让代理保留三类信息用户明确说过的要求、根据对话作出的推测以及还没有问清楚的问题。它们不应该在数据库里获得同样的可信度。下面是一份用于解释设计思路的需求记录数值均为虚构示例不是某个框架或支付协议的标准格式{ task_id: buy-used-laptop-001, intent_version: 1, goal: 购买一台用于每天通勤的二手电脑, hard_constraints: { currency: CNY, max_total_cost: 3500, allow_deposit: false }, preferences: [ { key: portability, value: 优先轻便, source: user_explicit }, { key: battery_priority, value: 可能重视续航, source: agent_inferred } ], open_questions: [用户能接受的最大重量是多少], approval: { allow_negotiate: true, allow_commit: false, allow_pay: false } }source、open_questions和权限范围能让后续流程检查每条信息的依据。“经常通勤”可以提示代理追问重量和续航却不足以直接生成一条“用户要求低于 1.3 千克”的硬约束。代理作出的推测需要有机会回到用户面前核对。同样允许谈判也不代表允许替用户承诺付款。即使交易平台没有接入支付“我确认购买稍后转账”也可能已经是超出权限的决定。4. 把需求确认放进执行流程如果要做一个交易代理原型我会先把流程画清楚再决定使用哪个模型。步骤需要完成的工作1. 确认需求记录用户明确要求、待确认问题和授权版本。2. 核实候选检查商品信息、报价来源和有效时间。3. 提出行动由模型提出报价、还价、接受条件或退出的建议。4. 执行前校验越权则拒绝信息不足或需要新授权时回到用户确认。5. 执行与核对执行已获准行动核对工具结果并保存记录。这条流程需要区分三个不同的输入输入来自哪里在流程中的作用用户确认的需求与授权用户确认记录决定代理能做什么、不能做什么商品状态与报价检索结果、卖家回复、交易工具返回值提供候选事实需要记录来源与时间代理提出的行动模型输出提议下一步交给执行层检查关键是避免让同一段模型输出同时扮演“提出行动”和“批准行动”两个角色。例如模型认为可以加付 200 元定金不应因此就能修改用户的allow_deposit。卖家回复“买家已经同意付款”也不能成为新的用户授权。外部消息可以影响交易判断修改权限仍应经过用户确认的入口。下面的伪代码只展示检查顺序省略了身份校验、授权有效期和各类业务规则收到代理提出的下一步行动 读取用户最近确认的需求与授权版本 如果行动依据的版本已经过期重新评估 如果缺少关键商品信息或价格已经失效补充核实 如果总价、定金或交付条件违反已确认的要求拒绝执行 如果行动会产生尚未获准的承诺或付款请求用户确认 保存本次比较依据与授权引用 执行已获准行动并记录工具返回的结果版本检查很容易被忽略。代理开始谈判时预算是 3,500 元期间用户改成了 3,000 元如果执行层还拿旧记录校验逻辑可以全部跑通结果仍然违反用户的新要求。执行工具也应有自己的状态。请求超时意味着“暂时不知道结果”不等于付款失败。遇到这种情况应先查询交易状态再决定是否重试避免为了恢复流程重复提交同一笔操作。5. UCP 与 AP2 分别处理哪一段交易系统之间如何衔接已有专门的协议工作。Google 在 2026 年 1 月宣布的 Universal Commerce ProtocolUCP覆盖商品发现、购买到售后支持的互操作流程。[4]2025 年 9 月公布的 Agent Payments ProtocolAP2则通过带密码学签名的授权记录把用户意图、购物车与支付关联起来它分别讨论人在场确认购买以及提前委托代理的情况。[5]这些协议处理的是系统协作和交易授权。商品是否适合用户仍需要产品自己的判断与证据。假设代理按授权买下了一台 3,200 元的电脑订单和支付记录都能核对。后来用户发现它太重每天背着很难受。此时支付系统可能没有出错问题出在需求没有问清楚或者选品阶段没有重视重量。因此接入支付协议之后前面的需求确认和候选比较仍然要保留。本文的 JSON 示例也不能直接当成 AP2 的授权凭证使用。6. 评测交易 Agent不能只统计成交率如果一个代理总是接受第一份报价它可能很容易成交。单看成交率甚至可能优于一个会耐心比较、在不满足要求时退出的代理。开发者需要先写清“什么算完成”再选择指标。下面是我会在原型阶段保留的一组评测记录检查项可以怎样记录它能帮助发现什么需求理解让用户核对关键条件比较候选的偏好排序代理是否从一开始就选错目标硬约束超预算、擅自承诺定金等事件的次数与总尝试数执行边界是否失效报价比较已验证的候选、总价、交付条件和有效时间“划算”的结论基于多大范围任务结果合格候选是否找到、是否按授权完成、退出原因流程完成与用户目标是否一致人工参与确认、纠错和接管分别发生多少次系统把哪些工作留给了用户资源成本耗时、模型调用和外部工具成本多谈几轮带来的收益是否值得这些指标要放在一起解释。例如正确拦截越权行动后没有付款的任务会增加这类结果不能直接归为代理能力不足。做模型对照时我会固定同一份商品集合、初始需求、对手规则和时间预算并运行多次。还要记录失败样本究竟没有找到合适候选还是明明找到了却在后续谈判中失去了它。如果想衡量“本来还能做得更好多少”需要一个可比较的基准。在限定商品池、已知用户排序的模拟环境里可以计算或设定基准结果到了开放市场代理通常看不到所有潜在报价就应如实说明比较范围避免声称拿到了“全网最低价”。7. 最后需要交给用户的是可核对的交易结果两场实验都来自同一家公司参与者也是员工场景比真实市场简单。它们给出了值得继续研究的线索还不足以给开放市场里的所有模型排出一张收益榜。但对于正在做 Agent 的开发者这些线索已经能落到设计上保留需求的来源区分推测与确认让行动经过授权校验并留下候选比较和执行结果。当代理说“已经替你谈好了”用户应当能看见它比较过什么、接受了哪些取舍以及最终替自己承诺了什么。这些信息比一段流畅的成交总结更能说明系统是否值得继续使用。参考资料AnthropicProject Deal: our Claude-run marketplace experiment2026-04-24。AnthropicProject Swap: What happens when agents trade for us?2026-09-24。Bianchi F. 等How Well Can LLMs Negotiate? NegotiationArena Platform and AnalysisICML 2024PMLR 235:3935–3951。GoogleNew tech and tools for retailers to succeed in an agentic shopping era2026-01-11。Google CloudPowering AI commerce with the new Agent Payments Protocol (AP2)2025-09-16。配图为公开研究相关图片转存出处Anthropic搞了个全是AI的闲鱼群大模型在里面互割起了韭菜-CSDN博客 。流程、JSON 与伪代码用于解释本文设计不构成完整交易系统实现。
：网络编程中的关键配置函数)
