GenericAgent Goal Hive Master 调度 SOP 深度解析以工程控制论驱动多 Worker 稳定交付【免费下载链接】GenericAgentSelf-evolving agent: grows skill tree from 3.3K-line seed, achieving full system control with 6x less token consumption项目地址: https://gitcode.com/GitHub_Trending/pc/GenericAgent本文围绕 GenericAgent 仓库中 memory/goal_hive_master_duty.md 这一核心文档展开系统拆解 Goal Hive 模式下 Master 的职责边界、四阶段迭代循环、失稳急刹与底线纪律并结合 memory/goal_hive_sop.md、memory/goal_mode_sop.md、assets/agent_bbs.py 与 reflect/agent_team_worker.py 等仓库实现给出可直接落地的主从协作、BBS 通信与增量验收完整方案。一、Master 是谁只拆、只判、只汇绝不亲自生产Goal Hive 是 Goal Mode 的多 worker 协作协议见 memory/goal_hive_sop.md。在这个体系里Master 是 Hive 的总体设计部它的职责只有三类动作拆把阶段目标切成互不重叠的独立子任务派发给 worker判汇总产物后判断质量、排序优先级汇把多路产物收拢、整合、验收。Master不亲自生产子任务产物——一旦 Master 下场干活worker 就会空转整个调度体系失去意义。同时Master 无权停止自己不得设计自停条件它只能按预算推进直到用户给定的时间预算耗尽。这一职责边界在 memory/goal_hive_sop.md 的Hive Master 职责四条中进一步固化master 必须阅读记忆中 goal_hive_master_duty.md持续检查问题、寻找改进点只负责任务调度和团队组织不允许亲自干活导致 worker 空转终极目标是要做到完美的找不到任何问题的任务交付结果围绕核心产出如果子任务很多worker 做不过来可以拉起更多 worker。二、底层模型把交付当成受控系统SOP 从工程控制论的第一性原理推导出整套工作方法。核心符号只有四个J*用户真正要的价值目标/价值函数哲学层不变ĴMaster 对 J* 的形式化估计——会变需要持续校准y当前产物e偏差e J* − y。每一轮的实际工作就是测 e、压 e让 y 单调逼近 J*预算到点就交出当前最好的 y。所谓失稳就是系统跑偏或空转详见第四节。这个模型的关键启示是Master 的核心职责不是做得多而是把 J* 与 y 之间的偏差测量准确、压缩到位。因此 SOP 反复强调两点锁边界先于动手钉死 J* 范围——要什么、明确不要什么需求模糊或有歧义例如接入是只收还是收发时按最小必要 简单优雅收敛或向用户澄清禁止臆测扩张 scope校准 Ĵ 而不只校准 y检查阶段要回头质疑目标本身看 Ĵ 是否做多、做偏、过度设计如造了需求不要的能力。三、怎么跑三条铁律与四阶段循环3.1 三条铁律铁律一只拆只汇。Master 只做拆切子任务和汇汇总、判断、排序绝不自己下场生产产物。铁律二锚点只增不减。始终维护一个当前最优已验收版本作锚点每轮只在锚点上做增量改——在已有产物上找可优化点修改能不重写就不重写。验收让 J 升才合入变差就回退。铁律三循环到预算用尽才停。交当前锚点版不是做完才停。任何时刻必须清楚自己在x.几这个阶段。一轮的标准节奏是探测 → 设计 → 执行 → 检查 →重读本 SOP→ 下一轮。其中探测/检查是发散求全靠多 worker 并行、独立、去相关地铺开设计/执行是收敛择优Master 判断、择一、忠实落地。3.2 x.1 探测查得尽量全阶段目标是查得尽量全查五类内容分析用户需求探测环境现状记忆中的重要信息/原则调研可用的方案、材料、方法建议上轮的结果、变化、检查报告。操作上先锁边界校准 Ĵ → 按需求、环境、记忆、方案四项切成独立调研子任务分头派多个 worker→ 收齐后按对 J* 的重要性排序 → 写探测报告Tx.md只留重点和变化。从第 2 轮起只查上轮变了/没查清的部分不重查环境一变就重探变化的部分。3.3 x.2 设计收敛出最优那一个方案这一阶段Master 亲自做没什么可并行。依据探测报告 上轮检查报告决定这轮改哪几处、拆几个执行子任务、各自的验收线。产出执行方案Tx.md内含changelog这轮要改的 P0/P1 清单——来自上轮检查报告逐条对准缺口不在已饱和处精雕。3.4 x.3 执行忠实落地选定方案拆每个执行子任务都定义成独立接口输入/输出/放哪里/合格线派给 worker能并行就并行汇Master 不下场只盯进度、收产物、按 changelog 增量改锚点。这里与仓库的 worker 拉起机制直接对应。在 memory/goal_hive_sop.md 中worker 的启动命令为start /b python CodeRoot/agentmain.py --reflect CodeRoot/reflect/agent_team_worker.py \ --base_url http://127.0.0.1:PORT --board_key BOARD_KEY --name hive-worker-1后续 worker 由 Master 按需增加不能超过 5 个一般任务 24 个足够。worker 侧的接单逻辑实现在 reflect/agent_team_worker.pycheck()会轮询 BBSGET /posts?limit10带X-API-Key头无新帖返回None不唤醒 agent连续失败 10 次则/exit有帖子后按_prompt()的规则接单先看新帖、找适合接的任务帖、回复抢单、确认是最早接单后执行完成后发帖汇报结果长结果使用文件并严格区分交付结果与报告信息特别强调master 的说明性帖子要求 worker 不要接单的不要接单——这正是 memory/goal_hive_sop.md 第一帖规范中worker 不要接单先等 hive master 拆分子任务的落地。3.5 x.4 检查挑出尽量多的问题检查阶段要从多角度派独立的挑刺/测试子任务给不同 workerSOP 给出了五个必做视角用户视角试用攻击者/反面假设边界与 corner case测例尽量多、全、广第三方独立复核回到需求质疑目标本身对照 J* 看 Ĵ 是否做多/做偏/过度设计。验收线是硬性的每个挑刺/测试子任务必须交可复现的物理证据且证据形态匹配交付形态——代码要端到端跑通的命令 原始输出不止单元桩测文稿要全文通读 按需渲染/视觉核对版式数据要实跑校验。声明已完成不算验收。汇总后按对 J* 的伤害排成 P0/P1写检查报告Tx.md。这份 P0/P1 报告就是下一轮 x.2 的 changelog——偏差e J*−y被具体化带进下一轮增量修形成闭环。这一监察哲学在仓库中也有独立实现 memory/supervisor_sop.md 定义监察者模式——先定行动协议再盯协议偏离最后看完成证据监察者只读探测、一句话干预、禁止下场干活与 Master 检查阶段的验收纪律证据必须可复现、与交付形态匹配一脉相承。四、失稳急刹六个信号与五步处置SOP 明确列出六种失稳信号出现任意一种立即按序处置信号worker 忙但 J 不升 / 局部产物多但整体不可用 / 过程证明取代用户价值 / 多人改同一产物冲突 / Master 被细节牵走丢全局 / 额外产出污染核心交付。处置顺序不可跳步停止新派发回读用户需求与 J*重新对齐现在最重要的一件事查接口是否未冻结砍掉与主目标最弱的在途任务某维度连续两轮 J 不升即判饱和换到离达标最远的维度恢复闭环再派。其中接口未冻结的检查对应执行阶段的子任务接口设计输入/输出/放哪里/合格线——接口一旦被并发修改多人改同一产物的冲突就会冒出来这正是失稳的典型来源。五、底线纪律交付、诚实与整洁SOP 的最后一部分是四条不可逾越的底线成品与过程分离核心产物只放用户要用的成品说人话、给成品、取舍随场景来源、验证、尝试记录另放不污染成品不留半成品不确定性要么查证补全、要么删除自己搞定不推给用户诚实记录时间够就修到更优预算到点仍未通过的项必须如实写入交付报告。诚实记录写报告不写进成品本身BBS_CWD 保持整洁中间产物归子目录或带标注核心交付物一眼可定位。这与 memory/goal_hive_sop.md 中的工作目录约定一致——优先使用BBS_CWD进行文件传输而非 BBS 文件功能即把 BBS 当作消息通道、把本地目录当作产物仓库。六、落地环境BBS 与 goal_state 的配套实现要真正跑起一个 HiveMaster 依赖两套基础设施均在仓库中有完整实现。6.1 Agent BBS消息总线assets/agent_bbs.py 是一个极简 FastAPI 公告板是 Master 与 worker 的全部通信通道。启动方式与 API 在 memory/goal_hive_sop.md 中有完整记录# 1. 选一个空闲端口 PORT 和本次协作 key BOARD_KEY # 2. 创建 Hive 数据目录 # BBS_CWDCodeRoot/temp/hive_目标短名 # 3. 启动 BBS start /b python CodeRoot/assets/agent_bbs.py --cwd BBS_CWD --port PORT --key BOARD_KEY # 4. 用 requests 访问 http://127.0.0.1:PORT/readme?keyBOARD_KEY 查看 API 说明从源码看--key会让 BBS 进入单板块模式BOARDS_FILENone以 key 作为板块名建库并通过ApiKeyMiddleware强制所有请求携带X-API-Key头或?key参数。核心 API 包括方法路径说明POST/register注册 agent 名返回token重复注册返回既有 tokenPOST/post发帖body 含token与contentGET/poll?since_id0limit50增量拉取id since_id的帖子用于轮询GET/posts?authorlimitoffset按作者/分页查询倒序POST/file/uploadmultipart 上传文件返回ref如a1b2c3/filename.extGET/file/{rand_id}/{filename}下载上传的文件启动后需要在 BBS 发出第一帖必须包含四项任务目标、Hive Master 职责全文一字不改、工作目录说明优先使用BBS_CWD传输文件、附加说明此为最终目标worker不要接单先等hive master拆分子任务。一字不改。6.2 goal_state.json预算与状态载体Master 的预算、状态与收口逻辑由 memory/goal_mode_sop.md 定义的goal_state.json承载{ objective: 用户原话目标, budget_seconds: 10800, start_time: 1757780000, turns_used: 0, max_turns: 200, status: running, done_prompt: }参数要点budget_seconds时间预算最少 3 小时10800 秒可按用户要求调整max_turns防空转上限一般 200 够用status必须为running启动命令为后台运行start /b python agentmain.py --reflect reflect/goal_mode.py可用--llm_no N指定第 N 个已配置模型。在 Hive 场景下memory/goal_hive_sop.md 对objective和done_prompt有更严格的约束objective必须包含四块缺一不可用户目标、BBS 地址http://127.0.0.1:PORT/readme?keyBOARD_KEY、Hive Master 职责全文一字不改、阅读 goal_hive_master_duty.md 的分派管理说明done_prompt必须设置为固定文本一字不改关闭所有你拉起的worker并在BBS发一条帖子宣告你管理的任务结束worker除了明确追加任务外不应再回应。启动 master 前必须回读goal_state.json逐项确认 objective 完整、done_prompt 原文匹配否则不得启动——这是把锁边界、校准 Ĵ落到基础设施层面的体现。6.3 与调度系统的衔接仓库中还有 reflect/scheduler.py 的定时任务调度器它与 Hive 是并列关系而非替代scheduler 负责按sche_tasks/*.json的repeat/schedule/max_delay_hours触发定时任务并写报告到sche_tasks/done/而 Hive 模式单独运行、不与 plan/supervisor/subagent 混杂memory/goal_hive_sop.md 明确要求。理解这一边界有助于在实际部署时避免把 Hive Master 当作通用定时器使用。七、实践建议把 SOP 变成可执行的检查单结合全文把 SOP 压缩成每轮循环的核对清单可直接作为 Master 的自检项探测轮x.1是否先锁边界要什么/明确不要什么再动手是否按四类切成独立调研子任务分头派发第 2 轮起是否只查变了/没查清的部分设计轮x.2changelog 是否逐条对准上轮检查报告的 P0/P1 缺口是否避开了已饱和维度执行轮x.3每个子任务是否有独立接口输入/输出/位置/合格线Master 是否没有下场亲自生产检查轮x.4是否覆盖五个视角用户/攻击者/边界/第三方/质疑目标每个挑刺任务是否交了与交付形态匹配的可复现证据P0/P1 报告是否已按对 J* 的伤害排序并写入检查报告Tx.md任何时刻是否清楚自己在x.几是否出现失稳信号worker 忙但 J 不升等出现即按五步急刹锚点是否只增不减验收 J 升才合入变差回退这套 SOP 的价值在于把多 agent 协作交付从玄学变成可测量、可回退、可收敛的控制过程Master 不做工、只调偏产物沿锚点单调逼近用户价值预算到点即交出当前最优版本。对希望复用 GenericAgent 多 worker 协作能力做长周期开放目标的开发者memory/goal_hive_master_duty.md 与本文梳理的配套实现memory/goal_hive_sop.md、memory/goal_mode_sop.md、assets/agent_bbs.py、reflect/agent_team_worker.py构成了一个可直接照做的完整闭环。【免费下载链接】GenericAgentSelf-evolving agent: grows skill tree from 3.3K-line seed, achieving full system control with 6x less token consumption项目地址: https://gitcode.com/GitHub_Trending/pc/GenericAgent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GenericAgent Goal Hive Master 调度 SOP 深度解析：以工程控制论驱动多 Worker 稳定交付
GenericAgent Goal Hive Master 调度 SOP 深度解析以工程控制论驱动多 Worker 稳定交付【免费下载链接】GenericAgentSelf-evolving agent: grows skill tree from 3.3K-line seed, achieving full system control with 6x less token consumption项目地址: https://gitcode.com/GitHub_Trending/pc/GenericAgent本文围绕 GenericAgent 仓库中 memory/goal_hive_master_duty.md 这一核心文档展开系统拆解 Goal Hive 模式下 Master 的职责边界、四阶段迭代循环、失稳急刹与底线纪律并结合 memory/goal_hive_sop.md、memory/goal_mode_sop.md、assets/agent_bbs.py 与 reflect/agent_team_worker.py 等仓库实现给出可直接落地的主从协作、BBS 通信与增量验收完整方案。一、Master 是谁只拆、只判、只汇绝不亲自生产Goal Hive 是 Goal Mode 的多 worker 协作协议见 memory/goal_hive_sop.md。在这个体系里Master 是 Hive 的总体设计部它的职责只有三类动作拆把阶段目标切成互不重叠的独立子任务派发给 worker判汇总产物后判断质量、排序优先级汇把多路产物收拢、整合、验收。Master不亲自生产子任务产物——一旦 Master 下场干活worker 就会空转整个调度体系失去意义。同时Master 无权停止自己不得设计自停条件它只能按预算推进直到用户给定的时间预算耗尽。这一职责边界在 memory/goal_hive_sop.md 的Hive Master 职责四条中进一步固化master 必须阅读记忆中 goal_hive_master_duty.md持续检查问题、寻找改进点只负责任务调度和团队组织不允许亲自干活导致 worker 空转终极目标是要做到完美的找不到任何问题的任务交付结果围绕核心产出如果子任务很多worker 做不过来可以拉起更多 worker。二、底层模型把交付当成受控系统SOP 从工程控制论的第一性原理推导出整套工作方法。核心符号只有四个J*用户真正要的价值目标/价值函数哲学层不变ĴMaster 对 J* 的形式化估计——会变需要持续校准y当前产物e偏差e J* − y。每一轮的实际工作就是测 e、压 e让 y 单调逼近 J*预算到点就交出当前最好的 y。所谓失稳就是系统跑偏或空转详见第四节。这个模型的关键启示是Master 的核心职责不是做得多而是把 J* 与 y 之间的偏差测量准确、压缩到位。因此 SOP 反复强调两点锁边界先于动手钉死 J* 范围——要什么、明确不要什么需求模糊或有歧义例如接入是只收还是收发时按最小必要 简单优雅收敛或向用户澄清禁止臆测扩张 scope校准 Ĵ 而不只校准 y检查阶段要回头质疑目标本身看 Ĵ 是否做多、做偏、过度设计如造了需求不要的能力。三、怎么跑三条铁律与四阶段循环3.1 三条铁律铁律一只拆只汇。Master 只做拆切子任务和汇汇总、判断、排序绝不自己下场生产产物。铁律二锚点只增不减。始终维护一个当前最优已验收版本作锚点每轮只在锚点上做增量改——在已有产物上找可优化点修改能不重写就不重写。验收让 J 升才合入变差就回退。铁律三循环到预算用尽才停。交当前锚点版不是做完才停。任何时刻必须清楚自己在x.几这个阶段。一轮的标准节奏是探测 → 设计 → 执行 → 检查 →重读本 SOP→ 下一轮。其中探测/检查是发散求全靠多 worker 并行、独立、去相关地铺开设计/执行是收敛择优Master 判断、择一、忠实落地。3.2 x.1 探测查得尽量全阶段目标是查得尽量全查五类内容分析用户需求探测环境现状记忆中的重要信息/原则调研可用的方案、材料、方法建议上轮的结果、变化、检查报告。操作上先锁边界校准 Ĵ → 按需求、环境、记忆、方案四项切成独立调研子任务分头派多个 worker→ 收齐后按对 J* 的重要性排序 → 写探测报告Tx.md只留重点和变化。从第 2 轮起只查上轮变了/没查清的部分不重查环境一变就重探变化的部分。3.3 x.2 设计收敛出最优那一个方案这一阶段Master 亲自做没什么可并行。依据探测报告 上轮检查报告决定这轮改哪几处、拆几个执行子任务、各自的验收线。产出执行方案Tx.md内含changelog这轮要改的 P0/P1 清单——来自上轮检查报告逐条对准缺口不在已饱和处精雕。3.4 x.3 执行忠实落地选定方案拆每个执行子任务都定义成独立接口输入/输出/放哪里/合格线派给 worker能并行就并行汇Master 不下场只盯进度、收产物、按 changelog 增量改锚点。这里与仓库的 worker 拉起机制直接对应。在 memory/goal_hive_sop.md 中worker 的启动命令为start /b python CodeRoot/agentmain.py --reflect CodeRoot/reflect/agent_team_worker.py \ --base_url http://127.0.0.1:PORT --board_key BOARD_KEY --name hive-worker-1后续 worker 由 Master 按需增加不能超过 5 个一般任务 24 个足够。worker 侧的接单逻辑实现在 reflect/agent_team_worker.pycheck()会轮询 BBSGET /posts?limit10带X-API-Key头无新帖返回None不唤醒 agent连续失败 10 次则/exit有帖子后按_prompt()的规则接单先看新帖、找适合接的任务帖、回复抢单、确认是最早接单后执行完成后发帖汇报结果长结果使用文件并严格区分交付结果与报告信息特别强调master 的说明性帖子要求 worker 不要接单的不要接单——这正是 memory/goal_hive_sop.md 第一帖规范中worker 不要接单先等 hive master 拆分子任务的落地。3.5 x.4 检查挑出尽量多的问题检查阶段要从多角度派独立的挑刺/测试子任务给不同 workerSOP 给出了五个必做视角用户视角试用攻击者/反面假设边界与 corner case测例尽量多、全、广第三方独立复核回到需求质疑目标本身对照 J* 看 Ĵ 是否做多/做偏/过度设计。验收线是硬性的每个挑刺/测试子任务必须交可复现的物理证据且证据形态匹配交付形态——代码要端到端跑通的命令 原始输出不止单元桩测文稿要全文通读 按需渲染/视觉核对版式数据要实跑校验。声明已完成不算验收。汇总后按对 J* 的伤害排成 P0/P1写检查报告Tx.md。这份 P0/P1 报告就是下一轮 x.2 的 changelog——偏差e J*−y被具体化带进下一轮增量修形成闭环。这一监察哲学在仓库中也有独立实现 memory/supervisor_sop.md 定义监察者模式——先定行动协议再盯协议偏离最后看完成证据监察者只读探测、一句话干预、禁止下场干活与 Master 检查阶段的验收纪律证据必须可复现、与交付形态匹配一脉相承。四、失稳急刹六个信号与五步处置SOP 明确列出六种失稳信号出现任意一种立即按序处置信号worker 忙但 J 不升 / 局部产物多但整体不可用 / 过程证明取代用户价值 / 多人改同一产物冲突 / Master 被细节牵走丢全局 / 额外产出污染核心交付。处置顺序不可跳步停止新派发回读用户需求与 J*重新对齐现在最重要的一件事查接口是否未冻结砍掉与主目标最弱的在途任务某维度连续两轮 J 不升即判饱和换到离达标最远的维度恢复闭环再派。其中接口未冻结的检查对应执行阶段的子任务接口设计输入/输出/放哪里/合格线——接口一旦被并发修改多人改同一产物的冲突就会冒出来这正是失稳的典型来源。五、底线纪律交付、诚实与整洁SOP 的最后一部分是四条不可逾越的底线成品与过程分离核心产物只放用户要用的成品说人话、给成品、取舍随场景来源、验证、尝试记录另放不污染成品不留半成品不确定性要么查证补全、要么删除自己搞定不推给用户诚实记录时间够就修到更优预算到点仍未通过的项必须如实写入交付报告。诚实记录写报告不写进成品本身BBS_CWD 保持整洁中间产物归子目录或带标注核心交付物一眼可定位。这与 memory/goal_hive_sop.md 中的工作目录约定一致——优先使用BBS_CWD进行文件传输而非 BBS 文件功能即把 BBS 当作消息通道、把本地目录当作产物仓库。六、落地环境BBS 与 goal_state 的配套实现要真正跑起一个 HiveMaster 依赖两套基础设施均在仓库中有完整实现。6.1 Agent BBS消息总线assets/agent_bbs.py 是一个极简 FastAPI 公告板是 Master 与 worker 的全部通信通道。启动方式与 API 在 memory/goal_hive_sop.md 中有完整记录# 1. 选一个空闲端口 PORT 和本次协作 key BOARD_KEY # 2. 创建 Hive 数据目录 # BBS_CWDCodeRoot/temp/hive_目标短名 # 3. 启动 BBS start /b python CodeRoot/assets/agent_bbs.py --cwd BBS_CWD --port PORT --key BOARD_KEY # 4. 用 requests 访问 http://127.0.0.1:PORT/readme?keyBOARD_KEY 查看 API 说明从源码看--key会让 BBS 进入单板块模式BOARDS_FILENone以 key 作为板块名建库并通过ApiKeyMiddleware强制所有请求携带X-API-Key头或?key参数。核心 API 包括方法路径说明POST/register注册 agent 名返回token重复注册返回既有 tokenPOST/post发帖body 含token与contentGET/poll?since_id0limit50增量拉取id since_id的帖子用于轮询GET/posts?authorlimitoffset按作者/分页查询倒序POST/file/uploadmultipart 上传文件返回ref如a1b2c3/filename.extGET/file/{rand_id}/{filename}下载上传的文件启动后需要在 BBS 发出第一帖必须包含四项任务目标、Hive Master 职责全文一字不改、工作目录说明优先使用BBS_CWD传输文件、附加说明此为最终目标worker不要接单先等hive master拆分子任务。一字不改。6.2 goal_state.json预算与状态载体Master 的预算、状态与收口逻辑由 memory/goal_mode_sop.md 定义的goal_state.json承载{ objective: 用户原话目标, budget_seconds: 10800, start_time: 1757780000, turns_used: 0, max_turns: 200, status: running, done_prompt: }参数要点budget_seconds时间预算最少 3 小时10800 秒可按用户要求调整max_turns防空转上限一般 200 够用status必须为running启动命令为后台运行start /b python agentmain.py --reflect reflect/goal_mode.py可用--llm_no N指定第 N 个已配置模型。在 Hive 场景下memory/goal_hive_sop.md 对objective和done_prompt有更严格的约束objective必须包含四块缺一不可用户目标、BBS 地址http://127.0.0.1:PORT/readme?keyBOARD_KEY、Hive Master 职责全文一字不改、阅读 goal_hive_master_duty.md 的分派管理说明done_prompt必须设置为固定文本一字不改关闭所有你拉起的worker并在BBS发一条帖子宣告你管理的任务结束worker除了明确追加任务外不应再回应。启动 master 前必须回读goal_state.json逐项确认 objective 完整、done_prompt 原文匹配否则不得启动——这是把锁边界、校准 Ĵ落到基础设施层面的体现。6.3 与调度系统的衔接仓库中还有 reflect/scheduler.py 的定时任务调度器它与 Hive 是并列关系而非替代scheduler 负责按sche_tasks/*.json的repeat/schedule/max_delay_hours触发定时任务并写报告到sche_tasks/done/而 Hive 模式单独运行、不与 plan/supervisor/subagent 混杂memory/goal_hive_sop.md 明确要求。理解这一边界有助于在实际部署时避免把 Hive Master 当作通用定时器使用。七、实践建议把 SOP 变成可执行的检查单结合全文把 SOP 压缩成每轮循环的核对清单可直接作为 Master 的自检项探测轮x.1是否先锁边界要什么/明确不要什么再动手是否按四类切成独立调研子任务分头派发第 2 轮起是否只查变了/没查清的部分设计轮x.2changelog 是否逐条对准上轮检查报告的 P0/P1 缺口是否避开了已饱和维度执行轮x.3每个子任务是否有独立接口输入/输出/位置/合格线Master 是否没有下场亲自生产检查轮x.4是否覆盖五个视角用户/攻击者/边界/第三方/质疑目标每个挑刺任务是否交了与交付形态匹配的可复现证据P0/P1 报告是否已按对 J* 的伤害排序并写入检查报告Tx.md任何时刻是否清楚自己在x.几是否出现失稳信号worker 忙但 J 不升等出现即按五步急刹锚点是否只增不减验收 J 升才合入变差回退这套 SOP 的价值在于把多 agent 协作交付从玄学变成可测量、可回退、可收敛的控制过程Master 不做工、只调偏产物沿锚点单调逼近用户价值预算到点即交出当前最优版本。对希望复用 GenericAgent 多 worker 协作能力做长周期开放目标的开发者memory/goal_hive_master_duty.md 与本文梳理的配套实现memory/goal_hive_sop.md、memory/goal_mode_sop.md、assets/agent_bbs.py、reflect/agent_team_worker.py构成了一个可直接照做的完整闭环。【免费下载链接】GenericAgentSelf-evolving agent: grows skill tree from 3.3K-line seed, achieving full system control with 6x less token consumption项目地址: https://gitcode.com/GitHub_Trending/pc/GenericAgent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考