智能体需要反馈循环，而非完美提示词

对于需要大量判断力的工作，起始提示词只是开始。最好的智能体会从团队中学习“何为优秀“，并随时间自我改进。

每个人都在尝试为智能体编写更好的提示词。这虽然有用，却忽略了一个重要挑战：你今天写出的最佳提示词，一个月后未必还是最佳。

你的产品在变化，用户在变化，团队的品味在不断精炼。新的边缘情况不断涌现。如果智能体从事的是需要判断力和品味的工作，没有任何静态提示词能涵盖它所需的一切。

这便将问题从“如何写出完美提示词“转变为“如何构建能在部署后持续从团队学习的智能体“。

我们在 Warp 构建一个智能体时遇到了这个问题，该智能体旨在帮助我们的开发者体验团队回应 Twitter、Reddit 及其他平台上提到我们的人。我们乐于与用户讨论 Warp，倾听他们的问题和反馈，并非常重视对每个谈论或提及我们的人做出回应。社区成员每周产生超过一千条提及！这比任何小团队用手动方式能跟上的对话都要多。

接近成功却仍有欠缺的智能体挑战

在许多智能体开发中，核心循环很直接：智能体尝试某件事，检查是否成功，然后重试。如果是编写代码，通常有具体的信号可供使用：测试、构建、浏览器检查、命令输出。

社交回复并不完全如此，因为智能体没有合理的“外部检查“可用。它不能发送一堆公开回复，等待观察人们对我们信任度是否增减，推断品牌语调是否正确，然后再重试。反馈循环太长、太嘈杂且成本太高。公司内部许多有用工作也是如此：客户拓展、支持回复、代码审查评论、产品反馈分析、文档、招聘信息。它们需要知道什么重要，以及何时不应行动。

我们见过很多智能体卡在这种状态：它们接近成功。它们显然有能力，输出足够好能让你看到希望，但还不够好可以信赖。团队不断调整提示词，希望下一个版本能缩小差距。

我认为这是错误的抽象层次。让智能体完成任务一次并非难事。困难的是构建一个系统，让智能体能从团队已有的工作方式中持续进步。

我们构建的智能体

我们将该智能体命名为 Buzz。Buzz 监控 Twitter、LinkedIn 及其他平台上关于 Warp 的提及。当新的提及出现时，它会判断我们应该回复、点赞、记录还是忽略。如果应该回复，它会草拟一条消息并将建议发布到 Slack 中。

右侧：在 Slack 线程中给 Buzz 的反馈。左侧：Buzz 链接了技能更新的每日 PR。

右侧：在 Slack 线程中给 Buzz 的反馈。左侧：Buzz 链接了技能更新的每日 PR。

每条回复最终仍然由我们亲自撰写，但仅此一项就节省了大量时间：团队不再需要监控每个平台、打开每个线程、判断每条提及是否重要、并从零开始撰写每条回复。我们希望在合理范围内尽可能自动化，同时不牺牲有价值的互动或损害质量。每条回复都是公开的，代表我们的品牌，并影响人们体验公司的方式。我们需要智能体学习我们团队如何看待社区参与。

原则胜过规则

Buzz 的第一个版本与许多智能体的第一个版本相似：一长串规则的清单。如果某人提到 bug，说这个。如果某人将我们与另一个工具比较，说那个。如果某人询问定价，提及这个方案。

这非常脆弱。提示词越来越长，回复很机械，一旦出现我们未曾告知的情况，智能体就会崩溃。于是我们将技能从规则转向原则。我们不再试图列举每种情况，而是写下了指导优质回复的持久理念：

• 提供帮助，而非防御。

• 不要对用户居高临下。

• 根据文档核实事实主张。

• 听起来像产品构建者，而非反馈处理者。

这让技能文件更小，智能体也好了很多。回复开始听起来更像我们实际会说的话，智能体能够处理更多情况，因为指示不再是一个巨大的决策树。然而，原则仅仅给了 Buzz 一个更好的起点。我们无法囊括它可能需要的一切。

除非智能体能泛化，否则反馈并非学习

一旦 Buzz 具备了一个基于原则的体面技能，我们便开始给予它反馈。

它会草拟一条回复。我会指出哪里有问题，或者写下我自己会用的回复。然后 Buzz 会尝试根据反馈更新自己的指示。

