AI圈人士最近在忙什么？

最近，我参加了在旧金山举办的AI Engineering大会，这次经历让我对AI领域的现状有了更清晰的认识。大会演讲大致分为两类：85%的参会者是来自企业的用户，他们试图学习如何在组织中更好地利用AI；而剩下的15%则是真正处于前沿的人，他们探索了自动化软件的深度，甚至带回了一些“克苏鲁式”的恐怖故事。我原本期待后者会占更大比例，但实际结果让我有些惊讶——即使在这个高度筛选的环境中，绝大多数人仍然不知道如何有效使用AI。

AI世界每个月都有新热点。一月份是起飞，二月份是“什么是技能”，三月份是“每个人都必须使用Claude Code”，四月份是让运维团队加入，五月份是token最大化。而六月份显然变成了“技能泛滥”月。有十几个演讲的变体都是“我们如何管理组织中创建的1000个技能？”这些演讲场场爆满，这应该能反映出大部分市场的关注点。在我的公司Nori，我们早在去年十二月就解决了这个问题（参见noriskillsets.com，一个基于开源本地技能管理客户端的团队级包管理器）。

然而，许多关于“技能管理”的演讲让我感到失望。我认为拥有那么多技能是一种“代码异味”。根据我的经验，智能体非常擅长从基本原理出发解决问题。一个技能可能会漂移、可能不会增加任何新内容、还需要管理，这更可能制造问题而非解决问题。坦率地说，我认为许多在组织中处理数百个技能文件的团队，是因为员工乐于让编码智能体为各种事情生成技能，而没有严格验证它们是否真的有用。这给人一种“AI赋能”工作的假象，但实际上并非如此。

另一个让我失望的是，很多演讲都涉及某种形式的自我学习，即让智能体阅读转录并自动创建技能，以至于我专门写了篇文章。任何没有人类参与上下文管理的流程都会迅速失控，这正是我们最终拥有如此多技能的原因。在我看来，你不能真正依赖智能体来为你编写好的技能。这个过程需要有意识地进行。我们发现有一种特定的格式非常有效：将技能集打包成特定组，而不是简单地堆砌一堆技能然后加上搜索服务器。每次与智能体交互都像是从虚空中召唤一个实体，而与智能体捆绑的特定技能是获得最高质量结果的关键部分。试图让智能体大脑“糊化”只会产生混乱的结果。

关于评估（evals），这个术语在AI领域被严重过载。研究人员和模型提供商使用“评估”来指代可以用于评估原始模型性能的基准测试，如SWE-Bench、Humanity's Last Exam和ARC-AGI。这些评估是人为设计的，为研究人员提供改进模型训练的指标。而工业界部署这些模型的人使用“评估”来指代回归测试，用于使生产工作流尽可能确定，例如“AI是否正确标记数据”或“它是否会在客服窗口中正确回应对抗性输入”。尽管前者对前沿人员更相关，但我认为后者是许多大型企业所考虑的，因此也是大部分听众所关心的。

AI在不同类型的组织中有着不同的应用方式。在科技公司和初创企业，员工主要将AI作为开发工具使用，如Cursor和Claude Code。开发者每天大部分时间都与此类界面交互，因此对AI的能力有相当深入的了解。然而，在其他行业如银行和零售，工程并非核心职能，AI的主要使用方式是作为基础设施。最常见的形式是ETL管道——一个定期从某个表提取数据、进行转换然后加载到另一个表的过程。传统ETL管道脆弱且需要大量API和字段的调整。LLM凭借其固有的灵活性，有望大大简化这一努力。但新技术从未被完全采纳，尤其是在大型、行动缓慢的公司中。新技术的引入通常是作为现有系统的补充或替代。这就是为什么AI在很多公司中落脚于ETL世界——因为这是最适合的现有形状。不幸的是，ETL管道需要一致性和可审计性，而AI智能体两者都不具备。

因此，token最大化在大型科技公司意味着“给个人开发者无限预算用于Claude Code之类”，而在其他地方则意味着“向这些失败的ETL管道投入更多令牌，使其从80%正确率达到100%正确”。一种天真的方法是构建另一个AI系统来检查第一个系统的输出。但如果那个也失败了呢？你可能需要构建第三个系统来检查第二个系统的输出。这显然是个问题。现在token最大化已死，一些技术能力较弱的公司已将员工每月的令牌支出限制在50-100美元左右。

最后，关于云端智能体：当Claude Code在本地运行时，它会困在你的机器上，造成巨大的安全漏洞，并且难以协调和协作。云端智能体解决了这些问题：它们可以从任何地方访问，集中化带来安全、可观测性和治理方面的优势，并且是迈向“全自动化企业”的必要步骤。云端智能体可以响应事件和定时器，自动执行任务。

总之，这次大会让我清楚地看到了旧金山与其他地方之间的鸿沟。前沿人员谈论的是云端智能体和强化学习环境，而大多数观众则关心如何让ETL不再糟糕。我的建议是，不要试图让AI系统达到100%的正确率，而是让AI完成95%的工作，然后由人类审核剩余部分。