Sarvam AI 发布智能体编排栈 Arya

1. 首页
2. /
3. 博客

面向生产级智能体的智能体编排栈

研究产品

2026年2月10日 · 16分钟阅读

Claude从零编写了一个C编译器。Cursor的智能体重建了Chrome的渲染管线。但尝试在生产工作负载上运行这些智能体时，它们并不会优雅地失败。它们会静默地、代价高昂地失败，而且每次失败的方式都不同。

考虑一个简单的用例：分析上市公司报告的财务报告。要回答诸如“哪些制造企业正在投资供应链本地化，以及它们的项目是否按预期推进”这样的问题，你需要提取结构化和非结构化数据，例如管理层评论、资产负债表中的资本支出投资等。对于某一类问题，我们大致需要提取约200个字段，如财务指标、业务指标、公告、关联方交易、股权结构、风险因素和行业详情。

这就是ETL。软件中最被充分理解的工作负载。乍一看，这似乎是前沿模型智能体应该能够处理的事情。我们开始了一场24小时的冲刺来一探究竟。

与此同时，我们使用前沿模型，借助Arya——我们的智能体编排栈——来编写一个多智能体系统。以下是我们从0到达到预期准确率（定义为准确推导出的结构化指标百分比，以从Screener下载的实际数据为衡量基准）的历程。

我们从单个智能体开始，给它提供了知识库的上下文（包含约100家上市公司的文档），以及用于应用过滤器的字段和预期的最终输出格式。最初的尝试会在15-20分钟后停止，尝试提取的数据点不到一半。随后我们推动它制定计划，将工作分配给智能体集群。它花费了更多时间，但无法走得更远。在提取的多个字段中，前沿模型难以一致地解释正确的单位（₹、%、₹/股）和指标类型（绝对值 vs 比率 vs 每股数字），或者无法验证所涉及的报告期。

相同的模型。相同的任务。一种方法在自身的上下文中崩溃了。另一种方法完成了。区别不在于智能，而在于结构。

这个故事与计算本身一样古老。硬件不可靠。我们构建了操作系统。数据可能损坏。我们构建了数据库。服务器如同雪花般各不相同。我们构建了Kubernetes。每当一层栈不可靠时，我们就会构建具有保证的基础设施来驯服它，而该保证就成为了产品。每一次成功都不是通过暴露更多能力，而是通过减少表达力来实现的。SQL的表达力不如C，而这正是关键所在。约束带来自由，自由带来约束。如今，被引入生产系统的最具概率性的组件，却运行在与Python脚本相同的抽象之上：没有抽象。

框架是关于代码的观点。基础设施是关于执行的保证。

但正确的基础设施不仅仅是可靠地运行东西。它为开发者提供了构建和迭代AI系统的正确抽象：让复杂的事情成为可能，让简单的事情变得容易。我们构建Arya时遵循了四项保证：

• 可组合的原语
• 崩溃后仍能存活的状态
• 受控的动态性
• 声明式编写

让系统变得可靠的同一套抽象，也让在其之上构建变得简单：前沿模型可以编写生产级智能体，而对多智能体系统的迭代则变成了编辑一个配置文件。即便每一步的可靠性高达 99%，一个 50 步的工作流也只有 60% 的成功率。基础设施不会增加可靠性，它改变的是这道算术。把四个方面都做对，可靠性就会随复杂度扩展，而不是在复杂度下崩溃。

理念一：可组合的原语

大多数智能体框架靠累积而生长。新的层、新的抽象、新的概念，你必须先内化它们才能交付任何真正的东西。到了某个节点，你不再是在构建自己的系统，而是在学习他们的系统。

Arya 走的是另一条路。

它不以层级结构起步，而是从八个扁平的、可组合的原语开始。LLM、Agent、MCP、Node、Ledger、Task Graph、Code Interpreter、Artefact。每一个都只承担单一职责。单独来看，没有一个有用。能力只在正确的关联中涌现——即这些部件如何连接，而非你拥有多少个。

一个聊天机器人和一条五百文档的流水线，都是由同样的八个组件构建的。区别不在部件，而在于它们的组合方式。

这里没有特权层。每个原语都是平等的：一个智能体需要 LLM 来思考，需要 MCP 来行动，需要一个节点来运行。任务图将自身的工作暴露为工具，供其他智能体调用。代码解释器直接调用 MCP，在确定性计算与外部系统之间架起桥梁。每个原语只做一件事，而系统在你把它们连接起来之前什么也不做。

