关于AIGC人工智能、思维方式、知识拓展，能力提升等。投稿/合作： @inside1024_bot
AIGC 领域的最新工具、开源项目以及行业大事件
AIGC 领域的最新工具、开源项目以及行业大事件
2019年我刚加入Scale时，Linear的联合创始人Tuomas——我在Uber的前同事，也是Linear的CTO——给我发了一封邮件。他先是恭喜我加入Scale，然后提到难怪最近在Uber没碰到我，接着介绍了他做的新app Linear，问我要不要试用。我们很快安排了demo，虽然Scale成为Linear的客户是后来的事。
后来我回国创业期间，LinkedIn上有一段时间大家都在讨论：一个公司是否必须进行疯狂扩张才能成功。Linear团队分享了他们的经验——公司可以不用疯狂扩张，专注做好产品也能成为优秀的公司。当时我们在Uber共同的leader Ganesh（他后来转做VC）comment说：Linear找到了很好的发展路径，但在竞争残酷且赢家通吃的市场中，很难实现这种高效增长方式。
事实证明，Linear团队的扩张确实很克制，但业务增长表现相当出色。我一直在使用Linear，也向我advise的公司推荐。相比传统的Jira、Asana、Trello等工具，Linear的用户友好度高出很多。可以明显看出，这是一家认真做产品、做工程、听用户反馈的公司，通过效率而非资源投入来打造更好的产品。
上周Linear宣布了新一轮融资。在此之前他们只融过两轮，这次由在AI领域斩获颇丰的Accel领投，融资后Linear成为独角兽。观察最新的各种工具——AI Coding工具如Devin, Claude Code等——会发现它们官方文档公开支持的任务管理工具通常只有一到两家：如果只有一家，那就是Linear；如果有两家，就是Linear和Jira。
2019年Linear刚起步时还没有大语言模型，很难想象AI Agent会为任务管理系统创造颠覆性机会。按照现在很多方法论去分析，几个人的创业公司在任务管理领域挑战Jira这样的百亿美元市值巨头，结论必定是不可能成功。但今天我们已经看到Linear超越Jira的可能性，而这种可能性源于对产品效率的追求、对工程设计的taste、扩张上的克制，以及对工程效率的极致提升。
我认为这正是很多做软件的人缺乏的信念。大家做软件时，要么觉得必须大干快上，要么觉得只能赚点小钱。我希望看到越来越多像Linear这样的成功案例。
后来我回国创业期间，LinkedIn上有一段时间大家都在讨论：一个公司是否必须进行疯狂扩张才能成功。Linear团队分享了他们的经验——公司可以不用疯狂扩张，专注做好产品也能成为优秀的公司。当时我们在Uber共同的leader Ganesh（他后来转做VC）comment说：Linear找到了很好的发展路径，但在竞争残酷且赢家通吃的市场中，很难实现这种高效增长方式。
事实证明，Linear团队的扩张确实很克制，但业务增长表现相当出色。我一直在使用Linear，也向我advise的公司推荐。相比传统的Jira、Asana、Trello等工具，Linear的用户友好度高出很多。可以明显看出，这是一家认真做产品、做工程、听用户反馈的公司，通过效率而非资源投入来打造更好的产品。
上周Linear宣布了新一轮融资。在此之前他们只融过两轮，这次由在AI领域斩获颇丰的Accel领投，融资后Linear成为独角兽。观察最新的各种工具——AI Coding工具如Devin, Claude Code等——会发现它们官方文档公开支持的任务管理工具通常只有一到两家：如果只有一家，那就是Linear；如果有两家，就是Linear和Jira。
2019年Linear刚起步时还没有大语言模型，很难想象AI Agent会为任务管理系统创造颠覆性机会。按照现在很多方法论去分析，几个人的创业公司在任务管理领域挑战Jira这样的百亿美元市值巨头，结论必定是不可能成功。但今天我们已经看到Linear超越Jira的可能性，而这种可能性源于对产品效率的追求、对工程设计的taste、扩张上的克制，以及对工程效率的极致提升。
我认为这正是很多做软件的人缺乏的信念。大家做软件时，要么觉得必须大干快上，要么觉得只能赚点小钱。我希望看到越来越多像Linear这样的成功案例。
今天很有趣，两家知名的公司各出了一篇文章，争论要不要使用多智能体系统。
Claude 的官方 Anthropic ：如何构建多智能体系统
Devin 的官方 Cognition ：不要构建多智能体系统
这核心的争议点在于：Context 上下文到底应该共享还是分开？
Claude 这边的观点是，搜索信息的本质是压缩，单个智能体的上下文有限，面对无限的信息，压缩比太大就会失真。
这就好比一个老板能力再强，也不可能搞定所有的事情，还是需要雇人去解决。
通过多智能体系统，老板让不同的智能体分别研究、汇报重点，老板最后整合到一起。由于每个智能体有自己的专长，具有多样性，减少了单一路径依赖现象，实际效果上，多智能体也超过但智能体 90%。
这是集体智慧，一起协作获得的胜利。
Devin 这边的观点是，多个智能体的上下文不一致，会导致信息割裂、误解、他们汇报给老板的信息经常充满了矛盾。
而且很多时候，智能体的每一步行动都是依赖前一个步骤产生的结果，而多智能体通常分别跟老板沟通，互相之间缺乏沟通，这样很容易导致互相矛盾的结果。
这体现出了个体智慧的完整性和高效性。
两边观点看下来，是否使用多智能体架构，特别像是人类运行一家公司的选择。
一人公司还是多人公司？
一人公司，一个人的脑力、体力、时间都是非常有限的。
优点是一人公司的沟通成本为0 ，可以把所有的时间都高效使用。
而多人公司，人越多，沟通成本就越高，管理难度就越大，总体效率下降。
但因为人数多，脑力多，体力多，整体的价值产出也就有可能更多。
多智能体的设计很有难度，这其实很正常，就像运行一家公司一样，很难。
难就难在建立有效协作的系统。
而且 1个人，3个人，10个人，100人，1000人，所需要的协作系统又不大相同。
参考人类历史，依靠集体智慧，人类在近代获得了文明的指数级发展。
多智能体的集体智慧，也许就是在 Scaling Law 逐渐放缓后，AI 获得指数级发展的那个萌芽。
而关于上下文，人类的协作至今也无法做到完美的上下文管理。
这让我想到，软件工程从来不是追求完美，而是持续迭代。
Claude 的官方 Anthropic ：如何构建多智能体系统
Devin 的官方 Cognition ：不要构建多智能体系统
这核心的争议点在于：Context 上下文到底应该共享还是分开？
Claude 这边的观点是，搜索信息的本质是压缩，单个智能体的上下文有限，面对无限的信息，压缩比太大就会失真。
这就好比一个老板能力再强，也不可能搞定所有的事情，还是需要雇人去解决。
通过多智能体系统，老板让不同的智能体分别研究、汇报重点，老板最后整合到一起。由于每个智能体有自己的专长，具有多样性，减少了单一路径依赖现象，实际效果上，多智能体也超过但智能体 90%。
这是集体智慧，一起协作获得的胜利。
Devin 这边的观点是，多个智能体的上下文不一致，会导致信息割裂、误解、他们汇报给老板的信息经常充满了矛盾。
而且很多时候，智能体的每一步行动都是依赖前一个步骤产生的结果，而多智能体通常分别跟老板沟通，互相之间缺乏沟通，这样很容易导致互相矛盾的结果。
这体现出了个体智慧的完整性和高效性。
两边观点看下来，是否使用多智能体架构，特别像是人类运行一家公司的选择。
一人公司还是多人公司？
一人公司，一个人的脑力、体力、时间都是非常有限的。
优点是一人公司的沟通成本为0 ，可以把所有的时间都高效使用。
而多人公司，人越多，沟通成本就越高，管理难度就越大，总体效率下降。
但因为人数多，脑力多，体力多，整体的价值产出也就有可能更多。
多智能体的设计很有难度，这其实很正常，就像运行一家公司一样，很难。
难就难在建立有效协作的系统。
而且 1个人，3个人，10个人，100人，1000人，所需要的协作系统又不大相同。
参考人类历史，依靠集体智慧，人类在近代获得了文明的指数级发展。
多智能体的集体智慧，也许就是在 Scaling Law 逐渐放缓后，AI 获得指数级发展的那个萌芽。
而关于上下文，人类的协作至今也无法做到完美的上下文管理。
这让我想到，软件工程从来不是追求完美，而是持续迭代。
