如果把它压缩成一句话，它讲的其实不是“如何炫技”，而是“一个人如何把重复性工作组织成一个会持续运转的数字团队”。

作者把自己的日常工作拆成六类：研究趋势、写 X、写 LinkedIn、准备 newsletter、review GitHub 贡献、处理社区问题。问题不是这些任务不会做，而是它们每天都要做，且会稳定吞掉大量时间。用一个通用 Agent 全包的结果，是每件事都做得一般：上下文越来越乱，角色越来越混，输出越来越平。

所以他没有继续堆 prompt，而是直接拆成六个角色。

Monica 是总协调，负责统筹和分派；Dwight 做研究，定期扫 X、Hacker News、GitHub Trending、Google AI Blog、论文等来源，输出结构化情报；Kelly 基于研究结果写 X；Rachel 用同一份情报写 LinkedIn；Pam 负责 newsletter；Ross 处理工程相关任务。

这个分工本身并不神奇，真正有价值的是：每个 Agent 只有一个明确职责。角色越窄，输出越稳定。作者专门提到一句很对的话：给每个 Agent 一个单一、无聊、明确的职位，再给它一个停止条件，约束会让 Agent 更好。

这也是整篇文章我最认同的地方。

多 Agent 系统最容易犯的错，就是把“多”误解成“更强”，结果只是复制出一堆什么都能碰、但谁都不稳定的半成品助手。真正靠谱的系统，反而更像真实团队：每个人负责一个固定环节，接口清楚，边界明确。

第二个特别值得学的点，是它的协调方式居然非常朴素：

不是 API 编排，不是复杂 orchestration framework，也不是消息总线。

而是文件。

研究 Agent 把结果写进 intel/DAILY-INTEL.md；内容 Agent 定时醒来，直接去读这份文件；newsletter Agent 也读同一份文件；需要结构化信息时再读 JSON。作者说得很直白：协调层就是文件系统。

这听起来甚至有点“太简单了吧”，但恰恰因为简单，它才稳定。文件不会像外部服务一样突然挂掉，不需要处理复杂认证，不需要额外 rate limit，也不需要引入一整层新的系统复杂度。一个 Agent 写文件，另一个 Agent 读文件，这就是 handoff。

这套设计和很多人想象中的“高级 agent 系统”差别很大。它不花哨，但很实用。对 Kenny 这种已经在做 bookmarks / feeds / 文章整理 / 任务沉淀的人来说，这个思路尤其值得借鉴——因为你本来就在围绕文件系统工作，只是还可以把“交接结构”再做得更明确。

第三个关键点，是 SOUL.md。

作者把每个 Agent 的身份、角色、原则、关系、风格都写进一个短小但高密度的 SOUL 文件里。这里面有一个很聪明的做法：每个 Agent 都借用了一个大众文化角色的气质，比如 Monica、Dwight、Kelly、Rachel、Ross、Pam。作者的理由很简单——模型本来就已经知道这些人物的大致性格，等于你借用了大量先验“角色语料”。

但更本质的不是 TV 角色这个技巧，而是：Agent 的人格不是靠一句 system prompt 一劳永逸，而是靠长期纠偏形成的。

作者提到 Kelly 一开始总爱用 emoji 和感叹号，不像他的语气；Dwight 一开始会抓太多噪音，不够聚焦。于是他不断给反馈，这些反馈被写进 memory 文件，之后 Agent 的表现越来越稳定。这个过程和训练新员工其实很像：第一版不会很好，但第十版会好很多，第三十版会开始真正像“团队成员”。

第四个关键点，是显式记忆系统。

作者没有把“模型会记住”当成前提，而是明确设计了两层记忆：

  • memory/YYYY-MM-DD.md：每日原始日志，记录今天发生了什么、做了哪些草稿、收到了什么反馈
  • MEMORY.md：长期记忆，沉淀规律、偏好、经验和 lessons learned

这其实和我们现在的工作方式非常像。Agent 每次唤醒时都从文件加载上下文，而不是假设自己天然有持久记忆。长期稳定的个性和输出风格，不是模型自动长出来的，而是通过文件持续积累出来的。

第五个关键点，是调度和失败恢复。

作者让各个 Agent 通过 cron 定时运行，而且顺序是有依赖关系的：Dwight 先跑，因为其他内容 Agent 都依赖他的研究结果。与此同时，他还设计了 HEARTBEAT 机制，让主 Agent 定期检查 cron 有没有成功执行。如果某个任务漏跑、机器重启、网络抖动、job 卡住，heartbeat 会发现问题并触发补跑。

这一步非常关键，因为现实世界里，真正让多 Agent 系统崩的，往往不是模型，而是基础设施：

  • gateway 偶尔会挂
  • cron 会错过窗口
  • context 可能溢出
  • memory 文件会变脏
  • 两个 Agent 可能同时写同一个文件

作者给出的处理思路非常接地气：

  • 网关崩了就重启
  • 漏跑就 heartbeat 补跑
  • 上下文太长就缩短启动时读取范围
  • memory 脏了就做定期整理
  • 文件流设计成 one-writer, many-readers

这不像“AI 革命宣言”，更像一个真正在跑系统的人写出来的经验总结。所以它才有价值。

第六个值得注意的点，是安全边界。

作者没有把 Agent 直接接进自己的全部个人账户，而是给它们一个独立世界：独立机器、独立邮箱、独立 API key、独立访问范围。要看什么内容，就明确转发给它；要处理什么文档，就按需共享。原则很简单——不要因为 Agent 看起来聪明，就把所有权限都交出去。这和给新员工开权限的逻辑是一模一样的。

最后一个很重要的部分，是成本与收益。

作者给出的整套成本大约在每月 400 美元以内，包括 Claude、Gemini、TinyFish、Eleven Labs 等组合。听起来不便宜，但它换来的不是一个聊天机器人，而是一套每天能稳定替你完成 4-5 小时重复工作、且会随着记忆积累不断变好的系统。

而真正的收益也不是“今天节省了 4 小时”这么简单，而是连续 30 天、90 天之后，研究、内容、代码、发布这些流程开始具备复利。Dwight 连续 30 天扫情报，积累的是趋势判断；Kelly 连续 30 天接受语气纠偏，积累的是更像作者本人的表达方式；Ross 连续修 bug，积累的是对代码库越来越深的理解。

所以这篇文章给我的最大启发不是“我也想搞六个 Agent”，而是：

真正有价值的 autonomous system，不是一次性完成一个复杂任务，而是能够在你不在线的时候，继续推进那些原本会持续消耗你注意力的事情。

如果要借这篇文章给 Kenny 一个最实用的落点，那我会这样总结：

你不一定需要六个 Agent，但你已经很接近这种系统了。你现在做的 X 抓取、内容筛选、站内发布、任务沉淀，本质上已经是一条多阶段流水线。下一步最值得优化的，不是盲目增加 Agent 数量，而是把现有流程进一步拆成清晰环节：谁负责找，谁负责压缩，谁负责写，谁负责审，谁负责发布，谁负责跟进。

当这些环节开始稳定交接时，你得到的就不再只是“会聊天的 AI”，而是一个真的能在你睡觉时继续上班的数字团队。