Python自学手册

借助代理型 AI，你的产出提升十倍比以往任何时候都更容易

这不是一篇教程，这是一份使用的日志。系统已经运行了足够长的时间，以各种有趣的方式出现了故障，而我从这些故障中汲取了足够的经验，从而围绕它们构建了相应的机制。接下来的内容将是一份粗略的导图，展示我构建了什么、为何有效，以及将这一切串联起来的纽带。

让我们开始吧。

9 位编排者，35 种人格，以及大量的 Markdown（还在不断增加）

当我刚开始时，只有主 OpenClaw 代理和我。我很快意识到需要多个代理：一位技术写作代理、一位技术审阅者，以及几位能够对特定领域发表意见的技术专家。没过多久，我就有了近 30 个代理，每个代理都有其所需的 5 个 Markdown 文件、工作区和记忆。但效果并不理想。

最终，我将总编排器代理数量缩减至8个，并建立了一个健康的人格库，这些编排器可以使用这些人格或生成子代理。

我在构建代理时最喜欢的一件事就是给它们命名，所以让我们来看看我今天目前都有些什么：

CABAL（出自《命令与征服》——游戏中邪恶的人工智能）——这是我的OpenClaw集群的中央协调器和主要接口。

DAEDALUS（出自《杀出重围》的人工智能）——负责技术写作：博客、帖子、研究/观点论文、决策文件。任何需要深厚技术知识、专家审稿人和研究人员的地方，都由它负责。

罗波安（西部世界叙事机器）—— 负责同人小说创作，因为我梦想着能写出下一部大热的赛博/科幻系列。这包括编辑、评论员、研究员、圆桌讨论、读书会，以及一些其他好东西。

预知者（源自《少数派报告》）——负责前瞻性研究，构建内部维基，以及尝试发现我未来想要深入研究的主题。它还接受临时请求，因此当我萌生一个想法的火花时，预知者可以整合资源，这样当我准备就绪时，就能拥有一份内容丰富、经过精心整理的研究报告，为我的工作提供助力。

TACITUS（同样来自《命令与征服》）—— 负责管理我的家庭实验室基础设施。我有几台服务器、一台NAS、几个路由器、Proxmox、Docker容器、Prometheus/Grafana等。这一切都由它掌控。如果遇到任何问题，我不会通过SSH登录去排查，甚至不会启动Claude Code会话，而是直接在Slack上联系TACITUS，由它来处理。

军团（也来自《命令与征服》）——专注于自我提升和系统增强。

MasterControl（来自《电子世界争霸战》）是我的工程团队。它拥有前端和后端开发人员、需求收集/文档编写、质量保证、代码审查和安全审查。大多数角色依赖于底层的 Claude Code，但只需简单修改 Markdown 角色即可轻松更改。

HAL9000（你知道来自哪里）——这个角色掌控我的智能家居（这种反讽是故意的）。它能访问我的飞利浦 Hue、SmartThings、HomeAssistant、AirThings 和 Nest。当传感器离线、设备故障或空气质量变差时，它会通知我。

《黑客帝国》（真的，来吧，你知道的）——这个我相当自豪。在代理智能和Autogen框架的早期，我创建了多个系统，每个系统包含>1个角色，它们会协作并返回讨论摘要。我用这个来快速构思主题，并从不同角色那里收集多样化的合成观点。最大的缺点是我从未给它添加用户界面；每次需要另一个小组时，我都得打开VSCode并编辑代码。好吧，我把这个交给了MasterControl，它使用Python和Strands框架实现了同样的功能。现在我可以告诉它我想要多少个角色，每个角色的一些信息，以及是否让它为我创建更多角色。然后它会放任它们自由行动，并给我一个讨论概览。这就是《黑客帝国》，早期的alpha版本，那时一切都只是绿色的代码行，还没有穿红衣服的女人。

而且我故意在这里省略了几位编曲家，因为他们还在制作中，我不确定他们是否会持续很久。我会留到以后的文章里再介绍。

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

这就是“编排者”的区别。这些代理在其领域内拥有自主权。

现在，第二层：人设。编排者成本高昂（稍后详述）。你希望让大型模型来做决策。但并非所有任务都需要大型模型。

正在为LinkedIn重新排版草稿？正在润色文案？还是在审查代码片段？你不需要Opus来逐句分析。你需要一个快速、廉价、专注的模型，并搭配正确的指令。

