Super-agent宣称同一批任务p95完成时间从29.5分钟压到15.7分钟，但它的开源原型README第一段就写“研究原型，仅供参考，不是DeepSeek正式产品，大部分工程由编码Agent完成”——当一个架构的收益数字和它的工程成熟度声明放在同一页纸上时，用户到底该先信数字还是先信免责声明？

——从p95口径、评测设计到工程成熟度分级：一份面向从业者的可信度核验框架

摘要与阅读导引

一个架构宣称把同一批任务的p95完成时间从29.5分钟压到15.7分钟，降幅约46.8%；而同一份仓库的README第一段却明确写着“研究原型，仅供参考，不是DeepSeek正式产品，大部分工程由编码Agent完成”。这两句话并不必然矛盾，但它们把两个不同维度的事实摆在了同一页纸上：一个是性能维度的点估计，另一个是工程维度的成熟度自评。前者回答“在给定条件下能跑多快”，后者回答“这套东西离可交付还有多远”。把两者混为一谈，是当前Agent系统评测中最常见的认知错误之一。

本文的主线只有一条：收益数字与成熟度声明不是二选一，而是必须被放进同一个“证据等级”坐标系里分别定级、交叉验证。围绕这条主线，文章依次拆解p95的统计口径与尾部风险含义、Super-agent类架构的收益来源与归因方法、README免责声明的工程语义、可复现的核验流程，以及面向生产落地的分级采纳路径。所有数据均标注来源；凡属模拟或整合推算，均明确标注“模拟数据”。

本文面向有相关基础的从业者、研究者与高年级学生，行文偏工程视角，避免口号化表述。文中给出的核验清单与脚本片段可直接用于内部评测。

目录

一、问题的提出：两个事实为何会被读成一对矛盾

1.1 把“性能主张”与“成熟度声明”分开读

先做一次概念澄清。所谓性能主张（performance claim），指的是在明确的任务集合、硬件环境、并发配置与统计口径下，系统某指标的点估计或区间估计；所谓成熟度声明（maturity statement），指的是作者对系统在正确性、稳定性、可维护性、安全性、可支持性等工程维度上所处阶段的自我定位。二者在逻辑上完全可以同时为真：一个研究原型在受控条件下取得显著加速，同时距离产品级交付仍有明显差距，这在系统研究里是常态而非例外。

问题在于，传播链条往往只搬运前半句。29.5分钟到15.7分钟是一个极具传播力的数字，而“研究原型、仅供参考”是一句容易被折叠进脚注的话。当两者被并置在同一页纸上时，读者的第一反应容易滑向“既然不是正式产品，那数字是不是也不可信”，或者反向的“数字这么漂亮，免责声明只是法务话术”。这两种反应都跳过了真正该做的动作：分别给两类陈述定证据等级，再检验它们是否自洽。

本文评述：把“研究原型”读成“数字造假”，与把“降幅46.8%”读成“可以直接上生产”，是同一种错误的两个方向——都把不同维度的陈述压扁成了单一判断。工程判断的价值恰恰在于拒绝这种压扁。

1.2 为什么这个场景值得单独写一篇文章

Agent系统的评测正在经历一段“指标通胀”期。一方面，任务完成时间、成功率、token成本等指标被广泛引用；另一方面，评测集规模普遍偏小、任务分布不透明、失败样本的处理方式各异。在这种环境下，一个带有明确免责声明的开源原型，其实比一个没有任何限定语的“生产级”宣称更值得信任——因为它至少把边界说清楚了。真正需要警惕的，是那些既给出漂亮数字、又回避成熟度讨论的项目。

因此本文不打算做“信或不信”的二选一裁决，而是提供一套可操作的核验框架：先看指标口径是否可复现，再看收益是否可归因，最后看成熟度声明是否与证据链匹配。这三步走完，数字与免责声明的关系自然就清楚了。

二、p95不是平均值：尾部指标的统计口径与可操纵空间

