智能体 POC 能否进入生产，不能用“回答是否流畅”证明，而要用一次完整、可追踪、可复核的业务闭环证明：它能否在授权范围内获取可信数据，按明确规则完成判断，调用业务系统执行动作，并将结果、状态和异常准确回写。若只能生成建议，项目应定位为辅助决策；只有完成“感知—决策—执行—反馈”，才具备进入小范围生产的基础。
先定义生产放行对象
POC 的验证对象应是具体业务场景，而不是模型本身。优先选择高频、规则相对清晰、数据较稳定、结果可量化且风险可控制的任务，例如订单核验、客户状态更新、工单分派或付款申请预审。涉及大额付款、重大合同、核心数据修改等高风险动作，应先采用“智能分析或生成草稿＋人工审批”，不要直接开放全自动执行。
场景定义必须写清触发条件、输入数据、判断规则、执行动作、输出结果和失败处理。跨系统任务还要明确每一步的状态、业务编号、重试方式、人工接管和补偿机制。系统写入失败时，界面不能显示“已完成”；缺少这类状态约束，POC 即使演示成功，也不具备生产可信度。
用异常样本检验，而非只看正常流程
POC 至少应覆盖四类样本：正常任务、边界条件、数据缺失或接口超时等异常，以及越权指令和无关输入等对抗场景。正常样本通过，只能说明流程能够演示；边界、异常和越权情况也能被识别、暂停或转人工，才说明方案具备生产基础。
评估指标应同时覆盖效率、质量、闭环和风险，包括平均处理时长、人工操作步骤、字段与规则判断准确性、自动完成率、回写成功率、人工接管率、越权拦截率、错误执行数和审计完整性。试点前应建立基线，再比较智能体运行结果，不能只统计“回答成功率”。
把放行变成有条件的决策
POC 结束时，应形成明确的放行报告：哪些任务可以自动执行，哪些必须审批；哪些系统接入不稳定；异常由谁处理；综合成本是否下降；扩大规模后权限、并发和运维是否可控。上线路径宜从只读查询、生成草稿开始，逐步过渡到人工确认后执行，再扩大到低风险任务自动执行。
生产运行还必须保留原始请求、用户身份与权限、数据来源、工具调用、审批记录、回写结果以及重试和人工接管记录。真正可生产的智能体，不是“看起来会做事”，而是在责任边界清晰的前提下，能够被审计、被接管，也能够在失败后恢复业务流程。