这让我们遇到了下一个失败模式：智能体想把每次纠正都变成一条规则。例如，如果我说某条回复太营销化了，它会添加一条规则：“永远不要在首句提及定价。“而可迁移的原则更接近于：“如果某人在发泄，先表达共情，而非推销。“智能体需要被教导如何从反馈中学习。

于是，我们为此构建了一个独立的技能。它会审视智能体的建议、人类实际做了什么、以及当前的指示，然后提问：为了实现预期输出，缺少或不清楚的原则是什么？

GitHub 上的回复学习技能

GitHub 上的回复学习技能

学习过程大致如下：

• 识别哪里出了问题（或做对了）——从具体反馈出发，要具体

• 追问：为什么？——失败是症状，找到根本原因

• 放大到模式——这项原则是否能超越单个案例适用？

• 对照现有原则——优化、编辑、删除或新增？

• 以原则而非规则的方式编写——描述如何思考，而非做什么

• 将其放在合适的位置——章节对智能体正确应用原则很重要

• 编辑并提交——更新技能文件，保持精简，合并重叠原则

这感觉很像指导一位新团队成员，并让他们学会更广泛的思想。一个有用的副作用是，反馈迫使我们对自身的判断更加清晰。许多品味隐性地存在于人们的头脑中。教导智能体则将其推到纸面上。

反馈循环必须适合团队

此时，Buzz 已经具备了这个更大谜题中的两部分：执行任务的原则，以及从人类反馈中学习更好原则的方法。但是，谁会持续教导它呢？我们不想要一个定期的会议，也不想分配一个任务给某个人。

Buzz 已经将每条提及连同其建议和草稿回复发布到 Slack 频道中，因此我们把反馈界面做得尽可能小：团队通过表情符号反应表示他们实际做了什么，还可以在线程中可选地添加说明。一次点击就足以提供信号；线程则为额外上下文。

然后，每天一次，Buzz 收集反应和线程反馈，将其建议与团队实际行为进行比较，提取可持久化的经验，更新相关技能文件，并创建一个 PR。

正是这个小小的 Slack 循环让系统在实践中运转起来。从智能体中获得杠杆的最佳方法不是让每个人都成为提示词工程师。而是设计工作流，让团队正常的判断和品味成为周围系统的训练信号。

智能体技能应被视为代码

这样的系统显然存在一个问题：你真的想让智能体重写自己的指令吗？是的，但不能悄无声息。我们通过将智能体技能视为代码来确保安全。

当智能体反复执行工作时，提示词开始成为你需要审查的对象。如果这些指示决定了生产行为，它们就应该存在于一个仓库中，带有版本历史、审查和回滚。日常学习的智能体不会直接改变生产行为。它会打开一个 PR，展示它审查了哪些反馈，认为应该更改哪条原则，以及技能文件的确切差异。人类像审查其他任何变更一样审查它。

这为我们带来了自我改进的有用部分，同时没有放弃控制权。Buzz 可以持续提出改进建议，但持久化的更改需要经过审查，这样我们就能确保不会偏离到奇怪的方向。

目前进展如何

如今，Buzz 每月处理数千条来自 Twitter、Reddit、Bluesky、LinkedIn 及其他渠道的提及。大约一半不需要回复，这意味着团队只花时间在需要关注的提及上——这已经节省了大量时间。Buzz 运行在大约 15 个技能上，涵盖分流、起草、学习、分析和报告。我们使用 Oz 进行智能体管理和编排，因此 Buzz 可以在后台运行，并通过定时任务或传入的提及触发。

这让团队能够在不增加团队规模的情况下完成更多工作，并将更多时间花在我们最擅长的事情上：知道什么重要、做出品味判断、与社区建立关系，以及决定 Warp 在外部人士眼中应该是什么样的公司。

目标是复合型判断力

从事需要大量判断力工作的智能体需要一种方式，从它们试图模拟判断力的人那里学习。

每当我们构建类似的智能体时，我们会牢记以下三点：

• 原则胜过规则，因为规则过拟合而原则可迁移。

• 智能体需要学会如何学习，否则反馈会变成脆弱的例外。

• 反馈循环必须存在于团队已有工作的地方，否则人们就会停止参与。

我不想从系统中移除人类的判断和品味。我想让它们复合增长。每次团队纠正智能体，下一次运行就应该更好一点。每个持久的改进都应该被审查并签入。

随着时间的推移，智能体不再像是某人一次性写好的提示词，而更像是团队如何思考的工作记忆。最优秀的团队不仅会写出更好的提示词。他们会构建出更好的循环。