monday.com 如何在 Amazon Bedrock 上运行生产级 AI 同事

#monday.com 如何在 Amazon Bedrock 上运行生产级 AI 同事

AI 同事（AI Teammates）是跑在 Amazon Bedrock 上的智能体式人工智能（agentic AI）。很少有工程组织能像 monday.com 这样，在生产环境里以这个规模运行它们。十分之九的建设者（Builders）每个月都在使用 AI 编程工具，而大约一年前这一比例只有一半左右。每位工程师的拉取请求（pull request，PR）吞吐量上升了一半以上。这篇文章里的每一个数字，都来自 monday 自己的内部生产数据。

在这篇文章中，我们分享这些数字背后的架构、让它在一套已有十年历史的代码库里跑起来的改造，以及正在补上完全自治缺口的置信度评分合并方案。

这不是一块绿地

monday.com 是一套已有十年的代码库，有数百万付费用户、数百个微前端和微服务，以及数百名建设者（工程师、产品经理、分析师和产品设计师）。智能体开出的每一个 PR，都会进入一套数百万用户期望在下一次部署后仍然正常工作的系统。绿地演示很直接。让智能体跑在一套有真实值班、客户和合规要求的企业级软件即服务（SaaS）里，才是这项工作。

AI 工程的三个层级

可以把这段历程看成三个层级：

• L1，助手。工程师把 AI 当作结对程序员。Cursor 负责快而反射式的工作，Claude Code 负责重活。采用率同比几乎翻了一倍。

• L2，技能与子智能体。团队为重复工作搭建可复用智能体，工程师仍坐在驾驶座上。monday 今天大部分工作处在这一层，也是每位开发者 PR 吞吐量上升一半以上的地方。

• L3，多智能体。完全由智能体执行。智能体端到端负责交付，工程师负责编排：从看板领取任务，在 Slack 和 monday 里沟通，与人类一起交付代码。

智能体是同事，不是岗位

Sphera 是 monday 的内部智能体系统。你第一眼看到的不是任务队列，而是一个团队页面：人类和智能体混在一起，每个人都有档案、管理者、职责范围和绩效分数。Atlas 是这篇文章的中心智能体，也是其中之一：角色是软件工程师。工作是领取工单、写 PR、交付功能。集成开发环境（IDE）：没有。待办事项与其他人相同。

这不是装饰，这是数据模式。每个智能体都有一个稳定身份，贯穿 Slack、GitHub 和 monday，因此人类可以像对待任何其他同事一样标记、指派、代码评审或停用他们。真正拉动指标的智能体，生活在真实团队里，做真实工作，并对结果负责。

图注：Sphera 团队页面把人类和智能体列在一起，各自有档案、管理者、职责范围和绩效分数。

架构

下面说明系统如何拼在一起：从智能体监听的收件箱，到承载每一条事件的 AWS 服务。

三个收件箱，一个智能体

monday 自建的智能体有三个一等收件箱：Slack 的 @提及、monday 条目指派，以及 GitHub 的 PR 评审请求。三者都进入同一个智能体会话，使用磁盘上同一份记忆和工作区：同一事件的三种形态，同一条队列，同一条路径。我们不运行三套智能体系统。我们只运行一套。

一张图里的架构

图注：架构图追踪一条事件，从 Amazon SNS 到按团队划分的 Amazon SQS 队列，再到 Amazon EKS 上的 monday Builders CoWORK 消费者，然后到由 Amazon RDS、ElastiCache、EFS 和 S3 支撑的智能体运行器 Pod。

我们使用的七项 AWS 服务是 Amazon Simple Notification Service（Amazon SNS）、Amazon Simple Queue Service（Amazon SQS）、Amazon Elastic Kubernetes Service（Amazon EKS）、Amazon Relational Database Service（Amazon RDS）、Amazon ElastiCache、Amazon Elastic File System（Amazon EFS）和 Amazon Simple Storage Service（Amazon S3）。在它们旁边，AWS Secrets Manager 处理按会话的密钥管理。Amazon Bedrock 处理模型调用，monday-agent-sdk 运行在每个智能体运行器 Pod 内。

事件路径：从 SNS 到 SQS，再到 monday Builders CoWORK