这就是应用于智能体的 Unix 哲学：小的构建块、显式的连接、没有隐藏的耦合。当系统成长时，它靠组合而成长，而非靠堆积。

其结果是，一种在扩展时保持稳定的结构。你最终得到的不是一座纸牌屋，而是某种可以被推理、被扩展、被委派的东西——从单个对话式智能体到企业级流水线。

八个原语。一种组合它们的方式。

层级式组合

这正是类型化接口变得可组合的地方。一个任务图可以作为名为 Agrippa 的 MCP 暴露出来，让其他智能体以工具调用的方式调用整个工作流。调用方看到的是一个函数：输入数据，输出结果。而在这个接口背后，是一条完整的、拥有自身状态、路由和错误处理的多智能体流水线。图调用图，每一层都把复杂度藏在一份干净的契约之后。Agrippa 致敬的是 Marcus Vipsanius Agrippa，奥古斯都时期罗马扩张背后最重要的人物之一。他将军事指挥与大规模工程相结合，修建港口、渡槽、道路和物流系统，使罗马能够在广阔的距离上可靠运转。他留下的遗产不是集中控制，而是可扩展的执行：通过结构委派复杂操作，并保持清晰的问责。

八个原语定义了系统能做什么。但智能体还需要管理它们所知道的东西。上下文如何在步骤之间流动、什么在轮次之间持续、什么被遗忘，这些与组件本身同样重要。

上下文管理

大多数 agent 系统通过无类型的、基于文件系统的方式来管理上下文：把状态倾倒进 JSON 文件、追加到数据库，或者把所有东西都塞进上下文窗口，指望模型能记住。在小规模下这行得通。但这些方式没有作用域、生命周期或访问控制的概念。到第 40 轮时，你要么是 120K token 的所有东西混在一起、模型已经忘了什么重要，要么是一堆文件散落各处、没有任何结构来规定什么该放哪里、谁能读取。

Scroll

Scroll

关键洞见在于上下文的关注点分离。需要一个在工作流早期产生的值？那是账本：该值存在于其路径上，无论哪个节点写入它，它始终在那里，O(1) 查找，永远不会被上下文窗口驱逐。需要模型记住用户说过的话？那是对话历史，你可以为不需要它的步骤禁用它，让 token 成本保持恒定。需要一个人机协作的共享草稿本？那是产物。需要持久化计算？那是代码解释器。多轮上下文管理、用户和组织级记忆——全都变成账本上的简单结构化操作，而不是提示工程问题。

作用域隔离让组合在大规模下安全。代码解释器的全局变量作用域限定在一次组合运行内。磁盘作用域限定在执行运行内：每次运行都有自己的文件系统工作区，因此并行执行永远不会互相踩踏对方的文件，代码解释器成为一个持久化的计算草稿本，任务图无需协调即可共享。

上下文不是一堆东西。它是四个抽屉，每个都带锁和标签。

想法 2：不可变状态账本

大多数 agent 框架把状态当作共享白板。每个 agent 拿起一支记号笔，想在哪写就在哪写。当因为覆盖、崩溃、部分更新而出错时，白板被弄脏了，而且无法撤销。

Arya 把状态当作会计账本。每个条目都是仅追加且不可变的。变更以原子方式提交：要么全部成功，要么全部失败。先前的状态永远不会被修改，永远不会处于风险之中。你随时可以回到任何先前的状态，因为没有任何东西被覆盖。这与数据库恢复和版本控制背后的原则相同：永远不要覆盖已提交的状态，始终创建新状态。每个节点边界都是一个检查点。崩溃恢复轻而易举，因为总有一个干净的快照可供重启。

无争用的并行

每个 agent 都会收到账本的只读快照，完成自己的工作，并生成一个 delta：一个描述变更内容的结构化 diff。在一个分支内，agent 按顺序运行：每个 agent 都能看到它之前所有 agent 的 delta。在并行分支之间，账本完全独立。在汇聚点，所有分支的 delta 会被合并。如果两个并行分支可能写入冲突的键，这会在编写阶段就被捕获：系统会在执行之前就拒绝该拓扑。协调在设计上就是不必要的：分支之间不会相互干扰，而顺序执行的 agent 总是基于已提交的状态进行构建。

与其他方案的对比：

• 消息传递框架：agent 通过非结构化消息进行通信（“收入强劲，增长 15%”）。没有结构，容易产生幻觉，需要手动解析。
• 共享可变状态：Agent A 写入 state["revenue"] = 175000，Agent B 用 185000 覆盖它。现在你需要协商逻辑。

