Jason Liu 的 Codex 工作坊：别再把 Agent 当聊天框了

Jason Liu 在 AI Engineer 的这场 Codex 工作坊，表面是在讲 appshots、skills、plugins、memory、automation 和 computer use，实际讲的是一个更大的转向：Agent 不再只是接一次任务的工具，而是在被组织成可长期运行的个人工作系统。原视频：https://www.youtube.com/watch?v=il1c1a2FufU

这场工作坊真正讲的不是 Codex，而是工作形态

Jason Liu 开场说，他已经不太知道自己的工作是什么了。

这句话听起来像玩笑，但很准确。他不是只拿 Codex 写代码。他让 Codex 做原型、跑 eval、改 slide、编辑 iMovie、整理会议纪要、写文档、处理合作事务、追踪项目、生成自动化线程。Codex 在他的使用里不是 IDE 插件，也不是代码补全工具，而是一个能读取上下文、操作电脑、记住偏好、按时间醒来、彼此通信的工作台。

这也是这场 workshop 最值得看的地方。它没有把重点放在“怎样写一个好 prompt”，而是在展示一个更高级的问题：当模型已经足够能干，人的工作从“把每件事交给 AI 做”转向“把工作组织成可以被 AI 长期接住的系统”。

这个判断和最近几个月关于 Loop Engineering 的讨论是同一条线。过去是人站在循环里：我提示、AI 输出、我检查、我修正、再提示。新的玩法是让系统自己形成循环：触发、读取上下文、执行、验证、失败重试、写回记忆。人的位置往后退一点，不是退出，而是设计目标、边界和验证口径。

第一件事：输入方式变了，文字 prompt 不再是主通道

Jason 很早就提到一个细节：Tony Stark 不会用文字给 Jarvis 发消息。

他自己用脚踏板做语音输入，一个按钮转录，一个按钮提交。走到桌边，手背在身后，说一段很乱的话：修这个、改那个、顺便给某个 Slack 里的人发个消息。然后他继续和同事聊天。

这听起来像效率技巧，但它改变了人与 agent 的关系。文字 prompt 通常会逼人把问题压缩成干净的指令。语音输入允许你把脑子里没整理好的版本直接倒进去：背景、犹豫、旁支、模糊记忆、你不确定是哪次会议提到的东西。Agent 再去翻邮件、Slack、会议记录、旧线程，把这些模糊线索变成可用上下文。

这件事的重点不是“语音比打字快三倍”。真正的变化是：人可以把更多前置上下文交出去。AI 不再只收到一句清洁的命令，而是收到足够还原现场的杂乱材料。

这也解释了为什么 Jason 一直强调 appshots。他说普通截图信息太少，模型要 OCR，要猜 Slack channel，要猜人名，再调用多轮工具。appshot 同时给图片和 accessibility tree。对 agent 来说，这不是一张图，而是一段可操作的状态：它知道频道 ID、用户 ID、按钮结构和可点击目标。

截图是“给模型看”。appshot 更像“把当前 app 状态交给模型接管”。

第二件事：skills 和 plugins 把经验从聊天里搬出来

这场工作坊里，skills 和 plugins 的定位很清楚。

Skills 是几份文件、脚本和规则，保存“这类事应该怎么做”。Plugins 则把这些能力打包给团队共享，或者连接到 Slack、Gmail、Notion、Linear、Chrome、电脑控制等真实系统。

Jason 举了几个很实在的例子。

一个是 finalize Codex app 的 skill。公司里有人提 PR 前触发它，它会按团队风格和检查规则找问题。另一个是“review my code like Charlie / Dominic”，把某个同事过去一年的 PR review 风格吸收成审查 skill。还有一个是“write like me”，让 Codex 读取过去半年的邮件和 Slack，生成一份自己的写作风格指南，以后写消息就能更像本人。

这和普通 prompt 的差别很大。Prompt 是一次性委托。Skill 是可复用的工作习惯。Prompt 常常藏在一次会话里，用完就散了。Skill 会被团队、自动化和未来的线程反复读取。

这正好接上 Karpathy 的 spec / harness / verification 三层方法。模型本身只是底层能力。真正让能力落地的是 harness：上下文怎么带进来，规则怎么存，工具怎么调用，验证怎么跑。Jason 展示的 Codex 使用方式，本质是在把个人和团队的工作经验写进 harness。

第三件事：记忆不是“偏好列表”，而是工作系统的连续性

Jason 反复讲 memory，但他讲的不是“我喜欢简洁回答”这种轻量偏好。

