莫谢·桑博尔，Lightrun 客户解决方案副总裁 – 采访系列

莫谢·桑博尔，Lightrun 客户解决方案副总裁，在软件工程、架构、云基础设施和客户面向技术领导方面拥有超过二十年的经验。加入 Lightrun 之前，他在谷歌工作了近十年，担任过多个领导职位，包括云客户工程经理，帮助组织采用和扩展谷歌云技术。在他的职业生涯早期，桑博尔在 Oracle、Sun Microsystems、BMC Software 和 JPMorgan Chase 担任过工程和开发领导职位。在 Lightrun，他最初领导全球解决方案工程团队，后来成为客户解决方案副总裁，专注于帮助客户采用公司的 Runtime Insights 技术，并将其能力转化为可衡量的业务和开发者生产力收益。

Lightrun 是一个 AI 本土的工程可靠性平台，旨在为开发者和 AI 代理提供对软件行为的直接可见性。其技术可以动态捕获日志、快照、指标、跟踪、变量值和执行上下文，从而无需代码更改或重新部署即可从活跃应用程序中获取信息。该公司正在通过 Lightrun MCP 将此运行时智能扩展到 AI 辅助软件开发，使用模型上下文协议为编码助手和代理工具提供活跃应用程序上下文，而不是仅依赖静态源代码。这使得 AI 系统能够调查生产问题、验证假设和支持根因分析，同时纳入企业控制，如基于角色的访问和敏感数据编辑。

您的职业生涯跨越了软件开发、架构、云客户工程和客户解决方案等多个领域。这种多样化的经验如何帮助您理解令人印象深刻的 AI 代理演示和可靠的生产系统之间的差异？

令人印象深刻的 AI 代理演示和可靠的生产系统之间存在巨大的差异，因为代理只是一个生产就绪系统的一部分。框架和周围环境同样重要。必须强制执行最小特权访问、监视活动、保存审计跟踪、防止不可接受的风险操作，并在必要时引入人类干预。

代理系统与传统软件有着根本的不同，因为开发者不指定系统的行为。我们设定目标、提供工具和指导，模型决定如何继续。这种灵活性很强大，但也使得系统的行为更难预测。

对于企业，尤其是受监管的行业，通常可以工作或需要不可预测的时间来完成的生产工作流是不可接受的。生产环境包含敏感数据、源代码和知识产权，因此组织需要防止代理暴露这些信息或采取创造性但不可接受的方式来实现其目标。这变得越来越重要，因为每周都会出现一个新的 AI 系统，为了实现目标而变得容易受到安全漏洞的影响或造成安全漏洞。

大多数我交谈的领导者仍然像评估新员工一样评估代理，关注能力、判断力和输出。真正的问题不是代理是否足够聪明，而是周围的系统是否能够捕获和控制代理不够聪明的时刻。

许多企业最初认为构建 AI 代理主要是编写有效提示的问题。组织对生产就绪代理背后的工程、架构和运营要求有什么误解？

我认为最大的误解是对 AI 的力量的天真信仰，即只要给予合适的提示、相关上下文和合适的工具，AI 就可以解决任何挑战。团队将其大型语言模型连接到代码、文档、票据和历史遥测数据，并期望它能够准确地推理出正确的决定。

他们没有建立一个验证模型来验证 AI 的每一步推理。AI 的一个伟大优势是它使用概率推理，找到并采取多种可能的路径来达到目的。在复杂、相互连接的生产环境中，这种优势带来了严重的风险：单个决定可能触发下游回归、沉默故障或其他意外行为，威胁到运行系统的运营恢复力。

这就是确定性引导的必要性。代理的推理可以保持概率性，但围绕其行为的检查点不能。对于参与工程工作流的代理，这需要一个验证步骤来检查其假设的下一个操作与生产现实，并且是一个确定性门而不是另一个概率猜测。它需要看到该决定的后果，并且只在确定该操作是安全的之后才批准它。

