Lindy Teammate: Flo Crivello on Multiplayer Agents, Memory & Why He'd Ban the Chinese Models He Uses

Lindy 发布 AI 员工 Lindy Teammate，直接嵌入 Slack，用 DeepSeek 模型，靠“记忆代理”自动整理团队上下文，缓存命中率 85%，错误率一周降 8 倍。

用着 DeepSeek，他却想禁掉它

Flo Crivello 是 Lindy 创始人兼 CEO。Lindy 最早像一套更聪明的 Zapier 自动化工具，如今则把自己定义成进入 Slack 的 AI 员工 Lindy Teammate：它连上团队工具，读取共享信息，也在后台维护记忆。Flo 亲自拆开了这类产品最棘手的几层结构：Slack 历史怎么变成可用上下文，数百万 token 怎么不把账单烧穿，员工又该怎样规定“哪些事你不许记”。更有意思的是，这位公司默认大量使用 DeepSeek 的 CEO，同时主张限制中国前沿模型。

这期回答了 7 个问题：

1. 为什么 AI 员工的关键不再是模型智力，而是团队上下文？
2. 把 Slack、会议和文档都交给 AI 后，哪些历史信息不该被“记住”？
3. 为什么 Flo 认为静态 RAG 不如一个会持续整理记忆的代理？
4. 面对数百万乃至数十亿 token，AI 如何既记得住又付得起？
5. AI 让代码产量暴涨后，工程团队真正的新瓶颈是什么？
6. 当模型又强又会犯低级错误，人类到底该在哪个环节介入？
7. 为何一家默认使用 DeepSeek 的公司 CEO，主张美国禁用中国前沿模型？

被问到 Lindy 为什么一边大规模使用低价开源模型，一边又公开支持限制中国模型时，Flo 没有回避这层矛盾。他说，Lindy 当时几乎“全是 DeepSeek”：默认主力是 DeepSeek，用户若想要更强的能力，也能在设置里改选 Sonnet 或 Opus。原因很实际：DeepSeek Flash 足够便宜，适合大量运行代理；他甚至把它形容为接近免费。可他同时说："I have something against Chinese frontier models whether they're open or closed source."（我反对的是中国前沿模型，无论它们是开源还是闭源。）

他的反对点不只是“开源模型会不会泄露权重”。第一，是竞争路径。他认为中国模型可能通过蒸馏前沿模型获得不对称优势：美国公司花数十亿训练出模型，后来者以更低成本从模型输出中复现能力，等于绕过了原始研发账单。第二，是模型行为受中国政府审查与政策约束。一个会拒绝谈特定历史事件、又能接入美国企业工作流的代理，在他看来不只是聊天产品，更可能成为宣传和经济影响的入口。

这意味着，模型选型不再只有“能力、速度、单价”三列。采购团队还得问：模型来自谁、由谁托管、谁能影响它的行为、出了问题谁负责。低成本模型于是成了合规和地缘政治决策的一部分。不过主持人提出了另一条路：不必一刀切禁用，而是审计模型内部风险，再要求服务商按风险购买保险。Flo 接受这条折中路径。真正的分歧，不是“风险是否存在”，而是该由禁令、审计还是保险来给风险定价。

被问到多人模式的 AI 怎样不只是每个人各自打开的聊天窗口，而能成为 Slack 里的团队成员时，Flo 抛出了一个有力的比喻：把 John von Neumann 这样的历史级天才突然放进办公室，他在第一个小时、甚至第一天，可能还不如熟悉公司情况的普通同事有用。不是因为他不聪明，而是他不知道谁在推进什么项目、某个客户刚抱怨了什么、哪个决定已经被推翻。Flo 的结论很直白："intelligence actually matters less and less comparatively speaking and context matters more and more."（相较而言，智力的重要性越来越低，而上下文的重要性越来越高。）

传统入职很依赖 wiki、Notion、Confluence 和书面流程，但书面文档有个老毛病：写完的那一刻就开始过期。真正活着的公司知识散落在 Slack 对话、会议、临时决策和同事间的来回确认里。Lindy Teammate 因此不是一个等人提问的个人助理，而是接入 Slack、工具和全团队共享上下文的“团队脚手架”。Flo 把单人 AI 与多人 AI 的差别，比作邮件互传修订文档和 Google Docs 协作编辑的差别：前者人人各拿一份副本，后者才真正围绕同一份事实工作。

