做 AgentClaw：为什么教程要从“任务”而不是“产品”开始
AgentClaw 从一个 OpenClaw 教程站，变成按任务组织的 AI Agent 学习平台。这篇复盘写的是几个关键取舍：先问读者要完成什么，把完成标准写在前面，并且说清楚每篇内容到底验证过什么。
AgentClaw 是我独立维护的一个 AI Agent 中文学习站。现在站内有 65 篇以上的结构化教程，覆盖 DeepSeek Harness、WorkBuddy、OpenClaw 和 Hermes 四条路线。
这篇不讲它有多少内容，只讲几个做下来最重要的取舍。这些取舍后来也成了我给客户做 AI 流程时用的方法。
一开始，它只是一个 OpenClaw 教程站
AgentClaw 最早是围绕 OpenClaw 建的。那时候大家最关心的是：怎么自托管一个个人 Agent、怎么接消息入口、Gateway 怎么配、安全和审批怎么做。
但真正让我决定改版的，是另一件事：早期的文章写得太笼统了。 一篇教程讲清楚“这是什么”“有哪些功能”，看起来什么都说了，读者看一眼就走，因为读完之后手里什么都没有，也不知道下一步该做什么。
同时，WorkBuddy、Hermes、Harness 和新的 Agent 应用一个接一个出现。如果继续按“一个产品一个栏目”往下加，站点只会越来越像一本更厚的产品目录：读者得先认识一堆名字，才能找到自己要的东西，而每篇文章依然浅浅地停在介绍层面。
所以我把它从单一的 OpenClaw 教程站，改成了 AI Agent 学习与应用平台。改动的核心只有一句话：从读者想完成的任务出发，并且每篇都要带着读者真的做完一件事。
读者真正想问的，不是“这个产品是什么”
一个人搜索 AI Agent，想要的通常不是一段热闹的概念介绍，而是能马上帮他做判断的答案：
- 这个工具适合我吗？
- 应该从哪里开始？
- 什么时候该迁移？
- 哪些能力能进入我的真实工作？
- 哪些动作必须谨慎？
所以首页的第一个问题是：“先选择你要完成的事，不必先记住产品名。” 下面只有四个入口：第一次使用 Agent、办公与本地文件、Coding 与项目开发、长期自动化。
产品名依然在，但退到了第二层。选好任务之后，页面再告诉你该用哪个 Agent、要开什么权限、做到什么程度算完成。不同的工具也不硬写成互相替代的关系：WorkBuddy 更偏桌面办公和可复用工作流，OpenClaw 更偏自托管和多渠道，Hermes 更偏长期记忆和定时任务，Harness 更偏 DevOps 和 MCP。
把完成标准写在教程最前面
“学完以后，手里留下什么？”这是我给每条路线定的硬要求：不能只留下一段聊天记录，要留下一份能打开的文件、一次能复现的修复，或者一个可以继续改的 Skill。
以 WorkBuddy 的会议纪要教程为例。它提供一份固定的练习材料，里面故意埋了几种容易出错的情况：已经确认的决定、只是提议的建议、缺了负责人的行动项、还没结论的风险。教程开头就把完成标准列清楚：
| 检查对象 | 必须满足 |
|---|---|
| 已确认决定 | 只有 2 条 |
| 行动项 | 3 条 |
| 未确认建议 | 只能标为“建议” |
| 缺失字段 | 负责人和日期都写“待确认” |
| 可追溯性 | 每一条都保留原始编号 |
只要模型给那条缺负责人的行动项“补”了一个人名，或者把建议写成了结论，这一轮就不通过。
这样做的好处是，读者不用靠感觉判断 Agent 做得好不好。标准在前面，结果在后面，一对就知道。教程里还有一句我很喜欢的提醒：不要只根据对话里的“已完成”判断成功，要逐个打开真实文件去看。
说清楚每篇内容“验证过什么”
Agent 相关的内容变化很快，而且很容易写成“看起来都对”。所以 AgentClaw 把“验证”拆成了四个层级，在每篇教程里分别标注：
- 资料核对：确认了官方文档里的说明，但不代表已经运行过；
- 本地样例测试：用指定的输入跑过，验证了输出；
- 产品实测：写明用的产品版本、环境、操作和实际结果；
- 外部复现：其他使用者也能复现，内部测试不能算。
比如会议纪要那篇教程，页面上直接写着“官方文档核验 · 尚未运行实测”。另外，“更新时间”和“核验日期”也分开记：正文改了只更新前者，真的重新核验过才更新后者。
站点用了 AI 辅助整理和写作，这一点也在“关于”页和编辑政策里公开说明了。我的想法是：AI 可以帮忙写，但不能替代核验，读者有权知道哪些是核验过的。
Skill 不追求数量
AgentClaw 也提供 Skill，但目前公开的只有一个内部实测版（beta）：一个“有证据的周计划与复盘” Skill，附带 3 组测试样例和 42 条断言。页面上写明了它的验证范围：通过了本地固定样例测试，还没有完成外部用户复现。
站内的原则是：少量、透明、可以被推翻。 研究只能批准投入，真实产物决定能不能发布，公开的运行结果决定要不要继续维护。
这样做，Skill 页面看起来会有点“空”。但我宁愿少，也不想放一堆没人验证过的东西。
这套方法，后来怎么用到客户项目里
回头看，AgentClaw 让我反复练的其实是四件事：
- 先定任务边界：只读哪些材料、只写哪些文件、哪些动作要人确认；
- 用固定样例测试：同一份输入，才能比较不同做法的效果；
- 把完成标准写在前面：开工前就说清楚什么叫“做对了”；
- 区分“预期”和“实际”：没跑过的就说没跑过。
现在给客户做 Skill / Agent 定制 时，我用的就是这四步。区别只在于，教程里的练习材料换成了客户真实的工作。
还没做好的地方
- 很多教程目前停留在“资料核对”这一层，还没有全部做到产品实测；
- Skill 只有一个 beta 版，还没有外部用户复现；
- 按任务组织内容，意味着同一个产品的信息会分散在多个入口，找“某个产品的全部教程”反而要多走一步。
如果你也在考虑让 Agent 接手一段真实的工作，可以先去 AgentClaw 找对应的任务路线试一试。试完还有问题，再来找我。