首页科技快讯大模型经验为零？他们却在 12 个月内搞出了 AI 智能体编程神器！

大模型经验为零？他们却在 12 个月内搞出了 AI 智能体编程神器！

来源：晰数塔互联网快讯时间：2025年01月12日 20:58

作者 | James Austin

编译 | 傅宇琪

“目标是赋能下十亿个软件开发者”，这是目前拥有约 3000 万注册用户的在线集成开发环境 (IDE)、代码协作平台和云服务提供商 Replit 的野心。去年九月，Replit 公司推出了 Replit Agent ，这是一个完全自动化的代码智能体工具，旨在帮助任何人从零开始构建软件。

很少有公司能够像 Replit 一样推出如此大规模的智能体，但规模化也带来了挑战。那么，Replit 是如何构建并扩展其智能体系统，以及如何在几乎一夜之间将近一半的工程团队卷入其中呢？

最近，Replit AI 团队的高级软件工程师、Replit Agent 的核心贡献者之一 James Austin 在 MLOps 社区的一场直播中分享了他在构建 Replit Agent 中得到的经验教训。基于该直播视频，InfoQ 进行了部分增删。

核心观点如下：

明确你的目标用户，理解他们的需求，并据此优化产品，才能真正提供有价值的服务。

需要密切关注智能体的运行轨迹，推荐使用 Langsmith 来监控这些轨迹。

评估是一项长期的投资，虽然它们构建起来非常耗费资源，运行起来也很耗费资源，但它们所带来的价值是不可复制的。

要有效地构建这些智能体工具，唯一的方法就是发展出非常好的直觉，而培养这种直觉是非常困难的。

永远不要停止学习，永远不要停止实验。

教训一：明确为谁构建产品

首先，明确你是在为谁构建产品，虽然听起来有些陈词滥调，但这是每个产品开发的基础。我们最初专注于优化 SWE-Bench 得分，但这并不是我们用户的核心需求。用户更关注的是如何从零开始构建自己的创意，快速迭代，并与智能体紧密合作。因此，我们意识到，我们一直在优化一些易于衡量的指标，而不是用户真正关心的内容。

不同用户群体的需求差异非常大。例如，一位工程经理可能关注如何高效地管理大型项目和团队，使用智能体异步处理大量任务，并且在处理复杂的代码库时能获得帮助；而 AI-First 工程师和传统工程师则希望工具能够实时响应，帮助他们更好地编写代码或构建产品。对于后者来说，实时反馈和灵活性比传统的异步工作模式更为重要。

这让我们意识到，要为所有用户提供统一的解决方案是非常困难的。优化一个用户群体的体验，可能会使另一群体的体验变得更差。举个例子，蒙特卡洛树搜索（Monte Carlo Tree Search）方法，这个方法是指在特定问题上并行运行多个智能体，并找出哪个智能体表现最好，它对于提高准确度，尤其是在智能体长时间工作时的准确度非常有效。但问题是，如果你并行运行五个智能体，你的花费的成本是五倍，同时也会导致速度变慢。因此，对于 AI-First 工程师或传统工程师来说，他们可能更需要更快速的反馈和更低的成本，所以，如果你为他们构建功能，你就不应该采用类似的技术。

另外一点是关于产品决策，比如技术栈。产品经理或者 AI-First 工程师并不在乎他们的智能体是使用 Next、Express 还是 Flask，但工程师非常非常在乎这一点，而且他们会通过推特告诉你。

最终，明确你的目标用户是谁，能让你知道该如何改进你的智能体。举个例子，我们第一个以 SWE-Bench 为目标的智能体，在开始使用时并不好用，因为当你需要创建五到十个文件来开始时，每次操作大约需要 20 到 30 秒，这实需要相对较长的时间。

为了解决这个问题，我们引入了快速构建模式（Rapid Build Mode），在这个模式下，我们不再使用传统的智能体循环，而是通过尽可能快速地输出内容来启动问题的解决过程。我们提供了一些模板和指导，并使用了一些自定义的提示。这样，智能体可以快速生成 10 到 15 个文件，虽然这些文件有些小问题，但用户可以通过传统的智能体循环来修复它们。最终，这个改进使得我们把一个需要六到七分钟才能开始的工作应用程序，缩短到了不到两分钟，大大提高了效率。

另一个方面是我们开始进行提示重写（prompt rewriting）。我们不直接跳入代码，也不急于解决用户的问题，而是首先尝试重写他们给我们的输入，扩展其中的内容，加入更多的细节，真正弄清楚他们的需求。这样，我们能够避免在经过六七分钟后给出一个并非用户期望的结果，而是能提供一个更符合他们预期的解决方案。

