标题: cc的Agent Team大家有什么有趣的玩法？
作者: #Underthemoon
板块: #开发调优
编号: 2220004
帖子: https://linux.do/t/topic/2220004
时间: 2026-05-21 16:51:19
摘要:

今天开了5个Agent并行研究一个任务，挺好玩的

标题: win10的本地连接不见了
作者: #wanzi
板块: #搞七捻三
编号: 2220018
帖子: https://linux.do/t/topic/2220018
时间: 2026-05-21 16:53:31
摘要:

求助各位佬，突然发现笔记本上本地连接不见了，然后开热点出现无ip分配这个怎么办？

标题: xiaomi mmo token plan 2亿key 分享
作者: #JaydenHarrys
板块: #福利羊毛
编号: 2220019
帖子: https://linux.do/t/topic/2220019
时间: 2026-05-21 16:53:32
摘要:

有效期到2026-06-07
兼容 OpenAI 接口协议：
https://token-plan-cn.xiaomimimo.com/v1
兼容 Anthropic 接口协议：
https://token-plan-cn.xiaomimimo.com/anthropic
APIKEY: tp-ce66ts1po8s7xtaqc6pzoq5apdyuv2xn91y7ddal6nj2lnu0
模型
MiMo-V2.5-Pro、MiMo-V2.5、MiMo-V2.5-TTS-VoiceClone、MiMo-V2.5-TTS-VoiceDesign、MiMo-V2.5-TTS、MiMo-V2-Pro、MiMo-V2-Omni、MiMo-V2-TTS
额度
200,000,000 Credits
编程工具
支持 OpenClaw、Claude Code、OpenCode、KiloCode 等国内外主流编程工具

标题: Codex App 为啥问个你好就要用18K Token？有优化的方法吗？
作者: #WANGXIANRU
板块: #开发调优
编号: 2220035
帖子: https://linux.do/t/topic/2220035
时间: 2026-05-21 16:56:23
摘要:

这也太抽象了。我的自定义指令就一两句话。难道是内置的提示词占用的吗？能否精简？

标题: 【实践分享】25年到26年，我的NL2SQL智能体是如何迭代的
作者: #踏雪寻玫
板块: #开发调优
编号: 2220040
帖子: https://linux.do/t/topic/2220040
时间: 2026-05-21 16:56:58
摘要:

【实践分享】25年到26年，我的NL2SQL智能体是如何迭代的
前言
之前写过一篇《如何手搓一个RAG》，当时主要讲的是知识库问答。
引流：https://linux.do/t/topic/2187051
这篇讲另一个更痛苦的东西：NL2SQL。
先叠甲：


我不是底层模型开发，也不是论文选手，我是AI应用开发，现在人们叫AI应用落地工程师（有点想补一个黄豆流汗）。


这篇不讲特别高大上的理论，主要讲我自己从老项目到新项目的工程迭代。


里面很多东西可能现在看起来很土，很笨，很原始。


因为很多东西不是一开始就长成现在这个样子的。
现在大家都很懂智能体、tool call、workflow、planner、memory、MCP，但我第一次认真把这套东西串起来的时候，企业应用里还没有这么成熟的说法。那时候更多叫机器人、助手、问答系统，或者更朴素一点：大模型接口外面套一圈业务逻辑。
先说时间线
老项目是一个早期业务问答助手，这里就不写真实项目名了。
下面会附上老项目的git记录，其实实际时间比git更早，但有git记录就已经能说明老了。
老项目的Java服务模块最早能追到：
2025-08-04 11:00:49  早期数据问答基线上传

Python智能问答模块也是同一天开始：
2025-08-04 11:00:49  早期数据问答基线上传

然后到了2025-08-14，提交记录里已经出现了这种东西：
意图识别时校验问题中的数据表是否存在
生成SQL时判断问题中的字段是否存在
生成SQL提示词优化，增加自校验逻辑
SQL执行错误给出友好提示

再到2025-08-19，又有：
报表问答准确率提升：修改生成SQL提示词结构，采用少样本提示的标准写法

也就是说，至少在2025年8月，这个东西已经不是“我接个模型接口玩一下”了，而是在认真处理意图识别、表识别、字段校验、SQL生成、错误兜底这些问题。
新项目是2026年重做的一套业务智能体系统。
它的项目初始化是：
2026-04-20 14:45:08  项目初始化

数据问答正式落到新项目里，是：
2026-04-23 15:44:44  新增数据问答前后端能力并完成会话链路语义解析接口与数据库表落库

所以这篇讲的不是“我最近看agent火了，赶紧包装一个概念”。
更准确地说，是：
我在智能体概念还没有被企业应用完全标准化的时候，先用一种很土的方式把它做出来了；然后到2026年，我又把这套土办法重新工程化了一遍。
老数据问答：先把链路跑通
老数据问答主要看两个部分：


Java服务模块


Python智能问答模块


虽然用户入口、会话记录、前后端接口在Java应用里，但真正干NL2SQL脏活累活的是Python侧的问答模块。
当时的链路大概是这样：
用户提问
-> 问题重写
-> 意图识别
-> 判断要查哪张表
-> 权限校验
-> 拼表结构和few-shot样例
-> 让大模型生成SQL
-> 从模型返回里抠出SQL
-> 执行SQL
-> 让大模型总结结果
-> 如果用户要图表，再让大模型生成Echarts配置
-> 流式返回给前端

现在看起来，这不就是一个智能体么？
有意图识别，有工具选择，有工具执行，有结果加工，有流式输出，甚至还有图表工具。
但当时我不会这么说。
我只会说：这是数据问答。
或者说得更土一点：这是一个会查数据库的机器人。
问题重写
老链路里第一步就是问题重写。
这个东西在知识问答里重要，在NL2SQL里更重要。
因为用户不会每次都把问题说完整。
比如：
第一轮：今年杭州有多少商机？
第二轮：按行业分一下

