Agent 能接进 IDE为什么还不能随意互换假设你正在给团队的开发工作台加一个审查入口开发者选中一批改动点“审查”结果统一显示在侧栏。第一版接 Codex第二版想再接一个审查 Agent。界面没有变化看上去只要换掉调用目标。但同一个codex-plugin-cc插件里两种都叫“审查”的功能就已经不是同一种请求和返回值普通审查调用 Codex 内置 reviewer反方审查自行收集上下文、构造提示词再要求一份结构化结果。这个差异比“未来 IDE 会有多少 Agent”更值得先弄清。一个 Agent 能被工作台调用只证明入口接通要让它能被另一执行者替换还需要保持输入含义、运行状态和结果解释一致。下面沿这两条现成路径看一次替换需要改什么。工作台接入场景是设计例子源码分析没有执行真实跨 Agent 替换。一个审查入口已经有两种任务定义截至 2026-09-22本次核对的官方插件main指向提交db52e28。在这个固定版本的executeReviewRun中普通Review分支先转换并校验审查目标再调用runAppServerReview其余这里讨论的反方审查分支则调用collectReviewContext把上下文和关注点交给提示词构造函数。1区别最容易从自定义关注点看出来。validateNativeReviewRequest遇到非空focusText就报错提示改用/codex:adversarial-review。这不是让模型试着理解后再拒绝而是在进入普通审查前就明确限制输入。因此“审一下这批改动”和“专门挑战这批改动的重试设计”不能在客户端里无条件当成同一种请求。前者有内置审查目标的表示方式后者需要把自定义问题组织进输入上下文。即使执行者都叫 Codex这个差异也没有被模型名称消除。对工作台来说用户选择了一个 Agent 之后仍要回答一个更具体的问题它接受哪一种任务如果新执行者没有相同的目标选择能力适配层——把工作台请求转换成执行者请求的那段代码——就得补齐等价输入或者明确显示“不支持”。静默丢掉关注点会让界面看起来成功实际审查的却是另一个问题。协议负责把任务送进去调用方仍要选对方法沿着普通审查往下走runAppServerReview先创建线程再发送review/start请求中带着线程、交付方式和审查目标。反方审查则经runAppServerTurn发送turn/start其中包含文本输入和outputSchema。2把这两个调用并排差异很直观插件路径发送给 App Server 的任务插件准备的输入返回后主要处理什么普通审查review/start转换后的原生审查目标reviewText交给原生审查渲染函数反方审查turn/start自行收集的上下文、提示词、输出 schema最终消息解析后交给结构化审查渲染函数这是固定源码的调用关系不能把表里的第二行当成所有 Agent 都支持的统一标准。当前官方 App Server 文档也分别列出了这两个方法并区分 Thread、Turn 与 Item线程承载会话轮次承载一次请求及随后的工作条目承载过程中产生的内容。客户端要处理开始、增量与完成等事件。3协议提供的是可管理的调用方式不会替工作台定义“这个审查按钮究竟承诺检查什么”。同样是 JSON 消息也不会自动具有相同的目标选择、事件顺序或返回含义。换执行者时需要重新检查的是这段翻译关系如果现有执行者完全满足需求就没有必要为了“多 Agent”先造一个通用调度平台。相同的成功状态装不下两种结果插件对普通审查保留reviewTextrenderNativeReviewResult将其作为文本展示。这个分支没有把审查文本统一转换成反方审查使用的verdict、findings等字段。这里描述的是该插件的消费方式不是声称 Codex 内置审查器不存在任何内部结构。14反方审查的输出约定则写在review-output.schema.json中顶层需要verdict、summary、findings、next_steps其中 verdict 的允许值是approve和needs-attention。5返回后还有连续的处理步骤。parseStructuredOutput先尝试 JSON 解析renderReviewResult再检查顶层形状缺少必要的字符串或数组时展示结构错误和原始内容而不是直接按正常审查结果排版。这个形状检查有自己的有限范围不能等同于运行时完整执行了整份 JSON Schema更不能证明发现的问题真实存在。24另一个容易被界面抹平的差异是执行状态。buildResultStatus把最终 Turn 的completed映射为 0其他情况映射为 1。它回答的是本轮执行是否完成不是在读取verdict后判断代码能否合并。2假如一个接入方只看退出状态为 0就给侧栏画绿色勾选它会把“执行完成”误当成“审查认可”。反过来只要没有可解析 findings 就填空数组也会混淆“没有得到结构化结果”和“审查后没有发现问题”。这些是从源码差异推导的接入风险不是本次观测到的线上故障。把第二个审查 Agent 接进一次真实形状的任务把“换一个执行者”展开到足够具体才能看出适配工作在哪里发生。下面仍是构造案例用来推演接入设计没有调用第二个模型也没有获得可比较的运行结果。设想团队正在修改订单服务同一笔支付通知可能重复到达实现者为数据库写入增加了幂等判断。开发者在工作台选择这次提交要求审查重复通知是否仍可能产生第二条订单。第一版工作台调用 Codex准备再接一个只接收文本上下文、返回自然语言报告的执行者 B。这里刻意不假定 B 兼容 Codex 的接口。它的能力只是案例条件不对应某个真实产品。接入目标也很窄让开发者在同一侧栏阅读两种执行者的审查结果不自动修改文件或批准合并。第一处要适配的是输入。工作台不能把“当前改动”四个字原样转给 B 就算完成交接。用户选择的是哪次提交、比较基线是什么、相关文件内容来自哪个版本都要随任务留下记录。对于能读取工作区的执行者可以传入它支持的审查目标并记录实际解析到的版本对于只能接收文本的 B就需要提供对应差异和必要上下文。这不是要求把整个仓库塞进提示词。假设风险取决于数据库唯一约束只给订单函数的几行 diffB 可能根本看不到决定结论的条件。适配器要么补充相关表结构和调用入口要么在报告上保留“未提供数据库约束”的缺口。前者增加输入和准备成本后者限制结果可用范围两者都比悄悄把缺失上下文当成已检查更诚实。同时自定义关注点必须被保留。案例问的是重复通知而源码中的普通/codex:review路径不接受自定义focusText。如果工作台承诺一定审查这个问题就不能只因为普通命令容易调用而丢掉它需要选择能承载关注点的路径或者告知用户该入口只提供一般审查。这个约束来自固定插件实现不能泛化为 App Server 本身禁止自定义目标。第二处是运行中的归属。工作台创建的审查任务可以有自己的任务编号再关联 Codex 或 B 返回的执行标识。用户稍后切到另一批代码时迟到的报告仍应回到原来的任务而不是覆盖当前侧栏。若任务只有同步文本返回也可以先支持这一种简单模式没有必要为了统一外观虚构进度百分比或取消能力。假设用户等待期间又改了一次订单函数。B 最终返回“幂等判断之后仍有一次写入窗口”。工作台首先要显示这条结论对应的是送审时的旧版本。接下来是让开发者核对该问题是否还存在或者对新版本重审而不是偷偷把旧结果改挂到最新代码行。任务身份在这里服务的是结果归属并不要求恢复两个产品内部相同的会话历史。第三处才是结果转换。B 的原始报告没有文件位置工作台就保留原文并标注“尚未定位”不能从“订单函数”猜出一个文件路径再制造一条看似精确的行内评论。如果后续让另一个模型提取文件和行号提取结果仍需对照送审版本检查且应保留它来自转换步骤这一事实。否则接入层会把不确定性洗成结构化字段下游反而更难发现问题。最后开发者核对后发现数据库确有唯一约束但重复通知仍会触发一次多余的外部调用。这时可以记录哪些原始意见被采纳、哪些被证据排除以及实际需要修复什么。不能因为报告中的一处推断有误就把整次执行标成失败也不能因为执行完成就默认接受它的每条判断。沿这条过程走完第二个 Agent 已经可以成为工作台里的一个可用执行者但还没有变成 Codex 的无差别替身。它可能缺少工作区读取、结构化输出、进度事件或取消能力。工作台需要让这些差异可见再决定当前任务是否还能等价地交给它。用一份映射记录验收接入下面这份映射记录可以直接用于讨论接入方案。它是作者建议的工作台设计不是官方插件已有字段也不是完成过的兼容性验收工作台要保留的含义从插件现有路径看到的约束替换时要作出的决定审查对象与自定义关注点普通路径校验原生目标且拒绝自定义关注点反方路径自行组织上下文记录新执行者实际收到的对象不支持的关注点明确拒绝或交回调用方本轮执行结果Turn 完成状态被转换成执行状态把执行失败、中断与审查意见分开显示保留执行者自己的任务标识可供后续使用的审查内容一条路径消费文本另一条解析并检查结构保留原始输出只有可验证的字段才进入统一显示或后续动作能否推动下一步执行状态与结构化 verdict 来自不同处理位置单独定义采纳条件“需关注”进入核对结构缺失不自动变成“无发现”这张记录要围绕一个真实任务填写而不是先为所有 Agent 发明通用字段。第一步可以只支持“人工读报告”这一种用途后续确实需要自动定位或修复分派时再补相应适配。接入层的价值是让调用方清楚哪些含义已被保留、哪些仍需要判断。哪些职责留在工作台哪些交给执行者这个例子也解释了工作台为什么不能只是模型选择器。具体推理过程可以由执行者承担但用户选了什么任务、结果归到哪里、什么条件下可以推动下一步需要有稳定的管理位置。以下是基于案例的设计建议不是对官方插件已有能力的完整描述。工作台首先保存的是用户意图和任务身份。订单审查的输入版本、关注点、允许的操作、结果用途不能只存在于某个 Agent 的长对话里。换一个执行者后这些信息仍然需要成立。执行者内部如何命名会话、如何拆解工作可以不同工作台只保留完成追踪所需的映射不必接管所有内部状态。适配器则处理产品差异怎样把审查目标转换成请求怎样接收事件怎样保存原始输出怎样解释错误。它不应为了迎合统一界面而宣称执行者具备不存在的能力。例如B 没有可靠的中断接口适配器就不能把“用户不再等待”显示成“远端已停止”。最低限度应区分界面等待结束与执行是否确认终止涉及重试时也不能假定前一次工作没有继续发生。执行者负责在给定条件下完成分析但它生成的自述不应成为工作台唯一的事实来源。它说“检查了数据库约束”调用方仍应能追溯送入了什么材料或取得了哪些可核对的工具证据。本文没有实现这样的追踪机制这里提出的是接入验收需要验证的能力而不是承诺所有产品都能返回同样完整的轨迹。团队规则决定结果怎样被消费。人工阅读一份报告和根据报告自动建立修复任务是不同强度的承诺进一步让它影响合并又需要仓库检查、证据核对和明确的责任人。执行者输出approve可以是一条审查意见但工作台是否允许下一步仍取决于它原来向团队承诺了什么。不能让一个供应方的返回字段悄悄改写团队规则。这类分工有一个实际收益以后更新模型或换供应方时变化主要集中在任务能力和适配器已有任务记录及采纳规则不必跟着重建。但隔离程度也有成本。一次性的个人审查脚本保留原始输出、输入版本和人工判断可能就够了只有多个入口或执行者反复使用同一流程才值得把这些职责逐步抽成稳定模块。“可组合”因此不等于每个组件都必须独立成服务。它首先是一种可解释的责任划分哪些信息由谁保存哪里发生转换转换失败由谁处理。代码可以先放在一个进程里是否需要队列、数据库或独立调度服务应由并发、持久化和故障恢复需求决定。什么时候值得增加第二个执行者接入第二个 Agent 的理由不应该只是它在另一份排行榜上分数更高。对订单审查这个具体任务更有用的问题是它能否发现原流程遗漏且值得处理的问题或者在满足现有要求的前提下降低总成本这两种收益需要分别观测不能用一份听起来更强硬的报告替代证据。可以先拿一组团队已经理解的历史改动做离线比较其中既有已确认的问题也有容易被误报的正常代码。两种执行者使用对应版本和尽量一致的任务范围记录哪些发现被人工确认、哪些缺少依据、哪些只是重复了已有发现。历史样本不完整也可能与未来任务分布不同因此结果只能帮助决定是否继续试用不能证明上线后一定更好。比较时还要把接入层算进去。如果为了给 B 补齐上下文需要开发者手工导出文件、解释代码位置、重新整理报告那么单次模型调用便宜并不代表整条流程便宜。这里可以采用一个简单的记账口径总投入包括调用费用、输入准备时间、结果核对时间以及失败后的恢复工作。它是评估口径不是本文测得的数据也不必把所有项目强行折算成同一货币单位。并行运行会带来另一种取舍。两份报告同时返回可能缩短等待某个补充判断的时间也可能把更多冲突意见交给同一个人处理。若两者都围绕同样的提示和材料提出同一类猜测执行者数量增加并不自动提供独立证据。真正有价值的差异可能来自明确不同的审查任务、补充材料或已验证的能力而不是给两个窗口起不同角色名。因此初次接入可以先采用按需调用普通变更沿原流程走遇到具体争议或现有执行者不擅长的任务再请求第二份意见。团队能明确说出补充调用解决了什么问题之后再考虑哪些场景值得默认触发。这比一开始给每个改动都配置多角色流水线更容易看清收益与负担。如果当前问题主要是输入不全、送审版本错了、报告没人核对那么先修这些环节通常更直接。第二个执行者收到同一份错误输入也不能替工作台补回任务事实。相反当输入和验收已经稳定仍反复出现某类能力缺口并且试用记录显示另一执行者能提供可采纳的补充接入才有了可讨论的依据。上线范围也可以小于技术能力范围。即使适配器已经能返回结构化发现也可以先只供人工阅读不立即接到修复或合并动作。这样得到的运行记录会回答后续真正的问题哪些字段可信、哪些错误经常发生、维护者能否解释一次异常。当这些问题尚未解决时增加自动化程度只会扩大接入层判断失误的影响。可组合的工作台保留差异才有替换空间这两条审查路径没有证明未来 IDE 必然成为某种 Agent Router也没有证明多 Agent 一定比单 Agent 更快、更准。它们只给出一个扎实的观察即使同属一个插件、使用同一个执行产品不同任务仍有不同的输入能力与结果表示。由此能作出的设计推论是工作台若要接入更多执行者应把任务含义和结果消费方式放在明确的位置让每个适配器声明自己能满足什么。开发者才能判断一次切换是等价替换还是把任务改成了另一种工作。实际落地时可以先拿一个现有审查任务把上面的映射记录填完再接第二个执行者。如果连它审的是哪批改动、返回的是原始报告还是可用结论都说不清增加一个下拉选项不会带来真正的可替换性。OpenAIcodex-companion.mjs固定提交db52e28f4d9ded852ab3942cea316258ae4ef346validateNativeReviewRequest与executeReviewRunhttps://github.com/openai/codex-plugin-cc/blob/db52e28f4d9ded852ab3942cea316258ae4ef346/plugins/codex/scripts/codex-companion.mjs ↩︎ ↩︎OpenAIlib/codex.mjs同一固定提交runAppServerReview、runAppServerTurn、buildResultStatus、parseStructuredOutputhttps://github.com/openai/codex-plugin-cc/blob/db52e28f4d9ded852ab3942cea316258ae4ef346/plugins/codex/scripts/lib/codex.mjs ↩︎ ↩︎ ↩︎OpenAICodex App Server2026-09-22访问https://learn.chatgpt.com/docs/app-server ↩︎OpenAIlib/render.mjs同一固定提交renderNativeReviewResult、renderReviewResult与形状检查https://github.com/openai/codex-plugin-cc/blob/db52e28f4d9ded852ab3942cea316258ae4ef346/plugins/codex/scripts/lib/render.mjs ↩︎ ↩︎OpenAI反方审查输出 schema同一固定提交https://github.com/openai/codex-plugin-cc/blob/db52e28f4d9ded852ab3942cea316258ae4ef346/plugins/codex/schemas/review-output.schema.json ↩︎ Agent 能接进 IDE，为什么还不能随意互换？
Agent 能接进 IDE为什么还不能随意互换假设你正在给团队的开发工作台加一个审查入口开发者选中一批改动点“审查”结果统一显示在侧栏。第一版接 Codex第二版想再接一个审查 Agent。界面没有变化看上去只要换掉调用目标。但同一个codex-plugin-cc插件里两种都叫“审查”的功能就已经不是同一种请求和返回值普通审查调用 Codex 内置 reviewer反方审查自行收集上下文、构造提示词再要求一份结构化结果。这个差异比“未来 IDE 会有多少 Agent”更值得先弄清。一个 Agent 能被工作台调用只证明入口接通要让它能被另一执行者替换还需要保持输入含义、运行状态和结果解释一致。下面沿这两条现成路径看一次替换需要改什么。工作台接入场景是设计例子源码分析没有执行真实跨 Agent 替换。一个审查入口已经有两种任务定义截至 2026-09-22本次核对的官方插件main指向提交db52e28。在这个固定版本的executeReviewRun中普通Review分支先转换并校验审查目标再调用runAppServerReview其余这里讨论的反方审查分支则调用collectReviewContext把上下文和关注点交给提示词构造函数。1区别最容易从自定义关注点看出来。validateNativeReviewRequest遇到非空focusText就报错提示改用/codex:adversarial-review。这不是让模型试着理解后再拒绝而是在进入普通审查前就明确限制输入。因此“审一下这批改动”和“专门挑战这批改动的重试设计”不能在客户端里无条件当成同一种请求。前者有内置审查目标的表示方式后者需要把自定义问题组织进输入上下文。即使执行者都叫 Codex这个差异也没有被模型名称消除。对工作台来说用户选择了一个 Agent 之后仍要回答一个更具体的问题它接受哪一种任务如果新执行者没有相同的目标选择能力适配层——把工作台请求转换成执行者请求的那段代码——就得补齐等价输入或者明确显示“不支持”。静默丢掉关注点会让界面看起来成功实际审查的却是另一个问题。协议负责把任务送进去调用方仍要选对方法沿着普通审查往下走runAppServerReview先创建线程再发送review/start请求中带着线程、交付方式和审查目标。反方审查则经runAppServerTurn发送turn/start其中包含文本输入和outputSchema。2把这两个调用并排差异很直观插件路径发送给 App Server 的任务插件准备的输入返回后主要处理什么普通审查review/start转换后的原生审查目标reviewText交给原生审查渲染函数反方审查turn/start自行收集的上下文、提示词、输出 schema最终消息解析后交给结构化审查渲染函数这是固定源码的调用关系不能把表里的第二行当成所有 Agent 都支持的统一标准。当前官方 App Server 文档也分别列出了这两个方法并区分 Thread、Turn 与 Item线程承载会话轮次承载一次请求及随后的工作条目承载过程中产生的内容。客户端要处理开始、增量与完成等事件。3协议提供的是可管理的调用方式不会替工作台定义“这个审查按钮究竟承诺检查什么”。同样是 JSON 消息也不会自动具有相同的目标选择、事件顺序或返回含义。换执行者时需要重新检查的是这段翻译关系如果现有执行者完全满足需求就没有必要为了“多 Agent”先造一个通用调度平台。相同的成功状态装不下两种结果插件对普通审查保留reviewTextrenderNativeReviewResult将其作为文本展示。这个分支没有把审查文本统一转换成反方审查使用的verdict、findings等字段。这里描述的是该插件的消费方式不是声称 Codex 内置审查器不存在任何内部结构。14反方审查的输出约定则写在review-output.schema.json中顶层需要verdict、summary、findings、next_steps其中 verdict 的允许值是approve和needs-attention。5返回后还有连续的处理步骤。parseStructuredOutput先尝试 JSON 解析renderReviewResult再检查顶层形状缺少必要的字符串或数组时展示结构错误和原始内容而不是直接按正常审查结果排版。这个形状检查有自己的有限范围不能等同于运行时完整执行了整份 JSON Schema更不能证明发现的问题真实存在。24另一个容易被界面抹平的差异是执行状态。buildResultStatus把最终 Turn 的completed映射为 0其他情况映射为 1。它回答的是本轮执行是否完成不是在读取verdict后判断代码能否合并。2假如一个接入方只看退出状态为 0就给侧栏画绿色勾选它会把“执行完成”误当成“审查认可”。反过来只要没有可解析 findings 就填空数组也会混淆“没有得到结构化结果”和“审查后没有发现问题”。这些是从源码差异推导的接入风险不是本次观测到的线上故障。把第二个审查 Agent 接进一次真实形状的任务把“换一个执行者”展开到足够具体才能看出适配工作在哪里发生。下面仍是构造案例用来推演接入设计没有调用第二个模型也没有获得可比较的运行结果。设想团队正在修改订单服务同一笔支付通知可能重复到达实现者为数据库写入增加了幂等判断。开发者在工作台选择这次提交要求审查重复通知是否仍可能产生第二条订单。第一版工作台调用 Codex准备再接一个只接收文本上下文、返回自然语言报告的执行者 B。这里刻意不假定 B 兼容 Codex 的接口。它的能力只是案例条件不对应某个真实产品。接入目标也很窄让开发者在同一侧栏阅读两种执行者的审查结果不自动修改文件或批准合并。第一处要适配的是输入。工作台不能把“当前改动”四个字原样转给 B 就算完成交接。用户选择的是哪次提交、比较基线是什么、相关文件内容来自哪个版本都要随任务留下记录。对于能读取工作区的执行者可以传入它支持的审查目标并记录实际解析到的版本对于只能接收文本的 B就需要提供对应差异和必要上下文。这不是要求把整个仓库塞进提示词。假设风险取决于数据库唯一约束只给订单函数的几行 diffB 可能根本看不到决定结论的条件。适配器要么补充相关表结构和调用入口要么在报告上保留“未提供数据库约束”的缺口。前者增加输入和准备成本后者限制结果可用范围两者都比悄悄把缺失上下文当成已检查更诚实。同时自定义关注点必须被保留。案例问的是重复通知而源码中的普通/codex:review路径不接受自定义focusText。如果工作台承诺一定审查这个问题就不能只因为普通命令容易调用而丢掉它需要选择能承载关注点的路径或者告知用户该入口只提供一般审查。这个约束来自固定插件实现不能泛化为 App Server 本身禁止自定义目标。第二处是运行中的归属。工作台创建的审查任务可以有自己的任务编号再关联 Codex 或 B 返回的执行标识。用户稍后切到另一批代码时迟到的报告仍应回到原来的任务而不是覆盖当前侧栏。若任务只有同步文本返回也可以先支持这一种简单模式没有必要为了统一外观虚构进度百分比或取消能力。假设用户等待期间又改了一次订单函数。B 最终返回“幂等判断之后仍有一次写入窗口”。工作台首先要显示这条结论对应的是送审时的旧版本。接下来是让开发者核对该问题是否还存在或者对新版本重审而不是偷偷把旧结果改挂到最新代码行。任务身份在这里服务的是结果归属并不要求恢复两个产品内部相同的会话历史。第三处才是结果转换。B 的原始报告没有文件位置工作台就保留原文并标注“尚未定位”不能从“订单函数”猜出一个文件路径再制造一条看似精确的行内评论。如果后续让另一个模型提取文件和行号提取结果仍需对照送审版本检查且应保留它来自转换步骤这一事实。否则接入层会把不确定性洗成结构化字段下游反而更难发现问题。最后开发者核对后发现数据库确有唯一约束但重复通知仍会触发一次多余的外部调用。这时可以记录哪些原始意见被采纳、哪些被证据排除以及实际需要修复什么。不能因为报告中的一处推断有误就把整次执行标成失败也不能因为执行完成就默认接受它的每条判断。沿这条过程走完第二个 Agent 已经可以成为工作台里的一个可用执行者但还没有变成 Codex 的无差别替身。它可能缺少工作区读取、结构化输出、进度事件或取消能力。工作台需要让这些差异可见再决定当前任务是否还能等价地交给它。用一份映射记录验收接入下面这份映射记录可以直接用于讨论接入方案。它是作者建议的工作台设计不是官方插件已有字段也不是完成过的兼容性验收工作台要保留的含义从插件现有路径看到的约束替换时要作出的决定审查对象与自定义关注点普通路径校验原生目标且拒绝自定义关注点反方路径自行组织上下文记录新执行者实际收到的对象不支持的关注点明确拒绝或交回调用方本轮执行结果Turn 完成状态被转换成执行状态把执行失败、中断与审查意见分开显示保留执行者自己的任务标识可供后续使用的审查内容一条路径消费文本另一条解析并检查结构保留原始输出只有可验证的字段才进入统一显示或后续动作能否推动下一步执行状态与结构化 verdict 来自不同处理位置单独定义采纳条件“需关注”进入核对结构缺失不自动变成“无发现”这张记录要围绕一个真实任务填写而不是先为所有 Agent 发明通用字段。第一步可以只支持“人工读报告”这一种用途后续确实需要自动定位或修复分派时再补相应适配。接入层的价值是让调用方清楚哪些含义已被保留、哪些仍需要判断。哪些职责留在工作台哪些交给执行者这个例子也解释了工作台为什么不能只是模型选择器。具体推理过程可以由执行者承担但用户选了什么任务、结果归到哪里、什么条件下可以推动下一步需要有稳定的管理位置。以下是基于案例的设计建议不是对官方插件已有能力的完整描述。工作台首先保存的是用户意图和任务身份。订单审查的输入版本、关注点、允许的操作、结果用途不能只存在于某个 Agent 的长对话里。换一个执行者后这些信息仍然需要成立。执行者内部如何命名会话、如何拆解工作可以不同工作台只保留完成追踪所需的映射不必接管所有内部状态。适配器则处理产品差异怎样把审查目标转换成请求怎样接收事件怎样保存原始输出怎样解释错误。它不应为了迎合统一界面而宣称执行者具备不存在的能力。例如B 没有可靠的中断接口适配器就不能把“用户不再等待”显示成“远端已停止”。最低限度应区分界面等待结束与执行是否确认终止涉及重试时也不能假定前一次工作没有继续发生。执行者负责在给定条件下完成分析但它生成的自述不应成为工作台唯一的事实来源。它说“检查了数据库约束”调用方仍应能追溯送入了什么材料或取得了哪些可核对的工具证据。本文没有实现这样的追踪机制这里提出的是接入验收需要验证的能力而不是承诺所有产品都能返回同样完整的轨迹。团队规则决定结果怎样被消费。人工阅读一份报告和根据报告自动建立修复任务是不同强度的承诺进一步让它影响合并又需要仓库检查、证据核对和明确的责任人。执行者输出approve可以是一条审查意见但工作台是否允许下一步仍取决于它原来向团队承诺了什么。不能让一个供应方的返回字段悄悄改写团队规则。这类分工有一个实际收益以后更新模型或换供应方时变化主要集中在任务能力和适配器已有任务记录及采纳规则不必跟着重建。但隔离程度也有成本。一次性的个人审查脚本保留原始输出、输入版本和人工判断可能就够了只有多个入口或执行者反复使用同一流程才值得把这些职责逐步抽成稳定模块。“可组合”因此不等于每个组件都必须独立成服务。它首先是一种可解释的责任划分哪些信息由谁保存哪里发生转换转换失败由谁处理。代码可以先放在一个进程里是否需要队列、数据库或独立调度服务应由并发、持久化和故障恢复需求决定。什么时候值得增加第二个执行者接入第二个 Agent 的理由不应该只是它在另一份排行榜上分数更高。对订单审查这个具体任务更有用的问题是它能否发现原流程遗漏且值得处理的问题或者在满足现有要求的前提下降低总成本这两种收益需要分别观测不能用一份听起来更强硬的报告替代证据。可以先拿一组团队已经理解的历史改动做离线比较其中既有已确认的问题也有容易被误报的正常代码。两种执行者使用对应版本和尽量一致的任务范围记录哪些发现被人工确认、哪些缺少依据、哪些只是重复了已有发现。历史样本不完整也可能与未来任务分布不同因此结果只能帮助决定是否继续试用不能证明上线后一定更好。比较时还要把接入层算进去。如果为了给 B 补齐上下文需要开发者手工导出文件、解释代码位置、重新整理报告那么单次模型调用便宜并不代表整条流程便宜。这里可以采用一个简单的记账口径总投入包括调用费用、输入准备时间、结果核对时间以及失败后的恢复工作。它是评估口径不是本文测得的数据也不必把所有项目强行折算成同一货币单位。并行运行会带来另一种取舍。两份报告同时返回可能缩短等待某个补充判断的时间也可能把更多冲突意见交给同一个人处理。若两者都围绕同样的提示和材料提出同一类猜测执行者数量增加并不自动提供独立证据。真正有价值的差异可能来自明确不同的审查任务、补充材料或已验证的能力而不是给两个窗口起不同角色名。因此初次接入可以先采用按需调用普通变更沿原流程走遇到具体争议或现有执行者不擅长的任务再请求第二份意见。团队能明确说出补充调用解决了什么问题之后再考虑哪些场景值得默认触发。这比一开始给每个改动都配置多角色流水线更容易看清收益与负担。如果当前问题主要是输入不全、送审版本错了、报告没人核对那么先修这些环节通常更直接。第二个执行者收到同一份错误输入也不能替工作台补回任务事实。相反当输入和验收已经稳定仍反复出现某类能力缺口并且试用记录显示另一执行者能提供可采纳的补充接入才有了可讨论的依据。上线范围也可以小于技术能力范围。即使适配器已经能返回结构化发现也可以先只供人工阅读不立即接到修复或合并动作。这样得到的运行记录会回答后续真正的问题哪些字段可信、哪些错误经常发生、维护者能否解释一次异常。当这些问题尚未解决时增加自动化程度只会扩大接入层判断失误的影响。可组合的工作台保留差异才有替换空间这两条审查路径没有证明未来 IDE 必然成为某种 Agent Router也没有证明多 Agent 一定比单 Agent 更快、更准。它们只给出一个扎实的观察即使同属一个插件、使用同一个执行产品不同任务仍有不同的输入能力与结果表示。由此能作出的设计推论是工作台若要接入更多执行者应把任务含义和结果消费方式放在明确的位置让每个适配器声明自己能满足什么。开发者才能判断一次切换是等价替换还是把任务改成了另一种工作。实际落地时可以先拿一个现有审查任务把上面的映射记录填完再接第二个执行者。如果连它审的是哪批改动、返回的是原始报告还是可用结论都说不清增加一个下拉选项不会带来真正的可替换性。OpenAIcodex-companion.mjs固定提交db52e28f4d9ded852ab3942cea316258ae4ef346validateNativeReviewRequest与executeReviewRunhttps://github.com/openai/codex-plugin-cc/blob/db52e28f4d9ded852ab3942cea316258ae4ef346/plugins/codex/scripts/codex-companion.mjs ↩︎ ↩︎OpenAIlib/codex.mjs同一固定提交runAppServerReview、runAppServerTurn、buildResultStatus、parseStructuredOutputhttps://github.com/openai/codex-plugin-cc/blob/db52e28f4d9ded852ab3942cea316258ae4ef346/plugins/codex/scripts/lib/codex.mjs ↩︎ ↩︎ ↩︎OpenAICodex App Server2026-09-22访问https://learn.chatgpt.com/docs/app-server ↩︎OpenAIlib/render.mjs同一固定提交renderNativeReviewResult、renderReviewResult与形状检查https://github.com/openai/codex-plugin-cc/blob/db52e28f4d9ded852ab3942cea316258ae4ef346/plugins/codex/scripts/lib/render.mjs ↩︎ ↩︎OpenAI反方审查输出 schema同一固定提交https://github.com/openai/codex-plugin-cc/blob/db52e28f4d9ded852ab3942cea316258ae4ef346/plugins/codex/schemas/review-output.schema.json ↩︎