L01 参考解：从失败演示到可检查的Agent Loop

这是可讨论的参考设计，不是唯一架构。先完成实验题面，再对照本解。

关键推导

参考实现把模型、网关和执行器拆成三个对象。Runner.run只负责循环与关联；Gateway拥有身份和工具白名单；Store拥有业务事实。这个边界让你可以替换模型而不改授权逻辑。

期望正常示例：model_calls=3，tool_calls=2，status=MODEL_FINISHED，退款ledger_count仍为0。最终文本应表达“物流确认丢失，可创建提案，尚未退款”。这里不是让执行器自动判断自然语言真伪；真实模型文本一致性由独立验收器/人工审查处理。

将两次查询合并成一轮并行请求是允许的，但必须证明无依赖、保持call_id对应，并重新计数。不能为了漂亮的轮数把有依赖的工具擅自并行。

参考算法与实现位置

while model_calls < budget.model_calls:
    reply = model.reply(messages)
    model_calls += 1
    if reply.kind in {"refusal", "incomplete"}: return stop(reply.kind)
    if reply.kind == "final": return model_finished(reply.text)
    validate_call_ids(reply.calls)
    for call in reply.calls:
        reserve_tool_budget_or_stop()
        result = gateway.dispatch(call.name, call.arguments)
        append_result(call.id, result)
return stop("BUDGET_EXCEEDED")

上面是算法草图，不是Provider SDK的可直接调用接口。可运行版本见reference/agentlab/runner.py。

应当得到的可检查结果

输入	必须观察到
查订单→查物流→最终回答	正确call_id，2次工具调用，账本不变化
final文本“已退款”，没有退款工具	MODEL_FINISHED，但business_success_verified=false
同一call_id出现两次	PROTOCOL_ERROR，第二次不派发
工具预算为0	首次工具请求即停止，不访问业务服务
refusal或incomplete	各自终止状态，不能混同成功
模型脚本耗尽	显式错误，不编造额外输出

怎样判断替代实现是否等价

替代实现必须保留题面中的身份来源、状态归属和失败语义。数据库/框架可以更换，但应把相同故障窗口重新跑一遍。只在正常路径输出一致，不足以证明恢复与授权等价。异步或并发实现还必须解释取消传播、竞争窗口和资源回收。

常见错误与修正

第一类错误是把协议或框架提供的局部保证放大成业务保证：格式正确不等于授权，执行结束不等于业务成功，持久化不等于外部副作用恰好一次。修正方式是找到事实源并把不变量放在拥有该事实的层。

第二类错误是用演示数据替代证据。已有fixture可以检查确定性公式与状态机，但真实模型、网络或容器的结论需要实际运行。报告同时写出“已验证”“仅模拟”“未验证”，比宣称全部完成更有工程价值。

实现范围与限制

参考循环是同步、离线、非持久化的。它没有实现真实流式API、硬墙钟超时、取消或任意代码工具；这些限制不是测试通过就消失。

开放题评分要点

协议与关联30；预算/终止25；独立验收20；测试15；设计解释10。正确的反例、失败分析和替代方案论证应获得分数；框架堆叠、只报最终成功截图、删除失败成本不应获得同等评价。