Mikyo King：代码模式、沙箱与智能体评估

我是 Mikyo King，领导 Arize AI 的开源团队。我们开发开源可观测性和评估框架，也开发自己的智能体。我想解释什么是代码模式，以及我们如何采用它。

传统上，面向工程师和非工程师的软件有所不同。程序员如果需要收集电子邮件发票，可以写脚本；其他人则要在现有界面内操作。编码智能体能够动态生成一些针对任务的软件，改变了这一边界。

传统智能体可能获得一份庞大的工具目录。随着反复调用工具，定义和结果不断在上下文窗口中累积。更多工具、无关输出、分页和长任务可能造成上下文膨胀、增加轮次，最终需要压缩。

代码模式是一种替代架构。智能体可以搜索工具，并在编程环境中执行它，而不是接收完整目录。它可以顺序调用、并行运行或使用条件判断，并只把模型上下文所需的信息返回。

与把每次工具结果都累积到上下文中相比，良好实现的代码模式可以减少开销和轮次。King 强调渐进披露：模型发现并理解当前任务需要的工具，而不是预先接收所有定义。

可组合性让智能体能够串联或并行展开调用。它还可以在返回模型之前裁剪或搜索工具输出。King 认为另一个好处是涌现行为：当没有专用工具时，智能体可能为任务编写小程序。

例如，程序可以先从记录中移除个人身份信息，再返回结果，而不是把敏感值直接放进上下文。这种能力取决于具体实现和沙箱边界。

在 Arize Phoenix 中，团队首先向智能体提供 Bash，使其能够把标准命令行工具与自家 CLI 组合，并将中间结果保存到文件。团队还增加了 Python 沙箱，将 traces 和数据集的 REST 创建、读取、更新和删除操作提供给智能体。

团队加入 SQL，因为不是每个有用的问题都适合用 CRUD 工具解决。聚合查询可以找到具有特定延迟特征的 spans，而不必让模型在上下文中逐页读取所有 traces。

Arize 还构建了与浏览器界面绑定的编程接口。在 web worker 中运行的代码可以访问应用状态，例如时间范围或前端数据存储。King 认为，这让代码能够完成更复杂的界面交互。

代码模式并非没有代价：生成代码需要资源。托管沙箱必须管理 CPU、内存和生命周期。网络出口尤其值得关注，因为智能体可能需要访问网络，同时遇到不可信内容。

密钥和权限也很难处理。沙箱可能需要模型或服务凭证，但这些密钥不应返回模型上下文。单个操作看似合适的权限，到了后续操作或组合工作流中可能变得过宽。

运维也更复杂。沙箱可能启动失败，调试一个程序与调试单个工具调用不同。工具参数的准确性变成了代码准确性，工作流也可能中途失败。工具发现仍需要一种方法来找到并理解可用工具。

King 还指出，当 MCP 和智能体运行框架都实现代码模式时，会出现嵌套沙箱。结果可能需要在环境间序列化和解析，增加工作量。持久性仍是待解决问题：长程序中途失败后可能无法从失败步骤继续。

当确定性或数学运算重要时，编程语言的选择可能产生影响。图像等二进制数据也是挑战：把完整图像序列化进上下文并不可取，因此可能需要独立交接方式。与前沿模型相比，较小模型也可能更难胜任代码模式。

为了评估这一方法，Arize 使用 Phoenix 平台和 Harbor 框架。智能体在禁用网络访问的沙箱中执行明确定义的任务。团队重复试验、用验证器评分任务完成情况，并跟踪各任务的 pass-at-k，以考虑轨迹的变化。

King 展示的前后比较报告 token 减少 43%、成本降低 31%。尽管存在沙箱开销，幻灯片显示奖励值相同、延迟增加 0.6%。他将其视为所评估配置的证据，而非普遍保证。

同时记录轨迹和评估结果，有助于团队理解失败并改进指令。新工具加入后效率可能一开始下降；轨迹可以揭示哪些指令让智能体走错方向，帮助后续迭代。

King 最后强调更少轮次、更低成本，以及智能体构建长时程行为的潜力。他鼓励团队尝试沙箱并评估自己的智能体，而不是假定这种架构一定更好。