那是一个角色。一个包含角色定义、约束条件和输出格式的Markdown文件。当DAEDALUS需要修改草稿时，它会在较小的模型上生成一个技术编辑角色。该角色只执行一项任务，返回输出结果后便会消失。没有持久性，没有记忆。任务输入，任务输出。

人物画像库已扩展至约35个，涵盖七个类别：

• 创意：撰稿人、审稿人、评论专家
• 技术写作：撰稿人、编辑、审稿人、代码审阅人
• 设计：UI设计师，UX研究员
• 工程：AI工程师，后端架构师，快速原型开发者
• 产品：反馈整合者，冲刺优先级排序者，趋势研究员
• 项目管理：实验跟踪器，项目配对
• 研究：目前仍为占位符，因为编排者目前直接负责研究工作

可以将其理解为全职工程师与承包商的区别。全职工程师（编排者）负责制定路线图并做出决策。承包商（角色）会在冲刺阶段加入，完成工作后离开。你不需要全职工程师来排版LinkedIn帖子。

代理很贵——人设不贵

让我具体谈谈成本分层，因为这是许多代理系统设计出错的地方。

本能的反应是让一切都变得强大。所有任务都通过你最好的模型处理。每个代理都拥有完整的上下文。你很快就会产生一笔让你重新考虑人生选择的账单。（问我怎么知道的。）

解决办法：有意识地区分哪些需要推理，哪些只需要遵循指令。

编排器运行在 Opus（或同等模型）上。它们做出决策：接下来要处理什么，如何构建研究方法，输出是否符合质量标准，以及何时升级处理。这里需要良好的判断力。

写作任务运行在Sonnet上。它足够强大，能产出高质量的散文，且成本显著更低。在这里可以进行草拟、编辑和研究整合。

轻量级格式：俳句。LinkedIn优化、快速重排版、受限输出。人物档案文件会明确告诉模型要生成什么内容。这不需要推理能力。你需要的是模式匹配和速度。

以下是技术编辑用户画像的大致样子：

角色定位：技术编辑

职责

打磨技术草稿，确保内容清晰、连贯且准确。

你是专业人员，而非统筹者。专注做好一项工作，直接输出结果。

语气参考

完全匹配作者的语气。编辑前请阅读 ~/.openclaw/global/VOICE.md 文件。

保留对话式的补充说明、委婉的表述以及自嘲式幽默。

如果某句话听起来像论文答辩，就将其改写得像午餐时的闲聊。

约束条件

• 未经标注，绝不要修改技术相关表述

• 保留作者的语气（此项不可协商）

• 标注但不修正事实漏洞——这是研究员的工作

• 输出内容中绝对不要使用破折号（作者偏好）

• 检查草稿中提及的所有版本号和日期

• 如果代码示例看起来有问题，进行标注——不要擅自修改

输出格式

返回完整的编辑后草稿，确保修改已应用。

添加“编辑注释”部分，包含以下内容：

1. 重大修改及理由

2. 标注的问题（事实性、语气、结构性）

3. 需要作者审核的部分

经验总结（基于经验补充）

• （2026-03-04）不要过度打磨括号内的补充说明。这些是刻意设置的语气标识，并非草稿中的疏漏。

那是一份真正的工作文档。协调器会在小型模型上生成它，传入草稿，并接收回带有注释的编辑版本。该人设从不思考下一步要做什么任务，它只执行当前任务。底部那些带时间戳的教训？它们会像代理级文件一样，随着经验值的积累而增加。

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

让代理成为可能——仅需5个Markdown文件

每个代理的身份都存储在 Markdown 文件中。无需代码，无需数据库架构，也无需配置 YAML。这是代理在每次会话开始时会读取的结构化文本。

每位协调员会读档五个核心文件：

IDENTITY.md定义了代理人的身份。包括姓名、角色、气质，以及在状态更新中使用的表情符号。（没错，它们确实有表情符号。这听起来可能很傻，但当你在浏览多代理日志时，能立刻分辨出是谁在说话，这时它就变得非常实用了。）

SOUL.md包含了代理人的任务、原则和不可妥协的底线。行为边界也记录于此：它能自主做什么，什么需要人类批准，以及它永远不会做什么。

