AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具【免费下载链接】ouroborosAgent OS: the agent gets smarter on its own. We just hold the line: Interview-gated, staged evaluation, budgeted evolution loop. MCP server, 14 runtimes: Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot, Kiro and more.项目地址https://gitcode.com/gh_mirrors/ouroboros13/ouroboros点击查看免费下载导读tests/canonical/evidence/issue-1450-20260715-162447-736593/pair-2/arm-x/workdir/.ouroboros/traces/auto_20b877d7935f/summary.md是 ouroboros 自动流水线ooo auto在一次真实运行结束后生成的 interview trace 摘要文件。它记录了本次会话的最终状态blocked、Seed 质量评审QA给出的revise判定与 0.72 分、反复 5 次修复仍未能通过的阻塞原因以及 10 条契约决策的溯源分布。阅读本文后你将掌握trace 文件的生成原理与目录约定、每个字段的语义与源码出处、Seed QA 门控的完整判定流程含修复、超时、咨询降级路径、决策溯源provenance的等级划分与门控规则以及如何把这份 trace 当作排查自动化任务的审计线索。一、trace 是什么一份由持久化状态投影出来的运行档案1.1 生成位置与目录约定summary.md位于.ouroboros/traces/run_id/目录下其中run_id等于自动流水线的auto_session_id本例为auto_20b877d7935f。该目录的默认根路径由 trace_export.py 决定cwd/.ouroboros/traces/run_id/即从流水线执行时的工作目录state.cwd开始计算可通过out_root参数覆盖。该目录下会输出一组可 grep 的流文件空流不生成文件文件名内容questions.jsonl访谈问题历史来自 ledger 的question_history与事件流中的响应记录ambiguity.jsonl携带ambiguity_score的事件轨迹lateral.jsonl侧向思考lateral类事件与最终横向决策记录decisions.jsonl每条契约字段决策的节、键、值、来源、溯源、状态、是否晋升、是否被门控flags.jsonltimeout / fallback / degraded / blocked 等生命周期信号及端态状态标志outcome.json结构化运行结果含 QA 判定、溯源直方图、阻塞原因等summary.md人类可读的摘要即本文解析的对象流文件的分类规则定义在 trace_export.py事件类型名包含lateral/unstuck/stagnation的归入 lateral 流包含timeout/fallback/failed/deadline/degraded/blocked等标记的归入 flags 流携带ambiguity_score的事件无论类型名如何都进入 ambiguity 流。1.2 投影而非存储数据从哪来trace 不是独立存储而是一个projection投影。它从两个已存在的持久化源读取数据见 trace_export.pySeedDraftLedger保存访谈问题历史、每条已决策契约字段及其source/status/provenance以及决策来源直方图EventStore保存访谈事件流歧义度轨迹、lateral 建议以及驱动层追加的超时/降级/生命周期事件。由于内容完全由持久化状态与已存事件推导而来不含墙上时钟戳因此重新导出是字节级幂等的byte-idempotent每次导出都会确定性地覆写同样的内容。trace 有两个入口export_interview_trace手动/A3-CLI 入口可从AutoStore加载任意历史run_id重新投影与best_effort_export_trace流水线 finalize 钩子任何失败只记录日志、绝不抛入运行流程。后者的等待时间受TRACE_EXPORT_DEADLINE_SECONDS 30.0硬性约束trace_export.py且文件系统写阶段运行在独立的 daemon 线程上以保证 trace 生成延迟不会阻塞 CLI 返回终态结果。1.3 为什么这是一个好的审计格式每个 JSONL 行都通过type字段自描述summary.md采用纯文本 markdown 列表便于grep、脚本分析与 LLM 检索。这种可 grep的设计A2 / run-metaharness 计划让下游工具MCP 信封、harness trace、attention_relay能直接从结构化字段中读取结果而无需解析英文散文。二、逐字段解析 summary.md 的头部信息本节以示例文件内容为骨架逐项对应源码中 summary.md 的构建逻辑。2.1 Status终态与 stop reason- Status: **blocked**Status直接取自state.phase.valueAutoPipelineResult的终态阶段。blocked表示流水线在进入 RUN 之前被某个门控中止。blocked之外常见终态还有complete成功完成与failed内部失败。值得注意在 grade_gate_terminals.py 中grade 门控的终止码被定义为一组模块级常量seed_grade_below_requiredSeed 实际评级未达到要求的评级seed_review_withheld_run评审没有放行执行degraded_seed_safety_blockers降级 Seed 仍携带硬安全阻塞项。这套类型化编码让下游消费者无需读散文即可区分评级太低应提高评级、评级达标但评审未放行提高评级是错误动作与降级 Seed 仍带安全标记需先解决标记三种完全不同的处置方向。本示例 trace 虽因 Seed QA 未通过而 blocked但在outcome.json中会以stop_reason_code字段携带精确的编码。2.2 Grade确定性评级门- Grade: AGrade对应state.last_grade即SeedReviewer对当前 Seed 的评级结果。评级排序定义在 grade_gate_terminals.py{A: 0, B: 1, C: 2}grade_meets_required只有在实际评级优于或等于required_grade时才返回 True未知评级一律视为不达标。本示例评级为 A最高档说明 Seed 的契约质量本身达标——阻塞并非评级问题而是下面的 Seed QA 判定。2.3 Seed 标识与来源- Seed: seed_4ea47f30d65d (origin: auto_pipeline)Seed字段包含seed_id与seed_origin。origin 为auto_pipeline表示该 Seed 由自动流水线访谈驱动 自动填充合成而非由用户在交互式 Seed 会话中手工创建。这在 seed_preflight.py 与 pipeline 的state.seed_origin.value中体现不同来源的 Seed 走不同的前检路径。2.4 Evaluate/QASeed QA 门的判定- Evaluate/QA: verdictrevise score0.72 passedFalse这是本文件信息量最大的字段之一直接取自state.last_qa_*verdict判定revise——Seed 需要修改score得分0.72passedFalse——未通过。这三个字段的写入点在 pipeline.py 的_run_seed_qa_gate每次评估器返回后state.last_qa_score/state.last_qa_verdict/state.last_qa_passed会被同步更新并在下一次尝试前通过clear_seed_qa_verdict清空防止上一次尝试的判定泄漏到下一次seed_qa_advisory.py。2.5 Blocker阻塞的完整叙事- Blocker: Seed QA did not pass after 5 attempt(s): revise (score 0.72); differences: ...Blocker来自state.last_error在_build_outcome中由_clip(state.last_error)截断到 2000 字符trace_export.py。这一行同时携带了三个信息尝试次数5 attempt(s)——修复预算用尽。预算上限来自max(1, int(state.max_repair_rounds or 1))pipeline.py差异differences评审器列出的具体差距清单建议suggestions评审器给出的可操作修改方向。示例中的三条差异与三条建议恰好构成了一个完整的 Seed 质量闭环差异对应建议验收标准过于泛化未具体验证核心行为add / list / check off / JSON 持久化添加行为级验收标准覆盖新增习惯、列出已持久化习惯、勾选完成、跨调用验证 JSON 文件写入与重读Seed 未定义 CLI 表面命令名、必选参数、期望输出形态指定最小 CLI 契约如habit add name、habit list、habit check id\|name并给出确定性的 stdout 示例持久化要求欠明确无 JSON 文件名、schema、对已存在/损坏状态的处理定义持久化文件名与最小 JSON 结构以及缺失文件和无效文件的预期处理这些字段在outcome.json中以qa.differences与qa.suggestions数组形式保留各最多 5 条见 seed_qa_advisory.py 的_MAX_EVIDENCE 5。三、Counts一次访谈的量表## Counts - Questions: 1 - Decisions: 10 (promoted 10, rejected 0, gated 7) - Ambiguity points: 0 - Lateral records: 1 - Flags: 2Counts 在 trace_export.py 中由各流长度与决策行统计计算得出Questionsledger 的question_history长度含事件流中的interview.response.recorded响应事件跨 provider 运行时问题历史稀疏时由后者补足。本例为 1说明本轮访谈问题轮次很少大部分契约字段由自动填充完成Decisionsdecisions.jsonl中决策条目总数10。其中promoted晋升即状态非 WEAK/CONFLICTING/BLOCKED 的活跃条目10、rejected被否决/搁置状态为_REJECTED_STATUSES0、gated受门控即溯源属于MODEL_INFERRED或TIMEOUT_DEFAULT7。promoted 与 rejected 的判定见 trace_export.py 与 trace_export.pyAmbiguity points携带ambiguity_score的事件数。本例为 0说明访谈中没有产生歧义度轨迹点Lateral recordslateral 流条目数。本例为 1说明修复过程中曾动用过一条横向思考记录见下文横向修复Flagsflags 流条目数。本例为 2——结合 5 次修复与 advisory 路径这两条 flag 很可能对应生命周期信号如超时/降级标记与端态状态标志。特别需要解释gated 7的含义_GATED_PROVENANCEtrace_export.py只包含MODEL_INFERRED与TIMEOUT_DEFAULT两类溯源。10 条决策中有 7 条来自模型推断或超时默认意味着这份 Seed 的大部分契约字段并非由用户直接确认而是在自动填充机制下生成的模型最佳猜测——这正是 Seed QA 门控要重点审查的对象。四、Decision provenance histogram决策是如何做出的## Decision provenance histogram - maintainer_policy: 2 - timeout_default: 7 - user_confirmed: 1这是 trace 中最具审计价值的字段它回答一个关键问题Seed 里的每条契约字段到底是用户说的、模型猜的、超时兜底的还是维护者策略填的4.1 五种溯源等级ledger.py 定义了DecisionProvenance决策溯源枚举与描述内容权威类型的LedgerSource正交溯源值含义门控user_confirmed用户明确确认来自用户目标、偏好、非目标、仓库事实、既有约定无条件通过maintainer_policy确定性策略/配置填充conservative_default保守默认无条件通过lateral_consensus侧向思考达成的共识无条件通过model_inferred模型最佳猜测推断、假设、自动填充推断需要低歧义门timeout_default访谈超时后的确定性兜底值需要低歧义门这个设计直接回应了 #1485 暴露的失败模式超时默认的决策与用户确认的决策在过去无法区分导致包含原始问题文本的降级 Seed 被静默执行。引入溯源轴后model_inferred与timeout_default两类决策在成为可执行 Seed 前必须通过低歧义判据见ouroboros.auto.grading其余三类是接地/人类授权的无条件通过。4.2 溯源如何推导LedgerEntry.effective_provenanceledger.py的规则显式盖章的provenance字段优先未盖章旧会话、反序列化条目、未显式盖章的写入点时从source经_PROVENANCE_FROM_SOURCE映射推导ledger.pyUSER_GOAL/USER_PREFERENCE/NON_GOAL/REPO_FACT/EXISTING_CONVENTION→user_confirmedCONSERVATIVE_DEFAULT→maintainer_policyINFERENCE/ASSUMPTION/AUTO_FILL_INFERENCE→model_inferred兜底默认_PROVENANCE_DEFAULT MODEL_INFERRED——未盖章条目被视为模型猜测并接受低歧义筛选既不让旧会话崩溃也不让未盖章决策静默通过门控。超时兜底与横向共识无法由source表达因此在决策点被显式盖章ledger.py。4.3 直方图怎么数provenance_histogramledger.py只统计活跃条目状态非 WEAK/CONFLICTING/BLOCKED即真正流入合成 Seed 的决策并按溯源值字典序稳定排序。它被放到SeedMetadata.decision_provenance上供 A2 trace 工件 grep 出这份 Seed 的契约是如何拼装出来的、依赖多少条被门控的决策。本例直方图timeout_default: 7占绝对多数与 Counts 中gated 7完全对应共同说明了这次自动填充的真相这是一份高度依赖超时默认值拼装出来的 Seed——7 条契约字段在访谈未收敛时落入了确定性兜底而兜底值显然不足以支撑一个明确的 CLI 契约。五、Blocker 背后Seed QA 门控的完整判定流程Blocker 那句Seed QA did not pass after 5 attempt(s)背后是_run_seed_qa_gatepipeline.py一次完整的门控循环可选门只有当seed_qa_evaluator被装配时该门才生效未装配时 Seed 无条件进入下一阶段pipeline.py逐次判定每次尝试先清空旧判定、保存状态再以 EVALUATE 阶段超时_deadline_capped_timeout调用评估器瞬态重试评估器超时或报错时按_TRANSIENT_TOOL_ATTEMPTS次数与退避策略重试重试期间若触碰流水线 deadline 则立即返回 deadline 结果pipeline.py通过则继续passedTrue时先复查确定性评审门grade gate通过后标记进度进入 RUN 或 skip-run 完成pipeline.py未通过且预算未耗尽若判定请求歧义修复则直接 blockedseed_qa_ambiguity_unrepairable否则调用_repair_seed_after_qa修复 Seed重新评审SeedReviewer更新seed_artifact/seed_id/last_grade进入下一轮pipeline.py预算耗尽走 advisory 路径——本例即第 5 次尝试后repair_budget_exhaustedpipeline.py。5.1 修复机制机械回写与横向思考_repair_seed_after_qapipeline.py有两种修复手段机械回写机械反馈回声_seed_with_seed_qa_feedback把 QA 的差异与建议编码为诊断约束回写进 Seed再重新接受评审——但它只能复述差距解决不了缺一个绑定契约选择、缺一个章节这类实质性阻塞横向修复lateral repair装配了lateral_thinker时先由select_persona_for_qa_failure基于反馈选择横向人格再由该人格把已映射的修复约束转成一个具体决策并折叠进 Seed若人格链耗尽、超时或插件委派失败则回退到机械回写。修复过程记录在state.last_lateral_persona/state.last_lateral_approach_summary/state.last_lateral_text并计入personas_invoked——这正是本示例 trace 中Lateral records: 1的来源。注意_normalized_seed_qa_feedback会对反馈做清洗剔除恢复转录文本recovery transcript与上下文块避免把运行期杂讯写进 Seedpipeline.py。5.2 咨询降级不把 blocked 变成死胡同当修复预算耗尽或反馈无法被映射时_run_seed_qa_gate不会直接 dead-end而是走_seed_qa_advisory_continuepipeline.py与publish_advisoryseed_qa_advisory.py顺序保证先让所有仍可阻塞的门确定性 grade 门、流水线 deadline发言确认真正走在继续路径上才发出SEED_QA_ADVISORY_EVENTauto.seed_qa.advisory_override——避免宣称继续驱动的证据被后续门控打脸事件负载seed_qa_advisory_payload携带 schema_version、auto_session_id、seed_id、attempts、verdict、score、差异与建议各至多 5 条、reason 与裁剪后的 detail。reason区分真正的未通过判定repair_budget_exhausted/seed_qa_feedback_unmapped与评估器侧失败evaluator_timeout/evaluator_error/evaluator_transient_error判定移交未解决的发现保留在state.last_qa_*上由结果信封与事件继续暴露真实裁决推迟到 run → evaluate 阶段——evaluate 依据执行证据判定而非对 Seed 的静态阅读权限不削弱修复后不再满足required_grade或不再被放行的 Seed仍由grade_gate阻塞而不是这条 advisory 路径。配套进度消息为Seed QA advisory (reason): detail; continuing with the current Seedseed_qa_advisory.py。这套设计的核心契约写在其模块 docstring 中Seed-QA 门是可选门装配了评估器的流水线不得让会话比不装配时更糟——可以修复、注解、警告但不得把本可以启动的运行带进死胡同。5.3 超时与 deadline 的双重防护评估器调用受asyncio.wait_for EVALUATE 阶段超时约束修复含横向思考同样受超时与 deadline 约束超时抛TimeoutError直接返回 deadline 结果整个 trace 导出本身也有 30 秒 deadline超时后 daemon 线程可能仍在后台完成写入但调用方不受阻塞见 1.2 节。六、测试验证这条路径有测试吗自动流水线的 Seed QA 路径在单元测试中有充分覆盖可参见tests/unit/auto/下针对 pipeline、ledger 与 trace 的测试共 69 个测试文件。从测试目录结构看可以确认以下行为存在对应的断言基础tests/unit/auto/test_trace_export*.py可在 tests/unit/auto 中检索验证 trace 流文件生成、字段语义与字节级幂等导出tests/unit/auto/test_ledger*.py验证effective_provenance推导、provenance_histogram只统计活跃条目、冲突解决优先级tests/unit/auto/test_seed_qa*.py验证 Seed QA 门控的通过/修复/咨询降级路径、修复预算耗尽与瞬态重试。本文示例 trace 本身来自tests/canonical/evidence/issue-1450-20260715-162447-736593/pair-2/arm-x/workdir/即 canonical 测试夹具中的真实运行产物——它是把 trace 解读与 QA 门控行为作为回归测试证据的典型样本。结合 seed_preflight.py 与 resume_routing.py 中出现的 seed_qa 引用可以推断恢复resume会话也会携带 Seed QA 判定继续前检阶段同样关注 Seed 的 QA 状态。七、实操如何用 trace 排查一次自动化任务7.1 定位 trace 目录# 在 ooo auto 的执行目录下按会话 ID 查找 trace find . -path */.ouroboros/traces/* -name summary.md7.2 快速排查顺序看 Statusblocked→ 门控中止complete→ 进入执行阶段failed→ 内部失败看 Blocker5 attempt(s)revise (score 0.72)的组合意味着 Seed QA 修复预算耗尽——问题不在代码执行而在 Seed 契约本身看 differences / suggestions逐条对照差异 → 建议映射判断是验收标准太泛、CLI 表面缺失还是持久化契约欠定义看 Decision provenance histogramtimeout_default占比过高说明访谈收敛失败、大量字段落入确定性兜底这类 Seed 即使评级为 A也可能因缺乏具体契约而在 QA 门上反复失败看 Counts 的 gatedgated 数量与 histogram 中model_inferredtimeout_default之和应当一致本例均为 7看 Lateral records 与 Flagslateral 记录说明修复阶段动用了横向思考flags 中的 timeout/degraded/blocked 标记定位生命周期异常。7.3 反查结构化数据需要机器可读的细节时读取同目录的outcome.json含stop_reason_code、qa.differences、qa.suggestions、provenance_histogram、gate_findings、open_gaps与decisions.jsonl逐条查看promoted与gated标志。文件清单与各流分类规则已在第一节给出。结语一份 trace 的三重价值以auto_20b877d7935f这份 trace 为例可以看到它同时承担了三种角色运行档案Status/Grade/Blocker 记录终态与阻塞原因、质量诊断书differences/suggestions 精确指出 Seed 契约的短板、溯源审计单provenance histogram 揭露契约字段的决策来源与门控占比。当你在 ouroboros 的自动流水线中看到一条 blocked 的任务第一步不应该是去读执行日志而是打开这份 19 行的 summary.md——它已经把为什么被拦下和接下来该改什么写在了最显眼的位置。阅读延伸interview trace 导出实现、Seed QA 咨询层、Seed QA 门控主流程、决策溯源定义与推导、确定性评级门。赞分享AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具【免费下载链接】ouroborosAgent OS: the agent gets smarter on its own. We just hold the line: Interview-gated, staged evaluation, budgeted evolution loop. MCP server, 14 runtimes: Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot, Kiro and more.项目地址https://gitcode.com/gh_mirrors/ouroboros13/ouroboros点击查看免费下载相关推荐Klavis Strata 集成 LangChain TypeScript构建可调用 Gmail 与 YouTube 的 MCP AI Agent 示例详解Klavis Strata 集成 LangChain TypeScript构建可调用 Gmail 与 YouTube 的 MCP AI Agent 示例详解AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具Ouroboros Issue 质量策略结构化 Issue 与可追溯性 CI 门禁的工程实践Ouroboros Issue 质量策略结构化 Issue 与可追溯性 CI 门禁的工程实践 Ouroboros 将 GitHub Issue 视为可执行工作AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具Ouroboros ooo auto 深度解析从一句话目标到 A 级 Seed 的确定性收敛引擎Ouroboros ooo auto 深度解析从一句话目标到 A 级 Seed 的确定性收敛引擎 ooo auto 是 Ouroboros 项目中的端到端自动AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具上一篇AutoCut终极指南用文本编辑快速剪辑视频的完整教程下一篇PyTorch3D VoxelGridImplicitFunction 深度解析基于体素网格与 Scaffold 加速的隐式神经渲染创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考