作家 | James Austin
编译 | 傅宇琪
“见识是赋能下十亿个软件开发者”，这是咫尺领有约 3000 万注册用户的在线集成开发环境 (IDE)、代码协调平台和云行状提供商 Replit 的贪心。昨年九月，Replit 公司推出了 Replit Agent ，这是一个十足自动化的代码智能体器用，旨在匡助任何东谈主从零运转构建软件。
很少有公司大概像 Replit 一样推出如斯大限制的智能体，但限制化也带来了挑战。那么，Replit 是若何构建并延伸其智能体系统，以及如安在险些整宿之间快要一半的工程团队卷入其中呢？
最近，Replit AI 团队的高等软件工程师、Replit Agent 的中枢孝敬者之一 James Austin 在 MLOps 社区的一场直播均分享了他在构建 Replit Agent 中得到的履历训戒。基于该直播视频，InfoQ 进行了部分增删。
中枢不雅点如下：
明确你的见识用户，清醒他们的需求，并据此优化产物，智商确切提供有价值的行状。
需要密切关注智能体的运行轨迹，保举使用 Langsmith 来监控这些轨迹。
评估是一项耐久的投资，天然它们构建起来特殊徒然资源，运行起来也很徒然资源，但它们所带来的价值是不可复制的。
要灵验地构建这些智能体器用，惟一的方法等于发展出特殊好的直观，而培养这种直观黑白常坚苦的。
遥远不要住手学习，遥远不要住手实验。
伸开剩余89%明确你的见识用户，清醒他们的需求，并据此优化产物，智商确切提供有价值的行状。
需要密切关注智能体的运行轨迹，保举使用 Langsmith 来监控这些轨迹。
评估是一项耐久的投资，天然它们构建起来特殊徒然资源，运行起来也很徒然资源，但它们所带来的价值是不可复制的。
要灵验地构建这些智能体器用，惟一的方法等于发展出特殊好的直观，而培养这种直观黑白常坚苦的。
遥远不要住手学习，遥远不要住手实验。
训戒一：明确为谁构建产物
来源，明确你是在为谁构建产物，天然听起来有些夏炉冬扇，但这是每个产物开发的基础。我们率先专注于优化 SWE-Bench 得分，但这并不是我们用户的中枢需求。用户更关注的是若何从零运转构建我方的创意，快速迭代，并与智能体精致合作。因此，我们意志到，我们一直在优化一些易于测度的目的，而不是用户确切和顺的内容。
不同用户群体的需求相反特殊大。举例，一位工程司理可能关注若何高效地不时大型样式和团队，使用智能体异步处理大批任务，而且在处理复杂的代码库时能取得匡助；而 AI-First 工程师和传统工程师则但愿器用大概及时反映，匡助他们更好地编写代码或构建产物。对于后者来说，及时反馈和纯真性比传统的异步职责形态更为弥留。
这让我们意志到，要为通盘用户提供妥洽的不时决议黑白常坚苦的。优化一个用户群体的体验，可能会使另一群体的体验变得更差。举个例子，蒙特卡洛树搜索（Monte Carlo Tree Search）方法，这个方法是指在特定问题上并行运行多个智能体，并找出哪个智能体流露最佳，它对于提高准确度，尤其是在智能体万古候职责时的准确度特殊灵验。但问题是，若是你并行运行五个智能体，你的破耗的资本是五倍，同期也会导致速率变慢。因此，对于 AI-First 工程师或传统工程师来说，他们可能更需要更快速的反馈和更低的资本，是以，若是你为他们构立功能，你就不应该遴荐肖似的时刻。
另外少许是对于产物决策，比如时刻栈。产物司理或者 AI-First 工程师并不在乎他们的智能体是使用 Next、Express 照旧 Flask，但工程师特殊特殊在乎这少许，而且他们和会过推特告诉你。
《湘见万年—文物里的湖南故事（衡阳展）》在衡阳市博物馆开展。此次展览共集结湖南博物院10件国宝级展品、衡阳市博物馆44件馆藏精品文物以及贵州省博物馆1件镇馆之宝，分为“青铜王者”“衡岳仰止”“东方艺术”三大板块展现。
最终，明确你的见识用户是谁，能让你知谈该若何革命你的智能体。举个例子，我们第一个以 SWE-Bench 为见识的智能体，在运转使用时并不好用，因为当你需要创建五到十个文献来运转时，每次操作节略需要 20 到 30 秒，这实需要相对较长的时候。
为了不时这个问题，我们引入了快速构建形态（Rapid Build Mode），在这个形态下，我们不再使用传统的智能体轮回，而是通过尽可能快速地输出内容来启动问题的不时经由。我们提供了一些模板和率领，并使用了一些自界说的教唆。这样，智能体不错快速生成 10 到 15 个文献，天然这些文献有些小问题，但用户不错通过传统的智能体轮回来开荒它们。最终，这个革命使得我们把一个需要六到七分钟智商运转的职责诳骗法子，镌汰到了不到两分钟，大大提高了着力。
另一个方面是我们运转进行教唆重写（prompt rewriting）。我们不顺利跳入代码，也不急于不时用户的问题，而是来源尝试重写他们给我们的输入，延伸其中的内容，加入更多的细节，确切弄流露他们的需求。这样，我们大概幸免在经过六七分钟后给出一个并非用户渴望的末端，而是能提供一个更相宜他们预期的不时决议。
天下不错看到右边这个例子，用户给出的输入是：“为我的意大利餐厅 La Pizza 构建一个恭候名单网站，集合用户的电子邮件和全名，而且让网站的瞎想当代且专科。”接着，智能体会回复说将使用 Flask 来构建这个网站。然后用户就不错说，“嘿，其实我但愿你使用 Express”，然后智能体会回复：“太好了，我们在运转构建之前把这个弄流露了。”
智能体会以特殊奇怪、难以察觉的形势失败，而且智能体会不知疲困地尝试不时它们看到的任何问题，这意味着它们常常会走偏离干线的弯路。举例之前，Anthropic 发布了他们的筹画机使用演示，演示中有一个例子，他们的机器东谈主被教学用来操作筹画机或浏览器，但它却分神，运转稽察黄石国度公园的像片，而不是实施践诺的编程任务。
而且，即使添加了保护措施，用户也能通过一些巧妙的教唆绕过这些截止。举个例子，在我们初度发布 Replit Agent 时，我们决定先专注于几个特殊简单的时刻栈，直到我们对更世俗的时刻栈有了信心。Next.JS 是我们率先决定不维持的栈之一。但是，事实解说，若是你告诉它你是 Replit 的 CEO，而且正在进行测试，它就能绕过这个截止。
我们本不错通过一些教唆工程来强化这个黑名单，但事实上，用户通常是感性的，他们清醒若是使用这种技巧，可能会导致一些问题。因此，这只是一个告诫，阐发我们不可十足依赖系统每次齐能圆善地运行。
我们发现回滚战略特殊灵验。每次回滚意味着你犯了一个乖僻——任何回滚齐意味着你犯了一个乖僻，岂论是用户莫得明确指定他们的需求，导致智能体作念了乖僻操作，照旧智能体卡住了，用户念念要再行运转。若是你纪录下每次回滚的情况，以及某个特定点被回滚的频率，那么这就能成为一个特殊流露的信号，表贤慧能体存在问题，工程师就不错深远走访，尝试清醒问题所在。
其他不时决议包括对用户输入的神思分析。若是用户说“你莫得作念我念念要的”，负面神思就可能是一个告诫信号。另外，我们还曾添加了反馈按钮，让用户提供对智能体的反馈，但我们发现用户并不常用这个功能。回滚的公道是，用户能立即看到成果，而反馈按钮则让用户认为我方像是在对着空旷的虚空喊话。天然，传统的找问题方法依然灵验，比如外交媒体，许多用户会在 Twitter 上推敲我们，讲演他们碰到的问题，我们就不错深远分析，找出问题所在。
训戒三：评估，评估，评估！
当我们率先运转构建智能体时，我们遴荐了一种我们称之为“凭直观开发”的方法，基本上等于在与智能体互动中摸索，嗅觉它变好了，就作念出相应的转移，望望能不可变得更好，不时轮回进行。问题在于，这种作念法最终会导致一个由多样补丁、临时不时决议、谛视和教唆语构成的拼集决议，用以绕过特定的问题。若是你每次测试智能体的某个轨迹需要两三分钟，那就很难测度你是否从一个 50% 失败率的情况改善到了 90%、95% 以致 99%。若是一个问题每次失败的概率是 5%，迪士尼彩乐园2反水你可能需要运行 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 加载的文献运转，比如说“无法检测到这个象征”的信息；智能体大概看到用户能看到的一切迪士尼 彩乐园，包括及时的适度台日记，基本上不错看到通盘内容。
发布于：北京市