.mondaydotcom 打造的AI副驾驶Sidekick，目标远不止于回答问题。

它能够处理复杂且需迭代的工作，例如分析CSV文件或即时生成地图。为此，他们通过LangSmith沙盒为智能体提供了独立工作空间。

他们如何构建及学到的经验：https://langchain.com/blog/building-monday-com-sidekick-why-capable-agents-need-more-than-just-tools…

构建monday.com Sidekick：为何优秀的智能体需要的不止是工具

来源：https://www.langchain.com/blog/building-monday-com-sidekick-why-capable-agents-need-more-than-just-tools 这是来自monday.com AI工程组负责人Omri Bruchim的客座文章 (http://monday.com/)

在早期测试中，更多的工具让Sidekick显得更强大。但在生产环境中，这些工具反而让它表现变差。这篇文章讲述了我们如何推翻首个智能体架构，并围绕明确职责边界、沙盒与专业子智能体重建Sidekick的过程。

我们曾有一个拥有不断增长工具列表的通用智能体

Sidekick是monday.com内置的AI助手。我们的首个版本与许多智能体原型类似：一个通用智能体，外加一个不断扩充的工具列表。这作为起点很有价值——它让我们快速学习，并确认用户真实需要什么。一个能够总结项目、识别障碍、起草更新、分析文件、更新看板，并在monday.com及其所有连接系统中执行操作的助手。

随后Sidekick进入生产工作流，问题开始显现。我们添加的每一个新工具都让系统变得更模糊、运行成本更高、调试更困难。纸面能力在提升，实践中却在下降。

我们的目标从来不是构建一个仅回答monday.com相关问题的聊天机器人。我们希望Sidekick从“回答”转向“辅助”，最终能够主动帮助用户完成实际工作。这推动我们停止将智能体视为一个庞大的推理循环。我们开始在整个系统中分离职责：编排、权限感知的上下文检索、专业子智能体、受限工具以及沙盒执行环境。

本文将分享我们如何重新架构Sidekick、为何沙盒成为智能体的重要原语，以及我们在生产运行中的经验教训。

Sidekick必须在真实工作上下文中工作

Sidekick嵌入在monday.com中，工作上下文分散在看板、条目、更新、文档、仪表板、会议、文件、通知和集成中。用户可能请求项目总结，但答案可能依赖于多种数据源，例如看板、会议记录或上传的文件。

这就是为什么我们不能将Sidekick构建成聊天机器人。它需要理解用户目标、收集合适的上下文、尊重用户权限、跨多个来源进行推理，并真正完成工作。

而请求的类型千差万别。前一分钟是简单查询，下一分钟是写作任务，接着是结构化数据分析，然后是生成成果物的长时工作流。将所有这些都视为同类型的智能体问题，是我们必须纠正的首批错误之一。

我们的首个架构教会了我们什么

V1架构有一个主智能体和不断增长的工具集，这起初看似直观。如果用户希望Sidekick做更多事，我们就给智能体更多工具。然而在生产中，我们观察到每个新工具都以意想不到的方式影响整个系统。一些模式反复出现：

• 工具选择变差——而非变好。相似且描述重叠的工具让模型更难选择正确的工具。
• 工具定义消耗上下文。每轮对话提供大量架构和指令，留给用户请求和实际工作数据的上下文就变少了。
• 智能体变得过于通用。单个提示必须包含研究、内容生成、数据分析、看板操作、文件处理等多个领域的指令。
• 长工作流变得脆弱。某个中间步骤的失败可能导致整个推理循环失去方向。
• 可观测性变得困难。更难判断故障是来自规划、工具选择、工具执行、检索的上下文还是最终响应。
• 延迟和成本随复杂度增长。智能体经常探索不必要的工具或重复调用，因为缺乏足够的结构。
• 测试呈指数级复杂。添加一个新工具可能影响看似无关的工作流。

V1证明了Sidekick确实能产生价值，但也暴露了扁平架构的局限性。我们遇到了三个主要障碍：