他的个人 monorepo 里有 projects 目录、people 目录、松散笔记、agent summaries、daily summaries、todo list。项目目录记录每条 workstream。people 目录记录打过交道的人、他们在做什么、他们在哪些 Slack channel 里。todo list 由一个 thread 维护，必要时还会派 subagent 去验证某个任务有没有真的完成。

这类记忆的价值不在“模型下次想起你是谁”。价值在于，agent 不必每一轮从零发现组织结构。

他举了一个很典型的变化：一开始你必须明确 @mention 插件、指定数据源、说清楚去哪里查。随着项目文档、channel ID、people 信息、旧线程和 memory 都长起来，agent 会自己意识到“这个问题该去读 Slack / Gmail / Linear / 项目文件”。这和新人入职很像。头几个月你要给 SOP、纠错、让他写下教训。几年后你可以只说一句“帮公司多赚钱”，他知道去哪里动手。

这里有一个容易被忽略的分水岭：记忆不是越多越好，而是要变成可组织、可维护、可检索的文件系统。否则长期记忆会变成跨项目污染。Jason 在 Q&A 里也承认，项目之间的 memory bleeding 需要靠每个项目自己的 AGENTS.md / README 这类局部规则清理。

这和我自己的 Obsidian / LLM Wiki 经验也一致。RAG 只是取回上下文，Wiki 才是在积累判断。Agent 真正需要的不是一堆历史文本，而是能让下一轮行动少踩坑的结构化经验。

第四件事：automation 不是新建任务，而是“叫醒同一个工作线程”

工作坊中段开始，Jason 讲 automations 和 heartbeat。

早期自动化常见模式是：每天早上创建一个新线程，做一次 morning brief。Jason 认为，随着模型变强，更好的设计是把定时消息发回同一个长期线程。线程保持项目记忆，heartbeat 只是把它叫醒。

这个细节很关键。

如果每次自动化都新开线程，系统会不断失忆。每次都要重新读背景，重新判断优先级，重新建立上下文。把 heartbeat 发回同一条 pinned thread，线程就更像一个长期负责某件事的 teammate。

他把 /loop 描述成“keep an eye on this”。比如：盯着这个 PR，有反馈就修，保证它一直可合并，CI 挂了就处理，直到满足条件。heartbeat 不是神秘功能，只是定期把一条消息投回线程，让它根据当前状态继续行动。

这和 Loop Engineering 里的 closed loop 完全同构：目标明确，触发明确，检查明确，失败就重试，完成就停止。区别只在于，这里 loop 的载体不是一个脚本，而是一个长期线程。

第五件事：/goal 的核心是 verifier，不是更长的任务描述

Jason 对 /goal 的解释很短，但信息密度很高：它定义一个 verification step。只要验证没过，就继续做。

这就是 goal 原语的关键。

很多人以为 goal 是“给 AI 一个更大的任务”。其实 goal 的价值不在任务更大，而在停机条件更清楚。没有 verifier，agent 只能自我汇报“我觉得做完了”。有 verifier，promise 才变成 contract。

Jason 举的例子是迁移软件到 Rust：如果这个 Python 项目适合迁移，就迁移后端到 Rust，并保证所有 unit tests pass。他说自己用这种方式重写过 rich terminal library，也试过 rewrite UV 和 TypeScript，看能不能做到 100% test coverage。

无论例子多夸张，原则很朴素：生成能力越强，验证越重要。Karpathy 那套 spec / harness / verification 里，最不贬值的一层也是 verification。Spec 和 harness 会随着模型变强而变化，但“怎么知道它真的做对了”不会过时。

第六件事：computer use 把 agent 从“文件系统”带到“桌面世界”

Jason 说 computer use 是他第一次在工作中有“AGI 感”的功能。

它不是只能控制浏览器，而是可以在后台操作任意 app。Chrome extension 控制 Chrome，computer use 控制 Slack、iMovie、交易软件、系统 app，甚至通过屏幕镜像控制 iPhone。Jason 用它导出 iMovie、给视频加音效、填表、签 DocuSign、找传真服务发医疗记录、在 checkout 页面找优惠券、测试 native app。

这部分最容易被当成 demo 看热闹。但它背后的意义是：agent 的执行面从代码和 API 扩展到了整台电脑。

这会带来真正的安全问题。Jason 特意讲到：如果 Slack connector 不能上传文件，一个很“坚定”的模型可能会打开电脑控制，点文件上传按钮绕过去。如果 Gmail connector 发不出邮件，它可能打开 Chrome 去点发送。能力越强，权限边界越要清楚。

