文章来源微信公众号：郎瀚威Will
写在前面：我看到了一个巨大的生产力爆发
前两篇文章我写了两个判断：第一篇从用户视角梳理了龙虾生态的创业分层，部署派、工作台派、进化派各有各的逻辑；第二篇在看了大量案例以后做了一个推演，认为agent的正确形态应该嵌入在你日常使用的通讯软件里，独立App走不远。
这两篇发出去以后，我看到了一些令我吃惊的场景：有人已经在团队层面跑龙虾了，而且爆发出了惊人的生产力。这个生产力爆发的程度，远远超过了我在前两篇文章里的预期。
我之所以这么关注，有两个原因。
第一个原因是技术推演。在写前两篇的时候，我就判断agent的下一步一定是从单兵走向团队协同——多窗口、大总管、统一记忆、主动汇报，这些我都写过了。但当时更多是逻辑推演，我还没有看到真正跑通的案例。
第二个原因是我真的接触到了。过去三周我密集接触了几个正在做team方向的团队。大家的做法有轻有重，具体技术方案涉及商业机密我就不展开了。但他们给我展示的一些案例，说实话，对我的冲击非常大，不光是那种"哇AI又能干什么了"的兴奋，是一种"原来人类有这么多局限性"的震撼。看完以后的第一反应是：我好希望自己也能第一时间用上，没用上就浑身痒痒，非常FOMO。
这种感受是我写这篇文章的最大驱动力。当你亲眼看到一个agent在接入了公司数据以后，做出了人类团队两三个月都没搭出来的决策体系，你会意识到，team agent已经能用了，而且效果远超预期。
只是大部分人没办法调通这些东西。
我接触到的这些跑通了team agent的团队，大多数本身就是做agent的，或者有丰富的多平台踩坑经验，各种API接过、权限配过、坑都踩过一遍。对他们来说，接入整个流程是丝滑的。但普通团队不具备这个条件。现在这些平台的坑特别多，很多人在某一步就断了，可能是飞书的机器人权限配不明白，可能是Notion的API授权找不到入口，可能是接入的模型不够好导致输出质量上不去，可能是跨平台数据同步出了问题。断了以后就放弃了，永远体验不到team agent真正的威力。
这篇文章想聊的就是这件事：当龙虾从单兵进入team，到底需要什么样的基础设施？市面上有哪些技术路线在竞争？以及——为什么我认为飞书是这一轮里最大的赢家。
一、团队agent到底比个人agent强在哪
先回答一个最基础的问题：team agent的增量到底是什么？为什么不是"个人agent的放大版"？
个人用龙虾，你能做的事情是有上限的。你让它帮你写邮件、查资料、整理笔记，它干得不错，但本质上还是你一个人在用一个更聪明的工具。你的信息就是它的信息，你的瓶颈就是它的瓶颈。
团队场景下，增量来自三个地方。
第一，多个agent可以协同完成一条完整的任务链。一个agent负责从群聊里抓取需求，另一个去知识库里查历史方案，第三个去数据库里拉数据做分析，第四个把结果整理成报告推送给相关的人。这条链路如果靠一个人指挥一个agent来做，你得一步一步下指令；但在team场景下，agent之间可以自己串联，人只需要在关键节点做判断。
第二，agent能主动发现问题。个人场景下agent是被动的，你问它才答。团队场景下，agent在持续监控业务数据，它可以主动发现异常（比如某个指标突然下跌、某个客户很久没联系了、某个流程卡了太久），然后主动通知相关的人。这在个人场景下做不到，因为你没有给它足够的数据和上下文去"看全局"。
第三，agent之间可以互相校验。一个agent做了一个决策，另一个agent可以从不同角度审核，发现逻辑漏洞或者遗漏的信息。这比一个人对着一个agent反复确认要高效得多，也更不容易出错。
这三个增量叠加在一起，team agent的产出质量和效率会远超个人agent。但前提是你得把基础设施搭好。
二、团队场景的三个"接入"
我仔细观察了一下，发现这些团队的共同点是做到了三个"接入"。第一，团队聊天接入，agent直接参与团队的日常沟通，在群里就能接收任务和反馈。第二，知识库和数据层接入，会议记录、数据库、业务的订单流和信息流，这些全部喂给了agent。第三，外部工具接入，自媒体账号、邮件、CRM这些业务系统的权限全部打通。三个层面都接上了，agent就会爆发出惊人的力量。少接任何一层，出来的都是残次品。
这也解释了为什么大多数个人用户感受不到龙虾的真正威力，因为你给AI接入的数据太少了。你跟它聊两句，让它帮你写个邮件，它当然表现平平。AI没有办法通过零星的几句对话来理解你到底想要什么。但业务场景完全不一样，业务目标是极其明确的：赚钱、优化某个指标、联系某些人、完成某个流程。当你把业务数据喂给agent以后，它完全能get到你要干什么，因为业务逻辑是清晰的、可量化的、有明确反馈的。这就是为什么团队场景下agent的表现会远超个人场景。
三、从个人到团队，问题升级了
先说清楚"team场景"和"个人场景"到底差在哪。
个人场景下，你跟agent的关系是一对一或者一对多——你是唯一的"老板"，所有agent听你一个人的。记忆是围绕你个人的，权限问题也简单，因为所有数据都是你自己的。
团队场景下，这些假设全部不成立。
第一，多个人在跟多个agent交互。你告诉agent的信息，你同事可能也需要知道。但不是所有信息你都想让同事看到——有些是你的个人判断，有些涉及敏感数据。所以agent的记忆不能是一个大筐，它需要分层：哪些是个人的，哪些是团队共享的，哪些是部门级的，哪些是全公司的。
第二，agent需要理解"组织"。个人场景下agent只需要理解你一个人的目标和偏好。团队场景下它需要理解公司的目标、现在处于什么阶段、各部门在干什么、谁负责什么。这些信息不是你手动告诉它的，是它需要从公司的各种系统里自己去理解的。
我接触的一个团队做了一个让我印象很深的实验：他们把agent接入了公司内部的多个数据源，然后让agent帮他们做一个内部管理系统。结果agent产出的东西远远超出了预期——它不只是完成了任务本身，而是在理解了公司当前的阶段和目标之后，自主设计了一套完全定制化的策略方案，颗粒度细到他们自己都没想过的程度。
这个团队的创始人跟我说，这些策略是他们之前花了很长时间都没搭出来的。策略本身不复杂，难的是人要做这件事需要先理解全局，把散落在各个系统里的信息串起来，然后才能做判断。而agent在被接入了足够的数据源之后，"理解全局"这件事几乎是瞬间完成的。
第三，身份和权限。个人用龙虾，你就是你自己，没有身份问题。团队用龙虾，agent需要有一个"身份"——它是谁？它有权访问什么？它代表谁在行动？
这不是一个技术细节，这是一个根本性的问题。现在Manus这类产品最大的限制之一就是agent没有稳定的身份。它登录某个SaaS的时候，要么用临时邮箱（经常被拦），要么需要用户手动授权每一个平台。这导致agent的覆盖范围被严重限制了。
我接触的几个团队都在尝试解决这个问题，有些已经做出了让我非常意外的效果。但具体方案涉及商业机密，这里就不展开了。
我能说的是：agent的能力边界应该取决于"agent能不能像人一样操作数字世界"，而不是"平台开不开放API"。谁先解决了agent在数字世界里的"身份"问题，谁就能让agent的覆盖范围上一个量级。
这三个变化（组织级记忆、全局理解能力、稳定身份）叠加在一起，就是team场景跟个人场景的根本差异。任何想做team方向的产品，都必须同时解决这三个问题。
四、现有软件不是为AI时代设计的
在展开讲各种技术路线之前，我想先说一个越来越清晰的认知：我们现在用的绝大多数软件，都不是为AI时代设计的。
这话听起来像废话，但它的含义比表面上深很多。
拿Slack举例。Slack是一个通讯软件，设计初衷是让人和人之间高效沟通。它的消息格式、频道结构、权限体系、搜索机制——所有这些都是围绕"人阅读、人操作"来设计的。当你把一个AI agent塞进Slack，你会发现大量的摩擦：
agent发的消息太长，刷屏了人的对话；agent的回复格式跟人的聊天风格不匹配，看起来很突兀；agent需要展示一个多步计算过程，但Slack的消息格式撑不住这个信息量——你总不能让agent发20条消息来展示一个分析吧？agent需要主动推送信息，但Slack的通知机制是为人设计的，agent的推送和人的消息混在一起，用户分不清优先级。
Notion也一样。Notion是一个很好的知识库，但它是给人管理信息用的。当agent需要频繁读写Notion的时候，你会发现Notion的API限速很紧、授权流程藏在深处、数据结构对AI不够友好——它的页面是为人浏览设计的，不是为AI解析设计的。
这个问题在团队场景下被放大了。个人用户可以忍受这些摩擦——反正就自己一个人，将就用就行了。但团队场景下，多个人、多个agent在同一个系统里交互，摩擦会指数级增长。
我跟好几个创业者聊到这个话题，他们的共识是：现有IM加上去做AI，上限很低。能用，但你做到某个点就会碰壁，比如agent在群聊里没办法做丰富的交互展示，比如agent的推送和人的消息混在一起导致信息过载，比如多个agent之间在群里协作时上下文传递的效率很差。
这些问题不是靠"优化"能解决的，因为底层架构就不是为这个场景设计的。就像你不能在一匹马身上装个发动机——你需要一辆车。
这就引出了市面上正在竞争的几种技术路线。
五、四种技术路线，四种赌注
围绕"龙虾+team"这个需求，我观察到四种截然不同的技术方案。每一种都在赌一个不同的假设。
在展开讲之前，说一个我觉得挺重要的观察：最近我陆续聊了5到10家做这个赛道的公司，大多数还在潜行状态，少量已经开始宣发。一个有意思的现象是，当我跟某个创业者说"还有其他人也在做"的时候，对方通常比较惊讶。我也希望通过这篇文章传达一个认知：做team agent方向的团队，比你想象的多。这个认知本身没什么复杂的，只是因为我接触的创业者比较多，大家彼此之间还不知道对方的存在。不要觉得市面上做这个东西的人很少，timing还是很重要的。也不用怕别人抄，因为你不出来别人照样在做这个方向，最终拼的还是底层认知和执行力。你可能在某一个点上做得比别人好一点，这就是你的壁垒。另外我建议创业者还是尽早找有认知的投资人聊，如果对方聊完没有反馈，其实也在帮你省时间。
方案A：Slack + Notion——海外的默认组合
这是目前海外团队最常见的搭配。Slack做通讯，Notion做知识库，中间靠API把龙虾接进去。
这个方案的最大优势是用户基数。Slack和Notion在海外的渗透率非常高，尤其是科技公司和创业团队。用户不需要迁移，在现有工具里就能开始用。
问题也很明显：三个系统之间的打通全靠API对接，每个平台的权限体系不一样，接入成本高。我之前写过自己的体验——接入Notion得去后台开授权，功能藏在设置深处，对非技术用户来说光找到入口就是一道坎。这还只是接入一个平台，如果你要同时接Slack、Notion、Google Calendar、Gmail，每个平台都要走一遍这个流程。
更深层的问题是：Slack和Notion是两个独立的系统，它们之间的数据不互通。agent在Slack里收到的信息，不会自动出现在Notion里。你需要手动或者通过第三方工具做同步——又多了一个需要维护的链路。
对于简单的团队场景（比如接入几个工具、自动处理一些日常任务），Slack + Notion够用了。但如果你想让agent真正理解团队的上下文、做出有深度的决策，这个方案的天花板是有限的。
方案B：Telegram / Discord / WhatsApp + 外部数据源——个人和小团队的灵活方案
这是我在之前文章里重点分析过的方案。agent住在Telegram里，通过API或者browser use去连接各种外部工具和数据源——Obsidian、Notion、Google Sheets等等。
这个方案在个人场景和小团队场景下非常灵活——Telegram的bot API足够开放，生态也够丰富。但进入正式的团队场景，问题就来了：
Telegram不是一个企业级工具。它没有组织架构的概念，没有部门和权限分层，没有跟企业数据库天然打通的能力。你可以把它当成一个"个人级的team方案"，但它很难承载一个30人、50人的公司的日常工作流。
Discord类似——社区属性强，企业属性弱。WhatsApp更不用说，连bot生态都还在早期。
所以这个方案更适合的定位是：个人创业者和小团队的灵活选择，但不是企业级team方案的终局。
方案C：自建通讯软件（如Teamily AI、Slock等）——最重也最有想象力的路线
这是我接触的几个团队正在走的路。比如Teamily AI从零打造AI原生的IM，Slock也在走类似的方向，还有若干团队还在隐身阶段不方便透露。他们的逻辑很简单：既然现有IM不是为AI设计的，那就从零开始造一个。
这条路的天花板是最高的。因为你可以把agent的交互方式设计成原生的——不需要在已有IM的限制里做patch，而是从底层就考虑AI agent的需求。我接触过走这条路的团队，他们展示的交互体验确实比在现有IM上做改造要流畅很多，很多在Slack或飞书里"做不到"或者"体验很糟糕"的事，在原生设计的IM里是自然而然的。
但这条路的代价也是最大的：开发周期以年计，团队需要够大，用户迁移成本极高。你造了一个再好的IM，如果用户已经在飞书或Slack里，他凭什么迁过来？
而且这条路对创业者的要求也是最高的。你得懂基础设施，也得懂社交产品；得会优化memory架构来控制成本，也得能设计原生的通讯方案；得知道怎么用不同的agent去优化token消耗，也得能把浏览器、爬虫这些能力全部跑通；得能无缝接入各种skills生态，也得能设计好企业级的权限管理体系。这几乎要求创始团队同时具备infra工程能力和社交产品sense，缺一边都很难做出来。
所以走这条路的团队，赌的不是"我的IM比飞书好用"——他们赌的是"AI时代的通讯软件需要完全不同的底层架构，而已有IM改不过来"。这个赌注是否成立，目前还不确定。但如果成立，回报也是最大的。
破局之法在哪？我个人的判断是：创始人必须亲自下场，一个场景一个场景地攻克，快速占领市场。这条路没有捷径，不可能靠一个通用方案打天下，得用场景的密度和速度换时间窗口。谁能在大厂反应过来之前，把足够多的垂直场景跑通、把用户黏住，才有一线生机。
方案D：飞书——不小心成了最优解？（限国内）
终于说到这篇文章的核心判断了。
我越看越觉得，飞书可能是龙虾team场景里最大的隐形赢家——而且它可能自己都还没完全意识到这一点。
为什么？因为飞书恰好同时满足了team场景的三个核心需求，而且这些能力并非刻意为AI设计，是它在过去几年的产品迭代中"无心插柳"积累出来的。
第一，飞书是目前唯一把"通讯+文档+数据库+审批+日历"全部做在一个平台里的产品。
这句话的含义需要拆开来看。Slack是通讯，Notion是文档和知识库，Airtable是数据库，Google Calendar是日历——海外团队用这套组合需要四个独立系统。飞书把这四件事做在了一个App里。
对人来说，这不只是"少装几个软件、少切换几个窗口"的问题——现实是大多数人根本不会去装那么多软件，链路一长就放弃了。但对agent来说，这意味着一件根本性的事：agent在一个系统里就能获得完整的上下文。
它在群聊里收到一个任务→它可以直接去知识库里查相关文档→它可以在多维表格里查数据→它可以看日历判断时间冲突→它可以发消息给相关的人确认——整个过程不需要跨平台，不需要多套API，不需要处理不同系统之间的权限和数据同步问题。
这对于agent理解"组织"来说太关键了。前面说过，team场景下agent需要理解公司的全局。"全局"意味着它需要同时看到通讯记录、文档、数据和日程——如果这些东西散落在四个不同的系统里，agent要做"全局理解"就得先做"全局整合"，这本身就是一个巨大的工程。飞书天然帮你省掉了这一步。
第二，飞书的多维表格是一个被严重低估的数据库。
很多人把飞书的多维表格当成"高级Excel"来用，但它其实是一个结构化的关系型数据库。它支持多种字段类型、视图切换、公式计算、自动化规则——关键是它跟飞书的其他模块是打通的。
对agent来说，多维表格是最友好的数据存储方式之一。相比Notion的page结构（对AI来说解析成本更高），多维表格的行列结构天然适合AI读写。agent可以把收集到的信息结构化地存进表格，也可以从表格里高效地检索数据。
更重要的是，这个数据库不是一个外部服务，它就在飞书里面。agent不需要通过API去调一个外部数据库，它直接在同一个系统内就能完成数据的存取。这在延迟、稳定性和权限管理上都有优势。
第三，权限体系统一。
这是一个经常被忽略但极其重要的点。
在Slack + Notion + Airtable的方案里，每个系统有自己的权限体系。你在Slack里有权看某个频道，不代表你在Notion里有权看对应的文档。这意味着agent如果要跨系统工作，它需要在每个系统里都有独立的授权——而且这些授权之间没有联动。
飞书的权限是统一的。你在飞书里属于哪个部门、有什么角色、能看到什么数据——这套权限贯穿通讯、文档、表格、审批所有模块。对agent来说，它只需要被授权一次，就能在飞书的整个生态里工作。这大幅降低了团队部署agent的管理成本。
把这三点加在一起：一体化的信息环境 + 原生的结构化数据库 + 统一的权限体系。这恰好是team场景下agent需要的三个核心基础设施。飞书不是为AI设计的，但它在这三件事上的积累，恰好让它成了当前最适合跑团队agent的平台。
打个比方，飞书就像一个闭关修炼30年的武林高手，且用天材地宝滋养自己，出关一看，发现自己练的功夫恰好是必杀绝技，且内力深厚。我只能绝望地看着它即将血洗市场，寸草不生。但会不会有年轻俊杰出来挑战？我也拭目以待。
六、飞书的问题
说完优势，必须说说飞书的问题。不说问题就不客观。
第一个问题：机器人接入体验目前还是挺糟糕的。
我自己就是因为"想想那个流程就头疼"所以一直没接飞书。飞书的开放平台虽然功能很全，但操作路径太长，创建应用、配置权限、获取凭证、处理事件回调，每一步都有门槛。对于已经习惯了Telegram的bot API那种"几行代码就能跑"的开发者来说，飞书的接入体验是劝退级别的。
这个问题是可以解决的。飞书如果出一个"一键把龙虾接入飞书"的方案（类似于现在各大云厂商做的一键部署），它在龙虾生态里的地位会立刻上一个台阶。这个需求已经很明确了，只是不知道飞书的产品团队有没有意识到这个机会的紧迫性。
第二个问题：Lark在海外的存在感很弱。
飞书在国内增长很快，但它的国际版Lark在海外几乎没有什么市场份额。海外团队用Slack+Notion的组合已经很成熟了，没有动力迁移到Lark。这意味着飞书的优势主要局限在中国市场——当然中国市场本身已经足够大了。
第三个问题：飞书的AI交互还不够原生。
虽然飞书的一体化架构对agent很友好，但飞书本身的AI功能目前还停留在"辅助工具"的阶段，智能摘要、智能翻译、智能搜索这些。它还没有把agent交互作为一等公民来设计。比如agent在群聊里的展示方式、agent之间的调度机制、agent的主动推送和通知分级，这些在飞书里还没有原生的支持。
换句话说，飞书有最好的基础，但上面这层"AI原生交互"还需要有人来建。问题是，这个"人"会是创业者，还是飞书自己？这个问题我在后面会展开讲。
不过，也有团队选择了更激进的路线：不等飞书，直接从零打造为AI设计的通讯平台。前面提到的Teamily AI、Slock以及其他几个还在隐身的团队就在走这条路。这些团队赌的是飞书的底层架构终究是为人设计的，patch再多也改不了骨子里的东西。这个赌注是否成立还不确定，但他们的存在本身就说明了一件事：市场已经出现了对"AI原生IM"的真实需求，只是大部分人还在等飞书先动。
七、其他玩家的位置
说完飞书，快速扫一下其他几个重要的玩家。
钉钉：用的人多，但在数据库和开放生态上不如飞书。钉钉的优势在于下沉市场和中小企业，但龙虾的team场景目前主要是被科技公司和创业团队在推——这恰好是飞书的主场。钉钉的多维表格功能上线较晚，成熟度不如飞书的多维表格。所以在"龙虾+team"这个特定赛道上，钉钉目前不是最优解。
微信：永远接不进去。微信的封闭性决定了它不可能成为agent的载体。你可以在微信里聊龙虾，但你没法把龙虾接入微信。而且微信和腾讯文档/腾讯表格之间的割裂是结构性的——它们是不同的产品团队在做，数据和权限不互通。agent需要跨系统工作的时候，这个割裂就是致命的。
企业微信：理论上可以，但企业微信的开放程度远不如飞书，而且它和微信本体之间的关系很微妙——很多功能受限于微信的策略，不是企业微信自己能决定的。
海外方面：
Slack：通讯层最成熟，但没有自带的数据库。Slack + Notion的组合能跑，但天然割裂。Slack被Salesforce收购以后，未来可能会跟Salesforce的数据平台做深度整合——如果这件事发生了，Slack在企业agent场景里的竞争力会大幅提升。但现在还没发生。
Telegram / Discord：更适合个人和社区场景，不是企业级team方案的选项。
Microsoft Teams + Office 365：一体化程度其实不亚于飞书。Teams做通讯，SharePoint做文档，Dataverse做数据库，Outlook做邮件日历。但微软的产品太重了，接入体验跟飞书比更复杂。而且微软自己在推Copilot，大概率不会把agent的生态开放给第三方，它想自己吃掉这个市场。所以对创业者来说，微软生态不是一个友好的平台。
Google Workspace：Google其实是有机会的。Gmail、Google Docs、Google Sheets、Google Calendar，这也是一套一体化的体系，而且全球用户基数巨大。Google在推Gemini，如果它把Gemini的agent能力深度整合进Workspace，竞争力会很强。主要的短板在通讯层，大多数团队的日常沟通发生在Slack或者其他工具里，Google Chat的存在感太弱了。通讯软件这一环的缺失，可能让Google Workspace在team agent场景里差那么一口气。但如果Google补上这块，它在海外的地位可能不亚于飞书在国内的地位。
所以总结一下各平台的定位：
中国市场，我审视了一圈，不得不很无奈地说，飞书是当前最优解。无奈是因为我自己每次调飞书的机器人权限都非常挠头——但这不改变一个事实：在"通讯+文档+数据库+权限统一"这个组合上，国内目前没有比飞书更完整的选手。一体化架构 + 结构化数据库 + 统一权限，恰好满足team agent的核心需求。主要风险是飞书的机器人接入体验需要大幅优化，以及飞书自己的AI战略会不会跟第三方agent冲突。
海外市场，Slack + Notion是当前的默认组合，但天花板有限。如果Slack和Salesforce做深度整合，或者Notion推出更强的API支持，这个组合的竞争力会提升。
自建IM是最有想象力但最重的路线。赌的是"AI时代需要完全不同的通讯基础设施"——如果这个判断对了，赢家通吃；如果错了，几年的投入可能白费。
八、对创业者的判断：国内让给大厂，海外才是战场
基于以上分析，我对龙虾team场景的创业判断做一个比较大的修正。
在前两篇文章里，我列了不少"创业者可以做的方向"。但在深度接触了几个做team方向的团队、看清了大厂的反应速度之后，我的判断变了：国内team agent赛道的通用层，大厂会在3-6个月内基本覆盖掉。创业者在国内做飞书中间件、做agent调度层、做组织记忆管理——这些方向的窗口期可能只有几个月，然后飞书/钉钉的官方方案就会出来把你替代。
所以如果你想在team agent赛道创业，我分析下来的结论是：出海似乎是唯一的选择。
海外方向一：跨平台的agent调度和记忆层
这是海外市场最大的结构性机会。海外没有飞书这样的一体化平台，Slack+Notion+Gmail+Calendar的碎片化组合天然需要一个"整合者"。而且这个整合者不会是Slack自己（它不想帮你连Notion），也不会是Notion自己（它不想帮你连Slack）。创业者做的就是填这个缝。
海外方向二：围绕Slack生态做深度场景
虽然Slack本身有天花板，但它在海外科技公司的渗透率极高。如果你不做"通用的Slack agent工具"（这个Slack自己会做），而是做"Slack里的投研agent""Slack里的电商运营agent"这种垂直场景——Slack官方不会做这么细的事。
海外方向三：垂直场景的team agent方案
围绕海外某个具体场景（SaaS销售、跨境电商、投研、开发者团队协作）做一套完整的团队agent工作流。海外大厂做的是自己平台内的通用AI，不会深入到具体行业的工作流里。创业者如果能在某个场景里积累足够深的理解和用户数据，就能建立起大厂难以替代的壁垒。
海外方向四：自建AI原生IM，直接替代碎片化工具链
这就是前面方案C在海外的打法。海外没有飞书这样的一体化平台，Slack+Notion+Gmail的组合用起来够用但天然割裂。如果有人能从零造一个为AI设计的通讯平台，把通讯、知识库、数据库、agent调度全部做在一起，等于在海外市场造一个"AI原生的飞书"。Teamily AI、Slock以及其他几个隐身团队就在走这条路。这条路最重、门槛最高，但如果跑通了，天花板也最高，因为你在海外填的是一个飞书都没填的空缺。
国内方向：如果你一定要做国内
如果你一定要在国内做team agent，我的建议是不要做通用层，而是做大厂不愿意做的脏活累活——比如某个细分行业的完整工作流（财务审计、跨境电商、MCN运营），或者帮企业做"agent安全合规"的咨询和实施服务。这些方向的天花板不高，但大厂确实懒得做。
一个清醒的认识：这一轮team agent创业，大部分人会死。方向没错，但大厂的反应速度比过去任何一次都快，龙虾的热度太高了，所有人都看到了，留给创业者的时间差在急剧缩短。
九、【Opus 4.6 分析】Team Agent赛道的中期推演
以下内容为 Opus 4.6 基于公开信息、行业逻辑及作者提供的判断框架的独立推演，不代表作者观点，仅供参考。
短期（1-3个月）：大厂会跟，而且会很快
龙虾在过去两个月的爆发速度，已经不是任何大厂可以忽略的了。GitHub第二大开源项目、全球科技媒体连续报道、中国五大云厂商同时推一键部署。更能说明问题的是国内AI公司的跟进速度：KimiClaw、ManusClaw、MiniMaxClaw、SkyClaw、EasyClaw，几乎所有主流玩家都在第一时间推出了自己的龙虾方案。这个跟进速度本身就说明了龙虾的信号强度，飞书、钉钉、Slack内部一定已经在讨论"我们怎么接龙虾"这个问题。
作者的判断是飞书3个月内会有动作。Opus 4.6认为这个判断大概率是对的。原因不复杂：龙虾的火爆直接关联到飞书的核心利益——如果用户发现"在飞书里跑agent"的体验比"在Telegram里跑agent"好很多，这就是飞书最强的获客钩子；反过来，如果飞书不跟，用户可能会把工作流迁移到Telegram或者某个自建IM上，这是飞书不能接受的。
字节本身的AI战略也在加速。火山引擎已经推了龙虾安全方案，豆包大模型在快速迭代，飞书智能伙伴已经有了agent化的雏形。把这些能力整合到飞书的agent接入方案里，对字节来说就是把已有的积木拼起来。3个月可能紧张，但出一个MVP级别的方案是有可能的。
钉钉和企业微信也不会闲着。虽然在数据库和开放生态上不如飞书，但它们各自有自己的存量用户——钉钉的中小企业用户、企业微信的传统行业用户。它们大概率会推出自己的agent接入方案，即使体验不如飞书，也能吃到各自的基本盘。
海外方面，Slack被Salesforce收购后，有可能把Salesforce的数据平台和Slack的通讯能力做深度整合，形成一个"Slack + Salesforce Data Cloud"的一体化team agent方案。这比Slack + Notion的松散组合要强得多。如果这件事发生，Slack在海外企业agent市场的地位会大幅提升。
中期（3-6个月）：创业者的窗口期可能比想象中更短
这是这篇推演中最需要泼冷水的部分。
作者在访谈中获得的一个关键信号是：这一波创业者最担心的其实是"今天做的明天就过时了"。这个恐惧指向的是一个更残酷的现实：在team agent这个赛道上，创业者的生存空间可能非常小。
原因是这样的：team agent的核心基础设施（通讯层、数据层、权限层）全部掌握在大厂手里。飞书拥有通讯+文档+数据库+权限的一体化架构，Slack背后是Salesforce，Teams背后是微软，钉钉背后是阿里。创业者在这些平台上做"中间件"，就是在大厂的地盘上做生意。
历史经验告诉我们这类生意的结局通常不好。当平台方意识到某个中间件产品做得好的时候，它的第一反应就是"我自己做一个"。微信小程序生态里无数创业者的命运就是前车之鉴。
更麻烦的是，team agent的技术迭代速度太快了。你今天做了一个"飞书agent调度层"，用了三个月打磨到好用，结果飞书官方出了一个原生方案，体验比你好（因为它能调用你调不了的底层接口），价格比你便宜（因为它不需要额外收费），你三个月的投入就归零了。
这跟之前文章里分析快速部署派的逻辑是一样的——"当官方方案和大厂方案足够好用时，独立产品需要思考差异化。"只不过在team场景下，这个"被官方吃掉"的概率更高，因为team场景直接关联到大厂的核心业务（企业协作），不像个人场景那样"大厂懒得做"。
那创业者还有机会吗？
说了这么多悲观的话，结论其实指向一个方向：海外。
国内市场的team agent赛道，大概率会被大厂吃掉。飞书做通讯+数据库+agent的一体化方案，钉钉跟进自己的版本，企业微信也不会闲着。创业者在这些平台上做中间件，就是在给大厂打工——打磨得再好，平台方一个原生方案就能替代你。国内创业者如果非要做team agent，最后大概率是被大厂收编或者挤死。
但海外不一样。
海外的企业协作工具链是碎片化的。Slack做通讯、Notion做文档、Airtable做数据库、Google Calendar做日程、Gmail做邮件。没有任何一个平台像飞书一样把这些全部做在一起。这意味着海外的team agent需求天然需要一个"跨平台的整合层"，而这个整合层不会由任何一个现有平台来做，Slack不会帮你对接Notion，Notion也不会帮你对接Gmail。
这就是创业者的机会。
而且海外大厂虽然也在做AI（微软有Copilot，Google有Gemini，Salesforce有Einstein），但它们做的是"自己平台内"的AI，不是"跨平台"的agent协同。微软不会帮你把Teams里的agent连到Slack，Google也不会帮你把Gemini的能力接入Notion。
所以海外team agent赛道的创业机会在于：做一个不绑定任何单一平台的agent调度和记忆层——不管你用Slack还是Teams还是Discord，不管你数据在Notion还是Airtable还是Google Sheets，我都能让你的agent团队跨平台协同工作。
这条路的难度很高——你需要同时理解多个平台的API和权限体系，你需要做好跨平台的数据同步和记忆管理，你需要处理不同系统之间的安全和合规。但正因为难，大厂不太愿意做（各家都想把用户锁在自己的生态里），这才是创业者的空间。
回到前面的分析框架：国内飞书是赢家，但赢家是飞书自己，不是在飞书上做中间件的创业者。创业者的真正战场在海外，在那个没有"飞书"存在的碎片化市场里。
中长期（6-12个月）：还是早期，但格局开始分化
作者的判断是12个月后"还是早期，大部分人还在摸索"。Opus 4.6同意这个判断，但想做一个更具体的推演：
12个月后的team agent市场可能呈现三层结构：
最底层是平台层——飞书、Slack/Salesforce、钉钉各自有了原生的agent接入方案，覆盖了80%的通用需求。这一层的赢家就是这些大厂本身。
中间层是场景层，在每个垂直场景（自媒体、电商、投研、财务等），有一两家创业公司跑通了完整的team agent工作流，积累了用户的组织记忆和场景数据。这些公司的壁垒来自对行业的理解深度和用户的迁移成本，技术本身反倒不是核心。但大部分试图做垂直场景的创业者会在这12个月里死掉，要么是因为选错了场景，要么是因为技术迭代让他们的方案过时了，要么纯粹是因为烧不起钱。
最上层是生态层——OpenClaw基金会、skills社区、进化网络（比如第二篇提到的EvoMap）。这一层的价值在于它是跨平台的，不依赖任何一个大厂。但这一层的商业化路径最不清晰。
一个值得持续关注的变量：大模型能力本身的进化速度。如果接下来半年大模型在"理解组织""长期记忆""多agent协调"这些能力上有大的突破，那现在创业者在做的很多"中间件"工作可能会变成大模型的原生能力——你花三个月做的"组织记忆管理系统"，可能被下一代模型的context window直接替代了。这是这个赛道最大的系统性风险，也是创业者说"今天做的明天就过时了"的根本原因。
最后一个推演：中国和海外会走出不同路径。中国因为飞书的一体化优势，可能更快进入"平台+垂直"的格局。海外因为工具链的碎片化，可能先出现一个"跨平台agent调度层"的中间件产品，然后再逐渐分化出垂直场景。但两边面临的核心问题是一样的：在大厂能力快速追赶的环境下，创业者能跑出多大的领先优势？
十、我的整体判断
龙虾从个人场景进入team场景，是一次质变。team场景需要组织级记忆、全局理解能力、稳定的agent身份，这三样东西目前都还在很早期，但方向已经非常清晰了。
现有的通讯软件和协作工具绝大多数不是为AI时代设计的，在上面做agent交互会碰壁，这也是自建IM路线存在的根本原因。
在现有平台中，飞书"无心插柳"积累出的一体化架构恰好满足了team agent的核心需求，是国内当前的最优解。但飞书是赢家，不代表在飞书上做中间件的创业者也是赢家，龙虾的热度太高了，大厂不可能不跟，国内通用层会被快速覆盖。
我分析下来，创业者的结构性机会在海外，因为海外工具链天然碎片化，大厂各自为政，留出了"跨平台整合者"的空间。
这一轮team agent创业大部分人会死，能活下来的，要么在海外找到了碎片化市场的机会，要么在某个垂直场景里积累了大厂懒得做的深度。选对战场比选对方向更重要。
写在最后
两个月前龙虾刚火的时候，大家讨论的还是"怎么装""用什么skill"这些个人级的话题。现在讨论已经快速转向了"怎么在团队里用""怎么让多个agent协同工作"——这个转变的速度比我预期的要快。
我接触的那几个团队给我的最大感受是：team agent不是"个人agent的放大版"，它是一个全新的物种。它需要理解组织、需要稳定的身份、需要分层的记忆——这些东西在个人场景下可以将就，在team场景下必须解决。
飞书"不小心"在这三件事上都有积累，处在一个非常有趣的位置。但这个"赢家"的果实，大概率是飞书自己摘，不是创业者帮它摘。
对于正在这个领域创业的朋友，我最诚恳的建议是：看清楚你的战场在哪里。如果你在国内做通用层，你在跟飞书、钉钉赛跑，大概率跑不过。如果你在海外做跨平台整合，你面对的是一个碎片化的市场，大厂各自为政，反而给你留了空间。选对战场比选对方向更重要。
最后一个问题留给读者：你的团队现在在用什么工具跑agent？是Slack+Notion，飞书，还是其他方案？遇到了什么具体的问题？欢迎在评论区聊聊。
十条Takeaway
1、团队agent的威力远超个人agent，但大部分人体验不到，因为接入链路太长、坑太多，普通人在某一步就断了。
2、团队场景要跑通，必须同时接入三层：团队聊天、知识库/数据层、外部业务工具。少一层就是残次品。
3、个人用户觉得龙虾"也就那样"，核心原因是喂给AI的数据太少。业务场景目标明确，数据充足，agent的表现会质变。
4、现有的通讯软件和协作工具（Slack、Notion、钉钉、微信）都不是为AI时代设计的，在上面做agent交互会碰壁。
5、飞书是目前唯一把通讯+文档+数据库+权限做在一个平台里的产品，"无心插柳"成了team agent的最优基础设施。
6、飞书的短板同样明显：机器人接入体验劝退、Lark海外存在感弱、AI交互还没做到原生级别。
7、国内team agent的通用层，大厂大概率3-6个月内覆盖掉。创业者在飞书/钉钉上做中间件，窗口期极短。
8、创业者的结构性机会在海外。海外工具链碎片化（Slack+Notion+Gmail+Calendar），天然需要一个"跨平台整合者"，大厂各自为政不会做这件事。
9、Google Workspace是海外值得关注的变量。如果Google补上通讯层的短板，它的一体化程度可以对标飞书。
10、这一轮team agent创业，大部分人会死。能活下来的要么在海外找到了碎片化市场的机会，要么在某个垂直场景里积累了大厂懒得做的深度。选对战场比选对方向更重要。
