Plurai：Agent 从 Demo 到生产，缺的是持续评估闭环

Plurai 切中的问题，不是怎样再给 Agent 换一个更强模型，而是怎样让一个已经能跑的 Agent 经得起生产环境。演示阶段只需证明它偶尔能完成任务；上线之前，团队必须回答另一组问题：真实用户会怎样打乱流程，工具失败后系统会不会编造结果，政策边界能否稳定执行，模型、提示词或知识库更新后旧能力会不会回退。

Plurai 把产品定位为 AI Agent trust platform，公开产品线围绕 simulation、evals 和 guardrails 展开。Simulation 负责制造更接近真实业务的多轮场景；evals 把任务要求转成可重复的判准；guardrails 则把部分判准放进运行时，在危险输出或动作到达用户前进行拦截、降级或转人工。官网公布的失败率、成本和延迟对比均属于厂商自述，采用前仍需在自己的数据、流量和风险条件下复测。

Agent 的生产问题通常不是“答得不够聪明”

传统聊天模型的测试经常围绕单轮答案展开，但 Agent 的风险分散在整条动作链：识别意图、选择工具、读取上下文、生成参数、执行动作、解释结果，以及在信息不足时停下来。任何一环出错，都可能让一个语言上合理的回复变成业务上的错误。

真实用户也不会按演示脚本提问。他们会省略条件、混用术语、在第三轮改变目标、上传格式异常的附件，或者把本不该合并的两项任务塞进一句话。客服 Agent 可能在退款权限上越界；研究 Agent 可能把检索失败说成“没有相关资料”；编码 Agent 可能在测试未通过时仍然声称完成。只测标准问题，等于把最有价值的失败样本留给真实用户发现。

Simulation 的任务是扩展故障面

Plurai 的 Simulation 页面强调按具体产品、persona 和 edge cases 生成合成场景，并覆盖多轮对话、邮件、文档、图片等工件。这一方向的价值，不是生成更多看起来复杂的数据，而是系统地扩大故障面：相互冲突的指令、错误工具返回、缺少附件、权限变化、长对话中的状态漂移，以及政策中没有明确写出的灰区。

但模拟不等于现实。合成数据会继承生成方法的偏差，也容易高估文档里已经写清楚的规则，低估组织真正依赖的口头惯例。稳妥做法是把模拟集分为三层：人工确认的 golden set、来自真实事故和人工接管记录的回归集、由平台生成并等待审核的候选集。候选样本只有在业务负责人确认其风险和期望行为后，才进入发布门禁。

先建立 baseline，再训练评估器

引入自动化评估前，团队至少要整理三类 baseline：高频正常流程、已知失败案例、绝不能越过的红线。每条样本都应包含输入、上下文、期望动作、允许的降级方式和不可接受结果。退款 Agent 的答案不能只有“通过/失败”，而要区分自动退款、补问信息、转人工和直接拦截。

Plurai 所说的 intent calibration，可以理解为把自然语言里的业务意图压成可训练、可检验的边界。这里不能只交给模型。产品、运营、安全与合规需要共同决定：什么叫正确，哪些错误比另一些更严重，什么时候宁可拒绝，什么时候拒绝反而伤害用户。平台可以帮助生成样本和评估器，却不能替组织拥有政策。

为什么不能只靠 LLM-as-a-judge

通用大模型做裁判适合快速探索，但它有三个限制。第一，同一案例可能因提示词、温度或模型版本改变而获得不同标签。第二，通用裁判容易偏爱流畅答案，却忽略工具是否真的执行、引用是否真实、动作是否超权。第三，如果所有线上请求都交给大模型二次判断，成本和延迟很快成为覆盖率上限。

Plurai 的产品主张是针对具体语义任务训练小语言模型，用于会话评估、grounding、政策合规、意图分类、工具调用和动作验证。SLM 的优势不在“模型越小越好”，而在任务足够窄时可以获得更稳定的分类边界，并以较低成本常态运行。代价同样明确：训练数据覆盖不到的变化会形成盲区；政策更新后必须重做回归；高风险灰区仍需要人工复核。

Guardrail 不是一堵统一的墙

实用的护栏不应只有允许与拒绝两种结果。不同风险需要不同执行模式：隐私泄露和越权动作可以硬拦截；grounding 不足可以要求补充引用；意图不明可以追问；品牌语气问题可以只做标记；高金额或不可逆操作必须升级人工审批。把所有异常都硬拒绝，会让系统安全却不可用。

因此每条护栏都需要误报预算。团队要测量正常任务被误拦的比例、危险行为漏过的比例、增加的端到端延迟、人工接管量和用户流失。Plurai 官网公开的低延迟和成本数据只能作为试点假设，不能直接写进自己的 SLA。

上线前应有一套可执行门禁

• 政策所有权：每个 evaluator 和 guardrail 都有明确的内部负责人。
• 固定基线：保留不可被自动生成覆盖的 golden set，包含通过、失败、灰区和关键业务案例。
• 版本记录：记录 Agent、模型、提示词、工具、知识库、评估器、阈值和政策版本。
• 影子运行：新护栏先只评分不拦截，对照人工标签后再小流量启用。
• 分级执行：分别定义提醒、改写、追问、转人工、阻断，而不是统一拒绝。
• 真实负载：在生产相近并发和长对话下测成本、P95 延迟及稳定性。
• 回滚能力：保留上一版评估器和阈值，护栏异常时不必关闭全部保护。
• 反馈闭环：把误拦、漏拦、差评、人工接管和工具故障持续回灌回归集。

Plurai 最有价值的启发，是把 Agent 质量从一次上线验收改造成持续运行的控制系统。模拟负责在用户之前发现盲点，评估负责让失败可重现、可比较，护栏负责限制线上损害，真实反馈再反过来修正样本和边界。模型能力会继续变化，但只有这条闭环稳定，Agent 才真正从能演示的功能变成可以负责的生产系统。