Designing Agents (The Floor Is the Frontier) — Ben Hylak, Raindrop

讲者来自 Raindrop 公司，一家专注 AI Agent 问题检测的初创企业。他开场指出，虽然 Agent 已部署于金融、医疗、国防等领域，但产业对 Agent 的认知仍停留在聊天机器人时代，这是根本问题所在。

Agent 并非简单的聊天机器人。聊天机器人的评估很直白——问"美国首都是什么"，检查答案是否为"华盛顿特区"。但 Agent 拥有工具使用能力、自主决策权和创意问题解决能力。当遇到障碍时，它会尝试反汇编代码、调用意想不到的工具组合，这既让 Agent 强大，也让评估变得复杂得多。

讲者观察到，网上关于 Agent 评估的讨论多数仍在讨论"1000 个评估数据集"这类聊天机器人时代的做法，但现实中没几个公司真的这样做。根本问题是：一旦你切换模型（比如从 GPT 转向 Claude Code）或框架，投入数月打造的评估系统立刻失效。因此讲者强烈建议不要投入过多精力在庞大的静态评估框架上，而应该像对待代码一样对待评估——让它更像单元测试，更灵活、更可维护。

讲者重点阐述了两个核心概念。一是"天花板"与"地板"。天花板指 Agent 能达到的最高能力——有时候不可预测的创意解决方案很有用。地板指最坏情况——推荐竞争对手、误删关键数据、因为能访问邮箱而无意间发送 AI 生成的垃圾邮件。讲者强调，地板比天花板更值得关注，因为那些底层故障最容易摧毁用户信任。用户很少因为 Agent 功能不够强而流失，但会因为一次严重的失误而永久离开。

在问题发现的具体方法上，讲者提出了三个他认为"从未被公开讨论过"的策略洞见。第一个是反对盲目聚类。许多公司的朴素做法是把所有执行痕迹收集起来，然后聚类寻找规律。这对一次性错误分析可能有帮助，但无法很好扩展。聚类在追踪时间变化时不可靠（学术界已知的"时间聚类"是难题），且边界模糊——"价格错误"和"退款计算错误"可能源于完全不同的代码路径，但聚类会将它们混为一类，掩盖真实原因。

第二个策略是依据两个指标判断优先级：问题何时开始和影响多少用户。如果一个问题昨天才出现，你能快速追溯变化（是换了模型？改了工具链？）。如果仅影响 3 个用户而非 10 万个用户，应对策略截然不同。讲者分享了丰富的客户经验：从只有 5 个用户的企业内部应用（可能需要完美的一对一修复），到日均千万级消息的平台（可以做 A/B 测试和大规模实验），策略必须因人而异。

第三个策略是用代码模式（Code Pattern）替代聚类。代码模式涉及编写分类器来精确追踪和分类问题，这些分类器可在沙箱中开发，也可在生产规模运行，具有强大的可扩展性。讲者特别强调这在 Model Context Protocol 的背景下更显价值，并推荐所有公司尝试这个方法。

讲者给出了最后一个反直觉但至关重要的建议：不要让 Agent 去做异常检测。Agent 在这方面表现很糟糕。正确的做法是用确定性的、易于量化的指标（比如关键词出现频率突然激增）来发现潜在异常，然后让 Agent 对这些已确认的异常进行深入调查和诊断。这样既充分发挥了 Agent 的创意和推理优势，又避免了它在无结构、无方向的探索中的弱点。