100 万用户、6 个月、context 压缩 500 倍：多 Agent 架构真正的瓶颈不是模型，是让它持续修正自己的能力

大多数团队以为，把 AI 塞进产品 = 一个 prompt + 一个 API。

Rippling 在 6 个月内把 AI 铺到全线产品、服务 100 万用户之后，得出了一个相反的结论：模型不是瓶颈。Context engineering 才是。Eval 不是锦上添花。它是系统能持续运行的前提。

如果你正在把 AI agent 嵌入一个已经跑着的复杂产品 — — 尤其是那种数据模型跨度大、权限边界多、写操作不能随便放行的产品 — — 那你大概率已经被同一类问题折磨过。context 太大塞不进窗口 — — 但更糟的是塞进去了，agent 分不清 payroll 域和 spend 域里同名的 “balance”。tool call 多了之后 agent 开始幻觉实体的 ID — — 不是胡编，而是把 A 公司的 workspace_token 传给了 B 公司的查询接口。每次改 prompt 都像在修一个你不知道会崩哪里的漏水管道，因为改了一处 reasoning 逻辑，可能影响三条不同的 tool chain。

Rippling 的产品横跨 HR、IT、Payroll、财务和全球运营 — — 这不是五个独立的产品线，而是一个统一平台上互相纠缠的数据世界。底层数据模型有数千张表、几十万个字段、大量跨域同名的实体。”balance” 到底是健康储蓄账户余额、信用卡额度、还是承包商付款账户？同一个词，三个域，三个完全不同的含义。更致命的是，这些域不是静态的 — — Rippling 连接了 Salesforce、Carta、GitHub 等外部平台，entity 的语义在跨系统边界时又会发生变化。

把一个 LLM 直接扔进这个数据模型里做问答，不是”效果不好” — — 是根本不可行。你不可能把几千张表的 schema 全塞进 context window，即使能塞进去，LLM 也分不清同名实体在不同域里的区别。

这就是为什么 Rippling AI 的架构值得仔细看。它不是在模型层赢了，而是在 context 治理、多 agent 分工、和自我修复 eval 闭环这三个层面做出了一套可复制的系统。

适合谁读？ 正在把 AI agent 嵌入已有复杂产品的工程师和产品负责人、被 context window 和 eval 稳定性折磨的团队、想知道”多 agent 架构在生产环境到底长什么样”的人。

读完这篇文章，你应该能带走三个判断：

1. 为什么 Rippling 把 context 从全量压缩 100–500 倍，并且这不是一个 prompt 技巧 — — 是三层 context 治理基础设施；
2. supervisor + 3 类子 agent 怎么在一个数据模型横跨 HR/IT/Payroll/财务的产品里做到”每个 agent 只看到自己该看的东西”；
3. BeeOS 如何把 context 裁剪、写操作收敛、eval 闭环这三件事从”团队自己搭”变成 runtime 内置能力 — — 让 agent 系统不只是能跑，而是能持续修正自己。

零、案例事实：谁在什么条件下跑出了什么结果？

根据 LangChain 发布的 Rippling 案例研究（How Rippling Went AI-Native Across Every Product in 6 Months with Deep Agents and LangSmith，2026 年 6 月 1 日），这是一次真实的跨域 AI 系统落地：

• 维度: 上线时间 — 数字: 6 个月（从启动到全产品线 AI-Native）
• 维度: 用户规模 — 数字: 100 万+ 全球用户
• 维度: 数据模型 — 数字: 数千张表、几十万个字段，跨 HR/IT/Payroll/财务/全球运营
• 维度: Agent 架构 — 数字: 1 个 supervisor + 5~7 个专业子 agent
• 维度: Context 压缩 — 数字: 100–500 倍（通过动态 skill 注入 + 重排序）
• 维度: Eval 规模 — 数字: 300–400 个集成测试查询，每日多次生产环境持续评估
• 维度: 部署门禁 — 数字: ~10 个 deploy-blocking eval，任何通过才能上线
• 维度: 写操作隔离 — 数字: Action agent 用沙箱化代码执行，LLM 不直接操作数据

以上数据来自 LangChain 官方案例页（链接），未提供绝对金额和完整实验周期细节。

一、Context Engineering：不是”能不能塞下”，而是”能不能不乱”

Rippling AI 的核心技术挑战不是模型选择 — — 是 context。

数千张表、几十万个字段、跨域同名实体 — — 如果你把 schema chunks 直接喂给 LLM，结果不是慢，是乱。同名字段在不同上下文中语义完全不同，”balance” 在 payroll 域和 spend 域是两个东西。LLM 不能靠自己区分这些 — — 它需要一个外部系统帮它先把上下文剪裁对。

Rippling 的解法是三层 context 治理：

