Agents：复习题

workflow 用事先写好的代码路径串起模型和工具；agent 让模型自己决定流程和工具。步骤能事先列出来、没有验证信号、或者做错一步代价很高（发送、付款、删除）时，都不该直接用 agent：先写成 workflow，或者在关键步骤加人工确认。

模型（决定下一步）、工具（对外界动手）、循环（结果回到模型）、停止条件（做完或预算用完），再加上存放中间状态的上下文或记忆。ReAct 的「想一步、做一步」是这个循环最常见的形式。

因为验证信号最强：代码能跑，测试能过，每一步都有客观反馈，agent 可以在沙箱里多试，通过后仍要人看 diff。相比之下，客服、个人助理这类场景很难自动判断对错，更依赖规则、权限和人工。即使在写代码的场景，测试通过也不等于改对了。

不能只看单次成功率，要看同一个任务独立重复多次是否全都做对，比如 τ-bench 的 pass^k（k 次全部成功的概率）。还要检查是否遵守政策、工具调用是否正确、复杂情况有没有转人工，并看完整的运行轨迹而不只是最终回答。

先看能力：在自己的评估集上开源模型不达标，就用 frontier。数据有严格边界时，先核对 API 的地域、保留策略、合同和私有连接能否满足，满足不了再考虑自部署。流量大且稳定、已有闲置算力或需要深度定制时，自部署可能更划算、更可控，但要把闲置容量、运维和维护时间一起算；没有通用的流量界线。量小或不确定时，先用 API 把质量和成本测出来。实际上常常混用：路由、级联、蒸馏（distillation）、兜底。

若各步独立、任何一步出错都无法恢复，错误会沿步骤累积：每步 95% 做对，20 步全对只有约 36%；每步 99% 做对，约 82%。真实任务里错误会相关，也可能重试或恢复，所以这道乘法只是提醒：要做端到端评估，并记录失败发生在哪一步。

模型优化的是你实际给的奖励（reward），而不是你心里想要的目标，两者一有偏差，它就会钻空子。OpenAI 的划船游戏里，奖励是沿途的道具，agent 就原地转圈刷道具，比跑完比赛得分还高。LLM 里也一样：拿「测试通过」当奖励，agent 可能去改测试；RLHF 里奖励模型偏爱长回答或附和用户，策略模型就会学着写得更长、更会讨好。

级联让小模型先答，看了答案再决定要不要升级，所以判断更准，但被升级的请求要付两次钱，还要串着等两个模型。路由在看到答案之前就决定派给谁，每条请求只调用一次模型（另加路由开销）、延迟更低，但可能派错；派错后要靠输出检查或兜底补救，这部分成本和延迟也要算进去。两种方案都只有在难度判断足够准的时候才划算。