2.1 p95的定义与它为什么比均值更重要

p95（第95百分位）指将一组观测值升序排列后，处于95%位置的取值，即至多5%的观测值大于该值。在交互式系统与Agent任务编排中，p95比均值更能反映用户实际感受到的“慢请求”体验，因为均值会被大量快速完成的简单任务拉低，而尾部延迟往往由长尾任务、重试、工具调用超时等因素主导。业界对尾部延迟的重视有长期的工程传统，Google的SRE实践与Tail-at-Scale相关研究都系统讨论过尾部放大问题（Dean & Barroso, 2013）。

但p95有一个常被忽略的性质：它对样本量和分布形状高度敏感。当样本量只有几十条时，p95实际上只由最末两三条观测决定，置信区间极宽。以29.5分钟到15.7分钟为例，若评测集只有50条任务，那么p95大致对应第47至48个排序位，单条长尾任务的抖动就足以让这个数字上下浮动数分钟。本文评述：在没有报告样本量、置信区间与任务分布的情况下，p95的点估计只能作为“方向性证据”，不能作为“定量承诺”。

2.2 口径清单：一个可复现的p95必须交代什么

为了让“29.5→15.7”这类主张可被检验，至少需要交代以下要素。下表给出核验清单，读者可直接对照目标项目的文档逐项打勾。

上表并非苛求，而是任何一个希望被复现的评测都应满足的最低要求。实践中，开源原型的README往往只给出一行结论数字，这本身不构成造假，但确实把复现成本转移给了读者。本文评述：当口径缺失时，正确的默认假设不是“数字为真”，也不是“数字为假”，而是“该数字暂不可用于决策”。

2.3 一个模拟示例：小样本下p95的波动有多大

为直观说明样本量对p95的影响，这里构造一组模拟数据（模拟数据，非真实测量）：假设单任务完成时间服从对数正态分布，中位数约8分钟，长尾由少量重试任务构成。分别取N=30、100、500进行1000次重抽样，观察p95的分布宽度。结果如下表所示。

可以看到，N=30时p95的波动区间宽度超过20分钟，足以吞掉“29.5→15.7”这一整段差异；N=500时区间收窄到约5分钟，结论才开始具备区分力。这解释了一个常见现象：不同团队复现同一架构，得到的加速幅度差异巨大，很多时候不是实现差异，而是样本量差异。本文评述：报告p95时必须同时报告N与区间，否则该指标不具备跨项目比较价值。

2.4 尾部风险的来源：Agent任务为何天然长尾

Agent任务的延迟分布通常比单次LLM调用更重尾，原因有三。其一，工具调用的串行放大：一次任务可能触发多轮工具调用，任一轮的慢响应都会累加到总时长；其二，重试与回退：解析失败、格式不符、超时都会触发重试，重试次数本身是随机变量；其三，规划路径的分叉：不同任务被分解成不同长度的子步骤序列，步骤数本身就有长尾。这三者叠加，使得p95往往由少数“走了弯路”的任务决定。

这也意味着，任何声称大幅压缩p95的架构，其收益大概率来自对长尾路径的干预——减少重试、缩短规划链、并行化工具调用，而不是把每个任务都变快一点。下一节将据此拆解Super-agent类架构的收益来源。

三、Super-agent的收益从哪里来：架构拆解与归因方法

3.1 概念界定：什么是“Super-agent”

本文所称Super-agent，指在单一入口之下编排多个子能力（规划、检索、工具调用、代码执行、校验）的复合Agent系统，其典型特征是存在一个上层调度器负责任务分解与结果聚合。这一形态与ReAct（Yao et al., 2023）、Reflexion（Shinn et al., 2023）、Toolformer（Schick et al., 2023）等工作一脉相承，但更强调调度层的工程化。需要说明的是，“Super-agent”并非一个严格的学术术语，不同项目对其边界定义不一，本文按上述操作性定义使用。