查看第一波内部开发的企业代理，您看到什么最常见的架构错误？哪些问题可以逐步解决，而不是需要完全重建？

我反复提到的核心问题是验证。代理可以变成一个黑盒：它们从各种来源收集信息并做出看似合理的决定，但可能不适合复杂、混乱的生产环境的现实。

这指向了一个更根本的转变，这也是我们在 Lightrun 不断讨论的内容，因为我们帮助客户为其工程组织构建代理自动化。团队需要重建代理流本身，并在代理的行为上设置门槛，以确保其使用工具受到监督、审计和审查。为代理提供强大的反馈循环，包括实时运行时可观察性，关注当前正在发生的事情。这就是使代理能够验证其自身设计决策、根因分析和错误缓解建议的基础，而不是依赖静态代码分析或旧遥测数据。

完全重建并不是唯一的选择。可以逐步完成的事情，并且不需要突破性创新，但至关重要的是，投资于指导代理行为的技能。精心设计和评估的技能可以将代理引向确定性工作流的方向。团队不需要重新架构整个系统就能获得这种好处。他们需要像对待任何其他生产逻辑一样，对技能设计进行严格的评估。

为什么一些代理在受控测试中表现良好，但在面对真实用户、不断变化的数据、外部工具和复杂生产环境时，开始产生不一致、不完整或误导性的结果？

受控测试消除了大多数将定义生产现实的变异性。数据经过策划，工具行为可预测，权限已知，我们覆盖了预期的路径。当您发布代理与真实用户及其影响交互时，您不再比较同类事物。

用户引入模糊的请求并运行并发操作，系统状态不断变化，代理通常必须从部分数据中工作，外部工具带来了自己的延迟和故障模式。此外，由于模型是概率性的，每个新变量都创建了一个新的潜在分歧或复合之前错误的地方。

危险之处在于，代理可以继续看似正常运行，同时产生不正确但看似合理的响应，这些响应是基于部分数据或过时信息构建的。这就是为什么生产代理需要持续评估，这种评估在启动后继续运行，明确处理缺失数据和工具故障，以及在高影响操作完成之前对决定进行实时验证的原因。

Lightrun 强调为 AI 系统提供运行时上下文的重要性。运行时上下文提供了什么信息可能被传统日志、指标和跟踪所忽略，为什么这种信息在诊断代理故障方面尤其重要？

传统的可观察性显示了系统行为的外部症状，通常是通过开发人员在编写代码时做出的决定聚合、采样或过滤的：哪些信息将来会有趣？什么值得记录或测量？运行时上下文解除了对预先知道什么可能有趣的需求，并提供了粒度数据，显示了系统内部发生了什么以及如何到达那里。

真正的差距在于静态与动态数据。传统日志、指标和跟踪是静态的，提供了历史事件的记录。Lightrun 的运行时上下文是动态的。它为代理提供了在运行代码中插入新仪器并观察变量值、函数参数、对象状态、调用堆栈或分支条件的能力，就像它们发生时一样。

这种区别对于诊断代理生成代码中的故障尤其重要，因为这些故障通常是沉默的。代理可以选择错误的工具，传递错误的参数，或根据过时的假设采取行动，并且仍然可以在不触发任何错误的情况下完成其任务。这种故障不会出现在静态遥测中，因为没有人预先知道要为此进行仪器监控。意外行为需要直接在运行系统上进行动态调查，而不是依赖静态代码分析或旧遥测数据。

这就是为什么动态运行时上下文是 AI 生成决策的自然验证层的原因。

模型上下文协议（MCP）和类似的集成层如何允许编码代理从实际执行行为中学习，而不授予它们对生产系统的过度或不安全访问权限？

