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

> Perplexity 现在让 GPT-6 Astra 发送消息、修复软件、监控生产环境，人工审核大幅减少。但它没有公布任何数据，证明这份信任站得住。

原文: https://fdetimes.net/zh/news/perplexity-gpt-6-astra-end-to-end-trust/

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 在客户的系统上工作，不能独自做这个决定。你的工作是把“我们信任模型”变成一张客户自己看得懂的数字表，再由客户决定监督的力度。

**本周动手试试:**

- 选一条你在运行的 Agent 流水线，写下你还没有的三个数字：错误率、回滚频率、审批边界。答不上来的地方，就是人工审核还不能减少的地方。
- 把测试设计与写代码的模型分开：使用由人或独立流程定义的测试框架，再把结果与模型自己生成的测试做对比。

## 信源

- [Perplexity Says It Trusts Astra End to End](https://www.startuphub.ai/news/perplexity-says-it-trusts-astra-end-to-end)

- [Perplexity GPT-6 Astra end-to-end systems (DIYAI)](https://diyai.io/news/perplexity-gpt-6-astra-end-to-end-systems/)

- [Perplexity affida a GPT-6 Astra sistemi end-to-end, ma una minore supervisione alza la posta](https://www.remio.ai/it/post/perplexity-trusts-gpt-6-astra-with-end-to-end-systems-but-less-oversight-rais-it)