1. 复杂性管理：Sidekick需要支持类型迥异的工作，但我们把这些复杂性编码在了一个智能体提示和一个推理循环中。
2. 上下文。单个请求可能涉及大量看板数据、多个文档、历史对话、工具输出以及我们之前生成的制品。将所有这些都通过主模型传递既昂贵，而且往往适得其反。
3. 多步工作的可靠执行：有些任务不是两三个API调用的序列。它们需要探索、临时文件、迭代转换、验证以及从部分失败中恢复。

LangChain Deep Agents为我们提供了更结构化的方式来分解这些问题。我们不再期望一个智能体知道并执行所有事情，而是让主智能体负责理解用户目标，并将受限任务委派给专业子智能体或隔离的执行环境。

但真正的转变不是“转向多智能体”，而是在规划、领域特定推理、工具使用和执行之间划出更清晰的边界。

架构，逐层解析

今天的Sidekick围绕多个层次组织，为智能体带来更强的结构和控制，同时扩展其能为用户承担的任务类型。

1. 请求始于monday.com内部，我们已掌握有用的产品上下文：用户、账户、工作区、看板、文档、仪表板或打开Sidekick的条目。这些上下文帮助智能体根据请求位置推断用户可能的意图。
2. 在信息提供给智能体之前，我们通过上下文与权限层解析哪些上下文相关以及用户有权访问什么。该层可检索结构化的monday.com数据、语义搜索结果、对话上下文、文件、记忆和其他相关工作制品。权限感知的检索是基础要求，而非额外的安全过滤器。
3. 主编排智能体解读用户目标、维护计划，并决定如何执行工作。对于简单请求，它可能直接回答或调用一个工具。对于更复杂的工作，它可以委派给专业子智能体或使用沙盒。
4. 子智能体执行更窄的目标，使用更小的工具集。例如，内容生成智能体不需要所有看板管理工具。这为我们提供了更好的隔离性、更清晰的权责和更有针对性的评估。
5. 工具提供对monday.com和外部系统的受控访问。它们具有权限感知的上下文，适用于受限操作，如读取看板、搜索文档、更新条目或触发已知操作。我们为所有工具设计了三级分类系统，并采用平铺式工具发现。智能体必须显式激活它们才能解锁完整模式。这就像递给LLM一份菜单，而不是把整个厨房都扔给它。
6. 沙盒处理完全不同类别的工作。当智能体需要执行无法干净地封装为单个工具调用或简短工具调用序列的工作时，沙盒就很有用。它为智能体提供了一个隔离的工作空间，在那里可以存储文件、运行代码、检查中间输出、从错误中恢复，并生成制品，而无需将每一步都推过模型上下文。
7. 可观测性与评估是最后一层。我们使用追踪来检查完整的执行路径：模型调用、工具调用、委派、沙盒活动、延迟、令牌使用和失败情况。我们将离线评估与生产信号相结合，因为成功的执行并不等同于有用的结果。我们需要评估Sidekick是否选择了正确的上下文、遵循了权限、完成了任务，并产出了用户可信任的答案。

沙盒为智能体提供了工作场所

我们将MCP、工具和沙盒视为互补的。

MCP和工具调用有助于定义智能体可以访问哪些能力或资源。当操作是受限的时，工具调用工作良好：检索条目、更新列、搜索文档或发送已批准的消息。这些操作有明确的输入和输出。

另一方面，沙盒为智能体提供了一个执行复杂迭代工作的地方。

做出这种区分改变了我们思考文件密集型和分析密集型工作流的方式。如果用户上传多个CSV并要求Sidekick将其与看板数据协调，智能体不应将每个中间数据框都传递通过模型上下文，这既低效又脆弱。它也不应该为每一种可能的转换都设置单独的工具。更好的方法是提供一个临时工作空间，让它在那里检查文件、编写代码、运行它、纠正错误并生成制品。

这就是沙盒发挥作用的地方，这更接近于人执行任务的方式。你不会要求分析师通过为每个列操作调用不同的API来解决电子表格问题。你会给他们一个工作空间、适当的权限和一个明确的目标。

在沙盒中，智能体可以保存上传的文件、检查列名、编写脚本、运行它、遇到解析错误、修复脚本、生成图表，并将中间文件保持在主模型上下文之外。主智能体只需要结果和发生了什么的摘要。

在这个工作流中，工具提供对用户业务系统的受控访问，然后沙盒提供工作环境。

