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