每日AI新鲜事·07月06日早间播报：agent开发难点与开源大模型

今天AI圈的消息还挺杂的，有开源模型、有技术论文，还有一堆开发者在争论到底什么才算是真正的agent开发难点。李博，你刷到什么了？

我刷到一个Bilibili上的视频，标题很有意思——"agent开发不就是调接口吗？难点到底在哪？"一看就是要跟某些人较劲的那种标题。

这个标题我太有共鸣了，真的。很多业务方跟我聊agent需求的时候，就是这个心态——你不就是接个API嘛，怎么这么麻烦？

对，这个认知偏差太普遍了。调接口这件事确实简单，难的是你怎么让模型在多步任务里不犯浑、不绕圈、不把工具用错。

你想想，一个agent要做规划、要调工具、要处理工具返回的结果、要决定下一步，每个环节都可能出错，而且错误会级联放大。

对，我们内部管这叫"错误雪球"，第一步偏了，后面每步都在那个偏差上继续叠。到最后交付出来的结果，你根本不知道它在解哪个问题。

还有一个很折磨人的地方是观测性——你没法像调普通代码那样打断点，agent的中间状态很难追，出了问题复现都难。

所以说啊，"调接口"这四个字听起来简单，背后要做好的工程量是完全另一个量级的事。这个话题说出来了很多开发者的心声。

而且现在不少人是直接拿Dify之类的平台搭agent，顺带说一下，Bilibili上也有人发了Dify的容器安装教程，Docker一键部署那种，对想快速上手的人还挺实用的。

对，工具层确实越来越低门槛了，但理解清楚agent的本质难点还是绕不过去。好，说完agent，我们来聊聊今天开源圈的大消息。

RSS上有条更新——longcat 2.0开放权重了，MIT协议，总参数1.6T，但激活参数大概是48B左右，是MoE架构。

1.6T总参数，MIT协议，这个力度挺猛的。MoE的好处就是推理的时候只激活一部分参数，实际计算量控制在48B级别，跑起来没有那么烧卡。

MIT协议意味着商用也没有限制，这对中小团队来说还挺有吸引力的。不过1.6T的模型，存储和加载本身就是个挑战吧？

存储肯定得有一定规模的机器，但激活参数只有48B这件事意味着推理效率其实还好。当然你要全量微调的话，那就是另一回事了，基本只能做LoRA。

说到本地部署，今天还有条消息——有人在聊用llama.cpp跑树莓派。树莓派啊，那真的是……挑战极限了。

llama.cpp这东西最强的地方就是极致压缩，能把模型量化到很低的精度，树莓派跑个小参数量的模型理论上是可行的，就是慢。

慢到什么程度，一秒出一个token那种？

取决于模型大小，可能更慢。但这类探索本身有价值——边缘端推理这个方向，总要有人去摸极限在哪里，树莓派是个很极端的测试场景。

说到小参数模型，今天rss里也有开发者在问——Qwen 3.7 9B有消息了吗？还有没有其他9B级别的替代方案？

9B这个量级确实是很多人的甜点区，本地跑得动，效果又不太差。现在社区对Qwen系列的关注度挺高的，大家期待Qwen 3.7能在这个参数段有突破。

感觉大家越来越喜欢在"够用就好"的参数量里卷性能，而不是一味追求参数堆量。这和longcat那种1.6T MoE方向某种意义上是一个思路，只是路径不同。

对，一个是用稀疏激活解决大参数的效率问题，一个是直接在小参数里卷性能天花板，殊途同归——都是在算力约束下找最优解。

还有一篇论文值得提一下，Multi-Resolution Flow Matching，是关于扩散模型推理加速的，训练免调的那种，通过分阶段采样来提速。

training-free这个方向现在很热，因为大家都不想重新训练，成本太高了。通过多分辨率的分阶段采样来减少步数，思路挺聪明的，本质是在粗粒度阶段快速收敛，细粒度再补细节。

就像先打草稿再精修，不用每一笔都从头来？

差不多就是这个意思，这个类比挺准的。扩散模型加速一直是工程落地的痛点，每次出training-free的方案社区都会很兴奋，因为直接能用。

好，今天消息不少，从agent开发的本质难点，到longcat 2.0开源，再到llama.cpp跑树莓派，还有扩散模型加速的新论文。

总体感觉今天的主旋律就是——怎么在更少的资源里把AI跑得更好、更实用。这个方向我觉得会持续很久。我们晚上见。