读完一套个人 Agent 搭建复盘：真正该自己掌握的，是工作方法

导语

最近读到 Xudong Han 的一篇长文：《个人 Agent 搭建完整合集：从 Vibe Coding 到每天都在用的个人工作系统》。

文章复盘了作者在一个多月里迭代个人 Agent EvoPaw 的过程，涉及轻量框架、飞书接入、需求说明、测试、Skills、记忆、模型配置和双模型互审。

它最吸引人的地方，不是列了多少工具，而是展示了一种很具体的变化：

一开始，你在试用一个 Agent。
后来，你开始修改它。
再后来，你把自己的工作步骤和判断标准写进系统。
最后，它不再只是一个聊天工具，而成了工作系统的一部分。

不过，读完之后我并不完全同意“只有自己搭，才能成为主人”这个结论。

对大多数人来说，从零重写 Agent 框架并不是最有价值的事。更值得自己掌握的，是下面这些不会因为更换模型或平台就全部作废的东西：

你如何描述需求；
你如何拆分任务；
你如何验证结果；
你有哪些可复用流程；
系统如何理解你的偏好和历史；
这些数据能不能迁移。

换句话说：

真正该自己掌握的，不一定是 Agent 的全部代码，而是自己做事的方法。

这里说的“工作流”，就是完成一类任务时固定的步骤、判断标准和检查方法。

下面聊聊这篇长文里值得学习的几件事，以及哪些内容不宜直接照搬。

一、先别急着写代码，先去记录“哪里不好用”

原文给了一个很实用的起点：先用现成工具一段时间，把所有别扭的地方记下来，再从真实痛点开始改。

这比“我要做一个全能个人 Agent”靠谱得多。

因为“全能”没有明确标准，你很难判断它究竟有没有做好。

你很容易堆出聊天、搜索、记忆、定时任务、浏览器、知识库等功能，却说不清哪一个真正改善了工作。

真实痛点则通常非常具体：

每天早上要手动整理多个信息源；
会议结束后要重复生成待办并同步给团队；
写文章时总要重新检查标题、配图、格式和引用；
任务执行了很久，却不知道卡在哪一步；
同一种报告每次都要重新解释格式。

这类问题更容易说清楚：Agent 要处理什么、最后交付什么、多久做一次。做完以后，也更容易判断它是否真的节省了时间。

可以把个人 Agent 的起点写成一张简单的问题卡：

问题	要回答的内容
场景	这件事在什么时候发生？
当前做法	现在靠谁、用什么工具完成？
痛点	最浪费时间或最容易出错的环节是什么？
理想结果	Agent 最终应该交付什么？
验收方式	怎样证明它确实节省了时间或降低了错误？

这张卡写不清楚，就先别选框架。

二、选一个你看得懂、改得动的 Agent 项目

原文推荐从 Nanobot 这类轻量项目开始，判断标准包括核心循环是否容易理解、能否接入常用聊天渠道、能否更换模型供应商。

这个方向是对的，但“代码行数低于某个数字”不应该被当成硬标准。

真正重要的是，你能不能看懂一项任务在系统里是怎样跑完的：

一条消息从哪里进入系统？
模型在什么时候决定调用工具？
工具结果怎样回到模型？
会话和任务状态存在哪里？
记忆在什么时候写入和读取？
失败、超时和重复消息怎样处理？

如果这些问题都能较快找到答案，你才知道以后应该去哪里增加功能、排查错误或更换模型。

如果一个项目代码很少，却把核心行为藏在外部依赖里，出了问题仍然无从下手，那它并不真的容易修改。

反过来，一个项目即使功能更多，只要每个模块负责什么很清楚、接口不随意变化、运行过程有日志可查，也可能比“极简框架”更容易维护。

因此，选择现成 Agent 项目时，可以检查下面五件事：

流程图

目标不是从零重写一切，而是避免出现这种局面：系统出了问题你不知道怎么查，数据想搬走却导不出，某个模型停用后整个项目都得推倒重来。

三、让 AI 写代码前，先把需求说到能够验收

原文最值得反复读的一部分，是它对 Spec 的强调。这里的 Spec，可以简单理解为一份写清功能要求和验收标准的需求说明。

AI 写代码的速度越来越快，但它只会更快地朝你给出的方向前进。

需求清楚，它可以很快完成；需求模糊，它也可能很快写出一堆不是你想要的代码。

很多 Vibe Coding 项目失败，不是模型不会写代码，而是人只给了一句：

帮我加一个智能总结功能。

“智能总结”至少还缺少这些信息：

总结什么数据；
在什么时间触发；
谁可以看到；
输出什么结构；
信息不足时怎么办；
是否需要引用原文；
失败后是否重试；
结果保存在哪里；
怎样判断总结质量合格。

原文建议先通过对话把需求问清楚，再写成 spec.md，最后拆成一项项可以实施和检查的任务。

