推理服务代码评审的七项检查推理服务的代码评审不能只验证“给一段输入能否返回答案”。服务通常同时处理用户数据、模型配置、流式连接、检索内容和外部工具任何一个边界含糊都可能变成成本、权限或稳定性问题。下面七项检查适合作为评审起点它们不是固定模板应根据业务风险增减。1. 输入、身份与数据范围检查请求的身份如何认证租户和资源权限在哪里再次校验输入长度、文件类型和上下文引用是否受限。不要因为模型需要资料就让调用方传来任意文档内容或任意资源 ID。日志、缓存和调试信息同样要遵守数据范围不能绕过正常授权。2. 模型、提示词与配置版本每次请求应能关联模型、系统指令、工具 schema 和关键开关的版本。这样输出变化时团队才知道该比较什么。评审还要确认配置变更是否可回滚是否会在同一任务中途切换版本以及敏感提示词或凭证是否会被写入客户端日志。3. 上下文来源和提示注入边界检索结果、网页、附件和工具返回内容都应被视为不可信数据。它们可以给模型参考却不应改变权限、系统规则或允许调用的工具集合。检查上下文是否标明来源和时间是否限制大小以及长任务中旧状态会不会覆盖新用户意图。用户请求 系统策略 已授权资料引用 ↓ 模型提出下一步 ↓ 调度层校验后才调用工具把“模型提出”与“系统执行”分开是防止不可信文本越权的一条基本边界。4. 工具调用的契约与副作用工具名应来自允许列表参数必须经 schema 和业务校验服务端还要重新做授权。读取工具与写入工具应有不同的风险控制后者需要幂等键、确认步骤或审批并能查询操作是否已经发生。仅在提示词中写“不要调用危险工具”不构成控制措施。5. 预算、超时和重试检查单任务的截止时间、模型与工具调用次数、token 或费用预算、并发限制和队列容量。重试要按错误类别处理并有次数和总时间上限。超时不等于下游未执行特别是写操作因此不能把超时后的“再试一次”当作默认修复方式。6. 流式输出与取消SSE 或 WebSocket 连接断开时服务应释放不再需要的资源客户端也应知道任务是被取消、仍在后台执行还是可重连查看。事件需要稳定的任务标识和序号未知事件应能安全处理。不要让一条失去消费者的流式任务无限生成并消耗配额。7. 可观测性与可复跑验证至少记录任务 ID、耗时、模型与工具调用、失败类别、预算拒绝和人工接管原因并做必要脱敏。测试集应包含正常、无权限、畸形参数、慢依赖、重复请求和恶意指令等情况。评审通过前确认这些样例能在目标环境复跑且失败后有明确的停止、回滚或人工处理入口。七项检查最终都指向同一个问题服务面对不完整输入、慢依赖和错误模型输出时是否仍保持数据边界、资源边界和可解释状态。把答案落在代码、配置和测试上比写一段笼统的“已加防护”更有价值。
