很多 agent 评估仍然太像一次性问答评估：看最终答案是否正确，看任务是否完成，看 benchmark 分数高不高。

这对 agent workflow 不够。

agent 不只是生成答案。它会计划、调用工具、读取来源、修改状态、遇到失败、重试、请求人工、输出证据，最后把结果交给某个流程。只看最后结果，会漏掉最重要的运行质量。

评估对象应该是 trajectory

一个 agent workflow 至少有三层结果。

第一层是 outcome：最后有没有产出可用结果。

第二层是 artifact：产物是否符合结构、规范、证据和交付要求。

第三层是 trajectory：agent 是如何走到这里的。

trajectory 包括它读了哪些来源、调用了哪些工具、在哪些地方推断、哪里遇到不确定性、有没有请求人工、失败后如何恢复、是否遵守权限边界、是否把证据带到交付物里。

如果只看 outcome，agent 可能靠运气完成。如果看 artifact，可以排除一部分问题。如果看 trajectory，才能判断这套 workflow 是否可重复、可审计、可改进。

成本要按 successful goal 计算

agent 成本不能只看模型调用量、单次调用价格或单步延迟。

一个 workflow 可能单次调用便宜，但因为反复走错、重试、读错上下文、生成不可用产物，完成一个目标的总成本很高。另一个 workflow 单次调用更贵，但一次完成、证据完整、人工审查成本低，反而更便宜。

所以更合理的指标是 goal-level cost：

total model cost + tool cost + runtime cost + human review cost + failure/rework cost

除以成功完成并被验收的目标数量。

这对 autorun、domain-batch、publication pipeline、社交运营和专业工具 agent 都很重要。真正要优化的不是“每次便宜”，而是“每个可信完成目标便宜”。

恢复不能只做 retry

很多自动化系统把失败恢复理解为 retry 或 rollback。对 tool agent 来说，这还不够。

agent 失败后，系统需要判断恢复后的状态是否语义有效。

例如，代码回滚后，文档、测试数据和生成文件是否一致？
发布同步失败后，中心 publication record 和 site _generated 是否仍然匹配？
建模 bridge 执行一半失败后，结构化设计状态和 SketchUp 场景是否还对应？
多 issue autorun 合并后，domain invariant 是否仍然成立？

这就是 semantic recoverability：不是机械地回到某个状态，而是确认下游依赖和业务语义仍然成立。

Calibration 比自信更重要

agent 评估还要看不确定性处理。

一个好 agent 不应该总是自信推进。它应该能在证据不足时标记不确定，在权限不明时 halt，在来源冲突时 ask，在风险过高时 block，在自己没有验证能力时说明边界。

这类能力很难通过最终答案分数衡量，但它决定 agent 能否进入真实流程。

尤其在高信任 workflow 中，错误地自信比明确说“不知道”更危险。

一个最小评估面板

项目可以先从一个简单面板开始：

completion：目标是否完成并被验收。
evidence：关键结论和副作用动作是否有证据。
authority：高风险动作是否经过正确门禁。
trajectory：工具调用、状态变化和人工介入是否可追溯。
cost：完成一个目标的总成本和人工审查成本。
recovery：失败后是否能恢复到语义有效状态。
calibration：agent 是否正确处理不确定性和拒绝边界。
learning：失败经验是否进入规则、测试、skill 或 playbook。

这比单一成功率更接近真实工程。

核心判断

agent workflow 的质量不等于最终答案质量。

真正值得评估的是：它如何行动，花了多少真实成本，证据是否可审查，失败后能否恢复，以及它是否知道什么时候不该继续。