Flywire 如何用 Orbit 构建可控的 Agent 工作流：Eduardo Simon 与 Javier Casal 分享

简要说明Brief Description

Agents in Orbit: Workflows， Not Autopilot — Eduardo Simon & Javier Casal， Flywire

目录Table of Contents

• Flywire 的平台团队和支付背景
  Flywire's platform team and payment context
• 从有机实验到 Orbit
  From organic experiments to Orbit
• 基于现有基础设施自建还是采购
  Build versus buy on existing infrastructure
• YAML 工作流与受限代码审查
  A YAML workflow and restricted code review
• 触发器与工程应用场景
  Triggers and engineering use cases
• 运行时与编排的分离
  Separating runtime and orchestration
• 限制、锁和执行环境
  Limits, locks and execution environments
• 按步骤访问与共享技能
  Per step access and shared skills
• 结构化输出与评估差距
  Structured outputs and evaluation gaps
• 已报告的运行情况、采用情况与路线图
  Reported runs, adoption and the roadmap

Flywire 的平台团队和支付背景Flywire's platform team and payment context

大家好，欢迎各位。我叫 Edu，和 Javi 一起代表 Flywire 的 AI 平台体验团队。我们的核心使命是构建实用的智能体基础设施，在遵循既定工程标准和实践的同时，赋能软件工程师。今天，我们将分享结构化工作流自动化如何创造真正的企业价值，并确保整个开发流程具备可控性、安全性和可靠性。在深入探讨 AI 平台的技术细节之前，先为大家介绍一些关于 Flywire 的基本背景。Flywire 致力于处理全球各行业最复杂的支付业务，涵盖教育、医疗、旅游和商业服务等领域。目前，我们为全球 240 多个国家和地区的 5,000 多家客户提供服务。由于我们处理高价值的国际交易，监管合规、隐私和安全绝非可有可无的附加项。Hello everyone and welcome. My name is Edu and alongside Javi, we represent the AI platform experience team at Flywire. Our core mission is to build practical agentic infrastructure that empowers our software engineers while following our established engineering standards and practices. Today we'll share how structure workflow automation delivers real enterprise value, ensuring control, safety, and reliability across our development process. Before we dive into the deep technical details of our AI platform, let us give you some essential context about Flywire. Flywware is built to process the world most complex payments across global industries like education, healthcare, travel, and business services. Today, we serve over 5,000 clients across more than 240 countries around the world. Because we process highv value international transactions, regulatory compliance, privacy and security are not optional add-ons.

这些是我们业务的核心要求。我们遵循 PCI、DSS 和 SOC 2 等严格的合规框架。这意味着客户数据、个人身份信息和支付详情必须得到全面保护。我们不能在缺乏严格治理和架构边界的情况下，简单地将敏感上下文传递给第三方服务。为了让你了解我们的工程组织，我们的团队分布在全球各地，拥有约 400 名软件工程师。我们的技术栈丰富多样，包括 Java、Ruby、Go、Python、.NET 和 PHP。我们构建和运行的几乎所有内容都部署在 Victoria 上——这是我们的内部平台即服务，运行于 GitLab 和 AWS 基础设施之上。Victoria 提供标准化的构建流水线和一致的部署实践。They are core requirements of our business. We operate under strict compliance frameworks like PCI, DSS and so 2. This means that customer data, personal identification and payment details must remain completely safe. We cannot simply take sensitive context and pass it to third party services without strict governance and architectural boundaries. To give you an idea of our engineering organization, we have around 400 software engineers distributed globally across our teams. We maintain diverse technology stacks including Java, Ruby, Go, Python,.NET, and PHP. Almost everything we build and run is deployed on Victoria, our internal platform as a service that operates on top of GitLab and AWS infrastructure. Victoria provides standardized build pipelines and consistent deployment practices.

所以So

从有机实验到 OrbitFrom organic experiments to Orbit

