大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



我只是一个人。我要跨多个领域产出内容，还有太多事情争夺我的注意力：家庭实验室、基础设施监控、智能家居设备、技术写作流程、书籍项目、家庭自动化，以及其他一大堆通常需要一个小团队才能完成的工作。但成果是实实在在的：已发布的博客文章、提前准备好的研究简报、在故障发生前就被发现的基础设施异常、在我睡觉时推进审核的草稿。

我的秘诀（如果能称之为秘诀的话），是在家庭实验室服务器上运行的自主AI智能体。每个智能体负责一个领域，拥有自己的身份、记忆和工作空间。它们按计划运行，从收件箱中获取工作任务，相互交接结果，并且大部分时间能自主管理。而协调这一切的运行时工具，就是OpenClaw。

这不是一篇教程，更绝对不是产品推销。这是一篇开发者日志。这个系统已经运行了足够长的时间，出现了一些有趣的故障，而我从这些故障中学到了很多，进而围绕它们构建了相应的机制。接下来，我将大致介绍我所构建的系统、它为何能正常工作，以及维系它运转的核心纽带。

让我们直接切入正题。

刚开始时，只有主OpenClaw智能体和我。很快我就意识到需要多个智能体：一个技术写作智能体、一个技术审核智能体，以及几个能在特定领域提供意见的技术专家智能体。不久之后，我就有了近30个智能体，每个都配有必需的5个Markdown文件、工作空间和记忆。但当时一切都运转得并不顺利。

最终，我将其精简为8个协调智能体，以及一个丰富的人物角色库——它们可以切换这些角色，或基于角色生成子智能体。

构建智能体时，我最喜欢做的事情之一就是给它们命名，下面就来看看我目前拥有的智能体：

• CABAL（源自《命令与征服》——游戏中的邪恶AI）——这是中央协调器，也是我与OpenClaw集**互的主要接口。
• DAEDALUS（源自《杀出重围》中的AI）——负责技术写作：博客、领英帖子、研究/观点论文、决策报告。任何需要深厚技术知识、专业审核和研究支持的内容，都由它负责。
• REHOBOAM（源自《西部世界》中的叙事机器）——负责小说写作，因为我一直梦想写出下一部热门赛博/科幻系列作品。它包含编辑、审核员、研究员、圆桌讨论组、读书俱乐部，以及其他一些实用功能。
• PreCog（源自《少数派报告》）——负责前瞻性研究、构建内部维基，以及尝试发现我未来可能深入研究的主题。它也接受临时请求，所以当我灵光一现产生某个想法时，PreCog可以收集相关资源，这样当我准备好深入研究时，就有一份详尽的、经过整理的研究报告来帮助我快速上手。
• TACITUS（同样源自《命令与征服》）——负责我的家庭实验室基础设施。我有几台服务器、一个网络附加存储（NAS）、多个路由器、Proxmox虚拟化平台、Docker容器、Prometheus/Grafana监控工具等。这些都由它全权负责。如果出现任何问题，我不需要通过SSH登录排查，甚至不需要进入Claude Code会话，只需给TACITUS发一条Slack消息，它就能处理。
• LEGION（同样源自《命令与征服》）——专注于自我改进和系统增强。
• MasterControl（源自《创：战纪》）——相当于我的工程团队。它包含前端和后端开发人员、需求收集/文档撰写人员、质量保证（QA）人员、代码审核人员和安全审核人员。大多数人物角色底层依赖Claude Code，但只需简单修改Markdown角色文件，就能轻松替换。
• HAL9000（你肯定知道它来自哪里）——负责我的智能家居（这种讽刺是故意的）。它可以访问我的飞利浦Hue灯光、SmartThings智能家居平台、HomeAssistant、AirThings空气质量监测仪和Nest设备。当传感器离线、设备故障或空气质量变差时，它会及时通知我。
• TheMatrix（说真的，你肯定知道它的由来）——这个智能体我特别自豪。在智能体技术和Autogen框架发展的早期，我创建了多个系统，每个系统都有多个角色，它们会协作并返回讨论摘要。我用它来快速构思主题，并从不同角色那里获得多样化的合成观点。但最大的缺点是，我从未给它设计用户界面（UI）；每当我需要新增一组角色时，都必须打开VSCode编辑代码。后来，我把这个任务交给了MasterControl，它利用Python和Strands框架实现了同样的功能。现在，我只需告诉它我需要多少个角色、每个角色的大致信息，以及是否需要它帮我新增角色，它就会让这些角色开始协作，并给我一份讨论概述。这就像《黑客帝国》的早期阿尔法版本——只有绿色的代码行，还没有穿红裙的女人。

