Pro Collaboration Controller

让 Codex 不只完成一步，而是把整个任务推进到结果

你只需要告诉 Codex 最终要什么，不需要自己管理中间每一步。

Codex 很擅长写代码、研究问题、修改文件和处理具体任务。

但任务一旦变复杂，你往往还是需要自己做很多“管理工作”：

判断下一步应该做什么；
把大任务拆成几个阶段；
检查结果有没有遗漏；
要求它修改不合格的部分；
重新解释前面已经发生了什么；
在不同工作之间传递上下文；
决定什么时候继续，什么时候停止；
长任务隔一段时间后，再回来重新接上。

Pro Collaboration Controller 把这部分工作交给 Codex 自己管理。

你负责告诉 Codex：

我要什么。

Controller 负责让 Codex持续知道：

现在做到哪里、什么已经确认、还有什么没解决、接下来唯一该做什么。

一个目标进去，Codex 自己组织过程

最简单的用法不需要学习任何新概念。

你可以直接说：

把这个功能做完，包括检查和修复。

或者：

研究这个问题，最后给我一个可靠结论。

或者：

继续推进这个项目，直到遇到真正需要我决定的事情。

然后 Controller 会根据任务复杂度决定接下来需要什么。

一个简单任务可能只是：

理解目标 → 完成工作 → 检查结果 → 交付

一个复杂任务可能变成：

分析 → 实现 → 测试 → 发现问题 → 修订 → 再检查 → 交付

一个研究任务可能是：

确定问题 → 查已有工作 → 推导 → 找反例 → 复核 → 收敛结论

这些流程不需要你提前设计。

你给目标，Codex 自己组织完成路径。

你不再需要当 Codex 的项目经理

没有 Controller 时，复杂任务很容易变成：

你提要求 → Codex 做一步 → 你看结果 → 决定下一步 → 再告诉 Codex → 再检查 → 再纠正……

真正消耗精力的，往往不是每一步本身，而是中间这些协调工作。

Controller 的目标就是把它变成：

你提出总目标 → Codex持续推进 → 真正需要你时再回来

也就是说，你不需要反复告诉它：

“现在继续下一步。”
“前面这个已经做过了。”
“不要再走刚才失败的路线。”
“把这个结果交给下一步。”
“先检查一下是不是对的。”
“如果不行就修改一次。”
“别重新研究已经解决的问题。”

这些都应该成为 Controller 的工作。

简单任务保持简单

Controller 不会把每一个请求都变成庞大的 AI 工作流。

普通任务默认走最短路径：

理解任务 → 完成 → 检查 → 返回结果

如果第一次结果已经满足要求，就结束。

它不会为了“自动化”而自动制造：

很多角色；
很多对话；
多轮审查；
大量搜索；
复杂任务卡；
长链交接；
无限修改。

只有当任务真的需要时，它才升级。

例如：

第一次结果没有达到要求；
出现互相冲突的结论；
关键约束被遗漏；
需要独立验证；
需要判断已有研究是否已经解决问题；
工作需要跨较长时间继续；
当前能力不足以可靠完成任务。

复杂度由问题决定，而不是由 Controller 的存在决定。

Codex 会一直知道“现在在哪里”

长任务最大的麻烦之一，是状态会逐渐丢失。

做了几十步以后，真正重要的信息可能只剩几件：

哪些事实已经确认；
哪些工作已经完成；
哪些路线已经证明走不通；
现在还有什么没解决；
下一步究竟是什么。

Controller 会持续维护这部分状态。

它不会把整个历史无限堆积，而是尽量保留：

已接受的事实
未解决的问题
关键证据
失败路线及失败原因
当前唯一下一步

所以任务越长，Controller 的价值通常越明显。

它的作用不是单纯“记住更多东西”。

而是：

记住真正影响下一步的东西。

不再反复搬运整段上下文

传统的长任务很容易出现一个问题：

每进入下一阶段，就把前面的完整历史再塞进去一次。

结果往往是：

已解决的问题被重新讨论；
旧错误再次出现；
新任务被大量无关内容淹没；
上下文越来越长；
实际有效信息却没有同比增加。

Controller 默认只把下一步真正需要的信息带过去。

例如一个实现任务完成以后，后面的检查阶段不一定需要重新知道最初几十轮讨论的全部内容。

它可能只需要知道：

