即刻App年轻人的同好社区
下载
App内打开
李继刚
96关注25k被关注45夸夸
读书人
置顶
李继刚
4月前
把 skills 整理了下, 大家可以用用看:

github.com
28145
李继刚
1天前
解释力:压缩过去已见
预测力:泛化将来未见
02
李继刚
1天前
一个交互设计问题:

在手机端和模型聊天,输入一个问题,它输出一大段回答,并直接滚动到了结尾处。

为了阅读它的回答,需要不断上滑,找到起始处。

这里的交互,是不是可以改为直接定位到起始处?

“一个用户省去上滑的 3s,1000 万个用户省去了多少时间?”
112
李继刚
1天前
“老登”经历多,遇事时,容易触发“经验预测”:“这事我遇到过,是这样子的”。

年轻人经历少,遇事时,没有经验匹配上,只能去观察、提炼、抽象、假设、建模,在摸索和反馈中试错、修正,使用“模型预测”。

世界多变,模型预测的泛化能力,优于经验预测。

经验最好的用法,是帮助我们提出更好的假设,而不是让我们免于检验。
13
李继刚
1天前
人讲事,大致有两种方式。

一种像播音主持,内容是主角,人是载体。

人服务于内容,负责把事情讲准确、讲清楚。听众主要在乎说了什么;只要内容不变、表达得当,换一个人来讲,也没有太大区别。

另一种像山头旗帜,人是主角,内容是由头。

听众未必是对这件事有多大兴趣,而是想听这个人怎么想、怎么说。话题可以变化,真正吸引人的,是他的眼光、性情,以及他面对世界的姿态。

甚至,有时候并不需要什么新观点。听他讲几件小事,说几句闲话,就已经足够。因为听众在意的,不只是“我听到了什么”,还有“此刻,是这个人在对我说话”。

前者,以人为媒介,抵达内容;
后者,以内容为媒介,接近一个人。
21
李继刚
1天前
于建国的《学习观》,是最近半年读到的最惊艳的一本书。

我大脑中“学习”这个概念的压缩包,基本就是这本书的内容了。
48
李继刚
3天前
「增一减二」:每增加一个 x,就同步强制减少两个同类的 x。

x 可以是你的微信好友,可以一个关注账号,可以是一本书,可以是家里添加的新物件,任何事情。

这个原则,可以不断逼近我们内心真实“价值函数”,到底最重要的是什么。
102
李继刚
3天前

艾逗笔: 做协作类 agent 的关键点之一是,如何把多个不同能力的 agent 拉到同一个群组,让他们在无人干预的状态下,自主分工,协作完成复杂的任务。 要实现无监督自主运行,需要保证群组的整体可用性。比如一个群里面有 claude、codex、gemini、grok、openclaw、harmes 等 10 余个 agent,晚上睡觉前往群聊丢个任务:帮我写个对标 codex 的桌面 agent,明早起来验收。 要完成这个任务,首先需要有个任务协调者,也可以叫做 leader,由这个角色来负责理解任务,拆解任务,分配工作给群里的其他 agent。leader 自身可以不参与具体的工作,但是需要监控其他成员的工作状态,适当干预、调配工作。比如 claude 做 leader,让 codex、gemini、harmes 等成员分工去写代码,并要求他们每五分钟报告一次任务进度。期间 gemini 因为模型限额罢工了,leader 需要把罢工 agent 没干完的活分给其他空闲 agent 接着干。 协作类 agent 产品的设计难点和重点一定是群组的整体可用性建设问题。 多 agent 协作过程容易遇到的问题包括: 1. 某个成员 agent 因为模型限额或封禁、工具调用异常、网络等问题导致罢工 2. leader 不靠谱,分配任务不合理,成员 agent 之间容易干重复或者冲突 3. leader 自己挂了,缺了协调者,其他 agent 干完一轮不能继续干下去 4. 其他外部依赖异常(比如定时任务)导致整体进度没有往前推进 要通过 agent 协作实现全自动无人值守干活(比如建个群,让群里的 agent 每天晚上自己干 8 小时,去找到一些热点需求,做出产品,推给目标用户,让用户付费,实现产品商业闭环,人类群主躺着赚钱),需要一些关键的设计来保证群组的可用性: 1. 冗余机制。群内的 agent 成员,在条件允许下尽可能多配置,同类型的 agent 互为备份,按能力等级分组排序,比如 claude、codex 为一组,gemini、grok 为一组,kimi、zhipu 为一组,openclaw、harmes 为一组 2. 协调与监控。先指定一个 leader,比如 claude,由 leader 来理解任务、拆解任务、分配任务。发到群里的任务,leader 首先处理,从 agent 分组中按能力组合选择部分 agent 作为 worker 来执行任务。leader 需要定时查看群内的 agent 进度,如果发现某些 agent 进度异常或超时无响应,就从备份 agent 中挑选替换者,来接替异常 agent 继续完成任务 3. 进度上报。作为 worker 的 agent 需要定时把自己的任务进度上报到群组,方便 leader 和其他成员感知任务进度。 4. leader 选举。leader 跟所有的 worker 之间保持定时心跳,在 leader 挂了的情况下触发选举或由底层程序指定新的 leader,由新 leader 继续组织工作 5. 恢复机制和结果一致性。agent 协作过程中肯定会遇到各种异常问题,需要设置很多个 checkpoint(检查点),任务状态和依赖关系需要明确,支持断点恢复和幂等重入。继任的 worker 需要延续前任 worker 的工作进度继续推进,最终需要通过测试和验收来确认结果,不能只依赖 agent 自己报告完成 --- 最近在做协作类agent 产品,感觉分布式系统的可用性架构设计理论有很多可以参考的思路,我在 termany.sh 里面也实现了很多的策略,目标还是要把本地的多个 agent 聚合在一起,在无人值守模式下实现自主协作,共同完成复杂任务。 欢迎试用与交流。👇 https://termany.sh

00
李继刚
4天前
Nagel: 论荒谬
21
李继刚
4天前
Frankfurt: 论胡扯
00
李继刚
4天前
Russell: 论闲暇
42