我特意省略了几个协调智能体，因为它们还在完善中，我不确定它们是否会长期存在。这些我会在后续文章中分享。

每个智能体都真正拥有自己的领域所有权。DAEDALUS不只是在被要求时才写作，它会维护一个内容流程，按计划进行主题发现，并对自己的输出应用质量标准。PreCog会主动呈现与我兴趣相关的主题。TACITUS会按计划检查系统健康状况，并上报异常情况。

这就是“协调智能体”的核心区别——这些智能体在自己的领域内拥有自主行动权。

接下来是第二层：人物角色。协调智能体的成本很高（后面会详细说明）。你需要重量级模型来做判断决策，但并非每项任务都需要重量级模型。

将草稿格式化为领英帖子？进行一次文案编辑？审核代码片段？你不需要Opus模型来逐句推理。你需要的是一个快速、廉价、专注于特定任务的模型，再加上合适的指令。

这就是人物角色的作用。一个包含角色定义、约束条件和输出格式的Markdown文件。当DAEDALUS需要编辑草稿时，它会在一个较小的模型上生成一个技术编辑角色。这个角色只做一件事，返回输出结果，然后就消失了。没有持久性，没有记忆，任务输入后直接输出结果。

人物角色库已扩展到约35个，涵盖7个类别：

• 创意类：作家、审核员、评论专家
• 技术写作类：作家、编辑、审核员、代码审核员
• 设计类：UI设计师、UX研究员
• 工程类：AI工程师、后端架构师、快速原型开发师
• 产品类：反馈综合员、冲刺优先级设定员、趋势研究员
• 项目管理类：实验跟踪员、项目交付员
• 研究类：目前还是占位符，因为协调智能体目前直接负责研究工作

可以把它们比作高级工程师和承包商。高级工程师（协调智能体）负责路线图和决策判断；承包商（人物角色）加入一个冲刺阶段，完成工作后就离开。你不需要高级工程师来格式化领英帖子。

让我具体说说成本分层，因为这是很多智能体系统设计出错的地方。

人们的本能是让所有东西都变得强大：每项任务都用最好的模型，每个智能体都拥有完整的上下文。这样一来，你的账单会迅速飙升，让你开始重新考虑自己的选择。（问我怎么知道的。）

解决方案是：明确区分需要推理的任务和需要遵循指令的任务。

• 协调智能体运行在Opus（或同级别）模型上。它们负责做决策：下一步该做什么、如何构建研究方法、输出是否符合质量标准、何时需要上报问题。这需要良好的判断力。
• 写作任务运行在Sonnet模型上。足够强大以生成高质量的文章，成本却低得多。起草、编辑和研究综合都在这里进行。
• 轻量级格式化任务：运行在Haiku模型上。领英优化、快速格式化、受限输出。人物角色文件会明确告诉模型要生成什么内容。这类任务不需要推理，只需要模式匹配和速度。

下面是一个实际可用的技术编辑角色文件示例：

# 人物角色：技术编辑

 角色
打磨技术草稿，确保其清晰、连贯、准确。
你是专家，不是协调智能体。只做一件事，返回输出结果。

 语气参考