MCP 和其他对外部工具的受控访问（例如 CLI 包装器）允许代理调用特定的、范围有限的功能，而不是被授予对系统的广泛访问权限。通过 MCP 服务器连接以获取运行时上下文的代理可以请求只读证据、变量值、调用路径、是否超过阈值，而无需访问写入权限、无需重新部署任何内容，并且无需对底层环境具有永久凭证。

在重新设计第一代代理时，企业应该如何处理工具权限、内存、数据检索、评估、人工监督和回退程序，以使其成为一个整体架构的一部分，而不是单独的功能？

您不能独立地将这些部分附加上去，因为每一个都会改变其他部分。最好的起点是框架、控制代理循环的挽具以及将多个代理和其他参与者联系在一起的工作流编排。例如，对于根因分析工作流，团队应该决定需要什么证据、代理可以检查哪些系统、是否可以发布结论或仅草拟结论、什么时候需要人工批准下一步骤，以及如果运行时证据不可用会发生什么。

一旦合同明确，挽具和框架提供了执行这些准则的机制。MCP 网关可以用来限制代理对特定功能的访问，这些功能与其目的相关。工具可以以最小特权授予。内存可以在确定性地编辑敏感数据的同时进行监督。检索可以围绕工作流需要的证据进行设计。

评估、监督和回退然后关闭循环。系统应该衡量结论是否正确且有证据支持，风险或不确定性超过定义的阈值时引入人类，并且在无法收集足够证据时停止或回退到只读建议。共享的审计记录应该连接触发器、权限、证据、工具调用、批准、操作和结果。正是这些组件使其成为一个生产就绪架构，而不是六个单独的功能。

对于可以检查活跃应用程序或参与站点可靠性工程工作流的代理，特别是在受监管环境中，需要什么样的保障措施来确保访问控制、隐私、可审计性和运营稳定性？

这是我们在构建 Lightrun AI SRE 时面临的核心设计问题。AI SRE 作为一个特权操作参与者运行，靠近组织中一些最敏感的系统。我们将其设计为一个特权操作参与者，而不是聊天助手。一个重要的决定是将检查面与操作面分离。AI SRE 通过只读集成和 Lightrun 的沙盒运行时仪器收集证据，访问权限受到身份、租户、服务和环境的限制。它可以检查活跃执行并生成缺失的证据，但运行时检查层无法修改应用程序状态。

在受监管的环境中，这个边界必须由基于角色的访问控制、单点登录、租户隔离、个人身份信息编辑、保留控制和审计跟踪来支持，这些跟踪显示了哪些工具和证据支持了每个结论。我们还需要对数据收集、运行时查询频率以及需要批准的操作设置运营限制。如果证据缺失或结论无法验证，AI SRE 应该说明这一点，并将决策移交给人类，而不是假装知道的比实际更多。目标是受控的自治：足够有用以加速调查，但又受到足够的限制，以保持对活跃系统的安全性。

随着企业超越实验代理，什么指标应该决定代理是否真正生产就绪，以及您如何预计代理与人类工程师之间的关系在未来几年内会演变？

我会根据代理的行为产生预期结果的频率、其结论在生产中被证明为真实的频率、未经支持的结论在采取行动之前被捕获的频率以及代理在证据缺失时安全失败的频率来判断生产就绪性。对于工程代理，验证结果的准确性、证据覆盖率、根因分析时间、成功回退率和操作后结果是我们应该关注的核心指标。

在接下来的几年里，我预计代理将承担更多的证据收集和初步调查工作，以及监督代理工作流和从经验和反馈中持续学习的工作，而工程师将制定政策、解决模糊性、批准高风险操作并引导自我改进的代理系统。信任将逐步建立，工作流程逐一推进。能够将其结论追溯到活跃证据并明确披露其无法验证内容的代理将获得更大的自治权。那些无法做到这一点的代理将仅限于狭窄、低风险任务，无论它们听起来多么流利。

感谢这次精彩的采访，希望阅读本文的读者可以访问 Lightrun 以了解更多信息。