我们的 AI 之旅是如何开始的？大约 6 个月前，也就是 4 月，我们正式组建了专门的 AI 平台体验团队。在那之前，Flywire 各地热衷于 AI 的工程师就已经开始试用 AI 工具、创建技能、搭建 MCP 服务器，还组装出了一个早期的代码审查机器人。这些自发的行动证明，我们的工程师希望借助 AI 实现自动化；同时也表明，我们需要一支专门的团队，为安全可靠的智能体解决方案提供基础设施。从那以后，我们快速推进，内部工具的提交次数已接近一千次。但行业的脚步从未停歇。在同样的 6 个月里，光是 Claude Code 就发布了 160 多个版本，几乎每天一个；各大 AI 实验室也发布了 20 多个新模型。每周都会带来一个新模型、一种新工具，或一种新的工作方式。how did our AI journey begin? About 6 months ago, back in April, we formally established the dedicated AI platform experience team. Even before that, passionate engineers across Flywire were already experimenting with AI tools, creating skills, building MCP servers, and assembling an early code review bot. That organic activity proved that our engineers wanted AI automation. It also showed that we needed a dedicated team to provide infrastructure for safe and reliable agendic solutions. Since then, we have moved fast with close to a thousand commits to our internal tool. But the industry does not stop. In the same six months, Cloud Code alone published more than 160 releases, almost one per day, and the major AI labs release more than 20 new models. Every week brings a new model and a new tool or a new way of working.

我们的挑战不仅是快速构建，还要保持跟进。Our challenge is not only to build fast but to keep up.

主持人：这就引出了 Orbit，我们自己的工程琐事终结者。Orbit 是一个内部平台，通过将 LMS 直接纳入结构化工作流，消除日常工程中的重复任务。Orbit 不会让 AI 智能体在开放式循环中自由运行，而是将确定性代码与少量 LLM 步骤结合起来。我们把重复的流程逻辑固化为代码，只有在确实需要推理时才调用模型。Host: This bring us to Orbit, our own toil killer. Orbit is an internal platform that eliminates daily engineering repetitive tasks by including LMS directly into structural workflows. Instead of letting AI agents run freely in open-ended loops, Orbit pairs deterministic code with a small LLM steps. We crystallize repetitive procedural logic into code and we call a model only when reasoning is actually needed.

基于现有基础设施自建还是采购Build versus buy on existing infrastructure

在评估自建还是采购时，对我们的环境而言，自建完全是合理的选择。前沿模型让功能开发变得非常迅速，大幅降低了定制平台的成本。更重要的是，作为一家处理 PCI、PII 和 PHI 数据的金融企业，将执行过程保留在现有的 Victoria 基础设施内，可以确保敏感数据始终不会脱离我们的控制环境。我们也因此无需经历漫长的供应商安全审查，也不必承担额外的合规工作。那么，实际的工作流是什么样的呢？Orbit 中的每个智能体都定义在彩票娱乐When we evaluated whether to build or buy, building inhouse made complete sense for our environment. Frontier models made feature development really fast which drastically lowers the cost of a custom platform. More importantly, as a financial enterprise handling PCI, PII and PHI data, keeping execution inside our existing Victoria infrastructure ensures that sensitive data never leaves our control environment. We also skip long vendor security reviews and extra compliance work. So what does a workflow actually look like? Every agent in orbit is defined in

YAML 工作流和受限代码审查A YAML workflow and restricted code review

一个存放在代码仓库中的 JML 文件，与其他代码一样经过相同的合并请求审查流程。以我们的代码审查代理为例。它从一个触发器开始：当工程师在合并请求中提及审查机器人时，Gilda webhook 就会触发。接下来，一系列确定性活动会获取合并请求元数据、对其风险等级进行分类、加载之前的审查发现，并克隆代码仓库。然后，我们在一个 LLM 步骤中调用模型；模型可以读取代码，但无权修改代码，而且必须按照严格的输出架构作答。最后，另一个确定性步骤会将审查发现回传到合并请求中。这就是我们所说的工作流，而不是自动驾驶。代码负责处理可预测的部分，只有在确实需要推理时才会调用模型。a single JML file that lives in a repository and goes through the same merge request review as any other code. Take our code review agent as an example. It starts with a trigger, a Gilda web hook that fires when an engineer mentions the review bot on a merge request. From there, a sequence of deterministic activities, fetches the merge request metadata, classifies its risk tier, loads prior findings and clones the repository only. Then we call the model in an LLM step that can read the code but has no permission to modify it and that must answer in a strict output schema. Finally, another deterministic step post the findings back to the mer request. This is what we mean by workflows, not autopilot. Code handles the predictable parts and the model is called only where reasoning is actually needed.

