gongzhiyongandOmX
a4d771ede5
Add a concrete 0-100 swarmness/compliance score, local large-scale stress, and 3000 TPM budget acceptance so the repo can say when it is a swarm by measured criteria instead of prose alone. Constraint: user required Chinese docs, explicit scenarios, parameters, formulas, pass/fail lines, and git upload. Rejected: prose-only PASS reports | they did not answer whether the system is a swarm with a concrete score. Confidence: high Scope-risk: moderate Directive: keep production runtime claims separate from local minimal swarm acceptance scores. Tested: py_compile swarm_minimal examples tests; unittest discover -s tests 45 tests; run_swarm_compliance_score.py; run_tpm_budget_acceptance.py; run_academic_standard_evaluation.py; git diff --check; docs/script secret-pattern scan. Not-tested: live S07 and production Kubernetes/NewAPI provider-rate-limit stress were not rerun in this upload step. Co-authored-by: OmX <omx@oh-my-codex.dev>
11 KiB
Agnet 框架逻辑与实现过程说明
这份说明只从 Agnet 的输入、输出、交接和收敛角度解释当前框架逻辑，不展开源码，不写命令，不贴实现代码。
指标测试的统一阈值见 AGENT_SWARM_INDICATOR_TEST_MATRIX.zh-CN.md。本文件描述输入输出链路如何工作；“到多少值算成功”以该矩阵和 SCORING_AND_ACCEPTANCE_FORMULAS.zh-CN.md 为准。
一句话逻辑
当前框架不是让一个模型一次性回答完整问题，而是把一个复杂目标拆成连续的 Agnet 输入。每个 Agnet 接收“当前任务输入”和“上一位 Agnet 的输出摘要”，生成自己的输出，再把这个输出变成下一位 Agnet 的输入条件。最后，框架先做输出质量门和多轮质量共识，再根据评分选择最终可接受输出作为收敛结果。
被测场景是什么
本轮使用的外部场景是 FastAPI 项目的响应序列化与 OpenAPI 依赖链审查。FastAPI 是一个 Python API 框架，核心价值是让开发者通过类型标注和数据模型构建接口，并自动生成接口文档。
选择这个场景的原因是：它不是一个单点问题。响应模型、依赖注入、参数元数据、数据序列化、OpenAPI 文档生成和测试覆盖会互相影响。一个 Agnet 很容易只看到局部，所以需要多个 Agnet 按顺序承接。
本轮验证的重点不是给 FastAPI 上游提交真实补丁，而是验证蜂群框架是否能把外部复杂代码问题变成连续输入输出链，并保留每一步的交接证据。
框架的输入如何形成
最初输入不是简单一句“帮我分析 FastAPI”，而是一个带约束的任务包。这个任务包包含四类信息。
第一类是目标输入：要求审查 FastAPI 响应序列化与 OpenAPI 依赖链，目标必须固定在外部 FastAPI 项目，不能把当前仓库当成被测对象。
第二类是范围输入：告诉 Agnet 重点围绕路由、依赖注入、OpenAPI 生成、响应模型序列化、编码器和测试覆盖，不允许泛化成普通调度系统问题。
第三类是交接输入：从第二步开始，每个 Agnet 都会收到上一位 Agnet 的阶段标记和上一位 Agnet 的输出摘要。也就是说，后续 Agnet 不是从空白开始，而是从前一个输出继续。
第四类是验收输入：每一步都必须产生自己的阶段标记，除第一步外必须承接前一步，最终输出必须能体现不变量、依赖图、复杂度、反例、修正策略、文件级计划和验收判断。
第五类是质量门输入：如果模型输出拒答、角色拒绝、偏题、转向当前仓库或没有承接前一步，框架会把它判为低质量输出。低质量输出不能直接进入通过结论，而是触发重试或切换模型。
Agnet 的分工如何发生
当前框架把一个完整复杂任务拆成七个连续 Agnet。每个 Agnet 的输入和输出关系如下。
| Agnet | 输入 | 期望输出 | 实际输出评价 |
|---|---|---|---|
| Agnet 01 | 起始目标、外部项目范围、禁止自测边界 | 问题边界、不变量、风险、下一步交接摘要 | 完成了边界定义，明确目标是 FastAPI 外部项目，并给出下一步依赖图分析方向 |
| Agnet 02 | Agnet 01 的输出摘要，以及建立依赖图的任务 | 路由、依赖注入、OpenAPI、序列化之间的依赖图 | 新最小版本中通过质量感知重试和模型接手，输出通过交接质量门 |
| Agnet 03 | Agnet 02 的输出摘要，以及跨文件风险定位任务 | 响应模型、依赖参数、编码器、OpenAPI schema 之间的风险路径 | 继续围绕 FastAPI 外部项目展开，形成了跨文件风险分析 |
| Agnet 04 | Agnet 03 的输出摘要，以及构造反例任务 | 响应过滤、默认值、nullable、依赖参数和 schema 不一致的反例 | 输出了反例方向，使问题从抽象风险进入可验证失败场景 |
| Agnet 05 | Agnet 04 的输出摘要，以及修正策略任务 | 修改策略、兼容性约束、恢复路径 | 新最小版本中通过质量门约束，输出通过交接质量门 |
| Agnet 06 | Agnet 05 的输出摘要，以及文件级计划任务 | 具体到文件层面的修正计划和测试计划 | 重新把链路拉回 FastAPI 文件级计划，承担了恢复连续性的作用 |
| Agnet 07 | Agnet 06 的输出摘要，以及最终验收任务 | 验收命令、失败判定、可合并结论、最终收敛输出 | 形成最终验收判断，并成为本轮收敛选择的主要输出 |
这张表说明了当前框架的最新状态：链路不仅跑通，而且已经把“拒答、角色拒绝、偏题、本仓库漂移、没有承接上一步”纳入质量门。旧 run 中 Agnet 02 和 Agnet 05 暴露过异构模型不接受蜂群角色的问题；新最小版本已经把这类输出改成扣分、重试、换模型和质量共识验收。
输出如何变成下一步输入
每一步 Agnet 输出后，框架会抽取一个阶段摘要。这个摘要不是给人看的普通总结，而是下一位 Agnet 的上下文输入。
因此，Agnet 01 的输出会变成 Agnet 02 的前置条件；Agnet 02 即使输出质量不足，也会留下一个可审计的交接痕迹；Agnet 03 会在这个基础上继续推进；后续步骤依次重复这个过程。
这里的关键不是“模型说它交接了”，而是框架能回答三个问题。
第一，下一位 Agnet 收到了什么输入。它收到当前任务要求，也收到上一阶段摘要。
第二，当前 Agnet 输出了什么。它输出阶段结论、风险、反例、修正策略或验收判断。
第三，这个输出有没有被后续步骤使用。后续 Agnet 的输入中包含上一阶段摘要，最终报告也保留每一步的交接证据。
实现过程按输入输出看
第一步，先把用户目标改写成标准任务输入。用户想验证的是“蜂群 Agnet 能不能处理复杂代码任务”，所以任务输入被固定为外部 FastAPI 项目，而不是当前仓库。
第二步，把标准任务输入拆成七段连续输入。每段输入都只解决一个阶段问题，避免一个 Agnet 同时做边界、分析、反例、修正、验收。
第三步，让每个 Agnet 接收两部分输入：本阶段任务输入，以及上一阶段输出摘要。这样可以验证真正的上下文承接，而不是七个模型各说各话。
第四步，收集每个 Agnet 的输出。输出不是只看最终文字是否好看，而是看是否包含本阶段标记、是否承接前一步、是否仍然围绕 FastAPI 外部项目、是否给出下一步可用信息。
第五步，对输出进行评分。评分偏向连续性、目标一致性、可交接性和最终可验收性。输出偏题、拒答或只声明能力边界时，会被重罚，不能靠普通高分混进最终结果。
当前输入输出链的关键成功值是：每个 Agnet 输出质量分 Q >= 0.72 且关键项全通过；STEP-01 到 STEP-07 共 7 个任务全部完成；最终接受分 accepted_score >= 0.75；质量共识至少 2 轮；任一模型拒答、角色拒绝、偏题或漂移到本仓库时，风险输出分固定降为 0.12 并触发重试或 fallback。
第六步，如果输出不合格，框架先进行同模型重试；仍不合格时，切换到 fallback 模型接手当前步骤。只有通过质量门的输出才会成为下一步摘要。
第七步，把每一步输出沉淀成共享状态、观测记录和评分记录。这样最终报告可以追溯“谁接了什么输入、谁输出了什么、谁把结论交给了下一步”。
第八步，做多角色质量共识。当前最小版本引入了三个审查 Agnet 角色：交接连续性审查、输出质量审查、最终收敛审查。第一轮只形成候选，第二轮才允许达成接受结论。
第九步，做最终收敛。当前最小框架仍保留最高分输出作为最终接受文本，但它不再是单独门槛；必须先通过输出质量门和多轮质量共识门。
当前框架逻辑的优点
它已经能把复杂目标拆成连续输入输出链。用户可以看到每一步 Agnet 收到什么任务、输出了什么内容、下一步如何接手。
它已经能处理模型质量问题。遇到拒答、角色拒绝或偏题输出时，框架会重罚该输出，触发重试或换模型，并把质量门结果写入验收报告。
它已经能形成可追溯收敛。最终结果不是聊天窗口里临时拼出来的，而是从已完成 Agnet 输出中选择，并保留评分、观测、多轮质量共识和最终 artifact 证据。
已修复的最小版本问题
第一，收敛不再只看最高分。最新 S07 live run 在最高分输出之前增加了多角色质量共识门，第一轮未收敛，第二轮才接受外部 FastAPI 推理链。
第二，评分已经加强。模型拒答、角色拒绝、偏题、本仓库漂移和缺少交接信息都会触发质量风险，分数会被重罚，不能靠链路继续自动通过。
第三，补救路径已经接入。当前步骤输出不合格时，框架会先重试，再切换到 fallback 模型接手，避免低质量输出直接污染下一步输入。
第四，交接质量已经成为单独指标。每一步都要同时满足当前阶段标记、上一阶段标记、外部仓库、固定 commit、FastAPI 技术语义、下一步交接和非拒答输出。
仍保留的边界
当前最小版本已经补入互相质询的代码级验收：Agnet 可以先提出反驳，再生成修正，最后重新投票。它仍不是生产级长对话辩论系统，因为质询还运行在本地确定性验收场景中，没有接入真实 runtime 的动态任务图。
当前补救方式包括重试、换模型、候选融合和质询修正，但还没有自动创建新的补充任务。也就是说，它能修复当前候选和当前步骤输出质量问题，但还没有把“补充 Agnet”扩展成动态任务图。
当前已经有候选融合的最小代码能力，可以把多个有效候选去重合并；S07 live 外部链路仍保留质量门后的最高分收敛作为主路径。下一阶段要把候选融合接入 live 外部链路和真实平台收敛，而不只作为本地确定性验收能力。
结论
当前框架的核心逻辑是：用户目标先变成标准化任务输入，再被拆成多个连续 Agnet 输入；每个 Agnet 的输出都会变成下一步输入的一部分；输出必须先通过质量门和多轮质量共识，最终再通过评分收敛形成接受结果。
从输入输出角度看，最新最小版本已经修复了三项关键不足：不再只靠最高分收敛，不再放过拒答或偏题输出，交接质量也从“有记录”升级为“有质量判定”。本轮又补上了 3/5/7 并发 claim、候选融合、反驳-修正-再投票的本地最小代码验收；剩余工作是把这些能力接入真实 runtime、动态补充任务和生产级平台链路。