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

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

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

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

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

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

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

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

临界点也很清楚:当你发现自己开始跟低代码平台"斗智斗勇",为了绕一个它不支持的逻辑而拼三四个节点的时候,就该切回 IDE 了。下面这张表是我自己踩下来的判断,不是抄文档的:维度零代码搭写代码搭从想法到能用半天到一天三五天起步改一版的成本拖拖配配,几分钟改代码+测+发,半天没了接私有知识库(RAG)上传文档配一下就行自己搞 embedding、向量库、召回复杂分支/外部系统一绕就别扭想怎么写怎么写谁

底层其实就是 RAG 的思路,只不过粒度卡在了"章节"这个对人类最自然的单位上,而不是机械地按固定字数切块——按字数切常常把一个完整论述从中间劈开,目录粒度能保住语义的完整。具体搭的时候,我没自己写编排,用了个零代码就能配智能体的工具,拖几下把"建目录—问答—引用章节"的链路接起来,逻辑都是配出来的,没敲代码。说实话第一版做出来挺干的,目录抽得太粗,二级标题全丢了,问细节照样定位不准,我回去把摘要