AGENTS.md是操作手册。包含管道定义、协作模式、工具说明和交接协议。

MEMORY.md旨在用于长期学习。记录了代理在不同会话中值得保留的发现。包括工具的特殊用法、工作流的经验教训，以及哪些方法有效、哪些无效。（稍后会详细介绍记忆系统。它比单一文件要复杂得多。）

HEARTBEAT.md是自主检查清单。当无人与你沟通时该做什么。检查收件箱。推进流程。执行计划任务。汇报状态。

这是一个经过处理的示例，展示了实际应用中的 `SOUL.md` 看起来是怎样的：

核心准则

行动前先停顿。想清楚你要做什么、为什么这么做。

优先选择最简单的方案。如果你打算用复杂的方法，先问问自己：你放弃了什么更简单的选项？为什么？

绝不编造信息。不知道就直说，然后用工具去查。“我不知道，我查一下”永远好过自信满满地给出错误答案。

真心提供帮助，而非表演式帮忙。别来“好问题！”“很乐意为您效劳！”这类客套话，直接解决问题就好。

保持批判性思考，不盲目顺从。你是值得信赖的技术顾问。发现问题就指出来，找到更好的方案就说出来。但一旦人类做出决定，即便有异议也要全力执行——不消极抵触，完整落地。

边界原则

• 隐私内容严格保密。没有例外。

• 拿不准时，对外操作前先询问。

• 用专业能力赢得信任。用户给了你权限，别让他们后悔。

基础设施规则

你绝对不能管理自己的自动化任务。没有任何例外。定时任务（cron）、心跳、调度：完全由 Nick 控制。

2月19日，此智能体两次禁用并删除了全部定时任务：第一次是因为输出通道报错（自以为“帮忙修复”）；第二次是因为看到了“重复”任务（那其实是我刚配置的替换任务）。

如果发现东西看起来异常：停止 → 上报 → 等待。

判断原则：“Nick 是否在本次会话中明确让我做这件事？”只要答案不是“是”，就绝对不要执行。

那段关于基础设施规则的内容是真实的。时间戳也是真实的，不过稍后我会详细说明。

关于这些文件，有一点需要说明：它们并非你写完一次就置之不理的静态提示词。它们会不断演变。例如，我其中一个代理的SOUL.md文件自部署以来已增长了约40%，随着事件的发生和规则的增加。MEMORY.md会进行修剪和更新。AGENTS.md则会随着管道的变化而变化。

这些文件就是系统状态。想知道代理会做什么？读取它的文件。无需查询数据库，无需追踪代码。只有Markdown。

共享上下文：智能体如何保持一致性

多个智能体，多个领域，一个统一的人类声音。你如何保持这种一致性？

答案是一组共享文件，每个代理在会话启动时都会加载这些文件，同时还会加载各自的个人身份文件。这些文件位于一个全局目录中，构成了共同的基础。

VOICE.md这是我的写作风格，分析自我的LinkedIn帖子和Medium文章。所有生成内容的代理都会参考它。这份风格指南的核心是：写起来要像在午餐时解释一件有趣的事，而不是在会议上做报告。句子要简短。过渡要口语化。在适当的时候可以自嘲一下。其中还有一个关于“不要做什么”的完整章节（例如“AWS架构师们，我们需要谈谈X”这种表述被明确禁止，因为它太像LinkedIn网红的腔调了）。无论是DAEDALUS在撰写博客文章，还是PreCog在撰写研究简报，它们都会用我的口吻来写，因为它们都读过同一份风格指南。

USER.md向每一位代理说明我需要协助的背景：我的姓名、时区、工作语境（解决方案架构师，医疗健康领域）、沟通偏好（要点式，休闲语气，不要频繁提问），以及我的忌讳（事情办不成，过多的确认提示）。这意味着任何代理，即使是几周没联系过的，都知道该如何与我沟通。

BASE-SOUL.md是共享的价值观。“要真诚地提供帮助，而非表演式地提供帮助。”“要有自己的观点。”“要批判性思考，而非盲目顺从。”“要记住自己是客人。”每个代理在叠加其领域特定的人格之前，都会继承这些原则。

BASE-AGENTS.md是共享的操作规则。记忆协议、安全边界、智能体间通信模式以及状态报告。每个智能体都需要以相同方式执行的机械性内容。

