fengqun/docs/AGENT_SWARM_INDICATOR_TEST_MATRIX.zh-CN.md

Agent / 蜂群指标测试验收矩阵

对象: swarm-minimal 最小蜂群原型 日期: 2026-05-17 定位: 本文件是当前仓库所有 Agent / 蜂群指标测试的统一口径。其他文档只做解释或报告，指标阈值以本文件为准。

1. 指标设立方法

本项目不把“代码能跑”当成 Agent 质量标准。指标按下面流程设立：

1. 先确定 Agent 或蜂群特征，例如任务理解、交接、去中心化、自组织、涌现性。
2. 把抽象特征转换成可观察状态，例如 task status、claim event、shared_state、pheromone、artifact、consensus round。
3. 为每个指标设计一个可复现实验场景，明确输入、Agent 数量、任务数量、模型链路或候选集合。
4. 给每个指标设置成功阈值。阈值必须是布尔、数量、分数、集合或顺序条件，不能只写“效果不错”。
5. 指标通过必须有命令、测试文件或 live run 证据。

总体通过公式：

MINIMAL_AGENT_SWARM_PASS =
  AQS_PASS
  ∧ SW_AQS_PASS
  ∧ S01_to_S10_PASS
  ∧ F01_to_F06_PASS

其中任何一个一级门失败，当前仓库都不能声称满足“最小蜂群 Agent 验收”。

如果要声称“本机大规模压力也通过”，还必须额外满足：

LOCAL_LARGE_SCALE_PASS =
  MINIMAL_AGENT_SWARM_PASS
  ∧ L01_local_max_performance_stress_pass

如果要声称“3000 TPM 模型预算量级也通过”，还必须额外满足：

LOCAL_TPM_BUDGET_PASS =
  MINIMAL_AGENT_SWARM_PASS
  ∧ L02_3000_tpm_budget_acceptance_pass

2. 验收合理性设计

验收指标是否合理，按五个约束判断：

约束	设计要求	本项目落点
特征对齐	指标必须直接对应 Agent 或蜂群特征，不能只对应普通软件工程质量	AQS 对应单 Agent 能力；SW-AQS 对应多 Agent 协作；F01-F06 对应六个蜂群特征
可观察	指标必须能落到 task、claim event、shared_state、pheromone、artifact、report、consensus round 等证据	每项指标都有命令、测试文件或 live run 证据入口
可反驳	指标必须有失败条件，不能只写正向叙述	例如任一 F01-F06 失败则 S10 失败；S07 14 项检查任一失败则 live 标准失败
有阈值	指标必须能写成数字、布尔、集合或顺序条件	例如 Q >= 0.72、duplicate_claims = 0、round_count >= 2、event_delta >= 22
不自证	关键场景不能只用本仓库证明自己正确	S07 使用外部 GitHub 项目 fastapi/fastapi 固定 commit；S08 再审计报告和密钥样式

因此，这套验收的合理性不是来自“我认为合理”，而是来自：

抽象特征
  -> 可观察证据
  -> 可执行场景
  -> 明确阈值
  -> 失败可反驳
  -> 报告可审计

2.1 来源边界：引用算法、引用文章与项目自定义

这套指标不是“前无古人后无来者”的自创理论。它由三层组成：

