我开发自己的 Personal Agent 已经有一段时间了。

最近一直在啃其中最难的一块:怎么让它自动完成开发。

理想中的流程看起来很简单。我在手机上提一个需求,Personal Agent 把需求交给 Coding Agent,Coding Agent 写完代码、跑完测试、做完 review,最后给我一个可以合并的 PR。

真做起来,完全不是这回事。

任务做到一半,Coding Agent 的额度用完了怎么办?换模型以后,新模型怎么知道前面发生了什么?代码写完了,它说测试通过,应该相信吗?第一次 review 找到 5 个 blocker,修完以后由谁复查?如果第二次 review 又发现 3 个新问题,什么时候应该继续,什么时候必须停下来找人?Mac mini 执行到一半掉线,ECS 怎么知道它到底有没有产生 commit?如果取消发生在外部写入之后,系统又该从哪里恢复?

我越做越觉得,这哪是在接一个 Coding Agent,根本是在造一条小型软件生产线。

状态机、任务租约、heartbeat、checkpoint、artifact hash、独立 review、失败恢复、一次性权限……每解决一个问题,后面又长出两个问题。啃到最近,我已经有点怀疑人生:为了晚上少坐一会儿电脑,真的有必要把事情搞得这么复杂吗?

我最初的动机其实很朴素。

我每天晚上会在 Codex 和 Claude Code 之间来回切换。把需求告诉一个,让它写;把 diff 交给另一个,让它 review;再把 review 意见复制回去修;修完以后重新开一个上下文复查。模型额度不够了,再换另一个模型继续。

很多时候,我感觉自己不是在开发,而是在给几个很聪明的同事当传话员。

所以我想做一个 Graph,把这些传话工作自动串起来。它原本只是一个“把我从电脑前解放出来”的工程。

直到今天,我突然意识到,它可能不只是这个。

为什么模型公司都要做自己的 Coding Agent

今天我把一个问题抛给 ChatGPT:

Codex 和 Claude Code 已经这么强,coding harness 和底层模型在技术上又可以被拆开,市场上也有越来越多支持多模型的执行框架,为什么模型公司还要各自卷自己的 Coding Agent?大家只卖模型不行吗?

我把 ChatGPT 的回答单独放在下面,方便区分它和我的正文。

ChatGPT 的回答

短期很好理解。Coding Agent 是一个非常凶猛的 token 消耗器:读仓库、搜索文件、修改代码、运行命令、看到报错以后继续修,再跑测试、再 review,一次完整任务的消耗远高于普通对话。

它同时还是模型很好的反馈场。用户提出了什么目标,Agent 做了哪些操作,代码是否编译,测试有没有通过,修改最终有没有被接受——这些结果比“用户觉得回答还不错”清晰得多。谁掌握 Coding Agent,谁就更接近大量真实、可验证的工作轨迹。

更直接的是用户入口。大部分人不会天天做精细路由:装了 Claude Code,大概率默认用 Claude;装了 Codex,大概率默认用 GPT。入口影响默认选择,默认选择再影响用量。

长期来看,模型公司争夺的可能不只是“谁更会写代码”,而是谁能占住模型上面的工作环境:文件、terminal、工具、权限、任务历史、后台执行和用户习惯。

如果这一层被第三方掌握,GPT、Claude、Gemini 或 DeepSeek 都可能变成可替换的底层服务。上层产品可以比较效果、自动路由、控制成本,也可以在不同模型之间切换。反过来,如果模型公司掌握 Coding Agent,它卖的就不再只是一次模型调用,而是用户完成工作的入口,也更能守住自己的产品关系和定价权。

Coding 又恰好是通用 Agent 很好的起点:环境结构化,动作可以记录,结果能通过编译、测试和 Git 验证。今天它负责写代码,明天就可以继续连接 Jira、Slack、浏览器、云服务和部署系统,从“完成一段代码”走向“完成一项工作”。

所以,Coding Agent 争夺的是入口、数据和定价权,也是成为下一代工作环境的机会。

这个回答听起来很合理。为了把其中的推演和公开事实分开,我又核对了一眼公开产品:OpenAI 把 Codex app 描述为管理多 Agent、覆盖设计到维护全生命周期的工作台,并明确把能力延伸到代码之外;Anthropic 则把 Claude Agent SDK 定义为与 Claude Code 同源、可用于非 coding 场景的 Agent 基础设施。它们并不能证明厂商的真实商业动机,但说明 Coding Agent 确实正在从“代码生成器”变成更广泛的工作入口。

但它马上让我产生了另一个疑问。

为什么我好像完全不在乎自己用哪个 Agent

按照上面的逻辑,我应该越来越依赖某一个 Coding Agent 才对。

但回看自己的实际使用,我发现我好像完全不在乎。

