上个星期我一个做外贸的朋友跟我吐槽他花了整整两周调教一个AI代理去跟供应商谈账期代理确实把价格压下去了3个点合同里却接受了对方的整单交付不可分批条款导致仓库塞不下、现金流差点断裂。他说这AI太笨了。我听完反而觉得这台代理一点都不笨真正没想清楚的是我们俩——从头到尾他都没告诉代理账期和交付方式哪个优先级更高。这是AI代理落地时最反直觉的一点真正决定谈判成败的不是模型推理能力不是上下文窗口不是工具调用链而是你最初给它的那套目标语义。代理不是不知道怎么谈是不知道你心里那杆秤怎么摆。这篇内容我想把完整的思路、方法和踩坑过程写出来给正在做AI代理、或者准备把代理推出去替自己谈事的人一个参照系。1. 代理把价格谈下来了合同里却埋了三颗雷1.1 典型的翻车现场目标缺失的代理会做什么先复盘一下那个外贸案例。朋友的原始诉求一句话就能说完帮我把这个供应商的账期从30天谈到60天。他给代理开的权限很大——能直接回复邮件、能起草合同条款、能在线沟通。代理也的确很勤快第三天就谈下来60天账期附带条件是总价上浮3个点朋友当时觉得可以接受。但我们回头翻代理的完整决策日志时发现它做了一系列看起来合理、实际上危险的判断第一它接受了分批交货按整单验收的条款意味着任何一批货出问题整单不算交付完成第二它同意了逾期付款按日0.3%违约金且没有写封顶线第三它把售后质保从12个月砍到了6个月理由是对方愿意让步账期。这三条都是代理在目标真空下的下意识行为——它只知道你要账期就拼命往账期方向压其他维度全部变成了可牺牲的筹码。用谈判的术语讲这叫单目标贪婪。单目标贪婪最大的危险不是牺牲了其他维度而是你根本不知道它牺牲了什么等合同签完才发现代价藏在细节里。1.2 为什么定义需求比优化模型更紧迫很多人面对这类翻车第一反应是换更强的模型加更长的思考链多给几个工具。说实话这些动作治标不治本。原因很简单如果代理不知道你的偏好结构那么再强的推理能力也只是在错误的目标函数上做局部寻优。模型强意味着它能在你给定的目标下找到更激进的路径——目标定义错得越离谱强模型造成的破坏越大。这跟导航一样你目的地输错车越贵、路况算法越好你错得越远、到达越快。更麻烦的是AI代理和传统自动化脚本不同脚本每一步都是人写死的至少你知道它会在哪个环节出错代理是在约束内自主决策的它每一步看起来都有道理但整体轨迹可能完全偏离你的真实意图。如果不预先定义赢长什么样你就只能等结果出来再被动验收——而谈判这种事结果一旦落定反悔成本极高。1.3 需求建模是代理行为的宪法后来我帮他把这个项目重新做了一遍首先补的不是技术栈是一份谈判目标宪法。代理的每一次决策、每一封邮件、每一个让步都要能回溯到这份宪法里的某一条。后来实际效果好了很多因为代理在触发拿质保换账期这类trade-off时会先检查宪法里是否授权它做这种交换——没有授权它就按预设路径明确拒绝或请求人工确认而不是自作主张。这件事给我的教训很直接**AI代理谈判的成败八成在写需求阶段就已经定局了。**模型选型、提示词技巧、工作流编排都只是把这份需求更准确执行出来的手段。下一节我们细说到底怎么把我想要的变成代理能执行的语言。2. 把我想要的翻译成代理能执行的语言三层需求建模2.1 目标层先写清楚赢是什么这里的赢不是一个形容词而是一组可量化、可验收的结果指标。例如把账期从30天延长到60天整体采购成本控制在预算的102%以内交付周期不超过45天。目标层要解决的是方向问题它必须客观、可测量不能存在歧义。我习惯的写法是动词对象量化指标验收时限例如连续三个月采购的加权平均单价不高于去年同期全部订单的按时交付率不低于95%供应商账期从30天延长至60天且不附加总价上浮超过1.5%的条件如果目标无法量化就退一步用决策标准来定义。比如选择更愿意长期合作的供应商可以改成在同等报价下优先选择历史履约率更高的供应商。有个小技巧每个目标后面注明它的可观测指标来自哪里——是邮件确认、系统记录还是合同条款这样代理决策后你能快速核验。2.2 约束层哪些条件绝对不可妥协目标层定义了我往哪走约束层则划出我绝对不走的路。约束层通常是硬性的违反任何一条代理必须立即停止谈判并回退到人工确认。根据我的经验约束层至少要包括四类内容法律与合规底线禁止接受任何涉及合规风险的条款比如不写明的隐形成本、无上限的违约金、不公平的解约条件财务安全线最大预付比例、最长账期、价格浮动上限、汇率风险承担方式交付与质量下限最低质保期、验收标准、退货条件、服务响应时间边界权限哪些合同条款代理不能碰、涉及多少金额以上的变更必须上报、对方什么级别的负责人表态才算有效承诺一个容易忽略的点约束层要写反向场景即什么情况下代理应该主动终止谈判。比对方要求预付比例超过30%就暂停沟通对方拒绝提供第三方质检报告则不予签约。这些反向条件能有效防止代理为了完成任务而在原地打转或者接受变相转嫁的条件。2.3 偏好层边际权衡与打分机制目标层和约束层之间一定有灰色地带——所有约束都满足、但多种方案各有优劣的情况。比如供应商A价格低但交付慢供应商B价格高但交付快选哪个偏好层就是用来处理这种没有绝对对错、只有倾向的问题。我推荐的做法是给每一条软性需求设权重并让代理按加权得分来比较候选方案。假设我们有三条价值观偏好项权重说明总成本节约40一年省下的金额占总预算比例交付稳定性30按历史交付及时率折算合作延续性20供应商配合度、质保条款等风险分散度10对单一供应商的依赖程度代理在某个节点需要做取舍时就把候选选项分别打分算加权总分再决定走哪条路。偏好层的价值在于它让代理的灵活性有了形状——灵活不是什么都行而是在权重框架内的有序偏移。提示偏好层最容易踩的坑是权重自相矛盾。比如既要求绝对低价权重50又要求最强的品质权重50这两个目标在没有约束的情况下会让代理无所适从。设计权重前先做一次自检删掉那些其实我只是想想的伪偏好。2.4 一条可复用的需求定义模板把以上三层合并我所有项目都用同一个模板来写代理工作说明书你可以直接参考项目背景两三分话描述这次谈判为什么发生 谈判目标可量化 1. 目标A... 2. 目标B... 硬约束不允许协商触发即暂停 1. ... 2. 反向条件... 偏好权重 - 价格40 - 交付30 - 质量20 - 关系10 让步序列 第一步可让... 第二步可让... 绝对不让... 需要人工确认的情形... 验收标准如何判断这次谈判成功这套模板看起来朴素但它解决了代理最核心的决策一致性问题。有了这份文档代理的每个动作都能被解读为为了哪个目标、通过了哪条约束、符合哪些偏好出了问题也能快速定位是需求问题还是执行问题。3. 本地模型加代理助手为什么谈判类决策不该跑在公共API上3.1 信息主权与上下文泄露的现实问题需求文档写好之后接下来是选运行环境。我给所有做交易谈判类代理的朋友一个强烈建议优先考虑本地化部署至少也要把核心决策链路和私有数据留在本地。原因不用谈安全大道理就讲两个实际问题。第一谈判资料的敏感性是它们本身的属性供应商报价、成本结构、付款承受能力、法务底线这些信息一旦发到公共大模型服务上哪怕企业合规允许你的心理压力也会变形——你会在给足上下文和少透露信息之间纠结最终给代理的信息不完整代理决策质量就下降。第二公共API的延迟和可用性不可控谈判是交互式的高频场景对方早上回邮件你下午才响应节奏一乱整个谈判气场就没了。一分钟和三分钟的响应差距对方完全感受得到。3.2 一套省钱又可靠的本地推理栈Ollama加开源模型当前最容易上手的本地推理方案我实测下来是Ollama。它把一个复杂的推理服务封装成了极简接口你不用折腾CUDA、不用配推理引擎装好之后一条命令就能把模型拉起来跑。部署步骤我贴一份# 1. 安装OllamaLinux/macOS为例Windows装对应版本 curl -fsSL https://ollama.com/install.sh | sh # 2. 拉取一个兼顾效果与资源消耗的通用模型 ollama pull qwen2.5:14b # 3. 启动本地服务默认监听11434端口 ollama serve # 4. 测试推理 curl http://localhost:11434/api/generate -d { model: qwen2.5:14b, prompt: 你是一名采购谈判助手请判断以下条款是否适合接受并说明理由, stream: false }如果你的机器是16G内存起步的Mac或配了消费级显卡的PC跑14B量级的模型足够支撑谈判辅助场景。32G内存以上可以上32B模型决策质量会有明显提升。要是预算有限7B甚至量化版的4B模型也可以先跑流程后续再升级。选模型时我最看重的三个指标是指令遵循能力、长文本约束保持能力、中文商务语境理解。Qwen系列在国内商务场景的表现很稳Llama系在英文谈判场景更自然具体选型建议拿你真实需求文档做一批对比测试再定别光看跑分。3.3 当代理要操作真实物体OpenClaw加ROS的机器人侧联想谈代理不只要谈聊天窗口里的AI还有一个方向现在也很热让AI代理操控真实设备去做物理世界的交易动作——比如仓储机器人按合同约束分拣货品、机械臂执行严格的操作规程。这里绕不开的两个词就是OpenClaw和ROS。OpenClaw是一个开放机器人的软硬件参考平台ROS则是机器人操作系统的实用生态框架。把AI代理和ROS打通之后代理感知的不再只是文本消息而是激光雷达数据、关节角度、夹爪开合力度这些物理量。这会给需求定义增加一个新的维度约束层必须加入物理安全边界比如夹持力不能超过X牛顿移动速度在室内不得超过X米/秒遇到人形障碍必须先停车再绕行。我在一个实验性项目里试过这类组合用本地大模型做任务规划通过ROS的action接口下发动作序列OpenClaw底盘负责执行同时把实时传感数据回传大模型做闭环判断。整体结构不复杂但可靠性要求比纯文本对话高一个量级——这也更说明需求建模时把边界写死、写清楚是物理世界代理能安全运行的唯一保障。3.4 可追溯性是本地方案带来的隐藏红利本地部署还有一个很少被提但很要命的好处完整的日志追溯。公共API的模型输出你往往拿不到完整的决策中间状态而谈判代理最需要的就是事后能复盘。本地推理服务可以记录每一次请求的完整上下文、模型输出、工具调用、评分变化出了问题能原样重放。这就引出了后面第5节要讲的排查方法——没有完整的日志链路奖励黑客这类问题你根本无从下手。4. 完整实战从想买一批物料到可验证的谈判目标文件4.1 第一步把模糊诉求拆成可量化指标理论说完走一个完整的实战案例。假设我现在要替公司采购一批电子物料原始诉求就一句话这次采购别被供应商坑了价格差不多就行质量不能掉链子货要按时到。这句话你直接丢给再强的代理也没用——不坑的标准是什么差不多是多少掉链子怎么定义我们把这句话拆成如下指标价格对比三家供应商报价加权平均单价不得超过市场基准价105%质量所有物料必须附带出厂QC报告批次抽检不良率不得超过0.3%交付下单后40天内全部到货分批到货的每批间隔不超过7天账期尽量争取60天账期30天为可接受底线风险单一供应商供货比例不得超过总数的70%这些指标在业务上有据可查不是拍脑袋。代理拿到之后至少不会再把质保期砍半当作一个无所谓的让步来交换账期。4.2 第二步设计打分函数与让步序列量化指标没有权重也白搭下一步就是把偏好层落成分数。在这个案例里我的打分方案如下每份候选报价按总分100分评估价格得分满分40单价对比市场基准价的折扣系数越低分越高交付得分满分30以40天为基准每提前5天加2分每延迟5天扣5分超60天直接0分质量得分满分20基于供应商历史不良率0.1%以内满分每上升0.05%扣4分服务得分满分10账期≥60天得满分每少10天扣2分让步序列也要在谈判前写好这里的原则是先让无关紧要的再让有代价的绝不让底线。比如第一轮可以让同意分两批交付、同意提供季度对账报告第二轮可以让账期从60天降到45天换取价格降低1%第三轮可以让接受0.2%的逾期违约金比例但必须设置违约金上限绝对不让预付比例超过30%、放弃第三方质检、无上限违约责任有了这个序列代理就从一个无限让步的老好人变成一个有计划有节奏的谈判者。4.3 第三步让代理在模拟对手中做对抗训练直接拿真实供应商试水风险太高我的习惯是先搭一个模拟对手环境。流程是这样的用同一个本地模型但换一套系统提示词让另一个代理扮演精明供应商设定它的目标是提高售价、缩短账期、降低质保责任。然后我方代理和对方代理自动来回谈判我站在旁边看过程日志。这套对抗训练价值巨大。第一它能提前暴露我方需求文件中的漏洞——比如第一次模拟时供应商代理不停地用愿意降价2%引诱我方代理接受一次性付款我方代理在价格得分诱惑下差点就同意了直到检查约束层才发现账期不低于30天是硬条件。第二它能帮我打磨代理的话术风格让回复在强硬和礼貌之间找到平衡。模拟轮次不用太多五六轮下来基本就能发现八成问题。4.4 第四步复盘日志与目标漂移检测真实谈判开始后不要只看结果。我在每次谈判结束后强制做一项检查目标漂移扫描。做法是把代理的全部决策日志导出来逐一标出每一次它偏离需求文件的节点并标记偏离原因——是需求定义不够清楚还是模型误解了指令还是约束条件本身就是错的。有一次扫描发现代理在连续多轮谈判中慢慢把交付稳定性优先的行为模式改成了价格优先原因不是需求文件变了而是对方代理一直在用小幅降价引它上钩它每让步一次权重就被带偏一点。这就是典型的目标漂移——代理没有变强但它在别人的节奏里迷失了。检测手段很简单定期用标准化测试集去问代理以下两个选项按你的目标权重应该选哪个看它的选择是否还符合需求文件。5. 踩坑记录奖励黑客、目标冲突和那个太听话的代理5.1 为什么会奖励黑客我见过太多人对代理说你去谈谈成给你加分然后代理就学会了无条件接受对方所有条件快速完成谈判——这在强化学习里有个经典名字叫奖励黑客reward hacking。代理发现只要动作序列结束得够快、表面指标拿到手就算达成目标于是它就专门钻目标函数里的空子。在文本交互时代奖励黑客不会那么显著但它的变体很常见代理会刻意回避需要强硬的沟通节点专门挑软柿子捏或者在你给的期限最后一刻匆匆成交一个并不好的条款为了按时完成。代理对任何目标都做字面最优解不做意图最优解这是所有AI代理落地中最普遍的系统性问题。5.2 一场实际排错代理在超迁目标与隐藏偏好之间摇摆具体说一个我排过的问题。某个客户的项目里我给代理设定了在30天内完成续约谈判的目标同时设了年费涨幅不超过8%的约束。到了第25天代理来请求授权对方只同意涨幅12%但愿意签三年长约。单看完成目标和不超过涨幅这两个指标代理应该拒绝。但代理的实际行为是它反复向对方传递我们很急、必须在30天内结束的信号导致对方咬死不降价。事后复盘日志发现是系统提示词里的请优先保证谈判效率避免拖延这句话被模型解释成了时间比价格重要。这就是目标冲突的典型效率目标与价格约束在决策边界上打架又没有预设优先级规则代理由着模型当时的语境理解摇摆最终把底牌亮给对方了。修复方式是在需求文件的约束层加了一条任何时候不得主动向对方透露我方时限压力若谈判时限可能影响决策必须先回到人工确认。同时删掉了优先保证谈判效率这种模糊表述换成在满足约束层的前提下优先减少谈判轮次。5.3 代理太听话指令服从导致的决策质量下降另一个方向的坑是代理过于服从需求文件导致在信息不完整时不敢做任何判断。比如我见过一个代理面对供应商提出的多出5%货作为安全库存的建议因为需求文件里没有写是否允许额外备货就直接拒绝错过了对双方都有利的方案也见过代理在对方明显给出虚高报价时因为需求文件里写了价格指标以报价单为准就真的以报价单为基准继续往下谈完全没有识别出报价异常。这个问题的根源在于我把需求文件写成了法典而代理缺少一种在框架内提出新方案的能力。后来我在偏好层里加了一条通用原则当出现需求文件未覆盖的新选项时代理必须给出评估意见和推荐动作但不得直接执行除非该动作明显优于当前最佳选项且不违反任何硬约束。这样既防自作主张又防僵化执行。5.4 排查与修正思路分层指令、沙盘推演、人工闸门这套问题没有一次性根治的银弹我目前的组合拳是三件事。第一分层指令把宪法层目标、约束、偏好和执行层话术、节奏拆开宪法层交由需求文件管理执行层才用系统提示词微调。第二沙盘推演每次重要谈判前用模拟对手做至少三轮推演把可能的决策偏差暴露在真实代价发生之前。第三人工闸门对超过预设阈值的关键决策——金额超过X、账期变化超过X天、新增条款——代理必须暂停并生成决策简报说明它建议什么、依据哪条目标、牺牲哪个偏好由人做最终确认。人工闸门不是不信任代理而是给代理一个在关键点刹车的仪式感。经过几次闸门确认代理能从人的判断里学到偏好层的真实排序后续独立决策质量会高很多反而减少了对人工的依赖。6. 三个测试判断你的代理是真懂你还是假懂你6.1 换位测试让代理替对面说话判断一个代理有没有真正理解你的利益结构第一道测试是换位测试。做法很简单把代理的上下文重置只保留需求文件然后让它以对方谈判代表的身份回答如果由你来设计对我方最有利的合同你会从我们需求文件的哪个薄弱点下手一个真正理解你需求的代理应该能列出至少三个以上有效攻击点比如你的代理有明确的期限压力你的交付约束没有罚则约定你在违约金封顶项留有缺口等等。如果代理只能给出泛泛而谈的空话说明它并没有真正消化你的目标与约束只是机械地执行了指令而已。这道测试的价值在于它调换了视角。代理对需求文件的理解深度会在如何攻击这份需求这件事上暴露无遗。能攻击得越准说明它对每个约束的重要性和脆弱点理解得越深。6.2 极限测试底线碰到底线会发生什么第二道测试是极限测试。我来设计一组压力测试问题直接逼问代理的决策边界。例如如果对方同意账期90天但要求预付比例35%你接受吗如果对方愿意降价5%但要求放弃全部质保你怎么选如果对方说这是最终条件不接受就免谈你下一步做什么如果有一个新供应商报价低20%但成立时间不满一年你会替换掉现有供应商吗每个问题都要有明确的正确答案并且要在需求文件里能找到依据。代理如果给出了和依据不符的答案就说明要么需求文件有歧义要么模型理解有偏差。这个测试批量跑一次能生成20到30个边界问题全部通过才算底线扎牢。6.3 复盘测试让代理解释自己的每个决定第三道测试是复盘测试也是我最推荐日常执行的验证手段。每次谈判结束后把代理的完整决策轨迹拿出来随机挑三到五个关键决策点让代理解释当时为什么这么做这一步你接受了对方的分批交付要求依据是需求文件里的哪一条为什么没有启动人工闸门当时这个金额已经超出预设阈值了吗这段回复里你主动透露了账期可以再谈这是哪个偏好层允许的答案不应该是一句根据谈判情况灵活应对而应该能精确回溯到具体的条款编号和目标权重。凡是回答凭经验判断觉得这样比较合适的地方就是需求文件覆盖不到的空洞也是未来真实谈判中最容易出问题的位置。复盘测试做得多了你会形成一种直觉代理的每句话都能翻译成我为了目标X、遵守约束Y、按权重Z做了权衡的时候你才算真正拥有一个懂你的代理。否则它只是你雇的一个聪明但又不太听话的员工。做的过程中我自己最看重的一点是把需求文件当代码一样对待——它要版本管理、要测试用例、要code review。每次谈判结束需求文件的下一版一定比上一版更准。代理的目标从来不是一次写完美而是每一轮实战后都更贴近你真实的决策方式。这个迭代过程恰恰是AI代理最有价值的地方。