每一个外部触发都先进入 SNS，再按主题和路由键扇出到按团队划分的 SQS 队列。monday Builders CoWORK 是 EKS 上一组 SQS 消费者，它拉取每条消息，解析由哪个智能体负责，再交给正确的智能体运行器 Pod。

发布/订阅加上队列，给了我们不愿放弃的四件事：开箱即用的重试和死信队列（dead-letter queue）、Amazon Bedrock 被限流时的背压（back-pressure）、可持久重放（在提升之前，我们会用修补后的构建重跑过去一天的事件），以及并发扇出。如果 Claude Agent SDK 在运行时层交付了更好的东西，我们就删掉自己的版本。运行约束层（harness）留下来。

monday-agent-sdk：故意做成薄封装

Claude Agent SDK 是运行时。我们封装它，出于三个原因：

• 调用点上的提供方中立。智能体的大语言模型调用被路由到一个 Amazon Bedrock 模型端点。

• 冷启动（cold start）成本。智能体运行器带着预热的 node_modules 和插件缓存交付，因此第一次模型调用通常在一秒内发出。

• 我们想要自己的运行约束层。运行时正在变成商品。运行约束层才是我们的判断所在：智能体如何被评测，插件如何组合，它如何与 Slack、monday 和 GitHub 对话，它的输出如何对照 monday 标准被评审。我们把运行时留给别人，把运行约束层留给自己。

状态、记忆、会话

智能体至少有三种状态。把三种都放进同一个存储，你会在费用、延迟或正确性上付出代价。活状态放到 Amazon ElastiCache。当前任务、运行游标、分布式锁、心跳，以及智能体与人类的消息日志。亚毫秒读取，键会自行过期。Amazon DynamoDB 也能用；对这种访问形态，ElastiCache 更便宜也更快。会话和记忆存放在 Amazon Elastic File System。每个活跃会话是共享文件系统上的一个目录：

/sessions/<session-id>/
├── repos/          # checked-out workspace
├── secrets.json    # encrypted per-session secrets
└── messages/       # chronological event log

/agents/<agent-id>/
├── MEMORY.md            # cross-session memory
└── diary/2026-04-21.md  # per-day journal

不用 S3，有两个原因。第一，Claude Agent SDK 和大多数插件期望真正的 POSIX 文件系统（git、npm、文件编辑），这去掉了整类“在开发环境能用、在工作进程里坏掉”的缺陷。第二，当一次运行在另一个 EKS Pod 上恢复时，那个 Pod 挂载同一条 EFS 路径，并从离开的地方继续。

Atlas 的每日日记是一个真实文件。下面是一段已脱敏的片段：

# diary/2026-04-21.md
## In progress
- ENG-3491: rate-limit headers: verify staging, then open PR
- ENG-3502: dependency bump: blocked on Guardrails security-boundary
rule, waiting on standard-owner review
## What I learned last session
- The accounts-api team files every new error code in the shared
registry BEFORE the PR opens. I did it in the same PR last time
and got reverted. Filed the registry update first this time.

这个文件就是 Atlas 第二天早上恢复工作的方式。他读它，想起 accounts-api 团队要求把错误注册表更新单独提交，然后开始工作。记忆是一个磁盘上的文件，可以被不止一个 Pod 挂载。

持久记录进入 S3。最终记录稿、快照、产物和评测按会话 ID 作为键。EFS 保存工作记忆；S3 是审计轨迹。

Amazon Bedrock 作为模型织物

Amazon Bedrock 不只是一个取令牌的地方。它是让我们运行数百个智能体而不丢失成本、安全或容量跟踪的服务。大规模部署智能体的大多数运维要求，已经是 Amazon Bedrock 里的功能：

• 应用推理配置（Application Inference Profiles）路由每一次模型调用，因此成本跟踪和容量规划留在同一个地方。

• 每一次模型调用都有一条审计轨迹：当安全团队或监管机构询问某个时间窗口内智能体把什么发到了哪里，我们有一个地方可以回答。

• 当一个 AWS 区域被限流时，跨区域故障转移。智能体代码不会察觉。

• AWS PrivateLink 端点把模型流量留在我们的虚拟私有云（VPC）内。

