智能体需要的是反馈循环，而不是完美的提示词
对于从事判断类工作（judgement-heavy）的智能体（Agent）来说，最初的提示词只是一个起点。最好的智能体能够从团队身上学到什么是"好"的标准，并随着时间推移不断自我进化。
每个人都在尝试为智能体编写更好的提示词。这确实有用，但它忽略了一个重要的挑战：今天你能写出的最好的提示词，一个月后可能就不再是最佳方案了。
你的产品在变化，用户在变化，团队的品味在不断打磨，新的边缘案例不断出现。而且，如果智能体做的工作需要判断力和品味，任何静态的提示词都不可能覆盖它需要知道的一切。
这个问题把我们要问的问题从"如何写出完美的提示词"变成了"如何构建一个在发布后能持续向团队学习的智能体？"
我们在Warp构建一个帮助开发者体验团队处理社交媒体提及时就遇到了这个问题。我们喜欢和用户聊Warp，听取他们的疑问和反馈，认真对待每一个和我们交流的人。我们社区每周产生超过一千条提及！这种情况下小团队根本跟不上。
那些"差点就成"的智能体面临的挑战
在很多智能体开发中，核心循环很直接：智能体尝试某件事，检查是否成功了，然后重试。如果是写代码，通常有明确的信号可以用：测试、构建、浏览器检查、命令行输出。
社交媒体回复可没那么简单，因为智能体没有合适的"外部检查"可用。它不能先发一堆公开回复，然后等着看人们是更信任我们还是更不信任我们，去推断品牌调性是否对，然后再重试。这个反馈循环太长、太嘈杂、成本也太高。很多公司内部的有用工作也是如此：客户外联、客服回复、代码审查意见、产品反馈分析、文档、招聘消息。这些都需要知道什么重要、什么时候不该行动。
我们见过很多智能体卡在这种状态：它们"差点就成"。能力显然存在，输出好到让人抱有些希望，但还没好到可以放心信任的程度。团队不停地调整提示词，指望下一个版本能缩小差距。
我认为这是错误的抽象层次。让智能体做对一次不是难点。难点在于构建一个系统，让智能体能从团队已有的工作方式中不断变好。
我们构建的智能体
我们把这个智能体叫做Buzz。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个技能上，涵盖分类、起草、学习、分析和报告。我们用Oz（warp.dev/oz）做智能体管理和编排，所以Buzz可以在后台运行，由定时任务或incoming提及触发。
这让团队能完成更多工作而不增加团队规模，把更多时间花在我们最擅长的事上：知道什么重要，做品味判断，和社区建立关系，以及决定Warp应该给外部的人什么样的感觉。
目标是积累判断力
做判断类工作的智能体需要一种方式，从那些他们试图近似的判断力的人身上学习。
每当我们在构建类似的智能体时，我们记住这三件事：
• 原则优于规则，因为规则会过拟合而原则可以迁移。 • 智能体需要学会如何学习，否则反馈变成脆弱的例外。 • 反馈循环必须活在团队已经工作的地方，否则人们就不参与了。
我不想把人类的判断和品味从系统中移除。我想让它们不断积累。每次团队纠正智能体，下次运行应该好一点。每个持久的改进都应该被审查和check in。
随着时间推移，智能体变得不像某个人写过一次提示词，而更像是团队思维的工作记忆。最好的团队不只是写更好的提示词，他们会构建更好的循环。
