第四百一十六章 这才是新时代的API（2/2）
请关闭浏览器的阅读/畅读/小说模式并且关闭广告屏蔽过滤功能，避免出现内容无法显示或者段落错乱。
他做后端开发的时候，就算跳槽去的那家二线中厂，也只能给到税前四十万年薪，每个月到手才两万多。
现在的收入是那时候的四倍。
而且这是月度订阅，不是买断——也就是说，每个月都是十万；如果付费用户继续增多，后面还会涨。
这就是当风口上的猪的感觉？
可太爽了！
最近购买元宵邮箱的用户越来越多，很多还来自海外。
显然，相比于国内把很多业务都放在微信里，国外用户更偏向重度使用邮箱。
甚至还有很多企业来问协作功能，想要企业采购。
做过SaaS业务的林一舟立刻反应过来：这是真正稳定的收入来源。和个人用户不一样，企业采购流程复杂，一旦批准之后，也就不太容易轻易中断了。
但问题是，他们的一个主要需求是：不只是让元宵邮箱当一个被AI助手调用的工具，而是希望元宵邮箱能作为一个入口，同时还有那些AI功能，比如自然语言筛选邮件啊、操作邮件等等。
林一舟当然也想继续抓住这波风口。
可要给自己的这个小软件加上AI功能，就必须在后台调用API了。
这可是真真正正在开发AI智能体了。
想制作一个让AI助手能调用的工具，只需适配汤圆协议，也就是说让自己的功能能被AI使用，其实完全不需要什么AI能力。
但要开发智能体，却需要对AI有所了解。
虽然服务的人里有不少国外用户，但作为开发者的林一舟人在国内，就只能使用国内模型厂商提供的API。林一舟已经试过几个不同选项，最后结果都不尽如人意。
就拿最基本的筛选邮件功能来说，其实林一舟需要的功能很简单。
如果用户用中文或者英文说：“帮我找出上周的邮件。”
林一舟需要把这个输入连同他写好的系统提示词一起发给AI模型的API。
作为一个传统后端开发，系统提示词他自然没什么经验，只能一边在网上搜索别人分享的模板，一边自己摸索效果。
第一版是这么写的：
【你是一个邮箱助手，用户使用语言描述他的需求，把这个需求转化为以下命令之一，返回固定格式的JSON文档】
【JSON文档格式为：】后面是一个多层嵌套的JSON格式，然后在元宵邮箱客户端再写一个解析器（Parser），把这个JSON转化为具体命令。
【用户输入：】然后在里面填上用户输入的话。
按道理，这个时候API会把客户需求翻译成一个邮箱软件可以理解的命令，然后软件直接运行就可以了。
但林一舟惊讶地发现，就这么一个简单的架构，中间的坑竟然这么多。
因为客户有可能说的是：“帮我找出上周需要我回复的邮件。”
这怎么找？
得先把时间范围圈出来，然后把邮件内容发回给API，让它判断是不是需要回复。
可现在API只会回一种命令，就是系统提示词里规定的那种。
林一舟抓瞎了：系统提示词越写越复杂，接收回复的处理器也越来越复杂，但功能上却没有提升多少。
昨天晚上临睡前，又一次尝试失败了——坤元的API返回了一个解析器无法理解的内容，系统报错。
妈的，自己写一个智能体，才知道开发智能体有多难啊。
这一个需求卡了林一舟一个多星期，也没什么进展；不出意外，今天他也要度过在工作室和这个新功能死磕的一天。
从床上爬起来的林一舟在卫生间里一边刷牙一边刷手机，刷到了一个他平时关注的AI博主。
这个博主虽然时不时有点儿干货内容，但风格实在浮夸，还喜欢贩卖焦虑。林一舟心不在焉地看着。
“重磅新闻！汤圆1.0模型的API今天正式开放了。如果你还没有听说过汤圆1.0是什么，那你真的OUT了。这就是我们每天使用的汤圆Chat后面的模型。所有关注我的粉丝，我推荐你现在就去注册一个起源开发者平台的账号，真的会改变你的认知……”
博主还在滔滔不绝地输出内容，林一舟却看到这儿反应过来。
他说什么？
汤圆开API了？
怎么一点儿消息都没有？
林一舟漱了漱口，把嘴里的泡沫都吐出去，然后用手机打开起源官网上关于汤圆模型的内容。
竟然真的开放了！
额度有限，先到先得！
林一舟也顾不得自己还没来得及吃早饭，从卫生间出来就直奔电脑，先把API额度买上再说。
林一舟是多年的老开发，这种流程不知道走过多少遍了。很快他就绑好支付方式，生成了APIKey，并且往里充了一千块钱。
他之所以充这么多钱，自然是出于对汤圆系列模型一直以来的信任。
就算自己的API开发不顺利，这些额度将来也用得上，不会浪费。
如果是别的平台，他可不敢这么使劲充值——充进去的钱可不退款，你用不完是你活该。
随后，林一舟仔细查看起汤圆1.0API用法的官方教程来。
里面对如何用汤圆API开发智能体有详细讲解，尤其特别强调了对长程任务该怎么处理。
林一舟看得心头一阵狂跳。
我的这个元宵邮箱里，如果用户需要使用的功能是和邮件内容有关的，那不就是长程任务吗？
果然，汤圆API对智能体相关的长程任务有个新东西：工具调用链。
也就是说，不只是把元宵邮箱需要接收什么告诉汤圆，而是把元宵邮箱能做的所有事情都告诉汤圆，然后由汤圆来决定调用什么功能，后续是不是还要继续和汤圆API交流。
所有需要在客户端实现的复杂逻辑都不用写了，直接交给汤圆去做。
林一舟一边看一边怀疑。
不是不信哈，但这写得也有点儿太美好了吧？
不过反正尝试也不复杂。林一舟把之前写的好几十行系统提示词先注释掉，然后按照官方教程，把元宵邮箱提供的这些功能写成汤圆API接受的工具格式。
其实很好写，格式基本和汤圆协议一样。
然后最后只写了一行解析器和一个循环。
准备测试了，林一舟屏住了呼吸——不对，等等，先给循环加一个次数限制，不然模型犯傻一直调用，把我钱花完了怎么办？
林一舟庆幸自己的急智，把这段缺失的逻辑加上了：循环最多执行十次，也就是说最多会对汤圆API发起十次请求。
然后他再次屏住呼吸，在新编译好的本地开发版输入了那个让他最近无比挫败的命令：“帮我找出上周需要我回复的邮件。”
然后他没等着看结果，而是直接打开开发者模式开始看本地日志。
【发往汤圆API：用户：“帮我找出上周需要我回复的邮件”，工具：……】
【回复：调用工具：按日期筛选邮件，获取邮件内容】
【发往汤圆API：246封邮件内容】
【回复：调用工具：渲染界面，邮件ID*17】
调用两次之后，调用链结束了。
林一舟切回到元宵邮箱的界面，只见他故意生成的两百多封测试邮件里，之前他手动标记出来的、需要回复的那十七封已经被筛选了出来。
此时此刻，林一舟说不出心里是什么感觉。
这也太牛逼了。
这个困扰了他一个多星期的问题，就被这样一个简单的循环给解决了。
之前我测试的那些API都是什么？
这才是新时代的API吧！
林一舟迅速把这个改动提交了，然后在元宵邮箱里输入了一个新的命令：“帮我把所有询问过元宵邮箱AI入口的邮件找出来，统一回复：新功能已经开发完成，预计下周更新。”