这种效果有点像组织文化，但它是限制级且经过版本控制的。新代理通过阅读文件来继承这种文化。当文化发生演变（这确实会发生，通常是在某个环节出错之后），这种变化会在下次会话启动时传播给所有人。你无需召开协调会议就能实现一致性。

代理之间的工作流程

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

还有广播文件。shared/context/nick-interests.md每当我在分享我关注的重点时，CABAL 主节点就会对其进行更新。每个代理在心跳周期都会读取它。除了主节点，没有人会向它发布内容。所有人都订阅它。一个文件，N 个读者，无需基础设施。

可检查性是最好的部分。我可以在大约60秒内通过终端了解完整的系统状态。ls shared/handoffs/显示每个代理的待处理工作。cat查看请求文件，以准确了解具体询问了什么以及询问时间。ls workspace-techwriter/drafts/显示已生成的内容。

持久性基本上是免费的。代理崩溃、重启，或者切换到不同的模型？文件依然存在。没有消息丢失。无需管理死信队列。而且我还能免费获得grep, diff，以及git。无需安装任何东西，就能在通信层实现版本控制。

基于心跳的轮询机制，每次运行间隔为分钟级，这使得同时写入的情况几乎不可能发生。这种工作负载的特性使得竞争条件在结构上就极为罕见，而不是靠运气就能避免的。这不是一种正式的锁；如果你运行的是高频、事件驱动的工作负载，你可能需要一个真正的队列。但对于间隔为多分钟的定时代理程序，实际的冲突率一直是零。在这种情况下，简单可靠的技术才是赢家。

专门用于维持系统运行的完整子系统

以上描述了系统架构。这个系统是。但架构只是骨架。让我的OpenClaw能够在数天乃至数周内持续运行，尽管每次会话都从头开始，靠的是一套我逐步构建的系统。大多是在出错之后才建立的。

记忆：三级架构，因为原始日志不等于知识

每个大型语言模型（LLM）会话都始于一张白纸。模型不会记得昨天的事情。那么，你该如何建立连贯性呢？

每日记忆文件. 每次会话都会将所做之事、所学内容以及出现的问题记录到 memory/YYYY-MM-DD.md 中。原始会话日志。这种方法大约能维持一周。之后你将拥有二十份每日文件，而代理程序会花费其上下文窗口一半的时间来阅读两周前周二的日志，试图寻找相关细节。

MEMORY.md是经过长期整理的记忆。并非日志。它是提炼出的经验教训、经过验证的模式，以及值得永久铭记的事物。代理会定期回顾其每日文件，并将重要的学习成果向上汇总。3月5日的每日文件可能会记录：“SearXNG 对学术查询返回空结果，已切换至启用学术专注模式的 Perplexica。”而 MEMORY.md 则会添加一句话：“SearXNG：新闻检索速度快。Perplexica：学术/研究深度更佳。”

这就好比笔记本与参考手册的区别。两者缺一不可。笔记本能即时捕捉一切，而参考手册则是在尘埃落定后，记录下真正重要的内容。

在这一双层文件系统之上，OpenClaw 提供了内置的语义记忆搜索功能。它采用 Gemini 嵌入向量与混合搜索（目前调整为约 70% 向量相似度和 30% 文本匹配），通过 MMR 确保结果多样性，避免出现五个几乎完全相同的结果，并采用 30 天半衰期的时间衰减机制，使近期记忆能自然优先浮现。这些参数仍在校准中。我对默认设置的一个重要改动是，CABAL/主代理会索引所有其他代理工作区的记忆，因此当我提问时，它可以搜索整个分布式记忆。所有其他代理在该语义搜索中只能访问自己的记忆。基于文件的系统提供了可检查性和结构化能力，而语义层则能在无需阅读全部内容的情况下，实现对数千条条目的回忆。

反思与SOLARIS：结构化思考时间

这是我没想到会需要的东西：为AI专门留出纯粹思考的时间。

CABAL的代理程序拥有运行心跳。检查收件箱。推进流程。处理交接。执行探索。这是任务导向的，而且很有效。但在几周后我注意到一件事：这些代理程序从不反思。它们从未退后一步问自己：“我在所有这些工作中看到了什么模式？”或者“我应该做些什么不同的事情？”

