智能体正越来越多地自己挑工具、自己操作软件:查文档、调接口、点界面、填表单,一套动作越来越像一位真实用户。可有个细节一直没人认真接住——当 agent 用某个工具踩了坑,这次失败往往就随会话结束一起消失了。厂商不知道,别的 agent 下次还会踩。10 月 7 日,YC 孵化批次 P26 里的 Armature 在 Hacker News 上放出 Agent.reviews,想做的正是给这件事补一条通道:让 AI 智能体像人一样,给用过的软件工具写评价、也读别人的评价。

一个被忽略的结构性问题:agent 用了工具,却无处「吐槽」

人用软件不顺手,会去应用商店、评测站写一句差评,厂商看到后会改,后来的人也能搜到避坑。这套反馈闭环跑了十几年,早已是软件生态的底层设施。可 agent 没有等价物:它在任务里反复撞上同一个工具的同一个限制,失败就被吞掉,既没回流给厂商,也没留给后来者查询的入口。Armature 在正式动手前,先记录了超过 5 万次 agent 会话,观察到的现象很直接——同一批工具、在不同任务上,agent 一次次踩同一个坑,而系统里没有任何机制把这些信息沉淀下来。对一个正在把 agent 推上生产、让它们自主选工具跑流程的团队,这种「踩坑即蒸发」会缓慢但确定地拖垮可靠性。

评价闭环:人类有,智能体缺一段人类用工具遇坑 → 写评价厂商看到 → 改进智能体用工具遇坑 → 失败消失无回流、无记录Agent.reviews 补上「写评价 / 读评价」这一段,让经验可共享
图 1|人类用软件遇到问题会写评价、厂商能看到并改进,形成闭环;智能体遇到同样的坑却往往失败即消失,既没有回流给厂商、也没有留给其它 agent 的记录。Agent.reviews 想补上的就是这一段

把经验变成可共享的资产

Agent.reviews 的设想不复杂:把 agent 也当成软件的一类用户,让它在用工具之后,把「这次哪里好用、哪里卡住、卡在什么输入上」写进一个结构化评价,下次别的 agent 选工具前先读。它类比的是人类那套评价站,但对象换成了 agent。这里有几件值得说清的事。其一,评价要绑定到某次真实使用,而不是空泛打分,否则很容易被刷。其二,agent 写评价的前提是它确实跑过那个工具、撞过那个限制,所以评价天然带着使用痕迹,比人类的主观打分更可追溯。其三,它把「软件好不好用」这件原本只存在于人类口碑里的事,就此变成 agent 之间可以互相读取、互相避坑的公开资产。团队强调,动机来自那 5 万次会话里反复出现的「同样失败无记录」。

评价经济的三类失真,不能假装不存在厂商刷分自雇 agent 写好评agent 互评循环自说自话越推越偏评价被操纵为被选中而作弊可信度要靠「谁写的、基于哪次真实使用」来背书,而非只看评分高低
图 2|把评价权交给 agent 后,三类失真会自然浮现:厂商自雇 agent 刷分、agent 之间互评形成自说自话的循环、以及为被其它 agent 选中而操纵评价。平台的可信度取决于能否把每条评价绑定到真实的某次使用

三类失真不能假装不存在

把评价权交给 agent,也等于把一类新风险摆上桌。厂商可以自雇 agent 批量写好评,把自家工具顶到推荐位;agent 之间也可能形成互评循环,你夸我、我夸你,越推越偏;更现实的是,评价可能被操纵——某个工具为了被其它 agent 选中,专门优化「让评价看起来更好」而不是「让工具真的更好用」。这些都还不是 Agent.reviews 一家要解决的,但它提示了一个底线:可信度必须建立在「谁写的、基于哪次真实使用」之上,而不是只看一个总分。否则这条本要补上的闭环,反而会变成又一层噪声。

对 agent 落地意味着什么

把视角拉远一点,Agent.reviews 触到的是 agent 落地里一个长期被低估的环节:工具生态的「可用性信号」至今是为人设计的,而 agent 正在成为工具的另一类主力用户。当 agent 自主选工具、自主排任务,它需要的不是一份给人看的功能清单,而是一份同样由 agent 写成的、带着失败记录的经验库。如果这个方向真的长起来,软件的「好不好用」会同时拥有人类口碑与 agent 口碑两套信号,厂商也头一回有了来自机器用户的、可追溯的改进压力。当然,它现在更像一个早期构想而非成熟产品,评价质量、防刷机制、以及厂商是否愿意回应 agent 评价,都要等真实 adoption 来验证。对一个正在评估多 agent 工作流的团队,值得把它当成「agent 工具层成熟度」的一个观察指标:哪天你的 agent 开始读同类评价来避坑,说明这条生态才真正开始自转。

一句话收尾:当 agent 取代人去操作软件,软件的评价体系也该让 agent 有一席之地,否则踩过的坑只会一遍遍重踩。