这意味着，当基础模型能力逐渐接近，企业 AI 的壁垒会转向组织语境：它能否读懂公司的习惯、历史和暗线，能否持续跟上变化。反面也很明显。上下文越全，越可能碰到私人频道、旧私信和个人判断。让 AI 成为“最懂公司的人”，同时也会让它成为最需要被约束的人。

被问到 Slack 里满是日志、重复消息和边缘案例时，系统怎么避免把噪声郑重其事地写进企业知识库，Flo 的答案不是做一次更好的搜索，而是让一个专门的记忆代理长期工作。Lindy 的 memory agent 大约每 15 分钟运行一次。他把这种状态叫作“napping not sleeping”——不是每天睡一觉再更新，而是不断短暂打盹、醒来、整理新信息。"the memory is maintained by an agent itself."（记忆本身是由一个代理来维护的。）

这个代理第一次爬取 Slack 时，会遇到许多日志频道：构建日志、系统通知、重复状态更新。Flo 说，代理会逐渐学会忽略它们，因为其中没有可供组织学习的内容。这不是预先给每个频道贴死标签，而是代理通过持续接触信息，形成一层“什么可信、什么常用、什么无意义”的元记忆。会议在这里也被升格成一等对象。被放进公开会议文件夹的会议，会持续被摘要，并写入团队记忆；于是员工可以追问：最近客户最常提的需求是什么？大家对某项功能的反馈怎样？

这意味着，企业知识库会从“把材料存进去，需要时搜索”的静态仓库，变成一名持续归档的馆员。它不仅回答问题，还会观察问题被问了多少次、哪些材料反复被调用，再调整记忆结构。Flo 对 RAG——也就是“先检索相关文本，再让模型生成答案”的做法越来越悲观，原因就在这里：一次检索不会自己变聪明。不过他没有说 RAG 应被彻底废弃。Lindy 仍保留部分 RAG，只是不再把它当作记忆系统的中心。

被问到历史私信、八卦或某个人对同事的私人判断被写入长期记忆后，怎样不违背当事人的原始预期时，Flo 讲了 Lindy 团队内部的一场争论。一派认为两层就够：团队公开记忆，以及仅供个人使用的私密记忆。另一派认为不够。即便是“我的私密层”，也不该把所有内容混在一起；有些内容可以让私人助理知道，却不能让任何可能代理自己行动的系统随手调用。

最后，团队没有把所有情形都做成复杂的权限面板，而是让用户直接修改自己的 meta memory prompt。它是 Lindy 文件系统中的一个文本文件，每次记忆代理运行时都会被注入上下文。用户可以写下："this is what I never want you to remember"（这些是我永远不希望你记住的内容。） 也可以规定，敏感话题只许存在某个文件夹；除非满足 X、Y、Z 条件，否则不得读取。

Flo 自己展示过两个文件：真实的 memory.md，以及为播客演示准备、删去敏感内容的 memory2.md。他还专门在真实记忆里标注：另一个文件只是演示用途，不应当被混用。这意味着，未来的隐私管理不只是管理员配置“谁能看哪个频道”，还会变成员工给 AI 编写可读、可改、可审阅的记忆政策。边界在于，自然语言规则依赖模型遵守指令；规则写得越灵活，也越需要用户理解自己到底授权了什么。Flo 起初觉得多层“记忆泡泡”过度设计，但团队成员的真实顾虑，逼着产品保留了更细的控制空间。

被问到 Lindy 自己变成 AI 员工后，公司内部工作发生了什么变化，Flo 给出了一组很具体的数字：过去三个月，团队每周的 PR——也就是代码变更合并请求——数量增长了三倍；每个 PR 的代码行数也增长了三倍。代码产量上来后，人不再逐个检查每份代码，而是转去检查“检查代码的系统”是否可靠。Flo 用一句话概括："we're just reviewing the machine that reviews the PRs."（我们只是在审查那台审查 PR 的机器。）

最先吃不消的是 CI，即持续集成流程。它负责在代码合并前跑测试、验证构建、部署产品。以前，CI 慢一点、贵一点，工程师还可以手工忍着；当 PR 数和代码量一起翻三倍，CI 就会变成堵在流水线出口的收费站。Lindy 团队一开始也按旧习惯处理：花了数周人工调 GCP runner、构建缓存和 GitHub 相关配置。后来他们才反应过来，既然 Lindy 已经有代码库、GCP 和 GitHub 的访问权限，为什么不让它分析并优化 CI？

