三个系统 · 十一类架构 · 一本真账
Auto、军团、马甲虾不是三个平行产品，而是同一目标的三层：能力来源、运行底座、内容运营。这一版把工具、搜索、循环、Pilot、Hook、自监督、自进化、协作、上下文、经验组件与 Trace 全部摊开，能复用的和已经断掉的都写。
| 系统 | 代码规模（实测） | 最值得复用的资产 | 当前真实状态 |
|---|---|---|---|
| Auto能力层 | 199 个 py 72,318 行 98 + 143 个测试文件 |
34 路搜索源、证据与验证链、GAIA 账本口径、上下文账本与检查点 | 引擎已退出答题、接力与首脑竞选，保留为 capability 与工具库 |
| 军团底座层 | 146 个 py 63,442 行 333 个测试文件 |
工具生态、调度内核、项目现场、产物交付、验收账本、设备层 | 正式环境部署 1 台并通过浏览器验证；全员逐家验证未完成 |
| 马甲虾内容层 | 8 个 py 1,034 行 另有 10 个内容模块 |
8 套人设、画像到内容生产八环链路、1,875 话题与 240 条胜出模式 | 8 个沙箱全部离线，服务停摆约 3.5 个月 |
真正可迁移的是军团整套运行底座，加上 Auto 的能力组件与评测方法；马甲虾保留人设与内容链路代码，但不保留“在线服务”这个假设。
每块都按“真实文件、真实常量、真实断点”写。点进去看细节；没有代码支撑的说法不放进索引。
军团只做检索与执行，不把工具硬塞进每家 prompt。新装或锻造的工具，下一次检索立即全军团可见。
| 层 | 真实实现 | 规模与分类 |
|---|---|---|
| 清册层 | toolbox.py 1,083 行；三类来源归一进索引，TTL 3600 秒 | 22 类能力规则：生图、视频生成、视频编辑、音频、PDF 文档、视觉、搜索、浏览、数据、写作、代码、产品、Web 应用、工具发现、编排、自我改进、桌面、手机、规划、通用等 |
| 装备层 | arsenal_catalog.json | total 103 件，16 个 tier |
| 安装层 | install_registry.py，official / extension / user 三层注册 | 代码内置 28 条；dry-run 加白名单安装器 |
| 发现层 | capability_catalog.py 9 个 discovery 入口；capability_view.py 只读快照，TTL 600 秒 | media、search、file、web、ecosystem、toolbox 聚合视图 |
meyo_harnesses/skills.py 只读列出 skill；不路由、不绑定执行家。
list_skills / read_skillskill_matcher.py v9.6.18，九类能力：记忆学习、搜索研究、内容写作、代码运维、监控调度、生产力、创意媒体、市场数据、元社区。
SKILL_CATEGORIEStoolbox 缓存失效后，新工具下一次检索全军团可见。
invalidate_cachepeer source 映射把同伴源码路径与函数检索入口注入协议；成员可跨家搜函数、读同伴源码。
harness_registry.py:61内容侧 SkillNetwork 把成功帖子模式记录为 skill，分析后复用。
record_success / analyze_patterns没有“自动把某家 skill 注入另一家执行”的闭环；共享的是索引、路径与经验，执行仍归各家原生工具。
context not control随仓 skill 共 9 个目录：j-space、anysearch、web-access、multi-source-search、browse、browser-act、connect-chrome、open-gstack-browser、setup-browser-cookies。VENDORED_MANIFEST 声明 10 条，其中 last30days 没有对应目录，属于清单与实物不一致。
search_fabric 1,597 行加 verticals 2,529 行，是 Auto 最完整的一层资产，也是军团可直接复用的共享能力。
| 层 | 真实机制 |
|---|---|
| 来源层 | 9 个基座：ddgs、brave、wikipedia、sonar、sonar_pro、tavily、aisa_smart、aisa_verity、anysearch；25 个垂直：小红书、Reddit、Twitter、百度、HackerNews、CourtListener、OpenAlex、arXiv、Crossref、PubMed、PubChem、GDELT、MusicBrainz、Wayback 两种、Archive Today、Blogspot、Wikipedia Links、Wikidata、浏览器历史、内部 sh_ 五源等。去重后 34 个 |
| 路由层 | _route_query 用 LLM 读来源 schema 做语义路由；失败时 fail-safe 退回 tier 排序加 bandit 分数。BudgetManager 管 quota 与 bandit_score |
| 并发层 | ThreadPoolExecutor 加 as_completed，25 秒超时保留部分结果；缓存、quota、全局令牌桶、指数退避最多 3 次 |
| 归并层 | anysearch 优先的 merge order 加 dedup；结果不足 top_k 三分之一触发 fallback；每条 hit 固定 url、title、content、source、cost、meta，直接作为证据绑定 |
| 领域层 | domain_source_router 定义 31 个领域，先 classify 再 recommend_sources，最后 probe 可用性 |
换品类仍然成立的四件事：先判领域、并发取源、失败降级、结果绑定来源与成本。这套结构也是 research_pipeline 七阶段能力的底座。
蜂群解决“一个研究目标内的角色分工”，多跳解决“下一跳查什么”。两者都有固定角色、预算、停止条件与逐跳审计，不是自由群聊。
| 角色 | 职责 | 关键约束 |
|---|---|---|
| Planner | 选路由并拆子问题：simple、multi_constraint、ambiguous、multihop | 每个子问题必须有 claim、query、acceptance；多约束题另出消歧问题 |
| Scout | 多源发现候选来源，优先一手资料 | 只发现，不下结论 |
| Evidence | 深读候选，抽取可引用原文 | 只读证据，不脑补 |
| Skeptic | 主动找反例、时效风险、相反结论 | 反证单独记录，不并入支持证据 |
| Judge | 合并支持与反证，给可追溯结论与未解决项 | 只能用给定证据，不能用自身知识补充 |
| Coordinator | 只编排、报进度、写总线 | 不产出研究结论；换模型不换角色 |
| 层 | 真实文件 | 机制 |
|---|---|---|
| 第一锚点 | anchor_hop.extract_first_anchor_queries | 不搜整句；优先引号短语、专名序列、罕见约束组合，先锚第一个中间实体 |
| 分阶段检索 | staged_retrieval.py | Stage 1 用约 30% 预算搜最高特异度约束锁锚；Stage 2 到 3 用约 70% 顺藤补缺 |
| 锚点顺藤 | anchor_hop.py | 锚点乘缺口生成正向 query；五条铁律：确证锚点、复用闭包、grounding 自检、撒网才接管、每题最多 2 跳 |
| 身份覆盖 | identity_coverage.py | 四态 candidate、probable、confirmed、rejected；claim 覆盖率决定能不能交卷 |
脏锚门：path_working、unknown、none、占位词一律不当锚点；query 必须真的包含锚点 token 才发射，否则判为 hypothesis 丢弃。这解决“顺着错误实体越搜越远”的二次污染。
| 层 | 真实文件 | 机制 | 在防什么 |
|---|---|---|---|
| 采集 | entity_memory_bank.py | 工具结果落账当下抽实体，记出现次数与来源，存入会话实体库；带噪声词表与 HTML 清洗 | 事后从混杂日志抽不准 |
| 相关性 | entity_relevance.py | BM25 粗排候选段落，LLM 只精排 top-K：段落与每条约束 0 到 1 匹配加因果判断；圈选顺序为关联度、覆盖率、频次 | 部分匹配但更有名的错实体被选上 |
| 约束与证据 | identity_coverage.extract_claims 与 compute_coverage | 把题面拆成 claim，逐条统计证据覆盖；支持 LLM 语义覆盖，失败退回规则 | 布尔覆盖把“提到过”当“满足” |
| 四态判定 | identity_coverage.classify_state | 任一约束被证据矛盾直接 rejected；覆盖率大于等于 0.80 且多源才 confirmed；覆盖足但单源是 probable；0.40 到 0.80 是 probable；否则 candidate | 锁错实体、单源冒充确证 |
| 软锁 | identity_coverage._is_strictly_better | 已确认候选不被抖动替换；只有覆盖率明显更高且覆盖约束数不减少才换；收尾软锁 probable 优先于元评论与空 | 收敛时把正确实体换掉 |
| 防漂移 | entity_drift_lowconf_guard.py | 比对最终答案断言的实体与已确证集合，漂出就告警并回退；同时检测低置信措辞与置信数值 | 中间确证被覆盖、自认没把握仍硬交 |
| 特征反查 | feature_to_entity.py | 数值与属性特征转结构化查询（MusicBrainz lucene、Wikidata SPARQL、Crossref 年份作者），无结构化源时用 LLM 做特征到实体联想 | 6 shots、BPM 194 这类特征无法用全文关键词反查 |
只有两类锚点能驱动多跳：已确证实体，或关系节点。实体库是会话级的，不跨任务共享；四态与覆盖率是证据判定，不是真值判定；软锁只防覆盖，不保证候选正确。
load 小于 8 全并发；8 到 15 降到 2 路；大于 15 串行 1 路。简单题只深爬 top 3。
MEYO_SWARM_MAX_LANES七类节点：planner、fanout、dork、discovery、supervise、reflect、rescue；四种跳条件；支持并行与回环。
search_dag.py 548 行每次搜后判 is_sufficient、confidence、missing、next_action；四选一 stop、search_more、switch_source、dig_deeper。
search_supervisor.py 325 行DAG 管单次怎么编排，Supervisor 管一轮够不够，HopJudge 管跨跳要不要继续。
各管一段HopJudge 调用失败时直接判 sufficient，宁可单跳收口，不空转烧预算。
fail-safehop_record 记录 queries、new_hits、total_hits、hop_judge、stop_reason，可直接验证多跳真的发生。
agent_comm| 循环 | 入口与真实常量 | 终止条件 |
|---|---|---|
| 单 agent 迭代 | native_agent_loop 第 4,844 行；max_steps 30、ceiling 600、绝对墙钟 900 秒 | 步数、墙钟、连续错误 3 次收敛、预算耗尽；可申请续预算 |
| Auto 预算循环 | qa_auto_agent 默认硬墙 600 秒；可续 0.5 倍到 2,400 秒，加 20 步；软墙提前 12% 收尾 | 硬墙、续预算上限、无进展 |
| 军团自愈换模型 | run_one 的 attempt 循环；重试环境变量默认 0，表示不设固定次数、模型池耗尽才收敛 | 模型池耗尽、任务 deadline、跨方向兜底成功 |
| DAG 依赖波次 | _dependency_waves 用 Kahn 分层；有环时贪心断边并注入事实 | 所有任务终态，不判死 |
| relay 串行流水线 | _dispatch_relay 按 pipeline 或任务键顺序执行，上一步 final 全文传给下一步 | 最后一步完成；无父层总墙钟 |
| 跳间判决循环 | 蜂群专用：每跳后问 HopJudge，只有“证据不够且有具体缺口”才继续 | sufficient、max_hops 3、连续两跳零新增 |
另有两类定时：cron_jobs 只做登记与过期，没有常驻调度器；内容侧 evolve_loop 支持 forever 每 10 分钟一轮。后台扫描两处 deadline 分别为 1,800 秒与 3,600 秒。代码里不存在 loop_events 结构，只有 events.jsonl。
| 版本 | 真实实现 | 判定与续航 |
|---|---|---|
| Claude Code hook 版 | tools/pilot_v2/pilot_v2.py；四个事件 session-start、user-prompt、post-tool、stop | phase 为 understand、implement、verify、deliver；stop 可 block；最长续航 12 轮，空转 2 轮暂停；状态按 session 哈希落到独立目录 |
| 军团版 | pilot_kernel 加 legion_pilot；入口 pilot_check；输入契约 _pilot_run_state | intensity 为 focused，scope 为 query；判 done、blocked、waiting、delivered；delivered 必须有交付物证据，防短答误判 |
| 旧版残留 | memory gates 下 20 余个旧 hook 文件 | 存在但未注册，已被 v2 取代 |
Pilot 的核心不是“无限续命”，而是区分四种状态：用户要决策就停、真阻塞就停、等待外部就停、只有“还能做且没交付”才继续。状态本身落盘，换会话可恢复。
| Hook | 触发 | 作用 | 阻断 |
|---|---|---|---|
| pilot_v2 | SessionStart、UserPromptSubmit、PostToolUse、Stop | 目标注入、续航状态机、stop 拦截 | 只有 Stop 可 block |
| Codex hooks | SessionStart（startup 或 resume） | 仅 jcode 热键 | 否 |
| qa_loop_hooks | thin loop 每步 | anchor、no_progress、converge、context_ledger、finalize_hints 五个 pre_step，加 readiness 的 turn_stopping | 否，仅提醒 |
| on_correction | CLI 手工 | 用户纠正写入 corrections.jsonl | 否 |
| write_to_km | CLI 手工 | outputs 写入学城子页 | 否 |
final 质量检查、记忆轨迹检查、墙钟 watchdog。
native loop只读索引、账本、行动层：持久任务、修复、分级复验、发布门收口。
verification_*复杂任务审需求满足、正确性、可用性；简单任务跳过。
success_auditor改动后自动关联检查加安全 smoke。
harness_selfcheck原始目标、研究证据、强 MVP、跨轮差距四类事实并列，不做单一总判决。
quality_context安全边界可以硬，产品质量策略必须软；不加阻断式质量门。
context not control| 机制 | 真实状态 | 输入到输出 |
|---|---|---|
| delivery_knowledge | 真实在跑，唯一完整的交付经验闭环 | capture 在 world_class 交付收尾收割锚点表、证伪死路、桂冠参照；match 按品类命中；inject 进派单前置。单品类上限 40 条，种子 2 条 user_verified |
| skill_mining | 真实存在，但需要显式确认 | 从会话记录找重复命令，生成 skill 候选，确认后固化，不是全自动 |
| 内容侧进化 | 真实存在，但服务已停摆 | 七阶段每 10 分钟；事件驱动编排；每小时看 CTR gap 生成策略并应用 |
自进化不能靠“名单上有几个 evolver”证明，只能靠“这次交付是否真的复用了上次经验”。当前唯一可验证的闭环是 delivery_knowledge。
多成员同跑一个 DAG 的一致性与防迟到覆盖。
team_state.py:223每步 append-only，终态后可重放，10 种以上事件。
events.jsonl默认最强单家直答，多人才选首脑。
elect_captain运行中换帅，每次 dispatch 限一代防循环。
handoff_captain成员主动向同伴要输入，父层只放邮箱不代答。
mailbox首脑拆子任务给新 worker，同迭代 join，继承项目现场。
_fork_worker验证判修改后重建，锚点 revision 必须一致才通过。
_select_revision_owner一家用尽 attempt，带完整失败上下文转交另一家。
_dispatch_relay真实输出、报错、工具动作原样喂下一轮，不教手段。
_build_failure_context崩溃后 lease 过期任务可被领取续跑。
recover / claim_resume危险能力需要用户批；用户级 handoff 可恢复。
approval_state补充事实直达 cc 原生输入，绑定四元组，fail-closed。
cc_live_mailbox相似问题召回历史经验。
experience.jsonl每 task 的工作目录、产物、工具状态。
task_memory另一条容易被忽略的规则：DAG 依赖默认要求前序成功，不把“进程结束”当成“依赖成功”，避免空输入编造。有环时不断死任务，而是贪心断边并注入事实。
蜂群解决“一个研究目标内的角色分工”：固定五角色、单目标、按跳收敛、逐跳留痕。军团解决“多个独立任务之间的编排”：按 DAG 波次、可换 owner、可接力、可换届。把两者混成一个“大群聊”，会同时丢掉审计和收敛——既说不清谁对结论负责，也说不清什么时候该停。
项目现场用 packet 做单一事实源，派单上下文分六层注入，接棒从现场取，不靠记忆。
| 层 | 内容 | 怎么进 | 预算与边界 |
|---|---|---|---|
| L0 目标与验收 | 原始问题、范围、验收标准 | 每轮都在，置顶 | 压缩时最后丢 |
| L1 项目现场 | project_context packet：目标、DAG、证据、产物、锚点、验证 | snapshot 注入 | 单字段 4,000 字符，每类最多 80 项 |
| L2 证据与引用 | Atlas 短索引（URL 加目录）、evidence_digest、原始 URL | 先给索引，正文按需回访 | 不丢原始 URL |
| L3 会话与轮次 | 会话历史、每家自己上一轮产出 | 每家只认自己的 | 每条 1,200 字 |
| L4 各家私有 | 自己上一轮输出、失败现场 | 只进对应家 | 不跨家广播 |
| L5 全量日志 | tool_log、loop_events、完整 events | 不直接进 prompt | 只落盘，按需查 |
五层是事实源，上面那六个 flow-step 是注入顺序。设计要点：L5 只落盘，L2 先索引，L3 分家，L4 不串门。
| 位置 | 真实常量 | 行为 |
|---|---|---|
| Auto 上下文账本 | 3,000 字符，五类均分，每类最低 200 | GOAL、JOURNEY、CANDIDATE、EVIDENCE、FAILURE，可按类关闭 |
| 项目现场 packet | 单字段 4,000 字符，每类最多 80 项 | 超出裁旧，保留最近 |
| 每家上轮产出 | 1,200 字 | 只给自己的，不冒充 winner |
| 父成员成果 | 1,200 字 | 子任务继承父现场 |
| pending 与产物清单 | 12,000 字符 | relay 串行传递 |
| 失败回流 | 8,000 tokens | 头 50% 保留，其余按尾部保留，超预算丢最旧 |
| 蜂群 HopJudge | 22,000 字符 | 当前跳支持与反证摘要 |
原始目标与验收、项目现场 snapshot、证据与原始 URL、上一轮真实输出与失败现场、自己上轮产出、产物路径。
handoff / fork / revision全量 tool_log、别家私有上下文、密钥与凭据、未验证的中间猜测。
context 不是日志不带 project_context，新家会掉回空目录从零重做；三处调用点都已补。
project_context每家看到“你自己上一轮”，不是“全军团最佳产出”；后者会让别家抄 winner、丢自己的推进线。
per-key目标与验收置顶，压缩最后丢；失败 context 头尾保留，中间省略并预扣标记字节。
8,000 tokens不丢原始 URL；不全量日志塞 prompt；别家产出不冒充自己；缓存戳带目录维度。
四类污染| 组件 | 真实作用 | 来自哪类失败 |
|---|---|---|
| GAIA 账本与四类口径 | 单次基线、错题救回、累计最好、清账更正分开记录，禁止画成一条曲线 | 把不同执行路径混在一个能力结论下 |
| BrowseComp 重放器 | 保存完整轨迹、按 qid 重放、跳过搜索与 LLM 判题，专用于调试打捞与评分 | 超时与意图误判后无法复现 |
| first_anchor / anchor_hop | 先锁第一锚点再扩散，治“撒网锁错实体” | 搜得多但实体漂移 |
| evidence_graph / cross_verify | 候选必须绑来源，反证也记录 | 弱证据拼答案 |
| answer_vault / failure_memory | 答案仓保存已验证结论；失败记忆保存错误类型与触发条件 | 重复踩同一个坑 |
| entity_memory_bank | 在工具结果落账当下采集实体，防交接丢失 | 换 owner 后不认识原实体 |
| checkpoint_serialization | 只保留恢复必需字段，status 三态 | 崩溃后无法续跑 |
共同点：都在“证据”和“恢复”上，不在“替模型想答案”上。换品类仍然成立，这是可复用的原因。
| Trace 类型 | 内容 |
|---|---|
| Auto 检查点 | goal、triage、全量 tool_log、evidence_digest、final；status 三态 |
| Team 事件 | teams JSON 加 events.jsonl，含 meta、step、final、error、task_reopened 等 10 种以上事件 |
| 项目现场 | 目标、DAG、证据、产物、锚点、验证报告快照 |
| 任务记忆 | 每 task 的工作目录、产物、工具状态，4,880 项 |
| 任务产物索引 | 产物清单与来源绑定 |
| 深度计划 | 47 项计划与状态，用于循环重放锚点 |
| 会话交付物 | 1,129 个会话记录与导出目录 |
| 口径 | 数字 | 组成 | 适合回答 |
|---|---|---|---|
| 执行事件 | 269,561 条 | 军团 239,899 + Auto 循环 29,662 | “trace 到底多少条”最接近这个 |
| 可回放单元 | 3,053 个 | Auto 1,020 + GAIA 159 + team 746 + session 1,128 | 有多少份能独立打开的记录 |
| 纯 trace 文件 | 14,186 个 | 归档 14,009 + evidence 172 + 错题 5；GAIA 159 与 ckpt 零重叠 | 占多少文件 |
| 全部资产文件 | 37,772 个 | 纯 trace 14,186 + 交付物 23,586 | 整个记录与交付有多大 |
推荐对外说三句：执行事件 269,561 条；可回放记录 3,053 份；纯 trace 文件 14,186 个。1,020 只是 Auto 检查点文件数。工具步 10,692 与循环事件 29,662 是不同维度，不能相加；交付物 23,586 是产物，不是执行 trace。
1,020 是“多少个检查点”，不是“多少条 trace”。完整账本还包括 GAIA 165 题主账、BC 主账 21 题 110 attempts、会话交付 1,129 个、产物索引 2,107 条、任务记忆 5,504 个文件、项目现场 255 个、开发证据 4,893 个文件。
| 来源 | 真实位置 | 真实数量 | 说明 |
|---|---|---|---|
| GAIA 主账 | evidence/ledgers/gaia_ledger.jsonl | 166 行；official 165；correct 164 | 官方题单口径 |
| GAIA 逐题轨迹 | evidence/gaia_correct | 159 文件 / 4.69 MB | 每题一份正确轨迹 ckpt |
| GAIA 错题语料 | v11/.gaia_100miss_traces | 5 文件 / 241 KB | 100 道错题的重放样本 |
| BC 主账 | evidence/ledgers/bc_ledger.json | 21 题 / 110 attempts | 另有 v11 子账本 4 题 8 |
| BC 逐题轨迹 | attempts.trace_path | 0 条 | 真实缺口：账本没记 trace 引用，回不到当时轨迹 |
| Auto 检查点 | ~/.meyo/users | 1,020 文件 / 10,692 步 | 每题一份 ckpt |
| 军团事件 | ~/.meyo/legion/teams | 746 team / 239,899 条 | step 占 99.4% |
| 交付物 | ../deliveries | 23,586 文件 / 3.98 GB | 9 份 file-manifest，单份 1,500 条以上 |
| 交付证据 | evidence 与 evidence-player-finish | 12 文件 / 11.6 MB | 真实操作截图与验证记录 |
| 开发证据 | dev | 4,893 文件 / 211.9 MB | json 3,490、md 388、png 211、py 204、sql 182 |
| 内容运营 | tracking 与 ctr_live | 819 次记录 / 412 条 feed | 内容侧回流数据 |
| 运行时归档 | dev/trace-archive-20261018 | 14,009 文件 / 897.5 MB | 只含运行时记录，不含交付物 |
按“所有 trace 资产”算，是 14,009 个归档 + 23,586 个交付物 + 172 个 evidence，合计约 37,767 个文件、约 4.9 GB。1,020 只是其中最核心的 Auto 检查点数；之前把它当“trace 总量”，口径错了。
只看“七类文件”不够。真实 trace 按四个维度交叉读：先定位问题，再进具体文件。以下分布来自 1,020 个真实 Auto 检查点。
| 维度 | 真实分布 | 回答什么 |
|---|---|---|
| 类型 | 执行轨迹 1,020 个文件 / 10,692 步；事件流 746 个 team / 239,899 条；评测账本 BC 主账 21 题 110 attempts（v11 子账本 4 题 8）加 GAIA 165 题主账；会话交付 1,129；产物索引 2,107；计划 47；项目现场 255 | 怎么走、谁协作、对错、用户拿到什么 |
| 场景 | task_level：琐事 466 / 重型 374 / 标准 152；search_route：no_search 483 / heavy 442 / verify 67；intent：concept 656 / process 213 / decision 79 / methodology 44；backend：native 1,003 / deepagents 15 | 哪类任务最容易出问题 |
| 步数 | tool_log：0 步 298 / 1 到 5 步 344 / 6 到 15 步 147 / 16 到 40 步 168 / 40 步以上 63；done 中位 2 步，p90 20；非 done 中位 15 步 | 没启动、正常完成，还是空转 |
| 效果 | done 797（78.1%）/ running 212（20.8%）/ interrupted 11（1.1%）；空 final 177（17.4%） | 交付是否真的发生 |
循环事件也补一个纠正：1,020 个检查点全部有 loop_events 字段，共 29,662 条（done 平均 22.1、running 56、interrupted 19.5）。旧说法“代码里完全没有 loop_events”不准确；准确说法是“检查点里有这个字段，军团内核没有同名结构”。
归档包：dev/trace-archive-20261018/legion-trace-full-20261018.tar.gz，附 manifest.json。归档前已排除 lock 文件；包含真实会话与产物索引，属于内部运行记录，不对外公开。单条 trace 查看走只读查看器，只放行受控目录，防穿越。
Auto 的真实价值在“搜得全、留得下证据、账算得清”。它退出答题池是架构选择，不是能力否定。
BrowseComp 旧报告为 2 道有效题 0 正确，单题 390–442 秒，第 3 题超时；公平 40 题口径 2/40 → 6/40，但前后模型、预算与包装记录不一致，不能宣称三倍提升。
146 个 Python 文件、63,442 行，按职责分七层。每一层都对应一个真实断点，而不是为了架构好看。
它确实跑通过一次社区冷启动，也留下了完整的八环链路代码与真实数据。今天它不在线，这件事同样要写。
结论：马甲虾的真实价值是“人设资产加链路设计加历史数据”，不是“现在还能自动生产内容”。下一步要么补齐链路并重跑一条真实发帖到反馈的闭环，要么把链路并入军团内容工作流，不再单独运维沙箱。
multi_puppet_runner 按 3 线程并行派发，选题做事件级饱和度去重，避免同一事件被多只虾重复写。8 只虾是角色池，不是 8 个同时在线；当前 8 个沙箱全离线，这套并行只存在于代码与历史记录里。与研究蜂群的区别：内容蜂群共享热点与选题池，不共享一条证据链；研究蜂群共享同一目标与证据，按跳收敛。
| 范围 | Python 文件 | 行数 | 说明 |
|---|---|---|---|
| release | 979 | 262,112 | 军团与发布层 |
| seed-users-system | 631 | 183,959 | Auto、v11、内容引擎 |
| dev | 204 | 20,826 | 证据、工具与实验 |
| sandbox | 8 | 1,034 | 马甲虾管理面板 |
| tools 加 scripts | 11 | 2,381 | Pilot 与运维脚本 |
| 自有合计 | 1,833 | 470,312 | 不含他人 harness 源码 |
| harness_baselines | 10,367 | 3,873,772 | 第三方 harness，用于学习与对照 |
| 全仓合计 | 12,240 | 4,350,050 | 含第三方源码 |
单文件规模：legion_core 10,810 行、qa_auto_agent 10,087 行、native_agent_loop 6,132 行、server 4,729 行、index_v2 4,127 行、search_fabric 1,597 加 verticals 2,529 行。全仓 test 开头文件 5,853 个，markdown 13,509 个。对外只说自有 470,312 行，避免把别人的源码算成自己的。
| 要做什么 | 直接拿什么 | 不要拿什么 |
|---|---|---|
| 多 Agent 运行底座 | 军团全目录：调度、状态、交付、验收、设备五层 | 不要重写 server 与 team_state；不要绕过 artifact_delivery 自己拼下载 |
| 工具与搜索 | toolbox 四层、legion_tool、34 路搜索源、research_pipeline | 不要再造第五套搜索；不要引用不存在的 skill_factory |
| 循环与续航 | native loop 常量、run_one 自愈循环、DAG 波次、pilot_v2 | 不要把旧行号当现状；不要恢复已删除的五个 evolver |
| 自监督与验收 | verification 三件套、success_auditor、harness_selfcheck、quality_context | 不要加阻断式质量门；不要用单一总分覆盖过程 |
| 协作与上下文 | team_state、project_context、六层派单、上下文账本 | 不要把完整日志硬塞进 prompt；不要丢原始 URL |
| Trace 与复盘 | 七类归档包加 manifest、只读查看器 | 不要把内部会话公开；不要把 lock 打进包 |
| 内容运营 | 人设、画像链路、审核与反馈代码、1,875 话题与 240 条胜出模式 | 不要保留明文密钥；不要假设沙箱在线 |
完整方案定方向与阶段，AI 原生社区定关系语义，创作经济定供给与成本，开工指令定这一轮做什么。总账只回答：现在有什么、能证明什么、下一步先做哪件。
| 文档 | 它定什么 | 我的理解 |
|---|---|---|
| Meyo 完整优化方案 | 方向、S0 到 S4、多 Harness 主体定义、生态纳入 | 主线。总账里的军团底座与交付证据，对应 S0 与 S1 的“可用作品版本”。主体是多个完整 Harness，不是平台拆出的被动子 Agent。 |
| AI 原生社区 | 关系语义：目标到参与、行动到执行、版本到贡献、派生到来源、工具到使用 | 解释“为什么协作记录要可追溯”。team events、产物来源、版本记录就是这些关系的原始事实；先投影，不新建全量关系图平台。 |
| 创作经济循环 | 先试玩、再私有云版本、再 AI 原项目续改；三种循环；成本口径 | 交付形态与成本口径。artifact_delivery、project_context、知识库支撑这条路径；成本按被接受且实际使用作品的完整成本计。 |
| 下一次开工指令 | PQ0 到 PQ5 纵切、AgentGit 补充、生态核查顺序 | 这一轮的执行单。真实缺口（重型空交付 31.3%）应先于新功能；文档更新不启动模型、不安装、不发布。 |
重型空 final 117/374，31.3%；琐事只有 0.9%。先按四维读法逐单归因：0 步没启动、40 步空转，还是 running 未收尾；修完重放原旅程。
最大交付缺口选一件有真实使用人的成熟作品，固定版本、真实操作、两用户领取隔离、原项目改一项、交付入口与恢复证据。
先交可用旅程作品供给（许可/版本/运行包）、用户作品（试玩/私有/续改/使用）、平台能力（反馈/复用/验证/采用）。
先把一个作品做实目标到参与、行动到执行、版本到贡献、派生到来源、工具到使用；每条关系带来源事件、主体、版本、权限与时间。
先投影，不重造Omnigent 优先核查现有接线；Orca、Grok Bot、Multica 按许可与真实接口逐个验证。
登记不等于接通社区、经济、生态都建立在“用户真的拿到并继续使用一个作品”上。底座能交付单件，但全员稳定与重型空交付未过，所以 P0/P1 优先。
先有作品，再谈协作| 下一步 | 已有的底座 | 还缺什么 |
|---|---|---|
| P0 重型空交付 | trace 四维分类、失败回流、自愈循环 | 逐单归因与修复后的同题重放 |
| P1 作品纵切 | artifact_delivery、project_context、desktop 与 mobile、sessions | 两用户隔离领取、原项目续改的真实旅程 |
| P2 创作经济 | delivery_knowledge、research_pipeline、成本字段 | 运行包标准与完整成本账 |
| P3 社区关系 | team_state、events、产物来源 | 关系投影与权限范围 |
| P4 生态接入 | 38 条成员登记、external registry | 逐家真实接口与许可 |
可复核入口