2026年个人Agent自建实战

标签： | 发表时间：2026-05-08 16:41 | 作者：
出处：https://x.com
上一篇我聊了为什么自己不再去追新框架、不再频繁迁移、而是决定自己搭一套Agent。很多朋友看完后留言说“想动手但不知道从哪开始”，所以这篇文章讲了我用15天把我的个人 Agent “EvoPaw”从“能跑”迭代成每天都在用的工作系统，完整复盘可复制的方法论。
坦率的讲，我自己第一次摸索的时候也走了不少弯路。所以这一篇方法篇我尽量把每一步都拆得很细，让一个会装软件、能复制命令、不一定会写Python的普通人，也能跟着跑通。
整个过程其实就五步，选一个轻量基座，把Claude Code装好顺手把飞书跑通，建好几个脚手架文件让Claude Code知道你是谁，然后用对话把需求逼成具体的spec，最后边写代码边配测试。
我自己用这套流程跑了两周，把EvoPaw从一个「能勉强跑起来的脚本」迭代成了一个我每天都在用的工作系统。下面一步一步说。
我提前打个预防针，这套方法上手第一周其实有点笨拙的，一些步骤花的时间会比手动做还长。但是一旦跑顺了，后面每加一个新功能的速度会指数级上升，到后面真的会上瘾。

第一步，选一个轻量好扩展的基础项目

不要一上来就从零写，也别直接上那种功能堆得很重的框架。这两条路我自己都试过，一个是写到一半就卡死了，另一个是看不懂别人的抽象层、改不动。
你优先选那种代码少、可读性强、核心循环一目了然的项目，这样你才看得懂、改得动、长得久。
我当时主要是以一个课程Agent项目作为基础搭建，比较简陋，不过作为新手，可以先从下面两个里挑。
  • Pi-mono（ ）是一个非常干净的Agent基础包，OpenClaw很多思路都来自它，喜欢极简风格的同学可以从这个起手。
  • Nanobot（ ）是后来出现的「ultra-lightweight版OpenClaw」，几千行核心代码就能跑完整Agent循环，自带memory、skills、multi-provider，飞书、Slack、Telegram、Discord这些聊天通道都内置好了，扩展性极强。我最后选的是它，省下来的工程脚手架时间至少三个月。
这一步要看的几个判断标准，一是代码行数最好别超过8000行，二是agent loop要一眼看明白，三是能不能比较容易地加进飞书或微信，国外用户看Telegram和WhatsApp，四是能不能自由切换不同模型厂商的API。如果你找到别的合适项目，下面这套方法是完全通用的。

第二步，用Claude Code装上，把飞书也顺手跑通

我开发主力就是Claude Code，也推荐试试Codex这类CLI工具。它能直接读懂整个项目然后按你的指令改代码，不用再到处贴代码片段、来回切窗口。
以Nanobot为例，最简单的方式就是把项目地址直接丢给Claude Code，跟它说:
"请fork 到本地，帮我安装好，要求能正常运行，一步步告诉我需要做什么。"

它会读项目，给你一串安装命令，每一步执行前你看一眼再回车就行。中途遇到报错它也会接着帮你排查。
这里要插一句，API Key的事得说一下。它问你要某个大模型的API Key的时候，不要直接在命令行里贴出来，会有泄露风险。正确做法是问它「我这个Key应该放在哪个文件、写成什么格式」，它会告诉你格式，你自己手动填进去。
装完之后，如果你不想从头读README，就直接问:
帮我梳理nanobot的项目结构和核心功能，告诉我它支持哪些聊天通道、记忆方式和技能系统。
跟看产品说明书一样，30分钟你就有一个全局认识。
接下来要做的事，是给它接上一个聊天平台，让Agent真的「活」起来。国外Telegram、WhatsApp都行，国内我推荐飞书，主力通道就是它。当然如果可以使用Telegram或者WhatsApp最好，因为搭建起来真的很方便。
你可以先丢一句给Claude Code:
帮我配置飞书通道，要求能收发消息、支持富文本和文件上传。
它会一步一步告诉你要做什么。但飞书这一步比较特殊，Claude Code帮不了你点飞书开放平台的网页，凭证必须你自己去拿。流程在 ，4步搞定。
  • 第一步，创建一个「企业自建应用」。
  • 第二步，启用「机器人」能力，申请`im:message`、`im:message.p2p_msg:readonly`、`cardkit:card:write`这三个权限（如果你还想要群聊和文件传输，再加上`im: _msg:readonly`和`im:resource`）。
  • 第三步，事件订阅一定要选**长连接模式**。这是nanobot最舒服的一点，长连接不用公网IP、不用配webhook，比网上大部分飞书教程都省事，刚开始我也没注意到，被这个长连接特性救了一命。
  • 第四步，拿到App ID和App Secret之后，**记得点「版本管理与发布」把应用真的发版**。否则权限不生效，90%的人卡在这一步。
