真实脚本构建 E2E 调试报告（2026-07-20）

1. 结论

本轮已经补齐并实际验证了两个硬门槛：

Host 可以通过内部测试专用 Runtime Factory 使用真实 Qwen、真实 AgentRunner、持久化 TraceStore 和明确的内部 Principal/Auth 运行；非 test 环境会 fail-closed。
Script Build 的 16 个 Planner、Worker、Validator preset 都有完整、可冻结的模型配置。

第三个硬门槛——“真实旧版输入 → Qwen → Phase 1/2/3 → MySQL 原子发布 → 旧 detail API 回读”——尚未完整通过。目前真实链路已经稳定推进到：

真实旧版输入 → Phase 1 → Direction ACCEPT/发布 → Phase 2 → Structure Worker → Structure Validator passed → Structure ACCEPT → Paragraph 规划

Paragraph 之后的 Compose、CandidatePortfolio、Phase 3 Root、Final UoW 和旧 detail 回读还没有在同一条真实运行中全部通过。因此当前不能宣称“真实 E2E 已完成”。

用户明确要求暂不做数据库账号/权限隔离，本轮没有扩大该范围。

2026-07-20 推送前补充：最新全量回归发现 Host 有 7 项失败，详见第 6.1 节。这些失败尚未修复；用户随后明确要求停止测试、记录现状并提交推送。因此本报告和对应代码只能作为有已知失败的调试交付，不能视为发布门禁通过。

2. 本轮测试输入和停止状态

真实输入来源：上一代 MySQL 数据，而不是 fake fixture。
脱敏输入身份：execution_id=50、topic_build_id=230、topic_id=400、 account_name=创业邦。
模型：通过百炼 OpenAI-compatible endpoint 调用配置的 Qwen 模型。
模型 thinking：关闭；请求具有 300 秒超时和 2 次 SDK 重试。
本地持久化：.local/agent-data 下的 Trace、Task Ledger、Artifact、owner lock 和 E2E report。
MySQL：经本地 127.0.0.1:13306 的受管隧道连接真实输入/测试输出库。

收到停止指令后已执行：

终止正在运行的 900022 E2E 进程；
调用 900022 的正式 stop API；
stop API 返回 stopping，stopped_operation_ids=[]；
900022 的 stop/fence 意图已经持久化，不允许继续派发新工作；
E2E CLI 写出失败报告 .local/agent-data/e2e-reports/20260720T081451Z-8233aee0.json。

这里的 stopping 而非 stopped 是一个需要继续修的恢复问题：原 Planner 所在进程先被终止，另一个临时 Host 可以写 stop/fence，但不能等待已经消失的进程内 Planner Task 正常收尾。它不代表模型仍在后台运行；当前没有 internal_e2e 进程。

3. 三个硬门槛的当前状态

硬门槛	当前状态	已有证据	剩余工作
真实 Runtime Factory + Auth	已实现，针对性测试通过	真实 Qwen tool-call smoke 成功；内部 Runtime/Auth 测试通过；非 test 环境 fail-closed	最终全量门禁
16 个角色模型配置	已实现，针对性测试通过	manifest 覆盖 16 个 preset，Validator/Worker 温度和迭代上限可冻结	最终全量门禁
可执行真实全链路 E2E	部分通过	真实输入、Phase 1、Direction、Phase 2 Structure 已跑通	Paragraph→Compose→Portfolio→Phase 3→MySQL final→legacy detail

16 个 preset 为：

script_planner
script_direction_worker
script_pattern_retrieval_worker
script_decode_retrieval_worker
script_external_retrieval_worker
script_knowledge_retrieval_worker
script_retrieval_validator
script_candidate_validator
script_structure_worker
script_paragraph_worker
script_element_set_worker
script_candidate_compare_worker
script_compose_worker
script_candidate_portfolio_worker
script_root_worker
script_root_validator

4. 真实运行中发现的问题、修复和验证

4.1 Runtime 和模型接入问题

问题：Host 缺少可直接执行的真实内部 Runtime Factory

