MoreRSS

site iconVicalloy | 天地一沙鸥修改

程序员与技术爱好者,曾用ID zbird,现在vicalloy,杭州居住,擅长多种编程语言,喜欢分享开源作品和软件开发经验。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

Vicalloy | 天地一沙鸥的 RSS 预览

我的 AI Agent 实验项目 Sequoia

2026-03-17 20:09:47

今年 OpenClaw 的忽然爆火,让我有些难以理解。在我看来 OpenClaw 似乎没有太多实质性的创新。除了不支持 IM 控制外,给任何一个 AI Client 加上 SKILLS 和 MCP 似乎都可以做到类似的事情。在对 OpenClaw 有了些了解后,虽然依旧认为 OpenClaw 不存在太多颠覆性的东西,但要做好并不容易。

OpenClaw 本质是一个带记忆模块的Agent管理工具,并通过 IM 的集成极大增强了用户体验(虽然现阶段依旧是个玩具)。或许 OpenClaw 这样可以通过 “记忆” 持续学习并可以通过 SubAgent 分工合作完成任务的 AI 工具会成为今后一段时间 AI 的发展方向。

为了探索 AI 能力的边界,开了一个试验性项目 Sequoia 。Sequoia(红杉)世界上最大的树,寓意一颗小小的种子终有一天可以长成参天大树。

AI Agent 框架选型

为了方便验证想法,因此希望框架可以帮忙完成MCP/SKILL调用、交互界面、SubAgent创建等大部分常规工作。这样我可以聚焦记忆模块和关键工具模块的设计。同时尝试通过prompt让 AI 自己决定如何来使用这些工具。在研究过主流AI开发框架后最终选定了 LangChain Deep Agents。下面是考虑的一些框架。

Pydantic AI

可以说 Pydantic 是 Python 界数据校验框架的事实标准。在很早之前就简单了解过 Pydantic AI,Pydantic AI 的 API 也算是比较易用。但实际使用过程中发现 Pydantic AI 的 SubAgent 管理功能非常弱,涉及 SubAgent 的操作会很不方便。且 Pydantic AI 没有配套的 UI,想要一个易用的交互 UI 得花不少功夫。

CrewAI

CrewAI 是个多代理编排框架。强项是 SubAgent 的协同管理,可以轻松实现多 Agent 协同。CrewAI 的发展势头不错,且非常易用。不过 CrewAI 的记忆模块和框架深度绑定。由于我想探索如何精确的管理 AI 的记忆,因此放弃。

LangChain Deep Agents

LangChain 是使用最为广泛的 AI 框架,拥有完整的生态。Deep Agents 是 LangChain 团队推出的 Agent 框架,可以完美的融入 LangChain 生态。记忆模块作为独立组件,可以方面用户自行扩展。可以使用 Agent Chat 和自己的 Agent 交互,免去了 UI 的相关工作。

项目现状

目前搭建了基础的项目框架。利用 Deep Agents 框架本身能力提供了 SKILLS支持、SubAgent 管理、本地文件读写等功能。

按照我的预想,记忆应当通过“文本+图数据库+向量数据库”共通管理。为此我自己添加了向量数据库和图数据库的集成。

考虑如果一开始就将应用定位成一个带记忆,可以自主学习的完整“人”实现起来会非常困难。最初会尝试利用这个框架来写小说。

小说生功能设计及问题

小说的写作知识完全通过 SKILL 教给 AI。框架只提供文件读写、数据库读写工具,具体怎么用这些工具完全由 AI 自己决定。

AI 对于长文写作的一大难点是 LLM 的上下文长度限制。为了突破 LLM 的限制,必须将小说大纲、设定、章节摘要等信息分别保存,让 AI 在需要时再自行加载。

尝试用 AI 生成了一篇小说的前两章(使用 qwen3-plus)。似乎 AI 对指令的依从性不是很高。虽明确要求使用图数据库保存人物关系等信息,但在我主动要求前没被触发。另外 token 的消耗速度非常惊人。没跑几次就把 qwen3-plus 赠送的 100 万 token 用完了。随着文章长度的增加,上下文长度会持续增长, token 的消耗量也会快速增加。后续应当会一边调整 SKILL 一边不定期更新。

小说链接:《他们都劝我冷静,然后我疯了》

