去年，包邮区一家零售企业做客服 Agent评审。演示过程很顺利，但是客户问：“转化率怎么算？” 。现场一下沉默了。

所以，技术团队关注的是 Agent 能实现什么功能，而客户关心的是能创造什么价值。需要的是既懂技术又懂业务的人。

这种项目我见过不少。验收的时候效果最好，之后越用越差，半年左右就没人提了。复盘大家都说是模型不行或者需求变了，但我觉得根子在团队 —— 上线之后该谁盯效果、谁迭代，职责不明确的。

算法堆得再多，也补不上另外两个坑

基座模型能力平台化之后，“能不能做出来” 这件事的门槛其实下降得很快。真正挡住企业的是两个更基础的问题：Agent 到底该干哪些活，以及它干完了怎么判定算数。

这两个问题分别对应两种人 —— 把业务指标翻译成可执行目标的人，和上线后对效果负责的人。它们跟算法工程师的能力模型基本不重叠，也很少写进算法岗的 KPI。

我现在看一个 Agent 团队，只看三个位置有没有明确的人认领：

• 业务翻译—— 拆解业务 KPI 为 Agent目标和边界，定义人机分工的触发条件。缺位的典型症状：需求反复推翻，验收口径谈不拢，做出来的东西业务方说不清价值。
• 工程落地——系统集成、数据接入、权限、并发、灰度与回滚。缺位的典型症状：演示环境一切正常，接真实业务后逐层卡壳，集成阶段无限期延后。
• 运营评测—— 上线后指标监控、异常处置、语料与规则迭代。缺位的典型症状：就是标题说的，上线即巅峰，指标衰减没人察觉，最终静默下线。

这三个职能不一定对应三个编制。团队小的时候，业务翻译和运营评测由同一个人兼很常见。但兼可以，空缺不行 —— 没人认领的职能，等于不存在。

上线即巅峰是怎么发生的

为什么衰减几乎是必然的？因为 Agent 面对的输入分布本身就在动。

业务侧改了话术，用户提问的表达方式跟着变；促销季来了，咨询类型的占比整体偏移；对接的后台系统上了个版本，某个字段含义变了。这些变化单独看都很小，累积起来就是效果持续下滑。

传统软件为什么能 “验收即结束”？因为逻辑是写死的，输入变了它至多报错，不会悄悄给出错误答案。Agent 不一样 —— 它会一直给出看起来合理的输出，直到有人去测才发现不对。

所以我说，Agent 更像招了个新员工，而不是上了套系统。 招人你会安排带教、试用期考核、定期沟通；上系统你验收完就不管了。用管系统的方式管 Agent，衰减是迟早的事。

技术管理者可以先落的三件事

这三件事不需要额外预算，只需要立项时把话说清楚。

第一，验收口径前置到立项阶段。不是上线前才讨论"算不算做好了"。立项时就要写死：哪几个指标、基线是多少、达到什么值算通过、掉到什么值要报警。写不出来，说明业务翻译这个职能还没到位，这时候急着招算法是浪费钱。

第二，把运营期写进职责或合同。内部团队的话，运营评测要进岗位职责和绩效；外部团队的话，稳定运营期和指标承诺要写进合同，而不是上线后再谈。区别在于：写进去了，它是义务；没写，它是人情。

第三，知识沉淀到文档而不是个人。提示词模板、规则演进记录、边界案例台账、模型配置，这些东西如果只存在某个工程师脑子里，那项目的可持续性完全绑在他的稳定性上。我见过核心工程师春节后离职，后面接手的人对着一堆 prompt 完全不知道为什么这么写，最后推倒重来，半年白干。

组队顺序建议倒过来

常规做法是先招算法出原型，后补运营。我更建议反过来 —— 先定业务翻译，通常从内部找，业务骨干、愿意研究新工具、在组织里说得上话的那种。让他先把场景边界和验收口径定下来，后面需要什么样的技术人、要几个，答案会自己浮出来。

反着来的代价我见过太多：算法先到岗，业务侧还在纠结做什么，人闲两个月，能力最强的那个先走了。磨刀不误砍柴工，这句老话在这儿特别实在。

回到开头那家零售企业。他们后来没有继续加算法编制，而是从运营部门抽了一位熟悉客服流程的主管，专职做需求翻译和上线后盯盘。半年后系统接进了三条真实业务线。技术方案几乎没变，变的是有人对结果负责。

选团队这件事，能力结构比技术路线更值得花时间。技术路线错了可以调，团队职责空缺，你要到半年后才知道。