现在，Lindy 会检查 runner、构建和成本数据，每天自动生成图表，汇报 CI 成本是否下降、从提交到合并的时间是否缩短。这意味着，AI 提高写代码速度后，工程团队的核心工作不再是增加“写的人”，而是设计、评估和治理自动化生产线。测试覆盖率、权限、发布策略、异常回滚都会先承压。这里的反面很朴素：技术瓶颈并不总在模型。人类沿用旧流程的惯性，足以让团队先白花几周时间，再想起把任务交给代理。

被问到假如公司最后只剩 Flo 一个人，其余都是 Lindy 代理，哪些岗位还非人不可时，他没有回答“战略”或“创意”。他先描述了当下模型最令人头疼的特性：spiky，尖锐且不均匀。它能一次生成 5 万行代码，也能独立工作数小时，把复杂构想推进成结果；但它同样可能一天 50 次决定“走去洗车场”。强大和荒唐不再是两个阶段，而是同一个系统里的两种输出。

Flo 把这种组织比作 Iron Man suit，钢铁侠战衣。企业不是简单地把任务分成“机器做”与“人做”，而是在一个多维任务空间里不断画线：哪些事情可全自动，哪些必须复核，哪些只在触发条件出现时升级给人。真正难处不在于让 AI 少打扰人，而在于让 AI 知道何时必须打扰人。正如他说的："you need the AI to know when it needs to bug you. And almost definitionally it can't"（你需要 AI 知道自己什么时候该来打扰你；但几乎从定义上说，它做不到。）

这句话的逻辑是：如果 AI 真知道自己会犯错，它理论上就能避开或修正；正因为它不知道盲区，才会在错误发生前保持自信。于是，人类的角色不一定是比机器写得更快、记得更多，而是替系统识别“这里不能信它”。这意味着，评价人机协作不能只看自动化率，还要看升级决策的校准度：该提醒时有没有提醒，不该惊动人时会不会制造噪声。Flo 承认，这条介入边界目前没有稳定答案，它仍是 AI 组织最难解的设计题。

被问到 Lindy 最好的想法究竟来自人还是 AI，以及“AI 加人永远优于纯 AI”是否成立时，Flo 先承认现实：现在的好点子确实常由人机共同产出。团队会在 Slack 直接问 Lindy 的意见，也会让它听完整场会议后再发消息给出判断。处理 CI 的案例就是来回讨论的结果：Lindy 最初给出的方案合理，但没吃透工程约束；工程师补充条件，系统再调整，最后才形成可执行方案。

但 Flo 不接受把这一阶段包装成永久规律。他援引国际象棋和其他已被 AI 超越的游戏：最初是 AI 胜过人；随后出现一段“AI 加人”优于 AI 的时期；再往后，人的干预优势缩小，甚至变成负数。于是他说："humans are introducing at best like random noise into the system."（人类充其量是在给系统引入随机噪声。） 他把当前称作 centaur phase，即“半人马阶段”：人和机器组合暂时更强，但这不保证人会永远是必要部件。

这意味着，今天围绕人机共创设计的会议、审批和岗位，可能不是终局，而是模型能力尚不稳定时的过渡架构。企业长期要面对的不是“要不要用 AI”，而是当代理在更多任务上变得稳定后，人类从生产者转成监督者、再转成例外处理者时，谁来定义例外、谁来承担后果。反面同样不能忽略：Flo 没有否认当前人机讨论的价值。人还在填模型的洞，尤其是在模型会突然犯低级错误的阶段；争议只在于，这种填洞是否会永远存在。

“AI 员工的上限不由智力决定，而由它是否拥有团队上下文”和“企业记忆不会靠一次检索变聪明，必须由代理持续整理”，说的其实是同一件事：模型不是接上 Slack 就自动变成员工。它得知道团队正在做什么，哪些信息已经失效，哪些会议才是最新事实，哪些日志只是噪声。否则，再强的模型也只是一个没有入职过的天才访客。

而“多人记忆的隐私边界，可以靠用户可编辑的自然语言规则收紧”与“人类的最后岗位不是做得更强，而是替尖锐模型拦下它不知道的蠢错”，又指向系统的另一面：AI 拿到的信息越多、权限越大，越不能只靠“它应该会做对”来管理。谁能访问什么，什么情况下必须停下来问人，出了错由谁接手，这些都要被写进系统。

所以，AI 员工真正的难题不是换一个更强、或更便宜的模型。它是把组织上下文、动态记忆、隐私规则、推理成本和人工介入，编排成一套每天都能运行的机制。对正在把 AI 接进自己工作流的人来说，最该先问的或许不是“它能替我做什么”，而是：它依据哪些事实做事，哪些事实不该碰，以及当它自信地走向“洗车场”时，谁有权让它停下。