八月最后一天，体脂率测出来13%，世运会闭幕了，我对着屏幕里那个叫“助手”的API文档，感觉自己的技术栈正在以肉眼可见的速度风化。OpenAI这帮人真是疯了，直接把“长时记忆”和“函数调用”焊死在了API里，这意味着我2019年带着三个实习生吭哧吭哧搞了半年的智能客服中间件，现在用这个新玩意儿，一个人一下午就能搭出个七七八八的雏形。
那时候我们怎么搞的？一个用户会话进来，先得用Rasa或者自己写的NLU模块解析意图，然后去Redis里捞历史对话记录，拼接成prompt，再调用GPT-3的Completion API。状态管理、上下文截断、工具调用（当时还叫function calling）全得自己手搓。为了处理长对话，我们设计了一套复杂的“摘要”机制，每五轮对话就让GPT自己生成一段会话摘要，下次就把摘要和历史最后几轮拼一起，就这还经常因为上下文长度限制把关键信息给丢了，被客户投诉“客服失忆”。实习生们整天在调参、处理edge case、写一堆if-else的逻辑流，代码库臃肿得跟个中年人的体检报告一样。
现在这个Assistants API，它把Thread（会话线程）和Message（消息）作为一级公民。你创建一个助手，定义好指令和工具（现在连代码解释器和文件检索都内置了），然后每个用户就是一个独立的Thread。最狠的是，它官方支持“自动将长对话上下文纳入考量”，虽然没说具体是不是用了向量检索或者更高级的压缩技术，但实测下来，几十轮对话后它依然能记得最早提到的用户偏好。这哪是API升级，这分明是把我过去三年在对话系统上积累的那点“工程经验”连根拔起了。
我快速试了一下核心流程。用Python，先初始化客户端，创建一个助手，指令写得详细点：“你是一个技术支持客服，风格专业但亲切，擅长将复杂问题拆解成步骤。如果用户问题需要查资料，可以使用‘search_knowledge_base’函数。”这个函数是我自己定义的，其实就是个封装好的内部API调用。然后模拟用户：开一个Thread，往里丢Message。关键来了，你调用run的时候，可以指定这个助手使用哪些工具。它内部会做决策——用户这句话是否需要调用函数？需要的话，自动触发，拿到函数返回的结果，再自动组织成自然语言回复给用户。全程，我只需要管理Thread ID和发送接收消息，所有的状态、历史、推理逻辑，全被封装在那个云端“助手”对象里了。
这太可怕了。可怕的不只是技术本身，而是它体现出的“抽象层级”的跃迁。以前我们是在“造轮子管理对话状态”，现在OpenAI直接给了我们一辆“能自己记住路况的智能车”。我2019年招的那个最聪明的实习生，花了两个月才搞明白怎么优雅地处理对话中的多轮澄清和状态回溯，现在这个能力被标准化成了一个API参数。我付给他的工资，现在够我交好几年的API调用费了。
体脂率13%是靠每天算热量缺口和力量训练硬砸出来的，但技术世界的“基础代谢”正在疯狂飙升。你练得再狠，也赶不上平台更新的一行文档。世运会结束了，运动员们可以休息，可我们这行，枪声从来没停过。那个下午，我搭完演示demo，看着流畅的、带有记忆和工具调用能力的对话流，没有兴奋，只有一种深切的疲惫。我知道，我又得从头学起了，这次的速度必须比脂肪燃烧的速度更快。