Codex、Claude Code、DeepSeek Harness、Qoder、CodeBuddy,哪个顺手就用哪个;模型也是哪个效果够用、额度充足、价格合适就用哪个。规划可以交给一个模型,编码交给另一个,review 再换一个完全独立的 Agent。

不同 Coding Agent 给我的体感差异,很多时候只是速度快一点还是慢一点,以及同一份代码拿去 review,它最后报出 3 个 blocker 还是 5 个 blocker。

我并不期待某一个 Agent 一次把事情做对。

我真正依赖的是多轮、不同 Agent 和不同模型之间的互相检查。第一个 Agent 写,第二个 Agent 在全新上下文里 review,原来的 Agent 修,再换一个没有继承前文结论的 Agent 复查。最终代码质量并不来自我“押中”了最强模型,而来自整个流程不允许任何一个模型给自己判卷。

当然,这些 Coding Agent 并不等价。它们在速度、上下文长度、工具能力、resume 机制、安全边界和犯错方式上都不一样。切换也有真实成本:要重新适配命令、权限模型、输出格式和失败语义。

所以“供应商”不是贬义,也不意味着它们已经商品化。它描述的是我希望建立的系统关系:每个 Agent 都可以有明显优势,但任何一个都不应该独占我的记忆、项目状态和继续工作的权利。换掉其中一个,不应该等于换掉整个系统。

为什么我能这么做?

答案可能是:我早就把最有粘性的东西从 Agent 里搬出去了。

我的 Agent 不需要记住我的项目

我跨 Agent 做项目时,基本不依赖它们自己的长期记忆。

我的个人知识库保存长期积累:我在做什么、过去做过哪些判断、哪些经验值得复用、我习惯怎样和 Agent 协作。它会持续更新,也可以被不同 Agent 读取。

具体项目的上下文则放在 repo 里:项目状态、PRD、技术方案、已经冻结的合同、开发拆解、测试、Git history,以及下一步到底是什么。

每次一个 Agent 完成阶段性工作,还会留下完整的交接:当前状态、做过什么、没做什么、发现了哪些问题、证据在哪里、下一步应该从哪开始。下一个 Agent 不需要相信上一段聊天总结,它可以直接读项目里的事实。

这套方式当然比依赖一个超长会话更麻烦。我要维护知识库,要更新项目状态,要区分什么已经验证、什么只是计划,还要确保交接文档不会和代码事实打架。

但它带来的结果非常直接:我可以随时换 Agent。

Claude 里形成的偏好,不需要重新“训练”Codex;Codex 做完的项目,也不需要靠它自己的 session 才能继续。只要知识库和 repo 还在,只要项目状态和交接还在,新的 Agent 就能重新进入现场。

换句话说,我的记忆体系已经和具体 Agent 剥离了。

Agent 不再拥有我的项目记忆。它只是来读取我的记忆、完成一段工作,再把结果写回我的系统。

意识到这一点以后,我突然发现,自己正在做的 Personal Agent 可能和常见的产品思路不太一样。

我需要的 Personal Agent,本来就不是一个 Coding Agent

我最初决定把业余时间投入 Personal Agent,并不是因为我想再造一个更强的 Claude Code 或 Codex。

我需要的是一个只服务于我的助理。

我在路上花了一笔钱,可以随时对它说一句“午饭 45”,它帮我写进自己的账本;月底我问最近钱花到哪里去了,它能读取真实记录,给我一份可以核对的回答。

我想知道最近健康状态怎么样,它能读取我自己的运动、睡眠、体重等数据,按照我关心的方式做周期复盘。

国庆准备去瑞士,我可以问它应该带哪些衣服。它不仅知道天气,还知道我的行程、衣橱里有哪些衣服、哪些搭配我真的愿意穿,最后给出适合我的建议。

这些需求看起来都可以被叫作“工具”,但它们其实高度非标。

别人的账本结构和我不一样,健康目标和我不一样,旅行习惯和我不一样,衣橱更不可能一样。即使两个人都需要“查机票”,有人只想看到降价提醒,有人要同时检查家庭日历、孩子上学时间和积分兑换,有人还要符合公司的差旅政策。

这些能力中的很多,其实就是我过去通过 vibe coding 做出来的一个个小项目。Personal Agent 要做的,不是重新发明它们,而是把这些项目接进同一个入口,让它们共享我的身份、记忆、权限和长期状态。

它自己不需要会 coding,也不需要亲自写文档。

需要开发新工具时,它可以调用 Coding Agent;需要查网页时,它可以调用 Browser Agent;需要做长时间研究时,它可以调用 Research Agent。真正服务我的,是最上面的 Personal Agent;下面的模型和 Agent,都是它为了完成工作而采购的能力。

这和我今天使用 AI 产品的关系刚好反过来了。

