monday.com重构Sidekick：弃用单一大模型智能体，改用沙箱与专业子代理
monday.com工程师在生产环境中发现，工具越多，Sidekick表现反而越差，于是引入有界工具、专业子代理和隔离沙箱，以提升复杂任务执行可靠性。
AI解读：monday.com的Sidekick早期版本把所有能力塞进一个通用智能体，结果是工具数量增加，模型越难选对工具，上下文也被大量挤占，生产环境中的实际表现反而下降。后来团队把系统拆成多层：主代理负责规划和调度，专业子代理做专项推理，沙箱提供文件处理、代码运行等中间状态操作的隔离环境。这样做的直接后果是，像“分析三个看板的数据并生成高管汇报”这类复杂任务，不必再让所有中间计算过程都穿过主模型的上下文窗口，降低了成本和出错概率，也让每一步的执行过程更容易追踪和调试。对使用者而言，他们仍只面对一个助手，但后台的分解能处理更复杂、更长的任务，且失败时更容易定位环节。这一改动提醒其他开发者的关键是：给代理加工具不等于加能力，真正的提升来自明确划分责任边界和隔离执行环境。
monday.com的AI工程团队负责人Omri Bruchim在LangChain博客发文，详细说明了其AI助手Sidekick如何在生产环境中暴露出架构缺陷，并最终放弃“单个通用代理 + 工具列表”的初版设计，转向分层架构。文章称，早期测试中更多工具让Sidekick显得更强大，但生产中每个新工具都会导致系统更模糊、成本更高、更难调试，整体能力反而下降。
V1架构暴露的三个问题
初版Sidekick采用一个主代理调用所有工具，团队观察到反复出现的模式：相似工具描述重叠导致模型选错工具；工具定义每轮占用上下文，留给用户请求的上下文变少；单一提示词试图覆盖研究、内容生成、数据分析、看板操作等多个领域，导致代理过于泛化；长工作流中间一步失败会使推理方向丢失。
观测也变得困难，难以判断失败来自规划、工具选择还是执行；延迟和成本随复杂度增长，因为代理经常尝试不必要的工具或重复调用；添加一个新工具可能影响看似无关工作流的测试结果，测试组合数激增。
团队遇到三个核心障碍：一是复杂度管理，不同类型工作都塞进一个提示词和推理循环；二是上下文超载，大量看板数据、文档、工具输出和产物若都传入主模型，成本高且经常适得其反；三是多步骤工作的可靠执行，某些任务并非简单的API调用序列，需要探索、临时文件、迭代转换、验证及部分失败恢复。
新架构的分层结构与沙箱辅助
Sidekick的新架构包括：上下文与权限层（在信息进入代理前进行基于权限的检索）；主编排代理（理解用户目标、维护计划、决定执行方式）；专业子代理（使用更小工具集处理狭窄目标，如内容生成代理不需要看板管理工具）；3层分类的工具体系（代理需显式激活工具才能解锁完整schema）；以及沙箱执行环境，用于处理无法用单个或短序列工具调用完成的工作。
沙箱为代理提供隔离工作区，可在其中存储文件、运行代码、检查中间输出、从错误中恢复并生成产物，无需每一步都经过主模型上下文。团队将MCP、工具调用和沙箱视为互补：工具适合有界操作（读取看板、更新项目、搜索文档），沙箱适合文件密集和分析密集任务。例如用户上传多个CSV与看板数据核对，代理可把文件放入沙箱、验证列名、反复修复脚本、生成图表，主代理只需最终结果和事件摘要。
一个示例任务是“分析三个看板数据和附件CSV、识别主要交付风险、撰写高管更新”：主代理通过工具检索数据，会委托分析子代理进行风险分析；如CSV需归一化、合并、计算或生成图表，分析子代理在沙箱中执行；最后主代理或专注写作的子代理生成所需格式的更新稿。
生产中的应用与经验总结
新版架构已在生产环境运行数月，团队观察到的典型用例包括：跨上下文的项目报告（需权限感知检索、结构化与非结构化分析、专业推理和可溯源内容生成）；文件处理（将电子表格与monday.com数据整合、查找异常并生成图表或报告，沙箱在此类任务中作用关键）；内容生成（研究阶段与写作阶段分离，有助于保持来源并减少幻觉）。
文章中列出经验：不要默认给一个代理所有能力，更多工具可能因增加歧义和占用上下文而削弱能力；应将上下文检索与权限过滤作为架构的一部分来设计；有界操作用工具，开发式工作用执行环境，否则会导致接口庞大低效；应从初期就设计评估与观测机制，成功的API调用不等于满足用户目标；用户看到的单一助手背后可以由多个专门组件协同执行。
作者也提到，如果重来一次，会更早引入清晰的能力边界——单一代理有助于快速学习，但在分离职责前让主代理积累了过多责任。关于LangChain的使用，文中说明其LangGraph、Deep Agents、LangSmith和Sandboxes组件配合工作，使委托与沙箱行为停留在同一追踪中，便于生产调试，同时允许团队保留自己的工具、检索层、模型和权限控制。