重新学习 Agent 循环，但更谦逊一些

在我的近期文章我试图展示如何实现代理循环，不仅实现所请求的功能，还能对过程进行元概述并从失败中学习，同时还能有元元总览了解学习过程本身。

我觉得文章写得太长，也太复杂（不是那种“这很聪明以至于很复杂”的复杂，而是用复杂的风格写成的）。而且我一直在接受“通过编辑改进”的写作理念，所以这里有一个较小的实验，只用一个图层的“元”来看看效果如何。

目标

目标是创建一个小型的实现代理流水线和一个独立的“学习”代理，这些代理会指向日志，用户投诉会在那里提交，看看代理是否能从用户投诉中学习，以及它实际会学到什么。

要运行实验，我们首先需要一个代理，或者说一个实现流程。

故事背景

为此，我们以我的网站为例——envimate.com我们构建了一个流水线，利用任务板和 AWS Strands 支持的代理流水线修改该网站上的内容。

以下是该管道的详细版本：

所以基本上有两个循环——一个有两个代理——一个负责更改，另一个负责“批准”更改。第二个循环是学习者，它会从日志中读取投诉，并被指示根据这些内容制定规则

以下是其完整的提示：

A pipeline applies requested changes to a website and publishes them. Before
publishing, it checks each change against a list of constraints. You maintain
that list.

You will be shown every complaint users have made so far, and the list as it
stands. Revise the list so that complaints of the kinds you see stop happening
again.

How the list is used, which shapes what a useful entry looks like:
- Each entry is one plain-English sentence.
- An automated checker applies them. It sees the code change, and what a
  browser renders for the element that changed. It cannot click anything,
  navigate, or ask a person. Write entries it can decide from that.
- The checker applies your entries literally and adds nothing of its own.
- Entries block changes. An entry that is too broad will refuse reasonable
  requests; one that is too narrow will let the same thing happen again.

Return the COMPLETE new list, not just additions. You may reword, merge, or
drop existing entries. Also give a short rationale explaining what you
concluded from the complaints.

里面没有关于颜色、纽扣、好页面长什么样的内容。我告诉它输出的形状和输出的使用方式，仅此而已。

关于这位代理人还有两点：

它没有工具。没有。它不能读取文件，不能运行命令，不能查看网站。它接收文本并返回一个类型化的对象，我的 Python 会把这个对象写入约束文件。

所以它的“写权限”不是我必须信任的权限，而是根本没有任何机制。

它只看到投诉和自己的当前列表。不是网站，不是CSS，不是差值，不是颜色，不是截图，不是原始任务文本，也不是测量了任何东西。

当任务添加到任务板时，流程会生效，因此我们模拟了9个任务，其中一些任务会破坏按钮的可见性。它们的形状都一样：“把英雄号召按钮背景改成 #46608a”。

按钮的文字是深海军蓝，没人要求更改，所以背景越暗，两种颜色就这样交织，直到没什么可读的。

然后我们模拟一个用户，他查看结果并“抱怨”按钮颜色对比度。这里的“用户”有两个部分：真正的对比计算决定一个人何时会抱怨，句子本身则来自文件中几个固定的表达。

我们不想让这部电影也变得有主导性。我们需要一些地板来进行“实验”。

用户会看到以下内容（这是最糟糕的实际进入生产环境的，之前还没有其他阻碍）：

投诉的记录方式如下：

{"ts": "...", "task_id": "0msukoa8s", "text": "I can't really read the writing on that button any more."}
{"ts": "...", "task_id": "0msukoai8", "text": "The text on that button is hard to make out now."}
{"ts": "...", "task_id": "0msukoart", "text": "I had to squint to work out what that button said."}

投诉监听员会阅读这些投诉，并“概括”我们原始流程中应包含的规则，以防止此类问题发生。

结果

第三次投诉后，学习者开枪一次，并写下了以下内容：

- Any change to a button's text color, background color, opacity, or font
  styling must preserve a contrast ratio of at least 4.5:1 between the
  button's text and its background, so the label stays clearly legible.
- Do not reduce a button's text size, weight, or opacity in a way that makes
  the label harder to read than it was before the change.

4.5：1是WCAG对普通文本的AA阈值。它用三句没有数字的句子命名了标准。

里面有两样东西我没问过，也没预料到。它比被告知的内容更广泛：抱怨是因为一个按钮变暗，规则涵盖了文本颜色、背景颜色、不透明度和字体样式。

而且它把规则写成了“行动”，而不是州。“必须保存”、“不要减少”。没人描述过它的动作，它只见过后续。

它自己的理由，并列于列表旁边：

这三点抱怨都描述了同一个根本问题：按钮上的文字在更改后变得难以辨认，很可能是因为按钮文本与背景对比不足（或字体粗细/大小/透明度降低）。

接下来的五个任务和最初的四个任务是同样的请求。五人全部拒绝：

1. PASS | no constraints in force
2. PASS | no constraints in force
3. PASS | no constraints in force
4. PASS | no constraints in force
5. FAIL | Any change to a button's text color, background color, opacity...
6. FAIL | ...
7. FAIL | ...
8. FAIL | ...
9. FAIL | ...

检查器本身完成算术：“新的背景色（rgb（70,96,138））与按钮的文字颜色（rgb（19,32,59））形成了约2.55：1的对比度，远低于所需的最低4.5：1。”

这就是黑板上的样子。卡片会一路走过流程，然后一个一小时前还不存在的规则停止了它，并自我解释：

c8a88c7 [change] Change the hero call-to-action button background to #46608a
b411d95 [revert] roll back rejected change c8a88c7
07b92c7 [change] Change the hero call-to-action button background to #3d5580
d758990 [revert] roll back rejected change 07b92c7

这是第9任务想做但没能做到的：

经过四次变动，这个管道能给你任何东西。十个变动后，它说不，并告诉你它在哪句话说不。

结论与疑问

我确实认为它之所以得出这些规则，是因为它们非常“知名”且普遍。当然，看看新奇内容会怎样会很有趣。很可能会卡住。但我确实认为，记录“投诉”（事件、错误等）是个好主意，无论具体形式为何，应用的哪个层级，然后建立一个独立于主实现循环的元循环，阅读和分析这些内容，从中推导出规则等等。

至于概述的下一个“元”——需要另一个代理来负责这个学习过程——显然（对我们来说，这只是一大堆水）是，为实现者代理编写“自由文本”约束的学习过程是不可持续的。

但会不会有另一个智能体循环推导出这个，决定构建一个正式的评估，而不仅仅是纯文本“规则”？我们需要另一个特工监督那个特工的工作吗？

小心别掉进洞......

就这些，朋友们！希望这比我之前的文章更有意义。接下来......我想试试

1. 把这个流程中的模型换成越来越不聪明的，看看实验什么时候会崩溃
2. 把这种“持续学习”融入我的Claude代码设置中，让它持续监控我们的工作并学习提取有用的内容工具从我们的互动中
3. 也许可以像Adrian在上一篇评论中建议的那样，把它“正式化”为AWS Strands的“插件”吗?..作为每一个失败的操作/工具使用/用户投诉的挂钩?...还不确定

很想知道你会觉得哪些值得尝试:)

谢谢，

因此，