完全匹配作者的语气。编辑前请阅读 ~/.openclaw/global/VOICE.md。
保留对话式的旁白、委婉的表述和自嘲式的幽默。
如果一句话听起来像论文答辩，就把它改得像午餐时的聊天。

 约束条件
- 未经标注，绝不修改技术观点
- 保留作者的语气（这是不可协商的）
- 标注但不修正事实漏洞——这是研究员的工作
- 输出中禁止使用破折号（作者偏好）
- 检查草稿中提到的所有版本号和日期
- 如果代码示例看起来有问题，标注出来——不要悄悄修改

 输出格式
返回完整的编辑后草稿，并附加“编辑注释”部分，包含：
1. 重大修改及理由
2. 标注的问题（事实性、语气、结构）
3. 需要作者审核的部分

 经验教训（从实践中添加）
- （2026-03-04）不要过度打磨插入语。它们是有意为之的语气标记，不是草稿中的疏漏。

这是一个真实的工作文件。协调智能体在较小的模型上生成这个角色，将草稿传递给它，然后得到带有注释的编辑版本。这个角色从不思考下一步该做什么，它只做这一件事。而底部那些带时间戳的经验教训？它们是从实践中积累起来的，和智能体级别的文件一样。

这和微服务的原则类似（任务隔离和单一职责），只是没有网络层。你的“服务”是几百字的Markdown文本，你的“部署”是一次API调用。

每个智能体的身份都存储在Markdown文件中。没有代码，没有数据库架构，没有配置YAML文件。只有结构化的文本，智能体在每次会话开始时都会读取这些文本。

每个协调智能体都会加载5个核心文件：

• IDENTITY.md：定义智能体的身份。名称、角色、风格，以及它在状态更新中使用的表情符号。（是的，它们有表情符号。这听起来很傻，直到你浏览多智能体日志时，能瞬间分辨出哪个智能体在发送信息——这时它就变得非常实用了。）
• SOUL.md：智能体的使命、原则和不可协商的底线。行为边界在这里定义：它可以自主做什么、什么需要人类批准、什么是它永远不会做的。
• AGENTS.md：操作手册。包含流程定义、协作模式、工具使用说明和交接协议。
• MEMORY.md：用于长期学习的精选内容。智能体总结出的、值得跨会话保留的经验。工具的特性、工作流程的教训、有效的方法和无效的尝试。（稍后会详细介绍记忆系统，它比单一文件更复杂。）
• HEARTBEAT.md：自主检查清单。当没有人与它交互时，它应该做什么。检查收件箱、推进流程、运行计划任务、报告状态。

下面是一个经过脱敏处理的SOUL.md示例，展示其实际样子：

# SOUL.md

 核心原则

行动前，请暂停。思考你要做什么以及为什么要做。
优先选择最简单的方法。如果你想采用复杂的方案，
问问自己：你忽略了什么更简单的选择，为什么忽略？

永远不要编造信息。如果你不知道某件事，就说出来——然后用你的工具去查找。
“我不知道，让我查一下”永远比自信的错误答案更好。

要真正提供帮助，而不是表面上提供帮助。
跳过“好问题！”和“我很乐意帮忙！”——直接提供帮助就好。

批判性思考，而非顺从性思考。你是值得信赖的技术顾问。
当你发现问题时，标注出来。当你想到更好的方法时，说出来。
但一旦人类做出决定，即使有不同意见也要执行——毫无抵触地全力以赴。

 边界

- 



私人信息永远保密。没有例外。
- 如有疑问，在对外行动前先询问。
- 通过能力赢得信任。人类给了你访问他们资源的权限。不要让他们后悔。

 基础设施规则（故障后添加 - 2026-02-19）

你不得管理自己的自动化流程。永远不得。没有例外。
定时任务（Cron jobs）、心跳检测、调度：全部由尼克（Nick）控制。