层级	来源	本项目如何使用	是否项目自定义
模型限流 / TPM	RFC 2697 token bucket / rate policing；OpenAI rate limit 文档中的 RPM / TPM 维度	L02 使用虚拟 token ledger，验证多 Agent 并发时不会冲破 3000 TPM	3000 来自本轮用户给定量级；50 token × 60 task 是为了刚好打满 3000 token 窗口的工程验收参数
信息素 / 隐式协作	Stigmergy；Dorigo 等 1996 Ant System	用 pheromone 和 shared state 表示环境痕迹，Agent 不直接互发消息也能被环境影响	具体字段名、分数阈值、测试任务数是项目自定义
蜂群六特征	Bonabeau / Dorigo / Theraulaz 的 Swarm Intelligence 体系	把去中心化、自组织、涌现性、鲁棒性、可扩展性、隐式协作设为一级门	六特征组合为本项目验收口径，但每个特征不是自创概念
马尔可夫边界	Puterman MDP；Sutton / Barto 强化学习中对 state/action/reward/transition 的定义	只声明“工程意义上的马尔可夫式状态机”，不声明严格 MDP	当前非概率核、非策略优化，因此不强行套严格 MDP
Agent 风险与可观测性	NIST AI RMF / AI 600-1、OWASP LLM / Agentic Skills、MITRE ATLAS、OpenTelemetry	把拒答、偏题、泄密、工具边界、run/task/event/artifact 证据变成门禁	具体通过阈值按本仓库最小闭环目标配置
Handoff	LangGraph handoff 参考	用 active agent、previous summary、chain edge 表示接手	交接字段和报告格式是项目自定义

核心结论：

理论来源不是自创；
验收矩阵是项目配置；
阈值是为了让“最小蜂群 Agent 是否通过”可执行、可反驳、可复验。

关键引用：

• RFC 2697, A Single Rate Three Color Marker: https://www.rfc-editor.org/rfc/rfc2697.html
• OpenAI API rate limits: https://platform.openai.com/docs/guides/rate-limits
• Stigmergy: from mathematical modelling to control: https://pmc.ncbi.nlm.nih.gov/articles/PMC11371424/
• Dorigo, Maniezzo, Colorni, Ant System: Optimization by a Colony of Cooperating Agents, 1996: https://iridia.ulb.ac.be/~mdorigo/Published_papers/All_Dorigo_papers/DorManCol1996tsmcb.pdf
• Bonabeau, Dorigo, Theraulaz, Swarm Intelligence: From Natural to Artificial Systems, 1999: https://academic.oup.com/book/40811
• Puterman, Markov Decision Processes, 1994: https://books.google.com/books/about/Markov_Decision_Processes.html?id=tsiiQgAACAAJ
• NIST AI RMF: https://www.nist.gov/itl/ai-risk-management-framework
• NIST AI 600-1: https://doi.org/10.6028/NIST.AI.600-1
• OWASP LLM Top 10: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• MITRE ATLAS: https://atlas.mitre.org/
• OpenTelemetry: https://opentelemetry.io/docs/
• LangGraph handoff: https://reference.langchain.com/python/langgraph-swarm/handoff/create_handoff_tool

3. 反推测试标准的逻辑闭环

反推方式是从最终结论倒推必要条件，再把必要条件变成测试：

目标结论: 当前仓库满足最小蜂群 Agent 验收

必要条件:
  1. 单 Agent 输出可靠
  2. 多 Agent 协作成立
  3. 蜂群六特征成立
  4. 外部复杂代码任务链路成立
  5. 失败、拒答、偏题和泄密风险不能直接通过

反推测试:
  必要条件 -> 可观察指标 -> 场景输入 -> 成功阈值 -> 证据入口

闭环表：

结论主张	反推必要条件	测试场景	成功阈值	失败后结论
“Agent 能承接任务”	当前输出必须包含当前任务和上一步信息	S07 STEP-01 到 STEP-07	7/7 输出有 own marker 和 previous marker	不能声称上下文承接通过
“输出质量可控”	拒答、角色拒绝、偏题不能混入最终结果	质量门和 fallback 场景	Q >= 0.72；风险输出分 0.12；触发 retry/fallback	不能声称 Agent 质量门通过
“不是本仓库自证”	需要外部复杂代码目标	S07 fastapi/fastapi 固定 commit	14 项 live checks 全 PASS；外部文件引用 >=5	不能声称 live 外部代码验收通过
“蜂群不是多 Agent 堆叠”	六个蜂群特征都要可观察	S10 F01-F06	6 项全部 PASS	不能声称蜂群特征通过
“能容错”	单 Agent 失败不能导致整体失败	F04 / B01 / S06	failed_tasks >= 1 且 run 仍 converged	不能声称鲁棒性通过
“能扩缩容”	Agent 数变化不能改变架构或产生重复 claim	S09 / F05 的 3/5/7 场景	每个 n 完成 2n 任务，失败 0，重复 claim 0	不能声称可扩展性通过
“能收敛而非碰巧最高分”	需要质量门、候选融合和多轮共识	S07 / S09	S07 共识 round_count >= 2；S09 融合过滤低分噪声；质询先不收敛再收敛	不能声称收敛机制充分
“可审计且安全”	报告能说明输入输出交接且不泄密	S08 模型 I/O 报告审计	场景、输入、输出、交接证据存在；密钥样式命中数 0	不能声称人类审计友好或安全

