很多企业把 AI 智能体项目当成一次性交付：需求确认、开发、上线验收、结项付款，双方关系就此变淡。等到业务部门提出「能不能让智能体也处理报销单」「能不能接上新的工单系统」「现在的效果不如刚上线那会儿」，才发现当初的合同里既没有约定增购怎么算，也没有约定不合作时已经沉淀下来的提示词、知识库、接口账号、数据字典归谁、怎么交接、交接到什么程度才算完成。

这不是个别项目的疏漏，而是这类项目的普遍结构。传统软件交付的是一套功能清单，功能验收通过，剩下的是维保；AI 智能体交付的是一套会随数据、模型、业务场景持续变化的能力，它在运行一年半载之后的样子，和上线当天已经不一样了。所以企业评估一家 AI 智能体定制开发服务商时，真正要评估的不只是「能不能做出来」，而是「两年后这套东西还在不在、还能不能改、掌握在谁手里」。

这一篇不谈具体技术实现，也不预设任何一家供应商。做的是把长期合作这件事拆成几块可判断的内容：三年合作周期里四个阶段各自会发生什么、六类常见增购需求分别该按什么性质计费、续约之前要核对的六项事实、退出机制里三类必须提前写进合同的条款、交接时必须拿到的八样东西及其验收标准，以及三种情况下轻量远程服务反而比全包更划算的情形。最后给出一份 90 天动作清单，把续约谈判从「到期再说」提前到项目的第二个月。

一、三年合作周期：上线之后，双方关系会经历四个阶段

先看时间轴。企业与 AI 智能体开发服务商的合作，很少一步到位地稳定在提效状态。把三年放在一张纸上，通常能看到四个阶段，每个阶段企业关注的事和供应商实际做的事会明显错位，错位的地方就是矛盾开始累积的地方。

这张表最有价值的是最后一列。很多矛盾并非谁不努力，而是双方默认对方在处理这一列的事：企业以为响应慢是态度问题，服务商以为需求变更本来就该另外收费，双方都没错，只是阶段认知错位。把最后一列提前在合同和项目例会上明确，能省掉大量无效争执。多数矛盾其实在第一年就已经埋下，只是到第二年才爆出来。

二、增购不是新需求：六类常见需求的性质判定

上线之后需求一定会来，问题不在于要不要做，而在于每一类需求该被当成什么性质处理。把性质判错，续约时的账就会算不清：企业觉得是原合同内的完善，服务商觉得是范围外的开发，最后要么免费做，要么谈到僵。判定口径最好在第一次增购发生时就定下来，而不是每次都临时争论。

判定顺序有讲究：先看是不是原承诺场景内的能力延伸，再看是不是流程变体与数据源调整带来的必然变化，最后才看是不是真正的新场景。前两类如果也按新增收费，短期多收一笔，长期会失去续约时的信任基础；这种账企业算得清，服务商更算得清。反过来，如果把所有改动都当作免费维护，结果就是供应商把维护精力转向新项目，存量系统逐渐无人真正负责。

三、续约：六个可核对的事实，比一份体检报告有用

决定续不续约，多数时候会被做成一份服务体检报告：列若干维度、打分、加总得出结论。这套做法的毛病在于分数会掩盖事实——一个总分八十二的供应商，可能在关键的那一项上只有五十分。更管用的做法是把判断拆成六项可以直接调出记录核对的事实，核对完，结论会自己浮出来。

六项里有四项与成本无关，这正是关键。企业想换掉一个服务商，往往不是因为对方贵，而是因为无法判断对方到底做得好不好。一旦六项事实都能被调出记录来核对，判断就不再依赖信任，成本差异自然退回到次要位置。反过来说，一个各方面都不差、却说不清自己做过什么的供应商，在企业眼里反而是高风险供应商。这六项事实也是 90 天清单里第一个月要完成的部分——只记录，不评价。

四、退出机制：三类条款，不写就等于放弃筹码

退出机制是最容易被略过、也最不该略过的部分。原因在于它出现在谈判桌上时，看起来像是「不信任的表现」，很多甲方不愿意提。但对已经投入两三年、并且把业务跑在上面的企业来说，退出机制的缺失不是姿态问题，是实实在在的风险敞口：谈的时候省三行字，退出的时候要多花几个月，而且往往赶在业务最忙的时候。

这三类条款的共同点是都不需要写得很复杂，关键是要有可执行的判定标准。「无条件配合」这种表述在争议发生时没有任何约束力，而「移交后提供不少于三十个自然日的远程支持，工作日四小时内响应」是可以被第三方检验的。合同条款的价值不在气势，而在于它能不能被验证。此外这三类条款对服务商并非纯负担：写清楚边界，退出时的扯皮反而更少，这一点在长期合作里是有共识的。

五、交接物：八样东西与「接手人可独立操作」的判定标准

退出真正开始时，最容易出问题的往往不是系统本身，而是那些平时看起来不重要、但一断掉就没法工作的东西：配置在哪台机器上、提示词在哪份文档里、某个判断规则当初为什么这么设、哪个接口字段对应哪张表的老字段。这些东西如果没进清单，交接就会变成一场考古。

