作者：王林Lincoln | MindsLeap创始人 | Founders Space合伙人 | 企业家AI俱乐部创始人
"它确实充满前景，但最终还是没跑通——它在我们面前炸开了。"
在 2026 年 Interrupt 大会上，monday.com 的团队负责人 Omri 站在台上，毫不掩饰地复盘了他们的失败。Sidekick V2 是他们的第二代 AI 智能助手，采用了多智能体架构，每个业务领域都有自己的 MCP 服务和专属工具，引擎里塞进了超过两百个工具。结果呢？上下文污染让大模型陷入混乱，成本直线上升，各个团队的需求互相打架。
这不是一个遥远的实验室故事。monday.com 是一家服务全球企业的 AI 工作平台，他们的判断直接决定了数百万用户的日常体验。而他们踩过的坑，正在成为今天所有想构建企业级 AI 系统的公司的共同课题。
从"管理工作"到"替你工作"
monday.com 的野心在过去一年发生了一个根本性转变。过去，他们帮企业用看板管理工作——帮你找到销售线索，帮你把候选人信息录入系统。现在，他们的 SDR 智能体可以直接给潜在客户打电话推销产品，招聘智能体可以自己去 LinkedIn 上筛选候选人并发送邮件。
用 Omri 的话说："我们为什么要替你管理工作？干脆替你做完算了。"
这不是产品功能的叠加，而是产品形态的重定义。当 AI 从记录系统变成执行系统，企业的业务流程、组织架构和人岗匹配方式都会被重新洗牌。但对于 monday.com 自己来说，第一步要解决的，是让他们的 AI 助手足够可靠，而不是在关键时刻掉链子。
两百个工具为什么反而成了灾难
Sidekick V2 的思路在直觉上完全合理：每个产品线——CRM、客服、营销——都有自己的术语和场景，那就给每个领域配专属工具和提示词。但实际运行下来，一个引擎承载两百多个工具，无限扩张的上下文让模型不知所措。
Omri 描述得很直白："上下文污染，模型被搞糊涂了，成本飙升。每个领域都有不同需求。"
这在企业经营上对应一个经典误区：当你看到多个细分需求时，第一反应往往是做更多专门的东西。但 AI 系统的复杂度和工具数量之间的关系不是线性的——工具越多，模型做选择的噪音就越大，出错的概率呈指数级增长。
他们做了一个在当时看起来很反直觉的决定：整个架构不要了，从头重写。
一个聪明的指挥者，胜过一群忙碌的执行者
重写的方向只有一个词：Deep Agent。
monday.com 的选择逻辑很简单——与其让数百个专业智能体互相喊话制造混乱，不如培养一个高度集中的大脑。Omri 说："我们想要一个聪明的编排者，而不是混乱的蜂群。"
这个判断背后的信念是：今天的模型已经足够聪明，可以把规划、记忆管理和子智能体调度这些硬活儿交给模型自己处理。你需要做的不是帮模型想清楚每一步怎么走，而是确保它不会在起步阶段就被过多选项淹没。
这也是为什么 progressive disclosure——渐进式信息暴露——成了他们架构的核心原则。不要一次性把所有东西扔给模型，让它在需要的时候自己去发现。
三层工具发现：按需供给的工程智慧
具体怎么做？monday.com 设计了一个三层工具分类系统。
第一层是基础工具，覆盖大约百分之五六十的常见用例——网页搜索、图像生成、知识库检索，这些永远对模型可见。第二层是上下文工具，只暴露与你当前所在领域相关的功能：如果你在看 CRM 的文档，你就只看到 CRM 的工具，看不到营销模块的东西。第三层最巧妙——延迟加载工具。所有剩余的工具以大约二十个字的简短描述放在目录里，模型需要时才激活调用。
这意味着模型在绝大多数时间里只面对少量清晰的选项，而不是被两百个工具名称淹没。
Omri 还透露了下一步计划：把这些工具描述全部放入语义数据库，用语义搜索替代简单的列表匹配。工具发现从"翻菜单"变成了"问问题"。
写代码的智能体，取代了所有专门工具
整场演讲中最让人意外的一个设计是：与其为每一个可能的用例建造专门的工具，不如让智能体自己写代码。
monday.com 给 Sidekick 配备了一个可以在沙箱里运行 Python 代码的能力。他们用的是 LangChain 的沙箱环境，安全隔离，即写即跑。效果是什么？"一个安全的沙箱，可以替代几百个工具。"
Omri 举了一个真实例子：有用户想找伦敦的新办公室，要求从大本钟出发在特定时段驾车不超过二十分钟。Sidekick 调用 Google API 和地图服务，自己写了一套算法来筛选符合条件的房源。这种事在没有代码能力的情况下，需要单独开发一个完整的工具链。
当智能体获得编写和执行代码的能力，它的行为边界就从预定义的操作扩展到了任意可计算的逻辑。对企业而言，这意味着你不需要预判用户的所有需求——你只需要提供一个安全的执行环境和足够的上下文。
能自我修复的系统，才配进入企业
企业级产品和消费级产品最大的区别在于：失败的成本太高。Omri 给出的数字是百分之九十四的自愈成功率。
他们是怎么做到的？不是追求模型永远不出错，而是设计了一套疗愈中间件。当智能体卡住了，系统会识别出来并切换到其他模型；当内存溢出，系统会自动扩容资源。用 Omri 的话说："真实的企业工作流不应该频繁失败。"
这是一种完全不同的工程哲学：接受大模型会犯错这个前提，然后在系统层面设计容错和自愈能力，而不是试图在模型层面消灭所有幻觉。
判断与边界
monday.com 的探索给了几个清晰的信号。工具发现比工具堆叠更重要，渐进式暴露是解决上下文污染的核心思路。代码执行能力正在成为智能体的标配基础设施，而不是某个产品的差异化功能。自愈机制不是锦上添花，而是企业级 AI 系统的准入门槛。
但也要看到，这些实践仍然处于早期阶段。百分之九十四的自愈率听起来很高，但剩下的百分之六在企业场景中可能就是关键业务的停摆。智能体写代码的能力虽然强大，但代码质量、安全性和维护成本仍然是需要回答的问题。monday.com 选择把所有硬活儿交给模型，这种策略在不同行业、不同风险等级的场景下是否都适用，还需要时间验证。
对中国企业家而言，更有价值的启示可能不是具体的技术方案，而是 monday.com 面对失败时的态度。他们公开承认 V2"在我们面前炸开了"，然后果断推倒重来。这种对技术边界的诚实和对架构原则的坚持，比任何工具选型都更能决定一家公司在这场变革中走多远。
关于 MindsLeap 心智悦动
MindsLeap 心智悦动是 AI原生组织转型加速平台。
我们与硅谷创新孵化器 Founders Space 深度合作，持续连接全球 AI 前沿认知、硅谷科技创业生态与中国企业家的真实转型场景。
围绕 AI 原生组织建设，MindsLeap 正在构建一个面向企业家、创业者、AI 工程师、产业专家和投资人的转型生态，帮助企业把 AI 从认知、战略和工具，真正落到组织能力、业务流程、产品创新和增长系统中。