AI Agent 表现不稳定？HALO 用生产轨迹数据自动诊断并优化 Agent 行为
你有没有遇到过这种情况：AI Agent 在开发环境跑得好好的，一上线就开始”抽风”——同一个任务，今天全部通过，明天半数失败；你改了一下 system prompt 修了一个 bug，结果又冒出来两个新问题。
这不是你的 Agent 写得不好，而是生产环境的复杂度和非确定性远超开发测试所能覆盖的范围。LLM 调用的非确定性、外部 API 的延迟波动、工具调用的竞态条件……这些因素在低流量下几乎不会触发，但一旦流量上来，各种边角失败就会频繁出现。更棘手的是，这些失败往往难以复现 —— 今天出错的 trace，明天用同样的输入跑一次可能就通过了。
为什么 Agent 生产调试是个真问题
手工排查 Agent 生产问题有多耗时？以当前最常用的调试方式为例：
- 翻日志：从 OpenTelemetry 导出的 JSONL trace 文件，一条完整的 Agent 对话可能有几百个 event，人工肉眼翻一遍至少 10 分钟
- 脑内比对：把成功和失败的两条 trace 摆在面前，逐行寻找差异 —— 同样的 tool call，为什么这次参数对了下次错了？
- 试错修复：根据推测改 prompt 或工具实现，部署后等新的 trace 数据来验证 —— 一个轮次至少 30 分钟
这还不算最坏的情况：如果你的 Agent 有三层 subagent 递归（HALO 的默认 --max-depth=2），一条 trace 可能包含上千个 event。人工分析这类 trace 基本不可行，大部分团队的做法是”先重启，不行再说”。
HALO 是什么
HALO 是一个用 RLM（Recursive Language Model） 来分析和优化 Agent harness 的开源工具。简单说，它把生产环境中采集的 Agent 执行 trace 喂给一个专门的分析模型，自动识别常见失败模式、性能瓶颈，然后生成可执行修复建议。
项目由 context-labs 开发，MIT 许可，同时提供 桌面应用 和 Python CLI 两种使用方式。
核心工作流
采集 trace → RLM 引擎分析 → 输出报告 → 编码 Agent 执行修复 → 部署 → 再次采集
这个循环就是 HALO 的核心理念：用 Agent 分析 Agent，形成持续自我改进的闭环。
安装
pip install halo-engine halo --help
HALO 依赖 OpenAI 兼容 API，默认使用 OPENAI_API_KEY 环境变量，也可以通过 --base-url 切换到 OpenRouter、Together 等提供商：
export OPENAI_API_KEY=sk-xxx export OPENAI_BASE_URL=https://openrouter.ai/api/v1
快速上手：让 HALO 分析你的第一条 trace
要使用 HALO，你只需要三样东西：
- 一份 JSONL 格式的 Agent 执行 trace 文件
- 一个 OpenAI 兼容的 API key
- 一句话描述你想让 HALO 关注什么
halo your_agent_traces.jsonl \ -p "Diagnose errors you find and suggest fixes"
就这么简单。HALO 会自动分解 trace，识别出现频率最高的失败模式，分析它们的根因，然后输出一份结构化报告。
Trace 格式要求
HALO 希望 trace 文件是 JSONL 格式，每条记录代表一个 OpenTelemetry span。你现有的 observability 工具（Langfuse、Arize）导出的 JSONL 文件可以直接喂给 HALO，不需要额外转换。
如果还没有 trace 数据，halo-engine Python 包提供了 tracing 集成指南：
from openai import OpenAI
CLI 参数详解
HALO 提供了丰富的 CLI 选项来控制分析行为：
| 参数 | 默认值 | 说明 |
|---|---|---|
TRACE_PATH | 必填 | JSONL trace 文件路径 |
-p, --prompt | 必填 | 给根 Agent 的分析指令 |
-m, --model | gpt-5.4-mini | 分析用模型 |
--synthesis-model | 同 --model | trace 摘要用模型（推荐用 gpt-4.1-nano 省钱） |
--compaction-model | 同 --model | 上下文压缩用模型（最大 token 消耗者，推荐小模型） |
--max-depth | 2 | subagent 递归深度 |
--max-turns | 20 | 每个 Agent 的最大轮次 |
--max-parallel | 10 | 最大并发 subagent 数 |
一个实际的使用示例：
halo production_traces_day1.jsonl \ -p "Find all tool call failures and classify them by root cause" \ --base-url https://openrouter.ai/api/v1 \ --synthesis-model gpt-4.1-nano \ --compaction-model gpt-4.1-nano \ -H "HTTP-Referer: https://your-site.com"
这里的关键设计是分离分析模型：根模型（--model）做推理密集型分析，摘要和压缩模型用更便宜的小模型，节省成本。
真实效果：AppWorld 基准测试
HALO 团队在 AppWorld 基准上做了系统测试。AppWorld 是一组多服务 Agent 任务（操作 Spotify、Venmo、文件系统等），能较好地模拟生产环境的多样性。
测试结果（使用 dev split 迭代优化，test_normal 验证泛化）：
- Gemini 3 Flash: dev 提升 15.8 个百分点（36.8% → 52.6%），test 提升 10.7 个百分点（37.5% → 48.2%）
- Sonnet 4.6: dev 提升 15.8 个百分点（73.7% → 89.5%），test 提升 10.7 个百分点（62.5% → 73.2%）
关键发现：HALO 引擎识别出的失败模式主要集中在这几类 —— 幻觉 tool call、冗余工具参数、拒绝循环（refusal loop）和语义正确性问题。每个问题都能直接映射到 harness prompt 的特定段落的编辑。
值得注意的是，Gemini 3 Flash 的 test 提升（10.7 个百分点）和 dev 提升（15.8 个百分点）之间的差距不大 —— 这说明 HALO 没有过拟合到特定的 dev trace 集，而是真正发现了 harness 层面的系统性问题。Sonnet 4.6 的结果也验证了这一趋势。两个模型、两套数据集之间的一致性，是 HALO 方法论可信度的有力证据。
建立持续的 trace 分析循环
HALO 真正的价值不在于一次性的 trace 分析，而在于持续运行的优化循环。推荐的落地方式：
- 接入 tracing：在 Agent harness 中内置 OpenTelemetry 集成（HALO 文档提供了 OpenAI Agents SDK、LangChain 等主流框架的集成指南）
- 定时分析：每天或每个部署周期运行一次 HALO，分析最新 trace 数据
- 自动修复：将 HALO 报告直接喂给 Claude Code 或 Cursor，让 AI 编码 Agent 实施修复
- 验证回滚：修复生效后，用下一轮的 trace 数据验证改进是否持续
如果不想本地跑，inference.net 提供了托管版 HALO，可以直接接入 trace 源。
总结
HALO 解决了一个 AI Agent 生产部署中的核心痛点：当 Agent 的失败模式难以靠人工排查时，用专门的分析引擎来自动完成这件事。它不是在模型层做改进，而是在 harness 层持续发现和修复系统性问题。
如果你有以下需求之一，HALO 值得一试：
- 维护高流量的生产 Agent 服务，手动排查 trace 已经力不从心
- 想用数据驱动的方式持续改进 Agent 行为
- 需要在多个 Agent 框架之间复用 trace 分析能力
项目地址：github.com/context-labs/halo
CLI 安装：pip install halo-engine