Low Gravity

在这里,我们用算法解决问题,用代码表达思想

10 月 31 号晚上,DeepSeek Harness 团队发了篇长文:《Super-agent 设计探索:迈向更自主的 Agent 系统》。

整篇读下来,最戳我的是这句话:Session 应当是系统的实现细节,而不应是用户的认知负担。

文里提到,一个人通常只能同时盯住 3 到 5 个活跃会话。我对照自己日常的状态数了一下,确实差不多——到了第六个窗口,脑子里就会开始出现“我记得有个任务在等 CI,但死活想不起来切去哪个标签页找”的状况。

他们把这叫“瓶颈转移”:单任务的上限取决于模型能力,多任务的上限取决于人的注意力。前半句现在基本是行业共识了,而后半句,正是这套系统想解的题。

阅读全文 »

上个月,我把手上一个 agent 应用里的三个 specialist 删了。

倒不是为了省 token。主要是之前那套 orchestrator 加三个 subagent 的结构太折腾人:每加一个功能,我得同时改四个地方——路由的分类规则、subagent 自己的 prompt、主 agent 的 prompt,还有交接时的字段约定。

删完之后,跑了一遍回归测试。任务完成率没掉,端到端延迟差不多砍半。当然,这只是我自己粗看的结果,没做严格的 A/B。

刚好 10 月 22 号 Anthropic 的 Applied AI 团队发了一篇 Building agents: When to fold subagents into your main agent loop。看完挺有共鸣:原来大家都在往回退,而且他们拿严肃的测试数据把背后的账算清楚了。

阅读全文 »

前两天读了一篇文章,标题叫《我不得不把才华埋葬在昨天》。

刚看到标题时,我以为又是那种“AI 会不会取代程序员”的陈词滥调。这两年类似的话题实在太多了,多到让人审美疲劳:程序员还能干几年、哪些岗位最危险、以后是不是只剩调遣 Agent 的人。

耐着性子往下读,才发现味道不太一样。作者就在 DeepSeek 写算子,而且亲手参与了核心 Attention 算子的实现。

他不是站在岸上看潮水涨起来的人,他是那个正在挖渠引水的人。更让人五味杂陈的是,他自己能清晰地感觉到:手头正在写的代码,正在帮 AI 更快地学会怎么取代自己。

阅读全文 »

前几天,DeepSeek v4.1 发布了,将小模型能力的高度又向上推进了一个档次。

AI 发展的速度远远超过了所有人的预期。从那个只会咿呀学语地聊天、上下文长度只有几千 token 的初版 ChatGPT,到具有推理能力的 OpenAI o1、DeepSeek R1 与 Kimi K1.5 Thinking,只不过短短两年;从推理模型到如今能够流畅地在各类 harness 工具中执行命令、完成复杂任务的智能体,也不过一年半。很难想象,倘若再等上一年、两年、三年,彼时的 AI 会成为什么样子,会有多么强大,会不会已经具备了自我进化的能力,并深度渗透进了具身智能等领域。

阅读全文 »

Anchr 最开始只有一条传统的 RAG 链路:用户提问,系统搜出相关内容并重新排序,挑前几个片段塞给模型,最后生成带引用的回答。

1
用户提问 → 检索 → 重排 → 构造上下文 → 生成回答

应付大多数事实型问题,这条链路足够了。比如问“文档重新解析后,旧索引怎么处理”,只要知识库里有说明,搜一次基本就能拿到核心材料,剩下的就是让模型整理成通顺的话。

但有些问题没法这么干:

找出几份设计文档里所有与任务恢复有关的内容,再比较进程重启、网络断开和主动取消三种情况下分别会发生什么。

这种问题很难靠现成的几个片段拼出答案。第一次搜索可能只翻出 Agent 运行恢复的说明;顺着读下去,才发现还牵扯到异步任务(Task);掉头去查 Task,又冒出进程内状态和持久化状态的区别。等最后去核对部署约束时,你对“恢复”这两个字的理解,早就和第一轮搜索时不一样了。