此前生产装配要求外部注入 Runner、PrincipalProvider 和 BuildAuthorizer，但项目内没有一条可以直接运行真实 Qwen E2E 的内部装配路径。

修复：

新增内部测试专用 Runtime Factory；
注入真实 AgentRunner、Qwen LLM call 和 FileSystemTraceStore；
注入显式内部 Principal 和 Authorizer；
仅允许 environment=test，其他环境直接拒绝启动；
API Key 只从 Secret settings 读取，不写入报告、Trace 或源码。

验证：内部 Runtime/Auth 针对性测试通过，真实 Qwen tool-call smoke 约 2.01 秒成功。

问题：Qwen thinking、超时和重试不可配置

默认 thinking 会显著增加工具型调用的延迟；SDK 没有项目级请求超时和瞬态失败重试。 900016 的真实运行遇到一次 provider InternalServerError，因为当时 max_retries=0 直接中断。

修复：

create_qwen_llm_call 新增 enable_thinking、request_timeout_seconds、 max_retries；
默认内部 E2E 关闭 thinking；
SDK 配置 300 秒请求超时和 2 次重试；
单次调用仍可以显式覆盖 extra_body，不会丢失调用方参数。

验证：Qwen Runtime options 单测和真实 tool-call smoke 通过。

问题：工具 schema 无法正确解析 postponed annotation / PEP 604 Union

真实 Runner 注册工具时，部分注解因 from __future__ import annotations 仍是字符串，以及 A | B Union 没有完整展开，导致模型看到的工具 schema 不准确。

修复：使用 get_type_hints 解析实际类型，并补齐 PEP 604 Union schema。

验证：Agent 工具 schema 新增针对性测试并通过。

4.2 E2E 驱动器问题

问题：轮询会无限容忍服务端 500

早期 E2E poll 把 mission endpoint 的 404/500 都当成“刚启动，继续等”，持久错误会表现成假卡死。

修复：只允许启动阶段前 5 次 404/500，之后立即暴露原始 HTTP 错误。

验证：

前 5 次失败、第 6 次成功的测试通过；
持续 500 在第 6 次直接失败的测试通过。

问题：CLI 只支持 start 新 build

当前 internal_e2e 每次都创建新 build，所以每发现一个后段问题，都要重新付出 Phase 1 和 Phase 2 前段的模型时间。

当前只完成了问题确认，尚未修复。详见第 7 节提速方案。

4.3 Phase 1 / Retrieval 状态语义问题

问题：把 `BLOCKED` 子任务误认为终态

900017 中 Retrieval 子任务被 Planner BLOCK 后，父 Direction 一直处于 waiting_children。Framework 中 BLOCKED 是可恢复状态，不会关闭父任务。

修复：

Planner policy 明确：不可用 Retrieval 必须 CANCEL，不能用 BLOCK 丢弃；
BLOCK 只用于 Host 定义的 Root phase boundary；
dispatch 在父任务仍有 blocked child 时返回稳定、可操作的 TASK_CHILD_BLOCKED，提示 CANCEL 或 UNBLOCK。

验证：blocked-child 不关闭父任务的针对性测试通过。

4.4 Validator 读不到当前候选的问题

问题：Candidate Validator 只能看到历史 evidence，看不到本 Attempt 的冻结产物

900018 中 Direction/候选 Validator 无法读取正在验证的 artifact，只能反复查询不相关的 evidence，最终既浪费 token 又不能形成可靠 verdict。

修复：

query_validation_evidence 返回 validation snapshot 中的 current_artifacts；
current_artifacts 是当前 Attempt 的精确冻结业务产物；
历史 Retrieval 仍通过独立的 current_evidence 返回；
Validator prompt 要求优先读取 current_artifacts，只有存在 raw artifact ref 才读取原图。

验证：候选 Validator 工具面和 frozen artifact 读取测试通过；后续真实 Structure Validator 已经用该路径给出 passed。

4.5 Budget 统计问题

问题：真实 Qwen 上下文超过旧的测试型 token 上限