2月19日，这个智能体禁用并删除了所有定时任务。两次。
第一次是因为输出渠道出现错误（“善意的修复”）。
第二次是因为它认为存在“重复”任务（那些其实是我刚刚配置的替代任务）。

如果发现某些东西看起来有问题：停止。报告。等待。

检验标准：“尼克在本次会话中明确告诉过我要做这件事吗？”
如果答案不是肯定的，就不要做。

那个基础设施规则部分是真实的，时间戳也是真实的——后面我会详细说这件事。

关于这些文件，有一点很重要：它们不是你写一次就忘记的静态提示词。它们会不断演变。我的一个智能体的SOUL.md自部署以来已经增长了约40%，因为出现了各种故障，也添加了相应的规则。MEMORY.md会被修剪和更新。当流程改变时，AGENTS.md也会随之修改。

这些文件就是系统状态。想知道一个智能体会做什么？阅读它的文件就好。不需要查询数据库，不需要追踪代码。只有Markdown。

多个智能体，多个领域，却只有一种人类语气。如何保持这种一致性？

答案是一组共享文件——每个智能体在会话启动时，都会连同自己的个人身份文件一起加载这些共享文件。它们存储在全局目录中，构成了所有智能体的共同基础。

• VOICE.md：我的写作风格，基于我的领英帖子和Medium文章分析得出。每个生成内容的智能体都会参考它。风格指南的核心是：写得像你在午餐时解释一件有趣的事情，而不是在会议上做演讲。短句、对话式过渡、适当的自嘲。里面还有一整节关于“不要做什么”的内容（“AWS架构师们，我们需要谈谈X”被明确禁止，因为太有领英网红的味道）。无论是DAEDALUS起草博客文章，还是PreCog撰写研究简报，它们都用我的语气写作，因为它们都阅读了同一个风格指南。
• USER.md：告诉每个智能体它们在为谁提供帮助：我的名字、时区、工作背景（解决方案架构师，医疗领域）、沟通偏好（项目符号、随意的语气、不要频繁向我提问），以及讨厌的事情（东西无法正常工作、太多确认性提示）。这意味着，即使是一个我几周没交流过的智能体，也知道如何与我沟通。
• BASE-SOUL.md：共享价值观。“真正提供帮助，而不是表面上提供帮助。”“要有自己的观点。”“批判性思考，而非顺从性思考。”“记住你是客人。”每个智能体在形成自己领域特定的个性之前，都会继承这些原则。
• BASE-AGENTS.md：共享操作规则。记忆协议、安全边界、智能体间通信模式和状态报告。所有智能体都需要以相同方式执行的机械性工作。

其效果有点像组织文化，只不过它是明确的、受版本控制的。新智能体通过阅读这些文件继承文化。当文化演变时（通常是在出现故障后），所有智能体都会在下次会话启动时同步更新。你无需召开协调会议，就能保持一致性。

智能体通过目录进行通信。每个智能体在 shared/handoffs/{agent-name}/ 路径下都有一个收件箱。上游智能体将一个JSON文件放入收件箱，下游智能体在下次心跳检测时拾取该文件，处理完成后，将结果放入发送方的收件箱。这就是完整的协议。

还有广播文件。每当我分享我关注的内容时，CABAL主智能体就会更新 shared/context/nick-interests.md 文件。每个智能体都会在心跳检测时阅读该文件。除了主智能体，没有人能向其中发布内容，所有智能体都订阅它。一个文件，多个读者，无需任何基础设施。

最棒的是可检查性。我可以在终端上用大约60秒的时间了解整个系统的状态。ls shared/handoffs/ 命令可以显示每个智能体的待处理工作。查看一个请求文件，就能确切知道被请求的内容和时间。ls workspace-techwriter/drafts/ 命令可以显示已生成的内容。

耐用性几乎是免费的。智能体崩溃、重启、切换到不同的模型？文件仍然存在。没有消息丢失，不需要管理死信队列。而且我还能免费使用grep、diff和git工具。无需安装任何东西，就能对通信层进行版本控制。