我们有意选择从 JAML 文件和请求审查流程入手。YAML 是我们的工程师已经熟悉的格式，而且审查流程也符合他们日常的工作方式。这也让代码库更适合 AI 使用。编码代理可以像人一样轻松地读取、编写和审查工作流定义。不过，并非所有用例都来自工程团队。对于企业用例，我们正在考虑在 Orbit UI 中提供一个创作工具，让人们可以通过拖放来构建工作流，并……We choose to start with JAML files and a request review process on purpose. YAML is a format our engineers already know and the review works the way they already work every day. It also keeps the codebase AI friendly. Coding agents can read, write, and review workflow definitions as easily as people can. However, not every use case comes from an engineering team. For corporate use cases, we are considering an authoring tool in the orbit UI where people can build a workflow by dragging and

触发器与工程应用场景Triggers and engineering use cases

从一组预定义活动中进行选择，无需编写作业。工作流可以通过三种方式启动。工程师和其他系统可以直接调用 Orbit 的内部 API，也可以使用我们的内部 CLI。来自 GitLab、Jira、Sentry 和 AWS 的 Webhook 会在事件发生时启动工作流，例如创建新的合并请求或出现新的生产环境错误。定时任务会按固定频率运行工作流，例如每日翻译同步、功能标志清理和知识库刷新。除了这些入口之外，我们目前还在为 Orbit 构建 MCP 服务器，使我们在 FlyWire 使用的其他 AI 服务和工具能够直接启动工作流。例如，工程师将能够在 Slack 中通过 CL 标签请求 Claude 运行 Orbit 工作流，而无需离开当前对话。我们从明确且影响重大的用例入手。dropping from a set of predefined activities without writing a jam. A workflow can start in three ways. Engineers and other system can call Orbit's internal API directly or using our internal CLI. Web hooks from GitLab, Jira, Sentry and AWS start a workflow from the moment something happens such as a new merge request or a new production error. Schedule jobs run workflows on a fixed cadence like our daily translation syncs, feature flag cleanups, and knowledgebased refreshes. Beyond these entry points, we are currently building an MCP server for Orbit so that the other AI services and tools we use across FlyWire can start workflows directly. For example, an engineer will be able to ask cloth in Slack through CL tag to run an orbit workflow without ever leaving the conversation. We started small with clear high impact use cases.

首先是日常工程工作：自动审查合并请求中的代码，我们的 Victoria 升级代理则会自动修复 Victoria 界面中的问题。其次是翻译：现在，一个工作流就能处理整个流程——获取新增字符串、翻译、更新文件，并将更新后的文档通知相关团队。第三是生产环境错误：Sentry webhook 会启动 Sentry 调查代理，由它评估问题、在 Slack 中发布评估结果，并在同一处分享包含修复方案的合并请求。在支持工作方面，工单分流会对新工单进行分类，并将其转给合适的工程团队。AI 就绪度评分卡用于衡量代码仓库对 AI 辅助开发的准备程度，修复代理则会根据发现的问题采取行动。最后，J 实现代理会接收工单并将其转化为合并请求。First the daily engineering work automated code reviews on mer request and our Victoria upgrades agent which fixes Victoria interf findings automatically. Second translations one workflow now handles the full cycle. It fetches the new strings, translates them, updates the files and notifies the teams with the updated docs. Third production errors. A sentry web hook starts the sentry investigator. It assesses the issue, post the assessment in Slack and shares the mer request with a fix in the same place. On the support side, ticket triage classifies new tickets and routes them to the right engineering area. AI reading is a scorecards measures how ready a repository is for AI assisted development and a fixer acts on the findings. Finally, the J implement takes a ticket and turns it into a mer.

