AI智能体需要的是反馈循环，而不是完美的提示词

要让AI智能体真正聪明起来，关键在于构建持续学习的系统，而非执着于一次性的完美指令。

核心内容：

1. 智能体为何需要动态反馈而非静态提示词

2. 以社交媒体回复为例说明“差点就成”的挑战

3. 通过原则优先和反馈循环构建可进化的智能体

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

对于从事

（judgement-hea vy）的智能体来说，最初的提示词只是一个起点。真正有意思的地方在于，那些能不断进化的智能体，都懂得从团队身上学习什么是“好”的标准，并且能随着时间推移自我迭代。

现在大家都在琢磨怎么写出更牛的提示词。这事当然有意义，但很容易忽视一个扎心的现实：

产品在迭代，用户在变化，团队的品味在不断打磨，新的边界问题层出不穷。更何况，如果智能体本身需要判断力和品味，那任何静态的提示词都没法涵盖它需要知道的一切。

这个问题从根本上把我们的思路转变了：从“如何写出完美提示词”变成了“如何构建一个发布后还能持续向团队学习的智能体”。

我们在Warp构建智能体时也遇到了这道坎——团队需要处理社交媒体上的用户提及。我们非常重视和用户的每一次交流，认真倾听他们的疑问和反馈。结果呢？社区每周产生的提及超过一千条！小团队根本忙不过来。

那些“差点就成”的智能体面临的挑战

大多数智能体的开发逻辑很直接：尝试做事、检查是否成功、然后重试。比如写代码，有明确的信号可用：测试能否通过、构建是否成功、浏览器检查、命令行输出。反馈信号清晰明确。

可社交媒体回复就没这么简单了。智能体没有一个现成的“外部检查”机制。它总不能先发出一堆公开回复，然后等着看大家是更信任我们还是更反感，用这种方式来推断品牌调性对不对，再据此重试吧？这个反馈周期太长、干扰太多、成本也太高昂。很多公司内部的工作也都有这种特点：客户外联、客服回复、代码审查意见、产品反馈分析、文档撰写、招聘消息——这些都需要智能体理解什么重要、什么时候该行动、什么时候该沉默。

现实情况是，我们看到很多智能体卡在这种“差点就成”的状态。能力确实有，输出质量也让人燃起希望，但还远远没到可以放心信任的程度。于是团队就不停地调提示词，盼着下一个版本能把这个差距补上。

这说明我们找错了抽象层次。让智能体做对一次并不难，真正的门槛在于：构建一个系统，让智能体能够从团队已有的工作方式中持续变好。

我们构建的智能体

这个智能体叫Buzz。它监控Twitter、LinkedIn和其他平台上的Warp提及。当有新提及时，它会判定我们应该回复、点赞、记录还是直接跳过。如果决定回复，它就会起草一条消息，并把建议发布到Slack上。

右图：Slack频道里给Buzz的反馈。左图：每日PR，Buzz把技能更新链接到这里。

最终每条回复仍然由我们亲自撰写，但仅此一项已经节约了大量时间：团队不必再逐个平台盯着、逐个话题点开、逐个判断每条提及是否重要、每次回复都从零开始。我们的目标是，在不牺牲有价值的互动和质量的前提下，尽可能做到自动化。毕竟每条回复都公开可见，代表着品牌形象，直接影响人们对公司的体验。所以智能体必须学会团队是如何理解社区互动的。

原则优于规则

Buzz的第一个版本和很多智能体的第一个版本高度相似：一个长长的检查清单。比如“如果有人提到bug，这样说；如果有人把我们和另一个工具比较，那样说；如果有人问价格，提一下这个套餐”。

这种方案非常脆弱。提示词越来越长，回复变得机械，一旦遇到没教过的情况，智能体就彻底“断片”。于是我们把策略从规则转向了原则。与其枚举每一个场景，不如写下一组能持续指导好回复的核心理念：

• 要乐于助人，不要防御性。

• 不要居高临下对待用户。

• 用文档核实事实陈述。

• 听起来像做产品的人，而不是处理反馈的人。

这让技能文件变得精简，智能体反而更出色了。回复开始有了真人说话的味道，而且能处理的场景也更多了——因为指令不再是庞大的决策树。不过，原则只是给了Buzz一个更好的起点。我们不可能把所有可能需要的东西都写进去。

反馈不是学习，除非智能体能泛化

一旦Buzz掌握了基于原则的基础技能，我们就开始给它反馈。

它会起草一条回复。我或者同事会指出问题在哪，或者直接写出我们会怎么回复。然后Buzz尝试根据这些反馈更新自己的指令。

