文章指出，尽管AI编码代理的代码生成能力有所提升，但其生产力增益受限于手动工作流及缺乏全面反馈循环。OpenAI和Stripe等公司通过“束缚工程”及强大的反馈机制，赋予代理与人类工程师相同的工具和环境信号（如代码检查、测试、可观测性数据、端到端验证），从而实现高度自主和生产力提升。核心观点是：更好的反馈基础设施而非仅仅更好的代理，是最大化代理生产力的关键。
译自：Coding agents are only as good as the signals you feed them
作者：Arjun Iyer
过去几年，业界一直致力于优化AI代理的代码生成能力。重点放在扩展上下文窗口、针对特定代码库数据微调模型以及开发复杂的提示策略上。这无疑催生了更强大的编码代理。然而，对大多数团队而言，这种代码生成能力并未转化为生产力的显著提升。
大多数工程团队都陷入了手动工作流程。代理生成代码，在本地进行测试，然后将拉取请求（PR）提交给开发人员进行审查。部署代码、验证其是否有效以及将任何集成问题反馈给代理，所有这些都以人类的速度进行。这种工作流程通过使开发人员成为验证瓶颈，给代理所能带来的生产力提升设置了上限。
但一些公司正在让其代理实现真正的自主性，并看到了AI所承诺的生产力提升。Stripe、Ramp以及OpenAI和Anthropic的内部团队都得出了同样的结论：代理输出的质量与其收到的反馈循环的质量直接相关。
“代理输出的质量与其收到的反馈循环的质量直接相关。”
为了将工程师提升为架构师，并让代理式代码生成的速度转化为生产力，平台工程团队需要重新考虑其策略。与其专注于为开发人员提供更好的编码代理，更具影响力的杠杆可能是为代理提供更好的反馈基础设施。
束缚工程的经验教训
OpenAI最近记录了他们如何使用Codex构建了一个完整的软件产品，其指导原则是“人类掌舵。代理执行。”他们的成功并非纯粹由模型智能或提示工程驱动。它是由对代理运行环境的巨大投入所驱动的。
一个由三名工程师组成的团队通过设计环境、明确意图和构建严谨的反馈循环，生成了一个拥有内部用户和数百万行代码的可用产品。工程师的主要工作从编写实现代码转变为构建支架，使代理能够验证自己的工作。这种方法被称为束缚工程。
束缚工程涉及为代理配备有效行动所需的工具和约束。OpenAI工程师会编写一个文档字符串（docstring）和一组断言。然后代理会生成实现。如果断言失败，环境将自动捕获回溯信息，将其反馈给模型，并请求重试。这个循环允许数十次迭代而无需人工干预。
这里的关键教训是，要让代理像工程师一样行动，它们需要在基础设施层面拥有与工程师相同的工具、环境和约束。通过为代理提供一种验证自身工作的方法，他们将模型从一次性代码生成器转变为一个能够迭代的工程师。束缚提供了代理调试自身代码、验证其逻辑并交付功能完善的软件所需的信号。
Stripe的Minions和反馈循环
我们可以在Stripe看到类似的模式。该公司最近发布了一篇博客文章，详细介绍了其内部代理框架Minions。据报道，Minions每周生成一千多个合并的拉取请求。Stripe并非仅仅通过将大型语言模型指向其单一代码库就达到了这一数量。
该公司构建了一个名为Toolshed的MCP服务器，向其代理公开了400多种工具。至关重要的是，它赋予了代理对开发环境的完全访问权限，并将确定性验证步骤构建到代理的循环中。
当Stripe的Minion编写代码时，束缚会迫使其经历一系列验证步骤。它从git操作开始，然后转向代码检查（linting）和格式化。如果代理生成的代码违反了风格指南，代码检查器会立即拒绝并返回具体的行号。代理会接收此错误消息并纠正语法。
接下来，Minion进行类型检查和测试。如果测试失败，错误输出会被反馈到上下文窗口中进行修复。这作为一个闭环控制系统运行，开发环境本身提供了错误信号。这种设计使得组织能够信任代理的输出，因为系统会阻止不正确的代码离开代理的本地上下文。
验证鸿沟
今天，大多数工程团队并未达到这种复杂的水平。他们通常只为代理提供一个代码编辑器和一个终端窗口。
这造成了一个验证鸿沟。这就像雇佣了一位高级工程师，却不给他们访问预演环境、监控仪表板、测试基础设施或代码审查的权限，却期望他们能有效贡献。
代理可用的反馈信号决定了其自主完成任务的上限。如果代理只能看到编辑器中的文本，它就只能修复语法错误。如果它能看到编译器输出，它就能检测类型错误。但要解决复杂的集成问题，它需要访问人类工程师所依赖的同样丰富多样的信号。
“代理可用的反馈信号决定了其自主完成任务的上限……没有这些信号，代理容易发生静默故障。”
没有这些信号，代理容易发生静默故障。代理可能会生成一个语法正确并返回正确数据的SQL查询，但它执行了全表扫描，从而降低了生产性能。如果没有访问解释计划或执行指标的权限，代理就无法知道它编写的代码在生产环境中会失败。
反馈信号的层级结构
为了理解反馈信号对代理的影响，有必要绘制其层级结构。每个层级都为代理提供了更多的上下文，提升了它们的自主性，进而提升了它们的生产力。
语法和类型检查
这是基线。任何称职的代理循环都能通过针对编译器或代码检查器输出进行迭代，有效消除语法和类型错误。然而，这些代表了最浅层的错误。一个程序即使语法完美且类型安全，也可能在生产环境中完全失败。
单元测试
能够运行本地单元测试的代理可以独立验证逻辑。这能捕获大量的逻辑缺陷，但会错过分布式系统的复杂性。单元测试可以确认一个函数正确计算了税率，但它无法确认税务服务是否可达或认证令牌是否有效。
集成和API测试
在这里，验证鸿沟扩大了。为了验证新的或更新的服务是否正确调用了上游依赖项，代理需要访问一个运行环境，以便这些服务能够交互。没有这种上下文，代理经常会凭空捏造API负载或编造端点。
可观测性数据
代理很少被授予访问跟踪和日志的权限，然而这些是开发人员调试复杂故障的关键工具。赋予代理查询日志或分析跟踪ID的能力，使其能够诊断静态分析永远无法捕获的运行时行为问题。
可视化和端到端验证
最后，需要可视化和端到端验证来验证完全影响前端的任何更改。后端代理可能会部署一个通过所有服务级测试的模式更改，但会破坏用户界面，因为某个组件预期的数据格式不同。通过为代理配备隔离预览和驱动浏览器的工具，它们可以确认其更改端到端运行正常并闭合循环。
展望未来
我们已经跨越了模型智能的门槛，为代理带来了强大的工程能力。现在的限制因素是代理可用的反馈信号的丰富程度。
有充分的理由将代理反馈基础设施视为一流的平台能力，就像现在的CI/CD管道一样。这包括考虑投资于像MCP这样的标准化工具接口、使日志和错误易于机器消费的结构化输出，以及允许代理并行启动所需的隔离空间以针对真实依赖项进行测试和迭代的临时环境解决方案。
那些构建基础设施以实现这些反馈循环的团队，将随着模型的改进看到速度的复合增长。而那些不这样做则将始终受到编码代理所能产生生产力的限制。