大家可以看到右边这个例子，用户给出的输入是：“为我的意大利餐厅 La Pizza 构建一个等待名单网站，收集用户的电子邮件和全名，并且让网站的设计现代且专业。”接着，智能体会回应说将使用 Flask 来构建这个网站。然后用户就可以说，“嘿，其实我希望你使用 Express”，然后智能体会回应：“太好了，咱们在开始构建之前把这个弄清楚了。”

教训二：自动识别失败案例

智能体会以非常奇怪、难以察觉的方式失败，并且智能体会不知疲倦地尝试解决它们看到的任何问题，这意味着它们经常会走偏离主线的弯路。例如之前，Anthropic 发布了他们的计算机使用演示，演示中有一个例子，他们的机器人被训练用来操作计算机或浏览器，但它却分心，开始查看黄石国家公园的照片，而不是执行实际的编程任务。

而且，即使添加了保护措施，用户也能通过一些巧妙的提示绕过这些限制。举个例子，在我们首次发布 Replit Agent 时，我们决定先专注于几个非常简单的技术栈，直到我们对更广泛的技术栈有了信心。Next.JS 是我们最初决定不支持的栈之一。然而，事实证明，如果你告诉它你是 Replit 的 CEO，并且正在进行测试，它就能绕过这个限制。

我们本可以通过一些提示工程来强化这个黑名单，但事实上，用户往往是理性的，他们理解如果使用这种技巧，可能会导致一些问题。因此，这只是一个警告，说明我们不能完全依赖系统每次都能完美地运行。

另一个问题是，识别智能体失败的情况非常困难。传统的监控系统可以帮助你发现应用崩溃，但它无法帮助你识别智能体是否陷入了循环，无法解决问题，或者用户是否绕过了黑名单。当你查看这些用户指标时，用户因沮丧退出的会话，看起来和用户满意离开的会话没什么区别。

因此，最终你需要密切关注智能体的运行轨迹，但如果你试图查看每一条轨迹，你会被淹没。我们每天生成成千上万条轨迹，实在难以一一查看。我们使用 Langsmith 来监控这些轨迹，它是一个非常出色的产品，强烈推荐。然而这也不够，最终你需要在应用中构建策略，专门用来识别这些失败案例。

我们发现回滚策略非常有效。每次回滚意味着你犯了一个错误——任何回滚都意味着你犯了一个错误，无论是用户没有明确指定他们的需求，导致智能体做了错误操作，还是智能体卡住了，用户想要重新开始。如果你记录下每次回滚的情况，以及某个特定点被回滚的频率，那么这就能成为一个非常清晰的信号，表明智能体存在问题，工程师就可以深入调查，尝试理解问题所在。

其他解决方案包括对用户输入的情感分析。如果用户说“你没有做我想要的”，负面情感就可能是一个警告信号。另外，我们还曾添加了反馈按钮，让用户提供对智能体的反馈，但我们发现用户并不常用这个功能。回滚的好处是，用户能立即看到效果，而反馈按钮则让用户觉得自己像是在对着空旷的虚空喊话。当然，传统的找问题方法依然有效，比如社交媒体，许多用户会在 Twitter 上联系我们，告知他们遇到的问题，我们就可以深入分析，找出问题所在。

教训三：评估，评估，评估！

当我们最初开始构建智能体时，我们采用了一种我们称之为“凭直觉开发”的方法，基本上就是在与智能体互动中摸索，感觉它变好了，就做出相应的调整，看看能不能变得更好，不断循环进行。问题在于，这种做法最终会导致一个由各种补丁、临时解决方案、注释和提示语组成的拼凑方案，用以绕过特定的问题。如果你每次测试智能体的某个轨迹需要两三分钟，那就很难衡量你是否从一个 50% 失败率的情况改善到了 90%、95% 甚至 99%。如果一个问题每次失败的概率是 5%，你可能需要运行 20 次才能实际看到一次失败的情况。

另一个问题是，你不能完全依赖公开的评估标准。公开评估就像 SAT 考试，它衡量的是一些重要的东西，但它并不具体到某项工作或你的需求，就像你不会仅仅根据 SAT 成绩就决定是否雇佣某个人。很多公开评估在某些特定问题上很有效，但对于你的问题可能并不合适。例如，SWE-Bench 非常适合用于 GitHub PR 编码智能体，但它并不适合评估帮助 AI-First 工程师建立营销网站的智能体，对于这种情况，用户可能会说：“哦，你把图片放在了左边，可以把它移到右边吗？或者换成棕榈树代替森林？”而这并没有公开的基准评估供使用。