杭州的四季

2026-03-08 19:29:10

不觉间又到了杭州的春季,看花开花谢,竟有些不舍。忽然想写写杭州的四季,虽留不住时间,却能留下当下的心情。

曾无法理解古人笔下的春天,在我看来春天有的只有无尽的阴雨。来了杭州后慢慢的理解了古人为何会伤春。

杭州的花季从一月底的梅花开始,到三月底的桃花结束。在这短短的两个月里,百花争艳,你方唱罢我登场,好不热闹。桃花过后纵有千般不舍也只能再待来年。杭州的春天明丽却又短暂,韶华易老,春花易逝。

杭州的夏天不是不美,只是对于久居江南的我而言,绿水青山、映日荷花都只是日常。美则美矣,只是美的有些平淡。

春天犹如一位少女,扭动着自己婀娜的身姿,肆无忌惮的展现着自己的美。秋天则如一枚花火,在冬天来临前一次性的释放了自己所有的能量,绚烂的毫无保留。

杭州最美的秋色等到11月中旬。乌桕、水杉、枫叶、银杏将杭城装点点的五颜六色,然后又在阵阵寒风中褪去了所有色彩。

冬日的杭州有着几分萧瑟,不过因为雪,让人多了几分期待。雪后的西湖有着自己独特的美。千山暮雪、断桥残雪是穿越千年的浪漫。

近年来城区很少积雪,不过好在还好可以去杭州周边的山区看雪。

AI将如何重塑这个世界

2026-03-04 21:47:07

一、AI进化的悖论

AI的发展高度依赖其训练所用的语料。互联网的蓬勃发展为AI提供了海量且高质量的训练素材。然而,随着AI的普及,大量由AI生成的低质量内容开始反噬互联网,造成严重的信息污染。内容的数量在激增,但整体质量却在下降。寻找纯净、高质量的语料库,正变得前所未有的困难。

二、传统编程技术的末路?

随着AI技术的突破,“vibe coding”已进入实用阶段。或许在不久的将来,新入行的编程人员只需要掌握这种交互方式即可,而传统的编程语言则会像如今的汇编语言一样,退居幕后,只需少数专业人士掌握。

对于新兴的编程语言和框架而言,由于AI对其不够熟悉、难以熟练运用,可能陷入无人问津的恶性循环,最终难以发展。除非新的编程技术从一开始就围绕“如何让AI高效使用”来设计,否则很难获得成长空间。近年来,Go、Rust、TypeScript、Swift等语言蓬勃发展,本以为是高级语言新一轮演进的开始,没想到却遇到了AI这个分水岭。或许,它们就是最后一代能被广泛使用的高级语言了。

AI阅读代码的速度远超人类,但它也有自身的极限。大多数软件在代码彻底失控之前,可能就已经寿终正寝了。对于一些简单的应用,纯“vibe coding”或许不是问题;但对于复杂的软件系统,如果任由AI不断堆砌代码,最终形成的“屎山”就连AI自己也会无能为力。

如果“vibe coding”成为主流编程方式,低质量代码对语料库的污染,将远比其他领域的知识污染更为严重。

三、生产力革命与社会结构重塑

回顾历次技术革命,其本质都是对人类劳动的替代。工业革命用机器取代了体力劳动,机械技术的发展使得普通手工业者无论如何努力,其生产效率和质量都无法与机器抗衡,因此市场只留下了少数满足个性化需求的“匠人”。这些被释放的人力,最终流入了脑力行业和第三产业。

今天的AI革命则更进一步,开始取代人的智力劳动。类似地,AI的发展也将使大多数智力平平者难以企及AI的能力,智力劳动领域同样只需保留少数顶尖的“匠人”。然而,这一次被释放的大量脑力工作者,似乎还没有找到合适的承接领域。

经济活动最终要服务于人的消费。如果生产力的提升导致大量人口失业,就必须建立新的分配规则,否则将引发生产过剩的经济危机,进而导致大萧条。生产力决定生产关系,当AI将生产力推升到一个新高度时,旧有的生产关系必然面临调整。

如果不能妥善应对AI带来的这一系列挑战,现有的社会秩序很可能面临崩溃的风险。

水浒传杂谈,乱世中没有救赎

2026-02-03 20:48:00