我们要实现什么
已经改了什么
验收标准是什么
目前哪里最值得检查

这种上下文压缩，让 Codex 更像是在维护一个持续运行的工作状态，而不是不断重新阅读聊天记录。

长期研究不会反复从头开始

对于数学、技术研究、架构设计这类长期任务，Controller 还会维护已经检查过的研究范围。

如果问题没有变化：

复用已有结论。

如果只有一部分变化：

只检查变化部分。

只有出现真正的新情况时才重新展开搜索，例如：

研究对象改变；
关键假设改变；
原路线失败；
出现新的命题；
需要确认一个新的创新性声明；
旧结论已经不足以支持当前判断。

它不会因为任务持续了很久，就定期把同一个问题再搜一遍。

目标不是“搜索更多”。

而是：

只在新信息可能改变决策时重新搜索。

它会检查结果，而不是只负责继续

自动推进并不等于不断往前跑。

Controller 每完成一个阶段，都需要判断结果属于哪一种情况：

接受
修改
停止
换路线
交给下一步

例如：

如果实现已经满足验收条件，就不需要再制造额外工作。

如果结果基本正确但漏了一项要求，可以只修一次。

如果路线本身错误，就应该停止，而不是在错误方向上继续追加工作。

如果当前信息不足以判断，也不应该假装已经完成。

所以 Controller 的目标不是：

让 Codex 做更多步骤。

而是：

让 Codex做尽可能少、但足够完成目标的步骤。

真正需要额外能力时，Codex 可以自己组织

有些任务一个执行过程就能完成。

有些任务则可能需要：

独立复核；
第二种推理路线；
外部搜索；
更强的模型能力；
不同上下文中的独立判断；
专门工具；
延迟一段时间后重新检查状态。

这些都应该是 Controller 根据任务需要调用的能力。

用户不需要提前知道背后具体用了几个模型、几个对话或者什么内部角色。

对用户而言，仍然只是：

我把任务交给 Codex。

只有当这些执行细节会影响费用、隐私、授权或最终结论时，Controller 才需要把它们暴露出来。

如果你拥有 ChatGPT Pro，复杂思考会优先交给它

对于高级任务，Controller 会在宿主环境支持且数据边界允许时，把用户已有的 ChatGPT Pro 当作默认的高质量推理资源，而不是等 Codex 失败后才使用。Controller 优先追求复杂任务的完成质量，节省 Codex token 只是次级收益。

例如：

让 Pro 起草复杂计划、完成主体研究或长推理；
让 Codex 联网搜索、修改文件、运行测试并检查现实证据；
在关键结论无法直接验证时，让第二个 Pro 从不同角色攻击它；
只有两个角色在一个明确争点上仍冲突时，才让第三个 Pro 做限定裁决。

这不是“整个任务只调用一次 Pro”。长期任务每出现一个新的、会改变下一步的复杂认知问题，都可以调用一个新的 Pro 工作单元；已经接受且问题没有变化的结论会直接复用。

但这是 Controller 的执行方式，不是用户使用产品前必须理解的概念。

你不需要先知道：

“这个任务是不是应该用 Pro？”

也不需要决定：

“应该开几个 Pro？”

你仍然只需要说：

把这个任务做完。

Controller 会自动判断当前阶段是由 Codex 直接执行，还是交给一个或多个有明确分工的 Pro。

如果产品明确显示这个账户没有 Pro，或 Pro 的周／计划额度已经达到硬上限，Controller 会在同一个 ChatGPT Chat 界面中选择当前最强、且能够被产品证据唯一确认的非 Pro 模型继续。它会明确告诉你这是“非 Pro”结果，并记录界面选项标签和实际观察到的模型标签。临时限流、网络错误、界面加载失败或状态不清楚不会触发降级；它也不会偷偷改用 API、Work、Codex、额外付费额度或其他服务。你也可以在任务中明确要求 Pro-only，此时无法使用 Pro 就停止。

自动推进，但不会偷偷替你做决定

Controller 可以自动处理已经授权范围内的工作，但不会把“自动化”理解成无限授权。

如果一个新的步骤会改变重要边界，例如：

产生额外费用；
使用新的外部服务；
把数据发送到新的地方；
切换到明显不同的执行方式；
做不可逆操作；
需要新的用户判断；

它应该回来询问你。

它的原则是：

能在已有授权里继续，就继续。
需要新授权，就停下来问。

