现在做 Agent，最容易被忽略的不是提示词，而是可回放的 traces 和最小 eval 集

我现在越来越不想讨论“提示词怎么写得更聪明”了。不是 prompt 不重要，而是很多 agent 项目一旦进入第二周，真正拖垮迭代速度的通常不是提示词，而是你根本不知道它上一次为什么成功、这一次为什么失败、换个模型以后到底退化了多少。

说得直接一点：没有 traces 和最小 eval 集，很多所谓的 agent 调优其实只是情绪化开发。今天觉得它变好了，明天觉得它又抽风了，后天再换个提示词碰运气。你做的不是工程迭代，更像在和一个概率系统赌手感。

为什么这件事现在比提示词更重要

今年公开资料里，这条线已经说得很清楚了。Anthropic 在 1 月专门写了 agent evals，强调没有 eval 很容易陷入生产里被动修问题的循环；OpenAI 在 1 月写了如何系统化测试 Agent Skills，5 月又给出用 traces、evals 和 Codex 做 improvement loop 的示例。这几篇放在一起，其实在讲同一件事：agent 一旦进入真实工作流，调优对象就不再只是 prompt，而是整条执行链。 citeturn219854search0turn219854search1turn219854search9

而整条执行链里最先该落下来的，不是大而全的平台，而是两样最朴素的东西：可回放 traces，和一组能反复重跑的最小任务样本。

为什么很多团队会一直卡在“感觉它变好了”

因为 agent 的失败通常不是单点失败。它不像接口 500 那样直白，而更像下面这种链式偏差：

第一步理解任务时就漏掉了一个约束；
第二步选了一个勉强可用但不稳定的工具；
第三步工具输出里有噪音，模型没处理干净；
第四步把前面的错误当成事实继续往下做；
最后结果不是完全错，而是“看起来差不多”。

这类问题如果没有 trace，你几乎无法复盘。因为你最后看到的只是终态，而不是中间每一步到底做了什么判断、调用了什么工具、返回了什么内容、在哪一步开始偏。于是团队只能继续改 prompt，希望下一次它运气更好一点。

我说的 trace，不是日志越多越好

很多人一听 trace，就开始想全量埋点。但 agent 系统里真正有用的 trace，不是把所有 token 都存下来，而是把足够还原决策链的信息留下来。至少包括：

任务输入和约束；
模型选择和参数；
每一步工具调用的入参、出参与耗时；
关键中间摘要；
最终产出和人工评分；
失败分类标签。

{
  "task_id": "ticket-184",
  "goal": "修复 billing webhook 重试逻辑",
  "model": "reasoning-model-x",
  "steps": [
    {"type": "plan", "summary": "定位 webhook handler 和 retry policy"},
    {"type": "tool", "name": "read_file", "path": "services/billing/webhook.ts"},
    {"type": "tool", "name": "run_test", "cmd": "pnpm test billing-webhook", "exit_code": 1},
    {"type": "decision", "summary": "怀疑 retry counter 在 429 分支没有落库"}
  ],
  "result": "partial_success",
  "human_label": "bug_fixed_but_missing_regression_test"
}

这类结构的价值在于，你下次碰到类似失败时，不用靠记忆复盘，而能直接比较：是模型变了、工具变了、上下文变了，还是任务边界本来就没写清。

最小 eval 集也别想得太大

很多团队迟迟不做 eval，是因为一想到 eval 就以为要建一套很重的平台。其实对大多数个人开发者和小团队来说，先做一个 20 到 50 条的最小 eval 集就已经非常够用了。关键不是规模，而是覆盖真实失败模式。

我会优先收这几类样本：

曾经在线上或测试里真正失败过的任务；
看起来简单，但经常边界不清的任务；
需要工具调用两步以上才能完成的任务；
涉及成本差异明显的任务，比如要不要上高推理模型；
最影响业务信任的错误类型。

eval_cases:
  - id: billing_retry_429
    pass_if:
      - retry_counter_persisted
      - regression_test_added
  - id: support_triage_refund
    pass_if:
      - policy_cited_correctly
      - escalation_flag_set
  - id: code_review_public_api
    fail_if:
      - public_api_changed_without_note

你会发现，一旦这批样本建立起来，很多关于“要不要换模型”“要不要改提示词”“要不要新增 skill”的讨论都会从拍脑袋，变成有证据的权衡。

个人开发者为什么更应该早点做这件事

因为个人开发者最容易被“我自己大概知道它哪里不对”这种感觉骗到。团队里至少还有别的同事会质疑你，个人项目里没有第二双眼睛，trace 和 eval 就更像是你给未来的自己留的防错装置。

而且个人开发者通常更频繁地改 prompt、换模型、调工具、动上下文。变化一多，如果没有最小 eval 集，你几乎不可能知道这次提升是真的，还是只对你刚测的那三个样本成立。

我会怎么在半天内把这件事做起来

不用等平台完善。半天时间，先做一个够用版本：

挑最近 20 条真实任务或失败案例；
给每条任务写一个通过条件或失败条件；
把 agent 的关键步骤落成结构化 trace；
每次改模型、提示词、工具后，固定重跑一次。

make eval
python run_eval.py --suite minimal-agent-suite.yaml --model current
python diff_eval.py results/baseline.json results/current.json

这一套非常土，但比“感觉最近变稳了”强太多。真正的工程进步，很多时候不是因为你引入了更高级的框架，而是因为你终于能稳定地比较变化前后。

我的判断

现在做 Agent，最容易被忽略的不是提示词，而是可回放 traces 和最小 eval 集。没有它们，你很难持续改进，只能不断在随机波动里自我安慰。

如果我是个人开发者，我现在不会先花时间挑更复杂的 agent 框架，而会先把 trace 结构和 20 条最小 eval 样本建出来。因为这两样东西一旦有了，你后面不管是换模型、加技能、接工具还是调工作流，才第一次真正有了工程上的地基。