它的运作方式就像一座小型的自动化工厂。我们发现，它最大的优势之一是可以跨多个代码仓库批量进行更改，从而实现大规模软件工程。这对于迁移、库更新和弃用操作来说非常方便。我们还用它来运行 Cloud Doctor，并推出自己的 AR 就绪度评分卡。尽管有了这些自动化手段，合并请求仍然是我们的工作单元，也是人工参与流程的环节。我们身处受监管的环境，因此仍由人员审核并批准这些合并请求。接下来，让我们深入了解 Orbit 的技术架构。It works like a small toward factory. One of the biggest benefits that we found is that we can make changes in bulk across many repositories that lets us do software engineering at scale. It is very convenient for migrations, library updates and deprecations. And we also use it to run cloud doctor and to launch our own AR readiness scorecard. Even with all this automation, the mer request is still our unit of work and it is where a human stays in the loop. We operate in a regulated environment, so people still review and approve those merge requests. Let's take a deeper look at the technical architecture of Orbit.

分离运行时与编排Separating runtime and orchestration

最初，我们在 AWS ECS Fargate 上采用了简单的容器设置，将编排层框架和运行时环境放在同一个容器中。随着需求不断增长，我们逐步将编排层、智能体运行时环境和会话状态拆分为独立组件。这样可以提升隔离性、可维护性和资源分配效率。系统的弹性也因此更强：智能体出现错误不会导致沙箱崩溃，而且我们可以独立扩展各个组件，并灵活适应不断变化的需求。Fargate 支持弹性扩展任务，因此我们能够并行运行大量智能体。部署 orbit 也非常简单，因为我们已经有了 Victoria——我们现有的 PaaS，可以轻松扩展应用。但Originally we began with a simple container setup on AWS ECS Fargate where the orchestration layer harness and the runtime environment lived inside the same container. As our needs grew, we evolved towards separating the orchestration layer, the agent runtime environment and the session state into distinct components. This improves isolation, maintainability and resource allocation. It also makes the system more resilient because an error in the effort does not kill the sandbox and it lets us scale each piece independently and adapt to changing requirements. Fargate lets us scale task elastically so we can run a very large number of agents in parallel. It was also really easy to deploy orbit because we already had Victoria our past that scales applications without any effort. But

限制、锁定与执行环境Limits, locks and execution environments

这种规模需要设置防护措施，以免平台遭到滥用。首先是超时限制：每个智能体运行到可配置的时长后都会停止。其次是速率限制，默认设置得比较严格。API 集成出错时，可能会开始生成成千上万个智能体，让我们的构建规模膨胀很多。这些限制可以控制这种情况。第三是并发控制。我们的控制平面使用锁来防止同一任务被重复执行。例如，如果代码审查已经在进行中，我们就会丢弃重复请求。在 Victoria 上运行智能体也受到容器限制。Victoria 使用标准的 Fargate 任务定义，因此容器轻量且受到严格限制。我们的基础智能体容器包含常见的语言运行时，但有意不包含 Bundler、Maven 和 Composer 之类的包管理器。that scale needs guard rails. so the platform is not misused. First, timeouts. Every agent stops after a configurable amount of time. Second, red limits, which are aggressive by default. A broken API integration could start spawning thousands of agents and make our build much bigger. The limits keep that under control. Third, concurrency control. Our control plane uses locks to prevent duplicate executions of the same task. For example, if a code review is already running, we drop the duplicated request. Running agents in a Victoria comes with container limits. Victoria uses standard Fargate task definitions. So the containers are lightweight and tightly restricted. Our baseline agent container includes the common language runtimes. But it intentionally leaves out package managers like Bundler, Maven, and Composer.

因此，像我们的 Jer 实现这样的重型代理无法轻松地在容器内运行原生构建或单元测试。我们 4 月启动 Orbit 时，AWS Lambda 微型虚拟机还不存在。AWS 在 6 月发布了它们。因此，我们的第一个版本只能运行在 Fargate 上。这些是托管式微型虚拟机，运行方式类似于可暂停和恢复的 Lambda 函数进程，因此可以暂停，并从中断处继续运行。这非常适合代理式执行的特性。现在，我们会根据项目类型选择运行时来使用它们。每种技术栈都能迅速在隔离环境中获得自己的工具链。这还不算完整的沙箱化，我们正积极朝这个方向推进。我们的目标是支持 Docker-in-Docker 或多个微型虚拟机之类的配置，让代理能够运行测试或执行更多任务。So heavy agents like our Jer implement cannot easily run native builds or unit tests inside the container. When we started orbit in April, AWS Lambda microVMs did not exist yet. AWS released them in June. So our first version run only on Fargate. These are managed microVMs that work like Lambda functions resumable processes. So they can pause and continue where they stop. that fits the nature of agentic execution really well. So we now use them with a runtime chosen by project type. Each tech stack gets its own tool chain quickly in an isolated environment. This is not full sandboxing yet and we are actively moving there. The goal is to support setups like dockering docker or multiple microvms so agents can run test or more