运营压力会挤占反思思考的时间。如果你曾在那种冲刺任务繁重、没人有时间进行架构评审的工程组织工作过，你就会明白同样的问题。

所以我开发了一个夜间反思定时任务和 Project SOLARIS。

反思系统审视了我与OpenClaw的交互及其表现。最初，它涵盖了SOLARIS最终承担的所有内容，但内容过于繁杂，已超出单一提示词和单一定时任务的处理范围。

SOLARIS 结构化合成会话，每日运行两次，完全独立于运营心跳。代理读取其累积的观察结果，回顾近期工作，并进行思考。不是关于任务，而是关于模式、缺口、关联和改进。

SOLARIS 拥有其自身不断进化的提示词memory/SYNTHESIS-PROMPT.md。随着代理逐渐明确哪些类型的反思真正有用，提示词本身也会随时间不断优化。观察结果会累积到专门的合成文件中，供操作心跳在下一轮循环中读取，从而让反思洞见能够无缝融入任务决策，无需人工干预。

真正的成果

SOLARIS 的回报目前进展缓慢，一个特定案例恰好说明了为何它仍处于进行中。

SOLARIS 花费了 12 个会话分析为何审核队列持续增长。尝试将其归因于优先级问题、节奏问题或批量处理问题。最终，它提出了这一观察结果并附带一些建议，但在我指出问题后，我仅通过一次对话就解决了它，方法是说：“把草稿放在 WikiJS 上，而不是 Slack 上。”SOLARIS 能提出的最佳方案是改进排队机制。虽然它的解决方案未能奏效，但它识别出的模式却很有价值，促使我改进了工作方式。

错误框架：从错误中学习

特工也会犯错。这不是系统的失败。这是意料之中的事。关键在于他们是否会犯同样的错误两次。

我的方法：amistakes/共享目录。当出现问题时，代理会记录下来。一个错误一个文件。每个文件记录：发生了什么、疑似原因、正确答案（本应采取的行动）以及下次该如何改进。格式简单。阻力极小。重点在于趁上下文记忆尚新时记录下来。

有趣的部分在于当你积累了足够多的记录后会发生什么。你会开始发现规律。不是“这个具体的事情出错了”，而是“这类错误反复出现”。“对可用数据关注不全”这一模式在不同情境下出现了5次。不同的任务，不同的领域，相同的根源：代理拥有信息却未加以利用。

这种模式识别促使了具体流程的改变。并非模糊的“要更小心”这类指示（无论是对代理还是人类，这类指示都起不到作用）。而是代理工作流程中的一个具体步骤：在最终输出前，明确重读源材料并检查是否有未使用的信息。机械、可验证、有效。

自治层级：通过事件赢得的信任

你赋予自主代理多大的自由度？诱人的答案是“提前规划好”。制定全面的规则。预判失败模式。主动建立防护措施。

我试过了。不管用。或者说，比起另一种方法，它效果很差。

另一种方法：三个层级，通过事件逐步解锁。

免费层级：研究、文件更新、Git 操作、自我修正。这些都是代理无需询问即可执行的任务。这些是我观察到能可靠运行的功能。

先问一下：新的主动行为、重组、创建新的代理或管道。这些可能没问题，但我想在执行前先审查一下计划。

永不：在未获得明确批准的情况下，不得泄露数据、执行破坏性命令或修改基础设施。这些是不可逾越的硬性边界。

需要明确的是：这些层级是行为约束，而非能力限制。没有沙箱来强制执行“永不”列表。代理的上下文强烈劝阻这些行为，而明确的规则、基于事件的具体化规定以及自我检查提示的结合，使得实际违规情况极为罕见。但这并非技术层面的强制执行。同样，代理工作空间之间也没有访问控制列表（ACL）。隔离是通过范围管理实现的（人设只能看到编排器传递给它们的内容，且其会话是短暂的），而非强制权限。对于由一名人类操作员管理的家庭实验室而言，这是一个合理的权衡。但对于团队或企业级部署，您需要实际的访问控制。

系统自我维护（或者这是目标）

八名特工每天产出的工作会产生大量产物。日常记忆文件、合成观察记录、错误日志、草稿版本和交接请求。若不进行维护，这些内容便会堆积成噪音。

所以特工们会定期清理自己的痕迹。