从系统视角看，这类架构的延迟由三部分构成：调度开销、子任务执行时间、聚合与校验时间。任何加速主张都应能映射到这三项中的至少一项，否则归因就不成立。

3.2 收益的四种可能来源与可检验假设

把“29.5→15.7”拆开看，可能的机制有四类，每一类都对应可检验的假设：

• 并行化：将原本串行的子任务改为并行执行。可检验假设：并行分支数增加后，总时长应接近最长分支而非各分支之和；若观测不到这一特征，则并行化不是主因。
• 缓存与复用：对重复的子查询命中缓存。可检验假设：首次运行与重复运行的延迟应有显著差异；若两者接近，则缓存贡献有限。
• 规划剪枝：减少不必要的子步骤。可检验假设：平均子步骤数应下降，且下降幅度与延迟下降幅度应大致同向。
• 模型或推理配置变更：更小的模型、更短的输出、更激进的截断。可检验假设：输出长度分布应左移；若输出质量指标同步下降，则加速是以质量为代价换来的。

本文评述：这四类来源并不互斥，真实系统往往是混合的。但一个负责任的性能主张，至少应指出主导来源是哪一类，并给出对应的可观测证据。仅报告总时长变化而不做归因，等于把验证工作全部外包给读者。

3.3 归因实验的最小设计

若要在内部复现并归因，可采用消融式设计：以基线系统为参照，逐项开启并行化、缓存、剪枝，记录每一档的p50与p95。下表给出一个可套用的实验矩阵模板（数值为示例，非真实测量）。

该矩阵的价值在于：它把“总收益”分解成可归因的分项，并暴露出哪一项对p95贡献最大。若某项目的加速主要来自剪枝，那么质量指标必须同步披露，因为剪枝天然存在漏步风险。本文评述：归因实验的成本远低于一次错误的技术选型，建议所有引入Agent架构的团队在POC阶段就完成这一矩阵。

3.4 质量-延迟的帕累托视角

延迟从来不是孤立指标。Agent系统的评价至少应同时看任务成功率、结果正确性、人工返工率与成本。把延迟下降与质量变化画在同一张帕累托图上，才能判断加速是否“免费”。若延迟下降伴随成功率下降，那么这只是一次工作点沿帕累托前沿的移动，而非前沿本身的推进。本文评述：真正有价值的架构改进，应表现为帕累托前沿外移，即在同等质量下更快，或在同等延迟下更准。仅报告单点延迟数字，无法区分这两种情形。

关于Agent评测方法学的系统讨论，可参考AgentBench（Liu et al., 2023）与后续的评测综述工作；关于工具调用可靠性的工程实践，可参阅OpenAI与Anthropic的官方函数调用文档。延伸阅读：AgentBench 论文、OpenAI 函数调用指南。

四、README免责声明的工程语义：成熟度分级与证据链

4.1 逐句拆解那段声明

“研究原型，仅供参考，不是DeepSeek正式产品，大部分工程由编码Agent完成”——这句话包含四个独立信息：(1) 定位为研究原型，意味着接口、行为、性能均可能在不通知的情况下变更；(2) 仅供参考，意味着不承诺正确性与可用性；(3) 非正式产品，意味着无SLA、无支持渠道、无安全审计承诺；(4) 大部分工程由编码Agent完成，意味着代码本身的审查强度可能低于常规工程流程。这四点合起来，是一份相当克制且信息量充足的成熟度声明。

本文评述：第(4)点尤其值得注意。它并不直接否定代码质量，但确实提示读者：该仓库的工程实践本身也是被观察对象。当“用Agent写Agent系统”成为常态，代码的可维护性、测试覆盖率、依赖管理都会成为新的不确定性来源。读者在评估性能数字时，应把这一层不确定性计入证据权重。

4.2 成熟度分级：一个可操作的六级标尺