每一步的访问权限与共享技能Per step access and shared skills

在任何代码仓库中执行复杂验证。在每个 LLM 步骤中，我们没有自己构建运行框架，而是复用 Claude Agents SDK，也就是为 Claude Code 提供支持的同一套运行框架。它开箱即用，提供成熟且经过充分测试的运行框架，支持工具使用、子代理和技能。因此，我们可以专注于工作流，而不是底层基础设施。我们在此基础上增加的是控制能力。对于每个步骤，我们会限制四项内容：代理可以访问的网络、可以调用的工具、可以加载的技能，以及可以使用的 MCP 服务器，并精确限制每个服务器允许使用的工具。所有这些都在 YAML 文件中声明。例如，代码审查步骤可以读取和搜索代码，但不能编辑文件或推送更改。我们的中央调查器可以通过 MCP 服务器查询追踪记录，但只能使用一小组只读工具。complex verifications on any repository. Inside each LLM step, we did not build our own harness. Instead, we reuse the clot agents SDK, the same harness that powers cloud code. This gives us a mature, well- tested harness with tool usage, sub aents, and skills out of the box. So, we can focus on the workflow rather than on the plumbing. What we add on top is control. We restrict four different things for every step. the network the agent can reach, the tools it can call, the skills it can load, and the MCP servers it can use down to the specific tools allowed from each server. All of this is declared in the YAML file itself. A code review step, for example, can read and search the code, but cannot edit files or push changes. And our central investigator can query traces through our MCP server, but only with a short list of readonly tools.

在实践中，每个 LM 步骤只会运行所需的轴，而且这个轴和其他代码一样清晰可见、可供审查。技能本身统一来自一个地方。在 Flywire，我们维护着一个中央技能仓库，并将其作为云代码插件市场在内部发布；orbit 会在构建时连接到该市场。这意味着同一套技能可以在两个地方使用：工程师可以在笔记本电脑上的云代码中运行它，orbit 也可以在自动化工作流中运行它。这种共享基础也影响了我们给团队的建议：从技能开始。技能编写成本低、易于迭代，而且从第一天起就能发挥作用。一旦团队确认某项任务值得自动化，我们就会将其迁移到 orbit，并把它转化为工作流。可预测的部分会变成确定性代码。模型只会在能带来价值的地方被调用，而且每次运行都会比开放式会话更可靠、成本更低。In practice, each LM step runs with only the axis it needs and the axis is visible and reviewable like any other code. Skills themselves come from a single place. At Flywire, we maintain a central repository of skills that is published internally as a cloud code plug-in marketplace and orbit connects to that marketplace at build time. This means the same skills works in two places. An engineer can run it in cloud code on their laptop and orbit can run it inside an automated workflow. That share foundation also shapes our recommendation to teams. Start with the skill. Skill is cheap to write, easy to iterate on, and useful from day one. Once a team is sure that a task is worth automating, we move it into orbit and turn it into a workflow. The predictable parts become deterministic code. The model is called only where it adds value, and each run becomes more reliable and less expensive than an open-ended session.

工作流也会在后台运行，因此工程师无需一直守着打开的会话并逐步引导其运行。这意味着更少的Workflows also run in the background, so engineers do not have to sit with an open session and guided step by step. That means less

结构化输出与评估差距Structured outputs and evaluation gaps