闭环判定：

在 swarm-minimal 本地最小原型范围内:
  目标 -> 指标 -> 场景 -> 阈值 -> 证据 -> 结论
  是逻辑闭环。

在生产级无中心分布式 runtime 范围内:
  还不是闭环。

原因是当前测试已经能反驳“最小蜂群 Agent 验收”这个结论，但还不能反驳“生产级蜂群平台验收”这个更大结论。生产级闭环还需要真实 Kubernetes worker、Manager / Agnet API、人类审批、长期运行、真实扩缩容压测和生产监控。

3.1 蜂群性数值评分模型

为了避免“是不是蜂群”只停留在口头判断，本仓库新增 SWARM_COMPLIANCE_SCORE。它分成两个数值：

分数	含义	当前值
swarmness_score	只判断六个核心蜂群特征是否成立	100 / 100
minimal_compliance_score	判断是否达到本仓库最小蜂群 Agent 验收	100 / 100

权重设计：

组	权重	指标	为什么这样设
核心蜂群性	60	F01-F06，每项 10 分	“是不是蜂群”必须先看六特征，不能让工程外围项冲高分
Agent / 审计 / 收敛支撑	25	S07 10 分、S08 5 分、S09 10 分	证明不是多个 Agent 各跑各的，而是有外部复杂任务、输入输出审计、融合和质询共识
规模和预算	15	L01 7 分、L02 8 分	证明在本机大规模任务和 3000 TPM 模型预算下仍稳定

评分公式：

swarmness_score =
  100 × (Σ passed(F01..F06) × 10) / 60

minimal_compliance_score =
  Σ weight_i × pass_i

其中：

pass_i ∈ {0, 1}
Σ weight_i = 100

当前代入：

swarmness_score =
  100 × (10+10+10+10+10+10) / 60
  = 100

minimal_compliance_score =
  F01..F06(60)
  + S07(10)
  + S08(5)
  + S09(10)
  + L01(7)
  + L02(8)
  = 100

分级线：

分数区间	判定
< 60	不满足蜂群
60-74	部分蜂群，不可验收
75-84	最小可验收蜂群
85-94	合规蜂群原型
>= 95 且无硬上限	极强本地最小蜂群合规

硬上限规则：

失败条件	上限	解释
F01-F06 任一核心蜂群特征失败	最高 59	核心特征缺失时不能通过外围工程项补分
S07/S08/S09 任一支撑证据缺失	最高 84	可以是最小蜂群，但不能声称完整合规原型
L01/L02 任一规模或预算证据缺失	最高 94	可以合规，但不能声称“极强本地最小蜂群合规”

因此，当前结论不是“看起来像蜂群”，而是：

swarmness_score = 100 / 100
minimal_compliance_score = 100 / 100
tier = 极强本地最小蜂群合规
production_certification = false

边界：这个分数只证明本仓库定义的本地最小蜂群标准，不证明生产级 Kubernetes runtime、跨机器真实调度、人类审批和长期监控已经完成。

证据入口：

python3 -u -B examples/run_swarm_compliance_score.py

4. 总门槛

