embedding就是把文字压成一串数字（向量），语义相近的文字，向量距离就近。如果这个模型对你的领域语义理解得糙，"社保缴费基数"和"医保报销比例"在它眼里挨得很近，那召回就会把不相关的块捞上来。后面大模型再强，喂的料是错的，答案必然废。我是在一个零代码就能配智能体、知识库里能切换embedding的平台上做的对比，换嵌入模型是下拉选一下、重建索引就行，不用改代码。维度是工程权衡，不是越大越牛。

我每天上班第一件事是刷行业新闻,大概要花二十分钟扫一圈各个源头。烦了之后我搭了个小助手,让它每天早上八点自己跑一遍,把当天值得看的几条整理成一段话,推到我企业微信。现在我喝口咖啡就看完了。说说怎么搭的。

我现在用一个零代码平台搭这种会调工具的智能体，工具是在界面上配的，连参数、连描述，拖一下就挂上去了，模型什么时候调、调完结果怎么接回来，平台都接好了。我吃过亏：一个工具我描述写得太笼统，"处理订单相关"，结果用户问退款、查物流，模型全往这一个工具上怼。用户说"查我上周那个订单"，"上周"模型得自己换算成日期，偶尔会算岔。A：模型本身调不了，它没那本事。准确说是——你提前把可用的工具（比如"查订单接

直说结论:如果你的 Agent 线上有大量重复或相似的问题,。我有个客服 Agent,上线第一个月账单出来我差点没绷住,一看日志,30% 的问题都是"营业时间""怎么退款""客服电话"这种翻来覆去的。次次喂模型,纯纯浪费。后来加了两层缓存,token 消耗砍了快一半。这篇讲讲怎么加、坑在哪。

做过 Agent 的人迟早会遇到这个尴尬：调 Prompt 时按下葫芦浮起瓢——为了修好 A 类问题改了指令，结果 B 类问题悄悄退化了，上线才被用户发现。这本质是个的问题。传统软件改完跑测试套件就知道有没有破坏存量功能，Agent 也该有这么一道门。这篇讲讲我怎么用平台的"效果测评"功能给 Agent 搭回归测试，给同样要对 Agent 质量负责的测试/后端同学参考。

"，客户都是合作好几年的老国企，这腔调发出去像诈骗。这里我踩了第一个坑：客户邮件经常带长长的历史引用，全文塞给模型，分类老被引用内容带偏。后来加了个预处理，只取最新一段正文（按"发件人写于"和分隔线切），准确率肉眼可见地上去了。我们做 B 端业务，公共邮箱每天进五六十封客户邮件：催进度的、要发票的、报问题的、谈合作的，混在一起。错的那 6% 集中在"一封邮件说两件事"的，比如又催进度又要发票。客户

星辰能让我把精力全压在"调好导购话术和推荐逻辑"上，工程的事平台扛，这对外包是刚需。我把客户的商品库整理成知识库，配上"只能推荐知识库里存在的商品，并说明匹配理由"，把瞎编这条路堵死。客户是个做家居的小电商，想要个"导购 Agent"：用户描述需求（预算、风格、尺寸），它推荐合适的商品并说明理由。预算不高、工期一周、多模型对比 + 知识库 + 测评这套组合，正好打在"话术质量"和"不瞎推荐"这两个

做了个帮用户算费用的智能体，上线没多久就出洋相——一道稍微复杂点的乘除，它给的结果错了。大模型这东西，语言强，算数是真不行，几位数相乘都能给你算飘。涉及钱、涉及精确数字的场景，千万别让模型"心算"。正确做法是把算的活交给工具。

做过 Agent 的人迟早会遇到这个尴尬：调 Prompt 时按下葫芦浮起瓢——为了修好 A 类问题改了指令，结果 B 类问题悄悄退化了，上线才被用户发现。这本质是个的问题。传统软件改完跑测试套件就知道有没有破坏存量功能，Agent 也该有这么一道门。这篇讲讲我怎么用平台的"效果测评"功能给 Agent 搭回归测试，给同样要对 Agent 质量负责的测试/后端同学参考。