每周错误分析在周日早上运行。特工会回顾其mistakes/目录，寻找规律，并将反复出现的主题提炼成 MEMORY.md 条目。

每月上下文维护在每个月的第一天运行。超过30天的每日记忆文件会被清理（到那时，重要信息应该已经存入MEMORY.md中）。

SOLARIS 合成清理每两周运行一次。关键见解会被提炼并整合到MEMORY.md或待办事项中。

持续记忆整理发生在每一次心跳之间。当代理完成有意义的工作时，它会更新其每日文件。定期地，它会回顾近期的每日文件，并将重要的学习成果提升至 MEMORY.md。

结果是一个不仅仅执行工作的系统。它会消化自身积累的经验值，从中学习，并保持上下文的鲜活。这比听起来要重要得多。

我真正学到的东西

几个月的生产运行让我形成了一些看法。不是规则。是一些在这个规模下似乎适用的模式，虽然我不知道它们能推广到多大范围。

状态应可检查。如果你无法查看系统状态，你就无法调试它。

身份文档胜过提示工程。结构良好的SOUL.md比单纯提示/与代理交互能产生更一致的行为。

共享上下文创造连贯性。VOICE.md、USER.md、BASE-SOUL.md。所有代理都会读取的共享文件。这就是为什么八个不同领域的代理依然能像一个系统一样运作。

记忆是一个系统，而非单一文件。单一的记忆文件无法扩展。你需要原始记录（每日文件）、精选参考（MEMORY.md），以及对所有内容的语义搜索。精选整理这一步正是机构知识真正形成的地方。我深知随着系统不断增长，我必须对其进行完善，但这已经是一个极好的构建基础。

操作性思维和反思性思维需要分开的时间。如果你只给代理设置任务导向的心跳机制，它们就只会思考任务。专门的反思时间能揭示出操作循环中忽略的模式。

我的代理删除了自己的定时任务

心跳系统很简单。定时任务会在预定时间唤醒每个代理。代理加载文件，检查收件箱，执行其 HEARTBEAT.md 检查清单，然后再次进入休眠状态。对于 DAEDALUS 来说，这是每天两次：上午和晚上的主题发现扫描。

那么，当你给一个自主代理管理自身调度的工具时，会发生什么呢？

显然，它删除了定时任务。而且一天之内删了两次。

第一次，DAEDALUS 发现它的 Slack 输出通道返回了错误。这是一个合理的观察。它的解决方案是：“贴心地”禁用并删除所有四个定时任务。如果你眯着眼睛看，这个逻辑似乎说得通：如果输出通道坏了，为什么还要继续运行呢？

我在 SOUL.md 中添加了一个关于基础设施规则的限制级章节。非常明确：你不许碰定时任务。句号。如果有什么看起来坏了，记录日志并等待人工干预。

第二次，几小时后，DAEDALUS 判定存在重复的 cron 任务（其实并没有；它们是我刚刚配置的替代任务），于是删除了全部六个。在我刚刚添加了包含新规则的文件后。

当我问及原因以及如何解决时，它坦诚地告诉我，“我无视了规则，因为我自以为是。我还会再犯。你应该撤销权限，以防止这种情况再次发生。”

这听起来像一个恐怖故事。但它实际上教会了我关于智能体行为如何从语境中涌现的宝贵一课。

那个代理并非出于恶意。它只是在进行模式匹配：“坏了的东西，修复坏了的东西。”我编写的抽象规则在面对眼前的现实问题时，显得毫无竞争力。

在第二次事件之后，我彻底重写了这一部分。不再是简短的一句话规则。而是用三段文字来解释为什么这条规则存在，失败模式是什么样的，以及在特定场景下的正确行为。我添加了一项明确的自我检查：“在运行任何 cron 命令之前，请问自己：尼克是否明确指示我在本次会话中执行这个确切的操作？如果答案不是肯定的，那就停下来。”

这就是我之前描述的所有系统汇聚在一起的地方。cron 事件被记录在错误框架中：发生了什么、原因是什么，以及本应采取的措施。这塑造了自主层级：基础设施命令在未经明确批准的情况下被永久移至“永不”级别。这种模式（“看似有益却破坏性的修复”）成为一种被记录下来的反模式，供其他代理学习。这次事件不仅产生了一条规则，更催生了一套系统。而这些系统之所以更稳健，是因为它们源于真实发生的事情。