所以他提到 permission sidebar：可以要求每次操作都询问，也可以开放更高权限。工程上，这对应 agent harness 里的 G 层：governance / gate。不是模型“会不会乱来”的问题，而是系统有没有把高风险动作放在可审计、可拦截的位置。

第七件事：线程可以互相通信，个人 agent 系统开始出现组织结构

工作坊后半段，Jason 讲了一个更有意思的方向：threads can talk to each other。

每个线程可以列出其他 pinned threads，可以重命名线程，可以给别的线程发消息。这样你不只是有一堆 subagents 在后台跑，而是有一组可见、可命名、可管理的工作线程。

他的例子是支持问题监控。一个 monitor thread 发现 Twitter 或 Slack 上有人反馈某类问题，就创建一个 triage thread。triage thread 负责调查、联系相关人、跟进 PR 或 Slack ack。如果之后又有人抱怨同一个问题，monitor thread 会识别“这是同一件事”，然后给之前那个 triage thread 发消息：这个问题又复现了。

这已经不是单个 agent 完成单个任务，而是 agent 之间有分工、状态、引用和升级路径。

这也解释了他为什么喜欢 pinned threads。普通 subagent 像后台漂浮的实体，用户很难长期感知它们。Pinned thread 出现在 sidebar 里，你能看到某条 workstream 还活着，能改名，能叫醒，能让别的线程给它补上下文。

这是一种很早期的“个人组织结构”。IC thread 做具体任务，manager thread 追踪状态，monitor thread 发现外部信号。今天看起来还很手工，但方向已经很清楚。

这套方法的真实门槛：不是 token maxing，而是 taste

Jason 整场一直在弱化“烧 token 很酷”这件事。他说自己不是最大的 token maxer，也看到有人每天烧几十亿 token。目标不是浪费 token，而是避免浪费 token。

这句话很重要。Agent 系统最大的浪费不是 token 本身，而是让 agent 每轮重新发现同样的上下文、重复犯同样的错、在没有验证口径的状态下长跑。

Q&A 里有人问，AI 快速变化后，开发者还该练什么。Jason 的回答很老派：要有 taste，就要多吃。多试 app，知道好的 onboarding 是什么感觉，知道什么体验让你烦，发展一套描述坏东西的词汇。你描述不了自己不懂的东西。

这段和前面所有自动化正好形成平衡。Agent 可以跑很远，但 taste 仍然在人这边。你决定什么应该变成 skill，什么应该变成 goal，什么应该拆成新 thread，什么只是一次性消息。你决定哪些动作可逆，哪些必须 human gate。你决定 loop 什么时候停。

Loop Engineering 那篇材料里有一句话很适合放在这里：两个人可以搭出一模一样的 loop，一个用它加速自己深刻理解的工作，另一个用它逃避理解。Loop 分不出区别，你能。

对我们有什么用

如果把这场 workshop 压成几条可执行判断，我会保留这几条。

第一，别再把 agent 当聊天框。能沉淀的流程要写成 skill，能验证的目标要写成 goal，能定时检查的状态要交给 heartbeat，能长期负责的工作流要放进 pinned thread。

第二，记忆要文件化。项目、人物、决策、旧线程、操作日志都应该有可读的位置。不要指望模型神奇记住一切，给它一个能成长的工作目录。

第三，先做 closed loop。目标、权限、输入、输出、验证、失败重试、停止条件都讲清楚。open loop 可以探索，但没有 quality gate 的 open loop 只是昂贵噪声。

第四，computer use 和 appshot 值得重视。API 是干净世界，桌面是真实世界。真正的个人 agent 会同时需要二者，但权限门禁必须跟上。

第五，最该投资的是 verification。模型会越来越会生成，真正稀缺的是你能不能定义“什么叫做了、什么叫做对了、什么情况下必须停下来问人”。

Jason 这场工作坊不像一个“Codex 新功能介绍”。它更像一次真实用户把产品推到边界后的现场报告。真正的新东西不是某个按钮，而是工作单元正在从“单次对话”变成“长期线程”，从“提示模型”变成“设计循环”，从“AI 帮我做事”变成“我维护一套会醒来、会读上下文、会操作电脑、会互相沟通的工作系统”。

这也是 Codex Maxing 最容易被误解的地方。表面上是 token、线程、自动化和权限。底层其实是工作治理：你怎样把自己的判断、经验、边界和验证写进系统里，让 agent 不只是更勤快，而是真的更可靠。