如果走完这一段还是觉得吃力，回头我可以单独录个视频补一下。
凭证全部填完之后，跟Claude Code说
帮我运行Nanobot。
然后你就能在飞书上跟自己的Agent正常聊天了。说真的，那一刻挺爽的。它终于不再是一个跑在终端里的脚本，而是真正的、你随时能用的助手。

第三步，先建脚手架文件，让Claude Code知道你是谁、你要什么

跑通飞书之后，很多人下一秒就开始喊Claude Code加功能。先停一下。
如果你不告诉它项目长什么样、你的偏好是什么、你想做什么，它每次都会从零猜。迭代两周之后你会发现项目里全是它自作主张加的代码，风格不统一，新会话还要花十分钟解释「我们上次做到哪了」。这个坑我前两周天天踩。
正确的做法是先花30分钟，建好下面这套文件，让Claude Code跨会话也能秒进入状态。这套约定不是我拍脑袋发明的，「给Agent写项目说明文件」已经是主流做法，Anthropic官方推荐这种工作流，OpenAI后来也跨厂推出了AGENTS.md开放标准，被6万多个开源仓库采用。
整体长这样：
`tests/`不用你建，nanobot仓库本身就自带完整的测试目录（`tests/channels/`、`tests/providers/`这些子目录都现成的），第五步往里加`test_*.py`就行。
下面分别说说每个文件干什么。
1.项目根的`CLAUDE.md`，相当于Claude Code的项目说明书。
它每次启动会自动读这个文件，把它当作「会话开头自动注入的记忆」。最简单的起手式是直接在Claude code 让它自动生成：
在我fork的nanobot项目里运行 `/init`，扫描代码库生成首版CLAUDE.md。
它生成的初版通常太啰嗦，你可以让Claude把它简化到200行以内。社区共识是不超过300行，再多就开始挤占上下文、让Claude对规则的遵循度下降。只留它推不出来的非显然信息就够了，比如:
markdown
    - WHAT，这个项目是干嘛的，一句话讲清
- WHY，哪些设计选择不能动，比如「channels目录保持nanobot上游可合并，自定义skill全部放custom_skills/」
- HOW，build怎么跑、test怎么跑、调试入口在哪、有哪些已知坑点
- 你的个人偏好，比如「用中文回复、commit前先问、改代码前先读现有文件」这种
最常用的一个例子，是把「测试规则」也写进CLAUDE.md。这样后面让它写代码的时候，它会自动连测试一起做、跑完pytest才报「完成」，不用你每次重复提醒。第五步会展开，先给个最小版本:
markdown
    ## 测试规则
修改任何代码时必须，
- 同步加或改 tests 下对应的 test_*.py
- 外部依赖（HTTP / 第三方 SDK）用 MagicMock 替换，不发真请求
- 至少覆盖正常、空输入、出错三种情况
- 写完跑 pytest -v，全绿才算完
反过来说，有些东西不该往CLAUDE.md里塞，比如格式化规则、代码风格规则、命名规范这些。这种死规矩你写一个脚本就能约束，让Claude来记是浪费上下文。圈内有句话叫「Never send an LLM to do a linter's job」，linter能干的事就别让Claude干。
2.`docs/`目录，把需求和进度从你的脑子里搬到磁盘上。**
里面我固定放三个文件，是Harper Reed在2025年初定型的「LLM codegen三件套」，和CLAUDE.md一起形成完整闭环。
markdown
    - `docs/spec.md`，当前要做的功能的需求规格，包括场景、痛点、期望、优先级、约束
