\n\n本文探讨了 AI 编程智能体在云原生系统中的局限性，指出由于缺乏实时、真实的运行时反馈，传统脚手架难以在分布式架构中生效，并提出需构建轻量、隔离且可编程的环境。
译自：Why agent harnesses fail inside cloud-native systems
作者：Arjun Iyer
编程智能体在拥有为其提供工具、指导和反馈信号的脚手架（Harness）时表现更好，这些信号能让它们知道该做什么、怎么做以及如何判断是否奏效。但在云原生系统中，提供反馈组件并不那么简单。
我已经思考 Addy Osmani 最近关于智能体脚手架工程的文章 好几天了。其中的观点我非常赞同：一个编程智能体是由模型加上围绕它的一切（提示词、工具、上下文策略、沙盒、子智能体、钩子、反馈循环）组成的，而这些脚手架对智能体行为的提升，往往比另一次模型升级效果更显著。Addy 引用了 Viv Trivedy 的数据，显示同一模型在放入不同的脚手架后，在 Terminal Bench 2.0 上的排名从第 30 位提升到了第 5 位。一旦你见过几次这种幅度的波动，就很难再把模型选择当作最关键的变量了。
我想补充的是，当智能体的工作是更改云原生系统中的代码时，情况会出现微妙的变化。脚手架的框架依然成立，反馈循环是核心的观点也依然成立。难点在于，在分布式系统中，“反馈”究竟意味着什么，以及为了让智能体在其循环内接收到反馈，必须存在什么样的基础设施。
智能体“脚手架”的组成部分并不对等。提示词塑造了智能体的尝试方向；像 MCP 和 CLI 这样的工具决定了它的行动能力；技能指导它如何尝试更改以及使用哪些工具；策略和沙盒定义了其行动的护栏。所有这些都会影响智能体能做什么以及如何表现。但它们都没有告诉智能体尝试是否成功。那是反馈信号的工作。反馈是闭环的关键，它将智能体从开环生成器转变为能够自我修正并在无需干预的情况下完成工作的系统。
对于 Addy 和其他人所写的那些工作类型（单个应用程序、可本地运行、可通过浏览器评分），反馈的基础设施大多是直接的。但对于分布式系统，提供同样的信号要困难得多。
脚手架中高质量反馈的样貌
Addy 使用了一个我觉得非常有用的框架：成功是无声的，失败是冗长的。如果类型检查通过，智能体什么也听不到。如果失败，错误会被注入循环，智能体进行自我修正。测试、Lint 和任何确定性检查也遵循同样的模式。生命周期点（提交前、编辑后、PR 前）的钩子将“我告诉智能体做 X”与“系统强制执行 X”区分开来。没有强制反馈，智能体的其他组件就只是建议。
Anthropic 在长效脚手架方面的工作进一步推动了这一点。他们的三智能体设置（规划者、生成者、评估者）驱动了一个 Playwright 会话，该会话点击运行中的应用程序并根据标准进行评分。在长达数小时的运行中，最终产出的是可以工作的全栈应用程序。其中起关键支撑作用的是评估者的反馈。
这就是单体应用开发的现状，它可以在本地运行，“这行得通吗”可以通过启动开发服务器并点击查看来回答。但大多数生产环境的软件并不符合这种形态。
云原生破坏了什么
微服务架构中的生产代码存在于分布式系统中。一个服务的更改必须应用到它所依赖的真实服务中：数据库、消息总线、配置和鉴权层。智能体用来判断其更改是否奏效所需的信号是系统在运行时的实际响应，而这些在本地沙盒中都不存在。那些在没有这种反馈的情况下“通过”的测试，丢失了大部分的验证维度。
在实践中出现了三种变通方法，但三者都在同一点断开了反馈循环：
Mock 和桩（Stubs）。 对于单元级工作没问题。但在分布式系统中，关键的错误往往产生于具有真实状态的真实服务之间的交互，而 Mock 既无法复现状态，也无法复现交互。
PR 开启后的 CI。 真实环境确实存在于那里，但信号出现在智能体的循环之外。智能体完成工作，开启 PR，然后等待。这个阶段的失败成本很高：智能体已经失去了它的工作上下文，人类现在进入了循环，循环周期从几分钟拉长到了几小时。反馈存在，但来得太晚，且效率太低。
每个分支的全量预览环境。 平台团队多年来一直为人类开发者开启的 PR 这样做。但在智能体规模化的情况下，这种计算方式不再成立：并行运作的智能体很容易产生十倍于人类的分支数量，而提供十倍的预览环境（每个都是完整的系统克隆）是任何人都无法承受的预算。
“在云原生系统中，标准的脚手架模型只能让智能体达到‘我认为这行得通’的状态，然后就停止了。”
在云原生系统中，标准的脚手架模型只能让智能体达到“我认为这行得通”的状态，然后就停止了。那些原本能告诉它事实并非如此的反馈，要么不存在，要么来得太晚，要么无法扩展。智能体别无选择，只能移交给人类来验证行为并关闭循环。脚手架所依赖的反馈组件需要更好的基础设施，才能在分布式系统中按预期发挥作用。
环境在完整脚手架中的角色
如果云原生系统中至关重要的反馈是运行时响应，那么脚手架就需要一个运行时供智能体指向。不是沙盒（它将智能体的执行与主机隔离），而是环境，它为智能体提供一个真实的、可运行的、系统级的表面来进行验证。沙盒保护主机不受智能体影响。环境则提供智能体所需的反馈，以验证其更改是否在真实系统中奏效，并在失效时进行修正。两者都属于脚手架，并承担不同的职责。
“沙盒保护主机不受智能体影响。环境则提供智能体所需的反馈，以验证其更改是否在真实系统中奏效，并在失效时进行修正。”
要使环境能在智能体速度和规模下作为有效的脚手架发挥作用，必须满足四个属性：
廉价且快速。 不是全量的分级环境克隆。而是一个轻量级的临时环境，它共享稳定的基础设施，仅隔离智能体更改触及的部分。如果启动一个环境的成本与全量预览一样高，逻辑就走不通。如果耗时超过几秒钟，它就会脱离智能体的迭代窗口。
真实。 环境必须通过真实服务路由真实流量，并将智能体的更改叠加在上面。智能体调试的条件应该与生产环境表现出的条件一致。
可编程。 智能体必须能够启动它、执行它、读取结果并销毁它。如果需要人类来配置或解释，循环在开始前就已经断了。
隔离。 环境需要在单一共享环境中提供真实的反馈，同时保持完全隔离，以避免与其他智能体的更改发生冲突。一个共享集群需要能同时服务成百上千个并行工作的智能体，且没有竞争。
这些要求都不算奇特。平台团队多年来一直在为了服务人类开发者而朝着这些方向建设。而智能体化开发带来的改变是将这些作为智能体自身驱动的脚手架的一部分，而不是作为位于循环之外、仅在 PR 时才被咨询的基础设施。
这能开启什么
一旦智能体在其循环内拥有了运行时反馈，验证维度就会大大扩展，远超本地检查所能覆盖的范围。智能体可以针对服务之间真实的调用图端到端地运行集成路径。它可以针对真实的消费者和生产者验证契约行为，而不是生成的桩。它可以访问真实数据库，观察真实事务行为，并捕获那些会破坏无关查询的数据迁移。
这些是大多数工程师今天手动运行的检查，通常是在智能体完成后，通过本地复现、预发布环境和 PR 阶段 CI 的某种组合来进行。当脚手架止步于本地沙盒时，这些检查都是不可逾越的，这限制了智能体能自主推进更改的程度。
有了运行时反馈，智能体不仅仅产出一个能编译并通过单元测试的 Diff。它还产出了带有验证证据的更改：显示代码运行的链路追踪（Traces）、显示集成正常的测试，以及显示没有其他功能回退的可观测性数据。Diff 在到达 PR 评审阶段时，已经针对系统中关键的部分进行了验证。评审者的工作从“这行得通吗”转向“我们要发布这个吗”，这是一种不同且更有价值的关注点。
闭环
脚手架工程的方向是正确的：编程智能体需要围绕它们的支撑结构才有用，而反馈循环是该支撑结构的核心。塑造智能体第一次尝试的组件已经取得了很大进步，而关闭本地工作循环的类型检查和测试反馈也已被很好地理解。对于构建分布式系统的工程团队来说，目前仍然缺失的是能够以智能体速度和规模，针对真实的、运行中的系统提供同类反馈的基础设施。
这就是我们 在 Signadot 致力于解决的问题：共享基础架构、按更改隔离、并为智能体提供可编程运行时进行验证的轻量级环境。在开发循环内部，提供智能体速度和规模下的真实反馈。端 工智能