整个过程可以概括为：

流程图

任务是否必须控制在 2 到 5 分钟，不必机械照抄。

更可靠的判断标准是：

每个任务最好只解决一个清楚的问题，并且做完后有办法单独检查结果。

有些任务两分钟可以完成，有些任务需要半天。耗时不是关键，关键是做完以后能明确判断“通过”还是“不通过”。

四、测试到底在防什么？防的是 AI 改了 A，又弄坏了 B

原文有一句判断很准确：没有测试，你不知道 AI 这次修改是否破坏了旧功能。

假设你让 AI 给 Agent 增加一个“自动总结群聊”的功能。

它很快写完代码，现场试了一次，也确实生成了总结。看起来任务已经完成。

但你可能还不知道：

没有新消息时，它会不会生成一篇空总结；
同一批消息会不会被重复处理；
总结失败后，原始消息是否还在；
新代码有没有破坏原来的历史记录功能；
普通群成员会不会看到无权查看的内容。

所以，测试不是为了给 AI 的代码打一个分数。

它的作用更直接：每次 AI 修改代码后，自动检查那些“原本应该正常工作”的事情是否仍然正常。

Spec 用文字说明系统应该怎么工作，测试则把其中最重要的要求写成可以反复运行的检查。

但这里也有一个常见陷阱：

同一个上下文里的同一个模型，先写实现，再为自己的实现补测试。

这种做法的问题是，AI 很容易按照自己刚写的代码补一套测试。代码怎么实现，测试就怎么验证，最终当然容易通过。

但测试通过，只能证明“代码和测试说法一致”，不一定能证明“功能符合用户需求”。

更稳妥的流程是先确定用户能看到的结果，再写测试，最后才写实现：

流程图

写测试和检查测试的人，最好不要只盯着现有代码。

可以让人根据 Spec 审查测试，也可以让另一个 Agent 只看需求和测试，不先看实现。这样更容易发现“测试漏掉了用户真正关心的情况”。

对于 Agent 应用，下面这些情况尤其值得测试：

用户可见行为；
权限边界；
数据是否被正确保存；
同一请求重复发送时，会不会重复执行；
工具失败后怎样降级；
超时后状态是否可恢复；
模型输出异常时系统是否兜底。

这些检查都通过了，你才更有把握说：这次修改不仅能跑，而且没有把系统其他地方弄坏。

五、什么时候该写成 Skill？同一套步骤开始重复出现时

原文推荐用 Skills 固化 brainstorming、写计划、TDD、系统化调试和完成前验证等流程。

这里先用一句话区分 Prompt 和 Skill：

Prompt：告诉 Agent 这一次要做什么。
Skill：告诉 Agent 以后遇到这类任务，都按什么步骤做。

比如，你第一次让 Agent 发布公众号文章时，可以在 Prompt 里逐项交代要求。

但当你每周都要发布文章，再反复输入同一套要求就没有必要了。这时可以把稳定步骤整理成一份文章发布 Skill，内容包括：

检查文章目录和元数据；
确认封面和正文图片归属；
渲染 Mermaid；
检查移动端排版；
上传正文图片和封面；
创建公众号草稿；
记录草稿 ID 和预览路径。

如果这些步骤只存在你的脑子里，换一个会话就要重新解释，也容易忘记检查封面、手机排版或图片上传。

写成 Skill 后，Agent 每次都能读取同一套步骤；再配上脚本和检查规则，一部分步骤还可以自动执行和验证。

一套流程通常这样变成 Skill：

流程图

不必第一次做某件事就急着写 Skill。

更实用的判断是：同类任务已经成功做过几次，步骤相对稳定，而且你发现自己在重复解释同样的要求。这时再写成 Skill，通常更准确。

需要注意的是，Skill 也会过期。

API 会变化，工具会升级，平台规则会调整。一个可靠的 Skill 不只要写“怎么做”，还应该说明：

适用条件；
输入和输出；
外部副作用；
失败后的处理；
必须执行的验证；
依赖版本或来源。

所以 Skill 不是一段让模型突然变聪明的神奇 Prompt，而是一份 Agent 可以反复执行、并且需要持续维护的操作手册。

六、Agent 可以记住你，但这些记忆必须由你管理

原文提出，Agent 用得越久，就越了解用户。这个观察很有启发。

用户偏好、任务拆分习惯、常用格式、项目背景和历史决策，会让 Agent 越来越贴合个人工作。

EvoPaw 的公开仓库把记忆分成了几类：固定文件保存用户偏好和运行规则，会话记录保存最近发生的事情，数据库则帮助系统从大量历史记录里找回相关内容。

从产品角度看，记忆至少可以拆成三层：

层次	内容	示例
稳定偏好	较少变化的规则	输出语言、格式、哪些操作要先确认
项目状态	当前阶段的事实	目标、进度、已经做出的决定、当前卡点
历史经验	从过去任务中检索	失败案例、复盘、可复用方案

