AI 相关回顾：模型、工具与 Codex
GPT-6 Astra 上线，先回顾模型、工具与 Agent 的关系，再聊聊 Codex 怎样进入日常开发。
原本想直接写 GPT-6 Astra。打开资料才发现，如果沿着发布宣传往下写，很容易又变成一篇模型功能清单：更强的推理、更长的任务、更少的人工介入，然后接一句“AGI 时代来了”。
但过去这段时间，变化最大的是用工具做事的方式。以前主要在聊天窗口里问问题、拿代码；现在会把仓库、运行环境、浏览器和验收要求一起交给 Agent，让它接着执行。中间听到的新词也越来越多：Function Calling、MCP、Skill、RAG、Harness，最近连 FDE 都经常被放进 AI 的讨论里。
几个词单独看都能解释，摆在一起却容易乱。有人说 Skill 淘汰 MCP，有人把装好一个 Agent 产品说成获得了 AGI，还有些介绍把原本熟悉的软件工程工作换个名字，听完反而不知道该做什么了。
这次回顾起于飞天闪客的三段视频：名词拆解、Harness，以及 AI 底层逻辑。它们帮我把几个接口之间的关系串了起来。整理笔记时，又对照论文和官方文档补了一些边界。视频里的比喻适合入门，往实际开发里放，还需要多走一步。
GPT-6 Astra 的具体变化留到下一篇。官方模型指南已经列出它在代码、浏览器操作和多步骤任务上的能力；这些能力哪些来自模型，哪些依赖模型周围的软件，正好可以用这篇梳理出的认识继续看。
1. AI 底层逻辑：模型学到了什么，又怎样做事
1.1 从写规则，到训练出处理规律的能力
这里讨论的主要是以 GPT 为代表的生成式大语言模型，并不打算用一种原理概括整个 AI 领域。
传统程序里，规则通常是开发者明确写出来的。比如博客只显示带有“阅读”标签的文章，程序遍历数组，检查标签，返回匹配项。输入和规则确定，结果就应该确定。
大语言模型的训练走的是另一条路。以自回归语言模型的预训练为例，系统把文本切成 token，根据前面的内容预测后续 token，把预测与训练目标之间的差距转成损失，再通过优化过程调整参数。这样的过程在大量数据上反复进行。
Token 是模型处理内容的基本单位，可以是字、词的一部分、标点或代码片段，不能简单按“一个 token 就是一个汉字”理解。参数则是训练得到的大量数值。常规使用时，我们没有在对话里逐个修改这些数值。
“预测下一个 token”听上去很简单，但要在大量不同文本里把预测做好，模型需要学到语言结构、知识关联，以及完成许多任务时有用的表示和计算模式。GPT-3 的论文就讨论了不更新参数、只在输入里给出说明与少量示例，也能完成多种任务的现象。
所以，“它的生成过程可以分解成逐个 token 的预测”和“它只会机械接龙”是两种不同的判断。前一句描述一种计算机制，后一句把能力边界也顺手下了结论。理解机制以后，仍然要通过任务表现判断它会做什么、在哪些条件下会失败。
1.2 Transformer、训练与推理，分别发生在哪里
Transformer 是这类模型的重要基础。文本先被转换成向量表示，注意力机制根据当前内容计算不同位置之间的关联，多层计算逐步形成后续预测所需的表示。写代码时，一个变量究竟指向哪里、一处错误可能和前面哪段定义有关，都需要利用跨位置的信息。注意力提供了处理这种关联的机制，但“关注了某段内容”不等于已经验证它正确。Transformer 原始论文适合用来追溯这部分结构。
把从训练到使用的过程拆开，会清楚一些：
预训练：从大量数据中形成基础能力
训练更新模型参数，学习语言、代码及其他数据里的结构。数据质量、模型结构、训练方法和计算资源都会影响结果，不能只看参数数量。
后训练：让能力更适合任务与交互
通过指令示例、偏好反馈或奖励等方式，进一步训练模型遵循要求、使用工具、处理推理任务。不同模型采用的具体方法不同。InstructGPT 论文是理解指令微调与人类反馈的一份早期资料，并不代表所有新模型的完整训练方案。
推理：用已有参数处理这一次输入
模型读取当前上下文，生成后续内容。推理模型还可能在给出最终答案前进行更多中间计算。花更多推理时间和重新训练模型，是两回事。
执行与验证：让软件接住模型的输出
如果输出是工具调用，外部程序负责真正执行，再把文件内容、报错或浏览器观察结果送回来。此时得到的是一个能够与环境交互的系统。
这也解释了一个很常见的误会：把资料发给模型，它后来能回答相关问题，并不意味着它已经把资料永久学进参数。资料可能只是留在本轮上下文里，或者被产品保存在外部记忆中，下次再检索出来。
1.3 Prompt、Context 和 Memory
Prompt 通常指给模型的指令与输入。Context 是本次模型实际能够利用的信息，除了当前问题，还可能包括系统要求、历史对话、检索片段、工具定义、工具返回值、图片等。两者在日常用语里会重叠，不必为了画图硬切成互不相干的盒子。
Memory 则要追问一句：存在哪里，怎样取回来？
聊天记录、项目里的说明文件、数据库中的偏好、上轮任务的摘要，都可以承担“记忆”的作用。产品需要选择哪些内容重新放进上下文。文件明明存在，如果没有被读到，这一轮模型就未必知道；摘要如果漏掉了关键约定，下一轮也可能重新犯错。
看一个与博客开发有关的虚构例子。模型没有变化，只把报错、源码和接口响应分次交给它，能够支持的判断就发生了变化。
同一个模型，看到的证据变了
需求：给博客增加文章筛选。 报错：posts.filter is not a function
先检查 posts 的实际类型。只有一句报错，还不足以认定是哪一层的问题。
虚构的教学案例；条形长度仅帮助理解证据变化，不是实测模型概率。切换信息不会训练或更新模型。
补充上下文的价值在这里很具体：把“可能如此”逐步缩小到能查证的原因。给它更多无关文档，未必比给出一条准确的接口响应更有效。
1.4 为什么说得很像，仍然可能是错的
生成一个符合语言习惯的解释，与确认解释符合当前仓库，是不同的工作。模型可能记得旧版本 API，可能把两个相似库的接口混在一起，也可能在证据不足时补出一段完整故事。
视频用“从规律中学习”的方式解释模型，这对理解错误来源很有帮助。不过，从统计学习不能直接推出“模型绝对不会推理”，更不能据此证明智能一定停在某个上限。另一方面，参数超过一个数字就会稳定获得某种智能，也不是可以通用于所有模型的定律。
落到开发里，我更关心错误能否被发现。生成一个 JSON，交给解析器和 Schema 检查；修改一个筛选函数，运行相关测试；声称手机端排版正常，就打开窄屏页面。检查不保证覆盖所有问题，却给了判断一个外部依据。
多问几遍也有用，但不同回答可能重复同一种错误。模型自己说“检查过了”，与测试进程返回结果，证据分量不一样。后面的工具调用和 Agent，正是把这条验证路径接起来。
2. AI 圈造词大解析
“名词诈骗”这个说法挺解气。真正容易把人带偏的，是把接口协议、知识组织方式、完整产品和职业名称放在同一条进化链上，仿佛后来的词一定淘汰前面的词。
先把它们放回各自解决的问题里：
| 名词 | 主要解决什么问题 |
|---|---|
| Function Calling | 模型怎样表达要调用哪个工具、传什么参数 |
| MCP | AI 应用怎样按共同协议接入外部工具与上下文 |
| Skill | 怎样把一类任务的做法与资源整理成可复用的能力包 |
| RAG | 回答前怎样取来相关资料，作为生成依据 |
| Agent | 怎样围绕目标，依据反馈持续选择和执行下一步 |
| OpenClaw / WorkBuddy | 怎样把模型、工具、入口和任务管理做成可用产品 |
| Harness | 怎样组织 Agent 的运行条件、反馈、约束与接续 |
| FDE | 谁进入业务现场，把技术做成能产生结果的系统 |
| AGI | 怎样讨论跨任务的通用能力，以及达到什么程度 |
2.1 Function Calling：模型提出调用，程序负责执行
假设要给博客加文章筛选，模型首先需要知道现有文章放在哪里。应用可以给它一个 list_articles 工具，说明用途和参数。
模型随后可能返回下面这样的调用意图。这里只展示名称与参数，不是某家 API 的完整响应格式：
{
"name": "list_articles",
"arguments": {
"directory": "docs/blog",
"includeDrafts": false
}
}接下来，应用检查工具是否存在、参数是否合法、目录是否允许访问，再执行相应代码，把文章列表交回模型。模型看到结果后，才能继续分析数据结构或决定读取哪个文件。
模型生成调用请求，不会因为写出一个函数名就直接拥有执行权限。 OpenAI 的 Function Calling 文档也把工具执行明确放在应用一侧。
不使用专门的工具调用接口，也可以要求模型输出约定的 JSON，再自己解析。Function Calling 把这种协作变成模型与 API 明确支持的交互方式，省去很多从自然语言里猜调用意图的麻烦。结构约束能提高格式可靠性，但 JSON 合法不代表参数适合当前业务，更不代表这次操作已经得到授权。
读文件、查数据库、执行测试、控制浏览器，都可以被包装成工具。工具背后可以是一段本地代码，也可以调用远端服务。它们是否使用 MCP，是下一层的问题。
2.2 MCP：把每家都要接一次的接口规范起来
接一个工具不难。工具多起来、客户端也多起来，重复适配就很烦：同一个文章库，要分别接给几个 AI 应用，每个地方都维护一套工具说明、调用方法和返回格式。
MCP，全称 Model Context Protocol，处理的是这种连接问题。提供能力的一侧实现 MCP Server，AI 应用作为 Host，通过其中的 MCP Client 与服务通信。Server 可以运行在本机，也可以在远端；它不是大模型的另一种叫法。
以工具为例，客户端可以用 tools/list 发现工具，再用 tools/call 发起调用。除了工具，协议还定义了 Resources 和 Prompts，用于提供上下文资源和可复用提示模板。具体版本的协商与传输细节应查官方架构说明。
这里没有“Function Calling 与 MCP 谁更先进”的问题。前者关注模型怎样表达调用，后者关注应用怎样连接能力提供方。应用完全可以把 MCP 工具转换成模型支持的工具定义，也可以让某些本地工具直接执行。
共同协议减少适配成本，但数据库查询怎样写、返回信息是否准确、失败怎样处理，仍然要由服务实现。接入 MCP 不会自动解决这些问题。
2.3 Skill：把做过几次的事，整理成下次能直接用的办法
写博客时，有些要求会反复出现：先查资料，区分事实与个人判断，保留文章链接，生成封面，检查摘要长度，最后构建并打开页面。
每次都重新口述一遍，既累，也容易漏。可以把它们整理成一个 Skill：说明适用场景、执行顺序、交付标准，再附上需要的模板或脚本。例如：
blog-review/
├── SKILL.md
├── references/
│ └── writing-and-cover-rules.md
└── scripts/
└── check-article-metadata.mjs按 Agent Skills 的格式，核心文件是 SKILL.md，其中包含名称、描述和指令，其他资源按需附带。兼容的 Agent 可以先读名称与描述，判断相关性，再加载完整说明及具体资源。这就是渐进式披露。
装上这个 Skill，没有修改模型参数。它把原本零散的任务知识整理出来，让 Agent 在合适的时候读到，并调用现有工具执行。能否稳定完成，还取决于说明质量、模型能力、脚本和运行环境。
把 Skill 简称为“一份提示词”并非完全说错，但容易漏掉资源组织、脚本复用、版本管理和按需加载这些实际价值。一个经过使用和修订的 Skill，往往记着不少正文之外的细节：哪些输入容易失败、检查哪几处、什么结果才算交付。
Skill 与 MCP 也可以配合。 Skill 写“先从文章库取回元数据，再生成目录”，文章库恰好通过 MCP 暴露。换成 CLI 或直接 API 也行，任务方法与连接方式可以分别变化。某些简单场景里，Skill 加脚本确实能省去一个 MCP 服务，但这不能推导出跨应用连接、远端鉴权与标准化接口都没有价值。
至于 token 越来越便宜后，还要不要按需加载：我仍然倾向于保留。上下文里塞满无关说明，会增加干扰和等待，也让问题更难定位。价格只是其中一个因素。
2.4 RAG：回答前，先把依据找过来
如果问“之前哪几篇读书笔记谈到了独处”，模型没有读过这批文件，就只能猜。RAG，Retrieval-Augmented Generation，也就是检索增强生成，让系统先检索相关材料，再把材料交给模型组织答案。早期 RAG 论文给出了把参数化模型与外部检索结合的具体研究方案。
在博客这个例子里，可以先建立文章索引。查询时找到“独处”“孤独”“自我相处”等相关段落，保留文章标题、出处和位置，再让模型解释它们的联系。最后的引用应当能点回原文，而不是只有一句“根据知识库”。
向量检索很常见：把查询和文本片段编码成向量，用相似度寻找候选内容。但 RAG 不要求每个实现都配向量数据库。标题、专有名词、错误码适合关键词检索；语义接近而用词不同的内容适合向量召回；也可以组合检索，再过滤或重排。这里介绍的是今天常用的工程范式，不把某篇早期论文的实现当成唯一形式。
RAG 与微调的区别也在这里：前者主要改变这次生成能看见的材料，后者通过训练更新参数。文档经常更新，需要保留出处时，把资料留在可更新、可检索的存储里通常更好维护。
检索到内容，并不意味着问题已经解决。段落切断了限定条件、旧文档排在新文档前、检索词漏掉同义表达，都可能让答案出错。排查时要分别看：有没有检索到，取回的是否合适，模型是否忠实使用了材料。只盯着最后一句回答，很难知道该改哪一段。
2.5 Agent：下一步怎么走，开始由模型参与决定
用聊天窗口写代码时，人经常承担循环里的大部分工作：复制代码，保存文件，运行命令，把报错贴回去，再复制一版。
Agent 把其中一些步骤接了起来。给它目标，它读取环境、选择动作、通过工具执行，观察结果，再决定下一步。关键变化是：任务执行路径可以随反馈调整。
这里采用 Anthropic 对工作流与 Agent 的区分：工作流主要沿预设路径组织模型和工具，Agent 则让模型动态决定过程与工具使用。实际系统常常混合两种方式，行业里也并没有只有一种 Agent 定义。
继续用文章筛选这个例子。真正值得关注的，是失败结果怎样进入下一轮，而不只是它生成代码有多快。
让 Agent 把文章筛选做完
范围：已有博客的文章筛选。验收：逻辑测试通过，桌面与窄屏页面可用。
- 1读代码
- 2做修改
- 3测试失败
- 4修复代码
- 5浏览器发现问题
- 6修复布局
- 7验收通过
- 8交付与接续
读取目录组件、文章元数据与已有测试。 发现：部分旧文章没有 tags 字段。
接下来：确定筛选规则，沿用现有组件与样式。
点击逐步演示。代码、日志和结果均为预设案例，不会执行命令，也没有调用在线模型。
一个可用的循环还需要停止条件。需求已经满足就交付；遇到缺失信息、权限限制或不断重复的失败，就应暂停并说明。没有边界的重试，可能只是在持续消耗时间和费用。
Subagent 则是把一部分任务交给拥有独立上下文的执行单元，例如分别检查接口契约和页面交互，再汇总结论。它能减少某些上下文干扰，也会带来信息交接和协调成本。任务之间高度依赖时，多开几个 Agent 未必更快。
这让我重新看了一眼之前做的 resume-cli。其中固定权重算分，直接由 Python 完成；需要理解简历与岗位描述的部分，才交给模型。那次还特意讨论过要不要拆成多个 Agent，最终保留了更简单的调用方式。今天多学了几个名词，这个选择仍然成立。
工作流也不只存在于拖拽界面里，一段 Python 或 TypeScript 就能表达固定流程。LangChain 是开发框架，也不适合直接放在一条“僵硬程序到自由 Agent”的坐标轴上替所有实现定性。判断时，还是看谁决定下一步、依据什么决定。
2.6 OpenClaw 与 WorkBuddy：把能力装进日常入口
OpenClaw 容易给人一种“突然出现了新智能”的感觉。看它的官方文档，可以找到更具体的组成：Gateway、消息渠道、Agent 会话、模型提供方、工具、Skills，以及定时任务等。
它把这些能力组织成一个可以自行部署、从聊天入口触达的助手。用户不必每次打开开发环境，也能发送任务、接收结果。模型的能力由所接入的模型及整套运行环境共同决定，OpenClaw 本身并不是一个新训练出来的基础模型。
这类产品的价值，也不能因为“底层还是模型加工具”就一笔抹掉。入口是否方便、任务能否持续、失败能否恢复、消息与文件能否正确流转，都影响它最后会不会被留下来使用。
后来进入视野的 WorkBuddy 也放在这个产品层面理解。腾讯的产品介绍把它定位为面向多场景工作的桌面 AI 助手。它和 OpenClaw 可以被放在同一类使用需求下讨论，但不能因此说成同一个项目的改名版。腾讯在官方业绩材料中将自研 WorkBuddy 与基于 OpenClaw 的 QClaw 分别列出，项目关系要区分清楚。
我会用具体工作比较这类产品：它能接入哪些现成环境，能完成多长的任务，失败后怎样继续，结果怎样检查。只比较首屏聊天体验，往往看不到真正影响长期使用的部分。
2.7 Harness：让 Agent 在真实项目里持续干活
Harness 原义与挽具、约束和驾驭有关，软件领域也早有 test harness 这样的说法。现在 AI 圈经常用它指模型或 Agent 周围的一整套运行支撑。
刚听到这个词时，最困惑的是它的范围。工具算不算？提示词算不算？测试、权限、项目文档算不算？不同文章讨论的层次并不相同。直接背下“Agent = LLM + Harness”，遇到另一种用法又容易混乱。
视频里有一点很值得保留：产品怎样组织模型工作，与开发者怎样组织产品在项目里工作，是两个可以分别观察的层次。
| 观察位置 | 实际要处理的事 |
|---|---|
| Agent 产品内部 | 工具调度、上下文整理、执行权限、失败恢复、任务状态、可观察的记录 |
| 项目与使用方式 | 清楚的需求、仓库约定、可运行的环境、验收方法、小步修改、跨会话交接 |
举个容易发生的偏航：需求只是修改页脚颜色，Agent 发现构建报错后，开始升级依赖；升级引出兼容问题，又准备更换构建配置。每一步都能讲出理由，整个任务却已经离原来的目标越来越远。
给它写一句“不要乱改”太抽象。更有用的是明确修改范围，说明已有报错怎样处理，要求提供差异与验证结果，并在运行环境中设置对应权限。写在提示词里的约定依赖模型遵守；文件系统、沙箱和审批机制则可以在执行层阻止不允许的动作，两者不能混为一谈。
还有一种问题发生在长任务里：窗口换了，前面做到哪里就模糊了。Anthropic 关于长时间运行 Agent 的工程文章讨论了用进度记录、功能清单、环境初始化与增量验证帮助不同会话接续。它说明仅靠上下文压缩不足以解决所有连续工作的问题；这不等于所有任务都应该禁止压缩。
前一篇 resume-cli 记录里，其实已经做了不少这类事：先把命令职责、数据结构、评分规则和测试范围写进实施计划，再分阶段开发；遇到新决定，回头更新约定；通过真实输入、测试与人工检查确认结果。现在把它们放在 Harness 这个词下面，能看出相互关系，但并不需要为了跟上新词，把现有流程推倒重做。
我会把 Harness 的效果看得很具体：新一轮任务是否能找到当前状态；报错是否真的被处理；“完成”是否有依据；局部修复有没有越过原来的范围。模型更强之后，一些手工步骤可能被产品接管，项目里的目标和验收仍然要有人说清楚。
2.8 FDE：这里开始说人了
FDE 通常指 Forward Deployed Engineer，可以译为前线部署工程师。这个词经常与 AI 项目放在一起，但它首先描述角色与工作方式。
Palantir 的官方说明强调进入客户实际环境开发、交付，并让现场经验持续影响产品。它早于这一轮大模型热潮；把它简单理解成 AI 时代新发明的“提示词工程师”，会漏掉大部分工作。
假设一家企业想做内部知识助手，演示时能答对几道问题并不难。进入实际使用以后，文档权限、历史版本、内部缩写、审批流程、数据归属、旧系统接口都会出现。接下来需要有人和使用者一起确定到底要改善哪项工作，完成集成、验证效果，再把反复遇到的问题变成可以复用的产品能力。
这样的工作同时需要工程实现、业务理解和沟通，不宜只按“售前”或“驻场外包”几个字概括。Palantir 一位长期从事 FDE 的员工也特别强调对结果负责，以及把现场经验反馈到平台的过程。
对做全栈开发的人来说，其中很多工作很熟悉。真正需要继续补的，是怎样评估模型输出、怎样设计人机协作、怎样把不稳定的模型能力放进可维护的业务系统。职位换了名称，交付仍然要面对这些具体问题。
2.9 AGI：谈论之前，先说清楚任务范围
AGI 是 Artificial General Intelligence，通常译为通用人工智能。它讨论的范围比会聊天、会写代码，或者能持续调用工具更广。
看到“AGI 已经实现”，我现在会先看它在说哪几个维度：能做的任务有多广，完成质量达到什么水平，陌生任务能否迁移，多少环节需要人工干预，以及换一个环境是否仍然可靠。
《Levels of AGI》尝试从能力的深度与广度建立分层，并讨论自主程度等部署因素。这是一种研究框架，不是所有机构共同接受的一张认证表。它至少提醒我，不能把“操作电脑很自主”和“所有领域都很通用”当成同一件事。
写代码是很适合观察 Agent 进展的领域。文件、编译器、测试、浏览器都能提供反馈；不少任务也能被拆成边界较明确的工作。因此，一个系统可能在某些开发任务上已经非常像能独立工作的同事，却仍然在开放的业务判断、需求取舍或缺少验证条件的任务上不稳定。
所以后面说“开发范围的 AGI”时，我用的是个人体验中的简称：在明确边界内，能够接住一项工作，并持续执行到有结果。它不是对通用人工智能已经实现的技术证明。
3. Codex：这些概念怎样落到日常工作里
3.1 Codex 是什么，什么样的开发者会需要它
这里说的 Codex，是 OpenAI 面向软件开发的 Agent 产品与工具体系。底层模型负责理解、生成和决策；Codex 把它放进能读取仓库、编辑文件、执行命令、检查结果的工作环境。ChatGPT 是我日常讨论和整理问题时更熟悉的入口，两者与底层 GPT 模型也要分开理解。
让我留下 Codex 的，是任务不必停在一段建议上。讨论需求以后，它能继续查看真实代码，做修改，运行验证，再把结果交回来。我可以围绕同一份工作继续追问和调整，少做许多来回复制的动作。
有句话说得直一点：
在开发者这个范围里，能找到 Codex 并且自行用起来的人，说明他需要 Codex；没有用到的人，说明他暂时不需要 Codex。
这里的“需要”说的是眼下工作中已经显现出来的需求。有人每天都在跨文件改功能、排查问题、维护个人项目，很容易主动找到这类工具。有人当前的工作方式已经顺手，或者受到访问、成本和公司规定的限制，没有用上也很正常。用不用它，说明不了开发水平高低，更没有必要把安装工具变成一种紧迫的身份要求。
个人偏好也没必要藏着。Anthropic 的 Claude 编码能力确实不错，但封号这件事，tmd 就很烦。再好的工具，使用时还得惦记账号能不能继续用，也会影响选择。对我来说，OpenAI 的 ChatGPT 更合习惯，Codex 也因此更容易进入日常工作。这是个人取舍，不是给所有人的统一排名。
3.2 GPT-5.6 加浏览器，已经有了开发范围里“AGI”的感觉
这种感受其实不用等到 GPT-6。到 GPT-5.6 这一代，配合 Codex 的执行环境和 Chrome 浏览器扩展，我已经愿意用“开发范围内有了 AGI 的感觉”来形容它。
原因很具体：它既能改代码，也有条件查看代码运行后的页面。以前经常是它说改好了，我再启动项目、打开浏览器、截图、描述错误；把浏览器接进任务后，这部分反馈可以直接进入它的下一轮处理。
当前官方浏览器扩展文档支持从桌面应用的 Codex 或 Work 会话使用 Chrome 等浏览器，引用标签页、读取页面，并在授权范围内操作。具体可用性仍与客户端版本、功能开放情况和设置有关；它也不只服务于某一个 GPT 版本。
假设任务是“给文章目录增加筛选，手机上也要好用”，一段完整的执行过程可以包括：
读取仓库，确认接入位置
查现有目录组件、文章元数据、样式和构建命令，先确定需要改变的部分。
实现功能，检查逻辑
修改文件，处理没有标签的旧文章与空结果，运行相关验证。
打开页面，检查实际交互
点击筛选按钮，查看内容是否变化，再看窄屏下的按钮、长标题和空状态。
根据反馈继续修复，再交付结果
处理发现的问题，说明修改内容、验证结果和仍需人工决定的事项。
这时能观察到的能力属于整个系统：GPT-5.6、Agent 执行循环、文件与终端工具、浏览器连接，以及项目提供的验收条件。Chrome 扩展补上了一个与环境交互的通道，不会单独把模型“升级成 AGI”。
浏览器反馈也有边界。界面能点击，不代表后端数据一定正确；页面没有明显错误，也不代表性能、权限和边界情况都通过了验证。它让我减少了重复操作，同时也让我更容易要求一份具体的验收结果。
3.3 为什么现在更偏向 Codex
比较编码 Agent，最容易陷进去的是模型榜单。实际每天使用时，我更在意从需求到验收中间有多少次需要手工接力。Codex 吸引我的地方主要集中在这里。
第一，任务能从讨论自然进入仓库执行。
以前在聊天工具里讨论方案，再把整理后的要求交给编码工具，两边的上下文很容易出现偏差。现在能够围绕同一项任务持续讨论和修改，对个人项目尤其省事。resume-cli 就是从需求边界、实施计划一路推进到代码与验证，前一篇已经把实际过程写了下来。
第二，修改结果便于审查。
Codex 提供代码差异与审查入口，可以围绕具体改动继续反馈。官方 Code Review 文档也说明了对未提交修改或指定分支进行审查的方式。看得见差异，才容易发现它是否顺手动了无关部分。模型审查可以帮助找问题，最终仍要结合测试和对项目的理解。
第三，并行工作有仓库层面的隔离。
Worktree 功能利用 Git worktree，为不同任务提供独立工作目录。这样我继续做手头的修改时，另一项任务可以在自己的目录里推进。这解决的是文件与分支的组织问题，最后整合仍可能遇到冲突，多个任务同时修改同一处设计也仍然需要协调。
第四，浏览器、资料和项目文件能进入同一段工作。
个人开发很少只有写函数。查文档、核对页面、整理方案、生成文章、处理文件，也占了不少时间。Codex 加上适用的工具、Skill 和浏览器连接，可以覆盖这些相邻工作，减少在几个工具之间搬运背景信息。
这些能力并非每项都只有 Codex 才有，其他编码 Agent 也在发展自己的实现。我没有做覆盖所有产品的同条件测评，不会据此宣称 Codex 在所有任务上都更强。对我目前的个人项目，它把几项经常需要的能力接得比较顺，所以在实际选择里更占优势。
3.4 作为个人高级助手，怎样用才值
如果已经有持续维护的项目，需要一个能讨论、查资料、执行修改并协助验收的助手，Codex 很值得认真用一段时间。不要只用它生成几段代码，再据此判断整个工具的价值。
比较合适的起点，是交给它一个范围清楚、可以回退、结果可检查的真实任务。比如梳理一个模块，补上某个已确认的功能，修复能复现的问题，或者整理一篇需要核对资料的技术文章。
要求写清楚以后，让它把必要的工作做完。讨论设计时看依据，检查实现时看差异，验收时看实际结果。频繁纠结每个命令怎样敲，会把本来能够委托的工作重新拿回手里；什么都不看，又容易让错误积累到后面。
成本也要按一整项任务看。长任务可能包含多轮推理、工具调用和验证，模型单次回答的价格并不能代表最终开销。我更愿意比较的是，完成到可以接受的程度，花了多久，需要我介入几次，后面还剩多少返工。
下一篇再看 GPT-6 Astra 时，就可以沿着这条实际工作过程追问：哪些任务过去经常中断，现在能够持续完成；哪些判断需要更少补充说明；浏览器与工具使用是否更可靠；最后交付的结果，是否真的少了几轮人工返修。
如果这些地方有变化，就把具体过程写出来。这样再谈“更接近 AGI”，至少能知道这句话在自己的工作里对应了什么。
本次回顾的资料
三段视频均来自 B 站 飞天闪客。文章沿用其中值得继续思考的问题，例子与表述重新组织；涉及协议、产品能力和研究结论的地方，已在对应段落附上原始资料。产品信息核对时间为 2026 年 9 月 5 日。
- 一口气拆穿 Skill / MCP / RAG / Agent / OpenClaw 底层逻辑（14 分 46 秒）：工具调用、上下文与 Agent 的连接关系。
- 你管这破玩意叫 Harness？虚拟世界的牛马套餐！（11 分 32 秒）：运行约束、项目接续，以及两个层次的 Harness。
- 如何给我姥姥讲明白 AI 的底层逻辑？（5 分 42 秒）：从学习规律理解模型能力与错误；本文另外补充了训练、推理和外部验证的区别。