- `docs/prompt_plan.md`，把spec拆成分步可执行的prompt序列
- `docs/todo.md`，跨会话的粗粒度checklist，下次开新窗口直接说「读docs/todo.md继续」就能秒续
实操的时候，把这一句丢给Claude Code
我想给nanobot加PDF解析能力，先用对话方式跟我反复追问需求边界，最终写到docs/spec.md，然后基于这份spec生成docs/prompt_plan.md分步执行计划和docs/todo.md跨会话清单。
我第一周没建`todo.md`，每次开新会话都要花十分钟跟Claude Code解释「我们上次做到哪了」。建好`docs/`之后，每天开工第一句永远是「读CLAUDE.md和docs/todo.md，告诉我下一步要做什么」，五秒进入状态。这种持久化记忆比任何「prompt工程」技巧都管用。
脚手架建好，进入第四步，正式坐下来梳理你要做什么。

第四步，迭代之前，先用对话把模糊需求逼成具体spec

很多人在这一步直接跳过去了。脑子里只有一句模糊的「我想让它能XX」，拿着这句话就丢给Claude Code，结果它脑补一通生成一堆代码，跑起来发现根本不是你要的，返工返到怀疑人生。这个坑我自己踩过太多次。
正确的做法**不是自己闷头写需求文档，而是让AI来逼问你**。这套思路现在已经是社区共识，Anthropic官方文档把它叫做`explore → plan → code → commit`四阶段，干的都是同一件事，先把脑子里的雾捏成spec，再开工。它真正的价值不是让你写代码更快，而是让反馈环变短。
我每次开新需求的时候，会跑下面四个小步骤。
1.先用一张表把模糊需求列出来。
我每次开新需求会先花十分钟填这张表，作为下一步brainstorm的输入。
表本身不重要，重要的是逼自己用一行字说清楚每个场景的痛点和期望。说不清楚的，下一步brainstorm阶段你自然会被AI问出来。

2.Brainstorm，让Claude Code反复追问你，输出`docs/spec.md`。
挑表里优先级最高的那一行，开Claude Code，按`Shift+Tab`切到plan mode（这是Claude Code的内置模式，让模型只规划不写代码或者敲/plan命令切换），告诉它
我想给nanobot加一个PDF解析能力。先不要写任何代码，用对话方式反复追问我，直到把功能边界、输入输出格式、错误处理、性能上限、是否持久化到记忆、跟现有skill的边界都问清楚，最后把整理结果写到docs/spec.md。
它会一轮轮抛问题给你，「用户从哪里触发」「扫描版PDF怎么处理」「解析失败时是抛错还是返回空」「是否需要支持表格抽取」。这些问题你自己拍脑袋想半天也想不全，但模型五分钟就能逼出来。这是整套工作流里我觉得性价比最高的一步。
3.Plan，把spec拆成可执行的prompt序列。**
`spec.md`写完之后，紧接着让它把这份spec拆成可执行计划
读docs/spec.md，把它拆成5到10个可独立实现、可独立测试的小步骤，每一步配一段我能直接复制丢给Claude Code的prompt，写到docs/prompt_plan.md，同时把粗粒度checklist维护到docs/todo.md。
拆任务是典型的「想得久效果就好」的工作，记得开plan mode或者显式让模型think harder，同样的模型，开了深度思考拆出来的粒度明显更稳。如果你装了Codex MCP（见文末「进阶玩法」），也可以直接说「用codex拆一份对照版本」，借两家模型的训练分布差异互相挑刺。
4.把每条需求映射到Nanobot的架构层。**
最后用一句话决定每条需求落在哪一层，不然写代码的时候会到处乱跳。
markdown
    - **需要强隐私** → 强化本地记忆模块