Arya 颠覆了这一点。在边界处进行模式强制——JSON schema 会验证每一次写入。agent 不能返回“收入强劲”。它必须返回 {value: 175000, unit: "Cr"}。类型安全，在编译时就能捕获。

schema 是契约。delta 是事务。账本是审计追踪。其他一切都是对话。

失败而不损坏

在可变系统中，写入过程中崩溃会让状态处于半更新状态，一些字段已写入，另一些缺失，无法知道哪些是哪些。重试会加剧损坏。崩溃后的可变状态是犯罪现场。崩溃后的不可变状态是检查点存档。

账本的工作方式像收据，而不是共享白板。如果节点在返回其 delta 之前崩溃，则不会写入任何内容。账本保持不变。重试是安全的，因为你是从干净的状态重试，而不是在残骸之上重试。

可靠性计算发生了反转：99% 每步 × 50 步 = 60%（使用可变状态）。使用不可变状态 + 独立重试时，每个节点独立重试，接近系统级可靠性目标，而不是指数级衰减

测试也讲述了同样的故事。在可变系统中，测试第 47 步意味着先执行第 1-46 步，并希望没有任何步骤损坏状态。使用不可变性，节点的行为仅取决于它收到的账本快照。相同的账本输入，相同的输出。构造一个模拟快照，运行一个节点，断言结果。这也意味着你可以完全重写第 1 到 47 步，而不会影响第 48 步，只要账本契约保持不变。每个节点都是马尔可夫的：它只依赖于当前状态，而不依赖于你是如何到达那里的。“我们不测试 agentic 工作流”和“100% 测试覆盖率”之间的区别。针对 agent 的单元测试。不是“运行整个流水线并眯着眼看输出”。是真正的单元测试。

完全可观测性是一种涌现属性，而不是一个功能。每一次状态转换都是一条持久化记录。一个关联 ID 贯穿整个执行树。这实现了分布式追踪：为监管机构提供审计追踪，为运维提供瓶颈分析，为优化提供模式挖掘。

想法 3：受控的动态性

在工作流的任何位置，任意混合确定性和 agentic 自由。是滑块，不是开关。

滑块

有些步骤应该是可预测的：路由请求、格式化输出、验证数据。有些步骤则应该思考：分析文档、综合洞察、做出判断。大多数框架迫使你为整个工作流选择一种模式。Arya 让你可以独立设置每个节点：这里确定性，那里智能体化，处处都经过模式验证。每个节点在滑块上的位置都在你的配置文件中明确可见、可审计，只需一行 diff 即可更改。

拓扑作为编排器

图结构就是执行计划。三层各司其职：确定性代码处理循环和条件，图拓扑处理并行和顺序，LLM 处理推理和综合。全部在图里声明，全部由运行时强制执行。

这就是自主智能体的核心失败模式：它们把 token 花在导航上，而不是工作上。一个处理 200 份财务报告的 ReAct 智能体，会为每一份文档推理该选哪份报告、是否已完成、输出什么格式、如何处理边缘情况。那不是分析，那是开销。模型在做 for 循环的工作，做得很糟，还按 token 向你收费。

Arya 将控制平面与数据平面分离。代码和图拓扑处理迭代、分支、错误恢复和调度——这些确定性的部分，永远不该接触上下文窗口。模型处理判断——需要语言理解、领域知识和推理的部分。上下文窗口中的控制流在 token 上是 O(n)，在正确性上是概率性的。代码中的控制流是 O(1) 且确定性的。你不会用神经网络来递增计数器。别再用它来决定下一步做什么了。

代码编排模型，而不是模型编排自己。处理 500 份文档，每个结果存入一个变量，只有最终的综合结果进入上下文窗口。无限的有效上下文。在长上下文基准测试中，由代码编排的小模型比独自推理的前沿模型性能高出 114%。

理念 4：声明式构建

如今，构建多智能体系统是这样的：你写 Python，接上 API 调用，加上重试逻辑，拼上日志，构建状态管理层，写胶水代码在步骤之间传递上下文，然后祈祷它在生产环境中的表现和在你的笔记本电脑上一样。智能体的身份——它做什么——与运行它的脚手架密不可分。改一个提示词意味着要动处理错误恢复的同一个文件。换一个模型意味着要重新测试编排逻辑。每一次更改都是全栈更改。

