Partial runtime evidence
Partial runtime evidence【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagentQuestion being verified具体的断言例如 Opus 4.7 默认 effort 是 highAvailable signalsTier 1: 调试日志 /tmp/trace.log 第 47-49 行显示effort: high✓Tier 3: 对 m5T() 函数的静态提取在 smart 模式下返回 high ✓Tier 6: 通过阅读 prompt-builder.js 核实了代码路径 ✓Independence assessmentTier 1 和 Tier 3 是独立的——该日志由不同于 m5T() 的代码路径发出 如果静态阅读有误两者会产生分歧。ConclusionVERIFIED 基于 Tier 1 Tier 3 一致。无需升级。### 无法达标时的明示要求 如果你既做不到一次完整的 Tier 2 捕获、也凑不出上表中两条独立的非 Tier 6 信号**必须在交付物中写下显式说明** ⚠️ 部分证据结论。完整出站载荷因 [原因] 无法捕获。结论建立在 - [信号 A —— 层级与来源] - [信号 B —— 层级与来源] 未来的验证应在 [条件] 满足时尝试 [缺失的层级]。 这条规则与 [02-investigate.md](https://link.gitcode.com/i/c606cd65b501441f00a49dabda810755) 的证据纪律一脉相承**只记录逐字原值不转述**——messages.length0 是证据messages 看起来是空的只是对观测的记忆而记忆是调试会话的坟墓。 --- ## Verification Oracle 模式用于非调试任务 技能主流程的 Oracle Triple[04-oracle-triple.md](https://link.gitcode.com/i/852f8b472c1c38bc88d26bc2ba3fb9e0)服务于**卡死的调试**——连续 2 轮失败、思维困在盒子里、需要三个正交框架来打破。 而对于交付物是**工件而非 Bug 修复**的任务逆向工程、提取、审计、合规文档要使用另一种模式**单个 Oracle、时机靠后、态度怀疑、交付物在手**。 ### 何时调用 - 就在宣布提取/审计任务完成之前 - 交付物每次重大修订之后不是每次小编辑后 - 在升级给用户之前最多迭代 3-4 次 ### 模式模板task(subagent_typeoracle, load_skills[], run_in_backgroundfalse, prompt SKEPTICAL FINAL VERIFICATION — 请保持批判寻找任务不完整或出错的理由。Original task逐字粘贴用户请求What I produced工件列表带路径和简要描述Specific claims to verify交付物中每一个具体断言的列表Where to lookOracle 应 Read / Bash 核实的路径Your job阅读交付物。对照交付物引用的来源/证据逐条抽查每个断言。找出任何无依据的断言、缺失部分或事实错误。以 PASS / FAIL / PARTIAL 结尾并列出具体缺口。 保持怀疑。不要盖章放行。 )### 与 Oracle Triple 的区别 | | Oracle Triple调试 | Verification Oracle工件 | |---|---|---| | 触发时机 | 2 轮假设失败后 | 即将宣布完成时 | | 数量 | 3 个并行、正交框架 | 1 个串行、聚焦审查 | | 目标 | 打破思维盒子 | 抓住无依据的断言 | | 提示词语气 | 头脑风暴式发散 | 怀疑式审计 | | 迭代方式 | 之后重置假设集 | 修复缺口、重新调用直到 PASS | ### 不要混淆两者 卡在调试中就做 Triple手握交付物需要审计就做 Verification Oracle。对一个已经完成的提取任务跑 Triple会得到三条分叉的你为什么不试试……的题外话那不是你需要的对卡住的调试会话跑 Verification Oracle只会得到一句你已经知道的礼貌版证据不完整。 仓库佐证[04-oracle-triple.md](https://link.gitcode.com/i/852f8b472c1c38bc88d26bc2ba3fb9e0) 开头就醒目标注⚠️ 非调试任务用错了工具并链接回本文档的 Verification Oracle 模式[SKILL.md](https://link.gitcode.com/i/2634dbafe6b06f0b29dffed1cdd79235) 的跨方法参考表中也单独列出了这一节强调Verification Oracle 不是 Oracle Triple——去读文件。另外注意 [02-investigate.md](https://link.gitcode.com/i/c606cd65b501441f00a49dabda810755) 中 debug-squad 团队规范明确规定 **Oracle 是团队成员的硬拒绝类型**——Oracle 只在 Phase 4 单独使用。 --- ## 常见部分证据反模式 | 反模式 | 为什么失败 | 替代方案 | |---|---|---| | 代码里看起来对所以它能工作 | 只有 Tier 6未验证 | 至少加一条 Tier 1-3 信号 | | 我跑过一次没报错所以正确 | 没有错误 ≠ 正确 | 捕获实际输出并核验内容 | | Mock 返回了我写的值所以代码没问题 | 同义反复——Mock 把你的假设循环回来了 | 改用 Tier 2代理或用 Tier 3 交叉核验 | | 厂商仪表盘显示我的调用成功了 | 仪表盘往往只显示状态码不显示行为 | 有可用时与 Tier 1 组合 | | 我信最新的 Stack Overflow 答案 | 代码来自不同版本/语境 | 对照你手上真实的二进制验证 | 这些反模式与 [06-fix.md](https://link.gitcode.com/i/e51e2e92c10026da61d03a273e224818) 的根因确认原则互相印证**只有切换疑似原因能切换 Bug才叫根因确认**类型检查或编译通过永远不能代替运行真实用户场景。 --- ## 部分证据工作的清理补充 调试技能的第二条纪律是不留痕迹Leave no trace完整清理走 [09-cleanup.md](https://link.gitcode.com/i/8dbed8431376fafd22cd574cc4dcb345) 的 Phase 9。部分证据工作会产生代理、日志、shim 库和 shell 环境变量等特有工件本文档给出专属清理命令 bash # 代理工件 pkill -f mitmproxy 2/dev/null rm -f ~/.mitmproxy/cache_* 2/dev/null # 调试日志文件 rm -f /tmp/trace.log /tmp/*-debug-trace.log # DYLD_INSERT / LD_PRELOAD shim 库 rm -f /tmp/*.dylib /tmp/*.so # 确保 shell 中设置的 env 变量不被持久化 unset HTTPS_PROXY APP_DEBUG APP_LOG_LEVEL APP_LOG_FILE 2/dev/null【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考