这一步让我们撞上了新的失败模式：智能体想把每一个修正都变成一条新规则。比如我说“这个回复太像营销了”，它就会加一条“永远不要在第一句提到价格”。但真正可迁移的原则应该是：“如果有人在发泄情绪，先表达同理心，而不是推销。”智能体需要被教会如何从反馈中学习，而不是机械地套用规则。

于是我们专门为这个能力构建了一个技能。这个技能会对比智能体的建议、人类实际做了什么以及当前的指令，然后问：为了实现期望的输出，缺少或不清楚的是哪条原则？

GitHub上的回复学习技能

学习过程大致如下：

1. 识别对在哪里或错在哪里
   ——从具体反馈入手，越具体越好

2. 追问：为什么？
   ——失败只是症状，必须找到根本原因

3. 上升到模式
   ——这个问题能不能应用到当前案例之外？

4. 对照现有原则
   ——是加强、编辑、删除，还是新增？

5. 写成原则，而不是规则
   ——描述怎么思考，而不是做什么

6. 放到该放的位置
   ——章节位置对智能体正确应用原则很重要

7. 编辑并提交
   ——更新技能文件，保持紧凑，合并重叠的原则

这个过程很像教一个新成员融入团队，让他们理解更广泛的理念。一个有趣的副产品是：反馈迫使我们更清楚地表达自己的判断。很多品味只存在于人们的脑海里，而教智能体这件事，逼着我们把它们落在纸面上。

反馈循环必须适应团队

到这一步，Buzz已经有了两块关键拼图：完成工作的原则，以及从人类反馈中学习更好原则的方法。但谁来持续教它呢？我们不想搞定期会议，也不想把它分配给某个人。

Buzz已经把每条提及连同它的建议和草稿回复发布到Slack频道里了，所以我们把反馈界面做得尽可能轻量：团队成员用表情符号反应来表明他们实际做了什么，还可以在话题里加一条备注。一个点击就能传递信号；话题则提供额外上下文。

然后，Buzz每天收集一次反应和话题反馈，比较它的建议和团队实际做了什么，提取持久的学习成果，更新相关的技能文件，最后打开一个PR。

这个小小的Slack循环让系统在实践中顺畅运行。从智能体身上获得最大价值的方式，不是把每个人都变成提示词工程师，而是把工作流程设计成让团队的正常判断和品味成为智能体的训练信号。

智能体技能应该被当作代码来对待

这种系统最让人担心的问题很明显：你确定要让智能体重写自己的指令吗？答案是：可以，但不能偷偷摸摸地干。我们的做法是把智能体技能当作代码来管理，以此保证安全。

当智能体反复执行工作，提示词就成了你审查的对象。如果这些指令直接决定生产行为，它们就应该存在于代码库里，有版本历史、有代码审查、有回滚保障。每天的“学习智能体”不会直接改变生产行为。它会打开一个PR，清楚地展示它审查了哪些反馈、认为应该改动什么原则、技能文件的具体diff是什么。人类像审查其他改动一样审查它。

这样一来，我们既获得了自我改进的好处，又没放弃最终控制权。Buzz可以持续提出改进建议，但所有持久性改动都要经过审查，确保它不会一步步走向奇怪的方向。

现状如何

到今天，Buzz每个月处理成千上万条来自社交媒体平台的提及。其中大约一半不需要回复，这意味着团队只需要把精力花在那些真正需要关注的提及上——这已经是巨大的时间节省。Buzz运行在约15个技能上，涵盖分类、起草、学习、分析和报告。我们用

（warp.dev/oz）做智能体管理和编排，所以Buzz可以在后台运行，由定时任务或新提及触发。

结果就是：团队能完成更多工作，而不需要增加团队规模。大家把更多时间花在最擅长的事情上：判断什么重要、做品味决策、和社区建立关系，以及决定Warp应该给外界留下什么印象。

目标是积累判断力

做判断类工作的智能体，必须有一种方式能从它们所要模仿的那些人身上学习。

每当构建类似的智能体时，我们都会记住三件事：

• 原则优于规则
  ——规则容易过拟合，而原则可以灵活迁移；
• 智能体需要

  学会如何学习
  ——否则反馈只会变成脆弱的例外处理；

• 反馈循环
  必须活在团队已经工作的地方——否则没人愿意参与。

我们并不想把人类的判断和品味从系统中移除。恰恰相反，我们希望它们能不断积累。每次团队纠正智能体，下一次运行就应该比上一次更好。每一个持久的改进都应该经过审查，并正式纳入系统。

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