做数据问答类的 Agent，绕不开"让它拿到数据"这步。我前后试了三种接法，踩了不少坑，干脆横向拉一张表，省得你像我一样一个个试过来。先上结论表：接法怎么做优点坑适合知识库（RAG）把文档/数据导进知识库，检索后回答上手快、无需写代码、能防瞎编实时数据不行、召回要调文档问答、政策/手册类Text2SQL让它把人话翻成 SQL 查库能查实时、灵活口径要写死、复杂查询翻车、安全风险结构化数据自助查询工

做单轮问答的 Agent 很简单,一进一出完事。——用户上一句说"帮我订北京的",这一句说"改成明天",你的 Agent 得知道"明天"是接着"订北京"的。我在做一个预约助手时,会话状态管理这块来回返工了三遍,把心得理成几条。

我一开始每轮都无脑更新画像，后果是用户随口说句"今天天气真好"，模型也认真琢磨要不要更新字段，偶尔还真给我把 last_topic 写成"天气"。让模型 merge 旧摘要和新信息，它偶尔会把旧的关键事实悄悄丢掉——比如原来写着"拒绝股票型"，改写完变成只剩最近一句"想了解黄金"。我现在的土办法是，把画像表里的硬字段当锚点，摘要只补软性偏好，硬事实绝不依赖摘要。字段是预先定义死的，模型只负责"填空

先把结论摆前面：模型调工具传错参数，最划算的兜底就一招——把"哪儿不合格"原样回喂给模型，让它自己改一遍再调。别急着报错给用户，也别写一堆规则去猜它想干嘛。我线上跑了一个多月，一次自纠能救回七成多的失败调用。

我的结论很明确：用 AI 生成应用时，我把需求写成“角色、对象、状态、规则、验收”五部分，返工会少很多；只写一句功能愿望，页面出得快，后面的逻辑债也来得快。我这次以产品经理身份做了一个读书会图书漂流小程序。它要让书友登记闲置书、预约取书、确认借出、归还后重新流转。我用的是一类“中文需求直出多端应用”的零代码 AI 工具：我输入自然语言，它就能生成可用的微信小程序、APP、H5 或鸿蒙应用，生成后还

我的结论很明确：用 AI 生成应用时，我把需求写成“角色、对象、状态、规则、验收”五部分，返工会少很多；只写一句功能愿望，页面出得快，后面的逻辑债也来得快。我这次以产品经理身份做了一个读书会图书漂流小程序。它要让书友登记闲置书、预约取书、确认借出、归还后重新流转。我用的是一类“中文需求直出多端应用”的零代码 AI 工具：我输入自然语言，它就能生成可用的微信小程序、APP、H5 或鸿蒙应用，生成后还

先说结论:不用写一行代码,拖一拖配一配,我真的在一周里把一个能用的 AI 小助手搭起来了——省掉的主要是后端那堆胶水活,不顺手的地方在于它干的始终是杂活,真正难的判断还得我自己兜。上周三晚上十点多,我本来只是想找个借口拖延手头一个老需求。运营那边老让我帮忙从十几份周报里扒数据、对口径、再汇个总,纯体力,烦得很。我寻思能不能让 AI 干。以前我对"AI Agent"这词是有点抵触的。一提就是要装框架

先说结论:不用写一行代码,拖一拖配一配,我真的在一周里把一个能用的 AI 小助手搭起来了——省掉的主要是后端那堆胶水活,不顺手的地方在于它干的始终是杂活,真正难的判断还得我自己兜。上周三晚上十点多,我本来只是想找个借口拖延手头一个老需求。运营那边老让我帮忙从十几份周报里扒数据、对口径、再汇个总,纯体力,烦得很。我寻思能不能让 AI 干。以前我对"AI Agent"这词是有点抵触的。一提就是要装框架

我后来是在一个零代码搭智能体的平台上配的：函数节点后面挂一个校验节点，校验节点的失败分支连回模型节点形成重试环，到次数上限走转人工分支。见过模型连编三次不同的假 ID 死活不改的，再循环下去就是烧钱，到上限直接转人工。这种具体原因塞回去，模型很多时候会反应过来"哦我没问用户要订单号"，转头去问用户，而不是再编一个。这种"入参幻觉"我吃过亏，下面用问答的形式把我趟过的几个问题理一遍。MaaS，现成

这套重试-降级逻辑我是在一个零代码搭智能体的平台上配的，工具调用节点能直接设超时、设重试次数、连降级分支，可视化拉条件线就行，不用自己在代码里写try-except嵌套。不过有个取舍得提：平台的重试策略是通用的，遇到那种"要根据返回body里的业务码决定重不重试"的细活，还是得自己在节点里加判断，它不会替你读懂每个第三方接口的脾气。"——把单号回给他，给个替代路径，比一句"系统错误"强一百倍。一开