不要浪费你的反压

本文信息来源：banay

智能体的反向压力

你可能已经注意到，过去一年中最成功的智能体应用呈现出一个共同模式：那些能够围绕智能体本身建立结构，并为其提供关于质量和正确性的自动化反馈的项目，得以推动智能体承担更长时间跨度的任务。

这种反向压力帮助智能体在推进过程中识别错误，而当前的模型已经足够成熟，使得这种反馈能够在更长时间内让它们与任务保持对齐。对工程师而言，这意味着你可以通过将日益复杂的任务委派给智能体来提升自己的杠杆效应，同时也能增强对其最终成果达到令人满意标准的信任。

设想一下，如果你只给智能体提供了编辑文件的工具。若无法与构建系统交互，模型就只能依赖你来反馈它所做的更改是否合理。这意味着你要花费你自己的 把“背压”（即你花在向代理提供反馈上的时间）浪费在输入一条消息、告诉代理它漏掉了一个 import 上。这 扩展性很差，只能让你局限于处理简单问题。

如果你需要直接负责逐行检查生成的每一行代码在语法上是否有效，那就会占用你本该用于思考软件中更宏大目标或更复杂问题的时间。你将很难从代理身上获得更大的杠杆效应，因为你被琐碎的改动牵制住了。相反，如果你为代理提供允许其运行 bash 命令的工具，它就可以执行构建、读取反馈并自行纠正错误。这样你就无需再参与这些事务，而可以将精力集中在更高复杂度的任务上。

拥有高表达力类型系统的语言已经被 越来越受欢迎 ，在一定程度上正是因为背压。类型系统允许你在程序中描述更完善的契约，使得无效状态甚至无法在程序中被表示出来。它们还能帮助你识别那些可能未被处理的边缘情况。能够依赖这些特性，本身就是在构建另一种形式的背压，你可以将其作为对代理所做修改的反馈。

加分项还包括那些致力于生成出色错误信息的语言（比如 Rust， Elm，甚至 Python）。这些消息会被直接回馈到 LLM 中，因此提供的指导越多，甚至给出建议的解决方案，效果就越好。

另一个“背压”的例子是，越来越多的人迅速采用为智能体提供查看已渲染页面能力的方式，例如通过用于 Playwright 或 Chrome DevTools 的 MCP 服务器。无论哪种情况，这些工具都让智能体能够进行修改，并将其对 UI 中可能看到结果的预期与实际结果进行对比。接入这些工具意味着你无需反复告诉智能体某个 UI 元素没有正确加载，或某些内容没有居中。如果不是在做 UI 应用？那就使用可桥接到 LSP 的 MCP 服务器，用于获取 lint 或其他形式的反馈。

即便在工程任务之外，像 Lean 这样的证明助手与 AI 的结合（参见近期关于 Erdős Problems 的工作，该问题由 Kevin Barreto 和 Liam Price 通过使用 AI 解决） 让亚里士多德（Aristotle）将 GPT-5.2 Pro 编写的证明形式化为 Lean），以及在 生成 CUDA 内核时使用随机模糊测试来评估正确性，或让智能体进行逻辑编程，都是极为强大的组合，因为它们允许你不断拉动 LLM 的“老虎机拉杆”，直到得到可以信任的结果。我认为，对更高质量测试的投入所带来的回报正在急剧增长，而工程工作的一个越来越重要的组成部分，将是通过设计和构建“背压”，来扩展能够被接纳的智能体贡献的速度。

如果你在进行规格驱动开发，并希望代理生成特定的 API 架构，可以基于应用中的 OpenAPI 架构设置文档的自动生成机制，这样代理就能对比其生成的结果与原本意图实现的内容。一旦你识别出这种模式，还可以应用更多类似的技术。

在你的项目中，你应该思考如何在工作流中构建回压，一旦具备了这一点，你就可以 循环运行代理 ，直到它们为你消除所有不一致和问题。如果没有回压，你就只能把时间耗在亲自逐一指出代理所犯的每一个错误上。

所以下一次，不妨想一想—— 你是否在浪费你的回压？