- **需要多模型** → 完善Provider层
- **需要稳定性** → 加测试和定时任务
- **需要新能力** → 写SKILL.md或MCP server（这是最常见的落点）
- **只是规则约束** → 改CLAUDE.md或AGENTS.md，根本不要写代码
最后这条最容易被忽视。很多需求根本不需要写代码，加几行markdown规则就够了。这是2025年整个vibe coding圈子最重要的共识之一，能用markdown配置解决的，绝不写代码，能写skill或MCP server解决的，绝不改框架核心。这样未来nanobot上游升级，你的工作量几乎为零。
我自己的真实需求是飞书深度集成、学术场景工具、数据长期主权这三块。落到上面四类之后，每条需求是写skill、改provider，还是只调markdown，一目了然。
为什么这一步值得花一两个小时？我自己的体感是，spec写不清楚，后面每一轮implement → test → review都会反复在同一个误解上空转。花一小时brainstorm，能省掉两周的乱改，这就是Anthropic把plan mode做成内置功能的原因。

第五步，每加一个功能，必须配一组测试

vibe coding最容易偷懒的环节是测试。写完跑通就走人，结果两周后切个模型、改个provider，整个功能静默挂掉都没人知道，这就是我15天写了500多个测试的原因。
好消息是nanobot自带完整的pytest测试体系，你不用从零设计，写完功能直接让Claude Code帮你配测试就行。
每加一个新功能，我固定丢这一段prompt过去
我刚加的功能帮我写一组测试，下次改代码万一坏了能立刻发现。要求，第一，凡是要真的连网络或者调用外部接口的地方，用假数据顶替，不要发真请求；第二，至少跑三种情况，正常使用、没有数据、出错；第三，风格参照项目里已有的测试文件；第四，写完直接 `pytest -v` 跑一遍，全绿才算完。
它会先读项目里已有的测试，自动学你的风格，然后写完就自己跑一遍。绿了你才接下一段功能。
我得说一下，测试这件事第一次做的时候你会觉得「啊好麻烦，多花我30%的时间」。但坚持两周之后，你会发现真正的杠杆不是「防bug」，而是给你换模型、改底层、做大重构的胆量。红了立刻知道在哪，绿了你就敢继续。
没测试，你的Agent就长不大。

从别的agent项目里“偷点”好设计过来
这一段也是可选的，但我自己越走越觉得它价值高。
你把nanobot跑顺之后，会很自然地好奇，别人那些更成熟的开源agent项目里都有些什么我能学的。比如NousResearch的Hermes Agent、社区里讨论很多的OpenClaw。
坦率的讲，我一开始想得很贪，看到Hermes那种工业级的autonomous skill creation，第一反应是「我能不能fork整套过来」。后来踩了坑才明白，**不是你看到一个酷设计就能整套搬过来用**。我自己的判别准则现在固定下来变成了三层。
1.思想级，重写不要拷贝。 看完别人的设计文档，理解他要解决的问题，自己用nanobot的风格重写一遍。比如OpenHands的event-stream和sandbox设计。好处是你拿走了思想，但代码风格跟nanobot一致，未来好维护。
2.模块级，独立抄一个模块过来几个我自己最想抄的，
  • Hermes的Curator，它的活是周期性扫`history.jsonl`，自动合并、弃用、重构skill。解决了「skill一旦学到就不再更新」的痛点，是self-evolving agent的工业级样板。
  • Hermes的execute_code tool，让agent写一段Python脚本去调度其他tool，把多步操作压成一步，trajectory一下子短了一大半，省token也省时间。
  • SOUL.md，给agent一个稳定的性格档案，模型切换之后回答风格不会漂移。
3.文件级，原样复用。最简单的，比如Claude Agent SDK自带的`.claude/skills/skill-creator/`、`.claude/agents/code-reviewer/`这种SKILL.md文件，里面已经有完整的progressive disclosure结构（带`scripts/`、`references/`、`examples/`子目录），直接塞进nanobot的`skills/`文件夹就能跑。
这里有个反例提醒，千万不要把整套依赖复制过来。把OpenHands或Hermes的70多个Python包整套塞到自己环境里这种事我干过一次，跨版本冲突一个晚上都没搞定，最后只好回滚。一个稳健的姿势是，看到好设计先问自己一句「这到底是思想、模块、还是文件哪一层」，再决定怎么搬。
回扣一句前面说过的话，用现成框架你永远是用户，但同时多看几家项目的源码，你会从用户慢慢变成一个「会鉴赏的设计师」。再回头写自己的agent，那种「我知道每个选择背后的trade-off」的感觉，是没看过别人代码的人体会不到的。