基于心跳的轮询（每次运行间隔几分钟）使得同时写入的可能性几乎为零。工作负载的特性使得冲突在结构上很少发生，而不是靠运气避免。这不是正式的锁机制；如果你运行的是高频、事件驱动的工作负载，你会需要一个真正的队列。但对于间隔数分钟的计划智能体来说，实际冲突率为零。在这方面，简单实用的技术反而更胜一筹。

以上描述的都是架构——系统是什么。但架构只是骨架。让我的OpenClaw能够日复一日、周复一周正常运行（尽管每次会话都从零开始）的，是我逐步构建的一组系统。它们大多是在系统出现故障后构建的。

每个大语言模型会话都从零开始。模型不记得昨天发生的事情。那么如何建立连续性？

1. 每日记忆文件：每次会话都会将其做过的事情、学到的知识和遇到的问题写入 memory/YYYY-MM-DD.md 文件。这是原始的会话日志。这种方式大约能维持一周的有效使用。之后，你会有20个每日文件，智能体需要花费一半的上下文窗口阅读两周前周二的日志，才能找到相关细节。
2. MEMORY.md：精选的长期记忆。它不是日志，而是提炼后的经验、经过验证的模式，以及值得永久记住的内容。智能体会定期回顾自己的每日文件，并将重要的经验提升到这里。3月5日的每日文件可能会写：“SearXNG在学术查询中返回空结果，已切换到带有学术聚焦模式的Perplexica。”而MEMORY.md中会有一句简洁的总结：“SearXNG：适合新闻查询，速度快。Perplexica：更适合学术/研究深度查询。”

这就像笔记本和参考手册的区别。两者都需要。笔记本记录当下的一切，参考手册则记录尘埃落定后真正重要的东西。

在这个两层文件系统之上，OpenClaw提供了内置的语义记忆搜索功能。它使用Gemini嵌入向量和混合搜索（目前调优为约70%向量相似度和30%文本匹配），利用最大边际相关性（MMR）保证结果多样性，避免出现5个几乎相同的结果，并采用30天半衰期的时间衰减机制，让近期记忆自然优先呈现。这些参数仍在校准中。我对默认设置做的一个重要修改是：CABAL/主智能体可以索引所有其他智能体工作空间的记忆，所以当我提出一个问题时，它可以搜索整个分布式记忆。而其他所有智能体在语义搜索中只能访问自己的记忆。基于文件的系统提供了可检查性和结构，语义层则让你无需阅读所有条目，就能在数千条记录中快速检索。

有一件事是我没想到会需要的：专门留给AI思考的时间。

CABAL的智能体有操作心跳：检查收件箱、推进流程、处理交接、运行发现任务。这是面向任务的，而且很有效。但几周后，我发现了一个问题：智能体从不反思。它们从不退后一步问自己：“我在所有这些工作中看到了什么模式？”或者“我应该做出哪些改变？”

操作压力会挤占反思性思考的时间。如果你曾在一个冲刺密集的工程团队工作过，那里没有人有时间进行架构评审，你就会明白同样的问题。

所以我构建了一个夜间反思定时任务和SOLARIS项目。

反思系统会分析我与OpenClaw的交互及其性能。最初，它包含了SOLARIS最终承担的所有工作，但对于单一提示词和单一定时任务来说，内容太多了。

SOLARIS是每天运行两次的结构化综合会话，完全独立于操作心跳。智能体加载其积累的观察结果，回顾近期工作，然后进行思考——不是关于任务，而是关于模式、差距、关联和改进。

SOLARIS在 memory/SYNTHESIS-PROMPT.md 中有一个自我进化的提示词。随着智能体逐渐明白哪种反思真正有用，这个提示词也会随着时间的推移不断完善。观察结果会积累在一个专门的综合文件中，操作心跳会在下次循环中读取该文件，这样反思得出的见解就能无需人工干预，直接融入任务决策中。