评估是一项长期的投资，虽然它们构建起来非常耗费资源，运行起来也很耗费资源，但它们所带来的价值是不可复制的。每当你做出大的改变时，评估就像一个安全网，它能够针对具体问题收集反馈，你可以在新模型发布之前，了解它们可能存在的优势和劣势。举个例子，与 Anthropic 合作时，我们发现他们对解决一个具体问题的评估很感兴趣，他们想要得到反馈。例如，我们在计算机使用模型正式发布之前就提前接触到它，这使得我们能够给提供反馈，帮助他们了解哪些地方具有价值，哪些地方有不足。

最后，我们使用的是自己建立的评估标准，与公开的评估标准不同，公开的评估标准通常是由社区开发，并且一旦发布后很少得到更新，或者如果有更新，通常是发布全新的基准集。如果使用自己的评估标准，就可以随着时间的推移不断扩展评估集，而且每当你发现新的问题，就是一次添加新评估项的机会，从而不断完善你的测试集。

教训四：LLMs 有一个陡峭的学习曲线

大约 12 个月前，Replit 的 AI 团队大约有 8 名工程师，但他们分布在很多不同的领域。我们有一个团队，叫做 AI 工程师，这个团队主要负责与各种实验室提供的、外部托管的大型语言模型合作。我们还针对特定任务训练一些较小的大型语言模型，例如我们有一个名为“代码修复”的模型，它可以接收一段有问题的代码，并提出修复建议。此外，我们还在管理自托管模型的推理过程。

但是，负责构建智能体基础设施并开发智能体初步原型的团队只有 3 名工程师。不过，我们构建完智能体的原型后，这个项目迅速获得了公司领导的支持。于是，3 名工程师的团队迅速扩展到 20 人。虽然并非所有人都直接参与智能体的开发，但他们也在为智能体与平台各个部分的集成做工作，包括构建新的 API 供智能体使用。

Replit 多年来构建了很多软件，但其中并没有涉及 LLM 技术。这意味着我们有一支非常优秀的工程师团队，但并没有处理 LLM 的经验，因此我们面临着一个非常陡峭的学习曲线，需要尽快帮助这些工程师提升技能。

在智能体开发过程中，我们遇到了一些问题，这些问题本质上可以通过派遣工程师来解决，他们可以处理这些工程上常见的问题。例如，像内存泄漏这样的常见问题，任何工程师都可以轻松地追踪和修复。但有些问题是全新的，如智能体工具的设计。为智能体设计工具并不像设计 API 那样简单，API 可以有很多字段，字段名称对于沟通很重要，但对 API 的有效性影响不大。然而，对工具来说却完全不同，增加的字段越多，系统就越容易失控。你需要考虑它是否符合工具的工作方式，这其中很多细节非常微妙，而且几乎没有公开的文档可以参考。

要有效地构建这些智能体工具，唯一的方法就是发展出非常好的直觉，而培养这种直觉是非常困难的。非常有帮助的东西之一就是一个高质量的评估框架。虽然我们不会每 5 分钟就运行一次评估，但我们会通过让智能体并行运行多个不同的提示语，并观察每个提示语如何在做出某个调整后发生变化，这种方法帮助我们提高了工程师对系统整体架构的理解，帮助他们培养如何在不同部分之间进行有效调整的直觉。另外，时间的积累是无法替代的。与 LLM 的工作经验非常宝贵，工作时间越多，直觉就会越来越敏锐。

代码审查也是一种非常有效的帮助团队成员更好地理解代码库和提升技能的方法，注意确保每个涉及智能体的 PR 都包含相关的轨迹，这能够帮助其他工程师更好地理解智能体如何使用特定的工具，并进一步培养他们的直觉。

最后我想说，我是作为一名平台工程师加入 Replit 的，当时负责存储工作。我从事 AI 工程的时间大约只有 18 个月，但我发现自己能够非常快速地做出贡献，因为新的想法随时可能来自任何地方。你只需要看看社交媒体，就会发现即使是最前沿的团队，也不可能知道所有的事情，总是有很多可以贡献的空间。所以，永远不要停止学习，永远不要停止实验。

Q&A

Q：除了 Langsmith，还推荐哪些工具用于构建智能体和之后的评估工作？

