上一篇我们说，服务智能体是一种新的资产形式，而一份资产除了要能持有，还要能增长。服务智能体当然要成长，但它不能像个人智能体那样，靠记忆在使用中自我成长。它的成长方式是监督式的版本迭代：上下文分层，每一层都有负责人；服务中产生的信号经过审核，作为新版本发布。

这不是保守，而是服务的前提。一个靠记忆自我成长的服务智能体，说不清自己为什么这样回答，改错了也撤不回来。放任它自我成长，就等于放弃了审计和监管，这样的系统对它的每一位客户都是不可靠的。

## 服务智能体不能靠记忆自我成长

个人智能体可以这样成长。我们在第一篇里说过，它追求变化，每一次经历都直接沉淀下来；它的后果主要由用户自己承担，所以它可以随着这个人一起变。

服务智能体如果也这样，会出现四个问题。

**说不清它为什么这样回答。**它的行为取决于一路积累下来的记忆，没有一个固定的版本可以指着说「当时依据的是这个」。客户投诉、监管问询的时候，审计无从下手。

**改错了撤不回来。**一条错误的经验混进记忆，你不知道它在哪里，也没法只撤回这一条。

**一个客户的经历会改变它对所有客户的做法。**某一位客户教给它的东西，会影响它下一次回答别人。这破坏了服务应有的一视同仁，还可能把一位客户的信息带进另一位客户的对话。

**它会被教坏。**任何和它对话的人都能影响它。曾经有一个公开上线的聊天机器人，从用户的对话里学习，不到一天就被教出了不当言论，只能下线。

研究智能体结构的学者也得出了同样的结论。Sumers 等人 2024 年发表在《Transactions on Machine Learning Research》上的 CoALA 框架，把语言智能体的记忆分为工作记忆、情景记忆、语义记忆和程序记忆。论文指出，智能体自己改写程序记忆，也就是改写它做事的方式，比写入其他记忆的风险大得多，容易引入缺陷，甚至让智能体背离设计者的意图。论文举的零售助手例子里，助手可以记下与每位客户的往来，但商品库和它自己的代码只能读，不能改。

## 它的成长方式是监督式的版本迭代

不能自我成长，不等于不成长。区别在于成长发生在哪里。

个人智能体在使用中成长，变化发生在每一次对话里。服务智能体在版本之间成长：服务的时候，它运行的是一个固定的版本；改进发生在智能体外面，由负责的人提出、审核，以新版本的形式生效。在 CoALA 的描述里，「学习」是智能体自己的一个动作，由它决定把什么写进记忆。服务智能体把这个动作移到了智能体外面，交给有人负责的发布流程。

由此可以得到一条清楚的界线：**服务智能体在服务时，不改写任何所有客户共用的东西。**它可以记下这一位客户的事，但不能因为这一位客户，改变它对所有人的做法。

## 上下文分成五层，每一层都有负责人

CoALA 说明了智能体有哪几种记忆，但没有回答这些记忆归谁、谁能改。对个人智能体来说，答案很简单，都归它代表的那个人。服务智能体要逐层回答。这里的上下文取广义，指智能体在服务时读到的全部信息，第三篇里说的上下文、配置和客户记录都在其中。按这个问题，我们把它分成五层，前三层由所有客户共用，后两层属于某一位客户。

**规则层**，对应程序记忆：身份、口吻、底线，服务流程，能调用哪些工具、有哪些权限，什么情况交给人，用哪个模型。它由服务提供方的运营团队负责，其中底线一类的规则要由更高层级批准。规则层随着智能体的版本发布，服务时只读。

**业务层**，对应语义记忆：产品、价格、政策、专业知识，以及关于这家服务提供方自身的事实。它来自服务提供方的业务系统，由业务团队负责，随业务系统更新。服务智能体只读取它，从不改写它。

**案例层**，对应情景记忆里共用的部分：经过审核的典型案例和处理示范。它从许多次服务里挑选出来，审核通过后随新版本加入，服务时只读。

