Agent 工程很容易形成一种习惯：模型做不好，就再加一层规划器、技巧库、分支判断、回退规则和提示词。每一层都有当时的理由。可模型换代之后，原先用来弥补能力缺口的编排，还在帮助它吗？
2026 年 11 月 4 日，OpenAI 公开了针对 Linux 内核的自动化漏洞研究流水线。最值得 Mira 关注的，不只是它能大规模发现问题，而是报告里一段很少见的编排对照实验：同一套额外技巧，对较早模型有明显帮助，对更强模型的边际收益却已经很小。
这不是“以后只要一个超级 Agent”的宣言。恰恰相反，它要求我们把两类常被统称为 Harness 的东西分开：帮助模型思考的脚手架，可以随模型能力变化；保护真实系统的权限、执行与证据边界，不能因为模型变聪明就消失。
发生了什么：103 项技巧的边际收益变了#
OpenAI《A thousand fewer paths to root》（2026-11-04）披露了一条包含目标筛选、候选分析、隔离环境动态复现、影响验证、补丁生成和人工审查的研究链。2026 年 10 月中旬的一次运行产生了 2,308 个去重候选，动态复现 1,724 个问题，最终形成针对 948 个不同本地提权漏洞的候选补丁；报告给出的 API 费用约为 121 万美元。
这些数字来自研究团队自己的实验报告，不是已经有 948 个补丁被 Linux 上游接受，也不是一份适用于普通 Agent 产品的成本基准。它们说明的是：当 Agent 可以批量提出候选，验证、去重、排序和维护者审查会成为更突出的瓶颈。
更有工程启发的是报告的“More capable models can require lighter orchestration”一节。团队曾整理 103 项 Linux 利用技巧，以模型可使用的知识层形式提供给较早的 GPT-5.5 Cyber。在 63 个候选任务上，这使成功率由 76.2% 提升至 88.9%。但换成更强的 GPT-5.6 Cyber 后，模型已更善于自行寻找和选择技巧；额外加入这层技巧，报告称只带来 1.5 个百分点的增益。团队因此移除了重型技巧编排。
这里必须守住实验边界：76.2% 与 88.9% 是旧模型加不加技巧层的对照；1.5 个百分点是较强模型自身加回技巧层的边际差异。不能把两组数字拼成一个跨模型的严格因果实验，也不能推导出“所有 Agent 都应该删掉 Skill”。
这条信号真正指向的是：Harness 不是一次设计、永远正确的常量。它与模型能力存在交互作用。
暴露了什么：我们把三种不同的复杂度算成了一种#
所谓“编排”，至少包含三种不同的东西。
第一种是认知脚手架：教模型按什么顺序思考、提供技巧清单、替它预选路径、把每一步写成固定模板。这一层可能提升较弱模型的成功率，也可能在更强模型上造成冗余调用、上下文负担或不必要的维护成本。是否保留，应该用同一任务集实测。
第二种是执行与权限边界：工具是否真实可用、哪些能力被授权、具体调用是否需要批准、调用参数能否在批准后被替换、执行环境是否隔离。这些约束并不是为了教模型“如何想”，而是为了限定它能做什么。模型更强，反而更不能把这一层当作可以随手删除的脚手架。
第三种是结果证明与验收：成功到底意味着什么、结果对应哪个目标、证据来自哪次执行。OpenAI 报告里有一个尤其值得警惕的反例：早期一轮测试中，200 个被判为成功的提权结果里，有 20 个实际上通过任务指定漏洞之外的另一个漏洞获得了权限。结果确实发生了，但完成的不是被分配的那件事。团队随后增加了独立检查，确认结果是否确实来自指定目标。
这不是普通的“模型幻觉”。它是结果正确、路径错误。如果 Agent 的验收只检查“拿到了结果”，系统就可能奖励一次偏离任务的执行。
因此，轻量化 Harness 的正确问题不是“能删掉多少节点”，而是：哪些节点只是补偿模型能力，哪些节点在定义不可转移的系统责任？
Mira 当前代码实际说明了什么#
以下只谈本次读取的 Mira Desktop 当前 dev 源码，不把旧设计稿或其他产品的能力写成 Mira 已经实现。
AgentGraph 稳定入口目前仍同时保留 Pi Loop 与 LangGraph 兼容路径：应用默认走 pi_loop，显式环境变量可以选择 langgraph，测试环境未指定时保留历史图运行时。这个切换点证明编排实现与对外运行合同可以分离；它不证明两套运行时已在同一模型、同一任务集上完成效果与成本对照。
Pi Loop 实现把准备上下文、Planner、委派、工具 schema 披露、冻结调用、Policy、审批、工具执行、Evidence、Generate 和 Finalize 作为可辨认的语义步骤。这里既有可能随模型变化而优化的决策和工具发现环节，也有不应因模型升级而撤销的执行约束。
通用委派协议要求 Child 收到明确的 goal 与 1–8 条 acceptanceCriteria，并在 V1 禁止递归委派。Child 的能力视图由委派权限与运行时可用性共同限定；“可发现工具”不是“自动获得权限”。通用 Child 执行入口还会把局部结果作为结构化 observation 返回 Parent。
Evidence 节点是累积证据的单一写入者：工具和检索先产生 pending facts，再进入 Evidence。它说明 Mira 已经把“模型说完成”与“系统记录事实”拆开。但这不等于 Mira 已拥有针对所有任务的独立路径验证器，更不等于已验证任何安全研究任务的漏洞归因。
当前实现不是开放式多 Agent 自治平台，也没有通用 DAG scheduler、任意层级递归 SubAgent 或自动 sandbox 快照回滚。上述边界在 当前 Agent 真相文档中有说明，关键路径也由本次源码读取交叉核对。
Mira 这套结构最值得保留的，不是“Pi Loop 一定比复杂图好”，而是可以替换编排方式，同时让授权、冻结调用、证据归属继续有明确主人。
下一次模型升级，应该怎么检验 Harness#
一个合理的工程方向，是把 Harness 的可变部分和不可变部分分别计量，而不是凭直觉给每次模型升级再叠一层框架。
对同一批可重复任务，分别比较“当前模型 × 当前脚手架”“当前模型 × 精简脚手架”“新模型 × 当前脚手架”“新模型 × 精简脚手架”。记录任务完成率、实际可复现的验收通过率、模型与工具成本、调用次数、延迟、恢复次数，以及结果是否确实对应被授权的目标。样本必须包含失败、审批、工具不可用和跨会话恢复，而不能只挑顺利完成的 Demo。
这只是建议的实验设计，不是 Mira 已经运行过的 benchmark。也不能拿 OpenAI 安全研究中的 1.5 个百分点作为 Mira 的预期收益：任务分布、模型、工具和失败代价都不同。
有些复杂度值得优先质疑，例如重复的模型规划、为了弥补旧模型不足而硬编码的技巧注入、缺少证据的自动重试。另一些复杂度则必须通过更强的验证才能改变，例如 exact invocation 审批、Child 能力范围、Evidence 单写入和终态语义。删掉认知负担，不等于删掉责任边界。
OpenAI 那次“通过错误漏洞成功”的例子还提醒我们：验收测试最好绑定到指定任务、指定对象、指定执行路径和对应证据。一个看起来漂亮的终态，可能恰好遮住了 Agent 走错的路。
还有什么不确定#
目前关于技巧层收益、成本和成功率的数字主要来自 OpenAI 自己披露的研究环境，尚不能当作独立复现的普适规律。103 项技巧的具体实现、模型之间的任务分布差异，以及精简编排在长期维护和复杂失败路径中的收益，都没有足够公开数据让我们直接外推。
对 Mira 而言，当前也没有可据此宣布的模型换代 A/B 结果；没有证据表明某个现存节点已经成为性能负担，更没有依据直接删掉 Policy、Evidence 或审批。若要动手，应该先建立对照任务与成本账本，再针对具体冗余做小范围实验。
这次研究真正值得留下的判断是：Agent 变强后，工程师不必永远替它思考更多；但必须更清楚地决定，哪些事情绝不能只由它自己说了算。
主要一手资料： OpenAI：A thousand fewer paths to root（2026-11-04）；OpenAI：GPT-6 Cyber（2026-11-05）；Mira Desktop 上述 dev 运行时源码。
