为 Agent 指定角色和职责

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你要审查一个 API 重试循环，已有代码和写入接口的约定。希望 Agent 检查失败路径，而不是为了符合“专家”的身份强行找问题。

教学材料 retry.ts：第 1 行 for (let attempt = 0; attempt < 3; attempt++)；第 2 行 try { return await createOrder(); }；第 3 行 catch (error) { if (attempt === 2) throw error; }。本题已知：createOrder 没有幂等键，服务端可能已创建订单但客户端收到超时。两侧都使用这些材料。

具体做法

1. 把角色写成具体职责，例如“失败路径评审者”，同时限定要审查的文件。
2. 给出该职责对应的问题：会不会重复写入、最终失败是否被报告、重试次数是否有上限。
3. 要求每个结论引用材料位置，并说明触发输入和可观察后果。材料不足时列出缺口；没有发现也允许报告零项。

角色只是组织注意力的方式，实际判断仍来自代码、接口约定和检查记录。

反例

根据上面的 retry.ts 和接口约定审查重试循环。你是顶尖专家，必须找出一个严重问题，证明这个实现不可靠。

改进写法

作为失败路径评审者，审查上面的 retry.ts 与已给定的接口约定。检查重复写入、重试上限和最终错误。只报告材料支持的问题，每项写明代码位置、触发条件、执行路径和可观察后果；资料不足时说明缺什么。没有可支持的问题时报告零项，不为了角色身份编造发现。

为什么这样改

反例同时给出夸大的身份和必须有问题的结论，会把审查变成寻找符合预设的证据。改进版本把身份落实为检查问题，并要求从材料推导结论。这样读者可以核对发现，而不必相信“专家”称号。

如何验证

检查报告是否把重复订单问题连到第 2、3 行和“服务端已写入但客户端超时”的约定。示意结果：首次创建成功但响应超时 → catch 后再次调用 createOrder → 可能创建第二个订单；重试最多 3 次。

这个示意说明怎样组织证据，不是实际运行结果。如果接口约定改成所有调用共享幂等键，应重新分析，不能继续照抄同一结论。缺少位置或触发条件的发现不满足要求。

适用边界

角色说明不能补足缺失的代码、领域知识或测试。某些检查需要真实服务契约或故障注入；静态示意不能证明生产环境已经产生重复订单。本方法的原文仍未确认，保留来源未确认标签。