这节课标题叫"Agent系统服务化封装与IM接入"。
看到"服务化"，我以为就是把脚本包一层，再挂个聊天窗口。
上完才发现差得远。加个入口是小事，难的是想清楚"谁负责什么"。
脚本和服务的区别，不在代码，在"谁负责"
原来的程序，得手动跑一次，才完成一次任务。
做成服务之后，程序启动完就一直挂着，别人从约定好的入口发个请求，就能接着用已有的能力。启动、配置、出错提示、运行记录，这些都得安排上。
一次请求走五步：接收消息、建立任务、处理任务、保存结果、回复用户。
每一步都得有东西负责。课件给了张分工表。
平台适配器管连接平台、核验消息来源、提取消息、发送回复。Gateway公共处理管把消息交给服务、关联任务和回复位置、安排结果发送。Agent服务管接受业务任务、检查权限和输入、运行分析、保存结果。
这节课让我最清醒的一句话是：
模型只接收分析所需的业务材料。
谁发来的、结果存哪、回复到哪个会话，全是程序的事，跟模型没关系。
别让模型去管身份
接口约定那张表里，有一行我看了好几遍。
"已验证身份——由服务根据接入凭证和平台身份建立，不能直接相信消息正文里自报的身份。"
说白了，用户在消息里写"我是管理员"，你不能信。身份得从平台的接入凭证推出来，不能从聊天内容里读。
还有几个信息也得程序记。会话和回复分支，决定结果回到哪个单聊、群聊，或者被回复的那条消息。平台消息标识，用来认平台重复送来的同一条消息。任务编号，把业务任务和原来的回复位置对上。
为什么这么较真？因为用户发一次消息，程序得保证三件事：这条任务属于他、只能被他查、结果回到他发起的地方。这些交给模型，模型既不知道也不该知道。
模型的输入应该干净到只剩两样：评论列表、分析要求。
这也是"换平台不用改业务"的前提。这两样不变，助手就能接着用。
Webhook不一定是你收消息的方式
课件提醒了一句：Webhook这词会出现在不同方向的接口里，读文档先确认谁向谁发请求。
我一开始没当回事，后来发现真的容易绕。
三种接入方式，方向完全不一样。
群推送Webhook，应用主动调平台给的地址，往群里发消息，方向是你到平台。HTTP事件回调，平台往你的回调URL发事件，方向是平台到你。长连接、Stream、Socket Mode，应用主动连上平台，平台顺着这条连接下发事件，你先连，它再发。
前两个都叫webhook，方向正好相反。
长连接的好处很实在：不用准备公网回调地址，本地就能跑。代价也很实在：电脑一休眠、进程一退，服务就断了。想无人值守，得挪到一直开机的环境。
换一个平台，只应该改一个地方
要是每个IM都复制一份分析代码，改一次分析规则就得改好几份。
可插拔的做法是：平台差异全留在适配器里，业务服务只面对统一的请求。
怎么知道做到了？课件给了个办法。接完真实IM，再加一个终端入口。终端不用申请账号，正好用来验"第二个入口是不是真的复用了同一个服务"。
加个终端入口还要动分析逻辑，那就说明平台差异漏到业务层了。
插件也是这个道理，分两类。渠道插件管"从哪用"，飞书、终端、第二个IM都算。业务插件管"能做什么"，评论分析、反馈摘要都算。加平台加渠道插件，加业务加业务插件，两边不打架。
出问题的时候，四条记录就够了
第一版不用什么专业监控，终端加个日志文件就够查。
每次任务留四条记录。收到消息，建了任务T001。开始分析，模型在处理。分析完成，结果存了。回复已发出，去聊天窗口对一下。
打开同一次任务的记录，按时间往下读，卡在哪一步很清楚。
没有"收到消息"，去查连接、机器人配置、使用范围。停在"开始分析"，去查模型调用。"分析完成"但后面跟着"回复失败"，先保住已有结果，再查发送权限和回复位置，修好重发，别重新调一遍模型。
跟上一课的数据流排查是一个路子：别急着改代码，先找信息在哪一步断的。
能收到回复，不等于做对了
功能联调的检查项有九个：正常请求、重复事件、输入不足、身份隔离、业务失败、交付失败、重启、插件替换、少量并发。
有两个我印象最深。
一个是重复事件。平台有时候会把同一条消息送两遍，程序得用平台给的消息标识认出来，不能分析两遍。注意，用户自己又发一次相同的字，那是新请求，不该去重。
另一个是身份隔离。换个用户或组织去查某个任务，得按授权拒绝，不能把别人的内容返回来。
课件原话是：能收到回复，只说明这次传输通了。分析有没有依据评论、引用准不准，还得单独查。
对我意味着什么
我现在的状态是找工作，目标是AI应用开发岗。
学这节课之前，我以为AI应用开发就是调模型、写提示词。
学完发现，真正的工作量在模型之外。把已有能力封成服务，设计输入输出和失败怎么表达，处理身份和权限，让多个平台复用同一套业务逻辑，出了问题能定位到哪一步。
模型负责回答问题。让它能被别人用起来、用不出乱子，是另一回事。
你现在做的AI应用，是一个自己跑的脚本，还是一个别人能用的服务？
