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点击查看免费下载导读本文以 verify-gate-windows-portability.md 这份已落地实现的 RFC 为核心系统讲解 Ouroboros 接受标准Acceptance CriterionAC验证门禁在跨平台执行与证据判定两方面的演进其一将verify_command从默认使用cmd.exe的asyncio.create_subprocess_shell改造为先解析真实 POSIX Bash、再原样执行命令的分层方案其二修正 fat-harness 在运行期转写缺失时将已完成工作整体拒绝的问题。读者将获得可复制的配置参数、环境变量与源码级证据并理解验证基础设施不可用 ≠ 工人失败这一核心设计原则。背景两个在ooo run中观察到的关联故障RFC 记录了两个相互独立、但都发生在ooo run执行链路上的故障。故障一Windows 上verify_command直接无法解析_run_ac_verify_gate原本通过asyncio.create_subprocess_shell(command, cwdcwd, ...)执行 AC 的verify_commandRFC 指向的原始实现位于src/ouroboros/orchestrator/parallel_executor.py:9843。问题在于verify_command由 seed-architect 按POSIX bash 契约生成天然依赖grep、、单引号、正斜杠路径等 bash 惯用法Python 的create_subprocess_shell在原生 Windows 上默认解析到cmd.exe而cmd.exe完全不理解上述语法因此任何通过verify_command验证的 AC 在 Windows 上都有直接崩溃的风险。故障二fat-harness 的过度拒绝over-rejection没有verify_command的 AC 会回退到基于运行期转写的证据校验_verify_atomic_evidence_against_runtime_messages位于src/ouroboros/orchestrator/evidence/verification.py。当support_messages为空时AC 会被整体拒绝理由是no runtime transcript evidence supports the typed evidence claims。RFC 记录的真实事故是一个 AC 完成了 19 分 34 秒的真实工作测试、编辑却因转写未到达验证器疑似压缩或收集时机问题未确认而被拒绝自动重试随后重跑了整个 AC又烧掉了约 20 分钟。RFC 特别澄清了根因不是job_observer契约src/ouroboros/mcp/tools/job_observer.py只是宿主会话观察后台任务的只读轮询交接与叶子工人自身的工具调用转写无关。真正的分叉点是verify_command是否存在当设置了verify_command时_run_ac_verify_gate运行编排器自己的命令其余证据检查被豁免_fat_harness_acceptance_errorparallel_executor.py:12836-12869只有没有verify_command的 AC才会走脆弱的转写路径。对标研究GJC 的解析真实 shell模式RFC 记录了与 gajae-codeGJC的对比研究。GJC 的收据系统harness-control-plane/receipts.ts使用 sha256 密封的结构化 JSON 信封概念上比转写消息匹配更难篡改但其验证命令执行finalize.ts:315硬编码了Bash.spawnSync([bash, -lc, spec.command], ...)。真正可移植的答案在packages/utils/src/shell-config.ts的getShellConfig()它在每次 shell 命令前解析一个真实的 POSIX 兼容 shell 二进制优先级为用户指定的shellPath→ Git Bash%ProgramFiles%\Git\bin\bash.exe含 x86 变体→ PATH 上的bash.exeCygwin/MSYS2/WSL→ 携带可操作安装提示的显式失败。关键设计是GJC 不按 OS 翻译 bash 语法而是保证真实 bash 存在或大声失败命令作者永远只写 POSIX 语法。决策 Part AWindows 安全的verify_command执行永不破坏的不变量RFC 明确了采用 GJC 模式时必须守住的不变量_run_ac_verify_gate存在的意义是防止工人自报可被作弊。无论在哪里运行如何解析实际的通过/失败必须来自运行那条确切命令或其未修改/固定的翻译的确定性退出码——绝不能来自 LLM 对 AC看起来完成了的意见。三层解析Tiered resolutionRFC 记录了分级方案且注明这是业主批准、取代了早期缺 bash 即硬失败草案层级机制说明Tier 0确定性、免费新增src/ouroboros/orchestrator/verify_shell.py的resolve_verify_shell()沿用get_goose_cli_path()/get_pi_cli_path()的 env → config → PATH 优先级。POSIX/bin/bash然后shutil.which(bash)Windows%ProgramFiles%\Git\bin\bash.exe→ x86 变体 →shutil.which(bash.exe)Cygwin/MSYS2/WSL。OUROBOROS_VERIFY_BASH环境变量覆盖优先且因属于可执行路径变量必须按本仓库.env信任边界规则untrusted_env.py对*_CLI_PATH类变量的 denylist加入 denylistTier 1LLM 咨询仅限路由选择Tier 0 无果时LLM 只接收环境事实候选 shell 路径是否存在、OS、可用解释器从该固定候选集中挑选/构建ExecutionRoute。它永远看不到 AC、工人输出或超出字面字符串的 verify_command 语义。编排器用无害命令echo ok test -d .探测选定路由后才信任。此层不修改verify_command文本Tier 2LLM 翻译密封第二行仅当完全不存在 POSIX 解释器时LLM 将verify_command翻译为 PowerShell/cmd 等价物。为阻断改写为简单命令的失败模式翻译只在执行前 preflight 发生一次、固定进缓存失败后永不重新翻译——没有机会因失败结果而放松命令终局隔离quarantine而非静默通过。若 Tier 1/2 仍无法产出可用路由AC 被标记为environment_unverifiable。运行不会停止业主原话fail 처리로 멈추지마——不要因失败处理而停止但该 AC永不计为验证通过——它在最终报告中以本机无法验证需人工确认呈现。这是同时满足不走进死胡同与不伪造通过的唯一方式。缓存设计成本/延迟控制RFC 设计了两个缓存均以键控方式避免常见路径上的逐 AC 或逐重试 LLM 调用机器缓存~/.ouroboros/verify_route.json键为机器指纹OS 候选路径存在性的哈希。相同指纹 零 LLM 调用翻译缓存键为sha256(verify_command) 机器指纹。重试与重跑均为缓存命中解析在每次ooo run的批量 preflight中针对所有 AC 的 verify 命令执行一次而非按 AC 惰性解析——Tier 0 成功的稳态路径上零新增延迟。_run_ac_verify_gate的改动将create_subprocess_shell(command)替换为create_subprocess_exec(*resolved_route.argv)POSIX 上等效于bash -c command语义与今天一致。VerifyShellUnavailableError从终止性失败降级为进入咨询层的内部信号而非死胡同。已落地实现verify_shell.py 的源码级解析解析优先级与平台分支当前仓库中的 verify_shell.py 完整实现了 Tier 0 与终局隔离。resolve_verify_shell()的核心逻辑如下环境与配置候选_configured_candidate先读OUROBOROS_VERIFY_BASHVERIFY_BASH_ENV_VAR常量再读配置orchestrator.verify_bash_path。注意_config_value()刻意绕过 env-first 访问器——若环境变量已失效env-first 会返回同一个失效值导致配置 shell 永远无法被触达平台候选POSIX 上依次尝试/bin/bash、/usr/bin/bash、PATH 上的bashWindows 上依次尝试%ProgramFiles%、%ProgramW6432%、%ProgramFiles(x86)%下的Git\bin\bash.exegit_bash再是 PATH 上的bash.exe、bashWSL 启动器过滤_is_wsl_launcher识别%SystemRoot%\System32\bash.exe并拒绝。该二进制会把命令交给拥有独立根文件系统的 Linux 发行版门禁传入的 Windowscwd在其中毫无意义——命令将判定另一棵树或为与 AC 无关的原因失败。两种结果都比本机无法验证更糟绝对路径强制_executable只接受解析后的绝对路径。门禁以验证工作区为cwd启动相对路径会在检查时指向一个目录、执行时指向另一个目录——工作区可以借此提供评判自己验收标准的二进制。相对结果一律拒绝并落入下一个候选。为什么必须是 bash而不是shRFC 与源码都强调没有sh回退sh对同一文本的解读不同echo -e X在 bash 下输出X、在sh下输出-e X因此针对-e断言的契约会在其编写时的 shell 下失败、在替代 shell 下通过——那是关于另一条命令的裁决。无 Bash 的机器将验证记录为不可用它从不模拟 Bash也从不把缺失的验证器转化为工人失败。Windows 上永不回退到cmd也永不用%SystemRoot%\System32\bash.exeWSL 启动器。密封身份sealed identity与能力握手capture_verify_shell_identity()密封三要素path路由路径、realpath规范路径、sha256文件内容摘要。在待验证子进程启动前verify_shell_path_from_identity()通过规范路径 文件摘要重新校验身份变更或缺失时保持不可用绝不静默选择新可执行文件。_executes_bash_c_semantics()通过固定能力握手证明某可执行文件实现了 Bash-c契约直接通过 OS 执行[[ -n ${BASH_VERSION:-} ]] || exit 96; exit 37超时 3 秒仅在返回码为 37 时判定通过。该握手按内容摘要缓存避免重复 AC 门禁为同一密封可执行文件再派生子进程探测。它绝不是命令解析器、翻译器、回退 shell 或模拟器。环境的清洗让裁决由编排器意图的工具计算sanitized_verify_environment()从门禁子进程环境中剥离所有能不改变工作区与命令就改变裁决的变量VERIFY_ENV_STRIPPED_KEYS与VERIFY_ENV_STRIPPED_PREFIXES两个常量集Python 注入PYTHONPATH、PYTHONSTARTUP、PYTHONHOMEpytest 注入PYTEST_ADDOPTS仓库自身的.env可设置PYTEST_ADDOPTS-k nothing使每个 pytest 形状的契约不跑任何测试就通过——这正是 RFC/源码注释点名的最尖锐风险之一且它不在 untrusted-env denylist 覆盖范围内、PYTEST_PLUGINSNode 预加载钩子NODE_OPTIONSJS 形状契约的同类风险shell 启动文件BASH_ENVbash 在求值-c命令前会 source 它含exit 0的文件会把bash -c exit 23变成通过——这比弯曲工具配置更尖锐它直接在门禁内运行仓库代码、ENVshell 选项状态SHELLOPTS、BASHOPTS、BASH_XTRACEFD、BASH_COMPAT、PS4xtrace写入断言检查的组合输出、errexit改变链条哪条腿决定状态、xpg_echo改变echo输出分词/路径查找/glob 抑制IFS、CDPATH、GLOBIGNORE前缀剥离LD_PRELOAD、DYLD_INSERT_LIBRARIES动态加载器预加载家族按前缀剥离以覆盖跨平台新增成员、BASH_FUNC_导出的 shell 函数-c命令在解析任何同名可执行文件之前先解析它——名为pytest或git的函数会替换契约本要运行的工具。PATH刻意不剥离verify 命令通过它解析真实工具uv、pytest、node项目本地.venv/bin条目既常见又合法。project_verify_environment()进一步通过with_project_venvcore/project_env把项目虚拟环境置为最先解析因为任务工作树缺少被 gitignore 的项目虚拟环境。解析缓存与重试语义resolve_verify_shell()的缓存键_cache_key指纹化所有输入平台、OUROBOROS_VERIFY_BASH、配置路径、PATH、SYSTEMROOT、三个 Git-for-Windows 安装根变量。注释点明遗漏任何一项都会在变更后继续提供首次解析的路由——这正是缓存要避免的过期解释器。两个细节值得注意只有成功解析才被缓存。失败每次调用都会重新解析因为重试不可验证 AC的全部意义在于操作员可以在运行继续期间安装 Git Bash 或设置OUROBOROS_VERIFY_BASH。Git Bash 通过%ProgramFiles%而非PATH找到因此以PATH为键的无 shell缓存永远不会注意到新安装从而破坏它本要服务的重试reset_verify_shell_cache()提供测试与环境变更所需的缓存清空入口。配置项与环境变量RFC 的Implementation status部分与 loader.py 确认了完整参数面环境变量OUROBOROS_VERIFY_BASH——指向 bash 可执行文件的绝对路径优先级最高配置文件orchestrator.verify_bash_path——config.yaml中orchestrator段下的路径项denylistOUROBOROS_VERIFY_BASH与 shell 启动/选项控制BASH_ENV、ENV、SHELLOPTS、BASHOPTS、BASH_FUNC_*一同被加入 untrusted-.envdenylist见 untrusted_env.py 中与各*_CLI_PATH变量并列的条目。源码注释明确理由仓库.env若把OUROBOROS_VERIFY_BASH指向自己的二进制就会在验证门禁——这个必须保持不可篡改的地方——内执行任意代码行为前提解析在原生 Windows 上依赖 Git for Windows或 Cygwin/MSYS2 提供的 PATH 内 bash无 Bash 的机器含纯 PowerShell/cmd 环境会得到验证不可用而非工人失败。已落地实现不可用结果的隔离与事件化verify_quarantine.py 实现了 Part A 的终局隔离quarantine_unverifiable_result()保留成功的工人结果存储不可用的门禁结果发出操作员可见事件且永不消耗重试事件类型为execution.verify.unverifiable负载包含session_id、execution_id、ac_index、ac_content、verify_command、reason、verify_cause、状态unverifiedquarantine_reason()生成面向操作员的解释Verification unavailable: ... work result requires confirmation.验证不可用……工作结果需确认render_unverifiable_summary()在最终报告中呈现Succeeded without machine verification (N), needs confirmation: AC ...无机器验证地成功N 个需确认AC …启动错误与超时走同一路径verify_command_runner.py的VerifyRun将start_error与timed_out与returncode分开因为门禁不能把无法启动或运行过久读作普通非零退出——它们是关于运行的不同事实。verify_command_runner.py 提供了 Windows 上的进程生命周期保障子进程以挂起CREATE_SUSPENDED方式创建先分配进 kill-on-close 的 Windows Job Object_create_windows_job通过 ctypes 调用CreateJobObjectW/AssignProcessToJobObject再恢复主线程——保证超时终止时进程树可整体回收。POSIX 侧使用start_new_session加进程组SIGKILL。子进程 stdin 固定为DEVNULL因为 MCP 宿主下那是 JSON-RPC 流且任何沙箱路径规则之前打开的描述符都可用。最终的结算settlement会重新校验工件与工作区状态但从不把不可用验证转化为工人失败。BLOCKED与可重试失败类仍保留给工人/运行时失败验证器基础设施是独立事实不进入路由升级或工人重派。决策 Part B缩小 fat-harness 的爆炸半径RFC 提出三条措施默认把 AC 推向verify_command。扩展现有 seed preflight 门禁RUN 之前的确定性可执行性检查新增拦截器如ac_missing_verify_command针对既无verify_command又无显式豁免理由新增字段AcceptanceCriterionSpec.verify_exemption_reason的 AC。更新 seed-architect 的 prompt优先verify_command不可行时必须给出理由。_run_ac_verify_gate对转写丢失与自报作弊都免疫——它是唯一同时降低误接受与误拒绝的选项因此这是首要修复而非放宽转写检查本身重新分类空转写拒绝。在_verify_atomic_evidence_against_runtime_messages中为support_messages完全为空的情形单独给出原因码如transcript_missing_infrastructure复用现有*_transient_exhausted代码约定而非泛化的工人拒绝。该码路由到更窄的重试重新收集一次转写而非重跑整个 AC。事故中 19 分 34 秒的真实已完成工作绝不应被整体丢弃——空转写是收集失败的信号不是作弊信号作弊的工人会留下貌似合理的消息而不是什么都不留被否决的替代方案当support_messages为空时回退到工作区 diff/mtime 作为替代信号。否决理由可被作弊touch即可满足且破坏 fat-harness 存在的意义。已落地实现B3 转写不可用与 B1 警告阶段B3空转写 基础设施信号verification.py 已实现重新分类。核心逻辑验证器按身份而非位置排除叶子工人的终局自报消息message.is_final——harness 观察消息可能合法地出现在最终结果消息之后若剩余支持消息全部是 harness 观察消息即没有任何真实运行时转写到达且有效证据模式有必填字段则返回VerifierVerdict(passedFalse, ...)原因码为transcript_missing_infrastructure: the runtime transcript reached the verifier empty, so no claim could be checked; the leafs work was not evaluated失败类为FailureClass.TRANSCRIPT_MISSING_INFRASTRUCTURE.value注释点明命名逻辑空转写是基础设施信号而非作弊信号——试图作弊的叶子会留下貌似合理的消息而不是什么都不留。独立命名让丢失的转写不会被报告为工人拒绝也不会被解读为叶子什么都没做的证据若有效模式无必填字段not effective_schema.required直接返回通过——纯验证运行可能诚实地无事可做。RFC 的实现状态确认完全空的support_messages投影产生VerifierStatus.UNAVAILABLETRANSCRIPT_MISSING_INFRASTRUCTUREACCEPT准入。已完成工作保留为未验证成功不触发工人重试或重派。B1verify_exemption_reason与seed.verify_command_gate字段seed.py 中AcceptanceCriterionSpec.verify_exemption_reason为str | None描述强调它是按 AC 的显式逃生舱绝不是一揽子退出。校验器强制其与verify_command互斥同时存在抛ValueErrorverify_command存在时它会随规范化、语义身份迁移存活execution_acceptance.py 中的传递与比对逻辑解析acceptance_criteria_parsing.py 将其作为可选的exempt键解析配置models.py 定义seed.verify_command_gate: Literal[warn, block] warn——当前默认warn门禁seed_verify_gate.py 的unverifiable_criteria()找出既无verify_command又无豁免理由的 ACrender_verify_command_gate_warning()渲染操作员可见警告含 1-based AC 编号与截断到 80 字符的描述。verify_command_gate_mode()在配置缺失或不可读时回退warn——缺失或不可读的配置绝不能变成硬性拒绝运行接线runner.py 的_apply_verify_command_gate()在新会话准备时执行门禁warn模式以黄色打印警告并发出orchestrator.seed.verify_command_gate_warning事件block模式拒绝运行。遵循单调证据规则无法失败的 verify_command 不是漏洞RFC 的Follow-on finding章节提出一个发人深省的问题上述全部改动关心的是在任何机器上忠实交付门禁裁决却从未问过裁决是否有内容。树上的测量结果verify_commandexit 0 - gate passed True verify_commandtrue - gate passed True verify_commandprintf READY - gate passed True required evidence without verify_command: files_touched, commands_run, tests_passed required evidence with verify_command: files_touched后续实现采用单调证据规则而非恒定裁决证明verify 命令添加确定性证据但永不移除files_touched、commands_run、tests_passed义务也永不挽回失败的工人结果。因此exit 0无法削弱接受判定也不需要通用的 shell 状态解释器。这一规则也体现在 verification.py 的文档串中A declared verify command is additive and does not remove transcript obligations声明的 verify 命令是附加性的不移除转写义务以及 seed_verify_gate.py 的模块文档Averify_commandadds an orchestrator-owned machine check; it never replaces transcript obligations and can never recover a failed worker result.当无法解析真实 Bash或命令启动/超时阻止判定时门禁记录不可用结果。成功的工作保持成功被报告为需要确认不触发提供商重试或重派。分阶段发布与范围边界RFC 记录了分阶段发布计划及其落地状态阶段内容状态Phase A_run_ac_verify_gate 新verify_shell.py独立 PR。RFC 修正了决策章节的一个判断POSIX 行为并非与之前等价——create_subprocess_shell实为/bin/sh -cDebian/Ubuntu 上即 dashverify 命令此前在sh下运行现在在bash下运行或根本不运行。两个方向的改变都是有意为之bash 特有写法如今按作者本意运行无 Bash 的机器报告验证不可用绝不记录工人失败或消耗工人重试。Windows 分支通过 monkeypatchos.name、os.environ、shutil.which、Path.exists实现单元测试覆盖无需 Windows CI已交付Phase B3空转写重新分类已交付Phase B1preflight 门禁两阶段Release N 仅警告Release N1 硬拦截待遥测显示现有 seed 违规率可接受。逃生舱为配置seed.verify_command_gate: warn\|block随时间推移默认趋向block无永久退出。进行中/恢复的会话豁免于新门禁的重新评估避免运行中的工作流中途崩溃warn阶段已交付block默认值推迟Release N1明确不在范围内原生 PowerShell/cmd 的verify_command编写支持契约保持POSIX bashTier 2 翻译是唯一让步自动安装 Git Bash / WSL存量 seed 追溯性迁移添加verify_command在空转写重新分类之外重新设计 fat-harness 证据模型本身改变 verify_command 的沙箱/权限模型。推迟项与原因Tier 1 / Tier 2LLM 路由选择与翻译及磁盘机器缓存Tier 0 加隔离已同时避免走进死胡同与伪造通过。决策章节的缓存是为摊薄 LLM 调用而设计未接 LLM 层时为四次 syscall 的查找加磁盘缓存只会引入陈旧性风险。resolve_verify_shell()返回None正是这些层将挂接的接缝持久化转写重新收集尚无逐 AC 的持久化完整工具转写可供重放。事件原生接受契约与轨迹密封单独跟踪在那之前缺失转写证据保持显式UNAVAILABLE绝不导致重复的提供商工作。伴随性抽取#1797模块尺寸棘轮要求两个被触碰模块不可增长orchestrator/verify_gate_outcome.py门禁结果类型、检查点编码、expected_artifactsoracle与bigbang/acceptance_criteria_parsing.py严格 AC JSON 边界。小结一套可移植、不可作弊、不浪费工作的验证契约综合 RFC 与其源码落地可以提炼出本方案的三个可复用设计原则解析而非翻译跨平台契约保持单一 POSIX bash 语法由编排器负责找到真实 bash 或报告不可用永不模拟、永不降级到sh/cmd、永不选择 WSL 启动器基础设施与工人分离验证器基础设施无 Bash、空转写、启动错误、超时是与工人执行正交的独立事实——它保留成功结果、发出操作员可见的 unverified 事件、绝不消耗重试或重派单调证据verify_command只增加确定性证据不豁免files_touched/commands_run/tests_passed义务也不挽回失败结果门禁的裁决永远来自确定性退出码而非 LLM 意见。如需深入源码建议按此路径阅读RFC 原文 → shell 解析实现 → 命令执行与进程保障 → 隔离与事件 → 转写证据校验 → preflight 门禁以及 seed 契约字段 与 配置模型 中的参数定义。赞分享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点击查看免费下载相关推荐Dexter权限拒绝处理永久拒绝与临时拒绝的差异指南Dexter权限拒绝处理永久拒绝与临时拒绝的差异指南 在Android应用开发中权限管理是一个至关重要的环节。Dexter作为一款优秀的Android权限请移动开发认证鉴权Apache Beam SDK Harness 深度解析可移植性框架下的用户代码执行环境与配置实战Apache Beam SDK Harness 深度解析可移植性框架下的用户代码执行环境与配置实战 导读 本文围绕 Apache Beam 的 SDK Har大数据批处理流处理数据工程OPA 生态实践用 Rego 把 AI 治理法规变成可执行的允许/拒绝检查GOPAL 与 AICertify 深度解读OPA 生态实践用 Rego 把 AI 治理法规变成可执行的允许/拒绝检查GOPAL 与 AICertify 深度解读 导读 本文以 Open Polic后端认证鉴权云原生上一篇10 分钟从零到一Docker 部署 Claude AI 应用的完整实操指南下一篇深入探讨 FLUX.1 [schnell]性能优化全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 1:25:41 · 阅读 1.2k Ouroboros verify-gate 的 Windows 可移植性与 fat-harness 过度拒绝治理实战
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点击查看免费下载导读本文以 verify-gate-windows-portability.md 这份已落地实现的 RFC 为核心系统讲解 Ouroboros 接受标准Acceptance CriterionAC验证门禁在跨平台执行与证据判定两方面的演进其一将verify_command从默认使用cmd.exe的asyncio.create_subprocess_shell改造为先解析真实 POSIX Bash、再原样执行命令的分层方案其二修正 fat-harness 在运行期转写缺失时将已完成工作整体拒绝的问题。读者将获得可复制的配置参数、环境变量与源码级证据并理解验证基础设施不可用 ≠ 工人失败这一核心设计原则。背景两个在ooo run中观察到的关联故障RFC 记录了两个相互独立、但都发生在ooo run执行链路上的故障。故障一Windows 上verify_command直接无法解析_run_ac_verify_gate原本通过asyncio.create_subprocess_shell(command, cwdcwd, ...)执行 AC 的verify_commandRFC 指向的原始实现位于src/ouroboros/orchestrator/parallel_executor.py:9843。问题在于verify_command由 seed-architect 按POSIX bash 契约生成天然依赖grep、、单引号、正斜杠路径等 bash 惯用法Python 的create_subprocess_shell在原生 Windows 上默认解析到cmd.exe而cmd.exe完全不理解上述语法因此任何通过verify_command验证的 AC 在 Windows 上都有直接崩溃的风险。故障二fat-harness 的过度拒绝over-rejection没有verify_command的 AC 会回退到基于运行期转写的证据校验_verify_atomic_evidence_against_runtime_messages位于src/ouroboros/orchestrator/evidence/verification.py。当support_messages为空时AC 会被整体拒绝理由是no runtime transcript evidence supports the typed evidence claims。RFC 记录的真实事故是一个 AC 完成了 19 分 34 秒的真实工作测试、编辑却因转写未到达验证器疑似压缩或收集时机问题未确认而被拒绝自动重试随后重跑了整个 AC又烧掉了约 20 分钟。RFC 特别澄清了根因不是job_observer契约src/ouroboros/mcp/tools/job_observer.py只是宿主会话观察后台任务的只读轮询交接与叶子工人自身的工具调用转写无关。真正的分叉点是verify_command是否存在当设置了verify_command时_run_ac_verify_gate运行编排器自己的命令其余证据检查被豁免_fat_harness_acceptance_errorparallel_executor.py:12836-12869只有没有verify_command的 AC才会走脆弱的转写路径。对标研究GJC 的解析真实 shell模式RFC 记录了与 gajae-codeGJC的对比研究。GJC 的收据系统harness-control-plane/receipts.ts使用 sha256 密封的结构化 JSON 信封概念上比转写消息匹配更难篡改但其验证命令执行finalize.ts:315硬编码了Bash.spawnSync([bash, -lc, spec.command], ...)。真正可移植的答案在packages/utils/src/shell-config.ts的getShellConfig()它在每次 shell 命令前解析一个真实的 POSIX 兼容 shell 二进制优先级为用户指定的shellPath→ Git Bash%ProgramFiles%\Git\bin\bash.exe含 x86 变体→ PATH 上的bash.exeCygwin/MSYS2/WSL→ 携带可操作安装提示的显式失败。关键设计是GJC 不按 OS 翻译 bash 语法而是保证真实 bash 存在或大声失败命令作者永远只写 POSIX 语法。决策 Part AWindows 安全的verify_command执行永不破坏的不变量RFC 明确了采用 GJC 模式时必须守住的不变量_run_ac_verify_gate存在的意义是防止工人自报可被作弊。无论在哪里运行如何解析实际的通过/失败必须来自运行那条确切命令或其未修改/固定的翻译的确定性退出码——绝不能来自 LLM 对 AC看起来完成了的意见。三层解析Tiered resolutionRFC 记录了分级方案且注明这是业主批准、取代了早期缺 bash 即硬失败草案层级机制说明Tier 0确定性、免费新增src/ouroboros/orchestrator/verify_shell.py的resolve_verify_shell()沿用get_goose_cli_path()/get_pi_cli_path()的 env → config → PATH 优先级。POSIX/bin/bash然后shutil.which(bash)Windows%ProgramFiles%\Git\bin\bash.exe→ x86 变体 →shutil.which(bash.exe)Cygwin/MSYS2/WSL。OUROBOROS_VERIFY_BASH环境变量覆盖优先且因属于可执行路径变量必须按本仓库.env信任边界规则untrusted_env.py对*_CLI_PATH类变量的 denylist加入 denylistTier 1LLM 咨询仅限路由选择Tier 0 无果时LLM 只接收环境事实候选 shell 路径是否存在、OS、可用解释器从该固定候选集中挑选/构建ExecutionRoute。它永远看不到 AC、工人输出或超出字面字符串的 verify_command 语义。编排器用无害命令echo ok test -d .探测选定路由后才信任。此层不修改verify_command文本Tier 2LLM 翻译密封第二行仅当完全不存在 POSIX 解释器时LLM 将verify_command翻译为 PowerShell/cmd 等价物。为阻断改写为简单命令的失败模式翻译只在执行前 preflight 发生一次、固定进缓存失败后永不重新翻译——没有机会因失败结果而放松命令终局隔离quarantine而非静默通过。若 Tier 1/2 仍无法产出可用路由AC 被标记为environment_unverifiable。运行不会停止业主原话fail 처리로 멈추지마——不要因失败处理而停止但该 AC永不计为验证通过——它在最终报告中以本机无法验证需人工确认呈现。这是同时满足不走进死胡同与不伪造通过的唯一方式。缓存设计成本/延迟控制RFC 设计了两个缓存均以键控方式避免常见路径上的逐 AC 或逐重试 LLM 调用机器缓存~/.ouroboros/verify_route.json键为机器指纹OS 候选路径存在性的哈希。相同指纹 零 LLM 调用翻译缓存键为sha256(verify_command) 机器指纹。重试与重跑均为缓存命中解析在每次ooo run的批量 preflight中针对所有 AC 的 verify 命令执行一次而非按 AC 惰性解析——Tier 0 成功的稳态路径上零新增延迟。_run_ac_verify_gate的改动将create_subprocess_shell(command)替换为create_subprocess_exec(*resolved_route.argv)POSIX 上等效于bash -c command语义与今天一致。VerifyShellUnavailableError从终止性失败降级为进入咨询层的内部信号而非死胡同。已落地实现verify_shell.py 的源码级解析解析优先级与平台分支当前仓库中的 verify_shell.py 完整实现了 Tier 0 与终局隔离。resolve_verify_shell()的核心逻辑如下环境与配置候选_configured_candidate先读OUROBOROS_VERIFY_BASHVERIFY_BASH_ENV_VAR常量再读配置orchestrator.verify_bash_path。注意_config_value()刻意绕过 env-first 访问器——若环境变量已失效env-first 会返回同一个失效值导致配置 shell 永远无法被触达平台候选POSIX 上依次尝试/bin/bash、/usr/bin/bash、PATH 上的bashWindows 上依次尝试%ProgramFiles%、%ProgramW6432%、%ProgramFiles(x86)%下的Git\bin\bash.exegit_bash再是 PATH 上的bash.exe、bashWSL 启动器过滤_is_wsl_launcher识别%SystemRoot%\System32\bash.exe并拒绝。该二进制会把命令交给拥有独立根文件系统的 Linux 发行版门禁传入的 Windowscwd在其中毫无意义——命令将判定另一棵树或为与 AC 无关的原因失败。两种结果都比本机无法验证更糟绝对路径强制_executable只接受解析后的绝对路径。门禁以验证工作区为cwd启动相对路径会在检查时指向一个目录、执行时指向另一个目录——工作区可以借此提供评判自己验收标准的二进制。相对结果一律拒绝并落入下一个候选。为什么必须是 bash而不是shRFC 与源码都强调没有sh回退sh对同一文本的解读不同echo -e X在 bash 下输出X、在sh下输出-e X因此针对-e断言的契约会在其编写时的 shell 下失败、在替代 shell 下通过——那是关于另一条命令的裁决。无 Bash 的机器将验证记录为不可用它从不模拟 Bash也从不把缺失的验证器转化为工人失败。Windows 上永不回退到cmd也永不用%SystemRoot%\System32\bash.exeWSL 启动器。密封身份sealed identity与能力握手capture_verify_shell_identity()密封三要素path路由路径、realpath规范路径、sha256文件内容摘要。在待验证子进程启动前verify_shell_path_from_identity()通过规范路径 文件摘要重新校验身份变更或缺失时保持不可用绝不静默选择新可执行文件。_executes_bash_c_semantics()通过固定能力握手证明某可执行文件实现了 Bash-c契约直接通过 OS 执行[[ -n ${BASH_VERSION:-} ]] || exit 96; exit 37超时 3 秒仅在返回码为 37 时判定通过。该握手按内容摘要缓存避免重复 AC 门禁为同一密封可执行文件再派生子进程探测。它绝不是命令解析器、翻译器、回退 shell 或模拟器。环境的清洗让裁决由编排器意图的工具计算sanitized_verify_environment()从门禁子进程环境中剥离所有能不改变工作区与命令就改变裁决的变量VERIFY_ENV_STRIPPED_KEYS与VERIFY_ENV_STRIPPED_PREFIXES两个常量集Python 注入PYTHONPATH、PYTHONSTARTUP、PYTHONHOMEpytest 注入PYTEST_ADDOPTS仓库自身的.env可设置PYTEST_ADDOPTS-k nothing使每个 pytest 形状的契约不跑任何测试就通过——这正是 RFC/源码注释点名的最尖锐风险之一且它不在 untrusted-env denylist 覆盖范围内、PYTEST_PLUGINSNode 预加载钩子NODE_OPTIONSJS 形状契约的同类风险shell 启动文件BASH_ENVbash 在求值-c命令前会 source 它含exit 0的文件会把bash -c exit 23变成通过——这比弯曲工具配置更尖锐它直接在门禁内运行仓库代码、ENVshell 选项状态SHELLOPTS、BASHOPTS、BASH_XTRACEFD、BASH_COMPAT、PS4xtrace写入断言检查的组合输出、errexit改变链条哪条腿决定状态、xpg_echo改变echo输出分词/路径查找/glob 抑制IFS、CDPATH、GLOBIGNORE前缀剥离LD_PRELOAD、DYLD_INSERT_LIBRARIES动态加载器预加载家族按前缀剥离以覆盖跨平台新增成员、BASH_FUNC_导出的 shell 函数-c命令在解析任何同名可执行文件之前先解析它——名为pytest或git的函数会替换契约本要运行的工具。PATH刻意不剥离verify 命令通过它解析真实工具uv、pytest、node项目本地.venv/bin条目既常见又合法。project_verify_environment()进一步通过with_project_venvcore/project_env把项目虚拟环境置为最先解析因为任务工作树缺少被 gitignore 的项目虚拟环境。解析缓存与重试语义resolve_verify_shell()的缓存键_cache_key指纹化所有输入平台、OUROBOROS_VERIFY_BASH、配置路径、PATH、SYSTEMROOT、三个 Git-for-Windows 安装根变量。注释点明遗漏任何一项都会在变更后继续提供首次解析的路由——这正是缓存要避免的过期解释器。两个细节值得注意只有成功解析才被缓存。失败每次调用都会重新解析因为重试不可验证 AC的全部意义在于操作员可以在运行继续期间安装 Git Bash 或设置OUROBOROS_VERIFY_BASH。Git Bash 通过%ProgramFiles%而非PATH找到因此以PATH为键的无 shell缓存永远不会注意到新安装从而破坏它本要服务的重试reset_verify_shell_cache()提供测试与环境变更所需的缓存清空入口。配置项与环境变量RFC 的Implementation status部分与 loader.py 确认了完整参数面环境变量OUROBOROS_VERIFY_BASH——指向 bash 可执行文件的绝对路径优先级最高配置文件orchestrator.verify_bash_path——config.yaml中orchestrator段下的路径项denylistOUROBOROS_VERIFY_BASH与 shell 启动/选项控制BASH_ENV、ENV、SHELLOPTS、BASHOPTS、BASH_FUNC_*一同被加入 untrusted-.envdenylist见 untrusted_env.py 中与各*_CLI_PATH变量并列的条目。源码注释明确理由仓库.env若把OUROBOROS_VERIFY_BASH指向自己的二进制就会在验证门禁——这个必须保持不可篡改的地方——内执行任意代码行为前提解析在原生 Windows 上依赖 Git for Windows或 Cygwin/MSYS2 提供的 PATH 内 bash无 Bash 的机器含纯 PowerShell/cmd 环境会得到验证不可用而非工人失败。已落地实现不可用结果的隔离与事件化verify_quarantine.py 实现了 Part A 的终局隔离quarantine_unverifiable_result()保留成功的工人结果存储不可用的门禁结果发出操作员可见事件且永不消耗重试事件类型为execution.verify.unverifiable负载包含session_id、execution_id、ac_index、ac_content、verify_command、reason、verify_cause、状态unverifiedquarantine_reason()生成面向操作员的解释Verification unavailable: ... work result requires confirmation.验证不可用……工作结果需确认render_unverifiable_summary()在最终报告中呈现Succeeded without machine verification (N), needs confirmation: AC ...无机器验证地成功N 个需确认AC …启动错误与超时走同一路径verify_command_runner.py的VerifyRun将start_error与timed_out与returncode分开因为门禁不能把无法启动或运行过久读作普通非零退出——它们是关于运行的不同事实。verify_command_runner.py 提供了 Windows 上的进程生命周期保障子进程以挂起CREATE_SUSPENDED方式创建先分配进 kill-on-close 的 Windows Job Object_create_windows_job通过 ctypes 调用CreateJobObjectW/AssignProcessToJobObject再恢复主线程——保证超时终止时进程树可整体回收。POSIX 侧使用start_new_session加进程组SIGKILL。子进程 stdin 固定为DEVNULL因为 MCP 宿主下那是 JSON-RPC 流且任何沙箱路径规则之前打开的描述符都可用。最终的结算settlement会重新校验工件与工作区状态但从不把不可用验证转化为工人失败。BLOCKED与可重试失败类仍保留给工人/运行时失败验证器基础设施是独立事实不进入路由升级或工人重派。决策 Part B缩小 fat-harness 的爆炸半径RFC 提出三条措施默认把 AC 推向verify_command。扩展现有 seed preflight 门禁RUN 之前的确定性可执行性检查新增拦截器如ac_missing_verify_command针对既无verify_command又无显式豁免理由新增字段AcceptanceCriterionSpec.verify_exemption_reason的 AC。更新 seed-architect 的 prompt优先verify_command不可行时必须给出理由。_run_ac_verify_gate对转写丢失与自报作弊都免疫——它是唯一同时降低误接受与误拒绝的选项因此这是首要修复而非放宽转写检查本身重新分类空转写拒绝。在_verify_atomic_evidence_against_runtime_messages中为support_messages完全为空的情形单独给出原因码如transcript_missing_infrastructure复用现有*_transient_exhausted代码约定而非泛化的工人拒绝。该码路由到更窄的重试重新收集一次转写而非重跑整个 AC。事故中 19 分 34 秒的真实已完成工作绝不应被整体丢弃——空转写是收集失败的信号不是作弊信号作弊的工人会留下貌似合理的消息而不是什么都不留被否决的替代方案当support_messages为空时回退到工作区 diff/mtime 作为替代信号。否决理由可被作弊touch即可满足且破坏 fat-harness 存在的意义。已落地实现B3 转写不可用与 B1 警告阶段B3空转写 基础设施信号verification.py 已实现重新分类。核心逻辑验证器按身份而非位置排除叶子工人的终局自报消息message.is_final——harness 观察消息可能合法地出现在最终结果消息之后若剩余支持消息全部是 harness 观察消息即没有任何真实运行时转写到达且有效证据模式有必填字段则返回VerifierVerdict(passedFalse, ...)原因码为transcript_missing_infrastructure: the runtime transcript reached the verifier empty, so no claim could be checked; the leafs work was not evaluated失败类为FailureClass.TRANSCRIPT_MISSING_INFRASTRUCTURE.value注释点明命名逻辑空转写是基础设施信号而非作弊信号——试图作弊的叶子会留下貌似合理的消息而不是什么都不留。独立命名让丢失的转写不会被报告为工人拒绝也不会被解读为叶子什么都没做的证据若有效模式无必填字段not effective_schema.required直接返回通过——纯验证运行可能诚实地无事可做。RFC 的实现状态确认完全空的support_messages投影产生VerifierStatus.UNAVAILABLETRANSCRIPT_MISSING_INFRASTRUCTUREACCEPT准入。已完成工作保留为未验证成功不触发工人重试或重派。B1verify_exemption_reason与seed.verify_command_gate字段seed.py 中AcceptanceCriterionSpec.verify_exemption_reason为str | None描述强调它是按 AC 的显式逃生舱绝不是一揽子退出。校验器强制其与verify_command互斥同时存在抛ValueErrorverify_command存在时它会随规范化、语义身份迁移存活execution_acceptance.py 中的传递与比对逻辑解析acceptance_criteria_parsing.py 将其作为可选的exempt键解析配置models.py 定义seed.verify_command_gate: Literal[warn, block] warn——当前默认warn门禁seed_verify_gate.py 的unverifiable_criteria()找出既无verify_command又无豁免理由的 ACrender_verify_command_gate_warning()渲染操作员可见警告含 1-based AC 编号与截断到 80 字符的描述。verify_command_gate_mode()在配置缺失或不可读时回退warn——缺失或不可读的配置绝不能变成硬性拒绝运行接线runner.py 的_apply_verify_command_gate()在新会话准备时执行门禁warn模式以黄色打印警告并发出orchestrator.seed.verify_command_gate_warning事件block模式拒绝运行。遵循单调证据规则无法失败的 verify_command 不是漏洞RFC 的Follow-on finding章节提出一个发人深省的问题上述全部改动关心的是在任何机器上忠实交付门禁裁决却从未问过裁决是否有内容。树上的测量结果verify_commandexit 0 - gate passed True verify_commandtrue - gate passed True verify_commandprintf READY - gate passed True required evidence without verify_command: files_touched, commands_run, tests_passed required evidence with verify_command: files_touched后续实现采用单调证据规则而非恒定裁决证明verify 命令添加确定性证据但永不移除files_touched、commands_run、tests_passed义务也永不挽回失败的工人结果。因此exit 0无法削弱接受判定也不需要通用的 shell 状态解释器。这一规则也体现在 verification.py 的文档串中A declared verify command is additive and does not remove transcript obligations声明的 verify 命令是附加性的不移除转写义务以及 seed_verify_gate.py 的模块文档Averify_commandadds an orchestrator-owned machine check; it never replaces transcript obligations and can never recover a failed worker result.当无法解析真实 Bash或命令启动/超时阻止判定时门禁记录不可用结果。成功的工作保持成功被报告为需要确认不触发提供商重试或重派。分阶段发布与范围边界RFC 记录了分阶段发布计划及其落地状态阶段内容状态Phase A_run_ac_verify_gate 新verify_shell.py独立 PR。RFC 修正了决策章节的一个判断POSIX 行为并非与之前等价——create_subprocess_shell实为/bin/sh -cDebian/Ubuntu 上即 dashverify 命令此前在sh下运行现在在bash下运行或根本不运行。两个方向的改变都是有意为之bash 特有写法如今按作者本意运行无 Bash 的机器报告验证不可用绝不记录工人失败或消耗工人重试。Windows 分支通过 monkeypatchos.name、os.environ、shutil.which、Path.exists实现单元测试覆盖无需 Windows CI已交付Phase B3空转写重新分类已交付Phase B1preflight 门禁两阶段Release N 仅警告Release N1 硬拦截待遥测显示现有 seed 违规率可接受。逃生舱为配置seed.verify_command_gate: warn\|block随时间推移默认趋向block无永久退出。进行中/恢复的会话豁免于新门禁的重新评估避免运行中的工作流中途崩溃warn阶段已交付block默认值推迟Release N1明确不在范围内原生 PowerShell/cmd 的verify_command编写支持契约保持POSIX bashTier 2 翻译是唯一让步自动安装 Git Bash / WSL存量 seed 追溯性迁移添加verify_command在空转写重新分类之外重新设计 fat-harness 证据模型本身改变 verify_command 的沙箱/权限模型。推迟项与原因Tier 1 / Tier 2LLM 路由选择与翻译及磁盘机器缓存Tier 0 加隔离已同时避免走进死胡同与伪造通过。决策章节的缓存是为摊薄 LLM 调用而设计未接 LLM 层时为四次 syscall 的查找加磁盘缓存只会引入陈旧性风险。resolve_verify_shell()返回None正是这些层将挂接的接缝持久化转写重新收集尚无逐 AC 的持久化完整工具转写可供重放。事件原生接受契约与轨迹密封单独跟踪在那之前缺失转写证据保持显式UNAVAILABLE绝不导致重复的提供商工作。伴随性抽取#1797模块尺寸棘轮要求两个被触碰模块不可增长orchestrator/verify_gate_outcome.py门禁结果类型、检查点编码、expected_artifactsoracle与bigbang/acceptance_criteria_parsing.py严格 AC JSON 边界。小结一套可移植、不可作弊、不浪费工作的验证契约综合 RFC 与其源码落地可以提炼出本方案的三个可复用设计原则解析而非翻译跨平台契约保持单一 POSIX bash 语法由编排器负责找到真实 bash 或报告不可用永不模拟、永不降级到sh/cmd、永不选择 WSL 启动器基础设施与工人分离验证器基础设施无 Bash、空转写、启动错误、超时是与工人执行正交的独立事实——它保留成功结果、发出操作员可见的 unverified 事件、绝不消耗重试或重派单调证据verify_command只增加确定性证据不豁免files_touched/commands_run/tests_passed义务也不挽回失败结果门禁的裁决永远来自确定性退出码而非 LLM 意见。如需深入源码建议按此路径阅读RFC 原文 → shell 解析实现 → 命令执行与进程保障 → 隔离与事件 → 转写证据校验 → preflight 门禁以及 seed 契约字段 与 配置模型 中的参数定义。赞分享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点击查看免费下载相关推荐Dexter权限拒绝处理永久拒绝与临时拒绝的差异指南Dexter权限拒绝处理永久拒绝与临时拒绝的差异指南 在Android应用开发中权限管理是一个至关重要的环节。Dexter作为一款优秀的Android权限请移动开发认证鉴权Apache Beam SDK Harness 深度解析可移植性框架下的用户代码执行环境与配置实战Apache Beam SDK Harness 深度解析可移植性框架下的用户代码执行环境与配置实战 导读 本文围绕 Apache Beam 的 SDK Har大数据批处理流处理数据工程OPA 生态实践用 Rego 把 AI 治理法规变成可执行的允许/拒绝检查GOPAL 与 AICertify 深度解读OPA 生态实践用 Rego 把 AI 治理法规变成可执行的允许/拒绝检查GOPAL 与 AICertify 深度解读 导读 本文以 Open Polic后端认证鉴权云原生上一篇10 分钟从零到一Docker 部署 Claude AI 应用的完整实操指南下一篇深入探讨 FLUX.1 [schnell]性能优化全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考