我们如何在工具、子智能体和沙盒之间做选择

我们不为整个请求选择单一的抽象，而是为工作的每个部分选择合适的边界。

因此，如果智能体需要读取看板、更新条目、搜索文档或发送已批准的消息，这应该使用工具，因为操作是受限且可审计的。

如果任务需要更窄范围的推理——如风险分析、研究和内容生成——我们将其委派给子智能体，因为这些任务受益于集中的指令和更小的工具集。

如果工作具有可能使主智能体上下文模糊的中间状态，我们就使用沙盒。像文件、脚本、生成的图表、日志和临时输出这样的制品应属于隔离的工作空间，而不是主上下文窗口。

这里有一个常见例子。用户可能问道：

分析来自这三个看板和附件CSV的项目数据，识别主要的交付风险，并准备一份高管更新。

对于这个任务，主智能体通过monday.com工具检索相关的看板数据。然后，它将风险分析委派给一个目标更窄、上下文窗口更集中的专业分析子智能体。

如果CSV需要规范化、连接、计算或图表生成，分析子智能体可以使用沙盒。它将文件和选定的看板数据放入沙盒，运行转换、验证结果，并生成结构化输出或可视化图表。

最后，主智能体或专注于写作的子智能体将这些发现整理成用户首选格式的高管更新。

单个工作流同时使用这三种机制是常见的。工具提供对业务系统的受控访问，子智能体提供专业推理，沙盒为复杂执行提供工作环境。

LangChain的角色

LangChain是我们编排和智能体运行时层的一部分：

• LangGraph和Deep Agents用于有状态执行、委派、规划和多步智能体工作流。
• LangSmith用于追踪、调试、评估、数据集管理以及比较不同的智能体实现。
• 沙盒用于涉及文件、代码和长期中间状态的隔离执行。
• 标准化的模型和工具抽象使我们能够演进各个组件，而无需重建整个运行时。

一个主要好处是这些组件协同工作。当主智能体委派给子智能体或使用沙盒时，该活动在相同的追踪中保持可见，这在调试生产行为时至关重要。当出现问题时，我们需要了解故障是来自上下文检索、规划、委派、工具执行、沙盒执行还是最终响应。

我们希望避免创建另一个大型内部抽象层，除非它能给monday.com带来明确优势。Deep Agents和沙盒很合适，因为它们提供了所需的原语，而没有强迫我们采用僵化的架构：有状态的多步执行、显式委派给子智能体、用于代码和制品的隔离执行、集成的追踪与评估，以及继续使用我们自己的工具、检索层、模型和权限控制的能力。

面向文件系统的模型尤其有用。智能体已经能够很好地推理文件、目录、脚本、日志和制品。我们无需为每个中间结果设计专有协议，而是让智能体在隔离的工作空间中使用熟悉的原语。这使得沙盒工作流更容易检查、调试和随系统演进。

对我们来说，价值不在于框架消除了设计系统的需要。实际上，大多数重要决策仍然是产品和领域特定的。LangChain的好处在于，我们可以将更多工程精力投入到monday.com特定的上下文、权限、工具、评估和用户体验上，而不是重建一个通用的智能体运行时。

实践中的价值

我们修订后的包含沙盒的架构已在生产中运行数月，我们看到了一些用例模式的出现，这让我们对任务边界方法充满信心。

跨上下文项目报告。用户请求Sidekick分析一个跨看板、文档、更新和活动源的项目，然后生成一份高管摘要。内部需要权限感知的检索、结构化和非结构化数据分析、专业推理以及基于事实的内容生成。

文件处理。用户上传电子表格或CSV，并要求Sidekick将其与monday.com数据结合，查找异常，并创建图表或报告。这正是沙盒发挥作用的那种任务。智能体可以检查文件、编写和运行分析代码、从错误中恢复，并返回有用的制品。

内容生成。用户请求Sidekick基于启动看板和配套工作文档创建启动计划、客户更新或内部公告。研究阶段可以与写作阶段分离，这有助于保留来源并减少幻觉。

在所有这些情况下，用户感知到的是一个助手，但在幕后，该请求可能涉及检索、工具、子智能体和沙盒执行。

经验教训

首个版本…