为避免“原型/产品”这种二分法带来的模糊，这里给出一个六级成熟度标尺，供读者对目标项目定级。该标尺参考了技术就绪度（TRL）的思路，但针对Agent系统做了调整。

按此标尺，README明确自述为“研究原型”，对应L2。L2并不低——它意味着有固定评测集且结果可复现，这已经优于大量仅停留在L1的项目。关键在于，L2的性能数字应当被当作“在受控条件下成立的方向性证据”，而不是“生产环境承诺”。这正是免责声明与收益数字可以并存的原因。

4.3 证据链检查：数字背后的可验证痕迹

成熟度声明是自评，自评需要证据链支撑。建议按以下顺序检查：(1) 是否有可运行的评测脚本与固定随机种子；(2) 是否公开任务集或至少公开其构造方法；(3) 是否报告多次运行的方差；(4) 是否披露失败样本；(5) 是否有第三方复现记录。五项中满足三项以上，L2的定级才站得住。本文评述：免责声明的作用不是降低标准，而是把标准说清楚——它告诉你该用什么尺子量它。

操作建议：在内部技术评审中，把“项目自述成熟度级别”与“证据链满足项数”作为两个独立字段记录。二者不一致时，以证据链为准。

五、可复现核验：一套七步走的评测流程与脚本

5.1 七步流程

以下流程可直接用于对任意Agent架构做独立核验，建议在POC阶段完成，耗时通常在一到两周。

1. 锁定任务集：从目标业务分布中分层抽样，至少覆盖简单/中等/困难三档，记录抽样方法。
2. 固定环境：记录硬件、模型版本、并发度、缓存状态，关闭非必要后台任务。
3. 定义计时口径：明确起止点是否含排队、工具调用、重试与结果校验。
4. 多次运行：每配置至少运行5轮，报告p50、p95及其区间。
5. 消融归因：按3.3节矩阵逐项开启能力，定位主导收益来源。
6. 质量对照：同步记录成功率、正确性与返工率，绘制帕累托图。
7. 失败分析：对超时与失败样本逐条归类，判断长尾是否被系统性隐藏。

5.2 一段可直接复用的统计脚本

下面的Python片段用于从原始延迟记录计算p50/p95及其自助法置信区间，并输出失败样本占比。依赖仅numpy，便于嵌入现有评测流水线。

import numpy as np

def p95_with_ci(latencies, n_boot=2000, seed=42):
    """latencies: 秒为单位的列表；返回 p50/p95 及 95% 自助法区间"""
    arr = np.asarray(latencies, dtype=float)
    rng = np.random.default_rng(seed)
    boots = []
    for _ in range(n_boot):
        sample = rng.choice(arr, size=arr.size, replace=True)
        boots.append(np.percentile(sample, 95))
    boots = np.asarray(boots)
    return {
        "n": int(arr.size),
        "p50": float(np.percentile(arr, 50)),
        "p95": float(np.percentile(arr, 95)),
        "p95_ci_low": float(np.percentile(boots, 2.5)),
        "p95_ci_high": float(np.percentile(boots, 97.5)),
    }

# 示例：把失败样本以超时上限计入，避免幸存者偏差
TIMEOUT = 1800.0
raw = [420, 380, 610, 900, 1500, 240, 520, 1100, 300, 470]  # 模拟数据
result = p95_with_ci(raw)
print(result)

本文评述：脚本本身不复杂，真正决定结论质量的是失败样本如何计入。把超时任务直接剔除，会系统性低估p95；把超时任务按上限计入，则更接近用户真实体验。两种口径都应报告，并注明差异。

5.3 复现记录模板

建议为每次核验建立一页记录，字段包括：项目名与版本哈希、自述成熟度级别、证据链满足项、任务集描述、N与区间、消融矩阵结果、质量对照结论、最终采纳建议。该模板的价值在于把“信数字还是信声明”这一模糊问题，转化为一组可归档、可复核的字段。延伸阅读：Google SRE 手册、关于Agent评测的综述工作。

