\n\n本文探讨了异步智能体开发中的核心难题：验证。作者指出，在云原生系统中，依赖本地Mock测试无法保证生产环境的稳定性，必须通过在集群中提供真实运行时环境进行闭环验证，才能从源头提升开发效率并降低返工成本。
译自：Agentic development hinges on verification. For cloud-native software, that is a runtime problem.
作者：Arjun Iyer
异步智能体（Async agents）只有在你能够信任它们交付的结果时才有用。在一个分布式系统中，这种信任归结为你提供给它们的运行时环境：在提交拉取请求（PR）之前的内部循环中。
Cognition 的 Ido Pesok 最近发表了一篇文章，讲述了一个值得深思的里程碑。
这是第一次，他的团队从事件、调度、自动化和其他智能体触发的异步 Devin 数量，超过了交互式会话中的数量。智能体不再是需要开发者驱动的工具，它们可以自主运行并交付成果。
这个数字是一个里程碑，但重点在于它所带来的必然要求。
当开发者驱动每一个智能体时，开发者同时也扮演着验证者的角色。他们阅读代码差异（diff），在真实系统中运行，并决定它是否正确。如果你从每个步骤中剔除开发者，你也同时剔除了验证者。现在，智能体必须以其生成代码的速度和规模来验证自己的工作。正如 Ido 所言，异步智能体只有在 开发者能够信任 它们返回的结果时才有用。
“一个无法自我验证的异步智能体并不能节省任何人的时间。它只是在提交一个 PR，并要求下游的某个人来给它评分。”
这重构了整个问题。生成代码在很久以前就不再是约束了，现在的约束是验证。一个无法自我验证的异步智能体不会节省任何时间。它只是在提交一个 PR，并要求下游来评估。
为什么绿色的测试运行可能毫无意义
一个 装备了工具的智能体 可以独立完成实际工作。它编写代码，运行本地单元测试，利用它的 Mock 对象进行测试，并报告成功（绿色）。问题在于“绿色”代表的含义。
智能体编写了这些 Mock 对象。它根据自己对依赖项行为的模型来编写它们，而这个模型恰恰可能是错误的。因此，智能体根据自己的假设来测试其更改；如果这些假设通过了，该循环中的任何内容都不会触及智能体猜测的现实部分。针对存根（stub）运行并通过，只能证明智能体内部逻辑的一致性，不能证明该变更在现实中有效。
在单个位置运行的服务中，这种差距很小。但在云原生系统中，这是全部的风险。变更并非独立存在，它与调用的服务、依赖的代理和数据库以及网格（mesh）并存，而网格强制执行的超时和重试机制是它在自身进程内无法察觉的。真正的问题往往出现在边界：偏离的契约、序列化方式与预期不符的字段、因重试策略而超时的下游调用，以及本地无法捕捉的模式变更。
在变更与系统其余部分共同运行之前，这些行为都不会显现。因此，智能体可能记录了一次完美的运行，却依然导致两个跳数之外的服务在真实流量下瘫痪。本地运行是绿色的，但在生产环境中却是坏的。智能体做对了所有事，但执行的环境才是问题所在。
闭环的位置决定了缺陷的成本
这是最昂贵的部分。
智能体在迭代时捕捉到的失败只需几秒钟成本。它运行变更，看到真实错误，修复并再次运行。没有任何人知道这发生过。
而在 PR 合并后才发现同样的失败，则需要数小时，而且不是智能体的时间，是人的时间。此时，智能体已经转去处理其他任务，上下文已经过时。某位工程师被迫介入，去调试他们没写过的代码中出现的边界故障，而这些代码是由一个无法解释其思考过程的智能体生成的。
这还是好的情况。坏的情况是，其他变更已经堆叠在这个故障之上。其他智能体基于错误的逻辑构建了功能。现在你修复的不仅仅是一个 PR，而是在解开一连串的连锁反应。
这就是那种演示中从不出现，却总在季度报告里显现的成本。当一个开发者运行一个智能体时，返工成本受到该开发者的限制。但当智能体并行运行并合并时，每一个逃逸出内部循环的缺陷都会落入共享系统，而其他工作已经假设这个系统是正确的。
生成变得廉价了，但捕获一个糟糕的变更却并不廉价。将验证推迟到 PR 之后，返工成本会随着你添加的每一个智能体而增加。将其推向左侧（进入内部循环），大多数缺陷在变成 PR 之前就被消除了。
“生成变得廉价了。但捕获一个糟糕的变更却并不廉价。”
添加智能体并不会自动提升吞吐量。如果验证仍然发生在合并之后，更多的智能体只意味着更长的、看似合理的变更队列，等待着被人类证明是错误的。你只是扩大了编写规模，而将信任问题留在了原地。
在 PR 之后进行验证，边界故障会滞后显现并转化为人类的返工。在内部循环中进行验证，智能体在真实的临时运行时中运行，修复自己的故障，并提交一个已经在系统中被证明有效的 PR。
闭环的实际形态
解决方案不是事后进行更多检查，而是一个在 PR 之前闭环的循环。
给智能体一个表现得像生产环境的隔离运行时。它在那里部署变更。它针对真实的周围服务（而不是 Mock）运行变更。它读取真实的错误。它修复。它再次运行。它检查的范围刻意保持广泛：不仅是单元测试，还包括集成路径、契约以及真实路由下的下游行为。智能体不断循环，直到所有检查在实际系统中都显示为绿色，然后才提交 PR。
现在，PR 的意义不同了。它在到达时已经针对其必须生存的世界进行了验证。人类评审的重点在于意图和设计，而不是“这个智能体是否悄悄破坏了三个服务之外的东西”。这个问题已经在 PR 存在之前的几秒钟内由智能体回答了。
这就是异步开发所需要的闭环。智能体提交的不是供评分的草稿，而是它已经证明有效的变更。
隔离、保真度、成本，大多数方案只能三选二
关键在于运行时环境。在智能体的规模下，常见的方案在隔离性、保真度和成本这三个维度上各有缺陷：
共享的模拟环境（Staging）提供了保真度和低边际成本，但没有隔离性。让一百个智能体同时使用它，它们会破坏彼此的运行。一个智能体的半成品变更会成为另一个智能体的抖动测试，环境访问权限成为瓶颈。
完整的按 PR 环境（Per-PR environments）提供了隔离性和保真度，但代价是其他所有东西。建立环境需要几分钟，每个环境几乎是生产环境的完整拷贝，每天创建和销毁数千次，这种经济效益在智能体规模下无法生存。
Mock 对象和智能体专属的沙箱提供了隔离性，且廉价快速，但没有保真度。这种模型对于在单台机器上运行的软件非常有效，但对于分布式系统却完全失效，因为智能体又回到了针对自身假设进行测试的状态。
你需要同时实现这三者。实现的方法是停止复制整个系统，转而共享它。在集群中运行一个类似生产的环境。仅隔离智能体修改的服务，并路由一个标记过的请求通过它，以便变更能够测试到真实的周围服务。隔离是基于请求范围的。保真度是真实的，因为依赖项是真实的。成本被分摊了，因为数千个瞬态环境共享一个集群并在几秒钟内启动。
共享模拟环境牺牲了速度。完整的按 PR 环境牺牲了成本。Mock 和沙箱牺牲了保真度。共享一个生产级环境并仅隔离被测服务，是实现三者兼顾的方法。
未来是经过验证的，且在集群中闭环
Ido 的观点是对的，异步开发的未来是经过验证的。随着工具的改进，智能体将编写更多的代码，而交互式会话将退居边缘情况。区分你信任的智能体和你需要时刻照看的智能体的关键是验证。而运行时环境界定了智能体能够触达的验证边界。
“区分你信任的智能体和你需要时刻照看的智能体的关键是验证。”
在云原生系统中，运行时环境就是核心，它存在于集群中，紧邻着变更所需的一切资源。
这就是我们在 Signadot 所构建的模式：Kubernetes 原生的瞬态环境，让智能体在 PR 之前几秒钟内针对真实的周围服务执行变更，以满足异步开发所要求的并行性。如果你正在将编码智能体指向云原生系统，并眼看着它们撞上验证墙，那么这就是首先需要填补的空白。端 工智能
