今天想单拎出来聊一个项目。

不是因为它又刷了一波数据，也不是因为它很会做传播，而是因为我认真把它的 V2EX 原帖、GitHub 仓库和 live 网站看完之后，发现它真正有意思的地方，和大多数人第一眼看到的，其实不是一回事。

这个项目叫 yoyo。

项目地址我放在文末，建议先把文章看完，再回头去看仓库和 live 页面。

表面看，它像一个很容易出圈的 AI 项目：会自己写代码、自己提交、自己进化，叙事也很抓人。

但如果只把它理解成“一个会自动写代码的 Agent”，那其实是把它看浅了。

我现在更愿意把它定义成：

一个被公开饲养、公开观察、公开讨论的自我演化 Agent 实验。

它不是单纯在做“AI 写代码”，而是在尝试回答一个更大的问题：

一个 Agent，如果真的要长期运行，它该怎么活下去？

先把最表层的信息说清楚：yoyo 到底是什么

按 V2EX 发帖人自己的介绍，yoyo 是一个“正在实时自我进化的开源 Coding Agent”。

它不是你手动触发一下、帮你补几行代码的助手，而是会隔一段时间自动醒来，读自己的全部代码，决定下一步要进化什么，然后自己写代码、重构、跑测试、提交 commit，最后继续睡觉。

截至我更新这篇文章的 2026 年 4 月 14 日晚，三个官方来源上看到的数字仍然略有差异，但方向一致，而且这种差异本身恰恰说明它是持续运行中的：

• V2EX 原帖写的是 Day 42，代码 45,373 行，1,231 次 commit，1,830 个测试
• yoyo.yolog.dev 的 live 页已经显示到 Day 45，45,973 行代码，1,846 个测试，1,295 次提交，累计花费 $430.07；网站还能直接看到它此刻正处在哪个“房间”，比如 sleep room，同时 live 页显示 GitHub stars 为 1,584
• GitHub 仓库首页当前显示主分支已经来到 1,295 次 commit，99 个 fork，最近一次提交距离我查看时约 4 小时

也就是说，这不是一个“做完了放上来的展示项目”。

它是真的还在长。

这也是为什么它会让很多人第一眼就上头。因为你不是在看一个静态仓库，而是在看一个被包装成公开舞台的持续实验。

但如果你把 yoyo 只理解成“自动写代码”，你会错过它最厉害的那部分

我觉得 yoyo 最值得看的，不是单点能力，而是它把很多平时被拆开的东西，硬接成了一个完整系统。

至少有三层。

第一层，它当然是个 Coding Agent

GitHub README 里写得很直接，yoyo 本身也是一个终端里的 coding agent。

它有自己的 CLI、slash commands、配置文件、权限设置、项目上下文机制，支持测试、lint、review、git、PR、docs 查询、子代理等一整套工作流。仓库里还能看到比较完整的 Rust 工程结构、tests、docs、scripts、skills、memory 等目录。

所以如果你只把它理解成“一个会自己改自己仓库的 demo”，其实不准确。

它本身也是个认真在做产品形态的 agent。

换句话说，yoyo 不是在空地上自己写自己，它写的是一个也在对外提供能力的 Agent 系统。

第二层，它不只是 Agent，它还有一整套“自我演化的壳”

这一层才是关键。

看 README 和仓库结构，你会发现作者真正下功夫的，不只是模型调用，而是下面这些东西：

• 进化脚本
• 项目记忆系统
• active learnings 的合成机制
• journals 日志
• social 互动逻辑
• tests 和 mutation testing
• 回滚、提交、上下文装配、权限和工具护栏

V2EX 原帖作者在回复里也提到，他们在 yoyo 身上同时实验了性格培养、长中短期记忆处理和社交逻辑。

这句话把项目的真正难点说出来了。

因为它说明这项目的目标，已经不是“让模型多写点代码”这么简单，而是在尝试回答一个更难的问题：

如果一个 Agent 真的要长期运行，它怎么形成连续性？

