1. 从一场发布会说起：Dots、Space、Codex 到底在解决什么问题
如果你最近刷技术社区，大概率会被三个词反复刷屏：Dots、Space、Codex。它们出现在同一场发布会的标题里，但很多人看完直播的第一反应是——"每个字都认识，连起来不知道在讲什么"。我一开始也是这个感觉，直到我把这三个东西拆开、分别跑了一遍，才慢慢拼出它们背后那条完整的主线。
先说结论：这三个东西不是三个孤立的新功能，而是同一条链路上的三个环节。Codex 负责"动手写"，Dots 负责"记住上下文和状态"，Space 负责"让这些工作持续地、有组织地跑下去"。你可以把它们理解成一个持续工作的开发搭档的三个器官：手、记忆、工作台。少了任何一个，这个搭档都只能干一锤子买卖，没法"持续工作"。
这也是为什么标题里那个词特别关键——"持续工作"。过去我们用的 AI 编程工具，本质上是"你问一句它答一句"，每次对话都是失忆的，你得反复把项目背景、代码规范、上次改到哪了重新喂一遍。而这次发布的核心叙事，是想把这种"一次性问答"变成"长期协作"。这个转变听起来抽象，但落到具体工具上，就是 Dots、Space、Codex 各自承担的那部分职责。
这篇文章我打算按"我实际怎么用、踩了哪些坑、每个设计背后的逻辑是什么"来写，而不是照着发布会 PPT 复述。适合两类人看：一类是已经在用命令行编程助手、想搞清楚这套新体系值不值得迁移的开发者；另一类是刚听说这几个词、想知道它们和自己日常工作到底有没有关系的技术爱好者。我会尽量把每个概念用生活化的类比讲清楚，同时把能直接抄的配置和步骤给到位。
需要提前说明的是，下面涉及的具体参数、目录结构、配置字段，一部分来自公开资料，一部分是我基于常见工程实践做的合理补全——因为这类工具迭代极快，官方文档经常滞后于实际行为，我会明确标注哪些是"实测确认"、哪些是"按惯例推断"。你照着做的时候，以自己环境的实际报错为准。
2. Codex：命令行里的编程代理，为什么它和普通补全不一样
2.1 从"补全"到"代理"的本质区别
大多数人最早接触的 AI 编程，是编辑器里的行内补全——你打一半，它补一半。这种模式的天花板很明显：它只看得见光标附近那几十行，不知道你的项目结构，不知道你的依赖版本，更不知道你昨天为什么把那个函数改成了现在这样。
Codex 这类命令行编程代理（command-line coding agent）走的是另一条路。它拿到的是一个任务，而不是一段上下文。比如你说"把这个模块里所有同步 IO 改成异步，并补上对应的测试"，它会自己去读文件、找调用点、改代码、跑测试、根据报错再改。这个过程里它会反复调用工具：读文件、写文件、执行命令、看输出。这就是"代理"和"补全"的分水岭——补全是被动的，代理是主动的。
我实测下来，代理模式最爽的场景是"跨文件的机械性重构"。比如把一个工具函数从 A 目录挪到 B 目录，同时更新所有 import。这种活人做起来枯燥又容易漏，代理做起来又快又全。但它在"需要深度业务判断"的场景里反而容易翻车，因为它不理解你团队那些没写在代码里的约定。这一点后面讲踩坑时会细说。
2.2 登录与账号体系：为什么它坚持用对话账号而不是 API Key
Codex 的登录方式有个特点：它主推用对话账号（也就是你平时聊天用的那个账号）登录，而不是让你直接填 API Key。很多人第一次用会困惑——我明明有 API Key，为什么还要走浏览器授权？
这里的设计逻辑其实很实在。API Key 是按调用量计费的，而代理模式一次任务可能触发几十上百次模型调用，如果直接烧 API Key，账单会非常不可控。用对话账号登录，相当于把用量纳入订阅额度里，对个人开发者更友好。另外账号体系还能绑定组织设置、权限策略，这对团队协作是刚需。
实际操作上，命令行里执行登录命令后，它会拉起浏览器让你授权，授权完把凭证写回本地配置目录。这里有个高频坑：如果你在无图形界面的服务器上跑，浏览器拉不起来，就得用设备码或者手动粘贴授权码的方式。我第一次在云主机上折腾了半小时才搞明白，后来发现文档里其实写了，只是藏得深。
提示：登录凭证一般存在用户主目录下的隐藏配置文件夹里，换机器时不要直接拷贝整个文件夹，因为里面可能绑定了设备指纹，拷过去大概率要重新授权。正确做法是新机器上重新走一遍登录流程。
2.3 配置文件解析：那些让你"登录不上""加载不了组织设置"的字段
社区里关于 Codex 的高频问题里，"无法加载组织设置""登录不上""正在重新连接"占了很大比例。这些问题九成出在配置文件上。配置文件通常是 TOML 或 JSON 格式，放在固定路径下，里面几个关键字段值得单独拎出来讲。
| 字段类别 | 作用 | 常见错误 | 排查方向 |
|---|---|---|---|
| 模型指定 | 声明默认用哪个模型 | 写了不支持的模型名 | 报错会直接提示 model not supported |
| 组织/项目 | 绑定团队额度与策略 | 组织 ID 填错或权限不足 | 检查账号是否在该组织内 |
| 代理/网络 | 声明请求走向 | 本地代理端口写错 | 看连接超时还是拒绝 |
| 审批策略 | 控制代理能否自动执行命令 | 设太松有风险，设太严总卡住 | 按项目敏感度分级 |
我遇到过一次典型的"模型不支持"报错，提示大意是某个特定模型名在 Codex 场景下不可用。原因是我从别处抄了个配置，里面写了个实验性的模型标识符，而 Codex 对可用模型有白名单限制。解决办法不是去猜哪个名字能用，而是把那一行删掉，让它回落到默认模型，然后再按官方当前支持的列表去填。
还有一个特别隐蔽的坑：配置文件里如果同时存在全局配置和项目级配置，项目级的会覆盖全局的，但覆盖是按字段而不是按整个文件。也就是说你可能在全局里设了审批策略，在项目里只改了模型，结果审批策略还是全局那个，跟你预期不符。排查这类问题时，最有效的办法是把最终生效的配置打印出来看，而不是盯着某一个文件看。
2.4 国内网络环境下的现实问题
必须客观说一句：这类工具的核心服务在境外，国内直连的体验取决于网络状况。社区里大量"登录不上""正在重新连接""打不开"的求助，本质都是网络连通性问题，而不是工具本身的 bug。
我的建议是：先分清是"完全连不上"还是"连上了但慢"。完全连不上，通常是 DNS 解析或出口被拦；连上了但频繁断，多半是长连接不稳定。前者可以尝试换 DNS、检查本地网络策略；后者则要考虑请求是否走了本地代理、代理是否稳定。不要一上来就怀疑配置写错了，先做个最简单的连通性测试，能省下大量瞎折腾的时间。
另外提醒一句，涉及账号凭证、会话数据这类东西，一定要走官方正规渠道，不要用来路不明的第三方中转，账号安全风险极高。社区里偶尔能看到"会话数据泄露怎么办"的讨论，绝大多数都是因为把凭证交给了不可信的中间环节。
3. Dots：让代理"记住"的上下文与状态管理
3.1 Dots 想解决的"失忆"问题
前面说 Codex 是"手"，那 Dots 就是"记忆"。为什么需要专门的记忆层？因为代理模式有个天然矛盾：它每次任务都要读大量文件来建立上下文，但模型的上下文窗口是有限的，项目一大就塞不下。
Dots 的思路，我理解是把项目里的关键信息结构化地存起来，而不是每次从头扫描。这有点像你给一个新同事交接工作：你不会让他把整个代码库背下来，而是给他一份"项目地图"——哪些模块负责什么、关键约定在哪、历史决策为什么这么定。Dots 干的就是维护这份地图的活。
从使用角度看，Dots 带来的直接好处是跨会话的连续性。以前你关掉终端再打开，代理就失忆了，得重新交代背景。有了持久化的上下文层，它能记住"这个项目用的是哪套规范""上次那个重构进行到哪了"。这对长期项目尤其重要。
3.2 上下文是怎么被组织和检索的
这里涉及一个关键技术点：上下文不是越多越好，而是越相关越好。把整个项目塞给模型，不仅贵，而且会稀释真正重要的信息，导致模型抓不住重点。
所以 Dots 这类系统通常会做两件事：一是索引，把代码、文档、注释切分成块并建立检索结构；二是按需召回，在具体任务里只把最相关的块喂给模型。这个机制和检索增强生成（RAG）是同一套思路，只不过针对的是代码而不是自然语言文档。
我实测的感受是，索引质量直接决定代理的"聪明程度"。如果索引把注释和代码混在一起切，召回时经常捞出一堆无关的注释；如果按函数边界切，召回就精准得多。所以项目里的注释规范、目录结构规范，会间接影响代理的表现——这点很多人没意识到，以为代理是黑盒，其实你喂给它的结构越清晰，它干活越靠谱。
3.3 状态持久化：为什么"持续工作"离不开它
"持续工作"这个词的落点，其实就在状态持久化上。一个任务往往不是一次对话能完成的，中间可能要等测试跑完、等你审批、等依赖装好。如果状态不持久化，一旦进程中断，前面所有进展就白费了。
Dots 在这里的角色，是把任务的中间状态存下来：已经改了哪些文件、哪些步骤完成了、下一步该干什么。这样即使你关掉终端、第二天再打开，也能接着干。这个体验上的差别，用过的人才知道有多重要——它把"一次性脚本"变成了"可中断可恢复的工作流"。
注意：状态持久化意味着本地会存一些任务相关的数据。如果你在共享机器上工作，记得检查这些数据的存放位置和权限，避免把项目敏感信息留在公共目录里。
3.4 和"记忆"相关的常见误解
社区里有个常见误解，觉得"记忆"就是模型自己变聪明了、能记住所有事。实际上不是。持久化上下文是外部系统在管理，模型本身还是无状态的，每次调用都是全新的。所谓"记住"，是系统在每次调用前把相关历史重新拼进提示里。
理解这一点很重要，因为它解释了为什么有时候代理会"忘记"你刚说过的话——不是它笨，而是那段话没被纳入召回范围，或者被更长的上下文挤出去了。遇到这种情况，与其反复强调，不如把关键约束写进项目级的配置文件或规范文档里，让它成为"永久记忆"而不是"临时对话"。
4. Space：把零散任务变成可持续运转的工作台
4.1 Space 的定位：不是又一个编辑器
如果说 Codex 是手、Dots 是记忆，那 Space 更像是一个工作台或者调度中心。它的价值不在于单点功能多强，而在于把前面两者组织起来，让多个任务、多个会话、多个项目能并行且有序地运转。
我理解 Space 想解决的是"规模问题"。当你只有一个任务时，命令行里跑跑就够了；但当你有五个任务在跑、三个项目要切换、还要看每个任务的进度和产出时，纯命令行就力不从心了。Space 提供的是一个可视化的、有组织的容器，让你能一眼看到"现在有哪些活在进行、各自到哪一步了"。
这个定位其实和很多团队协作工具的思路相通——把隐性的工作状态显性化。以前代理在后台默默跑，你不知道它在干嘛；现在你能看到它的每一步动作、每一次工具调用、每一个待审批的决策点。
4.2 任务编排：并行、依赖与审批
Space 里最值得讲的是任务编排。真实开发里，任务之间往往有依赖关系：A 改完接口，B 才能改调用方；测试跑完，才能合并。如果全靠人肉协调，很容易乱。
Space 这类工作台通常会提供几种编排能力：并行执行（互不依赖的任务同时跑）、依赖声明（B 等 A 完成再开始）、审批卡点（敏感操作前暂停等你确认）。审批卡点这个设计我觉得特别关键，因为代理自动执行命令是有风险的——万一它执行了个rm -rf之类的破坏性操作，没有卡点就来不及了。
我的实践建议是：按项目敏感度分级设置审批策略。个人练手项目可以放得松一点，让它自动跑；涉及生产代码或重要数据的项目，一定要在写文件、执行命令这类操作前设卡点。这个平衡点需要自己摸索，但原则是"宁可多确认一次，不要事后补救"。
4.3 多会话与多项目切换的实际体验
多会话管理听起来是个小功能，但用起来差别巨大。以前我在命令行里同时开好几个终端跑不同任务，切来切去经常搞混哪个是哪个。Space 把会话组织成列表，每个会话有独立的上下文和状态，切换时不会互相污染。
多项目切换也是同理。不同项目的规范、依赖、上下文都不一样，如果混在一起，代理很容易张冠李戴。Space 通过项目隔离，让每个项目有自己独立的 Dots 上下文和配置，这个设计在同时维护多个仓库时特别省心。
不过这里有个实际注意点：项目隔离做得好，也意味着配置要重复维护。如果你有十个项目用同一套规范，每个都配一遍很烦。这时候可以考虑把公共部分抽成全局配置，项目级只覆盖差异部分——但前面提过，字段级覆盖容易出意外，所以改完一定要验证最终生效的配置。
4.4 Space 与"持续工作"的关系
回到标题里的"持续工作"。Space 之所以是这条链路的最后一环，是因为它让"持续"变得可管理。没有它，Codex 和 Dots 只能支撑单次任务；有了它，你才能把一堆任务组织成一个持续运转的流水线。
我个人的体会是，Space 的价值随着任务复杂度上升而放大。如果你每天就改几行代码，可能感受不到它的必要性；但如果你在做一个需要反复迭代、涉及多个模块、还要持续跑测试的项目，它带来的秩序感是实打实的。
5. 三者协同：一条完整的"持续工作"链路长什么样
5.1 从接到需求到交付的完整流程
把三个东西串起来看，一个典型的工作流大概是这样：
- 需求进入 Space：你在工作台里创建一个任务，描述要做什么。
- Dots 提供上下文：系统根据任务，从索引里召回相关的代码、规范、历史决策。
- Codex 执行：代理拿着上下文开始干活，读文件、改代码、跑命令。
- 审批卡点介入：遇到敏感操作，Space 暂停等你确认。
- 状态回写 Dots：任务进展被持久化，下次能接着干。
- 产出回到 Space：你能看到改了哪些文件、测试结果如何。
这条链路里，每一环都不可或缺。少了 Dots，Codex 每次都要重新建立上下文，又慢又贵；少了 Space，多个任务就没法有序组织；少了 Codex，前面两个就是空架子。
5.2 哪些环节最容易出问题
根据社区反馈和我自己的经验，最容易出问题的环节有三个：
第一是上下文召回不准。表现是代理改错了地方，或者忽略了某个关键约束。根因往往是索引质量差或项目结构混乱。解决办法是优化目录结构和注释规范，让召回更精准。
第二是审批策略配置不当。要么太松导致代理乱执行，要么太严导致频繁卡住、体验极差。这个只能靠实践慢慢调，建议从严格开始，逐步放宽。
第三是网络与凭证问题。前面讲过，这类问题占了求助量的大头。核心建议是：先把连通性和登录状态确认好，再谈其他。
5.3 一个我踩过的真实坑
说个具体的。有次我让代理做一个跨模块重构，它改到一半卡住了，报了个"模型不支持"的错。我第一反应是配置写错了，翻来覆去改配置，折腾很久没解决。后来才发现，是我在任务描述里无意中引用了一个实验性的模型标识符，代理把它当成了要调用的模型。
教训是：任务描述里不要出现任何看起来像模型名、配置项的字符串，否则代理可能误判。这个坑很隐蔽，因为报错信息指向的是配置，而真正的问题在任务文本里。从那以后，我写任务描述都会刻意避开这类"像配置的字符串"。
6. 实操建议：怎么把这套体系用起来
6.1 环境准备与安装的取舍
安装本身不复杂，但有几个取舍值得说。命令行工具通常提供多种安装方式：包管理器、安装脚本、预编译包。我的建议是优先用包管理器，因为升级和卸载都干净；如果包管理器版本滞后，再用官方脚本。
Windows 用户要注意，桌面版和命令行版的体验有差异。桌面版对图形界面友好，命令行版更适合脚本化和自动化。如果你主要做自动化，直接上命令行版；如果只是偶尔用用，桌面版上手更快。
安装完第一件事不是急着跑任务，而是先跑一个最小验证：让它读一个文件、改一行、再读回来。确认整条链路通了，再去干正事。这样出问题时你能快速定位是环境问题还是任务问题。
6.2 配置文件的稳妥写法
配置这块，我的原则是能少写就少写，能用默认就用默认。很多人喜欢从网上抄一份"完整配置"，结果抄进来一堆自己用不上的字段，反而引入问题。
稳妥的做法是：先用默认配置跑通，遇到具体需求再逐项添加。每加一项，验证一次。这样出问题时，你立刻知道是刚加的那项导致的。具体到字段，模型指定尽量留空用默认，组织信息按实际填，审批策略从严格起步。
提示：改完配置后，养成"打印最终生效配置"的习惯。很多诡异问题的根源，都是你以为生效的配置和实际生效的不是一回事。
6.3 任务描述怎么写才不容易翻车
任务描述的质量，直接决定代理的表现。我的经验是遵循三个原则：
- 说清目标，不说死步骤。告诉它"要达到什么效果"，而不是"第一步做什么第二步做什么"。代理自己会规划步骤，你管太细反而限制它。
- 明确边界。哪些文件可以改、哪些不能碰、必须遵守什么规范，这些要写清楚。
- 避开"像配置的字符串"。前面踩过的坑，任务文本里别出现模型名、路径模板这类容易被误判的内容。
一个反直觉的点：任务描述不是越长越好。写得太长，关键约束会被淹没。把最重要的两三条约束放在最前面，比写一大段背景更有效。
6.4 日常使用中的效率技巧
用了一段时间后，我攒了几个提效的小习惯。一是把常用规范写进项目级文档，让 Dots 自动召回，不用每次在任务里重复。二是给不同类型的任务建模板，比如"重构模板""修 bug 模板"，减少每次描述的成本。三是定期清理过期的上下文，避免旧信息干扰新任务。
还有一点：不要指望它一次做对。代理模式的价值在于迭代，第一版产出有问题是正常的，关键是你能快速看到它做了什么、哪里不对、怎么纠正。把心态从"一次生成完美代码"调整成"快速迭代逼近目标"，体验会好很多。
7. 关于"持续工作"这件事，我的一些真实体会
写到这里，我想聊点不那么技术的东西。这套体系最打动我的地方，不是某个单点功能多强，而是它试图回答一个问题：AI 编程工具怎么从"玩具"变成"同事"。
玩具的特点是，你玩一下、爽一下，然后关掉。同事的特点是，你们有共同的项目、共同的记忆、持续的分工协作。Dots、Space、Codex 这套组合，本质上是在给 AI 补上"同事"需要的那些基础设施——记忆、工作台、可管理的执行能力。
但我也得泼盆冷水：这套东西目前还远没到"开箱即用"的程度。配置要调、上下文要养、审批策略要摸索，前期投入不小。如果你的项目简单、任务零散，可能感受不到它的价值。它真正发光的场景，是那种需要长期迭代、涉及多个模块、还要持续跑验证的复杂项目。
最后分享一个我自己的判断标准：当你开始觉得"每次都要重新交代背景好烦"的时候，就是该上这套体系的时候了。在那之前，老老实实用简单的补全工具，别为了追新而追新。工具是拿来解决问题的，不是拿来供着的。
