# Agents Need Feedback Loops, Not Perfect Prompts
**作者**: Petra Donka
**日期**: 2026-05-14T12:13:14.000Z
**来源**: [https://x.com/petradonka/status/2054897826149101588](https://x.com/petradonka/status/2054897826149101588)
---
For agents doing judgement-heavy work, the starting prompt is only the beginning. The best agents learn what good looks like from the team and improve themselves over time.
Everyone is trying to write better prompts for agents. While that’s useful, it misses an important challenge: the best prompt you write today will not be the best prompt a month from now.
Your product changes. Your users change. Your team’s taste is refined over time. New edge cases present themselves. And if the agent is doing work that requires judgement and taste, no static prompt could cover everything it will need to know.
This changes the question from “how do we write the perfect prompt?” to “how do we build agents that keep learning from the team after they ship?”
We ran into this at Warp while building an agent to help our Developer Experience team respond to people mentioning us across Twitter, Reddit and other channels. We love talking to users about Warp, hearing their questions and feedback, and care deeply replying to people who talk to and about us. Folks in our community generate more than a thousand mentions per week! That’s more conversations than any small team can keep up with by hand.
## The challenge with agents that almost work
In a lot of agentic development, the core loop is straightforward: the agent tries something, checks whether it worked, and retries. If it is writing code, there are often concrete signals it can use: tests, builds, browser checks, command output.
Social replies do not quite work that way, because the agent doesn't have a sensible "external check" available to it. It cannot send a bunch of public replies, wait to see whether people trust us more or less, infer whether the brand tone was right, and then retry. The feedback loop is too long, too noisy, and too expensive. The same is true for a lot of useful work inside companies: customer outreach, support replies, code review comments, product feedback analysis, docs, recruiting messages. They require knowing what matters and when not to act.
We’ve seen a lot of agents get stuck in this state: they almost work. They are clearly capable, and the output is good enough to get your hopes up, but not good enough to trust. The team keeps tweaking the prompt and hoping the next version will close the gap.
I think that’s the wrong level of abstraction. Getting an agent to do the task once is not the hard part. It is building a system where the agent gets better from the way your team already does the work.
## The agent we built
We call the agent Buzz. Buzz monitors mentions of Warp across Twitter, LinkedIn, and other platforms. When a new mention comes in, it decides whether we should reply, like, note, or skip it. If we should reply, it drafts a message and posts the suggestion into Slack.
Right: feedback to Buzz in a Slack thread. Left: the daily PR where Buzz links the resulting skill updates.
Every reply is still written by us personally in the end, but this alone saves a ton of time: the team no longer has to watch every platform, open every thread, decide whether each mention matters, and start every reply from scratch. We wanted to automate as much as we reasonably could without sacrificing valuable engagement or compromising the quality. Every reply is public, represents our brand, and shapes how people experience the company. We needed the agent to learn how our team thinks about community engagement.
## Principles beat rules
The first version of Buzz looked a lot like many first versions of agents: a long checklist of rules. If someone mentions a bug, say this. If someone compares us to another tool, say that. If someone asks about pricing, mention this plan.
This was very brittle. The prompt got longer, the replies were robotic, and the agent broke the moment a situation appeared that we had not told it about. So we shifted the skill from rules to principles. Instead of trying to enumerate every case, we wrote down the durable ideas that guide good replies:
- Be helpful, not defensive.
- Do not talk down to the user.
- Check factual claims against the docs.
- Sound like someone who builds the product, not someone who processes feedback.
This made the skill file smaller and the agent a lot better. The replies started to sound more like something we would actually say, and the agent could handle more situations because the instructions were no longer a giant decision tree. Principles only gave Buzz a better starting point, though. We couldn’t encapsulate everything it could possibly need.
## Feedback is not learning unless the agent can generalize
Once Buzz had a decent principles-based skill, we started giving it feedback.
It would draft a reply. I would say what was wrong with it, or write the reply I would have used instead. Then Buzz would try to update its own instructions based on that feedback.
This got us to the next failure mode: the agent wanted to turn every correction back into a rule. For example, if I said a reply felt too marketing-y, it’d add a rule: “Never mention pricing in the first sentence.” The transferable principle is closer to: “If someone is venting, lead with empathy, not a pitch.” The agent needed to be taught how to learn from feedback.
So, we built a separate skill for that. It looks at the agent’s suggestion, what the human did instead, and the current instructions, then asks: what principle is missing or unclear to achieve the expected output?
The reply-learning skill on GitHub
The learning process is roughly:
1. Identify what went wrong (or right) — start from specific feedback, be concrete
2. Ask: why? — the failure is a symptom, find the underlying cause
3. Zoom out to the pattern — would this apply beyond this one case?
4. Check against existing principles — sharpen, edit, delete, or add?
5. Write it as a principle, not a rule — describe how to think, not what to do
6. Put it where it belongs — section matters for the agent to apply them right
7. Edit and commit — update the skill file, keep it tight, merge overlapping principles
It felt a lot like teaching a new team member and enabling them to learn broader ideas. A useful side effect was that feedback forced us to be clearer about our own judgement. A lot of taste lives implicitly in people’s heads. Teaching an agent forces it onto the page.
## The feedback loop has to fit the team
At this point, Buzz had two pieces of the larger puzzle: principles for doing the job, and a way to learn better principles from human feedback. But, who was going to keep teaching it? We did not want a recurring meeting, or a task to assign to someone.
Buzz already posted each mention into a Slack channel with its recommendation and draft reply, so we made the feedback interface as small as possible: the team reacts with an emoji for what they actually did, and can optionally add a note in the thread. One click is enough signal; a thread is extra context.
Then, once a day, Buzz collects the reactions and thread feedback, compares its recommendations to what the team actually did, extracts durable learnings, updates the relevant skill files, and opens a PR.
That small Slack loop is what made the system work in practice. The best way to get leverage from agents is not to turn everyone into prompt engineers. It is to design workflows where the team’s normal judgement and taste become a training signal for the systems around them.
## Agent skills should be treated like code
There is an obvious concern with a system like this: do you really want an agent rewriting its own instructions? Yes, but not silently. We make it safe by treating agent skills like code.
When an agent does work repeatedly, the prompt starts to become the thing you review. If those instructions determine production behaviour, they should live in a repo, with version history, review, and rollbacks. The daily learning agent does not directly change production behaviour. It opens a PR showing what feedback it reviewed, what principle it thinks should change, and the exact diff to the skill file. A human reviews it like any other change.
This gives us the useful part of self-improvement without giving up control. Buzz can continuously propose improvements, but durable changes go through review, so we can make sure it doesn’t all veer off into a weird direction.
## How it's going
Today, Buzz processes thousands of mentions a month across our Twitter, Reddit, Bluesky, LinkedIn, and other channels. About half don’t need a reply, which means the team only spends time on mentions that need our attention — that's already a massive time save. Buzz runs on around 15 skills across triage, drafting, learning, analytics, and reporting. We use Oz for agent management and orchestration, so Buzz can run in the background and be triggered by scheduled jobs or incoming mentions.
That lets the team get more done without increasing the team size, and spend more time on what we are best at: knowing what matters, making taste calls, building relationships with the community, and deciding what kind of company Warp should feel like to someone on the outside.
## The goal is compounding judgement
Agents doing judgement-heavy work need a way to learn from the people whose judgement they are trying to approximate.
Whenever we’re building a similar agent, we keep these three things in mind:
- Principles beat rules, because rules overfit and principles transfer.
- Agents need to learn how to learn, or feedback turns into brittle exceptions.
- The feedback loop has to live where the team already works, or people stop participating.
I do not want to remove human judgement and taste from the system. I want to make them compound. Every time the team corrects the agent, the next run should get a little better. Every durable improvement should be reviewed and checked in.
Over time, the agent becomes less like a prompt someone wrote once and more like a working memory of how the team thinks. The best teams will not just write better prompts. They will build better loops.
## 相关链接
- [Petra Donka](https://x.com/petradonka)
- [@petradonka](https://x.com/petradonka)
- [66K](https://x.com/petradonka/status/2054897826149101588/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [8:13 PM · May 14, 2026](https://x.com/petradonka/status/2054897826149101588)
- [66.2K Views](https://x.com/petradonka/status/2054897826149101588/analytics)
- [View quotes](https://x.com/petradonka/status/2054897826149101588/quotes)
---
*导出时间: 2026/5/15 12:11:31*
---
## 中文翻译
# 智能体需要反馈循环，而非完美的提示词
**作者**: Petra Donka
**日期**: 2026-05-14T12:13:14.000Z
**来源**: [https://x.com/petradonka/status/2054897826149101588](https://x.com/petradonka/status/2054897826149101588)
---
对于从事大量判断类工作的智能体来说，初始的提示词仅仅是开始。最优秀的智能体会从团队中学习“好的标准”是什么，并随着时间的推移自我完善。
每个人都在试图为智能体写出更好的提示词。虽然这很有用，但它忽略了一个重要的挑战：你今天写出的最佳提示词，在一个月后未必还是最好的。
你的产品在变，你的用户在变，团队的品味也在不断精进。新的边缘情况会不断出现。如果智能体所做的工作需要判断力和品味，那么没有任何静态的提示词能覆盖它需要知道的所有情况。
这就将问题从“我们如何写出完美的提示词？”转变为“我们如何构建在发布后仍能不断向团队学习的智能体？”
我们在 Warp 构建一个帮助开发者体验团队回复 Twitter、 Reddit 和其他渠道提及的智能体时，就遇到了这个问题。我们喜欢与用户探讨 Warp，倾听他们的问题和反馈，并非常重视回复那些与我们交流或谈论我们的人。我们的社区每周产生超过一千条提及！这远非一个小团队能靠人力跟得上的。
## “差点就能用”的智能体面临的挑战
在许多智能体开发中，核心循环很简单：智能体尝试做某事，检查是否成功，如果不成功则重试。如果是写代码，通常有具体的信号可用：测试、构建、浏览器检查、命令输出。
社交回复的操作方式不太一样，因为智能体没有可用的合理的“外部检查”。它不能发送一堆公开回复，等着看人们对我们的信任度是增是减，推断品牌基调是否正确，然后再重试。这个反馈循环太长、太嘈杂，且代价太高。对于公司内部许多有用的工作也是如此：客户外联、支持回复、代码审查评论、产品反馈分析、文档、招聘信息。它们需要知道什么才是重要的，以及何时不该行动。
我们见过许多智能体陷入这种状态：它们几乎能用了。它们显然是有能力的，其输出足以让你抱有希望，但又没好到可以放心信任的程度。团队不断调整提示词，希望下一个版本能填补差距。
我认为这是错误的抽象层次。让智能体做一次任务并不难。难的是建立一个系统，让智能体从团队已有的工作方式中不断学习。
## 我们构建的智能体
我们把这个智能体叫作 Buzz。Buzz 监控 Twitter、 LinkedIn 和其他平台上关于 Warp 的提及。当有新提及进来时，它会决定我们应该回复、点赞、记录还是跳过。如果应该回复，它会起草一条消息并将建议发布到 Slack 中。
右图：Slack 线程中给 Buzz 的反馈。左图：Buzz 链接最终技能更新的每日 PR。
最终，每一条回复仍然是由我们亲自撰写的，但仅这一点就节省了大量时间：团队不再需要盯着每个平台，打开每个线程，判断每条提及是否重要，并从头开始写每条回复。我们希望在不牺牲宝贵互动或妥协质量的前提下，尽可能多地实现自动化。每条回复都是公开的，代表我们的品牌，并塑造人们对公司的体验。我们需要智能体来学习团队如何看待社区互动。
## 原则胜于规则
Buzz 的第一个版本看起来很像许多智能体的初版：一长串规则清单。如果有人提到 bug，这么说。如果有人把我们和另一个工具比较，那么说。如果有人问价格，提这个计划。
这非常脆弱。提示词越来越长，回复很机械，一旦出现我们没有告诉它的情况，智能体就会出错。因此，我们将技能从规则转变为原则。我们没有试图枚举每个案例，而是写下了指导良好回复的持久性想法：
- 要有帮助，不要防御。
- 不要居高临下地对用户说话。
- 对照文档检查事实声明。
- 听起来要像是构建产品的人，而不是处理反馈的人。
这使得技能文件更小，智能体也更好了。回复开始听起来更像我们实际上会说的话，智能体也能处理更多情况，因为指令不再是一个巨大的决策树。不过，原则只是给 Buzz 提供了一个更好的起点。我们无法封装它可能需要的一切。
## 除非智能体能推广，否则反馈不等于学习
一旦 Buzz 有了像样的基于原则的技能，我们开始给它提供反馈。
它会起草一个回复。我会说出哪里不对，或者写出我会用的回复。然后 Buzz 会尝试根据该反馈更新它自己的指令。
这让我们进入了下一个失败模式：智能体想把每一次修正都变回一条规则。例如，如果我说一条回复感觉太像营销了，它会加一条规则：“永远不要在第一句提到价格。”可迁移的原则更接近于：“如果有人在发泄，要以同理心开场，而不是推销。”智能体需要被教导如何从反馈中学习。
因此，我们为此构建了一个单独的技能。它查看智能体的建议、人类实际采取的行动以及当前的指令，然后问：为了达到预期输出，缺少或不清楚的原则是什么？
GitHub 上的回复学习技能
学习过程大致如下：
1. 识别哪里出错了（或正确了）——从具体反馈开始，要具体。
2. 问：为什么？——失败是症状，找到根本原因。
3. 放大到模式——这是否适用于这单一案例之外？
4. 对照现有原则进行检查——锐化、编辑、删除还是添加？
5. 将其写成原则，而非规则——描述如何思考，而非做什么。
6. 放在它属于的地方——章节对于智能体正确应用它们很重要。
7. 编辑并提交——更新技能文件，保持紧凑，合并重叠的原则。
这感觉很像教导一名新团队成员并让他们学习更广泛的想法。一个有用的副作用是，反馈迫使我们对自己的判断更加清晰。很多品味隐性地存在于人们的脑海中。教导智能体迫使其落实到纸面上。
## 反馈循环必须适应团队
此时，Buzz 拥有了这个更大谜题的两块拼图：做工作的原则，以及从人类反馈中学习更好原则的方法。但是，谁来继续教它？我们不想要一个经常性会议，或者要指派给某人的任务。
Buzz 已经把每条提及连同它的建议和草拟回复发布到一个 Slack 频道中，所以我们让反馈界面尽可能小：团队用 emoji 表情做出他们实际采取的行动，并可以选择在线程中添加备注。点击一下就足够作为信号；线程则是额外的上下文。
然后，每天一次，Buzz 收集反应和线程反馈，将其建议与团队实际采取的行动进行比较，提取持久性的学习成果，更新相关的技能文件，并打开一个 PR。
那个小小的 Slack 循环正是让系统在实践中运作起来的原因。从智能体那里获得杠杆作用的最好方法不是把每个人都变成提示词工程师。而是设计这样的工作流：团队的正常判断和品味成为周围系统的训练信号。
## 智能体技能应被视为代码
对于这样的系统，有一个明显的担忧：你真的想让智能体重写它自己的指令吗？是的，但不能悄悄地进行。我们通过将智能体技能视为代码来确保安全。
当智能体重复做工作时，提示词开始成为你需要审查的东西。如果这些指令决定了生产环境的行为，它们应该存在于仓库（repo）中，具有版本历史、审查和回滚功能。每日学习的智能体不会直接改变生产行为。它会打开一个 PR，显示它审查了什么反馈，它认为应该改变什么原则，以及对技能文件的具体差异。人类像审查其他变更一样审查它。
这让我们获得了自我完善的有益部分，而没有放弃控制权。Buzz 可以不断提出改进建议，但持久性的变更需要经过审查，所以我们可以确保它不会全部偏离到奇怪的方向。
## 现状如何
今天，Buzz 每月处理跨 Twitter、Reddit、Bluesky、LinkedIn 和其他渠道的数千条提及。大约一半不需要回复，这意味着团队只把时间花在需要关注的提及上——这已经节省了大量时间。Buzz 运行在大约 15 个技能上，涵盖分诊、起草、学习、分析和报告。我们使用 Oz 进行智能体管理和编排，因此 Buzz 可以在后台运行，并由预定任务或传入的提及触发。
这让团队在不增加团队规模的情况下完成更多工作，并花更多时间在我们最擅长的事情上：知道什么很重要，做出品味判断，与社区建立关系，以及决定 Warp 应该给外人一种什么样的公司感觉。
## 目标是判断力的复利
从事判断类工作的智能体需要一种从它们试图模仿其判断力的人那里学习的方法。
每当我们构建类似的智能体时，都会牢记这三件事：
- 原则胜于规则，因为规则会过拟合，而原则可迁移。
- 智能体需要学会如何学习，否则反馈会变成脆弱的例外。
- 反馈循环必须存在于团队已经工作的地方，否则人们会停止参与。
我不想把人类的判断力和品味从系统中移除。我想让它们产生复利。每当团队纠正智能体时，下一次运行都应该好一点。每一个持久的改进都应该被审查和提交。
随着时间的推移，智能体变得不再像某人曾经写过的提示词，而更像团队如何思考的工作记忆。最优秀的团队不会只是写出更好的提示词。他们会构建更好的循环。
## 相关链接
- [Petra Donka](https://x.com/petradonka)
- [@petradonka](https://x.com/petradonka)
- [66K](https://x.com/petradonka/status/2054897826149101588/analytics)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [2026年5月14日 下午8:13](https://x.com/petradonka/status/2054897826149101588)
- [66.2K 次观看](https://x.com/petradonka/status/2054897826149101588/analytics)
- [查看引用](https://x.com/petradonka/status/2054897826149101588/quotes)
---
*导出时间: 2026/5/15 12:11:31*