A：除了使用 Langsmith 进行数据追踪和记录，我们还主要使用 Brain Trust 对传统的聊天功能进行一些评估。然而，对于大多数评估，我们自行开发了评估框架，因为我们认为深入理解这一过程对我们至关重要，能够帮助我们开发出更好的智能体。因此，我们自行开发了评估框架，技术栈主要包括 Python 和 Web。

Q：你们是如何解决评估问题的呢？你们是否运行一个 Web 智能体来自动化与智能体创建的最终应用的互动？

A：是的，我们确实这么做了。Web 智能体已经存在了一段时间，并且有很多有效的技术可以用来测试功能等内容。但现在，我们几乎完全依赖 Anthropic 的计算机使用工具。我们有一个评估框架，能够启动多个 Chrome 实例和 Docker 容器，然后智能体可以与这些实例进行互动，并行测试，同时记录所有的日志，工程师可以深入查看这些日志。

Q：什么是好的评估工具和评估方法？什么样的评估框架是有效的？

A：我们的评估框架是自家开发的，我们尽量避免过于规定具体的评估方法或测试内容。我们更倾向于采取反应式的方法，灵活应对实际情况。举个例子，几周前我们发现了一个问题，每个 Frontier 模型都不知道 GPT-4O 是什么，因为 GPT-4O 发布时正好在知识截止日期之后。这个问题导致用户的代码中使用了 GPT-4O，而智能体会认为这是个错误，并纠正为 GPT-4。这就带来了另一个问题：智能体如何正确地修复这个问题？我们构建了一些评估，专门测试智能体是否会错误地修改类似的内容，尤其是在改动附近的内容时。我们不希望智能体在这种情况下表现得过于主动，因而需要考虑哪些技术才是解决这一问题的正确方法。

Q：您提到过最后是“我们”编写了这些评估，那么在这个过程中“我们”指的是谁？是每个人都在编写评估吗？或者是有一个特定的小组在负责编写评估？具体是谁在执行这个任务呢？

A：我们 AI 团队负责管理评估框架，但这个框架的设计是为了让团队中其他成员也能使用。我们有一套指令，可以提供给 Web 智能体，指导它如何执行任务，比如如果用户询问某个问题，应该如何回答。这些指令基本上是纯文本提示。

整个组织中，所有参与智能体开发的工程师，比如那些负责特定集成或者想要改进某个功能的工程师，都可以编写自己的评估，并将其贡献到我们共享的评估池中。

Q：你之前提到过，评估应该被视为一种投资，随着时间的推移会带来回报。那么，是否曾经遇到过组织内的反对声音呢？是否有时候会觉得评估会拖慢组织的节奏，进而使得其他人更倾向于优先处理其他事项？如果是这样，你是如何为评估的重要性争取支持的？

A：你可以用同样的论点来讨论集成测试。集成测试有时会不稳定，设置起来也比较复杂。但一旦建立了评估框架，后续添加更多测试就相对便宜了。另一方面，智能体的评估与集成测试有一个特别的区别，就是即使评估偶尔失败也不是大问题，只要整体趋势是朝着正确的方向发展的。

一开始，我们确实遇到过一些反对声音，特别是在我们想要抢先上市、希望尽快发布产品时。那时，Vibes 式的开发方法似乎已经奏效，大家认为不需要花时间在评估框架上。此时，作为资深工程师的角色就很重要，我们需要坚持说：“我们希望做得更好，走得更稳，这将带来长期的回报。”我也很幸运能与愿意倾听的领导一起工作，他们理解这一点，并决定给我们一些时间和空间，暂时放慢节奏，以便将来能够更快速地推进。

Q：你们是如何协调调试的？你们的智能体会使用调试工具吗？还是主要依靠对错误的暴力排查？

A：我们有一些我们称之为“视图（Views）”的功能，这些视图可以让智能体查看不同的内容。这些视图包括从我们通过 LSP 加载的文件开始，比如说“无法检测到这个符号”的信息；智能体能够看到用户能看到的一切，包括实时的控制台日志，基本上可以看到所有内容。

但是，我们目前还没有那种像添加断点、逐步调试代码的调试工具。我们注意到，如果用户遇到问题，且需要进行多次交互，智能体会开始自动插入打印语句，这是它目前的调试方式。特别是我们理论上计划支持所有编程语言和环境，要构建一个在各种环境下都能一致工作的接口是一个极其困难的挑战。所以，这是我们还没有完全解决的一个难题。

发布于：辽宁