ARTICLE · 1302752
一个普通人的 AI Native 实践手记 · 第 02 篇
一个普通人的 AI Native 实践手记 · 第 02 篇上一篇，我写到自己想搭建一套 Personal AI Native，让不同的 AI 工具真正配合起来。 文章最后，我说接下来要做的，不是再画更多架构图，而是看看这套想法能不能真正跑起来。 于是，我开始动手。 没想到，最先遇到的问题不是技术，而是我发现自己又多了一份工作。 给 AI 当项目经理，而且是催促agent干活的那个“监工”类型项目经理。 最开始，我想让 Codex 把之前的设计落实成可以验证的实验。 它很认真。 先研究工具，再检查环境，接着核对权限、启动方式和停止机制。 每一步都有解释，也有需要我确认的事情。 我理解谨慎的重要性。 毕竟，一个能够修改文件、执行命令的 AI，不能想做什么就做什么。 但问题很快出现了。 我几乎一直在重复两个词： “继续。” “批准。” 它做完一步，等我确认。 我确认之后，它再研究下一步，然后继续等我。 我甚至对它说： “别在文档层面打转。” 后来又忍不住说： “你不能让我这样一直说一句动一句。” 这让我意识到一个有点荒诞的问题。 在上一篇文章里，我说自己不想再当 AI 工具之间的“人工快递员”。 结果好不容易开始让 AI 执行任务，我又成了它的项目经理。 我要分配任务、催进度、批准操作，还得检查它到底有没有完成。 AI 确实替我干了一部分活，但管理 AI 本身，又成了一份新的工作。 我当然希望保留决定权。 但我也希望，一个能够理解代码、检查环境的执行者，能在明确的范围内自行解决常规问题，而不是把每个技术细节都变成需要我回答的选择题。 后来，我们改变了合作方式。 不再每走一步都单独询问，而是提前约定好一批工作的范围。 用什么资料，能做哪些操作，最多运行多少次，出现什么情况必须停止。 范围以内，AI 可以继续推进。 超出范围，再交给我决定。 随后，我们完成了54次模拟实验。 18种测试情况，每种运行3次。 其中有6次，专门测试负责监督任务的程序出现故障时，系统还能不能停止。 其他实验则检查 AI 是否能够越过文件访问限制、修改不该修改的内容，以及正常工作是否会受到影响。 测试使用的是虚构资料和隔离环境。 这一批实验最后都留下了整台测试虚拟机停止的证据，声明范围内的结果也通过了独立技术复核。 这是一个实实在在的进展。 但它并不意味着我的 AI Native 系统已经建好了。 更复杂的安全验证还没有全部完成，真实业务试点也没有启动。 54次测试证明的是特定环境中的一些机制有效，不能证明整套系统已经可靠。 不过，这次实验让我更明确了一件事： 好的授权，不应该让人不停地说“批准”，而应该让 AI 知道自己能走多远，以及什么时候必须停下来。 但新的问题也来了。 如果 AI 只有在我主动交代任务后才开始工作，就算它能一口气执行几十步，我依然是所有工作的起点。 有没有可能，再往前走一步？ 11月1日，DeepSeek Harness 团队发布了一篇关于Super-agent 的研究文章。 我读完之后，觉得很有意思。 他们探索的，已经不只是让 AI 完成单个任务。 而是如何让一个 Agent 能够持续运行、主动发现有价值的事情、处理多个并行任务，并在异常发生后恢复工作。 其中一个设计让我印象很深。 它把负责协调的 Router 和真正干活的 Worker 分开。 可以把 Router 理解为一个负责安排工作的协调者。 它不需要亲自修改每一份文件，而是判断任务应该交给谁、是否需要人的决定。 Worker 则在各自隔离的环境里执行具体工作。 还有独立的 Watchdog，负责观察任务有没有卡住、跑偏或者出现异常。 听起来有些技术化。 但翻译成人话，就是： 不需要我亲自盯着每个 AI 窗口，也不应该让一个 AI 同时拥有所有权力。 更值得注意的是，他们并没有简单地主张让 AI 完全自由行动。 在公开设计中，AI 可以先观察事件，记录自己原本会如何处理，等规则经过验证之后，再逐步开放自动执行。 而且，收到新的消息，不代表自动获得了新的权限。 这与我们之前设计的权限边界、任务隔离和独立验收，有不少相似之处。 当然，DeepSeek 公开的是架构研究与实验原型，其中一些设计还没有完整实现。 我们自己的系统也远没有达到那种持续运行的状态。 但有意思的是，不同的探索开始指向一些相近的问题。 同一天，我还读到了抖音博主“数字生命卡兹克”的一篇文章。 标题叫《折腾了整整1年，毫无保留地分享一下我这套Agent自动化系统》。 他分享了自己用近一年时间搭建 Agent 自动化系统的经历。 文章里有很多架构图、流程图，还有各种模型、设备和自动化工具。 但真正吸引我的，不是这些技术配置。 而是他试图改变一件事情： 不再让所有任务都必须从人的一句指令开始。 比如，项目出现新的问题，有人提交反馈，代码需要检查。 这些事情发生之后，系统可以自行接收消息，判断应该交给哪个 Agent，再让它去处理。 处理完，还需要检查结果。 只有遇到需要人决定的事情，才把问题交还给人。 作者甚至给最后这一步起了个很有意思的名字： “批奏折”。 
他在飞书里收到 AI 助理发来的决策卡片，确认之后，Agent 继续工作。 我觉得这个设计很有意思。 因为它把人与 AI 的协作方式，从“人不断发号施令”，变成了“系统持续推进，人只在关键节点介入”。 为了理解这种变化，我把它整理成了一张简化的流程图。 
图：从人工逐步推动到事件驱动协作。根据数字生命卡兹克公开分享的 Agent 自动化实践整理，为概念示意，非原作者架构图，也不代表本项目已经实现。 上半部分，是我们现在很熟悉的工作方式。 人提出任务，AI 执行。 执行完，再等人安排下一步。 只要人不继续推动，很多工作就停在那里。 下半部分，则是另一种思路。 让任务自己进入系统。 系统先判断有没有必要处理、是否在授权范围内，再交给合适的 Agent。 能按照规则完成的，就继续往下走。 遇到重要变更、风险或者需要新增权限的事情，才交给人决定。 人不再需要成为所有任务的起点，但仍然保留关键决定权。 当然，这不代表所有工作都适合自动化。 更不意味着给 AI 一套流程，就可以放心让它随意执行。 什么事情可以自动处理，什么时候必须停止，怎样证明结果可信，这些问题依然存在。 而且，作者展示的实践效果，仍然需要结合具体使用场景理解，不能直接当作我们的系统已经达到的水平。 不过，这篇文章让我发现，我们之前的设计可能还少考虑了一件事。 我们很重视 AI 能做什么、不能做什么。 重视权限，也重视验证。 但对于任务究竟从哪里来、什么事情值得打扰人，考虑得还不够。 人的注意力，其实也应该是系统需要保护的资源。 如果我每天仍然需要打开十几个窗口，给每个 AI 分配任务、催促执行、检查结果。 那即使它们每一个都很聪明，我也只是从亲自干活，变成了管理一群 AI 干活。 这和我最开始想要的，似乎还是有些距离。 研究别人的架构时，我自己的实验也在继续。 这里得先解释一个容易让人误会的地方。 虽然 ChatGPT、ChatGPT Work 和 Codex 都是 OpenAI 的产品，但它们并不是一回事。 我最熟悉的 ChatGPT 聊天模式，主要用来讨论问题、研究资料、分析方案。 ChatGPT Work 则更进一步，可以承接任务、使用工具、交付成果。在获得相应权限后，桌面版还能直接处理本地文件。 而 Codex 更偏向软件工程。 它可以进入代码仓库、修改文件、运行命令、执行测试。 简单说，在我的使用习惯里： ChatGPT 更像讨论问题的伙伴，Work 更像能够动手交付的助手，而 Codex 更像专门负责开发的工程师。 当然，这只是为了便于理解所做的简化。ChatGPT 在连接工具后也能执行一些操作，三者的能力并不是完全割裂的。 
图：OpenAI 三种工作模式的主要区别，以及本次 WebCodex 实验所补充的连接能力。实际可用能力取决于使用入口、授权和执行环境。 但实际用起来，我发现了一个问题。 这些工具虽然来自同一家公司，却不意味着它们会自动共享每个项目的文件、工作状态和全部上下文。 我在 ChatGPT 里讨论好的方案，到了 Codex，不一定能直接接着做。 Codex 刚修改过的文件，ChatGPT 也不一定知道最新情况。 不同模式有不同的执行环境和工作记录。 于是，很多时候还是需要我负责协调。 而且，还有一个越来越现实的问题。 我的 Codex Pro 套餐，真的快不够用了。 随着 AI Native 项目不断推进，Codex 既要阅读大量资料、分析架构，又要修改文件、执行测试，还要反复检查结果。 它确实很能干。 但我发现，很多工作其实不一定需要它亲自完成。 比如查阅已有文档、梳理项目背景、讨论设计方案。 这些事情，ChatGPT 本来就能做得很好。 如果只是想知道某个项目目前进展到了哪里，却还得消耗 Codex 的使用额度去重新读取文件、整理信息，多少有些浪费。 我开始琢磨： 既然已经有了 ChatGPT 和 Work，为什么还要让 Codex 承担那么多非编码任务？ 能不能让它们真正分工？ 把讨论、阅读、分析交给 ChatGPT。 把需要独立完成的工作交付给 Work。 把代码修改、工程测试这些任务更多地留给 Codex。 但要这样分工，还有一个现实障碍。 ChatGPT 聊天模式需要有办法直接获取本地项目的真实信息。 虽然桌面版 Work 已经具备授权访问本地文件的能力，但我希望在自己日常使用的 ChatGPT 聊天过程中，也能够通过一条稳定、受控的通道查询项目，而不必每次都切换工作环境。 所以，今天我们又折腾了另一件事。 借助 WebCodex、本地 MCP 和长期运行的执行服务，为 ChatGPT 建立了一条受控访问本地工程项目的通道。 
MCP 可以简单理解为让 AI 连接外部工具的一套标准。 WebCodex 则承担了连接本地执行环境的工作。 这并不是把 ChatGPT 聊天模式变成了 Codex，也不是重新实现了一套 Work。 而是在已有产品能力之外，补充了一种适合我自己项目管理方式的连接路径。 在已经授权的测试项目中，我们完成了实际文件的读取和写入验证。 随后，也把正在开发的另一个项目加入了授权管理范围。 这个项目自己的访问验收还需要继续完成，但至少，基础通道已经有了可核对的运行记录。 更重要的是，我们没有为了方便，就把整台电脑的访问权限交给 AI。 不同项目仍然需要明确授权。 哪些文件可以读取，哪些操作可以执行，都应该有边界。 这也是我们之前一直坚持的原则： AI 可以帮我做事，但不能自己决定权限。 不过，目前这仍然只是基础连接能力的验证。 ChatGPT 能通过工具获取项目信息，不代表它和 Codex 已经能够自动分配任务、共享完整状态或互相验收。 至于这套方式究竟能帮我节省多少 Codex 使用额度，又会不会引入新的维护和协作成本，也还需要实际测量。 但这次实验，让我开始重新思考 AI 工具的使用方式。 以前，我总想着把任务交给能力最强的工具。 现在，我觉得还应该考虑另一个问题： 能不能把合适的工作交给合适的 AI，让有限的模型资源发挥更大的价值？ 如果未来还能让它们共享必要的项目上下文、明确任务边界，并且留下可靠的执行记录。 那么，我或许不仅可以少复制一些资料，少消耗一些使用额度，还能少花一些精力去管理它们。 至于 WebCodex 具体怎么搭建、ChatGPT 与 Codex 如何分工，以及其中有哪些坑，我准备留到后面的实践篇再详细记录。 把今天的几件事情放在一起看，我发现它们之间有一个共同的问题。 DeepSeek 在探索 Agent 如何持续工作。 那位开发者在探索如何让任务自动流转，减少人的日常干预。 而我正在尝试，让不同的 AI 工具能够围绕真实项目协作，同时保留明确的权限和验收机制。 它们的实现路径并不相同。 但我越来越觉得，真正值得关注的，不只是 AI 能不能完成更多任务。 而是： 当 AI 已经能够完成任务之后，我们该如何重新组织整个工作过程？ 谁来发现任务？ 谁决定任务该不该做？ 谁负责执行？ 谁检查结果？ 什么时候需要人出面？ 哪些已经做过的事情，不应该再从头来一遍？ 这些问题，看起来不像是在讨论 AI 模型有多聪明。 却可能决定了一套 AI 系统到底能不能真正融入我们的日常工作。 上一篇文章里，我想解决的是 AI 之间的信息搬运问题。 现在我发现，即使信息可以共享，工作也不一定能自动往前走。 如果所有任务都等着我发起，所有异常都等着我处理，所有步骤都要我逐个确认。 那我依然是整个系统里最忙的那个节点。 我希望未来的 Personal AI Native 能够改变这一点。 把目标和重要决定留给人，把那些有明确规则、可以验证的协调和执行工作，逐渐交给系统。 但这还只是方向。 54次实验并不能证明它已经实现。 打通本地连接，也不等于几个 AI 已经能够独立完成整个工作流程。 接下来，还需要真正的业务试点，看看它究竟能不能减少我的投入，而不是制造更多需要我管理的事情。 今天早上，我让 Codex 把这段实践经历整理成一篇公众号文章。 它写得很认真。 解释了54次测试怎么做，哪些结果通过了验证，哪些结论还不能下。 从技术记录的角度看，没有太大的问题。 只是读着读着，我发现它又开始从头解释： 为什么我想做 Personal AI Native。 资料怎么组织。 权限应该怎么设计。 这些内容，我好像已经写过了。 于是，我问它： “你有没有看过我 Obsidian 里的那篇文章？” 它这才去找，找到了之前已经完成的第01篇。 读完以后，它也发现，新写的内容与上一篇重复了不少。 一个能够研究复杂架构、运行54次实验、检查权限和停止机制的 AI，到了写一篇延续之前内容的文章时，还是需要我提醒它先看看我们已经写过什么。 我又补了一句： “其实你应该写第02篇。”
01｜AI 已经能干活了，为什么还要我一直催？
02｜54 次实验，让我看到了一点希望
03｜原来，DeepSeek 也在研究这个问题
04｜另一位开发者，已经在尝试把人从流程里解放出来
05｜同样是 OpenAI 的产品，为什么我还要把它们连接起来？