减少上下文切换，让需要它们的工作有更多时间。除了运行时隔离，我们还高度依赖结构化输出，以确保系统级可靠性。Orbit 工作流中的每个 LM 步骤都会对模型响应强制执行严格的 JSON schema。通过限制输出格式，我们确保后续的执行分支、错误处理和状态转换由确定性的控制流驱动，而不是依赖不可预测的字符串解析。如果 NLM 响应未能通过预期 JSON schema 的验证，Orbit 会在继续执行前自动触发有针对性的重试或回退流程。我们依赖的另一项关键模式是隔离式组件评估。在合成基准测试环境中评估复杂的端到端智能体工作流，往往会产生较大噪声、成本高昂，而且难以稳定复现。context switching and more time for the work that needs them. Beyond runtime isolation, we also rely heavily on structure output to guarantee systemic reliability. every LM step in an orbit workflow enforces strict JSON schemas for model responses. By constraining output formats, we ensure that subsequent execution branches, error handling, and state transitions are driven by terministic control flow rather than unpredictable string parsing. If an NLM response fails validation against the expected JSON schema, Orbit automatically triggers a targeted retry or fallback pass before proceeding. Another crucial pattern we rely on is isolated component evaluation. Evaluating complex end to end agentic workflows in synthetic benchmark environments is often noisy, expensive, and difficult to reproduce consistently.

我们不再尝试从头到尾评估整个工作流，而是通过评估工具单独隔离各个 LLM 步骤。通过将精确的历史状态和上下文直接注入特定工作流节点，我们可以评估模型输出质量、衡量 PROM 调整，并快速、经济地发现性能回退。那么，我们如何判断一个智能体是否足够好？如今，一个新智能体通常会在通过一次 b 检查后进入生产环境。团队会用几个真实案例测试它，并确认其行为符合预期。投入生产后，我们会使用 OpenTelemetry 端到端追踪每次执行，包括每项活动、模型调用和工具调用。随后，我们会从真实执行中提取追踪记录，并将其添加到黄金数据集。目前，每个黄金数据集都会与代码一同在代码库中进行版本管理，并按需运行。Instead of trying to evaluate entire workflows from start to finish, our evaluation harness isolates individual LLM steps. By injecting exact historical state and context directly into specific workflow nodes, we can evaluate model output quality, measure PROM adjustments, and catch performance regressions quickly and cost effectively. So, how do we know that an agent is good enough? Today, a new agent usually reaches production after a b check. The team tries it on a few real cases and confirms that it behaves as expected. Once it runs in production, we trace every execution end to end with open telemetry, including each activity, model call, and tool call. We then extract traces from real executions and add them to a golden data set. For now, each golden data set is version in the repository next to the code and we run it on demand.

基于这些结果，我们会改进提示词或更换模型，然后再次运行数据集进行比较。我们目前还没有在线评估，但正在内部开展相关工作。我们的目标是让整个评估循环都能在 orbit 中通过 UI 或 MCP 服务器完成。首先，部署你的智能体。然后，监控并评估它在生产环境中的执行情况。最后，根据评估结果改进智能体，无需再次部署。这就是我们评估工作的 Roma：在一个地方发布、衡量并改进每个工作流。这种方法带来的运营影响。Based on those results, we improve the prompt or change the model and we run the data set again to compare. We do not have online evaluations yet, but we are working on them internally. Our goal is to run the whole evaluation loop inside orbit from the UI or through the MCP server. First, you deploy your agent. Then, you monitor and evaluate its execution in production. Finally, you improve the agent based on those evaluations without the need to deploy it again. That is our Roma for evaluations. One place to ship, measure and improve every workflow. The operational impact of this approach

已报告的运行情况、采用情况与路线图Reported runs, adoption and the roadmap