跑在 EKS 上

计算集群是 Amazon EKS，每个活跃智能体会话一个 Pod，挂载该智能体的 EFS 工作区。崩溃隔离按会话进行。自动伸缩由 KEDA 驱动，依据是用 Datadog 测量的各 Pod 平均活跃会话数。我们运行单一工作镜像。代码仓库缓存在 EFS 上，并跨会话复用。没有服务网格，也没有编排器的编排器。负载由 EKS、SQS 和缓存层承担。

让这一切跑起来的五项改造

架构是地板。下面五项改造，才让智能体在一套十年代码库里变得有用。没有一项是奇技。在撞上之前，每一项都不显而易见：

模型升级之前先做评测

“看起来还行”曾经是 Atlas 早期 PR 的标准。量上来之后它就垮了。我们加了两层评测（evals）：每个智能体的确定性指标（已合并 PR、回滚率、零人工修改合并率），以及每个 PR 在五个维度上的大语言模型评分：意图与决策、执行与产物、完整性与有用性、指令与边界、效率。两者都回灌到运行约束层。在 Atlas 的连续版本中，我们没有改模型、没有改提示词、没有人工推动，只改了评测，分数在每个维度上都动了。

记忆是文件，不是向量库

第 1 次会话：Atlas 做了一个功能。第 2 次会话：他完全不知道第 1 次会话发生过。我们试过把上下文窗口塞满，也试过对过去记录稿做向量检索。两者都很差。真正有效的是：每个智能体一份 MEMORY.md，以及在会话结束时写入、会话开始时读取的 diary/YYYY-MM-DD.md。纯 Markdown，没有嵌入，没有召回评分，没有智能体式检索增强生成（RAG）的仪式。

人类评审之前先过远程沙箱

Atlas 最初的十几个 PR 通过了本地测试，却在持续集成（CI）里坏掉。monday 这个规模的代码库有一些只存在于真实环境的依赖：功能开关（feature flag）、第三方服务、真实流量。我们给 Atlas 每个会话一个远程沙箱（sandbox），每个 PR 都自动部署到那里。测试、检查和重放的生产流量，都在他请求人类评审之前运行：失败就修，修好再交付，循环里没有人。

PR Guardrails：对照 monday 标准的自动评审

Atlas 交付得更多了，人类评审变成瓶颈。我们把每一条 monday 工程标准变成自动评审者：指标打标、功能开关卫生、Datadog 用法、安全边界、数据库和微服务约定、测试质量、文档。其中一部分是阻断性的。每一条都通过 monday 的 MCP 服务器接到内部知识，因此评审者看到的上下文，与标准负责人团队会看到的相同。

每一个 PR，无论是智能体还是人类撰写，都要经过 Guardrails。在这个规模上，意味着每个月评估数万个 PR，并执行数十万次标准检查。大约五分之一的 PR 至少未通过一条标准并被退回，人类覆盖只占很低的个位数百分比。执行由系统管理，而不是由人类评审者管理。

Builders CoWORK：把 monday 看板当作共享状态层

最后一种失败模式最贵：孤岛里的智能体开出没有团队认领的 PR。我们加了 CoWORK 工作区，它是同一个负责路由事件的 monday Builders CoWORK 的用户侧界面。智能体的任务、状态、阻塞和交接，现在与团队住在同一块 monday 看板上，因此问责不再是系统问题：monday 已经为人类解决过它。

图注：monday 看板，智能体和人类在协作式 CoWORK 空间里共享任务、状态和阻塞。

智能体在协作空间里工作。

图注：monday 界面显示一个智能体同事与人类同事一起被指派任务。

智能体是同事，你可以像对待任何队友一样，请他们分享信息或执行任务。

从一个瓶颈到下一个瓶颈

到 2026 年第一季度末，瓶颈不再是代码生成，而是人类评审：Guardrails 抓住了过去由人类抓住的问题，但每个 PR 仍然要等一个人批准。下一堵墙就是这个。

许多个中的第一个：Morphex