Runner 会累计多轮 input/output token。原 Task 32k、Phase 2 2m 上限对真实工具型运行过低，正常验证也会被误判为 budget exhausted。

修复：

Task 上限提高到 1,000,000；
Phase 2 总上限提高到 10,000,000；
Planner 合同要求 max_tokens=1,000,000；
工具 schema 同步合法范围。

这不是要求模型必须消耗这些 token，而是防止 Host 用不现实的测试阈值误杀正常运行。

问题：执行时间把 Planner 等待时间算进 Worker/Validator budget

旧统计按最早 started 到最晚 completed 的墙钟跨度计算，多个阶段之间 Planner 思考和等待也被计费，导致尚未运行很久的 Task 被判超时。

修复：只累加每个 Attempt/Validation 自己的 completed_at - started_at 区间。

验证：跨两小时但实际阶段合计 20 秒的回归测试通过。

4.6 Phase 2 容器生命周期问题

问题：模型提前 dispatch 非执行态容器

900019 中 Planner 创建空 CandidatePortfolio/Compose 后立即 dispatch；这些容器在 adoption closure 为空时本来不可执行。随后模型试图 CANCEL 唯一 Portfolio，破坏 Phase 2 闭合路径。

修复：

Planner policy 增加严格的 7 步生命周期；
先建 Portfolio 和 Compose 容器，再完成本地候选；
Compose 通过 REVISE 写入精确 accepted decision closure 后才能 dispatch；
Portfolio 在 Compose ACCEPT 后用相同方式闭合；
Host 禁止 CANCEL 唯一 CandidatePortfolio；
容器不可执行错误改成可操作提示。

验证：唯一 Portfolio 不可取消测试通过；900020/900021 已不再出现提前 dispatch/cancel。

4.7 business scope 与 write scope 混用

问题：模型把业务输入闭包和候选写空间当成同一个 namespace

900020 中 Portfolio scope 没有与 accepted Direction 对齐，Compose/本地候选 scope 也没有正确嵌套；同时模型把业务 scope 当成 workspace 写路径，导致输入合同和 SQL workspace 分别失败。

修复：

Portfolio scope_ref 必须等于 accepted Direction scope；
Compose 和本地创作 scope 必须逐级嵌套；
内部整稿运行统一使用 write_scope=["script-build://writes"]；
prompt 和工具 schema 区分不可变输入兼容性与候选 SQL 写入 namespace。

验证：900021 已成功创建 scope 正确的 Portfolio、Compose 和 Structure。

4.8 Structure Worker 工具使用不收敛

问题：Structure Worker 不知道最短的 workspace 写入顺序

900020 中 Worker 在多个工具之间循环，消息数和 token 快速增长。

修复：Structure prompt 写明精确步骤：读取冻结输入 → 创建各 Paragraph shell → 检查 workspace → 保存唯一 Structure artifact → submit Attempt。Paragraph、Compose 和 Portfolio 也分别补了最短工具路径。

验证：900021 的 Structure Worker 收敛到约 22 条消息、约 33k token，并通过独立 Validator 和 Planner ACCEPT。

4.9 accepted Structure 与 Paragraph scope 不兼容

问题：错误合同直到 Worker 启动才失败

900021 中 Structure scope 为：

.../compose/candidate-1/structure/main

5 个 Paragraph 被规划为它的兄弟：

.../compose/candidate-1/paragraph/p1 等。

Paragraph 又把 accepted Structure 作为 immutable input，因此 producer/consumer scope 既不相等也不互相包含，必然触发 INPUT_SCOPE_MISMATCH。两个 Worker 已失败，另外三个也开始重复同一错误，所以该轮被停止。

修复：

Paragraph scope 必须等于或嵌套在 accepted Structure scope，例如 {structure_scope}/paragraph/p1；
在 PLAN、REVISE、SPLIT、DISPATCH 四个边界增加 accepted-input scope guard；
guard 同时检查 ACCEPT action、producer Task、expected task kind 和声明 scope；
无效合同现在会在启动 Worker 前失败，并给 Planner 可纠正的稳定错误。