通俗演义中的水浒常被描述成官逼民反的英雄叙事,然而水浒传原文并不是简单的英雄传奇,水浒写的是社会次序崩溃前的众生相。

想必水浒传的作者有着作弄读者的恶趣味并将此当成一种荒诞的艺术。作者通过好汉的视角来展示这个世界,让故事有种快意恩仇的爽感。一旦脱离好汉们的主角滤镜就会发现好汉们的很多事情十分龌蹉。为了达到作弄读者的目的,作者一面暗中提醒读者好汉们并不完美,一面又通过各种手段让用户来同情并带入角色。

第一章中洪太尉误放了108魔星,这些魔星沉寂多年后才开始作乱。暗中已经说明108将并不是单纯的英雄,魔星作乱实是世风日下社会动荡妖魔丛生。

为了让读者更好的带入好汉,好汉的道德底线是一步步被突破的。开始鲁智深的打抱不平,林冲的被陷害,杨志的作死,再到武松的私刑,宋江的赚人上山。随着角色的带入,读者开始不自觉的将好汉们的恶行合理化。

很多人不喜欢水浒70回后,金圣叹更是认为70回后的剧情应当全部砍掉。不过在我看来,水浒正是有了招安的剧情才完整。留白固然美好,却不如悲剧来的震撼,也避免了作者意图被曲解(参照红楼梦)。

前70回中宋江在刚流落江湖时就已明确提出了有心招安,面对敌将时也多次以招安作为劝降说辞。从心态上说,宋江是必然会将招安作为自己的追求。从客观条件看,梁山的精英大多出于体制,也是因宋江的招安许诺才暂居梁山。如果宋江安心的做山大王,这些人大概率是不满的。好些的情况是因不满而出走,更坏的情况是梁山内乱,将宋江做投名状送与朝廷。

从实力上看,梁山虽然取得了多次胜利,但此时朝廷并未认真对待,且很多胜利过于依赖梁山的地利。如朝廷认真对待,且采取围困策略,梁山是没有机会的。作为对照,方腊是一个有完整行政体制的政权,从军事实力及制度的完备性上都远高于梁山。方腊都败于朝廷,就更别说因义而聚,依靠“借粮”为生的梁山了。

招安看似梁山的众多选择中的一个,实际上是梁山的唯一出路。面对腐败的朝廷,招安后的惨烈也是必然,只是宋江没得选。对宋江而言,招安也算是求仁得仁。

方腊篇可能缺乏爽点,但少了方腊篇的水浒是不完整的。方腊是梁山的平行宇宙,一个正面写,一个反面写。方腊和梁山一体两面,方腊是剥离滤镜后的梁山。梁山杀人放火的事也不少,只是被英雄叙事淹没了。

水浒对于好汉们的结局写的也是非常好。张顺归神,武松断臂,鲁智深圆寂,宋江毒杀李逵,即符合人物性格也应因果。鲁智深性格火爆,闻潮悟道圆寂,得到内心平静。武松断臂,实则是通过断臂还了杀孽,终得善终。李逵最爱的还是他的公明哥哥,即使被毒杀也绝无怨言,可能唯一的遗憾只是公明哥哥没有让他自己选。

如果说招安是梁山的唯一出路,战方腊是水浒的悲剧美学。破辽则是作者对好汉们最大的温柔。只是在我看来破辽的相关篇章写的太过儿戏。从故事完整性看,招安后抗辽,收回丢失的郡县已经足够体面了。现在破辽则有些过于浪漫和繁复,同整体剧情有很强的割裂感。按我的理解原本中可能有少量的抗辽情节,但断不会是我们现在看到的。现有的很多情节大概率是其他作者后加的。即使将破辽篇全部删除也不会对后续剧情产生任何影响,且破辽后没有任何封赏也是离谱。

可能受时代局限性的影响,水浒中的好汉其实并不是普通百姓,他们只是体制内的失意者。这些失意者因为各种原因聚集在了梁山,并力求回归体制。只是乱世中没有救赎,他们中的大多人未能善终。

宋江,虽然出场稍晚,但毫无疑问是水浒里绝对的主角。

