先把结论摆这儿：function calling 这东西,默认就当它会出错来设计。模型该返回的地方,它有可能给你来个,或者参数名拼成citys,再或者干脆把 JSON 写崩了。线上跑久了你会发现,失败率没你想的低。我自己那套客服流程,头一周统计下来,函数调用相关的异常占了所有报错的三成多。所以兜底和降级不是锦上添花,是必须先铺好的地基。下面是我踩过坑之后定下来的几层防护,按"问题→设计→结论"说。

第一版我提示词写得太干，它回得像教科书，废话多，我删删改改试了五六轮才顺。结论先放这儿：线上智能体半夜报错，我没急着翻日志，先把那一坨堆栈丢给大模型让它先给个诊断，省了我至少四十分钟。配完我对着它贴了条上次那段 502 日志测了下，它真就把和风天气那条又拎出来了，还附了我们复盘文档里同类问题的处理记录。的目标域名，是我们一个第三方天气 API——对，这服务里有个挺无厘头的功能，用户问天气它去调和风

短期上下文（记住这轮对话）好做，难的是长期记忆——让 Agent 跨会话记住"这个用户上次问过啥、有啥偏好、是老客户"。做个性化服务，这步躲不开。但一不小心就踩隐私的雷。说说我的做法和顾虑。

这篇讲我怎么给一个知识库问答 Agent 加上引用标注,实操向。

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

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

一个智能体里不是只能用一个模型。我做的客服分析流程拆了五个节点，五个节点我挂了三种不同的模型，每月 Token 花费比"全程用最强模型"省了大概六成，效果几乎没掉。怎么分的，记一下。

客服AI小助手只要上线对外，就躲不开合规这事。模型偶尔会被用户带歪，说出不该说的；用户也可能在对话里发违规内容。我给一个对外客服智能体加了一层合规过滤，分享下我的做法和踩的坑。

第一版我提示词写得太干，它回得像教科书，废话多，我删删改改试了五六轮才顺。结论先放这儿：线上智能体半夜报错，我没急着翻日志，先把那一坨堆栈丢给大模型让它先给个诊断，省了我至少四十分钟。配完我对着它贴了条上次那段 502 日志测了下，它真就把和风天气那条又拎出来了，还附了我们复盘文档里同类问题的处理记录。的目标域名，是我们一个第三方天气 API——对，这服务里有个挺无厘头的功能，用户问天气它去调和风

我的结论是：零代码生成的会议室预约小程序可以交付，但我只把通过验收清单的版本算完成；页面能打开、按钮能点击，只能算演示稿。我接到的是一个共享办公区内部需求，三间会议室供二十多人预约。作为外包程序员，我先把上线边界钉死：仅服务已录入员工，开放时间为工作日 9:00—20:00，按 30 分钟切片，单次最长 2 小时，只能预约未来 14 天，不接访客审批、门禁控制和付费。边界写清后，我才把需求写进，生