验证：新增回归测试证明兄弟 Paragraph scope 在 Worker dispatch 前被拒绝；相关 32 个 Phase 2/Internal E2E 针对性测试全部通过。该修复尚未进行新的真实 Paragraph 运行，因为用户要求先停止并出报告。

4.10 900022 的状态

900022 使用同一真实输入重新启动，在收到停止指令时仍处于 Phase 1 Retrieval 阶段：Root 从 needs_replan 进入 waiting_children，3 个 Retrieval 子任务已开始。没有发现新的业务缺陷；该轮仅因调整测试策略而人工停止。

5. 运行批次记录

Build	推进位置	停止原因	对应动作
900001–900015	Runtime/E2E bring-up 的早期批次	均为人工取消；当前 JSON 报告只有 `CancelledError`，不足以可靠逐条还原	不对缺少证据的批次编造错误归因；其问题已按代码修复类别归入第 4 节
900016	Phase 1	百炼/OpenAI-compatible provider 瞬态 5xx，SDK 无重试	增加 timeout/retries
900017	Phase 1 Direction 等待 children	Retrieval 被 BLOCK 后父任务永远不闭合	BLOCK/CANCEL 语义和 dispatch guard
900018	Direction/候选 validation	Validator 看不到当前 frozen artifact；budget 偏小	`current_artifacts` + budget 修正
900019	Phase 2 容器创建	提前 dispatch 空容器，随后 CANCEL 唯一 Portfolio	7 步生命周期 + Host guard
900020	Phase 2 Structure	business scope/write scope 混用；Structure Worker 循环	scope policy + 精确 Worker 工具顺序
900021	Phase 2 Paragraph	Paragraph 与 accepted Structure 为兄弟 scope	四边界 accepted-input scope guard
900022	Phase 1 Retrieval	用户要求停止，切换为局部调试策略	已终止进程并写 stop/fence

所有 E2E JSON 都位于 .local/agent-data/e2e-reports/。这些文件被设计为本机运行证据，不应提交包含环境细节或大体积 Trace 的 .local 目录。

6. 已执行测试和当前可信边界

本轮已执行并通过：

Agent Qwen Runtime options + schema annotation：3 passed；
Host internal runtime/E2E/phase contracts/normalization：此前批次 28 passed；
Host phase agent tools/contracts/internal：此前批次 30 passed；
最新 Phase 2 contracts、agent tools、internal runtime、internal E2E：32 passed；
最新 scope/blocked-child/unique-portfolio 定向回归：3 passed；
Ruff 对最新 planning/test 修改：通过；
MySQL final publication 定向测试：4 passed、1 skip。该 skip 是用户明确暂缓的数据库账号隔离，不等于完整 MySQL release gate 通过。

真实运行已经证明：

能读取完整旧版真实输入；
能用真实 Qwen 进行工具调用；
Phase 1 能形成并接受 Direction；
Direction publication 和 Phase 2 continuation 可用；
能创建 Portfolio/Compose/Structure 的细粒度任务树；
Structure 能写候选 workspace、冻结 artifact、由独立 Validator 验证并 ACCEPT。

尚未证明：

修复后的真实 Paragraph Worker/Validator/ACCEPT；
Compose 对 Structure/Paragraph 的精确 closure 和结构化脚本生成；
CandidatePortfolio ACCEPT 和 Phase 2 checkpoint；
Phase 3 continuation、Root Worker、Root Validator、Root ACCEPT；
单事务 MySQL final publication 在这条真实运行上的成功；
publication/artifact pointer、branch0 canonical digest 和 legacy detail 的最终一致；
一条从 start 到旧 detail readback 的完整成功报告；
Agent/Host 全量测试、严格 mypy、compileall、完整 MySQL release gate 的最终一次统一通过。

6.1 推送前最新全量回归（已知失败，未修复）

在拆分本轮提交后、执行 push 前，实际运行了 Agent 和 Host 全量测试。结果为：

Agent：258 passed in 29.34s；
Host：201 passed, 5 skipped, 7 failed in 49.55s。

