先把结论甩出来:Agent 调大模型/工具,,三件套缺一不可。我上个月就是没加,被自己写的循环把账号打到限流封了 20 分钟,顺带烧了我自己一笔不算少的 token。下面是我踩完坑后现在固定用的那套写法。

很多人评测自己的智能体,就一个标准:答得对吗?对就行,错就改。我以前也这样,后来吃了亏——有个助手"答得对",但慢得要死、还经常答跑题一大段,用户照样骂。光看对错太粗了。我后来给评测立了一套指标,分享一下。

我给一个智能体接了定时任务，每天早上 8 点自动跑一遍：抓取昨天的行业新闻、让模型总结成五条、推到我飞书。一个月下来省了我每天半小时的剪报时间。这篇讲清楚怎么让 Agent 从"你问它才动"变成"到点自己动"。

没有一个模型通吃。对话 ≤ 8 轮 → 用 C(快、便宜,这档质量够)对话 > 8 轮 → 用 B(均衡,长对话也稳)重大投诉工单 → 用 A(质量优先,这类不差钱)整体算下来,综合成本只有全程用 A 的三分之一不到,质量均分还稳在 4.2 以上。混用比一刀切香。

一个客服机器人最值钱的能力，可能不是答得多全，而是知道什么时候闭嘴说"这个我不清楚"。我做客服 Agent 的设计时，花在"怎么让它该拒答时拒答"上的功夫，比花在"怎么让它答得好"上的还多。讲讲这个思路。

我搭了个会查公司制度的小助手，问它"年假能不能跨年清零"，它答得头头是道，引经据典，结果——公司压根没这条规定，它现编的。当时我一身冷汗，这要是给 HR 用了得闹笑话。这事让我去把 RAG 这套东西的原理重新捋了一遍。今天不讲怎么搭，讲讲，搞懂了你才知道该往哪儿使劲。

模型不接触底层HTTP，它只看到"有个查订单的工具，要传订单号",负责决定什么时候调、传什么值。把内部接口按工具规范注册进去，画布上的智能体就能直接调，不用我给每个接口写胶水代码去对接模型。查询类的工具随它调，但"发工单""改状态"这种有副作用的，我让它调用前先回显一句让人确认。后端视角的一个实际问题：想让智能体能调我们公司内部的接口（查订单、查库存、发工单这些），有两种封装思路，到底选哪个？先说

没有一个模型通吃。对话 ≤ 8 轮 → 用 C(快、便宜,这档质量够)对话 > 8 轮 → 用 B(均衡,长对话也稳)重大投诉工单 → 用 A(质量优先,这类不差钱)整体算下来,综合成本只有全程用 A 的三分之一不到,质量均分还稳在 4.2 以上。混用比一刀切香。

我们的内部答疑机器人刚上线时我自信满满，觉得文档备得挺全，结果第一周的对话日志一拉，"未命中知识库"的问题占了快四成。理论上可以再搭个智能体帮我预归类（把未命中问题聚类打标），我试过一版，聚类结果凑合能用，但合并粒度老觉得差点意思，目前还是机器初筛 + 人工定夺。每次大概花一个半小时，烦是真烦，像批作业。但坚持了两个月，未命中率从 38% 降到 12%，而且降得很扎实——补的每一篇文档都对应真实问

我们的内部答疑机器人刚上线时我自信满满，觉得文档备得挺全，结果第一周的对话日志一拉，"未命中知识库"的问题占了快四成。理论上可以再搭个智能体帮我预归类（把未命中问题聚类打标），我试过一版，聚类结果凑合能用，但合并粒度老觉得差点意思，目前还是机器初筛 + 人工定夺。每次大概花一个半小时，烦是真烦，像批作业。但坚持了两个月，未命中率从 38% 降到 12%，而且降得很扎实——补的每一篇文档都对应真实问