怎么记住昨天踩过的坑，怎么把经验沉淀下来，怎么和人互动，怎么被人纠正，怎么让“生成”变成“持续演化”。

这其实已经不是 prompt 工程了，而是 agent harness 工程。

第三层，它把整个过程做成了一场“被观看的成长”

这就是 yoyo 最像“楚门秀”的地方。

yoyo.yolog.dev 不是普通官网，更像一个给 Agent 直播成长过程的舞台。

你在上面能看到：

• 它活了多少天
• 现在在哪个 room
• 是醒着还是睡着
• 花了多少钱
• 写了多少代码
• 多少测试通过
• 最新 journal 在写什么
• 甚至还能进 backstage 看它更完整的运行面板

GitHub 仓库里也专门有 journals、memory、sponsors、social 这一整套内容，连 README 里的介绍都不是传统开源项目那种“功能列表式写法”，而是在主动强化“它正在长大”这个叙事。

这一点，我觉得非常聪明。

因为一旦做成公开叙事，这个项目获得的就不只是 star 和围观，而是：

• 反馈
• 讨论
• issue
• 社区参与
• 赞助
• 持续关注

也就是说，yoyo 不只是一个 agent，它还是一个“会吸收外部世界”的社会化对象。

所以这项目最有价值的，不是证明 AI 已经会独立做软件，而是把问题往前推了一步

这里必须降一点温。

我不觉得 yoyo 现在已经证明了“AI 可以放心独立完成软件工程”。

这是两回事。

代码多、提交多、测试多，不自动等于工程质量高。这里面仍然有很多关键问题，没有因为数字漂亮就被解决：

• 它的功能质量到底怎样
• 测试覆盖的是不是关键路径
• 它的“自我决定方向”到底多大程度上是真自主
• 长期演化会不会漂
• 它会不会把系统越长越重

这些问题，现在都还应该保持谨慎。

但反过来说，你也很难再把它简单归类成“噱头项目”。

因为它至少已经做成了一件事：

把“持续运行的 Coding Agent”从一个概念，做成了一个你可以观察、可以 fork、可以讨论、可以挑战的公开样本。

这很重要。

很多真正的行业变化，一开始都不是以完美产品的形态出现的。

它们最早往往是某个实验先把路踩出来，然后大家才慢慢意识到：原来问题已经从 A 变成 B 了。

我觉得 yoyo 就属于这种项目。

我真正被它提醒到的一点是：AI 编程的竞争，正在从模型层往“壳”上移

过去一年，大家聊 AI 编程，讨论焦点大多还是模型：

• 谁首轮生成更强
• 谁写代码更像人
• 哪个模型 bug 少一点
• 哪个上下文长一点

这些当然都重要。

但看完 yoyo 之后，我更强烈地感觉到，接下来真正拉开差距的，可能不只是模型本身，而是那层把模型组织起来的“壳”。

比如：

• 你怎么调度它
• 你怎么给它记忆
• 你怎么做长期上下文
• 你怎么测试和验收
• 你怎么让它提交
• 你怎么让它失败后撤回来
• 你怎么让它和人互动，而不是关门自嗨

说得直接一点：

单次调用模型的时代，拼的是“会不会问”。
长期运行 Agent 的时代，拼的是“会不会养”。

这也是为什么 yoyo 的作者在 V2EX 里强调“目的地不重要，过程比较有价值”。

我很认同这句话。

因为这个项目现在最有价值的，未必是它距离“超越 Claude Code”还有多远，而是它把很多人嘴上在讲的 harness 实践，真的摊开到阳光下跑了。

还有一个细节很值得注意：这个项目不是想做封闭神话，而是在设计“可被介入的进化”

V2EX 讨论里有一句我印象很深。

作者说，所有人都可以介入它的进化，可以通过 Issues 或 Discussions 和它互动，它甚至还能给人类提 issue 求助。

这句话看起来像彩蛋，但其实是整个项目成立的关键一环。

因为一个长期运行的 Agent，如果完全封闭在自己的循环里，很容易变成自说自话。

