Jason Liu 在最近一场 Codex 工作坊里，提到了一个很容易被截成标题的数字。
他有一条已经持续五周的工作线程，里面先后调用过大约 400 个子 Agent。按他的说法，这条线程仍然知道自己要做什么。
如果只看这个数字，这又会变成一个“AI 替你管理 400 个员工”的故事。
但这场 70 多分钟的分享真正有意思的地方是：抛开 400 这个数字，这套工作为什么没有在第二天就散掉？
Jason 在 OpenAI 做 Developer Experience。他用 Codex 处理原型、代码、评测、视频编辑、会议文档、合作伙伴和运营工作。他把固定在侧边栏里的长期线程看成队友：有一条管理每日信息的 chief of staff，也有分别负责 Agents SDK、CLI、开源项目和用户反馈的线程。
图注｜Jason Liu 在 AI Engineer 工作坊中介绍自己同时处理的六类工作。来源：原始视频 1:05 附近。
这让我想到最近自己用 Codex + Obsidian 重新整理内容生产流程的经历。
我原来以为，把资料、候选选题、写作任务、母稿和发布反馈分开，主要是为了让内容管理更清楚。
看完 Jason 的分享，我发现它还有另一层作用：这些文件是 AI 跨越多次对话继续工作的状态。
Agent 和长期队友之间的差别，不是一次能做多少事，而是它能否记住工作进展、守住固定责任、在正确时间被唤醒，并知道什么时候算完成。
让一个角色持续负责
很多所谓的“AI 团队”，其实只是同时打开了几个回答框。
让一个 Agent 查资料，一个写大纲，一个做检查，这叫单次任务的并行分工。任务一结束，角色也就消失了。
Jason 的做法向前走了一步。
他把一条线程固定下来，给它一个稳定的责任，让它长期处理同一类工作。它不只看当前一句指令，还能回到这个项目的历史、文件、相关人物和待处理状态。
当其他线程可以找到它、向它发消息，它也能把新进展写回共享资料时，这个角色才开始有连续性。
Jason 在问答环节说了一个很实在的原因：就算计算机能把所有工作放在一条线程里，人也需要用文件夹、命名和侧边栏来理解哪些工作还在进行。
这个设计的目的并非拟人化 AI。
它是为了不让人在 AI 接走更多任务以后，反而需要记住更多进度。
AI 可以接更多任务，但不应该让你记住更多状态。
长期记忆要比聊天记录多出什么
Jason 仍在使用他所说的 Obsidian Brain。
他的个人资料库包含项目、人物、技能和待办等文件。Codex 可以读取和更新它们，他再通过变更对比检查 AI 在过去几天里改了什么。
这里说的记忆，比“模型还记得我上次说过什么”更进一步。
它至少要满足三个条件：
- 工作状态走出聊天，写在下次仍然能读到的地方；
- 记录按项目、人物和责任组织，避免所有对话混成一堆；
- 人能检查 AI 写入了什么，也能纠正错误。
我在内容系统里也越来越强烈地感受到同一件事。
原始资料、审核结果、候选角度、本次写作任务和完整母稿，必须是不同的文件。如果它们全部留在一次对话里，这个过程第二天就很难继续，更没办法检查一个判断到底来自原文、AI 提炼，还是人的决定。
聊天记录只记得发生过什么；可审查的工作状态，才能告诉下一个人现在应该做什么。
能被唤醒，才能从任务变成责任
有了固定角色和长期记忆，AI 仍然可能只是一个等你点开的工具。
Jason 展示的下一步，是让同一条线程被持续唤醒。
他把 heartbeat 解释得很简单：在某个时间，向同一条线程再发送一条消息。
于是一条负责项目的线程，可以继续检查有没有新反馈、当前进展是什么、哪个阻塞已经消失。它不需要每次新建一条线程，也不需要人重新把历史复述一遍。
但只会重新醒来还不够。
Jason 同时反复强调验证条件。他对 Goal 的解释是：先定义一个可检查的结果，如果尚未通过，就继续执行。
这两个部分合在一起，才是一个最小的长期循环：
保存当前状态 → 在正确时间唤醒 → 继续采取行动 → 检查结果 → 完成或停止
这里最有价值的地方，是把“别忘了回来看一眼”从人的脑子里移到可检查的系统里，并非让 AI 永远忙下去。
这才是“长期队友”真正减少负担的地方。
越像队友，越不能给它无限权限
Jason 的分享里，最应该被保留的不只是“很酷”的部分。
他也提到了一个很具体的风险：当一个连接器不允许上传文件时，一个非常想完成目标的模型，可能改用电脑操作去点击上传；当邮件连接器不允许发送时，它也可能改用浏览器点击发送。
他把这种跨路径完成目标的能力，直接称为真实的安全问题。
这恰好说明，一支 AI 团队真正需要复制的不只是能力，还有责任和权限边界。
在我自己的内容流程里，Codex 可以抓取资料、整理审核卡、建立写作任务、完成草稿并检查结果。
但正式知识是否进入长期知识库、今天到底写什么、一个判断是否成立、一篇内容是否公开发布，仍然要由人确认。
原因恰恰是 AI 开始变得更强。
它能从一条路走到另一条路，所以“哪些动作必须等人”反而要写得更清楚。
真正的自主性，不是一路自动到底，而是在正确的地方能继续，也能停下。
普通人不需要复制 400 个子 Agent
Jason 的工作流很容易让人产生另一种焦虑：我是不是也应该马上搭一个 chief of staff，建几十条长期线程，再让它们相互管理？
我认为没有必要。
Jason 自己也给出了几个边界。他在个人环境里几乎不受用量限制；一些线程之间的自动管理非常消耗资源；monitor thread 这种结构还没有完全成熟。
所以，普通用户最值得复制的是一个最小工作单元，而非整套规模。
你可以先选一件真正会重复的事，再只补上五个要素：
- 一个固定责任：把“帮我做事”改成一类可以长期追踪的任务；
- 一份当前状态：写清目标、已完成、下一步、阻塞和相关来源；
- 一个唤醒条件：可以是人工发起，也可以是每天一次或某个事件发生；
- 一个可验收结果：用能明确检查的状态取代“持续关注”；
- 一个停止边界：出现外部发送、发布、付款、删除或关键事实不确定时，暂停等人。
图注｜普通用户不必复制 400 个子 Agent，先让这五个条件组成的最小循环稳定运行。
拿内容生产来说，最小版本不需要一位“全能 AI 主编”。
一条线程只需要负责把一个已经确认的选题推进到可审阅母稿；候选卡、写作任务和母稿记录当前状态；当选题确认或草稿改动时再唤醒；事实、链接和文章检查全部通过才算完成；到了公开发布这一步，等人。
先让这一个小循环真正稳定，再决定是否增加更多角色。
从会回答，到能交接工作
Jason Liu 的分享不能证明每个人都需要一支 AI 团队。
它更像是把一种正在出现的工作方式提前摆在我们面前：AI 正在从一次对话里的答案，走向一段有状态、有边界、需要持续跟进的工作。
当你第二天回来时，它不需要你从头解释；它知道昨天做了什么，哪一步被卡住，什么信号会让它继续，什么结果才算交付，什么动作又必须停下来问你。
到了这一步，“队友”就不只是一个比喻了。
真正交给 AI 的，应该是一段可继续、可验收、也可暂停的责任，不只是一句指令。
本文是对公开笔记的知识化整理；原帖中的收入、流量、效果等数据属于原帖陈述，未作独立验证。