7 个 Host 失败分为两类。

第一类共 6 项，均为 scripted real-runner 的 phase boundary 回归：

test_real_runner_creative_exploration_order_does_not_choose_adoption_order 的 element-first、paragraph-first、structure-first 三个参数；
test_mission_service_real_runner_auto_continues_phase_one_to_phase_two_boundary；
test_historical_partial_advances_via_http_and_reenters_after_filestore_reload；
test_real_runner_phase_one_to_three_final_publication_and_legacy_readback。

直接表现是 run_phase_one() 期望 Root 停在 PHASE_ONE_CAPABILITY_BOUNDARY，但 scripted Planner 已继续执行 Phase 2，最终停在 PHASE_TWO_CANDIDATE_PORTFOLIO_READY， Host 因此抛出 ProtocolViolation: mission did not stop at the phase-one boundary。

已定位根因：本轮把 Phase 2 的完整七步说明及 PHASE_TWO_CANDIDATE_PORTFOLIO_READY 常量写进了所有阶段共用的基础 script_planner.md。scripted LLM 通过消息中是否出现该常量识别 Phase 2，因此在 Phase 1 就被错误激活。这不只是测试适配问题，也说明 Phase 2 指令没有严格隔离到 Host 的 signed policy continuation，存在真实 Planner 越阶段风险。

计划修复但尚未完成：把 Phase 2 专属说明移出基础 Planner prompt，只在 build_phase_two_policy() 生成的 continuation system policy 中注入；同时在 Host 的 Root 规划入口根据受保护 phase context 强制 Phase 1 只能创建 Direction、Phase 2 只能创建 CandidatePortfolio。中断前产生的半成品 prompt 拆分已经撤销，没有纳入提交。

第二类共 1 项：

test_sql_phase_two_dynamic_replacement_compose_portfolio_and_boundary。

直接表现是 ElementSet replacement 同时引用自己的旧 ElementSet 和已接受 Paragraph 时，新 _guard_accepted_input_scopes() 报 INPUT_SCOPE_MISMATCH: element-set scope must equal or nest within accepted paragraph scope。

已定位根因：新增的 planning-time guard 比既有 authoritative AcceptedInputResolver._validate_consumer_input() 更严格，遗漏了 ElementSet 将跨 scope Paragraph 用于 placement 的明确合法例外。该 guard 原本用于在 Worker 启动前阻断 900021 的非法 Paragraph→Structure 兄弟 scope，但不能改变既有 ElementSet 组合合同。

计划修复但尚未完成：planning guard 必须复用或完全镜像 authoritative resolver 的 scope compatibility 规则，只为 ElementSet→Paragraph placement 保留既有例外，同时继续拒绝 Paragraph 以兄弟 Structure 作为 base artifact 的 900021 场景。

按用户明确指示，本节记录完成后不再运行测试。因此：

上述两类失败仍然存在于当前提交历史；
没有修复后的测试结果；
后续接手者必须先修复这 7 项，再继续断点恢复或真实 E2E；
本次 push 只代表代码和诊断记录已同步，不代表质量门禁通过。

7. 为什么慢，以及后续如何提速

7.1 当前慢点

不是 token 成本，而是调试循环粒度不合理：

E2E CLI 每次固定 start 新 build；
每次必须重跑已经验证过的 Phase 1、Retrieval、Direction 和 Structure；
后段第一个真实错误出现后，这一轮前面的时间不能直接复用；
当前 /resume 重点覆盖 Phase 3，不能重新启动已有 Phase 2 Planner；
run_phase_two 一旦检测到已存在 Phase 2 模型输出，会 fail-closed 为 MissionRecoveryRequired，这是安全设计，但缺少后续受控 replan 入口；
CLI 被 Ctrl-C 后会关闭受管数据库隧道，所以另一个诊断进程需要重新建立隧道。

7.2 已有恢复能力

现有代码不是完全不能恢复：