Arya 颠覆了这一点。规范——你的系统做什么——是一个声明式的 HCL 文件。执行——它如何运行——是运行时的问题。这与让数据库成为可能的分离相同：SQL 描述你想要什么数据，而不是如何获取它。查询规划器独立于查询来优化执行。你的智能体配置描述应该发生什么。运行时决定如何调度、在哪里重试、何时并行。

一旦你将两者分离，开发者体验在每个阶段都会改变：

创作

因为规范与执行分离，规范就像任何其他配置文件一样存放在 git 中。提示词的变更会出现在 git diff 中。回滚就是还原一次提交。为 A/B 评估更换模型只需改一行 llm_uid。无需重写提示词，无需改动流水线。前沿模型可以自己编写规范，因为它写的是声明，而不是程序。

完全用 Terraform（HCL）定义的任务图：边将节点连接成线性流水线，没有任何命令式代码。声明式的 nodes 块让执行流程一目了然，并且像任何其他基础设施一样可版本控制。

同一个任务图模块被多次导入，每次使用不同的 LLM，每个仅需 4-5 行 HCL。为 A/B 评估更换模型只需改一行 llm_uid——无需重写提示词，无需改动流水线。

部署

一次编写，随处运行。同一份声明可以编译成不同的执行模式，用于聊天机器人时在进程内运行，用于批处理作业时用 Temporal。声明 2000 个并行任务，运行时负责调度和背压。无效的拓扑结构在编译时就会被捕获，而不是在凌晨 3 点。

调试

我们的调试服务以罗马的《每日纪闻》（Acta Diurna）命名，那是第一份执行日志，旨在让政府决策公开可查，以获得更好的可见性。每一次状态转换都被持久化。一个关联 ID 贯穿整个执行树，使分布式追踪变得轻而易举。导航到任意节点，查看确切的账本、提示词和 LLM 响应。用不同的提示词重放。跨运行查询模式，哪些节点失败最多，哪些提示词导致 schema 违规。让编码智能体接入 Acta 来诊断成千上万次运行。

并行调试子智能体：Claude Code 并行生成四个子智能体，每个都调用 Acta MCP 服务来追踪单个会话的不同部分——同时检查节点血缘、账本状态、智能体步骤和数据流。过去需要在所有追踪中手动翻找日志的工作，现在完全自动化了。

生成的缺陷报告——调试会话会生成一份结构化报告，指出运行中的主要问题以及改进点所在。每项发现都可追溯到具体的节点和步骤，为你提供可操作的后续步骤，而不是原始日志。

用于深入探究某个会话并直观查看每一步实际发生情况的 UI。

优化

声明式结构有一个隐藏的好处，它让你的智能体系统可被机器优化。提示词是配置文件中的参数。执行追踪是结构化数据。将二者结合，你就可以自动地对提示词变体进行进化搜索。每次运行都会生成按节点划分的反馈，这一步的输出是否符合 schema？下一步是否成功？传统强化学习在 50 步链条的末端只得到一个奖励信号，50 步中哪一步失败了？不清楚。Arya 在每个节点边界进行验证。提示词变得可优化。你的智能体系统每运行一次都会变得更好。

Arya 如何与前沿编码智能体互补？

我们把前沿模型视为编译器。它们将人类意图翻译成执行计划。基础设施则是运行时，它保证执行可靠、可观测且可复现。

大多数人忽略的悖论是：模型越强大，基础设施就越关键。更快的 CPU 并没有消灭操作系统，反而要求更精密的调度器。能力更强的微服务并没有消灭 Kubernetes，反而放大了对编排的需求。更好的智能体不会消除对基础设施的需求，它们只会让可能之事与可靠之事之间的差距变得更大。

数百万开发者在 IDE 中编写软件；它在数十亿台服务器上执行。编写工具和执行平台是不同的层。一直都是如此。

模型是编译器。基础设施是运行时。你不会在没有操作系统的情况下发布二进制文件。

我们构建 Arya 是因为别无选择。作为一家大规模运营的基础模型公司，智能体生态系统中的每一种故障模式最终都会出现在我们的日志中，而现有的任何方案都无法经受生产环境的考验。所以我们构建了能够经受住考验的基础设施，团队坐落在分布式系统与模型内部机制的交汇处——这是这个问题真正能够被解决的唯一地方。智能体的十年不会由谁构建出最强大的模型来定义，而会由谁为每一位开发者提供让这种能力变得可靠的基础设施来定义。我们打算成为那一层。