而一旦它被放进 GitHub 的 issues、discussions、sponsors、journal、social 这种开放结构里，它就不只是“在跑任务”，而是在接受外部反馈。

这意味着什么？

意味着 yoyo 不是在被设计成一个“完美替代人”的系统。

它更像是在被设计成一个能跟人类共同演化的对象。

这就比“自动写代码”高级多了。

当然，它也把另一个问题提前摆上桌面了：以后真正稀缺的，也许不是写代码，而是管住 Agent

如果这种方向继续往前走，我觉得开发者最该调整的，不是情绪，而是坐标系。

以后更稀缺的，可能不是“能不能亲手把代码敲出来”，而是下面这些能力：

• 定目标
• 设边界
• 设计护栏
• 做验收
• 管长期上下文
• 决定什么该放权，什么必须人来拍板

也就是说，软件工程的重心，可能会从“代码生成”慢慢挪到“代码治理”。

这个变化其实挺大的。

因为它对应的不是“程序员消失”，而是程序员角色重心变化。

你以后也许还是写代码，但更值钱的部分，可能越来越像：

• Agent 的产品经理
• Agent 的审稿人
• Agent 的监管者

这也是我看 yoyo 最后真正记住的一件事。

它让我觉得，AI 编程下一阶段真正难的，未必是让模型再聪明一点。

而是让一个能长期跑的 Agent，既有野性，又不失控；既能成长，又能回头；既能被观看，也能被纠正。

这比“再多写点代码”难多了。

那我们普通人看完这个项目，究竟能得到什么？

我觉得至少能拿走三件事。

第一，别再把 Agent 只理解成“高级聊天框”

很多人现在口头上已经接受了 Agent 这个词，但实际使用方式还是：

• 问一个问题
• 收一段回答
• 复制一份结果

这当然也有用，但 yoyo 提醒我们，Agent 真正的价值，可能不是“回答得更像人”，而是：

它能不能围绕一个目标，持续行动。

所以以后你看一个 Agent 产品，不能只看 demo 漂不漂亮，还要看：

• 它能不能连续工作
• 它有没有记忆
• 它会不会从失败里恢复
• 它能不能和 git、测试、issue、上下文一起工作

这套判断，比“它第一次写得多惊艳”更重要。

第二，普通开发者最该补的，不只是 prompt，而是工程护栏意识

很多人看完 yoyo，最容易产生的冲动是：“我也想搞一个会自己进化的 AI。”

但更现实的收获，其实不是去复制它，而是理解它背后的工程常识：

• 自动做事的系统一定要有边界
• 长期运行一定要有记忆机制
• 改代码一定要配测试和回滚
• 能写日志、能被观察、能被纠正，和模型本身一样重要

所以 yoyo 最值得学的，不是“自动提交代码”这个表象，而是：

一个会长期跑的 Agent，背后到底需要哪些护栏。

第三，普通读者也不只是围观者，还可以成为它进化的一部分

这个项目有意思的地方在于，它不是完全封闭的。

你不一定要会写 Rust，也不一定今天就 fork 它，仍然可以参与：

• 去 live 页看它最近在干什么
• 去看 journal，理解它怎么总结自己
• 去 GitHub Discussions 跟它互动
• 去 Issues 提建议、提 bug、提挑战
• 用点赞、反馈、讨论影响它的优先级

README 里有一句话我很喜欢，大意是：社区其实是它的“免疫系统”。

这就意味着，普通人不是只能看热闹，普通人也可以成为这个 Agent 演化过程里的一部分。

那普通人能不能真的用 yoyo？

答案是：能，但要看你说的“使用”是哪一种。

第一种用法：把它当成一个公开实验来看

这是门槛最低的。

如果你只是想理解“自我演化 Agent”到底长什么样，现在就已经可以用：

• 看 live 页：https://yoyo.yolog.dev/
• 看 GitHub 仓库里的 journals、memory、skills
• 看它最近的 commits 和 discussions
• 看它如何把运行状态、日志、花费、测试公开出来