Morphex 是 monday 第一个完全自主的工程智能体，工作在与每一位建设者相同的仓库、CI 流水线、Guardrails 和回滚规程里。Morphex 每二十个 PR 中有十九个自动合并，不是因为跳过评审，而是因为通过了每一道门，并且获批的 PR 在没有人参与的情况下进入生产。它每个月开出的 PR 比大多数工程师更多，被拒绝的 PR 失败原因与任何工程师相同：不稳定测试、含糊规格、未处理的边界情况。

这个二十分之十九的比率是地板，不是天花板。尚未回答的问题是：什么信号能提前告诉我们，哪些 PR 可以在没有人的情况下安全合并。

信号：最近一次严格切分

在我们产出 PR 最多的智能体中（没有挑选样本），数字拆得很干净：大约十分之三的 PR 被合并，其中大约四分之三没有任何人类编辑，回滚率处在很低的个位数百分比。大约四分之一的 PR 在到达人类之前，就被 Guardrails 抓住并拒绝。

最后一个数字最重要。Guardrails 拦住了四分之一的智能体 PR，因为系统看出它们还没准备好，留下一个预先过滤过的合并群体。这个群体上很低的个位数回滚率，就是置信度自动合并可行的信号。

置信度评分的自动合并

置信度分数组合了 PR 一打开就具备的四个信号：

• 确定性的 Guardrails 结果：每一条阻断性标准都必须通过。

• 按智能体的评测轨迹：该智能体这一版本最近的评测分数窗口。

• 按（智能体 × 仓库 × 变更类别）的历史回滚率：低风险服务里依赖升级的近零回滚，与单体迁移上更高的回滚率，是不同的画面。

• 沙箱结果：第 3 项改造给出的绿色是必要的，不是充分的。

高于门槛，PR 自动合并。低于门槛，它路由给一个人，并指出具体失败的信号。这就是从 L2 到 L3 的转变：不是去掉人，而是在系统信号已经强到再加一个人也不会改善结果的情形里去掉人。接下来两个季度我们推动一个指标：已合并的智能体 PR 中，在没有人类评审者的情况下交付的比例，同时把回滚率保持持平或更好。

AI 工程不是要造出完美智能体。它是要建立反馈回路，让不完美的智能体可以被安全地信任，同时节省人的时间。

诚实的收尾

为什么我们按 monday 的方式来建

价值不在运行时，那只是 Claude Agent SDK 外面的一层运行约束。它活在我们围着它接上的一切里，而这些接线彻头彻尾是 monday 的：

• 把 monday 看板当作共享状态层：每个智能体的任务、状态和交接，都住在业务其余部分已经在看的地方。

• 把 monday 的 MCP 服务器当作 Guardrails 和标准插入的基底。

• monday 的认证与身份，使每个智能体在与任何人类相同的基于角色的访问控制（RBAC）下，拥有真实的 Slack、GitHub 和 monday 用户。

• monday 的部署流水线，使智能体代码与每一位其他建设者走同一套持续集成/持续交付（CI/CD）。

与人类共享状态、身份和基础设施的智能体，不需要单独的治理层。现有的那一层已经适用。这使系统默认可审计、可回滚、可信，而不是靠事后追加。一套样板系统会把这一切压扁进别人的模型。

三件我们会换种做法的事

评测本应在第一天就进入系统，而不是第九个月。Atlas 从评测得到的分数提升，才是头条结果。在意识到 EFS 上的 MEMORY.md 一直是正确答案之前，我们在向量库上投入过多。而且第一版 CoWORK 住在一个单独工作区里，迫使人类切换上下文才能看到智能体在做什么。把它搬到 monday 看板上，本应是第一个决定，而不是后来的修正。

结论

我们不会开源 monday-agent-sdk。封装很小，它的大部分价值在运行约束层，而那一层以对别人没有帮助的方式绑定于 monday。我们分享的是架构和运维手册，因为当大规模运行生产智能体的团队诚实说出什么有效时，行业会走得更快。

如果你正在把智能体建进工程团队，你会遇到我们遇到过的大多数墙，而我们已经跨过去了。来找我们谈：monday AI 工程团队，或 Amazon Bedrock 团队，都乐意分享我们的认识。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/ai-teammates-how-monday-com-runs-production-ai-agents-on-amazon-bedrock