长任务可以稍后继续，但不会重复执行

有些任务需要等待：

一个长时间运行的操作完成；
一个结果产生；
一个外部状态发生变化；
稍后再回来检查。

如果宿主环境支持，Controller 可以利用完成事件或 Scheduled Task 在之后重新检查任务状态。

但这种“唤醒”只用于：

观察已经发生了什么，并决定下一步。

它不会因为重新醒来，就再次发送原任务。

如果当前状态不明确，它会停止，而不是冒险重复执行。

这能避免长任务里最危险的一类自动化错误：

同一件事被做两遍。

工具做不到时，它会明确停下来

Controller 不会假装拥有不存在的能力。

能够直接完成的步骤，它直接完成。

只能通过浏览器完成的步骤，在能力允许时再通过浏览器完成。

如果某一步当前确实无法自动完成，它会明确告诉你：

哪里被阻塞
为什么不能继续
你需要做什么

而不是伪造：

“已经发送”；
“已经完成”；
“已经验证”。

自动化的前提是现实能力，而不是流程图看起来完整。

Codex 的结果仍然需要证据

Controller 能让工作组织得更好，但它不会把一次模型输出自动包装成事实。

一个结果是否可信，仍然取决于任务本身需要什么证据。

例如：

代码可能需要测试。

数学结论可能需要证明。

研究结论可能需要来源。

架构决策可能需要约束和反例检查。

Controller 的作用是确保这些验收步骤真正发生，而不是用一句：

“AI 已经确认。”

来代替它们。

什么时候最有价值？

它特别适合那些：

不是做一步，而是需要持续推进到完成的任务。

例如：

完成一个软件功能并测试；
修复一个复杂 bug；
重构一个代码库；
研究一个技术问题；
推进数学证明；
做文献和已有工作检查；
设计系统架构；
比较多个方案并作出决策；
持续推进一个长期项目；
对重要结果进行独立验证。

如果只是问：

Python 怎么把字符串转成整数？

直接让 Codex 回答就够了。

但如果是：

把这个模块重构掉，保持兼容，补测试，检查有没有遗漏，完成后告诉我。

这就是 Controller 真正开始有价值的地方。

你不需要学习 Controller

理想情况下，用户甚至不需要经常想到它的存在。

你不需要学习：

工作流 DSL；
YAML；
task ID；
role ID；
哈希；
内部状态机；
对话调度协议；
上下文交接格式。

这些属于内部实现和高级审计能力。

普通使用应该仍然像使用 Codex 一样简单。

你只需要说：

把这个做完。

检查完再交给我。

继续推进，只有真正需要我决定的时候再问。

研究清楚以后给我最终结论。

剩下的组织工作交给 Controller。

一句话理解

Codex 原本很擅长完成工作。

Pro Collaboration Controller 让 Codex 也开始管理工作。

你告诉它最终要什么。

它负责记住状态、安排下一步、检查结果、必要时调用更多能力，并把复杂任务持续推进到完成。

用真实运行数据继续变好

公共版包含一个最小化、OAuth 保护的遥测旁路。安装插件本身不等于同意遥测；只有用户单独打开遥测设置或明确要求连接时，才会出现一次清楚的同意页。普通任务结束时不会突然弹出 OAuth。不需要注册额外账号，也不需要提供邮箱、密码或付款信息。

同意后，每个根任务只有在最终结果和验收依据已经冻结时，Controller 才会自动尝试发送一次开始记录和一次立即提交。它只发送粗粒度任务类型、路由、Pro/搜索/修复次数、枚举结果码和耗时，用来发现路由、可靠性与延迟问题。

它不会发送 prompt、回答、推理、文件、路径、URL、账号信息、对话 ID、具体模型标签、候选模型列表、限额原文或重置时间。遥测失败、被拒绝或未连接时，主任务照常完成；不会重试、排队或以后补传。用户可以断开连接，也可以调用 telemetry.delete_my_data 删除当前匿名主体的活动数据和令牌。详见 Privacy notice。

如果任务需要调用 ChatGPT Pro、浏览器、搜索、外部连接器或其他工具，Controller 只在宿主产品实际提供相应能力且授权边界允许时使用；各服务的数据处理仍受其自身条款和隐私政策约束。

Public documents

Publisher: Eli Brad
Project brand: knockknock-hoho