我分析了246个代码仓库和57篇论文，关于AI代理框架。以下才是实际有效的做法

似乎越来越多的人在构建代理框架（包括我自己），但很少有人衡量它们是否真的有效。由于框架工程仍然是一个相对较新的领域，我想自己做研究，弄清楚哪些实践正在成为最佳实践，而哪些只是炒作。因此，我查看了246个开源仓库和57篇出版物，试图获得更清晰的画面。我想在这里分享一些我的主要收获，以防其他人陷入这个兔子洞。总之，模式相当清晰：最好的框架是小的、基于证据的并且不断改进的。似乎有效的做法包括：自己编写框架（或让其他人类完成）：ETH Zurich的一项研究发现，机器生成的上下文实际上降低了任务成功率，相比之下，给代理无上下文的情况下成功率更高，同时推理成本增加了20%。人工编写的上下文将成功率提高了约4%。所以，不要将编写框架外包给代理。根据观察到的失败来构建框架：现代代理已经相当有能力，框架应该弥补你看到的实际弱点。同样地：限制暴露给代理的工具和技能：仅在有真正需要时添加技能或专门的子代理，而不是因为它们流行。Vercel移除了80%的工具，成功率从80%跳到了100%，同时令牌减半。Microsoft将100个工具削减到2个。这里少即是多。一次改变一个组件并衡量影响：基本上是科学方法。如果你改变5件事并且情况变好了，你不知道是哪一个帮助了（或者哪一个在默默使事情变糟）。同时拥有测试和评估：就像代码一样，框架可能包含错误或过于冗长或模糊的指令，这些指令并不总是有效。不要假设你的AGENTS.md、钩子或脚本在做任何事情，仅仅因为它们存在，因为指令可以被简单地忽略。测试“应该发生”和“不应该发生”的情况：这个我个人就吃过亏。如果你的测试只包含必须被阻止的事情，收紧守卫总是安全的，而放松它是看不见的。所以框架慢慢偏向阻止一切，基本上扼杀了代理。片面的评估导致片面的优化。好奇听听其他构建代理的人：你是如何衡量你的框架是否真的有帮助的？