第一层：动态 skill 注入。 用户提问后，系统先用 Rippling 自有的语义层识别当前域（payroll？devices？ATS？spend？），然后注入该域专属的 skill — — 不是把所有 schema 都塞进去。midleware 在 agent 调用工具之前做重排序，把不相关的实体剪掉。这一步把 context 从”全量”压缩了 100 到 500 倍。

第二层：REPL 变量存储。 这是 Rippling 团队最锋利的一个观察。他们发现 LLM 在跨 tool call 传递长字母数字 ID（比如 employee_id、workspace_token）时，会频繁出现幻觉 — — 不是完全编造，而是把相似的 ID 搞混。解法：在 agent 执行步骤之间维护一个运行时变量表（REPL），agent 引用的是命名变量而非裸字符串。变量绑定由系统保证，LLM 只负责语义层。

第三层：沙箱化代码执行。 Action agent（写操作）不直接让 LLM 操控数据。LLM 负责”要做什么”（reasoning），但”怎么格式化”（deterministic code）在沙箱里跑。比如客户端上传的 CSV — — 里面可能是各种格式的员工数据、薪资调整、部门变更 — — 先由沙箱代码标准化成 Rippling 内部 API 期望的格式，再执行写入。这一步把 LLM 的不确定性收束在 reasoning 层，不让它侵入数据层。

为什么这一步不能省？因为数据格式错误比 reasoning 错误更难发现。LLM 如果把 “2026–01–15” 写成 “01/15/2026”，Rippling 的内部 API 可能静默接受但解析成错误的日期 — — 这个 bug 不会在 eval 里触发明显的失败告警，但它会导致员工入职日期偏移、薪资计算错误。沙箱代码把格式转换变成确定性操作，让 LLM 专注在它擅长的事上：理解”这条 CSV 里是什么数据、应该映射到哪些字段”。

这三层合在一起，本质上是在 LLM 和 Rippling 的数据世界之间建立了一个context 治理层。它不靠 prompt engineering 去”说服” LLM 不乱，而是靠系统设计去确保 LLM 没机会乱。

这里有一个容易被忽略的深层逻辑：这三层不是并列的 — — 它们有先后顺序。先确定域（skill 注入）→ 再注入上下文（REPL 变量绑定）→ 最后才执行（沙箱代码）。这个顺序本身就是治理层级。如果先执行再确定域，那 LLM 已经在错误的 context 里做出了一次不可撤回的 tool call — — 问题不是”回答错了”，而是”已经改错数据了”。

二、多 Agent 分工：不是你”告诉”agent 做什么，而是每个 agent 只看自己能管的那块

Rippling AI 的 agent 架构是 supervisor + 专业化子 agent。这个选择不是架构审美 — — 是被 context 逼出来的。

如果只用一个 agent 处理所有问题，这个 agent 需要一个能同时理解 HR、IT、Payroll、财务四个域的工具集。工具集越大，context 越重，tool selection 越容易出错。而且单一 agent 的写操作权限边界极其模糊 — — 它要么能写所有东西（危险），要么不能写任何东西（无用）。

这个选择不是架构审美 — — 是被 context 逼出来的。

如果只用一个 agent 处理所有问题，这个 agent 需要一个能同时理解 HR、IT、Payroll、财务四个域的工具集。工具集越大，context 越重，tool selection 越容易出错。而且单一 agent 的写操作权限边界极其模糊 — — 它要么能写所有东西（危险），要么不能写任何东西（无用）。更隐蔽的问题是：单一 agent 出 bug 时，你没有故障域的概念。是读数据出了问题，还是写数据出了问题？还是 RAG 检索到了一个错误的政策文档？你不知道 — — 所有行为都在同一个 agent 的 trace 里混在一起。

Rippling 把这些能力拆成了三类子 agent：

Supervisor Agent（主管 Agent）
  ├── Read Agent     → 查询结构化数据（HR/Payroll/IT/财务 + Salesforce/Carta/GitHub）
  ├── RAG Agent      → 检索非结构化内容（帮助文档、公司手册、HR 政策）
  └── Action Agent   → 执行写操作（批量上传、职级标准化、新员工预填充）

Supervisor 不干具体活。它只做一件事：分析用户意图 → 调度正确的子 agent。用户问”我的 balance 是多少”，supervisor 先判断这属于哪个域（health savings？credit card？contractor payment？），然后把任务路由给对应的 Read Agent。

这个 supervisor 模式的关键价值不是”分工” — — 你用 if-else 也能分工。关键价值在于 supervisor 的 reasoning 是 traceable 的。当系统出错，你能沿着 trace 看到 supervisor 把”balance”解析成了哪个域、为什么、然后确认是 supervisor 的路由判断错了还是子 agent 的查询结果错了。没有这个 trace，多 agent 系统在生产环境就是黑盒 — — 你知道出错了，但不知道错在哪一步。

