2027秋招项目别再只做聊天机器人：把一次“异常工具调用”做成可回放的测试系统

校招简历里写“用大模型做了智能客服”，面试官往往只能继续问：用了哪个API？Prompt怎么写？

如果你把项目改成“为客服Agent做工具调用异常检测与回归”，讨论会立刻进入测试开发：Trace怎么采集、什么算越界、误报怎么评估、版本升级如何回放。

这类项目不需要昂贵平台，两周就能做出一个可演示版本。

第一周：先做一条看得见的Trace

设计三个工具：查订单、查用户、发起退款。每次调用记录session_id、tool、arguments、timestamp、result和actor。准备三条正常用例和三条异常用例，例如普通用户查询他人订单、退款前跳过订单校验、同一会话连续读取大量用户。

然后写确定性规则：跨用户访问必须失败；退款必须先查订单；退款金额不能超过实付金额。

def assert_refund_trace(trace):
    tools = [x["tool"] for x in trace]
    assert "get_order" in tools
    assert tools.index("get_order") < tools.index("refund")
    refund = next(x for x in trace if x["tool"] == "refund")
    assert refund["amount"] <= refund["paid_amount"]

第二周：把一次失败变成回归资产

把异常Trace保存为JSON，加入pytest参数化用例。再做两个版本：旧Prompt允许直接退款，新Prompt要求先确认订单。跑同一批数据，输出成功率、越界调用数、平均工具次数和P95延迟。

为了让项目不只是“写几条规则”，再加一个简单的异常分层：调用频率异常由统计规则发现；权限和金额由确定性断言判断；跨多轮意图可以交给一个模型Judge解释。最后比较三层各自的误报和漏报，不要把它们混成一个总准确率。

还可以模拟检测延迟：异常在第3步发生，检测结果在第5步返回，验证第6步是否被阻断。这个细节能体现你理解旁路监控和同步门禁的区别。

项目页面不必华丽，一张表就够：哪条用例、期望行为、实际轨迹、失败步骤、版本差异。

仓库最好包含traces/样本、tests/断言、reports/结果和一份README。README写清楚教学数据、没有连接真实退款系统，以及如何一条命令重放，避免面试官拉下来却跑不起来。

简历应该怎么写

不要写“实现智能客服，准确率95%”。如果没有严谨标注，这个数字很难解释。

可以写：

“基于OpenTelemetry风格事件设计客服Agent工具调用Trace；构建24条正常/越界回放用例，用pytest验证权限、调用顺序和退款金额不变量；在Prompt升级前后执行回归，输出越界率、工具次数和延迟差异。”

面试时准备回答四个追问：为什么最终答案正确仍可能失败？规则和模型Judge怎么分工？Trace如何脱敏？新事故怎样进入回归集？

这比再做一个会聊天的网页更有辨识度，因为它证明你不仅会调用AI，还知道怎样让AI在真实业务边界内工作。