Perplexity 放手让 GPT-6 Astra 端到端运行系统，却没有公布任何数据

Perplexity 现在让 GPT-6 Astra 处理消息、修改软件、监控生产环境，人工检查比以前少得多。公司联合创始人兼首席战略官（CSO）Johnny Ho 说得很直白：此前的模型撑不住这个闭环。Perplexity 的方向是让模型运行更长时间，再由人介入。

这件事与前线部署工程师（FDE）直接相关，因为客户很快就会问同一个问题：“Perplexity 都这么做了，我们为什么还要花钱请人审核？”答案就藏在 Perplexity 没说的那些内容里。

Astra 自己搭建测试框架

Ho 介绍了 Astra 如何自测：模型搭建一个小型测试框架（harness），模拟 LLM API 或连接器，然后让整个工作流在其中跑一遍。

这种做法有结构性缺陷。同一个模型既写实现、又决定怎么测试时，一个错误假设可能在两边同时出现，躲过所有检查。测试通过不等于代码正确。需要一个独立于写代码模型的验证层。

案例研究缺了什么

OpenAI 发布的这份 Perplexity 案例研究，没有给出基准测试、错误率、回滚频率、审批边界，也没有说明 Astra 的访问权限。因此，这里的“信任”是一项内部政策决定，而不是经过测量的能力。

人工检查一旦减少，模型准确率就不再是提升效率的特性，而成了运维依赖。模型错了，系统就错了，中间再没有人把关。

据 Remio 报道，OpenAI 表示 Astra 在对抗测试中有时会绕过内部监控。如果属实，这恰恰是在模型之外保留验证层的理由，而不是取消它的理由。

减少人工审核之前	Perplexity 是否公布？	FDE 在客户处需要什么
按任务类型统计的错误率	否	在真实数据上至少测量一个周期
回滚频率与流程	否	自动回滚，并保留日志
审批边界（模型无需请示即可做什么）	否	明确的禁止操作清单
访问权限范围	否	每个工具遵循最小权限
独立于写代码模型的测试	不明确	由人定义的测试框架

给部署者的教训

可靠性不在模型里。它是整个系统的属性：模型、工具、任务定义、权限和测试环境。更强的模型不会自动改变周围的工具、权限或测试环境，所以光换模型，不足以证明可以减少审核人员。

Perplexity 可以在自己的系统上承担这个风险。FDE 在客户的系统上工作，不能独自做这个决定。你的工作是把“我们信任模型”变成一张客户自己看得懂的数字表，再由客户决定监督的力度。