如果第二轮直接拿去生成SQL，大模型可能知道“按行业分一下”是什么意思，也可能不知道。它不知道的时候，就开始表演了。
所谓表演，就是一本正经地胡说八道。
所以老项目里先把历史问题压缩成当前独立问题。这个思路没错，到现在也没错。
只是当时实现比较朴素：把最近几轮对话塞进提示词，让模型判断要不要改写。能用，但依赖模型稳定性。
意图识别
老项目里有一个很典型的东西：函数式意图识别。
它会让模型返回类似这样的结构：
{
  "function_call": {
    "name": "search_sql",
    "arguments": {
      "table": "项目表",
      "char": "柱状图"
    }
  }
}

这其实已经很接近现在大家说的tool call了。
只不过那个时候不是标准工具协议，也不是框架自动帮你做。就是自己写提示词，自己解析JSON，自己判断name是什么，自己决定下一步走哪里。
有人会问了，这不就是手搓function calling么？
是的。
很土，但能跑。
SQL生成
老链路真正刺激的地方是SQL生成。每次演示就好像上战场一样。
当时的思路很直接：


根据用户问题识别要查哪张表。


找到这张表的字段说明和相似问法。


把表结构、字段含义、few-shot样例、SQL生成规则一起塞给模型。


让模型返回SQL。


程序再把SQL抠出来执行。


这里的核心其实是few-shot。
例如“今年杭州新签约合同数量是多少”这种问题，对人来说很简单，对模型来说不一定简单。因为它要知道：


“今年”对应哪个时间字段。


“新签约”对应哪个状态或日期。


“杭州”对应城市字段，而且可能还要处理“杭州市”“杭州分公司”这种说法。


“数量”是count，不是把某个金额字段求和。


所以当时靠大量样例去教模型。
这条路是有效的。
但它有一个问题：越做越像补丁。
你发现“城市”识别不准，就加城市规则。
你发现“字段不存在”会乱生成，就加字段存在性校验。
你发现SQL报错太难看，就包装友好提示。
你发现用户想看图，就让模型再生成Echarts配置。
你发现“省、市、区县”容易混，就再写一个地名修正。
最后系统当然能跑，而且效果还可以。但你心里知道，这东西有点像用胶带把飞机粘起来。
飞是能飞。
但每次上线都要默念一句：千万别问奇怪问题。
老在哪里
这里我要强调一下，“老”不是贬义。
很多老办法在当时就是正确答案。
因为业务要结果，用户要能用，领导要演示，项目要交付。你不可能坐在那里说：等我设计一个完美语义层，半年后再说。
不现实。
老项目确实就是有很明显的时代痕迹。
第一，模型直接生成SQL
老链路里，模型承担的任务太重了。
它不仅要理解用户问题，还要理解表结构，还要选择字段，还要生成SQL，还要自己判断字段是否存在。
这就像让一个实习生同时当产品经理、数据库工程师、测试和客服。
他有时候很聪明，有时候也真的离谱。
最简单的例子：字段名。
你给他一张表，里面有“合同金额”“签约金额”“中标金额”“预算金额”。用户问“金额是多少”，他到底该用哪个？
如果业务口径稳定，模型可能猜对。
如果业务口径不稳定，模型猜对了也只是运气。
第二，提示词越来越长
为了让模型不犯错，我们会不断往提示词里加规则。
不能select *。
日期要怎么转换。
城市要去后缀。
字段别名不能当查询条件的值。
枚举值模型不能自己发明。
SQL生成前后要判断字段是否存在。
SQL生成后再自检一下字段是否存在。
听起来很严谨，对吧？
但提示词不是法律。
提示词更像劝告。
你说了一百条规则，模型不一定真的每条都遵守。特别是表结构一长、样例一多、用户问题一复杂，它就开始挑自己记得住的部分执行。
这就是老链路让人很痛苦地方。
第三，解析靠字符串和正则
老项目里会从模型返回中提取JSON、提取SQL、提取Echarts配置。
这也是当时很常见的做法。
模型返回：

sql
select ... from ...

我们就用正则把他抠出来。
模型返回：

json
{"sql": "select ..."}

我们就转JSON。
问题是，模型有时候会多说一句“好的，以下是SQL”。
也有时候会少一个引号。
也有时候会把中文标点、代码块、换行混在一起。
然后你就开始写各种清洗逻辑。
写到最后，你都分不清自己是在做NL2SQL，还是在做大模型输出垃圾回收。
第四，安全边界后置
老链路也做了不少安全处理，比如权限校验、表名校验、SQL错误兜底、结果数量限制。
但整体上，它还是先让模型生成SQL，再在后面拦。
这个顺序在生产里会带来心理压力。
因为模型生成SQL这件事本身就是不稳定的。
你可以拦掉delete、update、drop，也可以限制只查某些表，但只要SQL是模型自由生成的，它就总有一些奇怪路径。
比如字段错了。
比如条件错了。
比如时间字段错了。
比如聚合口径错了。
这些不一定是安全事故，但一定是业务事故。
用户不一定知道SQL错了，他只会觉得你的机器人在胡言乱语。
第五，业务口径藏在提示词里
这是我后来最深的感受。
NL2SQL最难的不是SQL。
是业务口径。
“今年新增项目数”到底按创建时间、立项时间、签约时间，还是入库时间？
“中标金额”用预算金额、中标公告金额，还是合同签约金额？
“商机数量”算草稿、已发布、已中标，还是全部？
这些东西不应该藏在提示词里。
因为提示词不适合承载业务制度。
提示词适合表达任务，业务口径应该进配置、进表、进规则、进校验的结构。
这也是我从老项目走到新项目