fengqun/docs/AGNET_FRAMEWORK_INPUT_OUTPUT_LOGIC.zh-CN.md

Agnet 框架逻辑与实现过程说明

这份说明只从 Agnet 的输入、输出、交接和收敛角度解释当前框架逻辑，不展开源码，不写命令，不贴实现代码。

一句话逻辑

当前框架不是让一个模型一次性回答完整问题，而是把一个复杂目标拆成连续的 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 的输出摘要，以及最终验收任务	验收命令、失败判定、可合并结论、最终收敛输出	形成最终验收判断，并成为本轮收敛选择的主要输出

这张表说明了当前框架的真实状态：链路是跑通的，但不是每个模型输出都完美。Agnet 02 和 Agnet 05 暴露了异构模型在“接受蜂群角色”和“持续承接任务”上的风险。框架没有把这个问题藏掉，而是在报告中标成输出质量风险。

输出如何变成下一步输入

每一步 Agnet 输出后，框架会抽取一个阶段摘要。这个摘要不是给人看的普通总结，而是下一位 Agnet 的上下文输入。

因此，Agnet 01 的输出会变成 Agnet 02 的前置条件；Agnet 02 即使输出质量不足，也会留下一个可审计的交接痕迹；Agnet 03 会在这个基础上继续推进；后续步骤依次重复这个过程。

这里的关键不是“模型说它交接了”，而是框架能回答三个问题。

第一，下一位 Agnet 收到了什么输入。它收到当前任务要求，也收到上一阶段摘要。

第二，当前 Agnet 输出了什么。它输出阶段结论、风险、反例、修正策略或验收判断。

第三，这个输出有没有被后续步骤使用。后续 Agnet 的输入中包含上一阶段摘要，最终报告也保留每一步的交接证据。

实现过程按输入输出看

第一步，先把用户目标改写成标准任务输入。用户想验证的是“蜂群 Agnet 能不能处理复杂代码任务”，所以任务输入被固定为外部 FastAPI 项目，而不是当前仓库。

第二步，把标准任务输入拆成七段连续输入。每段输入都只解决一个阶段问题，避免一个 Agnet 同时做边界、分析、反例、修正、验收。

第三步，让每个 Agnet 接收两部分输入：本阶段任务输入，以及上一阶段输出摘要。这样可以验证真正的上下文承接，而不是七个模型各说各话。

第四步，收集每个 Agnet 的输出。输出不是只看最终文字是否好看，而是看是否包含本阶段标记、是否承接前一步、是否仍然围绕 FastAPI 外部项目、是否给出下一步可用信息。

第五步，对输出进行评分。评分偏向连续性、目标一致性、可交接性和最终可验收性。输出偏题、拒答或只声明能力边界时，即使链路继续，也应该被标成质量风险。

第六步，把每一步输出沉淀成共享状态、观测记录和评分记录。这样最终报告可以追溯“谁接了什么输入、谁输出了什么、谁把结论交给了下一步”。

第七步，做最终收敛。当前最小框架的收敛方式是从已完成输出里选择最高分结果作为接受输出。也就是说，收敛不是多数投票，也不是专家委员会共识，而是当前最小原型里的最高分输出选择。

当前框架逻辑的优点

它已经能把复杂目标拆成连续输入输出链。用户可以看到每一步 Agnet 收到什么任务、输出了什么内容、下一步如何接手。

它已经能暴露模型质量问题。比如本轮 Agnet 02 和 Agnet 05 没有完成预期技术任务，报告会把它们标成输出质量风险，而不是假装全部内容都合格。

它已经能形成可追溯收敛。最终结果不是聊天窗口里临时拼出来的，而是从已完成 Agnet 输出中选择，并保留评分、观测和最终 artifact 证据。

当前框架逻辑的不足

当前收敛还是最小版本，主要是最高分输出选择。它还不是严格的多轮共识，也不是多个 Agnet 互相质询后达成一致。

当前评分还需要继续加强。特别是遇到模型拒答、角色拒绝或输出偏题时，应该更重地扣分，并触发重试、换模型或补充 Agnet，而不是只让链路继续往后走。

当前输入输出链已经能说明“有交接”，但还需要进一步说明“交接质量是否足够好”。未来标准应该把承接前一步、纠正前一步错误、恢复偏题链路作为单独指标。

结论

当前框架的核心逻辑是：用户目标先变成标准化任务输入，再被拆成多个连续 Agnet 输入；每个 Agnet 的输出都会变成下一步输入的一部分；最终通过输出评分和收敛选择形成接受结果。

从输入输出角度看，本轮已经证明框架能跑通外部复杂代码场景的连续推理链，也能暴露部分模型输出不合格的问题。但从更高标准看，它还需要加入更强的拒答识别、自动重试、交叉质询和多轮共识，才能从“最小蜂群闭环”升级为更稳健的蜂群 Agent 框架。