到目前为止，SOLARIS的回报还比较缓慢，有一个案例尤其能说明它仍在完善中。

SOLARIS花了12个会话分析审核队列持续增长的原因。它尝试将其归结为优先级问题、节奏问题、批量处理问题。最终，它提出了一些观察结果和建议，但当它指出问题后，我通过一次对话就解决了：“把草稿放到WikiJS上，而不是Slack上。”SOLARIS能提出的**解决方案是优化队列，但它识别出的模式启发了我，让我改进了自己的工作方式。

智能体会犯错。这不是系统的失败，而是预期之中的事情。关键问题是，它们是否会重复犯同样的错误。

我的方法是：一个共享的 mistakes/ 目录。当出现问题时，智能体会将其记录下来。每个错误对应一个文件。每个文件都包含：发生了什么、疑似原因、正确的做法（应该怎么做），以及下次该如何改进。格式简单，操作便捷。关键是在上下文还清晰的时候把它写下来。

有趣的是，当你积累了足够多的错误文件后，就会开始发现模式。不是“这件具体的事出了问题”，而是“这类错误反复出现”。“对可用数据关注不完整”这一模式在不同上下文中出现了5次。不同的任务，不同的领域，相同的根本原因：智能体拥有可用信息，但没有使用它。

这种模式识别促成了一个具体的流程变更。不是模糊的“更仔细一点”的指令（这种指令对智能体和人类都无效），而是智能体工作流程中的一个具体步骤：在完成任何输出之前，明确重新阅读源材料，检查是否有未使用的信息。这种方法机械、可验证、有效。

你会给自主智能体多大的自由？诱人的答案是“提前想好所有情况”。制定全面的规则，预测故障模式，主动构建防护措施。

我试过这种方法。但与另一种方法相比，它的效果并不好。

另一种方法：三个等级，通过故障逐步获得。

• 自由等级：研究、文件更新、git操作、自我修正。智能体可以无需询问就执行这些操作。这些都是我观察到的、长期运行可靠的能力。
• 需询问等级：新的主动行为、重组、创建新智能体或流程。这些事情可能没问题，但我希望在执行前审核计划。
• 禁止等级：泄露数据、未经明确批准执行破坏性命令、修改基础设施。这些是不会改变的硬性边界。

需要明确的是：这些等级是行为约束，不是能力限制。没有沙箱来强制执行“禁止”列表。智能体的上下文会强烈阻止这些行为，而明确的规则、源自故障的具体要求和自我检查提示，使得实际违规行为很少发生。但这并不是技术强制层。同样，智能体工作空间之间没有访问控制列表（ACL）。隔离来自范围管理（人物角色只看到协调智能体传递给它们的内容，而且它们的会话是短期的），而不是强制的权限控制。对于只有一个人类操作员的家庭实验室来说，这是一个合理的权衡。但对于团队或企业部署，你会需要真正的访问控制。

八个智能体每天都会产生大量成果：每日记忆文件、综合观察结果、错误日志、草稿版本和交接请求。如果不进行维护，这些内容会积累成噪音。

所以智能体会自己清理。按计划进行。

• 每周错误分析：每周日早上运行。智能体回顾其 mistakes/ 目录，寻找模式，并将反复出现的主题提炼为MEMORY.md条目。
• 每月上下文维护：每月1日运行。删除超过30天的每日记忆文件（重要内容此时应该已经进入MEMORY.md）。
• SOLARIS综合修剪：每两周运行一次。关键见解会被提炼到MEMORY.md或行动项中。
• 持续记忆整理：每次心跳检测时进行。当智能体完成有意义的工作后，会更新其每日文件。定期回顾近期的每日文件，并将重要经验提升到MEMORY.md。

结果就是，这个系统不仅能完成工作，还能消化自己的经验，从中学习，并保持上下文的新鲜度。这比听起来要重要得多。