**客户记录**，对应情景记忆里属于个人的部分：这位客户的历史和往来。它存在服务提供方自己的业务系统里，按客户隔离，只追加、不改写。第一篇说过，这是规则的输入，不会改变规则本身。客户记录不保存在智能体里，所以服务智能体本身仍然是无状态的：每一次服务都从同一个版本开始，再读入这位客户的记录。

**会话**，对应工作记忆：这一次正在处理的事。它在会话中可读可写，会话结束即丢弃。

| 层 | 对应的记忆 | 谁负责 | 服务时 | 怎样改变 |
|---|---|---|---|---|
| 规则层 | 程序记忆 | 运营团队，底线由更高层批准 | 只读 | 随智能体版本发布 |
| 业务层 | 语义记忆 | 业务团队与业务系统 | 只读 | 随业务系统更新 |
| 案例层 | 情景记忆（共用） | 运营团队审核 | 只读 | 审核后随版本加入 |
| 客户记录 | 情景记忆（个人） | 服务提供方的业务系统 | 只追加 | 每次服务后写入，按客户隔离 |
| 会话 | 工作记忆 | 无 | 可读可写 | 会话结束即丢弃 |

这张表里只有最后两层在服务时会被写入，而它们都只属于一位客户。共用的三层，没有一层由智能体在服务中改写。

## 服务中的信号经过审核，变成新版本

服务智能体不改写共用的结构，但每一次服务都会产生改进它的信号：客户的评价，转给人工的对话，人工客服改写过的回复，投诉，以及最后的业务结果。

分层让这些信号有了去处。答错了价格，问题在业务层，交给业务团队；该转人工的时候没有转，问题在规则层，交给运营团队；一次处理得特别好的复杂情况，可以整理成案例，进入案例层。每一层都有负责人，所以每一个信号都有人接。

接下来的步骤是固定的：负责人修改对应的那一层，新版本先通过评测，再发布上线，必要时先让一小部分流量试用。第一篇说服务智能体学到的东西「经过提炼和审核，作为结构的新版本发布出去」，指的就是这个过程。

这个闭环和质量管理里的 PDCA 循环是同一种思路：计划、执行、检查、处理，每转一圈，结构就改进一次，而每一圈都有人负责。

## 评测集既是关卡，也随服务生长

评测集是一组可以反复检验的问题和预期答案。在这个闭环里，它有两个作用。

它是发布前的关卡。任何一个新版本都要先通过评测集，确认没有把原来做对的事情做错，才能上线。

它也是闭环的产物。第三篇说过，评测集里的每一道题，都对应着过去某一次真实的失误。服务中每发现一次新的失误，修好之后，就把它写成一道新题。题目越积越多，同样的错误就越难再出现。评测集记下了这个服务智能体吃过的每一次亏，它本身就是这份资产的一部分。

## 每一版都能追溯，成长和可控同时成立

监督式迭代没有放弃成长，它让成长变得可控。开头提到的四个问题，在这里都有了答案。

每一次服务都记录了它用的是哪个版本，所以「当时为什么这样回答」有据可查，审计可以落到具体的版本和具体的那一层。改错了只影响一个版本，回到上一个版本即可。一位客户的经历只写进他自己的记录，不会改变别人得到的服务。任何人想教坏它，都要先通过审核和评测。

连锁经营早就是这样运作的。门店每天都会碰到手册上没写的情况，店员会把这些情况反馈给总部；总部修订手册，再统一发给所有门店。没有哪个店员会因为某位顾客的要求，自己改掉价格政策。改价格是总部的事，而且要通知到每一家店。

这样的成长，单看一次可能比自我成长慢，但它可以一直积累下去：每一版都建立在上一版已经验证过的基础上，不会因为一次失误把前面的积累一起赔掉。

## 下一篇

一个按版本迭代的服务智能体，还要能在真实的客户面前稳定运行：谁授权它做事，出了问题谁负责，怎么发现异常，出故障时怎样接管。下一篇《撑得起真实客户》讨论这些问题。