Tessl 提出反馈循环工程：让项目对智能体更友好

如今，智能体编程的大部分精力都集中在一个问题上：如何让智能体自主且高效地做我想让它做的事？我们写出更犀利的提示词，选择更强的模型，或者为手头的任务添加更好的技能。所有这些都有帮助，但与可能达到的效果相比，不过是沧海一粟。

我们已经开始把更大的图景称为反馈循环工程：即围绕你的智能体设计循环，使每一次运行都能为未来的运行改善条件。它为许多团队已经在做的工作赋予了一个名称，并让人们注意到一个仍然经常缺失的中间层。

三个循环

反馈循环根据其发现和解决问题的速度，处于不同的层级。

内循环在单次变更上运作。它包含你的项目中可能已经具备的质量关卡：测试、类型检查、代码检查、PR 审查以及审查意见的来回沟通。它的职责是在不良变更落地之前将其拦截。大多数团队都是从这里开始的。

中循环跨项目及其历史运作。维护智能体就生活在这里。有些是漂移循环，它们发现逐渐偏离项目标准的状态，例如过时的文档、退化的测试或不断增长的复杂度。另一些是回顾循环，它们发现跨多次运行反复出现的同一问题，例如重复的审查意见、不稳定的检查或智能体遇到的摩擦。它们将发现的问题转化为正常开发流水线的纠正性工作。

外循环读取来自生产环境和业务的信号。监视器可以在错误率或产品指标越过阈值时提交工作项。响应器可以直接采取行动，例如重启失败的服务。这一层级检查通过前两个循环的变更在真实系统中是否有效。

内循环改善你面前的这次变更。中循环改善未来许多变更得以进行的条件。没有它，你就会在测试、审查时间和失败的运行中不断为同类错误付出代价。

让项目对智能体就绪

中循环的目标是软件项目。维护智能体会注意到智能体在你的代码库中反复遇到困难的地方，然后将纠正性工作路由到正常流水线，使未来的运行更加轻松。智能体平台在前后可能完全相同。

这一区别影响你如何设定目标。循环从项目中的证据出发，例如智能体日志、反复出现的 PR 评论或对其架构的分析，并询问项目应如何相应改变。这可能意味着为未来的智能体消除反复出现的摩擦源，在代码库增长时保持架构健康，或者改进文档、测试和工具。数据使目标针对具体项目。

随着智能体编写代码的比例越来越大，这一点变得更加重要。每次运行都专注于自己的任务，可能看不到在十次或二十次变更中逐渐浮现的结构。不需要任何单个变更明显糟糕，重复的逻辑、不一致的抽象或过时的指导就可能累积起来。中循环为项目提供了一种反思自身状态和历史的方式。

维护智能体如何工作

维护代理可以运行一次，也可以按计划运行。在我们的场景中，它可能从一张周期性工单或一次计划运行开始。它分析一组聚焦的数据，写一份简短报告，并为该报告所暗示的工作提交普通问题。

这些问题随后进入与人工提交的工作相同的流水线。在我们的设置中，维护运行不会自己打开 PR。它的职责是把嘈杂的证据转化为范围明确的工作，供系统其余部分解决。

最初的几次运行仍然需要人工判断。我们手动运行一个新循环一次，并阅读它提交的每一个问题。如果信号有用，我们就把它排入计划；如果修复很小且机械，我们之后可能允许它们自动合并。循环健康状况的度量仍在进行中。我们需要知道一个循环何时嘈杂、它的发现何时被忽略，以及这些修正是否随着时间推移改善了项目。

为了给出一些规模感，在 Tessl，我们每天运行四个维护代理。每个代理每次运行大约提交两个问题，我们已经积累了大约 500 个标记为维护来源的问题。我们也尝试过更深、频率更低的运行。一次对 Kikimora 的审计检查了 1,102 次提交、400 个已合并 PR 的评审讨论串、CI 运行、代理转录以及 108 次监督会话。它产生了 63 项发现，而我们分诊的发现中有 86% 被派发为工作。

数据源就是全部关键

任何反馈循环的好坏，都取决于它读取什么，以及该来源能告诉它什么。我们发现的一些最有用的来源包括：

代理日志。这些日志显示代理在哪里花费了过多轮次、重试某个操作或反复陷入困惑。一个早期的回顾循环发现，代理一直在反复推导如何使用 Linear 的 API。由此产生的问题促成了一个小型 CLI，使该操作在之后的每次运行中都更快、更可靠。
反复出现的评审评论和 CI 失败。重复出现的反馈证明某项约定在流程中出现得太晚。回顾循环可以提出成本最低的持久修复：也许是一条 lint 规则、验证器、测试或一条指导。
仓库的当前状态。漂移循环将代码推导出的事实与文档进行比较，依据项目自身的原则检查架构，或使用覆盖率和变异测试来发现测试套件中的弱点。这些检查对每个 PR 来说往往太重，但按节奏运行效果很好。
生产遥测。错误、事故和产品度量会为外层循环提供输入。当实时信号超出团队预期的范围时，它们可以创建工作。

这些来源描述的是不同的问题。代理轮次的激增表明存在摩擦；过时的文档是漂移；反复出现的 CI 失败表明缺少护栏。循环的质量取决于把这种解释明确化。

入门

如果你想构建一个反馈循环，你需要三样东西：

一个好的数据源。这可能是代理日志、PR 和 CI 历史、架构分析，或项目当前状态的另一种视图。
清楚理解该来源揭示了什么。代理反复困惑、文档漂移和不断增长的架构复杂性是不同的信号，会导致不同的修正。
一个明确的改进目标。循环的目标可能是消除反复出现的摩擦来源、让文档与代码保持一致，或在项目增长时保持架构模块化。

从小处着手：先解决一个狭窄的问题，比如文档漂移或反复出现的评审反馈。然后在安排循环之前先运行一次。审查它提交的工作，检查它是否与现有工作重复，并且只有在你信任这个信号时才逐步增加它的自主性。随着时间推移，循环栈让项目能够保留它学到的东西：在标准漂移时恢复标准，把反复出现的问题转化为护栏，并将生产信号反馈到未来的变更中。