Ledger、Attempt、Validation、Operation 和 Trace 都是 durable；
Framework 的 recover_operations 能把崩溃中状态归一化；
未真正开始的 pending stage 可以安全 resume；
Worker 已提交而 Validator 未开始时可以只续 Validator；
已开始但未提交的 Worker/Validator 会 STOP/NEEDS_REPLAN，不会伪装成功；
Phase 3 /resume 可以处理 already-complete、finalize-only、Root blocked continuation；
finalize 使用唯一不可变身份，可以重试同一发布而不生成第二份正文。

7.3 当前恢复缺口

E2E CLI 没有 --script-build-id；
Phase 1/2 没有“接管 owner → recover operations → 恢复 Planner trace → 从当前 ledger replan”的完整入口；
stop 后的 build 按 fencing 合同不可解封，这是正确的，因此不能拿已 stop 的 900021 强行续跑；
新进程对原进程内 Planner Task 的停止收敛仍会停在 stopping；
当前失败报告只记录顶层异常；人工 Ctrl-C 都显示 CancelledError，缺少 last checkpoint、 root/task/operation 摘要和最后稳定 DomainError。

8. 后续测试方案

后续不再采用“每修一个小问题就从真实输入 start 一遍”的方式。

阶段 A：无模型快速重放

把 900021 暴露的合同形态做成最小 Ledger/contract fixture；
对 PLAN、REVISE、SPLIT、DISPATCH 逐入口重放；
用真实 Coordinator + FileStore + fake deterministic executor 构造 Direction ACCEPT → Structure ACCEPT checkpoint；
直接测试 Paragraph workspace 写入、Validator evidence、Compose closure、Portfolio closure；
对 Phase 3/finalize 使用不可变 accepted artifact fixture 做 MySQL rollback/readback 测试。

这一层应在秒级到分钟级完成，不调用真实模型。

阶段 B：补受控断点恢复

新增内部测试能力，但不放松生产 fencing：

E2E CLI 增加 --script-build-id 和 --resume；
新 Host 先获取同一 build 的 OwnerLease/epoch；
调用 Framework recover_operations；
pending/未开始阶段只 resume 原 Operation；
已开始未提交阶段归一化为 stopped/needs_replan，再让同一 Planner trace 创建新 Attempt；
Worker 已提交时只续 Validator；
复用原 InputSnapshot、accepted Decision、Artifact 和消息父链，不重复 Phase 1；
stopped/stopping、未知 child binding、半发布状态继续 fail-closed，绝不直接改数据库状态；
E2E report 增加 checkpoint、root 状态、active operation、last DomainError 和 resume 分类。

阶段 C：从中段开始的真实模型测试

先从 Structure ACCEPT 测 Paragraph→Compose→Portfolio；
再从 Portfolio ACCEPT 测 Phase 3 Root；
再从 Root ACCEPT 单独测 finalize→publication→legacy detail；
每段成功后固定为回归测试，失败只重跑该段。

阶段 D：最终只做一次全链路门禁

局部段全部通过后，再新建一个干净 build，执行：

真实旧版输入 → 真实 Qwen → Phase 1 → Phase 2 → Phase 3 → Root ACCEPT → MySQL Final UoW → publication/artifacts published → accepted pointer → branch0 digest → build success → legacy detail readback

随后统一运行 Agent 全量、Host 全量、MySQL release gate、Ruff、format check、strict mypy、compileall 和 git diff --check。只有这些全部通过，第三个硬门槛才标记为完成。

9. 建议执行顺序和时间预估

先补断点恢复/分段 harness 和详细失败报告：约 1–2 小时；
无模型覆盖 Paragraph→Portfolio 的状态和合同：约 30–60 分钟；
真实模型按后半段分段运行并修复：取决于新缺陷数量，预计 1–3 小时；
最终完整 E2E 和全量门禁：约 1–2 小时。

这是调试预估，不是完成承诺。后半段尚未首次真实跑通，任何新的框架级缺陷都会增加时间；但采用分段和恢复后，不再为同一个后段错误重复支付整个前半程时间。

REAL_E2E_DEBUG_REPORT_2026-07-20.md 23 KB Permalink History Raw