有人觉得宋江被这么多人仰慕难以理解。宋江似乎武力不行,钱也不会太多,没什么拿的出手的。实际上宋江是好汉中少有的有脑子的。宋江除了钱外更重要的是能在好汉落难后帮忙出主意,安排去处。宋江是好汉们的及时雨,是周旋于黑白两道的掮客。宋江深谙江湖规则,和底层官场规则。只是宋江的这套知识体系并不适合朝堂,招安后被很快清算。

梁山的好汉们大多抱着“今朝有酒今朝醉”的态度过活。宋江是这群人中少有的具有远见者——他深知梁山泊没有未来。面对誓死抵抗终被朝廷剿灭,与接受招安后被逐步瓦解这两条路,他选择了后者。一条在他看来更为体面的死法。

林冲,少数真正意义上被逼上梁山的好汉。林冲是个身怀一技之长(武力)却胸无大志的普通人。风雪山神庙之所以经典,很大程度上能让普通人产生共情,是退无可退后的情感爆发。

风雪山神庙是林冲的高光,却也将林冲燃尽。林冲表面上很能隐忍,实际上每次隐忍都留下了明显的心理创伤。每次爆发都容易造成无法挽回的后果,非常不可控。林冲杀完王伦,得知妻子死去的那刻起林冲的故事就已经结束。林冲已经失去了人的情感,只有战斗才能让他体会到自己的存在。林冲在火并王伦后就兵器化,少了人的属性。真正的林冲在更早之前就已经死了,死在了风雪山神庙。

利刃本无情,存在的价值只是为人所使。没有人使用的利刃只能逐渐腐朽,对应林冲病逝的结局。

李逵,说好听点是纯真,实则是兽性。李逵一意孤行的要背母上梁山,完全没有考虑大哥甚至母亲的意愿。母亲没有了,李逵的愤怒多于伤心,似乎是丢了玩具的孩子。李逵伤心的不是和母亲的情感联系,是别人有父母自己没有。

误会宋江强抢民女可能不是出于道义。即使宋江明媒正娶,李逵也不会高兴。李逵眼里只有“哥哥”,下意识的认为宋江也只爱李逵,有自己的爱被人分走的愤怒。强抢民女只是李逵的说头。李逵被毒死也并无怨言,可能唯一伤心的是宋江没有让李逵自己喝。

水浒的最后还是回到了忠君叙事,把锅都给谗臣背了。可能是时代局限性,作者找不到解决方案,只能祈求明君。

bye 2025

2026-01-10 17:17:01

2025 AI 技术进一步渗透到世界的方方面面。vibe coding 开始实际被广泛应用。一些前端的改动 AI 已经可以做的很好了,对于简单项目也可以让 AI 完成大部分工作。至于复杂项目,想全部依赖 vibe code 就不太现实了。目前 AI 还在持续进化中,不知道 2026 年 AI 可以进化到什么程度。

2025 年在喜马拉雅上收听了《红楼梦》、《西游记》,《水浒传》还在收听中。第一次发现读原版故事其实是一件有趣的事。在古代识字的人少,小说的阅读有一定的门槛,作者也很喜欢将自己的一些小心思藏在书中。作者的这些小心思经过影视化等途径通俗化后所剩无几。听完《水浒传》后应当还会继续收听《三国演义》,之后就告一段落了。作为一个喜新厌旧的人,需要寻找其他“有趣”的事情了。

py-cggtts 项目简介

2026-01-05 21:05:00

项目地址:https://github.com/vicalloy/py-cggtts/

py-cggtts 是一个为高精度时间传递领域打造的 Python 工具包,它基于 Rust 编写的高性能 CGGTTS 库(GitHub 仓库),提供了对 BIPM CGGTTS 2E 格式文件 的完整解析能力。CGGTTS(Common-View GNSS Time Transfer Standard)是由国际计量局(BIPM)制定的标准格式,广泛应用于全球守时实验室之间通过 GNSS 卫星进行远程原子钟比对。

项目背景

CGGTTS 本身是纯文本结构,解析起来并不困难。不过 Python 性能一般,且已经有了 Rust 的完整实现,于是尝试将 Rust 的 CGGTTS 库导出 Python 接口。目前将 Rust 导入 Python 生态的技术已经成熟,不少 Python 库都通过 Rust 来提升性能。

项目的主要代码都由 AI 完成。对于接口封装这类本身不复杂但又繁琐的工作,在 AI 的加持下变的轻松加愉快了。