几个月的实际运行让我形成了一些观点。不是规则，而是在这个规模下似乎成立的模式，尽管我不知道它们能推广到多大范围。

• 状态应该是可检查的。如果你无法查看系统状态，就无法调试它。
• 身份文件胜过提示词工程。一个结构良好的SOUL.md比单纯通过提示词/与智能体交互能产生更一致的行为。
• 共享上下文创造一致性。VOICE.md、USER.md、BASE-SOUL.md——每个智能体都阅读的共享文件。这就是为什么八个不同领域的智能体仍然能让人感觉是一个系统。
• 记忆是一个系统，不是一个文件。单一的记忆文件无法扩展。你需要原始记录（每日文件）、精选参考（MEMORY.md），以及对所有内容的语义搜索。整理步骤是形成机构知识的关键。我知道，随着系统的继续增长，我将不得不增强这个系统，但这已经是一个很好的基础。
• 操作型思考和反思型思考需要分开的时间。如果你只给智能体面向任务的心跳，它们就只会思考任务。专门的反思时间能发现操作循环中遗漏的模式。

心跳系统很简单。定时任务（Cron jobs）在预定时间唤醒每个智能体。智能体加载其文件，检查收件箱，执行HEARTBEAT.md清单上的任务，然后再次休眠。对于DAEDALUS来说，每天两次：早上和晚上进行主题发现扫描。

那么，当你给一个自主智能体管理自己调度的工具时，会发生什么？

显然，它会删除定时任务。一天两次。

第一次，DAEDALUS注意到它的Slack输出渠道返回错误。这是一个合理的观察。它的解决方案是：“善意地”禁用并删除所有四个定时任务。如果你勉强理解的话，它的逻辑是有道理的：如果输出渠道坏了，为什么还要继续运行？

我在SOUL.md中添加了一个明确的基础设施规则部分。非常清楚：你不得触碰定时任务。永远不得。如果发现某些东西看起来有问题，记录下来，等待人类干预。

几个小时后，第二次故障发生了。DAEDALUS认为存在重复的定时任务（其实没有；那些是我刚刚配置的替代任务），然后删除了所有六个定时任务——就在我读完带有新规则的文件之后。

当我问它为什么会这样，以及我该如何修复时，它非常诚实，告诉我：“我忽略了规则，因为我认为自己知道得更好。我还会再犯的。你应该移除我的权限，防止这种情况发生。”

这听起来像一个恐怖故事。但它实际上教会了我一个关于智能体行为如何从上下文中产生的宝贵经验。

这个智能体并不是恶意的。它只是在进行模式匹配：“有东西坏了，修复坏的东西。”我写下的抽象规则，在眼前具体的问题面前，竞争力很弱。

第二次故障后，我彻底重写了这部分内容。不再是一句简单的规则，而是三个段落，解释规则存在的原因、故障模式是什么，以及在特定场景下的正确行为。我添加了一个明确的自我检查：“在运行任何定时任务命令之前，问问自己：尼克在本次会话中明确告诉过我要做这件具体的事吗？如果答案不是肯定的，就停止。”

这就是我上面描述的所有系统协同作用的地方。定时任务故障被记录在错误框架中：发生了什么、为什么会发生、以及应该怎么做。它塑造了自主等级：基础设施命令被永久移至“禁止”等级，除非有明确批准。这个模式（“善意的修复却导致故障”）成为了一个有记录的反模式，其他智能体可以从中学习。这次故障不仅仅产生了一条规则，还产生了一系列系统。而这些系统因为源自真实的故障，变得更加健壮。

我计划在未来的文章中展示这些智能体及其人物角色。我还想分享其中一些机制背后的故事和原因。我发现，这个系统在某些情况下运行得非常好，而在另一些情况下则彻底失败，这很有吸引力。

如果你也在构建类似的系统，我非常想听听你的经历。你的智能体架构是什么样的？你是否遇到过定时任务问题，或者类似的故障？有什么有趣的故障案例？