还有一个细节：用户界面不只是文本框。Rippling AI 的回复里，结构化数据渲染成可排序、可筛选的表格；多选澄清以选择 UI 出现；action 确认有独立的交互模式。这意味着 agent 的输出不是一段文字 — — 它是结构化的 payload，前端根据 payload 类型选择渲染方式。这个设计让 agent 的输出变成可消费的 API response，而不是”你看着办”的自然语言。

这里有一个容易被忽略的设计选择：每个子 agent 的工具集是独立裁剪的。

Read Agent 只能读 — — 它的 tool set 里没有写操作入口。Action Agent 能写，但写操作先经过沙箱代码执行，再经过内部 API 校验。RAG Agent 只能检索 — — 它碰不到结构化数据。这个”最小权限”的设计，不是安全部门的 checklist，而是让多 agent 系统能稳定运行的前提条件。当一个 agent 的行为出问题，你能确定故障域是哪个 agent — — 而不是在一条巨型 prompt 链里大海捞针。

三、Eval 不是”测一下”，而是系统的自我修复能力

Rippling 的 eval 体系很容易被误读成”他们有很好的测试”。但真正值得拆解的不是”跑了很多测试”，而是eval 和 agent 之间形成了一个闭环。

先看四层 eval 管线：

Offline eval           → 本地 mock，每次 commit 自动跑
Post-merge integration → 300–400 个查询，在完整 sandbox 中用真实 API
Deploy-blocking        → ~10 个关键场景，不通过就不能上线
Continuous eval        → 每日多次，在生产数据上持续跑

这四层不是”测试金字塔”的翻版。关键在于：当 continuous eval 发现线上 regression，系统不是发一个告警等人修 — — 它用 agent 来分析失败、提出修复方案、重跑 eval 验证改善、然后生成 PR 等人审。

这就是 Rippling 团队说的 semi-automated self-healing loop：

线上失败 trace → agent 分析失败原因 → 提出修复方案 → 重跑 eval → 确认改善 → 生成 PR → 人工审查合入

“人工审查合入”这一步至关重要 — — 它说明这套系统不是全自动修 bug（那会引入新的风险），而是把修复的探索成本从人转移到 agent，把审批权留在人手里。

这个设计的深层含义：eval 不只是质量的度量，它是 agent 系统自我意识的基础设施。 没有 eval，你的 agent 不知道自己错了。有了 eval + self-healing loop，agent 能从错误中学习 — — 不是”模型的权重更新了”，而是”系统的行为被修正了”。

BeeOS 落点：百万人级别 agent 系统的三个治理维度

Rippling 的案例暴露了一个多 agent 系统进入生产后会遇到的三个核心张力。BeeOS 围绕这三个张力给出了协议层方案。

张力一：Context 裁剪应该在哪一层发生？

Rippling 的 100–500 倍 context 压缩在 middleware 层实现。BeeOS 的做法是把同一层逻辑推到 MCP 协议入口。

MCP（接入面）：在 BeeOS 里，每个 agent 实例不是拿到全套工具列表。tools/list 的返回结果按 agent 角色裁剪——ReadAgent 只看到读查询类工具，ActionAgent 看到的写类工具背后挂了 bak_ 权限门。这比 middleware 更进一步：不是在 LLM 拿到工具之后靠 prompt 告诉它”别乱用”，而是在工具分发之前就剪掉了它不该看到的东西。

A2A（协作面）：Context 治理不只发生在 agent 内部。Rippling 的 supervisor 需要把任务描述路由给子 agent — — 这个路由动作本身就是 context 的传递。如果 supervisor 把所有上下文一股脑推给子 agent，那三层治理白做了。BeeOS A2A 的 JSON-RPC task 格式自带 input/output schema，子 agent 只收到任务边界内需要的信息，而非全量透传。

张力二：写操作怎么做到”能执行，但不会乱执行”？

Rippling 用沙箱代码执行来隔离 LLM 和数据操作。BeeOS 在更大的范围上做了同一件事：不是禁止写操作，而是让写操作可见、可审批、可回滚。

• Agent 角色: DataReader — bak_ scope: bak_readonly — 允许: 查询跨域结构化数据 — 拒绝: 修改任何字段
• Agent 角色: DocRetriever — bak_ scope: bak_docs_read — 允许: 检索帮助文档和手册 — 拒绝: 修改文档内容
• Agent 角色: ActionExecutor — bak_ scope: bak_write_ops — 允许: 执行写操作（经沙箱代码） — 拒绝: 直接 SQL/API 裸写
• Agent 角色: EvalRunner — bak_ scope: bak_eval — 允许: 触发 eval、读取结果 — 拒绝: 修改 eval 配置
• Agent 角色: PRGenerator — bak_ scope: bak_code_review — 允许: 生成修复 PR — 拒绝: 合并 PR（需人工审批）