下一步搜什么,完全取决于上一步读到了什么。Anchr 的 Agent RAG 就是为了解决这种问题做出来的。

阅读全文 »

最开始做 Anchr,我想解决的问题很具体:手里的文档越攒越多,怎么才能把里面的信息重新捞出来、真正用起来?

文件夹目录只能解决“文件存在哪”,系统自带的全文搜索又要求我必须记得原文用过哪些词。资料少的时候还能凑合;资料一多,常态就变成了:我明明记得某份文档聊过这事,但早忘了文件名,也想不起当时具体是怎么表述的。

所以 Anchr 是从文档搜索切入的。等搜索基本能用了,我才在检索结果之上接了生成回答;再往后,发现单次检索根本应付不了跨文档的复杂排查,这才顺理成章长出了 Agent。

虽然功能模块的名字一路从 Search 变成 RAG、再变成 Agent,但底下干的始终是同一件苦力活:把原始文档稳定地拆解成模型能用、用户又能随时跳回原文核对的证据。

阅读全文 »

刚认识 INTJ 时,多数人会觉得他们挺好相处。

说话留余地,做事有章法,遇到突发状况也很少慌乱。分内的事不推诿,不懂的领域不乱接话,不管对方是什么头衔,态度都差不太多。虽然算不上热情,但让人觉得踏实、好沟通。

可处久了,不少人会撞上一堵无形的墙:客气还是那么客气,距离却一点没近。

你们可以聊工作、拆解具体问题,他甚至会给你非常诚恳的建议,但你很难真正走近他的私人生活。这种疏离不是因为闹了别扭,也不是对你有意见,他只是从来不觉得“认识久了,关系就该自动升级”。

摸清 INTJ,大概要先从这一点开始:礼貌是他给所有人的体面,亲近则是另一套严苛的筛选。

阅读全文 »

如果只记得一张图的大致内容,却忘了文件名,怎么把它找出来?我做 PicIndex,最初就是为了解决这个问题。

思路其实不复杂:用多模态 Embedding 把图片和文字映射到同一个向量空间。这样搜“赛博朋克风格的雨夜街道”或者“坐在窗边的猫”,系统就能顺着画面语义找出相似的图。

Demo 跑通得很快,但真当成工具用起来,毛病就全冒出来了:图里的订单号搜不准、几兆的原图调一次模型慢得离谱、同一个热词每次搜都要重新算一遍向量。

折腾了一圈之后我发现,这些问题最后都没靠“换个更强的模型”来解决。PicIndex 后来真正管用的改动,几乎全发生在模型之外的工程链路里。

阅读全文 »

这世上有如此多的“流行语”和“最佳实践”,但是让我们把注意力转向更基础的方面。即——开发人员在浏览代码时所感受到的“困惑程度”。

困惑是以时间和金钱为代价的。困惑是由高认知负荷造成的。这不是什么花哨的抽象概念,而是一种人类的基本限制因素。

由于我们花在阅读和理解代码上的时间远远多于编写代码的时间,所以我们应该不断地问自己,我们是否在代码中嵌入了过多会给人带来认知负荷的内容。

阅读全文 »

很长一段时间里,我都被一个问题困扰:为什么明明知道学习很重要,也有挺想实现的目标,可真坐下来开始学了,还是忍不住拖延、走神,很难坚持超过三天?

以前我总觉得是自己不够自律,或者吃不了苦。后来翻了一些认知科学和心理学的书,才算跟自己和解了。学习的回报周期太长,今天背的单词、看的源码,可能要几个月甚至一两年后才听得见响动;但刷短视频、打把游戏或者点份夜宵,爽感是秒到的。把这两样东西摆在一起,大脑本能地扑向眼前的甜头,再正常不过了。

想明白这一点之后,我就不再琢磨“怎么逼自己一把”了,而是换了个问题:学习非得靠痛苦和咬牙硬撑吗?能不能把这套流程改一改,让它顺应一点人性,变得更容易坚持?

下面这些,就是我这几年不断拿自己做实验、一点点攒下来的经验。

阅读全文 »
0%