现在通常是我进入 Codex、Claude 或 ChatGPT 的产品,再把自己的上下文交给它们。未来我更希望先进入自己的 Personal Agent,再由它决定这次应该找谁完成任务。

我
↓
我的 Personal Agent
├── 我的记忆
├── 我的项目状态
├── 我的权限规则
├── 我的工具与工作流
└── Orchestration
    ├── Codex
    ├── Claude Code
    ├── DeepSeek
    ├── Browser Agent
    └── Research Agent

模型公司想成为我的操作系统——至少,它们的产品正在向这个方向扩张。

而我可能正在做自己的操作系统,然后把它们变成里面可以替换的服务提供方。

更重要的不是“它会什么”,而是“它能不能长出新能力”

顺着这个想法继续往下走,我也终于理解了自己为什么要啃那条复杂到让人怀疑人生的自动开发 Graph。

它不只是替我传话。

如果 Personal Agent 永远只能调用我提前写好的几个工具,那么每次出现新需求,我仍然要回到电脑前,自己想方案、叫 Coding Agent 开发、找另一个 Agent review,再手工把新工具接回去。

但如果这条开发链路可以被 Personal Agent 自己调用,事情就变了。

它发现现有能力不够,可以先把需求整理成一份开发合同——也就是写清目标、修改边界和验收标准的结构化任务说明;Coding Agent 根据合同修改代码;另一个 Agent 在独立上下文里 review;确定性测试判断结果到底有没有通过;高风险变化回来找我确认;最后,新工具或新工作流被注册进 Personal Agent,成为它以后可以继续使用的能力。

今天我对它说:“以后每次开始一个新项目,都先生成 contract,再进入开发。”

未来这不应该只是记在 prompt 里的一句话,而应该真的变成工作流的一部分:有新的节点、状态、触发条件、测试和版本记录。

这才是我理解的自动成长。

不是模型在聊天里显得越来越懂我,而是它可以基于过去积累的状态,真正改变自己下一次能做什么。

但“长出新能力”绝不能等于“允许 Agent 随意修改自己”。开发合同、权限边界、独立 review、确定性测试、人类确认、版本记录和回滚能力,不是附加流程,而是这件事能够成立的前提。自动成长的对象应该是一个可审计、可撤销的能力版本,而不是一段无人知道何时变化的 prompt。

当然,我离这个目标还很远。

目前,我的 Personal Agent 已经完成了第一条真实的 Finance 链路;自动开发部分也已经有了外部状态机、远程 Worker、任务租约、checkpoint、确定性测试、独立 review 和候选 commit 等基础设施。但完整的能力注册、工作流自动修改和通用 self-extension 还没有做完。

这篇文章不是一个“我已经实现了个人操作系统”的发布公告。

它只是我在啃了很久工程问题以后,突然看到的一条可能的方向:我以为自己在做一条节省传话时间的自动开发流水线,后来才发现,它也许正是 Personal Agent 未来持续长出新能力的那条生产线。

未来的 Personal Agent,会是 App 还是工具包?

我不认为所有人都会自己搭 Personal Agent。

很多人并不知道自己具体需要什么,也不想维护知识库、状态机、权限和一堆个人工具。市场当然会提供开箱即用的第三方 Agent,就像今天提供各种 App 一样。对大多数人来说,直接使用成熟产品可能永远是更合理的选择。

但接下来有一个很有意思的问题。

这些 Agent 最终会不会仍然只是封装好的 App:厂商决定它能做什么,用户只能在设置页里选择?

还是会逐渐变成一种可以被个人修改的工具包:用户拥有自己的记忆,能够定义自己的工具和规则,也可以让系统根据需求继续开发新的能力?

前一种路线更容易规模化,后一种路线更接近真正的“Personal”。两者可能会长期同时存在。

如果后一种路线成立,那么真正可复用的就不是某一个最终 Agent,而是搭建 Agent 的基础设施:怎样保存状态,怎样组合工作流,怎样给不同执行器分配权限,怎样验证结果,以及怎样把一次开发变成可以长期使用的新能力。

每个人最后长出来的 Agent 都不会完全相同,但让它们生长的方法可以共享。

这也是我未来想逐步开源的部分。

我不知道它最终会不会成为所谓“个人 OS”的雏形。现在说这个显然还太早,它甚至还有很多具体又麻烦的工程问题没有解决。

但回头看,很多重要的东西一开始也只是某个人为了少做一点重复工作,给自己搭的一套系统。

谁知道呢。

至少,这个念头让我重新找回了啃 Graph 的动力。对我来说,保持对 AI 的热忱和信心,不是相信每一个宏大叙事,而是在解决一个个具体问题时,仍然能看见值得继续走下去的方向。更直接地说,AI 让我有能力把脑子里那些原本只能想想的东西一个个落地,真的太酷了。