最新

标签页、分屏和 tmux 用起来没问题，直到你同时打开了多个项目，里面有日志、测试和长时间运行的 shell。我以前总是重建上下文，而不是恢复工作。Horizon 把 shell 放在一个无限的画布上。你可以把它们组织成工作区，稍后重新打开时，布局、滚动回溯和历史记录都保持不变。 用 Claude/Codex 在 3 天内构建完成，并且在构建过程中一直在使用这个工作流程。欢迎提供反馈和贡献。

我尝试使用基准测试的方式来评估一个 AI 智能体。<p>结果它以我意想不到的方式失败了。<p>大多数失败并非源于模型质量问题，而是系统层面的问题。以下是一些来自小型测试套件的例子：<p>- 工具调用中的 URL 链接失效 → 分数降至 22<p>- 智能体在云环境中调用本地主机 → 卡在 46 分<p>- 真实的 CVE 漏洞被标记为幻觉 → 评估问题，而非模型问题<p>- Reddit 屏蔽请求 → 外部依赖失败<p>- 生产环境中 API 密钥缺失 → 静默失败<p>每次运行都会暴露一个真实的 bug，但并非我最初试图衡量的类型。<p>令我惊讶的是，评估智能体不仅仅是评估输出结果。它还涉及到验证整个系统：工具、环境、数据访问，以及智能体与所有这些的交互方式。<p>换句话说，大多数失败模式更像是软件 bug，而不是 LLM 的错误。<p>这让我认为，智能体的评估循环应该更像软件测试，而不是基准测试： - 可重复的测试套件 - 明确的通过/失败标准 - 回归检测 - 根本原因分析<p>否则，很容易将失败归咎于模型，而实际上它们来自其他地方。<p>我最终构建了一个小工具来规范这个流程，但对我来说，更大的收获是，与标准基准测试相比，现实世界中的智能体评估实际上是多么混乱。<p>很好奇其他人是如何处理这个问题的，尤其是在生产环境中。