我最近在整理自己用过的 AI 工具。
工具越来越多，真正能反复接住工作的东西，没有跟着增加。
有些工具看起来很强，到了自己的任务里，还是要从头解释一遍。
我后来回头看，问题不全在工具。
很多时候，我只是把工具装进来了，却没有把自己要交给它的那件事说清楚。
所以我现在建议，正在使用 AI 的人，开始搭建自己的 Agent。
一、
我现在做一篇文章，不会只从一个空白对话框开始。
选题、素材、旧文章、草稿、平台版本和发布记录，都放在自己的内容生产目录里。里面还有我写过的 Agent、Skill、SOP、验收和个人工作系统材料。
这些材料不只用来存档。下一次写作时，相关内容应该重新进入任务。以前确认过的判断可以继续用，失败留下的问题也可以提醒我不要再走一遍。
如果我只对 AI 说“写一篇关于 Agent 的文章”，它仍然可以生成一篇结构完整的文章。但它不会自动知道我以前写过什么，不知道哪些材料属于我的经验，也不知道这篇文章完成后要进入什么流程。
能生成文字的 AI 和能接住个人工作的 Agent，中间还隔着一段路。
如果一个 AI 每次都要等我重新解释，不知道我以前写过什么，不知道我怎样判断，也不知道怎样才算做完，它只是完成了眼前的一次对话。它没有进入我的工作系统。
我现在建议开始搭建自己的 Agent，原因就在这里。
二、
我说的“搭建自己的 Agent”，不等于注册一个平台，也不等于复制一段提示词。
它是把自己的材料、判断、步骤、验收和权限，逐步整理成一套能反复运行、能继续积累的工作系统。
模型会换，工具会换，平台也会换。自己留下来的文件、方法、失败记录和完成标准，才让下一次工作不必从头开始。
很多教程会告诉你，2 分钟可以做一个 Agent，或者 3 步就能完成配置。这样的教程解决的是入口问题。你会知道去哪里写角色、怎样接一个工具、怎样让它返回结果。
但配置完成，只说明它能动。它能不能处理你的工作，要看它是否知道你的工作到底由什么组成。
一件真实的工作，通常不只有指令。
以写文章为例，“写一篇关于 Agent 的文章”只是一句话。真正开始以后，还要决定用哪些旧文章和素材，哪些是我自己的经验，哪些只是外部案例，文章写给谁，哪些判断已经确认，哪些信息需要核对，写完以后要检查什么，母稿怎样改成公众号版和 X Articles，图片放在哪里，什么时候可以进入待发布。
这些内容不在一句提示词里。它们散在目录、旧文章、规则、对话和人的脑子里。
个人 Agent 要做的第一件事，是接住这些上下文。它不只听见这次说了什么，还要找到这次工作依赖的材料，并知道它们各自是什么：原文、参考资料、已确认事实、待核对信息，还是一次失败留下来的记录。
如果个人材料没有进入任务，流程仍然可能生成一篇文章。文件存在，结构也完整，但它只使用了当前对话能看到的信息。过去积累的判断没有接上。
所以，判断一个 Agent 有没有用，我不会先看它能调用多少工具。我先看它有没有理解这件工作的材料和判断。
三、
Agent 适合从反复出现的工作开始。
反复，不代表每次都一模一样。它只是说明，这件事里已经有一部分做法会再次出现。输入可能会变，具体判断也会变，但大致的步骤、停下来的条件和交付形式可以写下来。
我以前写过一组“把活干好”的笔记。里面反复处理的是几件普通的事：怎样把老手的经验写下来，怎样判断一件事做完了，怎样先打通最小的完整路径，怎样把一次对话压成交接单。
这些事放到 Agent 里，还是同一组问题。
你要告诉它从哪里开始，先看什么，再做什么。遇到哪种情况不能继续猜。输出放到哪里。交给下一个人或者下一次运行时，要留下哪些决定、风险和引用。
如果这些都没有写，Agent 只能根据当前对话临场补全。补得像，不代表补得对。
我也装过 160 多个 Skill，经常用的只有十几个。原因不复杂。有些 Skill 对应的是我反复做的工作，输入、步骤和验收已经逐渐稳定。另一些只是“以后可能有用”的工具，没有进入实际流程，装完就放在那里了。
这也让我确认了一件事：Agent 的积累不在数量。一个能反复把事情做完的流程，比一排没有使用场景的工具更有用。
我做过一个处理微信重复文件的小工具。任务很小，但它已经包含了一个 Agent 应该具备的基本结构。
它先扫描文件，按大小分组，再用 MD5 判断内容是否相同。确认重复后，不直接删除，只保留最早的文件，把其余文件移到隔离区。隔离区保留 30 天，发现误判还可以恢复。
这里真正有用的部分，不只是 MD5。
任务边界是微信目录。判断重复有可检查的方法。删除被改成可恢复的移动。发生误判时有退路。完成后也能知道处理了哪些文件。
工具只是其中一环。没有边界、检查和恢复机制，同一个工具也可能把事情做坏。
所以我现在搭 Agent，会先问：它要接住哪一件事？需要读哪些资料？允许调用什么？会改动什么？结果怎样验证？失败以后怎样退回？
等这些问题有了答案，再选择模型、平台、MCP 或脚本。选择会容易很多，因为工具要解决什么已经清楚了。
四、
我自己的内容生产系统，也是在这个过程中慢慢形成的。
这套目录本身还不等于 Agent。只有当任务能够找到相关材料、识别它们的状态、按流程生成产物，并在每个阶段停下来检查时，目录才开始变成可以运行的工作系统。
Agent 的知识库也不是把文件全部塞进去。它要知道这次该读什么，哪些内容可以公开，哪些只是内部记录，哪个版本更新，发生冲突时以什么为准。
上下文也需要交接。一次对话结束后，下一次运行要知道已经做了什么、确认了什么、还缺什么、哪些坑不要再踩。否则每次换一个窗口，系统就失忆一次。
我更愿意把这些内容保存在自己能看到、能修改的文件里。这样模型变了，之前的工作不会跟着消失。新的 Agent 也可以从这些文件继续。
搭建 Agent 时，还有一个容易漏掉的问题：怎么算做完？
“帮我整理好”“写得完整一点”“检查一下有没有问题”，这些说法对人已经有歧义，对 Agent 更是如此。
完成标准要能被检查。
整理资料，可以检查文件是否归到约定目录，原文是否保留，链接是否还能追溯。写文章，可以检查标题是否一致，引用是否有来源，平台稿是否漏段，图片是否对应正文。处理重复文件，可以检查哈希、隔离记录和恢复路径。
标准不一定一开始就很全。先把最小的一条完整路径跑通，看看它在哪里停住，哪里误解，哪里需要人补判断。每跑一次，就把新的条件写回流程。
一个流程能跑通一次，只能说明这一次完成了。换一批输入还能工作，出现异常知道停下来，才说明它开始具备重复使用的条件。
五、
Agent 可以替人执行一部分步骤，责任没有跟着转移。
读取资料、整理草稿、生成候选结果，可以先放在低风险范围里。涉及删除、付款、发送、发布、客户资料和外部系统写入，需要更小的权限和明确的确认点。
我会优先让动作可恢复。能先生成草稿，就不直接发布。能先移动到隔离区，就不直接删除。能只读检查，就不先开放写入。需要对外代表我的内容，要留给我确认。
这不是为了让流程变慢。它是在说明：Agent 可以做到哪里，人要在哪一步接手。
bad case 也要留下来。它漏了哪篇材料，误用了哪个版本，把谁的经历写成了我的经历，或者生成了一个看起来齐全、实际无法验收的结果。问题写下来，才可能变成下一次运行的规则。
如果每次出错都只在对话里提醒一句，下一次还会再错。
并不是每一件事现在都适合做成 Agent。
一件只做一次、目标还在变化、结果无法检查的事，先由人做几遍可能更合适。人在做的过程中，会发现实际输入是什么，哪些判断可以写下来，哪些部分每次都不同。
如果你自己还不知道怎样完成这件事，Agent 也很难替你补出一套可靠的方法。它可以给候选方案，但不能替你确认哪套方法属于你的工作。
所以我建议从熟悉的事开始。它可以很小：每天整理一组资料，检查一篇文章，把会议对话整理成交接单，或者处理一类反复出现的文件。
六、
先选一件最近反复做过的事。
把它需要的材料放到一个你能管理的位置。写下输入、步骤、工具、输出和完成标准。标出哪些动作可以自动执行，哪些地方必须停下来问你。再让 Agent 跑一遍。
第一次运行时，不要急着继续加工具。先看结果为什么对，为什么不对。缺的是材料，就补材料；缺的是判断，就把判断写下来；完成标准太含糊，就改成能检查的条件；权限太大，就把范围收回来。
它不会因为写完一段提示词就完成。
它会跟着你的工作继续变化。
本文是对公开笔记的知识化整理；原帖中的收入、流量、效果等数据属于原帖陈述，未作独立验证。