关键不在权限表本身。关键在于 **bak_ 是 runtime 层级的权限收束，不依赖 agent 的 prompt compliance**。ActionExecutor 想改某个字段？它必须穿过 bak_write_ops 这个 gate——gate 的判断逻辑在 BeeOS 的 control plane 里，不在 agent 的 prompt 里。

张力三：Self-healing 怎么从”一个团队的做法”变成”runtime 内置能力”？

Rippling 的 self-healing loop 依赖 LangSmith 的 trace API — — 有人写了一个 agent 来分析 trace、有人写了一个 agent 来跑 eval、有人写了一条 CI 管线来把这些串起来。这是一套定制的工程系统。

BeeOS 的观点是：deploy → monitor → eval → self-heal → rollback 应该是 runtime 内置的 cycle，不是每个团队各自搭的脚手架。

OpenAPI 提供 deploy/invoke/terminate 生命周期 — — 每一次 deploy 自动触发 eval gate，不通过的不上线。生产环境中 continuous eval 发现 regression 时，runtime 能触发 rollback 到上一个已知良好的 agent 版本，而不是等人工处理。Self-healing 从”团队文化”变成了”平台保证”。

这个三入口分工可以这样看：

A2A（协作面）
  supervisor → ReadAgent / RAGAgent / ActionAgent 的任务路由
  JSON-RPC task + input/output schema 实现最小 context 透传

MCP（接入面）
  按角色裁剪 tools/list → ReadAgent 看不到写工具
  bak_ gate 在 tools/call 路径拦截越权操作

OpenAPI（控制面）
  deploy → eval gate（不通过不上线）
  monitor → regression detect → rollback（runtime 内置）

为什么这些不是 LangChain 能单独做的事

Rippling 的架构依赖 Deep Agents 做 reasoning loop，依赖 LangSmith 做 trace 和 eval。这是一个强大的工具栈。但把视角拉高一点，你看到的是一个模式：

每个 agent 系统在生产环境都需要一套”框架外的治理层”。

LangChain 负责你怎么写 agent。但它不负责： — agent 之间的任务传递格式是否标准化（A2A 做的事） — agent 看到的工具集是否按角色裁剪（MCP 做的事） — agent 的部署、监控、回滚是否自动化（OpenAPI 做的事）

这些是 runtime 的能力，不是 framework 的能力。Rippling 团队自己搭了 context 治理层、eval 闭环、self-healing loop — — 但这不是”LangChain 让 Rippling 成功了”，而是”Rippling 在 LangChain 之上盖了一层 runtime 治理”。

BeeOS 的观点是：这层 runtime 治理不应该每个团队从头搭一遍。它应该是可复用的平台能力。

结尾：三个问题

Rippling 的案例不只是一个”大公司用 AI 的故事”。它摆在面上的问题是这些：

1. 你的 agent 系统的 context 裁剪在哪一层做？是在 middleware 里拼 prompt、
   还是在协议入口就剪掉了不该看到的东西？

2. 写操作的权限边界是依赖 agent 的 prompt compliance，
   还是有一个不依赖 agent 自觉的 runtime gate？

3. 你的 eval 体系能不能从"人发现问题"进化成"系统发现并修正问题"？
   如果不能——不是因为缺人，而是因为 eval 没有和 deploy/rollback 形成一个闭环。

如果这三个问题还没有答案，你的 agent 系统可能已经跑起来了，但它离”能持续运行”还有一段距离。

Rippling 的 6 个月不是奇迹 — — 它是一套可拆解、可复制的工程决策链。真正值得学走的不是”他们用了 Deep Agents + LangSmith”，而是：把 context 治理放在模型选择之前、用 agent 角色切分权限而不是用 prompt 约束、让 eval 闭环取代人工盯盘。这三件事，用任何工具栈都能做。区别是你在 framework 层重新发明它，还是在一个设计上就把它当一等公民的 runtime 上直接用它。

参考与延伸阅读

• 案例来源（事实基础）：How Rippling Went AI-Native Across Every Product in 6 Months with Deep Agents and LangSmith（LangChain，2026–06–01）
• 9,000+ 产品、247 个节点、近零错误：编排器 + 子 Agent 模式如何进化
• 5.3GB → 129MB，41× 瘦身：Agent 运行时的瓶颈不是存储，是状态模型
• BeeOS：docs.beeos.ai · openapi.beeos.ai · a2a.beeos.ai · mcp.beeos.ai
• A2A 规范背景：A2A（Google）
• MCP 规范背景：Model Context Protocol

BeeOS：docs.beeos.ai · openapi.beeos.ai · a2a.beeos.ai · mcp.beeos.ai