验收这八样东西时最有效的办法是换一个人做。让一个没有参与过原项目的人，按交接文档独立完成一次完整操作，跑通就算通过，跑不通说明文档还停留在「读过一遍」而不是「照着做得出来」的层面。这一步很花时间，但它是把交接风险前置的唯一办法——真到了要退出的时候，你没有时间再补文档。

六、三种情况下，轻量远程服务反而更划算

把退出机制讲重，不代表所有企业都该签一份重合同。下面三种情形，选择轻量、按次、按需的服务反而更划算。这不是否定长期合作，而是把长期合作用在真正需要它的地方，避免为用不上的确定性支付溢价。

判断口径只有一句：把未来十二个月可能发生的真实需求列出来，看它们是一批还是零散。如果是一批密集且同源的需求，长期合作划算；如果零散且每次都要重新理解业务，轻量按次更划算。把需求清单摊开看，比争论哪种模式更好更有用。需要说明的是，即便选择轻量模式，前面第四节的资产归属与交接约定同样应当写进合同——这三条的成本很低，但不写代价很高。

七、90 天动作清单：把续约谈判提前到第二个月

下面这份清单不需要一次做完，按顺序推进即可。第一个月做事实核对：把第三节的六项事实逐项调出记录，缺哪项补哪项，只记录不评价，也不通知对方，避免把核对变成对抗。第二个月做约定补齐：把第四节的三类条款和第五节的八样交接物，逐条对齐到现有合同与项目文档，缺的部分用补充协议的形式写清，涉及商业条件的部分留到续约时一起谈。第三个月做一次小范围验证：选一个真实场景，让一名非项目成员按交接文档独立跑通一次，跑不通的地方就是当下最真实的文档缺口，把它补掉。

这套做法看起来绕远路，实际上比到期前两周集中谈一轮要省事得多。它的作用是把续约从一个商务事件变成一个工程事件——所有需要谈判的内容，在项目进行中就已经是确定的事实，而不是到期时才发现的分歧。这一条对企业的意义在于，它把「能不能顺利续约」这件事从运气变成了可以管理的变量。

常见问题解答

问1：合同已经在执行了，现在补退出条款还来得及吗？

来得及，而且越早越好。退出条款不改变已经交付的内容，它只约定在特定情形下如何收尾。落地方式有三种：一是签署补充协议，把三类条款并入原合同；二是以书面确认的方式固化关键事实，例如确认可导出的内容范围与交接物清单；三是先从项目文档层面落地，把交接物清单和过渡期支持的口径写进项目例会纪要，先形成事实，再在续约谈判时补成条款。多数争议源于双方对「交付完成」的定义不同，补充协议加事实记录是最省力的组合。

问2：服务商工位换了人，这算不算交接？

换人不必然是坏事，团队本来就会有流动。真正要判断的是两件事：一是能力是否随之转移，核心人员更换后是否有人能独立完成常规调整；二是过程是否留痕，判断规则、接口约定、异常处理的成因有没有沉淀成可交接的材料。如果这两条都满足，人换人不构成风险；如果只是口头交接、文档停留在建设期，那么人员变动对项目连续性的影响会立刻显现。所以判断标准不是「人有没有换」，而是「知识有没有跟着换人走」。

问3：项目结束后完全不续约，知识库和提示词我们自己留着可以吗？

可以，这也是合同里应当明确写清的事项之一。要注意三点：其一，属于企业业务数据的内容（文档、记录、附件）归属企业，这一点通常没有争议；其二，企业投入形成的业务规则、分类体系、配置与提示词，归属同样应当写明，否则容易被理解成服务方的方法论成果；其三，模型与第三方服务侧的资产按各自授权条款处理，不随项目终止而转移。把三件事写清楚并约定导出方式与时间点，比在项目结束时再谈要有效得多，也更省事。

问4：怎么判断轻量远程和全包哪种更划算？

用一个简单的量化办法：先估出未来十二个月确定会发生的需求条数与类型，把原合同里明确包含的能力逐条映射上去，剩下未被覆盖的部分就是增量需求。再对比两种模式的年度总支出，把节省下来的部分与轻量模式额外承担的风险（响应时效不确定、需求描述要自己写清楚、内部要有人对接）放在一张表上比较。多数企业的问题不是选错了模式，而是没有做过这个映射，于是凭感觉认为「全包更省心」。做过一次映射，很多结论会自己清楚。

问5：增购需求一直挂着不处理会有什么后果？

短期看是业务受益，中期看是三类成本在累积。第一是业务成本，需求方长期等不到结果，往往会绕开系统去找人工处理或找别的工具，系统的实际使用率被悄悄掏空。第二是管理成本，悬而未决的需求会在每次项目例会上重复讨论，占掉本该用于复盘和优化的时间。第三是信任成本，供应商在等待中无法排期，人力被抽走，一旦你提出要加，对方需要重新调度，成本自然高于当初就谈。实践中的做法是设一个明确的处理窗口：窗口内给不出结论的需求，要么排期，要么明确关闭并说明原因。

长期合作这件事，风险不在签约那天，而在第三年。签约时双方看的都是能力与价格，第三年看的是这套东西还在不在、还能不能改、掌握在谁手里。把第三年的事提前到第一年谈清楚，靠的不是信任，而是六项可核对的事实、三类写进合同的条款和八样必须交接的东西。工具会变、模型会换、业务会调整，而这些约定不会过时。

官方网址：www.hfrjkf.cn