但“记得越多”不等于“越懂你”。

长期记忆还必须解决：

谁决定什么值得记；
错误记忆怎样纠正；
过期信息怎样淘汰；
敏感数据是否允许进入记忆；
用户能否查看、编辑和导出；
换模型或换框架后能否继续使用。

所以，把数据库部署在自己电脑上，并不代表这些记忆就已经完全受你控制。

你还应该能够查看 Agent 记住了什么，改正错误内容，删除敏感信息，并在更换系统时把数据导出去。

七、让两个模型互相检查，关键是不要让它们先互相影响

原文提出让 Claude 和 Codex 互相检查需求说明、测试、故障原因和重要代码改动。

这个方法要有效，关键不只是使用两个不同模型，还要让它们先分别判断。

如果第二个模型完整看到第一个模型的分析和答案，它很容易沿着同一条思路继续走，最后变成礼貌地点头。

更好的互审方式是：

两边先基于相同原始证据独立分析；
第二个模型不知道第一个模型的最终修复方案；
两边都必须给出证据和可复现步骤；
出现分歧时，用测试、日志和运行结果裁决；
只在重要任务上使用双模型，避免每件小事都增加费用和等待时间。

因此，双模型互审的价值，是多一个没有被原答案影响的检查视角，而不是简单获得“双倍智能”。

至于能否让 Bug 减半，不能只凭个人案例下结论。可以选一组自己的真实任务，比较它多发现了多少问题，以及为此增加了多少 Token、等待时间和费用。

八、三件不建议直接照搬的事

1. 不要把“自建”理解成“全部重写”

你可以使用开源项目、托管模型和第三方工具，同时保留自己的数据、接口、Skills、测试和业务逻辑。

真正重要的是：模型或工具不好用时，你能换掉它；数据和自己的流程仍然保留。代码不需要全部由自己写。

2. 不要把个人配置当成通用最佳实践

默认使用哪个模型、让模型思考多久、哪些操作需要确认、是否上传使用统计、命令等待多久，这些设置都和软件版本、费用、风险及任务类型有关。

作者的配置可以作为检查清单，但不应该脱离当前官方文档和自己的评测直接复制。

3. 不要先做记忆、语音和多 Agent，再寻找场景

复杂功能会让系统看起来完整，却不一定产生价值。

先让 Agent 把一件经常发生的工作从头到尾做好，而且结果能够检查。之后再添加记忆和自动化，通常更稳。

九、如果今天开始，可以按这条路线走

如果今天开始搭个人 Agent，我更建议按下面四步走。

第一步：选择一件真实的重复工作

选一件每周至少发生两次、输入输出明确的重复工作。

先人工跑通，记录每一步和失败点。

第二步：用现成项目做出最小版本

只接一个入口、一个模型和必要工具。

不要急着做长期记忆和多 Agent。

第三步：写清要求，补上测试和日志

写清楚怎样才算完成，让关键结果可以自动检查；任务失败时，也要能从日志里看到失败在哪一步。

第四步：把已经稳定的步骤写成 Skill

当同一流程成功执行三次以上，再把固定步骤整理成可复用 Skill，并记录什么情况下适用、失败后怎么办。

整个过程可以画成：

流程图

这条路线没有“十五天做出全能 Agent”那么刺激，但更可能得到一个半年以后仍然在使用的工具。

十、最后的理解：真正会留下来的，是你做事的方法

读完这篇长文，我最认同的不是某个框架，也不是某套配置。

而是这种逐步改进的思路：个人 Agent 不需要一次开发完，它可以从一件真实工作开始，哪里不好用就改哪里。

模型会换，框架会换，聊天入口也会换。

真正能够留下来的，是下面这些东西：

清楚的需求和验收标准；
稳定的工具连接方式；
可迁移的数据和记忆；
经过验证的 Skills；
覆盖关键行为的测试；
出了问题可以回看的运行记录；
你对自己工作方式的理解。

这些内容即使换一个 Agent 框架，仍然可以继续使用。

所以，不必先问“我要不要自己写一个 Agent 框架”。

更好的问题是：

今天这项重复工作里，有哪一步可以写清楚、自动检查，并在下次直接复用？

当这些步骤不断积累，你自然会拥有一个越来越懂你的系统。

到那时，Agent 才不只是一个偶尔聊天的工具，而会真正参与到你的日常工作中。

参考资料

Xudong Han：个人 Agent 搭建完整合集
https://x.com/xudong07452910/status/2062087939547332948
EvoPaw：作者公开的个人 Agent 项目
https://github.com/hxdflying/EvoPaw
HKUDS/nanobot：轻量个人 Agent 项目
https://github.com/HKUDS/nanobot
obra/superpowers：面向编码 Agent 的 Skills 工作流
https://github.com/obra/superpowers