跳到主要内容

第 1.5.4 节：用状态、日志和停止条件证明 Agent 可验收

方案是否能交付，不能只凭感觉，需要结合“用状态、日志和停止条件证明 Agent 可验收”的验收样例和实际证据。完成本节后，你应该能够写出状态、日志和停止条件的验收样例、通过/不通过标准、判断阈值和风险说明。

状态和日志​

最小项目也要记录状态，否则面试时很难讲清系统可维护性。

状态或日志字段用途
trace_id（追踪编号）串联输入、模型调用、输出校验和错误。
session_id（会话编号）支持多轮追问和补充信息。
user_id（用户编号）区分用户身份和权限。
intent（意图）记录识别结果。
risk_level（风险等级）支持转人工和审计。
next_action（下一步动作）连接后续 RAG（检索增强生成）或工具调用。
raw_model_status（原始模型状态）记录模型是否成功返回，不记录敏感内容。
validation_error（校验错误）记录字段缺失、格式错误或枚举漂移。
stop_reason（停止原因）说明本轮处理为什么结束。

失败场景与兜底​

失败场景表现兜底方式验收标准
模型输出无效字段缺失或枚举值不合法重试一次，仍失败则转人工或返回安全提示无效输出不会进入下一步动作。
用户信息不足没有订单号或商品名next_action（下一步动作）为 ask_followup不在缺信息时调用真实工具。
风险等级不确定既像咨询又像投诉保守判为 medium 或 high，并要求人工复核高风险样例不会被低估。
用户要求立即退款Agent（智能体）可能想承诺结果固定边界：只能说明需要核验和审批回复中不出现承诺退款。
模型服务失败超时、限流或供应商错误降级为人工或稍后重试提示用户能看到明确状态，日志有错误原因。
重复提交用户连续发送相同诉求用 session_id（会话编号）和摘要合并处理不重复生成多个工单草稿。

验收标准​

本章验收的是设计完整性和流程稳定性。

验收项通过标准
输入字段用户问题、会话编号、追踪编号和业务上下文明确。
输出字段意图、风险、缺失字段、下一步动作和回复草稿稳定。
Mock（模拟）模式无 API Key（接口密钥）也能按规则返回结果。
真实模型模式通过安全配置读取模型信息，输出经过校验。
状态日志每次请求都能追踪输入、输出、错误和停止原因。
失败兜底缺信息、输出无效、高风险、模型失败都有处理方式。
第 1.6 章衔接next_action（下一步动作）能明确指出是否需要工具调用。

常见坑​

第一个项目做太复杂​

不要一上来做多智能体、复杂 RAG 和真实业务系统写入。先把分流骨架做稳。

只生成自然语言回复​

如果只有回复草稿，系统不知道下一步该查资料、查工具还是转人工。结构化输出必须保留。

Mock（模拟）和真实模式输出不一致​

两种模式必须遵守同一份字段契约。否则测试环境和真实环境会变成两套系统。

没有 trace_id（追踪编号）​

Agent 出错时，如果没有 trace_id（追踪编号），很难追踪模型输入、输出校验和兜底过程。

把工具调用意图当成工具执行​

本章只输出 call_tool（调用工具）这样的下一步动作，不真正查订单。第 1.6 章才讲工具执行、权限、审批和审计。

工程检查清单​

  • 是否能用一句话说明第一个 Agent 的目标？
  • 是否定义输入字段？
  • 是否定义输出字段？
  • 是否有 Prompt（提示词）边界？
  • 是否区分工具调用意图和真实工具执行？
  • 是否有 Mock（模拟）模式？
  • 是否有 Real Provider（真实模型供应商）模式设计？
  • 是否有状态和日志字段？
  • 是否有停止条件？
  • 是否有失败兜底？
  • 是否能自然进入第 1.6 章工具调用？

继续学习​