在我们的工程组织中，这产生了显著影响。仅在过去 30 天里，我们的自动化代码审查代理就完成了 9,700 多次运行，平均每个合并请求耗时不到三分钟。除了协同审查之外，我们的审计修复器还发起了 159 个合并请求，用于修复存在漏洞的依赖项；AI 就绪度修复器则改进了大约 80 个代码仓库。Victoria linter 修复器修复了 413 个项目，合并冲突解决器运行了 921 次。在这些工作流中，我们总共执行了 11,000 多次任务，成功率达到 99%。回顾我们的历程，采用自助服务模式是我们做出的最佳决策之一。标准化的防护措施让 SR、安全、IT 和支持团队的工程师能够轻松、安全地构建自定义工作流步骤。我们还认识到，成本控制始于模型选择。has been significant across our engineering organization. In the past 30 days alone, our automated code review agent completed over 9,700 runs, averaging under three minutes per merge request. Beyond co- review, our audit fixer open 159 merge requests to fix vulnerable dependencies and the AI readiness fixer improve around 80 repositories. The Victoria llinter fixer fixed 413 projects and the merch conflict resolver run 921 times. Across these workflows, we run over 11,000 executions with a 99% success rate. Reflecting on our journey, adopting a self-service model was one of the best decisions we've made. A standardized guard rays allow engineers across SR, security, IT, and support to build custom workflow steps easily and safely. We also learned that cost control starts with model selection.

并非每个步骤都需要能力最强的模型。因此，工作流中的每个 LLM 步骤都会声明自己的模型。例如，规划步骤和实现步骤可以使用不同的模型。让模型与任务相匹配有助于控制成本，这也是我们将具备成本意识的模型路由器列入路线图的原因。另一方面，管理数据隔离仍是一项持续性的责任。我们严格区分工程 SDLC 数据、企业运营数据和敏感的支付生产数据。此外，由于自动化需求很高，保持专注并优先处理高影响力工作至关重要。展望未来，我们的路线图重点在于扩展平台功能并提升整体架构的灵活性。我们正积极推进全面沙箱化，使代理能够在各种项目类型中无缝处理复杂构建、本地环境和测试套件。Not every step needs the most capable model. So each LLM step in a workflow declares its own model. For example, a planning step and an implementation step can use different models. Matching the model to the task keeps cost under control and it is why a cost aware model router is in our road map. On the other hand, managing data separation remains an ongoing responsibility. We maintain a strict distillation between engineering SDLC data, corporate operational data and sensitive payment production data. Additionally, because demand for automation is high, maintaining focus and prioritizing high impact work is essential. Looking ahead, our road map focuses on expanding our platform features and increasing overall architecture flexibility. We are actively moving towards a complete sandboxing so agents can handle complex builds, local environments, and test suits seamlessly across all project types.

展望未来，我们还将引入可恢复会话，以处理复杂的多步骤任务。我们也在将更多评估工具直接集成到 Orbit 中，让团队能够在平台本身衡量其工作流的质量。与此同时，我们正在重构编排层，使其不受特定模型限制，从而能够灵活地在不同模型供应商之间进行路由，其中包括一个自动模型路由器，可为任务选择成本效益最高的模型。这将帮助我们在持续扩展平台的同时控制成本。我们还希望让平台不受特定执行框架的限制，这样就不会被单一框架绑定。最后，总结一下我们的三点经验。第一，从小处着手。选择一项重复性强、定义明确的任务，在扩大规模之前先验证它确实可行。第二，只在模型能发挥价值的地方使用它。Moving forward, we are also introducing resumable sessions to handle complex multi-step task. We are also building more evaluation tools directly into orbit so teams can measure the quality of their workflows on the platform itself. In parallel, we are refactoring orchestration layer to be model agnostic, enabling flexible routting across different model vendors, including an automated model routter that selects the most cost-ffective model for its task. that will help us control cost as we keep scaling the platform. We also uh want to make the platform harness agnostic so that we are not tied to a single harness. To wrap up, here are three things we learn. First, start small. Pick a repetitive well-defined task and prove it works before you scale it. Second, use the model only where it adds value.

一切可预测的内容都保留为代码，这正是工作流程可靠的关键。第三，要设置防护措施，并让人类参与其中。明确负责人、限制，以及可能的滥用请求。这样，我们就能从 AI 实验迈向工程团队每天都会使用的工作流程。Everything predictable stays as code and that is what keeps the workflows reliable. And third, keep guard rails and humans in the loop. Owners limits and may request abuse. That is how we move from AI experiments to workflows our engineerings use every day.

嘉宾：非常感谢大家今天抽出时间并给予关注。如果您还有其他问题或意见，欢迎随时联系我们。Guest: Thank you all so much for your time and attention today. Feel free to reach out to us in case you have further questions or comments.