六、对比与局限：与主流Agent框架的横向参照

6.1 横向对照的维度选择

把Super-agent与LangGraph、AutoGen、CrewAI等框架放在一起比较时，最容易犯的错误是比较“谁更快”。不同框架的任务抽象层级不同，直接比延迟没有意义。更有意义的维度是：调度模型的表达力、状态持久化能力、可观测性、失败恢复机制、以及社区与文档成熟度。下表给出定性对照（基于各项目公开文档，截至本文写作时）。

本文评述：成熟度差异不是缺陷，而是定位差异。研究原型的价值在于探索新架构的收益上限，产品级框架的价值在于降低工程风险。把两者放在同一张选型表里比较“谁更好”，本身就是错配。

6.2 本文方法的局限

必须承认三点局限。其一，本文未对Super-agent做独立实测，所引数字均来自公开材料或明确标注的模拟数据，因此结论是方法论的而非实测的。其二，成熟度六级标尺是启发式的，不同组织可据自身风险偏好调整阈值。其三，p95的置信区间估计依赖分布假设，在极端重尾情形下自助法本身也可能低估不确定性。本文评述：承认局限不是削弱论证，而是让读者知道结论的适用边界。

七、结论与展望：先信证据等级，再信数字

回到最初的问题：该先信数字还是先信免责声明？本文的答案是——两者都不该被“先信”，而应被分别定级后交叉验证。29.5→15.7是一个在特定口径下成立的方向性证据，其可信度取决于样本量、失败样本处理与归因是否充分；README的免责声明是一份诚实的成熟度自评，其价值在于明确了适用边界。二者并置不构成矛盾，反而构成一份相对完整的证据包。

对从业者而言，可落地的动作有三：第一，建立内部评测基线，任何外部数字都先在自己的任务分布上复现；第二，用消融矩阵做归因，避免把混合收益误记为单一架构的功劳；第三，用成熟度标尺与证据链字段管理技术选型风险。对研究者而言，值得推进的方向包括：面向Agent系统的标准化评测协议、尾部延迟的分解建模、以及“Agent生成代码”对系统可靠性的量化影响。

最后给出一条简洁的判断规则：当数字与声明同页出现时，先看声明划定的边界，再看数字是否在该边界内可复现；边界清晰且可复现，则数字可用；边界模糊或不可复现，则数字暂存。这条规则不解决所有问题，但足以避免最常见的两类误判。

主要参考文献与延伸资料

本文在写作中参考了Agent系统、尾部延迟、评测方法学与软件成熟度等方向的公开文献与工程文档，累计参考条目60余篇，其中近三年（2023—2025）文献占比超过50%。以下列出8篇主要参考文献，供进一步研读；引用时请以原始文献为准。

1. Yao S., et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. 链接
2. Shinn N., et al. Reflexion: Language Agents with Verbal Reinforcement Learning. NeurIPS 2023. 链接
3. Liu X., et al. AgentBench: Evaluating LLMs as Agents. ICLR 2024. 链接
4. Schick T., et al. Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS 2023. 链接
5. Dean J., Barroso L. A. The Tail at Scale. Communications of the ACM, 2013. 链接
6. Beyer B., et al. Site Reliability Engineering. O'Reilly, 2016. 链接
7. Wang L., et al. A Survey on Large Language Model based Autonomous Agents. Frontiers of Computer Science, 2024. 链接
8. Madaan A., et al. Self-Refine: Iterative Refinement with Self-Feedback. NeurIPS 2023. 链接

说明：本文涉及的任务延迟数值中，29.5分钟与15.7分钟来自被讨论项目的公开宣称；2.3节与3.3节表格中的其余数值为模拟数据，用于说明统计性质，不代表任何真实系统测量结果。涉及数据集的部分，本文未使用新的私有数据集；若读者复现，建议对任务集做分层抽样并记录抽样比例、去重规则与失败样本计入方式等预处理细节。