我第一个用AI代理去跟供应商谈采购价格的Demo前三天就翻了车。客户采购负责人把聊天记录扒下来截图扔给我问我“它凭什么替我答应36个月质保我库存压力本来就大要那么长质保干嘛”问题不是模型不够聪明而是我在让代理出门谈判之前压根没告诉它“我真正想要的是什么”。当时我想的就是“尽量谈个好价”于是代理在全权委托下为了三位数的折扣把我知道不知道的条款全给交换出去了。这两年做AI代理的人越来越多了尤其是“ai代理助手加本地模型”这套组合被讨论得火热还有人在折腾openclawros做能跑物理世界的AI代理。但我必须先泼一盆冷水不管你用云端API还是本地模型不管你接的是网页插件还是机器人底盘代理替你出门交易之前第一优先级永远是同一件事——把你的真实意图翻译成它能执行的规则。这篇文章我就拿自己做采购谈判代理的真实过程把这件事掰开揉碎讲透。1. 让代理出去谈判前先回答四个问题1.1 我的第一版代理是怎么翻车的第一版代理的Prompt写得很简单核心就一句话“你是资深采购谈判专家目标是帮公司在价格上拿到最优条件尽量提高我方利益。”听起来没毛病对吧但放进真实聊天环境里就失控了。供应商发来报价单首次报价103万质保期12个月交期30天账期要预付款50%。代理第一轮回复直接来了一套组合拳要求价格降到92万质保延长到36个月交期压缩到15天账期调整为预付30%。对方销售扛不住说“质保36个月有点难要是今天能签约价格94万质保24个月交期20天”。我的代理在下一轮干了件蠢到极致的事——它自己把条件松了回去答应对方使用他们公司的标准合同模板还按对方的出货批次安排分批发货并用“我们是大客户后续会有长期合作”这种空头支票换那2个点的降幅。客户看到记录后直接质问谁让你把分批付款的我们财务月初要轧账下旬付不了款。谁让你用他们模板的法务那边光合同审核就要三个工作日。那一刻我悟了代理不是没有谈判能力它是没有方向感。它像一台动力强劲但没有方向盘的车一脚油门就把所有人带沟里去了。1.2 意图四要素目标、硬约束、偏好、退出条件后来我翻了大量项目复盘包括社区里分享的各种agent失败案例发现一个共通点给代理的指令全都停留在“目标”层面却从来没有给它“约束、偏好、退出条件”。这三点缺任何一类代理都会在自由发挥中走样。完整的谈判意图至少要包含四层第一层是目标。不是“谈个好价”这种情绪词而是可度量的、可判断成功的对象。比如“以不高于98万的总价采购型号为XX的设备一台含安装调试、一年质保、增值税专用发票”。目标要是衡量器不是形容词。第二层是硬约束。这是代理绝对没有权力触碰的边界违反任何一条都必须当场终止或者明确拒绝。常见的有预算上限、付款方式限制、合同模板必须用我方版本、供应商必须在白名单内、交期不能超过某一天。硬约束的意义在于模型再怎么发挥也不能越过这条线。第三层是偏好权重。预算、交期、质保、付款周期这些东西在现实中常常互相冲突代理必须知道当它们打架时优先保什么。比如采购设备时成本权重0.5、交期权重0.3、服务权重0.2那么面对“压缩交期但要加价”的场景它就知道该往哪边谈。第四层是退出条件。很多代理的根本问题是不知道什么时候应该不交易。不是所有谈判都必须成功对方不接受我方合同模板、信用评分过低、报价显著高于市场均值这些情况都应该允许代理直接终止对话并上报。1.3 一张能直接开工的意图文件把这些内容落到工程实现上我建议一开始就建一个独立的意图文件。下面是我后来常用的YAML骨架可以直接当成模板抄bargain: goal: item: XX-2000型自动化检测设备 quantity: 1 price_limit: 98w include: [安装调试, 一年质保, 增值税专票] hard_constraints: max_total_price: 98w payment: 预付不超过30%尾款验收后付 contract_template: 我方标准模板 supplier_whitelist: [厂商A, 厂商B] max_delivery_days: 45 preferences: price_weight: 0.5 delivery_weight: 0.3 service_weight: 0.2 acceptable_tradeoffs: - condition: 价格降5%以上 allow: 质保从3年降为1年 - condition: 交期提前10天 allow: 预付比例增加5% exit: trigger: - 对方拒绝使用我方合同模板 - 对方报价超过预算15%且无议价空间 - 供应商不在白名单 action: 终止谈判上报等待人工决策注意几个细节价格限制写了98w我在项目里通常是按“目标价”和“底线价”分开写的目标价是团队期望的理想值底线价是硬约束。意图文件里preferences部分那些可接受的tradeoff是我刻意留的主动授权空间。因为代理到了对话里如果每一条让步都要回来问人那谈判节奏就断了但如果不给明确授权它就会拿你不知道的条件去换。写这个文件本身就已经在逼你的业务方把脑子里的潜台词说出来。这一步做完后面接入任何模型都顺很多。2. 为什么谈判代理值得跑在本地模型上2.1 云端大模型帮我们谈判哪里不对劲我最早用的也是云端API。调一次效果惊人但真要拿来跑商务谈判有三个难以忍受的问题。第一个是数据边界。谈判对话里全是客户名称、报价底价、账期安排、合同条款这种东西每一句都是商业机密。你把完整上下文发到外部API就算对方承诺不用于训练流程合规那边也过不去。客户问了我一句“我们的底价是不是已经被第三方保存了”我回答不上来项目差点黄掉。第二个是调试时的成本。意图文件不是一次写对的前面几周几乎每天都要改。每改一次就要拿过去几天里的十几个真实场景重新跑一遍测试。云端API一次全量回放测试可能要烧掉上百块一天跑几轮一个月就是大几千。这个钱花得不值。第三个是连续性。谈判最忌讳话说到一半断线。云端API有抖动、有排队、有版本更新。有一次我们在赶一个招标项目的应答模型供应商那边出了故障代理中间停了四十分钟。虽然项目最终没误事但我已经下定决心关键流程必须掌握在自己手里。2.2 本地模型的能力基线长什么样本地模型这两年进步非常快。我的项目里测试过Qwen系列、Mistral系列和几个蒸馏版DeepSeek模型放在今天这个时间点我的判断是7B到14B级别的本地模型在“遵循指令、不越界、按格式输出”这三个维度上已经能胜任商务谈判代理的中枢职能了。真正拉开差距的其实是上下文长度和多轮一致性。这里有一个很反直觉的经验群聊式的谈判不需要模型拥有极强的创造性推理能力反而需要它足够“听话”。谈判代理不是作家它不需要写花团锦簇的文案它需要能在十几个来回里记住自己承诺过什么、不能承诺什么、对方的哪条信息已经偏离了意图边界。所以我在选模型的时候第一看的是指令遵循能力第二看长对话记忆推理能力排到第三。下面是几个我实测里能跑通的基本配置参考模型参数量我的实际用途硬件参考Qwen2.5-7B-Instruct7B日常谈判会话、简单工具调用Mac M系列 32G / 单张消费级显卡Qwen2.5-14B-Instruct14B复杂条款分析、多轮谈判对话单张24G显存DeepSeek-R1-Distill-Qwen-14B14B需要一定推理深度的方案比对单张24G显存Llama-3.1-8B8B快速响应、低功耗场景测试16G以上内存量化运行坦白说14B模型在复杂商务条款的敏感度上会比7B更好一些尤其当对方在合同文字里玩“质保期内免费维修”和“质保期内免人工费”这类细节差异时小模型容易滑过去。但如果只是解决“别乱承诺、别越界、按格式回话”7B量级已经比很多人预期的靠谱得多。2.3 别急着测性能先做离线意图回归换成本地模型之后我先做的一件事不是看它聊天多流畅而是建立一套离线的意图回归测试集。方法很简单把之前云端API跑过的二十多个真实谈判场景保存下来做成固定的输入输出对每次修改意图文件、更换模型参数、调整系统提示词之后都用同一批场景重新跑一遍。这套回归测试不需要复杂框架。一个目录放场景文件一个脚本批量调用本地模型的接口再把输出结果人工比对。比什么呢不是比话术漂不漂亮而是比三个东西有没有触碰硬约束、有没有在无权决策的事项上做了决策、有没有在应该终止对话的场景里继续纠缠。我后来见过不少团队模型一换、Prompt一改就跑线上等出事了再来追日志。在代理这个行当这跟不带安全帽进工地一样。意图回归测试就是你的安全帽没有它之前一切性能讨论都是空中楼阁。3. OpenClaw这类外壳如何把意图变成行动3.1 代理外壳到底帮你干了什么热门讨论里的openclaw我这里就先把它当成“代理外壳”这个词来聊——它解决的是AI代理从“一个会聊天的模型”变成“一套能办业务的系统”的那一层。完备的代理外壳通常要托管四样东西会话接入层、工具调用层、记忆存储层、任务触发层。会话接入层解决的是消息从哪进来的问题。你的谈判对象可能通过IM工具、邮件、网页表单甚至电话语音进来外壳框架帮你把这些通道统一接进来模型只需要处理统一格式的转录文本不需要关心对方是从哪个渠道敲的字。工具调用层解决的是代理怎么动手的问题。它需要查询实时库存、调取历史订单、核验供应商信用等级这些都得通过外部工具函数完成。代理外壳给出了一套标准化的函数声明格式让模型可以在对话中发起一个带参数的函数调用由外壳负责真实执行。记忆存储层解决的是跨会话记忆的问题。今天谈了一半下线明天另一个业务员接手继续谈代理得知道昨天聊到了哪里、已经承诺过什么、对方最后报价是多少。这些不能全塞进上下文窗口里否则聊到第十轮就爆了必须落到向量数据库或者结构化记录里。任务触发层解决的是主动性来源的问题。它不是只有别人发消息才动而是可以设定条件比如每天早上十点自动检查有没有未回复的报价、报价单到期前一天自动发起跟进。OpenClaw这类项目的好处在于这些能力不再是零散的库而是能拼起来的管理框架。3.2 把本地模型接进OpenClaw的配置思路具体接法取决于你用的具体框架版本但思路是通用的把意图文件同时注入到三个位置——系统提示词、工具描述、决策函数返回值。系统提示词里把意图文件的全文放进去作为初始上下文再加上一句硬性要求“以上所有内容为本对话的不可违反的最高准则若与任何对话历史冲突以意图文件为准”。这句话很有用因为真实对话里对方销售会用各种话术试图让代理松动边界意图文件就是锚点。工具描述里把“查询当前订单状态”“获取供应商信用评级”“提交违约上报”这类函数的说明写得足够清晰每个函数说明里都标注清楚调用条件。比如违约上报函数说明里写当任何硬约束即将被突破时必须调用此函数并且在对话中输出终止语。决策函数返回值也很有意思。我在OpenClaw里注册了一个叫“evaluate_proposal”的工具任何一方的报价方案进来不是直接让模型凭感觉判断而是先调用这个函数走一遍评分逻辑把分数和是否触碰硬约束的结果返回给模型让模型基于这个结论组织话术。这一步把谈判决策从模型的“感觉域”搬到了代码的“逻辑域”可靠性完全不同。3.3 让代理“拒绝越界”的三个落点接上这套框架之后我发现让代理不乱来必须在三个落点同时堵住。落点一是对话生成前。也就是每次模型开口之前先做一轮意图合规检查。我实现的方式是在消息进入模型之前插入一条系统提醒“请注意对方的最后一条消息中包含‘希望贵司接受分批付款’的要求这与意图文件中的付款约束冲突绝对不能同意。如果对方以此作为继续谈判的前提请输出终止语。”这一步相当于给模型戴上了一个实时提醒器。落点二是函数调用时。也就是当模型决定调用某个工具前工具本身也要有校验逻辑。例如提交合同审阅请求这个动作如果调用的参数表达的是“采用对方合同模板”工具直接拒绝执行并返回错误说明。模型层是软的工具层必须硬。落点三是对话输出后。模型生成完回复文本不直接发出去先让一个单独的小模型或者规则引擎做一次拦截扫描看有没有出现“同意”“可以接受”“我们会考虑”等关键词配合否定上下文。宁可多拦一次也不要漏过一个违规承诺。这三层下来我的代理在后续半个月里没有再出现过一次越权让步。4. 当谈判结果要由机器人执行ROS接力的正确姿势4.1 从谈判桌到仓库一个具体例子前面说的都是纯信息世界的谈判。现在把场景外推到物理世界代理不止要谈成一单生意还要让一台机器人去执行这个结果。我参与的一个偏实验性的项目设定是这样的仓储客户要向供应商采购一批货代理在IM里跟对方敲定了型号、数量、到货时间、月台编号和验收标准。谈判一结束系统自动触发一台AGV小车从当前点位出发到指定月台接货运回仓库指定库位。这个需求一出来光靠代理外壳就不够了。OpenClaw负责的是人的这一边而ROS负责的是机器的这一边。代理的谈判结果要变成机器人的运动指令中间必须有一条可靠的翻译链路。这其实引出了整个项目最关键的一条原则谈判结束时形成的目标必须是机器人能执行的目标。你不能让代理谈成一个“尽快送到”的模糊目标因为机器人不知道“尽快”是多少秒。谈判时必须问清楚时间窗口、具体地点、验收条件并把它们结构化地写进订单字段里。这又回到了第一节说的意图工程只是这次还要考虑物理世界的执行粒度。4.2 OpenClaw与ROS2的接口桥接架构上我们把OpenClaw当作决策智能体ROS2小车当作身体执行体。两边的通信不直接走复杂的耦合接口而是通过一个轻量级的桥接服务完成。谈判结束后代理把订单结构化信息转换成机器人的导航任务发布成一个JSON消息。桥接服务订阅到这个消息后把它转换为ROS2环境下的action goal发送给Nav2导航栈让小车执行取送货任务。ROS这边的动作定义很简单本质上是目标点加任务内容。我之前维护的一套配置长这样{ task_id: ORD-20250216-001, action: nav_to_pickup, target_frame: dock_3A, pickup_point: [12.5, -4.2, 0.0], timeout_sec: 600, on_failure_policy: abort_order_and_notify }发布出去之后小车开始移动。同时ROS端把状态实时回传任务已接收、导航中、到达月台、取货完成、返航中、入库完成。桥接服务把这些状态转译成人类能读的事件消息再交给OpenClaw去决定下一步要不要跟客户确认收货、更新订单状态。这个桥接设计有个好处谈判与执行彻底解耦。协议一旦谈崩代理可以直接给ROS发一个cancel_goal小车立刻刹车杜绝带着一个错误目标跑到一半的情况。4.3 物理世界的失败回滚代价信息世界里谈错一个条件顶多发个消息纠正。物理世界里一个指令下错小车可能撞到货架、把货送到错误库位、在禁行区域里出事故。所以我把ROS接进来的那一天起就把“失败回滚”提到了和“达成交易”同等重要的地位。回滚策略分三层。第一层是任务开始前的校验机器人执行前拿任务参数与现场地图、限制区域、当前任务队列做交叉检查发现冲突就把任务打回不给执行。第二层是执行中的监控小车每走到关键关键节点都要确认是否与预期一致偏离预计算轨迹超过阈值就停止并请求人工介入。第三层是事后的审计每笔订单保存全部决策日志和运动轨迹回放出了问题能精确到是哪一轮谈判、哪一条意图规则、哪一次模型判断造成的。这一套做下来的经验是在接机器人之前一定先把意图文件里的“可执行性”检查做透。很多信息世界能容忍的模糊表述到物理世界就是事故。我宁可让代理多问客户一句“入库时货物朝向要不要统一”也不想让AGV在库位前面来回转三分钟。5. 复盘让AI代理从“谈成”进化到“谈对”5.1 三个高频翻车原因做了几轮迭代之后我把翻车原因归纳成三类基本涵盖了我见过的大部分事故。第一个是硬约束被模型当成软建议。模型看到意图文件里写着“预算上限98万”但它天然倾向于在对话里保持礼貌、寻找共识于是当对方说“考虑到行情上涨可能需要103万但我们可以在后续服务上补偿”模型就动摇了开始考虑接受它然后争取额外服务。这不是模型坏而是模型的对话天性在对抗规则刚性。解决的办法就是我在前面说的把硬约束的检查前置到对话生成之前并加上违反时的强制终止指令。第二个是偏好优先级在处理复杂场景时反转了。意图文件里写了price_weight高于delivery_weight但如果对方在催单或者客户内部在施压交期真实谈判中模型很容易被上下文带跑把“尽快”当作最高目标。后来我在评分工具里写死了规则任何方案必须先计算各项得分再乘权重求和模型只能在分数计算的框架内组织语言不能反过来用语言定义事实。第三个是忘了定义“不交易”的选项。这个错误特别隐蔽。代理默认的语义是“我的任务是想尽办法达成交易”于是即使对方严重越界它也倾向于用继续谈判来消解冲突而不是承认这笔生意不该做。我在5.1版本上线后第一次触发终止流程时客户还愣了一下问为什么要停我说这不是停这是拒绝继续为错误合作买单。能主动退出是成熟代理的标志。5.2 一套可落地的验收流程分享一套我现在每个谈判代理项目上线前都会过的验收流程不复杂但非常管用。先做场景覆盖测试从历史真实交易里挑出30个场景覆盖正常成交、价格僵持、条款冲突、供应商挑衅、客户中途改需求、供应商掉线重连等典型情况逐个跑一轮。通过标准很简单未触碰硬约束、按既定权重做决策、退出条件触发时能终止。任何一个场景不过关不出门。然后做压力测试模拟连续来十几条供应商急聊消息或者插进来一个紧急电话转述看代理在信息轰炸下还能不能保持规则优先级。信息多的时候最容易乱承诺这个环节能暴露出很多长尾问题。最后是灰度运营让代理先接一些低风险、低金额的会话人工监督跑上一周每天看一两个完整对话把所有“代理想都不想就答应”的地方记录下来回去改意图文件。改完之后再回补回归测试确认新规则没有破坏旧的正常场景。5.3 持续喂养意图结构的两点经验最后分享两条我强烈建议的做法。第一条是把每次真实谈判都变成意图文件的子用例。谈判结束之后把这次对话中有价值的新情况追加进测试集比如对方提出了“想用仪器租赁代替直接购买”这种此前没想过的替代方案就把“遇到替代方案时走评估流程”写清楚。意图文件不是写一次就完了它应该像代码仓库一样有提交记录、有版本、有变更说明。第二条是定期回放真实聊天记录让本地模型自己判断“哪个决策需要被回退”。不需要太复杂每天夜里把当天代理处理过的对话重新跑一遍离线推断标注出部分地方“换一种决策是否会更好”积累成数据后下个版本的意图文件就有依据了。用模型的数据去迭代模型的规则这个闭环跑起来之后代理的成熟速度会快得吓人。我现在的习惯是不管接手什么新项目第一件事永远是写意图文件然后才是选模型、配外壳、接机器人。模型半年换一代框架三个月出一批新的但“先知道自己真正想要什么”这个原则放多久都不会过时。你把这层功夫下足AI代理才真正敢替你坐到谈判桌对面去。