Arize 如何重建 Alyx 智能体：规划、记忆与评测

我是 Fuad Ali，Arize 的 AI 产品经理。今天我想分享近两年来交付产品内生产智能体的经验，希望为构建自己智能体的团队提供有用的设计问题。

我们的工作有一点递归：编程智能体帮助构建产品；Signal 读取智能体追踪；我今天讨论的 Alyx 是产品内智能体；我们还用 Alyx 调试 Alyx。我们可以用同样的工具评测自己的智能体，研究可能适用于其他系统的设计模式。

Alyx 位于 Arize X 内，可以读取追踪、将发现转化为评测和数据集、运行实验、规划多步骤工作，并根据追踪生成合成数据。一位资深工程师将 2023 年末使用 3.5 时代模型的首个原型描述为约一半内容是幻觉。这是对早期原型的内部描述，并非不同产品之间的实测比较。

产品从较简单的提示词和工具界面发展为更深入的工作流，能够规划并解释自己在做什么。例如，用户让 Alyx 优化它自己的系统提示词，它会规划如何检查应用中的资源。

原型始于 2023 年末。团队将数学工作从模型移到 harness 代码中，随后推出以技能路由为核心的 copilot。2025 年 8 月的重写加入迭代工具调用和待办工具；之后在 2026 年 2 月重新发布，并于 6 月进行整合。长期记忆是后来加入的。

这些变化背后的前沿模型不是我们训练的。模型按照自己的节奏改进，而我们的重建主要发生在 harness 代码中。我们没有使用智能体框架：循环、计划、停止规则和记忆都由我们自己管理。这让我们能控制系统，也能从中学习。

第一个设计问题是由谁管理计划。可以想象给孩子一张家务清单：你可以让他们维护清单，也可以自己保管，并给出下一项任务。两种方式对执行工作的人提出了不同要求。

最初我们给模型一份待办清单。它花费过多调用去勾选事项，而不是做有用的工作；多次工具调用后还可能失去焦点。随后，我们逐步将计划移入 harness，从增加进行中状态开始。

接下来，harness 在每次调用模型时把计划渲染成一条消息，让规则与相关数据放在一起。后来我们移除了进行中标记：如果未完成事项有顺序，下一个未完成事项本身就能指出下一项任务。现在我们正在测试不使用单独待办工具的版本，把状态和完成检查保留在 harness 中。

下一个问题是什么结束一个回合。我们最初的规则把没有工具调用的文本视为完成。但当模型在一个回合宣布步骤、下一个回合才调用工具时，这条规则就失效了。模型变化会暴露这类假设，而客户也可以选择自己的服务商。

当前设计使用明确的完成调用。如果计划事项仍未完成，harness 最多可以让模型返回继续执行三次。幻灯片还介绍了对纯文本工具调用的提示、停止没有进展的重复调用，以及在迭代上限前警告并随后强制结束。

记忆带来几个相关问题。一个大型工具结果就像一本占据桌面的书；多本这样的书会完全填满桌面。我们不把整个结果留在上下文中，而是保留引用和概要描述，让智能体按需取回内容。

追踪分析可能返回一个很大的 JSON 对象，占满上下文窗口，挤掉有用的工作空间。Alyx 会截断即时结果，并可编写代码或使用 jq 等工具检查完整材料。这利用了模型处理代码的能力，而不是把所有内容都塞进提示词。

智能体自身的历史也会增长。Harness 要求模型写入检查点，然后在固定历史 token 预算内丢弃被检查点替代的材料。跨会话时，后台任务为每位用户编辑一个小文件。

对于长期记忆，我们尝试了向量检索、情节和语义存储，以及时序知识图谱。最终我们选择每个用户在每个空间使用一个 Markdown 文件，最多 8000 字符，每次请求时完整加载。后台任务在一个回合结束后进行小幅编辑，写入时经过安全检查。

小文件易于加载和审计，也不会压垮上下文。人工标注者可以检查保存了什么，并调整后台任务的指令。Ali 将其视为 Arize 避免不必要工程复杂度的一条经验，而非文件在所有场景都胜过其他记忆系统的证明。

我们从一个追踪智能体开始，后来发展到十个针对不同页面的专业智能体。例如，数据集页面有自己的智能体，用于生成合成数据和检查数据集。之后，我们将主要流程合并进一个智能体，它按需加载技能指令和工具，并自行选择使用哪些工具。

幻灯片显示，限定范围的子智能体仍被保留，用于边界明确的工作，而不是规划。它还报告了重新设计后提示词 token 数量和提示词加工具定义大小的下降。这些数字来自该系统的架构，并不预示所有合并都会有相同结果。

最新模型不一定是最佳默认选择。一般前沿排名与特定产品中真正有效的选择不同。我们通常选择速度快、质量足够的模型，然后花时间改进 harness；团队也在探索针对任务的模型路由和小型后训练模型。

有些任务根本不需要智能体循环。Ali 以 AI 辅助生成筛选条件为例，说明一次小模型调用可能就足够。在这种情况下增加完整循环，可能又是一种过度设计。

追踪生产会话可以帮助我们将真实用户问题和失败转化为回归数据集。随着新案例出现，这些测试样本会不断变化。会话数据集也可以保存完整会话并重放特定回合，实验则有助于比较 harness 的改动。

智能体的 bug 不一定表现为明确错误。一次运行可能报告成功，却在一个回合中做了 43 次相同的工具调用。延迟也需要结合场景判断：227 秒可能显然过长，但可接受的响应时间取决于应用。Signal 帮助团队从追踪中发现模式。

一次修复可能引入下一个 bug，因此回归数据集很重要。评测用的裁判需要人工基准：团队让自动判断与工程师的评估对齐，并使用人工创建的黄金标签和数据集。自动化减少了一部分追踪阅读工作，但没有消除专家判断。

速度与质量之间的取舍仍由人作决定。指标可以显示切换模型带来的延迟和质量变化，但不能替产品的每个部分决定哪种取舍合适。

六项实践历经重建仍然保留：将追踪写入 Arize 自己的产品；用代码做数学聚合、由模型解释；在持续集成中使用黄金数据集；提供有明确下一步的可恢复错误；流式输出和持久化；以及技能。技能的含义从路由分支变成智能体可以自行加载的指令和工具。

Ali 最后提出希望构建者思考的问题：谁管理计划、什么结束回合、如何处理过大的工具输出和长期记忆、应该使用一个还是多个智能体、哪个模型速度和能力足够，以及谁检查智能体的修复。他的团队仍在用 Alyx 构建 Alyx。