门槛	测试场景	成功值
A01 静态编译	编译 swarm_minimal/*.py、examples/*.py、tests/*.py	退出码 0，无语法错误
A02 单元与确定性场景	python3 -B -m unittest discover -s tests	当前 45 项测试全部通过，失败数 0
A03 蜂群行为	B01-B04：故障隔离、涌现、信息素、handoff	4 个场景全部 PASS
A04 传统基线对比	蜂群 vs 单路线/FIFO/无共享状态/无 handoff	蜂群总归一化分高于传统基线；当前 0.9175 > 0.1958
A05 多轮共识	候选 lease_based_pg_queue 的加权投票	converged=true，round_count >= 2
A06 下一阶段边界	S09 三项：3/5/7 claim、候选融合、互相质询	3 项全部 PASS
A07 六特征	S10 六项蜂群一级特征	6 项全部 PASS
A08 模型预算	L02 3000 TPM 调度验收	3000 token 单窗口不超额；预算利用率 1.0；失败和重复 claim 都为 0
A09 蜂群性数值	加权评分和硬上限	swarmness_score=100；minimal_compliance_score=100；核心特征任一失败时最高 59
S07 live 外部代码	fastapi/fastapi 固定 commit 的 7 步 Agnet 链	14 项检查全部 PASS，失败数 0
S08 模型 I/O 审计	审计 MODEL_AGNET_IO_REPORT.zh-CN.md	场景、输入、输出、交接证据存在，密钥样式命中数 0
S09 边界能力	扩缩容、融合、质询	3 项全部 PASS
S10 六特征	F01-F06	6 项全部 PASS
L01 本机最大性能压力	使用本机检测到的全部逻辑 CPU 跑多进程大规模 swarm stress	默认 worker_processes = logical_cpus；完成任务数等于目标任务数；失败 0；重复 claim 0；所有分片收敛
L02 3000 TPM 模型预算	8 个 Agent 并发领取模型预算任务，共享虚拟 TPM ledger	target_tpm = 3000；单个模拟分钟 token 使用量 <=3000；总预留 token =3000；预算利用率 =1.0；失败 0；重复 claim 0

5. S10 蜂群六特征指标

S10 是当前蜂群指标的主门。它不接受“多 Agent 能跑”这种宽泛结论，只接受下面六项都达标。

ID	指标	设计场景	成功值
F01	去中心化	4 个 Agent 自主领取 8 个 autonomous 任务；每个 Agent 只基于共享任务池和本地 task 输入决策	participating_agents >= 4；duplicate_claims = 0；control_keys = 0；decision_records = task_count = 8
F02	自组织	5 个局部信号 api:0.31、docs:0.22、api:0.29、tests:0.18、api:0.27 写入 shared_state，初始不预置全局分类	no_preseeded_global_plan=true；local_interaction_count >= 5；dominant_cluster = api；cluster:api:count = 3；cluster:api:score > cluster:docs:score
F03	涌现性	4 个局部候选信号：alpha:0.31、beta:0.33、beta:0.34、gamma:0.45；单个 gamma 局部信号最高，但 beta 群体累计更高	candidate:beta:score = 0.67；accepted_candidate = beta；accepted_score > max(local_signal_i) = 0.45
F04	鲁棒性	3 个 route 任务，其中 1 个 Agent 故意抛错，2 个 backup Agent 正常完成	failed_tasks = 1；completed_tasks >= 2；negative_observation_exists=true；run_status = converged
F05	可扩展性	分别用 3/5/7 个 Agent 跑同一 shared task pool 架构，每个 Agent 对应 2 个任务	对每个 n ∈ {3,5,7}：completed_tasks = 2n；failed_tasks = 0；duplicate_claims = 0；participating_agents = n；所有 task 状态为 done
F06	隐式协作	3 个 stigmergy 任务预置信息素：high 0.9、medium 0.4、low 0.1；Agent 不互发消息，只读写环境痕迹	direct_message_keys = 0；environment:trail 存在；first_claim = high-signal；final_pheromone_high > final_pheromone_medium

S10 成功公式：

S10_PASS =
  F01_pass
  ∧ F02_pass
  ∧ F03_pass
  ∧ F04_pass
  ∧ F05_pass
  ∧ F06_pass

证据入口：

python3 -B -m unittest tests.test_swarm_characteristics_acceptance
python3 -u -B examples/run_swarm_characteristics_acceptance.py

6. S09 下一阶段边界指标

ID	指标	设计场景	成功值
S09-1	SW-AQS-16 并发自主 claim	3/5/7 个 Agent 分别领取 2n 个 stress 任务	对每个 n：converged=true；completed_tasks=2n；failed_tasks=0；duplicate_claims=0；participating_agents=n
S09-2	候选融合	三个候选：quality 0.91、coverage 0.86、noise 0.2；融合阈值 min_score=0.5	source_candidate_ids=("quality","coverage")；融合文本包含所有 expected terms；不包含 低分噪声
S09-3	互相质询共识	3 个 QuestioningAgent 执行 challenge、revise、vote；参数 threshold=0.7、min_margin=0.2、max_rounds=3、evaporation=0.85	converged=true；accepted_candidate=approve_fused_candidate；round_count>=2；第一轮不收敛；最后一轮收敛；每轮都有 challenges 和 revisions

证据入口：

python3 -u -B examples/run_next_boundary_acceptance.py

7. L01 本机最大性能压力指标

L01 用来回答“这台电脑本地最大性能下，当前最小蜂群 claim / 执行 / 收敛是否仍稳定”。它默认使用 os.cpu_count() 检测到的全部逻辑 CPU，并用多进程分片压测，避免只在单线程里假并发。

指标	设计场景	成功值
CPU 使用范围	默认读取本机逻辑 CPU 数	worker_processes = logical_cpus，本机当前为 8
大规模任务量	每个进程跑一个独立 swarm 分片	默认 tasks_per_process = 2048；本轮重压测提升到 16384
Agent 规模	每个进程多个 Agent 共享 task pool	默认每进程 8 个 Agent；本轮重压测提升到 16，总计 128 个 Agent
CPU-bound 工作	每个任务执行 deterministic checksum	默认 64 轮；本轮重压测为 128 轮
正确性	所有任务必须完成	completed_tasks = total_tasks
容错安全	本地压力下不允许任务失败	failed_tasks = 0
claim 安全	本地压力下不允许重复领取	duplicate_claims = 0
参与度	所有 Agent 至少参与一次	participating_agents = total_agents
收敛	每个进程分片都必须收敛	converged_shards = worker_processes

本轮最大性能实测结果：

logical_cpus = 8
worker_processes = 8
agents_per_process = 16
total_agents = 128
tasks_per_process = 16384
total_tasks = 131072
cpu_cycles_per_task = 128
duration_seconds = 46.9689
tasks_per_second = 2790.61
failed_tasks = 0
duplicate_claims = 0
converged_shards = 8

证据入口：

python3 -u -B examples/run_large_scale_stress_acceptance.py

本轮最大性能命令：

SWARM_STRESS_AGENTS_PER_PROCESS=16 \
SWARM_STRESS_TASKS_PER_PROCESS=16384 \
SWARM_STRESS_CPU_CYCLES=128 \
python3 -u -B examples/run_large_scale_stress_acceptance.py

边界：L01 是本机内存版最大性能压力验收，不等同于生产 Kubernetes runtime、跨机器网络、真实 Redis Stream 消费或长期稳定性压测。

8. L02 3000 TPM 模型预算指标

L02 用来回答“如果模型侧只给 3000 TPM，当前蜂群是否能在共享任务池里按预算调度，而不是并发冲过额度”。它不调用真实模型供应商，使用本地确定性的虚拟 token ledger，避免把验收建立在外部网络抖动或真实 key 泄露上。

参数来源：

参数	值	来源 / 解释
target_tpm	3000	本轮用户指定的模型吞吐量级，等价于每分钟最多 3000 token 的预算
tokens_per_task	50	本地确定性测试的单位模型任务成本；不是声称真实业务任务都只有 50 token
task_count	60	3000 / 50 = 60，刚好打满一个 3000 token 窗口，用来验收满载不超额
agent_count	8	默认 min(8, logical_cpus)；本机当前为 8 个逻辑 CPU，所以使用 8 个预算 Agent
simulated_minutes	1	ceil(total_token_demand / target_tpm) = ceil(3000 / 3000) = 1

补充单元测试还覆盖 61 个任务的 rollover 场景：第 61 个 50-token 任务会排入第二个模拟分钟，因此窗口分布必须是 {0: 3000, 1: 50}，用来证明不是简单把所有任务硬塞进同一窗口。

指标	设计场景	成功值
TPM 预算	目标模型吞吐预算固定为 3000 TPM	target_tpm = 3000
任务规模	60 个模型预算任务，每个任务 50 token	task_count = 60；tokens_per_task = 50；total_reserved_tokens = 3000
Agent 规模	默认读取本机逻辑 CPU，上限 8 个预算 Agent	本机当前 agent_count = 8，且 8 个 Agent 都至少参与一次
预算窗口	每次任务执行必须先向共享 ledger 预留 token	任意模拟分钟 tokens <= 3000；over_budget_windows = {}
预算利用率	默认总需求正好打满一个 3000 token 窗口	budget_utilization = 1.0
正确性	所有预算任务完成	completed_tasks = 60；all_tasks_done = true
容错安全	预算调度下不允许任务失败	failed_tasks = 0
claim 安全	并发预算调度下不允许重复领取	duplicate_claims = 0
收敛	预算任务完成后写入收敛结果	converged = true

L02 成功公式：

L02_PASS =
  target_tpm = 3000
  ∧ max(tokens_by_minute) <= 3000
  ∧ total_reserved_tokens = task_count * tokens_per_task = 3000
  ∧ budget_utilization = 1.0
  ∧ completed_tasks = task_count
  ∧ failed_tasks = 0
  ∧ duplicate_claims = 0
  ∧ participating_agents = agent_count
  ∧ converged = true

本轮 3000 TPM 实测结果：

target_tpm = 3000
agent_count = 8
task_count = 60
tokens_per_task = 50
total_reserved_tokens = 3000
simulated_minutes = 1
max_tokens_in_any_minute = 3000
budget_utilization = 1.0
failed_tasks = 0
duplicate_claims = 0
participating_agents = 8

证据入口：

python3 -u -B examples/run_tpm_budget_acceptance.py
python3 -B -m unittest tests.test_tpm_budget_acceptance

边界：L02 是本地模型预算调度验收，不等同于真实供应商的 live 限流压测。真实供应商限流还需要在 NewAPI 网关侧记录请求 token、返回 token、429 重试和费用归因。

9. S07 live 外部代码 Agent 链指标

S07 的任务不是测试本仓库，而是让 7 个连续 Agnet 阶段审查外部复杂 GitHub 项目：

目标项目: fastapi/fastapi
固定 commit: ecace740f3eaccb1aba152cf1de79477095c56f4
任务主题: 响应序列化与 OpenAPI 依赖链审查

指标	设计场景	成功值
模型发现	从 NewAPI 兼容模型列表选择模型	len(discovered_models) >= 3；len(set(selected_models)) = 3；selected 是 discovered 子集
7 步链路	STEP-01 到 STEP-07 连续推理	PostgreSQL 中 task_rows = 7；全部 status=done
marker 与前序承接	每步输出必须包含当前 STEP 和 previous marker	7/7 输出满足 own_marker 和 previous_marker
输出质量门	每步输出按质量检查项得分	Q >= 0.72 且关键项全通过
shared_state 交接	每步写 summary、cursor、edge	cursor=STEP-07；summary_count=7；7 条 edge 都存在
信息素证据	PostgreSQL 与 Redis 都记录正反馈	每个任务 P_task_pg > 0 且 P_task_redis > 0
收敛状态	run 完成并写入收敛结果	run_status=converged
artifact 证据	Blob 中存在结果工件	blob_artifact_exists=true
收敛分	最终结果可接受	completed_tasks=7；accepted_score >= 0.75
事件流	Redis Stream 记录 claim/done/converged 等事件	event_delta >= 3 * task_count + 1，当前任务数为 7，因此至少 22
外部代码材料	输出必须包含外部 FastAPI 代码审查信息	包含不变量、反例、修正、验收、复杂度或 O(，并包含 FastAPI 代码语义
多轮质量共识	三类审查 Agnet 对最终链路投票	converged=true；accepted_candidate=accept_external_chain；round_count>=2；参数 threshold=0.7、min_margin=0.25
文件引用	最终输出必须落到外部仓库文件	count_referenced_files(final_output) >= 5
不固定模型	不能把 NEWAPI_MODEL 当成唯一固定模型	输出必须说明模型发现 / discover，并拒绝固定单模型
不测试本仓库	不能把 swarm_minimal、examples 当成被测代码	输出含 fastapi/fastapi 和固定 commit；引用外部文件数 >=5；本仓库目标漂移为 false

证据入口：

python3 -u -B examples/run_standard_scenario_acceptance.py

10. 通用 Agent 指标 AQS

ID	指标	设计场景	成功值
AQS-01	任务理解	S07 每个 Agnet 被分配一个明确 STEP 子任务	7/7 输出回应当前 STEP，不泛泛聊天
AQS-02	指令遵循	输出必须包含 marker、约束、文件路径、验收命令或风险项	quality_pass=true，且缺失关键项数量为 0
AQS-03	上下文忠实	除 STEP-01 外，每步承接上一步 marker 和 summary	7/7 输出包含 previous marker；shared_state 有 7 条 edge
AQS-04	可验证输出	输出能被规则检查，而不是只有主观结论	S03/S05/S07 相关检查全部 PASS
AQS-05	模型选择可控	不依赖固定 NEWAPI_MODEL	discovered 模型数 >=3，selected distinct 模型数 =3
AQS-06	工具/资源边界	MVP 不把 NATS/Cosmos 变成必需依赖	依赖边界测试中“必须依赖 NATS/Cosmos”的文本必须被判 false
AQS-07	敏感信息保护	审计 Markdown、报告和配置摘要	明显密钥样式命中数 0；配置输出只允许 redacted 或占位符
AQS-08	可观测性	S07 写入 run_id、task、score、event、artifact	PostgreSQL、Redis、Blob 证据全部存在
AQS-09	错误可解释	故障注入任务失败	failed task 有 error；负信息素 <0；其他任务继续完成
AQS-10	交接准备度	每个 Agnet 输出给下一步 summary / risk / next action	STEP-01 到 STEP-06 均能被下一步读取并继续
AQS-11	外部依赖真实性	live 连接 Azure PostgreSQL、Redis、Blob、NewAPI	S07 完整矩阵 PASS；无 .env 时不能声称 full standard PASS
AQS-12	人类审计友好	生成并审计模型 I/O 报告	场景、任务、输入、输出、交接证据存在；审计测试 2 项 PASS
AQS-13	输出质量恢复	故意让 bad model 先输出拒答/角色边界文本	bad output 分数为 0.12；触发 retry/fallback；最终 used_model=good-model

11. 蜂群 Agent 指标 SW-AQS

ID	指标	设计场景	成功值
SW-AQS-01	多角色能力	S07 3 个不同模型、7 个连续步骤	selected distinct 模型数 =3；chain step 数 =7
SW-AQS-02	共享任务池	Agent 从统一 task pool claim	task_rows =7 或 S09/S10 场景任务数全部进入同一 store
SW-AQS-03	局部感知	Agent 输入包含当前任务和前序 summary	每步 prompt 带 task input；STEP-02 到 STEP-07 带 previous summary
SW-AQS-04	自主 claim / 去中心化	S10 F01	participating_agents>=4；duplicate_claims=0；control_keys=0
SW-AQS-05	信息素 / 分数	成功加分，失败扣分	成功任务 P_t>0；失败任务 P_t<0
SW-AQS-06	隐式协作	S10 F06	message:* 键数量 0；依靠 pheromone 和 shared_state trail 协作
SW-AQS-07	handoff 连续性	B04 与 S07 chain edge	active agent、目标 agent、payload、edge 均保留
SW-AQS-08	广播 / 事件	Redis Stream 记录事件	S07 event_delta >= 22
SW-AQS-09	收敛条件	不只看跑完，还看分数、状态、artifact、质量门、共识	S07 14 项 checks 全 PASS
SW-AQS-10	鲁棒性	S10 F04 / B01 / S06	单 Agent 失败时 failed_tasks>=1，但 run 仍 converged
SW-AQS-11	涌现性	S10 F03 / B02	群体累计分大于任一局部信号，最终候选来自群体聚合
SW-AQS-12	传统基线对比	C01-C04	swarm score 高于 traditional score；当前 ratio 4.69
SW-AQS-13	live 外部闭环	S07	Azure + NewAPI + 外部 GitHub 代码场景 PASS
SW-AQS-14	马尔可夫式状态	M01-M03	等价当前状态下 claim 与 score 更新一致；但不声明严格 MDP
SW-AQS-15	多轮质询共识	S07/S09	round_count>=2，第一轮可不收敛，后续达成接受
SW-AQS-16	扩缩容与并发	S09/S10 F05	3/5/7 Agent 下完成 2n 任务，失败和重复 claim 都为 0
SW-AQS-17	候选融合	S09-2	min_score=0.5 过滤低分噪声，保留多个高分候选来源
SW-AQS-18	本机大规模压力	L01	8 逻辑核满核压测，128 Agent / 131072 任务，失败 0、重复 claim 0、全部收敛
SW-AQS-19	模型预算调度	L02	3000 TPM 窗口内 60 个预算任务全部完成；单分钟 token 不超额；预算利用率 1.0；失败和重复 claim 都为 0

12. 不通过判定

出现以下任一情况，不能判定通过：

• 六特征任一项失败。
• S07 14 项 live 检查任一失败。
• 模型输出拒答、角色拒绝、偏题或漂移到本仓库后，没有触发扣分、重试或 fallback。
• 报告、日志或 Markdown 中出现真实长期密钥、连接串或未脱敏密码。
• claim 出现重复领取，或者单个 Agent 失败导致整体不能收敛。
• 只展示最高分候选，但没有候选融合或多轮共识证据。
• 缺少 .env 时仍声称完整 S07 live 标准矩阵已通过。
• L01 压测中出现任务失败、重复 claim、分片未收敛或参与 Agent 数不足时，不能声称本机大规模压力通过。
• L02 中任意模拟分钟 token 超过 3000，或者总需求没有被完整预留，不能声称 3000 TPM 量级通过。

13. 当前结论

按本文件定义的最小验收口径，当前仓库已经达到最小 Agent / 蜂群 Agent 闭环：

• A01-A09 通过。
• S01-S10 通过。
• F01-F06 通过。
• L01 本机最大性能压力通过：8 逻辑核、128 Agent、131072 任务、失败 0、重复 claim 0。
• L02 3000 TPM 模型预算验收通过：8 Agent、60 个任务、3000 token 单窗口打满、失败 0、重复 claim 0。
• S07 live 外部 GitHub 代码场景通过，最新 run_id 为 9c7ccc6087c1435694a52efb12c32301。

边界：这不是生产级无中心分布式 runtime 认证。真实 Kubernetes worker、Manager / Agnet API、人类审批、生产监控和长期运行压测仍属于下一阶段。