进阶玩法（可选），让Codex给Claude Code当reviewer

下面这一段是可选的进阶玩法，不做也完全不影响主流程，但做了之后效率会再上一个台阶。
如果你订阅了ChatGPT，可以把Codex CLI也装上，多花5分钟一次性配置，就能给Claude Code接上一个完全独立厂商训练的「第二意见」，全程不用切终端。
一个人写需求文档的最大盲区是自我合理化。Claude Code帮你写的`spec.md`，它会按自己擅长的实现思路去拆需求，盲区你很难察觉。换一个不同训练分布的模型来挑刺，效果立竿见影。
第一次配置只要三步。
第一步，装好Codex CLI并登录，参考OpenAI官方文档。
第二步，把Codex注册成Claude Code的MCP server。MCP是Anthropic开放的工具协议，注册之后Claude Code就能像调内置工具一样调Codex。在Claude Code里运行类似下面这一行（具体启动命令以官方文档为准）
markdown
    claude mcp add codex -- codex mcp
第三步，重启Claude Code会话。最新配置字段见 。
配置好之后，在Claude Code命令行里直接用自然语言说就行
用codex review一下docs/spec.md和docs/prompt_plan.md，重点看需求歧义、边界情况、跟nanobot现有架构的冲突。把它的修改建议逐条评估，你同意的直接改spec.md，不同意的告诉我理由，最后让我拍板。
Claude Code会自动调起Codex跑这次review，把结果拿回来逐条challenge，整个流程一气呵成，你只在最后做裁判。这是双AI工作流跟传统「两个终端来回切」最大的差别，你的注意力始终留在一个会话里。
为什么值得多花这10分钟？我自己的体感是，第二个模型最有价值的地方不是「更聪明」，而是它能替你发现另一套你看不见的盲区。归根结底，是把两家模型的训练分布差异，变成你的免费QA。
整个过程收获远超预期。最重要的是，我们可以真正拥有了一个可以长期演化的系统，而不是被一个框架牵着走。
最后聊一点感受。
这15天里我也碰过并发卡死、上下文炸掉、跨会话状态丢失这些问题。一开始确实有点慌，觉得「这是不是已经超出我能力范围了」。
后来发现，碰到问题、理解问题、用AI Coding解决问题，这条路基本上一定能走通。重点不是你立刻就懂，而是你愿不愿意把它逐渐拆成你看得懂的部分。这一点说起来简单，做起来其实就是反复跟Claude Code多聊几句而已。
回到开头那句话，「想动手但不知道从哪开始」。如果你真的看完这篇文章，今天就去fork一个Nanobot，让Claude Code帮你装上、跑通第一个对话。这个动作其实很小，但你会发现一旦做完它，整个Agent这件事，就从「别人在玩的东西」变成「我能改造的东西」。
用现成框架，你永远是用户。自己搭，你才能成为主人。

相关 [个人 agent] 推荐：

2026年个人Agent自建实战

- -
上一篇我聊了为什么自己不再去追新框架、不再频繁迁移、而是决定自己搭一套Agent. 很多朋友看完后留言说“想动手但不知道从哪开始”，所以这篇文章讲了我用15天把我的个人 Agent “EvoPaw”从“能跑”迭代成每天都在用的工作系统，完整复盘可复制的方法论. 坦率的讲，我自己第一次摸索的时候也走了不少弯路.

Agent Loop 简介

- - 唐巧的博客
先说一个看起来有点反常识的事： LLM 本身是无状态的. 每次调用模型，本质上就是一次”文本补全”——你扔一段 prompt 进去，它根据这段 prompt 续写一段输出，然后整个过程结束. 下一次再调用，模型对上一次的事一无所知. 从机制上讲，它和 2020 年的 GPT-3 没有本质区别，都是一次性的补全器.

