AI代理谈判不败：三层需求建模与本地部署实战

上个星期，我一个做外贸的朋友跟我吐槽：他花了整整两周调教一个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价格高但交付快，选哪个？偏好层就是用来处理这种"没有绝对对错、只有倾向"的问题。

我推荐的做法是给每一条软性需求设权重，并让代理按"加权得分"来比较候选方案。假设我们有三条价值观：

代理在某个节点需要做取舍时，就把候选选项分别打分，算加权总分，再决定走哪条路。偏好层的价值在于：它让代理的"灵活性"有了形状——灵活不是什么都行，而是在权重框架内的有序偏移。

提示：偏好层最容易踩的坑是权重自相矛盾。比如既要求绝对低价（权重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. 安装Ollama（Linux/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代理最有价值的地方。