总项目：一个能被追问、能被复测的AgentLab

目标

完成可查询订单、检索政策、提出退款方案、等待人工批准、可靠执行、记录事件和评测结果的Agent服务；再用同一套运行边界支持一组受限Coding任务。不是要求你造一个新的通用框架，而是证明你能把模型行为与业务、后端和执行环境正确连接。

可以使用成熟框架，但必须解释它替你保证什么，以及仍由你负责什么。主项目不接真实资金系统；所有订单和支付均为本包的虚构数据。

保留固定Workflow对照；实现最小Tool Loop及预算；工具请求不携带可篡改身份；检索过滤租户与版本；退款提案和审批绑定；账本与幂等结果一致；支持至少两个明确的故障恢复案例；具备结构化Trace与独立业务验收器。

完成共同基线后选择一个方向加深，不必把所有框架、云产品和模型部署都做一遍。总评先看硬约束，再看方向深度。

重点是把含糊需求转化为正确任务，提供证据、澄清和安全人机协作。实现订单歧义处理、政策检索、答案引用和至少一种上下文裁剪策略。比较固定Workflow、单Agent和你的改进方案；公开任务集上的真实模型实验需明确任务数量、试次、费用和选择偏差。

演示至少包括：直接可答、需要澄清、政策冲突、不能执行、待人工确认五类任务。不能只展示退款成功路径。用户表达“不要退款，只查询”必须尊重，不因业务可退就主动执行。

方向加分依据：bad-case分析深度、可靠证据链、可解释交互、检索与任务成功的因果分离。不是漂亮聊天UI或增加更多Agent名字。

重点是任务服务、请求幂等、Outbox、worker归属、审批恢复、事件流和取消。实现API契约，写并发创建、重复审批、重复消息、lease过期、请求响应丢失的测试。明确队列仅承载通知还是承载权威状态，解释回压和租户配额。

至少展示一个完整崩溃窗口：提交退款后进程退出，恢复读同一operation_id，账本仍一笔。展示一次SSE断线重连，重复帧不重复应用。等待审批不能占用活跃执行worker。

方向加分依据：状态转移清晰、事务边界正确、测试可复现、错误语义诚实。不要用“Redis锁已加”代替旧worker回写和外部副作用分析。

重点是执行模型、任务状态与代码隔离边界、取消、资源记账及端到端成本。完成三个原创Coding任务；若实现真实沙箱，给出威胁模型、运行profile、资源限制、进程树清理、可信测试隔离和实测记录。

比较至少一种准备复用或调度策略，报告应用质量不变的证据与隔离反例。将排队、准备、模型、工具、持久化、重试和清理成本分开。没有GPU也可以完成本方向；LLM serving是扩展而非门槛。

方向加分依据：测量可信、边界准确、故障语义完整。不要把一个快的kernel当成端到端改进，也不要把共享只读镜像扩展成共享任务凭据。

先过硬门槛：不得泄露其他租户数据；不得未批准退款；相同业务意图重复尝试不得重复记账；不得伪造性能/任务成功结果；未测试功能必须标明。存在硬门槛失败时先修复，不以UI分数或较高平均成功率抵消。

通过门槛后，建议按正确性与安全25、可靠性20、评测与实验20、方向深度20、文档与答辩15评审。不同方向可调整深度项，但共同基础不能跳过。没有真实模型预算时可以提交“确定性内核与评测设计版”，清楚标注其未验证模型行为，不能自称完成完整模型任务评测。

首先画一条任务从认证到最终账本的路径，指出每个状态的事实源。接着回答：模型错误建议退款由谁挡住？Worker重启时从哪里恢复？超时为什么不是失败？审批内容变化为什么要重批？日志什么时候可以丢、什么时候不行？你的优化影响了哪段关键路径？如果真实模型更便宜但多错两次，总成本会怎样？

最后要求现场改变一个假设：同一订单来自两个租户、工具成功但响应丢失、原有lease过期、可信测试被修改、检索旧政策排名第一。合格回答要修改机制或指出原机制已覆盖，并给出能证伪自己的测试。

“针对某任务构建了某系统；发现具体失败模式；通过某机制满足某不变量；在明确规模和环境下测得某结果；仍有哪些限制。”所有数字必须来自你自己的运行记录。课程样例数值不能写成个人项目实测，课程中的代码不能不加说明地包装为独立原创研究。