上线第一周分流就乱套——"我这东西用着用着不亮了"被分进了"咨询",其实该走"退换货/质量"。整个调优是在一个零代码就能搭智能体的平台里做的，分类节点能直接配类别、写示例、调prompt,还自带个效果测评——但有个实话，测评的用例集得你自己攒，平台不会凭空给你测试数据。剩下那不到10%的硬骨头，是那种一句话夹好几个意图的（"东西坏了我要退而且要投诉你们物流"），单标签分类天生扛不住，这类我直接放行

存了latency之后，我顺手做了个统计，发现有个"查物流"的工具平均要1.8秒，是整条链最慢的一环——它是个老接口，没加缓存。工程上我没自己搭这套埋点。我用的那种拖一拖就能配智能体的工具，本身每个工具节点的出入参就是可以结构化导出的，我做的主要是把它接到我自己的存储里、按trace_id组织起来。我一开始想着省空间，把工具返回截断了存，结果真出问题的时候，恰恰是被我截掉的那段里有报错信息。一个小

一开始我以为就是个客服问答，做完才发现完全两码事——答疑是"一问一答"，售后是"带状态的流程"：要先判断订单状态、是否超七天、商品是否影响二次销售，不同组合走完全不同的话术和动作。几个具体的数：跑了 19 天，接了 600 多次售后咨询，38% 全程没转人工就办完了，剩下的大多卡在"商品有质量问题"这种需要看图定责的，转人工。这一点意外地重要——同样是"超期不能退"，流程吐字段和模型组织过的话术，

工作流里上游字段没映射到下游，模型拿到空值不报错，给你一本正经编一个。Agent 链路有大模型、有检索，比普通接口慢得多。超时按 RESTful 那套设，高峰必报错。把我这一年踩过的坑列出来，你照着躲，能少熬好几个夜。设定里把格式按死，接收端再加容错。，省了不少底层功夫，但上面这些工程化的坑，平台给了能力、不替你负责，还得自己一个个补。用户说"答错了"，你连是哪条、它怎么想的都不知道。RAG 召回

组里有个老需求：大家总在飞书群里问"上次那个发布流程文档在哪""测试环境账号是啥"，每次都得有人捞一遍。我想干脆搭个能回答这些的机器人挂群里，谁问它答。动手前我以为得起个服务、写 webhook、维护一套会话状态。后来发现没必要那么重。我先用一个能零代码配智能体的平台（）把问答这块搭出来，再走它自带的发布渠道直接接到飞书，省掉了自己搭服务那一层。

把 Agent 做出来、发布成 API 接进自己系统，是很多人走的最后一步。。普通 RESTful 接口几十毫秒返回，Agent 的 API 动不动几秒——里头串了大模型推理、可能还有知识检索、工具调用，链路天然就长。如果调用侧没做好准备，高峰期超时、用户体验差，接口形同虚设。这篇分享几个我实测有效的优化方向，给要把 Agent API 上生产的后端同学参考。