User Agent注入攻击及防御

- - FreeBuf.COM | 关注黑客与极客
CloudFlare公司经常会收到客户询问为什么他们的一些请求会被. CloudFlare WAF 屏蔽. 最近，一位客户就提出他不能理解为什么一个访问他主页简单的 GET 请求会被 WAF 屏蔽. 正如他说的，一个简单的请求访问 WEB 主页，乍看之下好像没什么问题. 除非你仔细查看 User-Agent 部分：.

使用LangChain来实现大模型agent

- - Java译站
我们先从LLM Agent的各种不同示例开始讲起. 虽然很多人在热议这个话题，但很少有人经常在使用它；通常，我们所认为的agent只是大语言模型. 来看一个简单的任务，如搜索足球比赛结果并将其保存为CSV文件. GPT-4结合搜索和插件：如这里的 聊天记录所示，由于代码错误，GPT-4未能完成任务.

Agent 讓 RAG 過時了嗎? 談 AI Coding 的檢索策略

- - ihower { blogging }
看了一場 Augment Code (也是一家做 AI IDE 的廠商) 來講 “Agentic 檢索” 對比 “傳統 RAG 檢索” 的演講，蠻有啟發的. 在 AI Coding 領域，簡單的工具正在擊敗複雜的 RAG 系統. AI Coding 的演進歷程. AI Coding 的演進是這樣:.

Agent Skills 技能系统原理与实践

- -
[重读官方文档] Agent Skills 技能系统原理与实践. Agent Skills 把领域特定知识、工作流程、最佳实践打包成可重用的“技能包”，让通用 AI Agent 转变为专精于特定任务的 Agent. 不同于一次性提示，Skills 是基于文件系统的资源，按需加载，避免重复指导. Anthropic 已将 Agent Skills 标准正式开放：.

Google Deepmind论文解读：如何给AI Agent 投毒

- -
2026 年 3 月，Google DeepMind 发布了一篇论文，题目叫《AI Agent Traps》. 下载地址：📎 ai agent trap.pdf. 五位研究者做了一件之前没人系统做过的事：. 把所有已知的、针对 AI Agent 的攻击方式，第一次完整地梳理成一套框架. 读完，学习了不少AI Agent攻防技巧，但也感觉这件事比大多数人意识到的要严重得多.

Agent Harness：让AI从聊天机器人变成真正的智能体

- -
你可能已经搭建过聊天机器人，甚至接入了几个工具，做出了能演示的原型. 但当你想把它推向生产环境时，问题就来了：. 模型会忘记三步之前做过什么，工具调用会失败，上下文窗口塞满了无用信息. 问题不在模型本身，而在模型周围的一切. LangChain 用一个实验证明了这点：. 他们只改变了 LLM 的基础设施（模型和权重完全不变），在 TerminalBench 2.0 的排名就从 30 名开外跃升到第 5 名.

不用插件修改 Chrome 的 User Agent 字符串、模拟移动触屏设备

- - Chrome迷
今天发现了 Chrome 上一个修改 User Agent 字符串的新方法，甚至还能模拟触屏设备，手动改变你所在的位置(经纬度). 1、打开 Chrome 的”开发者工具”，也就是菜单——工具——开发者工具. 2、在打开的开发者工具(Developer Tools)界面的右下角，点击黑色齿轮图标. 3、然后在黑底界面中点击”Overrides”标签页就能看到了.

想用Clawdbot何必抢Mac mini，手把手教你打造最强本地Agent，立省200美元 | 附保姆级教程

- - 爱范儿
今年，本地 Agent 产品真的火了，说是一周一爆款，一点都不为过. 前有 Claude Cowork 一发布就创下将近五千万次的浏览；后有 Clawdbot（现在已经改名叫 Moltbot），在 GitHub 上的 Star 数量，直线突破，从两千狂飙到 7 万. 这么多工具，根本尝试不过来，况且像 Clawdbot 这种需要自己部署服务器的 AI，着实很劝退想要尝试的电脑小白用户.