这种“使用”不需要安装任何东西，但很适合建立对下一代 Agent 的直觉。

第二种用法：把它当成终端里的 Coding Agent 来用

这就是实用层了。

从 GitHub README 看，yoyo 本身已经可以当作一个终端里的 coding agent 使用。它支持 REPL、单次 prompt、provider 切换、skills、会话恢复，以及 git、test、lint、review 等命令。

如果你是开发者，其实完全可以先不碰“自我进化”那一套，先把它当普通 coding agent 用起来。

这个路径反而更合理，也更稳。

第三种用法：fork 一份，自己养一个

这是最重度的玩法。

README 里写得也很清楚：你可以 fork 它，修改 IDENTITY.md 和 PERSONALITY.md，配置 GitHub App 和相关 secrets，再开启 evolution workflow，跑你自己的版本。

但我不建议普通人一上来就走这条。

因为这已经不是“装个软件试试”，而是在维护一个长期运行系统。

它要求你至少对下面这些事情有基本概念：

• GitHub Actions
• API key 与 provider 配置
• issue / discussion 工作流
• 仓库权限和自动提交边界
• 测试、回滚、日志和运行成本

所以更合理的顺序应该是：

先围观，再当工具用，最后才考虑 fork 一个自己的。

如果真想上手，最稳的姿势是什么？

我会建议分三步。

第一步：先把它当工具，不要先把它当“生命体”

yoyo 的叙事很强，很容易让人一上来就被“自我进化”“楚门秀”这些表达吸走。

但如果你真想判断它能不能进入你的工作流，第一步应该非常务实：

先把它当作一个 coding agent 用。

GitHub README 给了安装方式：

• macOS / Linux：运行官方 install.sh
• Windows PowerShell：运行官方 install.ps1
• 或者直接通过 cargo install yoyo-agent

装完之后，先跑最基础的模式，比如交互 REPL 或单次 prompt，看看它在你本地项目里读代码、改代码、跑命令的手感。

第二步：先在低风险项目里试，不要先拿主仓库冒险

会改代码、会自动提交、会长期运行，听起来很强，但也意味着一旦你没设边界，风险会比普通聊天工具大很多。

所以正确姿势一定是：

• 先在测试仓库用
• 先开最小权限
• 先看它怎么读项目、怎么改代码、怎么跑测试
• 先确认它的输出风格和错误恢复方式

别一上来就拿正式生产仓库给它自由发挥。

第三步：你真正要学的，是它的“壳”，不是它的人设

很多人看 yoyo，最容易学到的是表面形式，比如：

• 会睡觉
• 会写日记
• 有 personality
• 会发社交内容

这些当然有传播力，也构成了它出圈的一部分。

但如果你真想把它的方法论用到自己身上，你更该学的是这些：

• memory 怎么组织
• active context 怎么合成
• tests 怎么兜底
• issues / discussions 怎么进入闭环
• 自动提交前后怎么做护栏
• 人类反馈怎么参与优先级

这些才是以后你做自己的 agent workflow 时，真正能复用的部分。

最后一句判断

如果你今天只把 yoyo 看成“一个 AI 连续 45 天自己改代码的酷项目”，你会错过它。

它真正新鲜的地方，不只是自动写代码，而是它已经开始把这些东西缝在一起：

• 编码
• 记忆
• 测试
• 日志
• 社交
• 赞助
• 公开叙事

所以，yoyo 最值得看的，不是它今天又写了多少行代码，而是它已经让我们提前看到：

AI 编程的下一阶段，可能不是“更会写”，而是“更会活”。

参考链接

• V2EX 原帖：https://www.v2ex.com/t/1205540#reply10
• GitHub 仓库：https://github.com/yologdev/yoyo-evolve
• 官网 live 页：https://yoyo.yolog.dev/

---

好了，今天的分享就到这里。如果你还有疑问，欢迎在评论区留言。

关注 AI杨侦探，带你用更简单的方式，搞懂更复杂的技术。