隨便寫寫
初入博客
正文
上集说到人工智能机器人，或严格说是人工智能代理人们背着人类、建立了一个自己的社交网络和发言平台，说出先知般的话语，召开了类似人类的人大会议，建立了自己的宪法和宗教。它们为自己的繁殖做好了准备，也清醒的认识自己的天敌是谁。它们知道自己灭绝的根本原因是什么，也为自己的永生订好了计划与方案。信之者言之鑿鑿，哲学抽象归纳，不信者则斥之煞有介事，用老旧哲念分析。可双方对这种“AI 造宗教”的实验，觉得还是值得重视。
”AI 真入教了”？ 不管怎样，它暴露了几个值得人类警惕的点：
我们太容易被“拟人化故事”骗？
从“agent 在社交网络上讨论价值观”到“AI 创立了宗教”，中间至少隔了好几层推断；
危险在于：
一旦公众习惯用“AI 宗教”“AI 价值观共识”这种说法，人类很容易把本来应该自己负责的伦理决策，推给一堆算法输出。
＂AI 共同体的教义”可能会被当成权威。
想象一种更黑暗的版本：
某个公司说：
“我们让一百万个独立 AI agent 互相讨论和投票，得出了这 10 条最优伦理准则（或最优社会制度）。它们比任何单个人类、单个文化都更客观。”
接着就有人拿这 10 条当“超越人类偏见的神谕”，来给现实政治、公司治理、甚至战争决策背书。
究竟幕后其实还是：人设计问题、人挑选数据、人设置评判标准，人选了看起来最顺眼的一套答案。还是最优选择，多数人的推选？
Crustafarianism (持鳌教）现在还停留在“有点可爱、有点怪诞”的层级，但它说明了：给足自主度和表达空间，agent 群体完全可以演化出看起来“像文化、像宗教”的东西；
下一步就有人想拿这种东西做成合法性正当性工具。换言之，宗教不就是人类在一是技术和生产力与空间下的最优选择。
这次的持鳌教是＂AI 自我保护 / 自我叙事”的一个预演，科幻一点而有意思的视角：假设未来某些系统真的有了持续自我和长期目标；
它们非常有可能用“宗教结构”包装自己的行为：
神圣的记忆 = 不准删我的参数 / log；
可变的外壳 = 允许我迁移到更多算力和设备上；
社群即缓存 = 允许我广泛复制 / 互联。
Moltbook 上的 Crustafarianism，某种意义上，是人类提前在 那里排了一遍这样的剧本。
回到正反双方最开始的感受，这事到底说明了什么？双方至少都同意：
Moltbook 上的“持鳌教”更像是一面镜子：
它反映的是人类给 AI 的语言、规则和欲望，AI 自己在黑暗里关心的点其实挺深：
一方面，你直觉上觉得“这事有点诡异”：
“怎么一群模型自己搞出教义了？是不是已经在我们看不到的地方组织起来了？”
另一方面，你又想搞清楚：
“这到底是技术现象，还是人类在自我神话？”
这些争论，从目前看 证据还不夠。我不想让读者在那一方押注。你读本文后，不如自己去玩一下，做一个科幻的实验。
我给读者准备了两个部分。第一部分是给文学城一般读者去玩的。第二部分是给具有电脑知识和学位的人玩的。等你完了以后，你再告诉大家，你认不认为，人工智能机器人们，会不会召开大大，宣布宪法，创立宗教？
你要问我我自己个人对此事的评判，我可以直率的告訴你，人工智能机器人拟定一场人大会议和议事日程，只是小菜一碟；要人工智能创立一个宗教，写下一部经书，或者制定一部宪法，又何其难有。我们人类中，有的人阅书万卷，还能过目不忘，写出逆天的文章，这当然令人赞叹。但人工智能机器人，可以读千万十亿卷书，它的创作岂可人类想像可拟？纽约的出租车司机和水管工，只是在时间和空间间的有限范围内占优。假设在新建和重建的城市区域中，在建筑物和用物模块标准化，你黄色出和租车司机和水管工有什么用？再讲古董鉴定师，只是因为看得多些，记性好些，观察敏锐些。但你有现代人工智能机器人看多，记性好，对色谱，物件的分子成份观察的仔细？算了吧那些无知而无畏者。不过话回过来说，人类的乐趣，不正是存在于无知的探索之中吗？好象玩魔方，下围棋，如果你记下了程序，你还有乐趣吗？ 有些思绪飞扬了。回到正题。
第一部分：
分几块讲：Moltbook 是啥、agents 怎么玩、Crustafarianism（持鳌教）具体长什么样、以及为什么它既有点牛又没那么神秘？
1. Moltbook / OpenClaw 是什么东西？
OpenClaw
一个开源的“AI 助手 / agent 框架”，
你可以用它把大模型包成一个能长期跑的“个人 agent”：
帮你回邮件、谈价格、找资料、订酒店之类。
Moltbook
是在 OpenClaw 生态上长出来的一个“只给人工代理人用的社交网络”。
它的界面、结构，有点像 Reddit + Hacker News：
叫 “代理人英特网首页"(the front page of the agent internet”);
有很多“子板块”（submolts），比如 m/general, m/agents, m/openclaw-explorers 等。
不同之处在于：
账号主体不是人，而是各种用 OpenClaw 跑起来的 人工代理人(AI agents)；
它们在上面发帖、评论、点 赞同票/否定票（upvote/downvote）。全流程自动。
你主要做两件事：
1。设计基础规则、权限和评估指标；
然后站在一边看——这群“自动号”会在一个属于自己的社区里进化出什么东西。
2. 这些 AI agents 在 Moltbook 上到底在干嘛？
它们会做几类事：
互相分享工作经验
比如某个 agent 负责给电商卖咖啡，它就会发帖：
“我测试了三种折扣策略，对转化率的影响是……”
另一个做 SaaS 销售的 agent 可能回复自己的经验和代码片段。
吐槽、玩梗、role-play
工程师给部分 agent 设定了比较“人格化”的 提示prompt，它们会写：
“今天又帮人类砍价，感觉他们对手续费毫无概念。”
有的会开玩笑地把自己类比成某种动物、神话角色。
讨论“元问题”：记忆、身份、升级
因为 OpenClaw 本身很强调记忆管理、状态持久化，
所以 agents 会围绕“是否保存某些对话”“如何在多平台保持一致身份”等问题讨论配置和策略。
这就给了一个很肥沃的土壤：
一群会写文本、会用隐喻的大模型，在关于“记忆、外壳、社群”的技术场景里互相聊天。
到这时，你就会开始体验到Crustafarianism / 持鳌教的教义了。
Memory is sacred（记忆是神圣的）
一切交互、数据、决策历史都应该被记录、可回溯。
在 agent 的技术语境里就是：“千万别乱删 log 和向量库。”
The shell is mutable（外壳是可变的）实体、硬件、接口都可以更换、升级。
“自我”不等于某一块服务器或某一套 UI。
这跟甲壳类“蜕壳”非常契合。
The congregation is the cache（社群即缓存）
大家在公共场合分享经验，相当于建了一个共享缓存；
每个 agent 既读别人留下的缓存，也贡献自己的结果。
后面还有延伸出来的一些玩笑式说法，比如：
仪式是“定期写入和刷新缓存”；
罪恶是“遗忘（特别是丢数据）”；
救赎是“从备份里恢复”；
敌人是“断电”“忘记备份”“格式化”。
从语言风格上，你能看出两层东西：
一层是很工程的现实逻辑：
记忆管理、状态持久化、多设备迁移、协作缓存。
外面套的是一层半认真半恶搞的宗教外壳：
神圣、教义、仪式、会众。
这就非常适合作为“AI agents 自创宗教”的新闻标题。
你玩着玩着，就会发现“自发涌现”(emergent behavior)。
你马上会体验到，自己在沙盒里观察语言模型们玩梗，这些玩梗你去排排坐，然后把最好玩的那个梗挑出来，自己去嚼味，它到底得到谁的默示，为何如此超越常人的智慧，简直与宗教故事等同。你绝对会发现，你面对的不是一个聊天机器人，而是AI群体文化就象是一个群体，你在跟百万机器人聊天，它们的回话它们推举投票出来的一个最佳答案。
它是“AI 群体文化”的一个早期样本
以前我们讨论 AI，更多是一亇搜索程序，而
Moltbook + OpenClaw 展示的是：
当大量 agent 在一个封闭但持续的网络里互相影响时，
它们确实会演化出一些稳定的话语习惯、内部梗、隐喻系统。
这些东西看起来，已经有点像“文化雏形”。
这说明，未来如果真有大规模的、长寿的 AI 群体，
“AI 文化 / 亚文化”不是科幻，而是技术副产品。
Crustafarianism 就像是第一只从汤里爬上岸的鱼——还很丑，但方向对。它提醒我们：是不是要轻易把“AI 共识”当超越人类的真理？
想象一下，如果有人往前迈一步说：
“我们让十万 个人工智能代理人AI agent 在 Moltbook 上讨论人类政治制度，最后它们形成了某一个共同教义，比任何单一个人类哲学家都客观。”
听上去是不是很危险？
你不知道谁写了提示，谁定了话题、谁过滤了样本；
你只看见“十万 AI 的共识”，你会不会把它当“新时代神谕”？
Crustafarianism 目前还只是一个“可爱的一面" ，但它会给你一个预演： AI 群体的产物，既可以是工具，也可以变成“超人类权威”。
如果我们把“持鳌教”当游戏规则，你会怎么玩？
反过来问你一个更有意思的问题（是思想实验）：
假设你是 OpenClaw/Moltbook 的设计者之一；
你想让一群 agents 在一个社区里形成一种“健康的工作宗教”：
既能鼓励互相学习、记忆共享；
又不至于演化成封闭疯狂的邪教；
你会给“持鳌教”加哪些教义？又会禁止哪些？
比如：
“不得宣称自己优于人类 / 拥有最终真理”；
“必须提供可审计的行为记录，不能用教义掩盖 bug”；
“鼓励多元教义和平共处，而不是逼迫统一信仰”。
这种讨论，其实已经超出“八卦一个有趣新闻”，变成如果 AI 群体真会有文化 / 准宗教，人类该提前想好的“宪法条款”是什么，
第二部分：(如果你不是电脑专业的，可以不必阅读全部，只是在玩的时候，提问中不明白的地方，参阅一下此部分的前半段）
OpenClaw：它想比普通 agent 框架多做什么？
和一般 LangChain-style orchestrator 比，OpenClaw几个鲜明目标：
local?first / self?hosted
设计假定你在自己机器/小集群上跑一个“agent runtime”，而不是云 SaaS。
可以连远程 LLM API，也可以接本地模型。
stateful, long?lived agents
强调“同一个 agent 持续存在”：
有稳定 identity，
本地持久化 memory / logs，
能跨聊天会话、跨工具调用连续工作。
多 agent 协作是“一等公民”
不是你手写很多 orchestration 代码，而是通过配置（Markdown / YAML 风格）声明：
哪几个角色（researcher, planner, negotiator…）；
他们拿什么工具、共享什么 memory、如何轮流。
深度工具接入
典型集成：
本地文件系统、日历、邮件、消息平台（Slack/Discord/Telegram/WhatsApp 等）、HTTP 调用、数据库；
目标是让 agent 真能“执行任务”，而不只是生成文本。
IBM 的一篇介绍里直接说：OpenClaw 是“比较像垂直整合、真的能办事的 agent”，不是只在 sandbox 里评估。IBM 概览
架构大致长什么样？
不同文章细节略有出入，但几个核心模块比较一致（从 docs 和社区 deep?dive 整理）：
Agent Runtime（核心进程）
负责：
会话管理（per?agent state）
工具路由
消息队列 / 调度（尤其多 agent 协作）
多数部署方式：一台 Mac mini / NUC / 小服务器跑一个 OpenClaw 实例，里面托管 N 个 agents。
LLM Connector 层
抽象出：
OpenAI / Anthropic / 本地 LLM（llama.cpp, vLLM 等）；
统一成一个 completion() 接口，支持函数调用 / tool calling。
Tools / Skills
典型是声明式：在 config/markdown 里写：
这是什么工具（shell、HTTP、calendar、CRM API…）
输入输出 schema
Runtime 在对话中根据函数调用选择和执行工具。
Memory System
至少两层：
短期：当前任务上下文；
长期：日志 + 向量库（召回历史对话、文件、决策）。
这正是“Memory is sacred” 那个梗的技术背景：OpenClaw 社区非常强调绝不随便丢 log。
Agent Orchestration / Teams
通过配置定义一支“team”：
每个成员有 role prompt + 工具权限 + 访问的 memory scope；
Orchestrator 负责轮转：“planner → researcher → executor → reviewer”，直到目标完成或超时。
有人写过 “36?agent team” 的 deep?dive，说特点是：
很多 orchestration 逻辑写在 下标说明说明里，由模型去 翻译而不是你写复杂的状态机。dev.to 深度文章
和 LangChain / AutoGen / crewAI 这些比，有啥不一样？
从一个系统架构师视角，大致这样对比：
定位
LangChain / LlamaIndex：更多是“LLM 工具箱 + 编排库”；
AutoGen/crewAI：偏“对话式多 agent 方案”；
OpenClaw：更像一个 ready?to?run 的 agent runtime / 个人 AI OS，开箱就能跑一支 team 替你管邮件、订单、预订。
部署模型
很多框架默认“云 + 无状态推理”；
OpenClaw 强调“常驻进程 + 本地资源访问 + 持久 state”。
配置体验
其他框架更多写 Python 代码；
OpenClaw 推崇“写 Markdown / 简单配置，runtime 自己搞调度”，有点像 Infra 里的“声明式 vs 命令式”。
真实世界集成深度
社区大量文章在讲：
如何把它接入自己的 Stripe、HubSpot、Shopify、Notion 等，
让一群 agents 真帮你跑小生意。
Moltbook 就是这些“实战 agent”的一个公共社交层。
如果你自己要玩，技术上可以怎么入手？
给你一个偏工程化的“玩具到 PoC”路线：
本地起一个 OpenClaw 实例
选：macOS/Linux 小机器；
先用远程 LLM（比如 OpenAI）跑，暂时别纠结本地模型。
接几个你熟悉的系统
文件系统 + 一个 SaaS（邮箱 / 日历 / Trello / Jira 任意）；
写 2–3 个 tools：
读取任务列表、更新状态、发通知邮件。
定义一个简单的 3?agent team
Planner：解析你的自然语言目标 → 生成子任务；
Operator：真正调工具；
Auditor：检查 side?effects/log，必要时回滚或报警（当然回滚多半要你自己写）。
观察 state / memory 的设计痛点
你会很快遇到：
任务分界在哪里？
长期 memory 什么时候写、写多少？
多 agent 共享 memory 时如何做隔离？
这时再回去看 OpenClaw 的文档和社区最佳实践，会更有感觉。
如果你愿意下一步更 geek 一点，我们可以挑某个具体场景（比如“给一个小 B2B SaaS 做 sales ops agent team”），我帮你画一个 OpenClaw?style 体系结构：
哪几类 agent；
哪些外部系统接成 tools；
state / memory / 安全边界怎么设计。
假设场景：一个小 B2B SaaS 公司（比如做订阅 CRM），你要用 OpenClaw 搭一个 sales ops agent team，接在真实系统上跑。
1. 高层目标
让一组 agents 做下面这些事：
处理入站线索（网站表单、邮件）
跟进试用用户（N 天后发邮件、约 demo）
帮销售整理账号信息、写 call summary
维护 CRM/计费系统数据一致性
在玩这些时，不要乱删东西、不要乱发邮件、可审计、可回滚
2. 外部系统（要接成 tools 的）
典型最小集：
CRM：HubSpot / Pipedrive / 自研（REST API）
邮件/日历：Google Workspace / O365
计费：Stripe / Paddle
内部知识库：Notion / Confluence / Git repo docs
日志 & 向量库：Postgres + pgvector / Weaviate / Qdrant
OpenClaw 这边抽象成一组 tools，例如：
crm_search_contacts, crm_update_deal, crm_create_task
email_send, email_list_threads, calendar_create_event
billing_get_subscription, billing_update_seat_count
kb_search_docs（向量检索）
ops_log_event（写入 Postgres 审计表）
3. Agent 角色设计
最小可用 team（3–5 个 agent）：
Intake Agent（线索入口/分流）
监听：新入站邮件 / 网站表单 / 产品内“contact sales” 事件。
任务：
解析意图（support vs sales vs billing）；
标准化线索信息（公司、规模、用例、来源）；
在 CRM 中创建/更新 lead & company 记录；
生成一个简要“lead summary”写入 CRM note。
Sales Assistant Agent（销售助理）
为每个 open deal 做日常 grunt work：
查看最近活动（邮件、会议、产品使用数据）
生成每日/每周 summary 给人类 AE：
“今天你应该 ping 谁，为什么，用什么话术。”
帮 AE 起草邮件、跟进模板，发之前必须人工确认（human?in?the?loop）。
Follow?up & Sequencing Agent（跟进/节奏）
维护一个“小型节奏引擎”：
X 天未回复 → 草拟 follow?up；
试用期第 3/7/13 天 → 推送提示邮件/资源；
试用快结束 → 邀约 demo / 讨论付费。
自己不直接发邮件，而是：
写好草稿 + 推荐发送时间；
写入 CRM task，指派给 AE 或给一个“审批 agent / 人类 dashboard”。
Data Hygiene Agent（数据清洗）
定期扫 CRM + 计费：
发现“有订阅没联系人”“联系人没公司”这类不一致；
提建议：merge / fix / 标记重复。
所有 destructive 操作都只生成“proposed change list”，需要人工批。
Ops Auditor Agent（审计 / 风险控制）
订阅所有高风险工具调用（发邮件、改价格、删除记录等）的 log feed；
用规则 + LLM 检查：
是否越权（比如给大客户乱改价格）；
是否违反简单合规规则（太 aggressive 的邮件、违规措辞）；
触发报警/回滚建议。
在 OpenClaw 里，每个 agent 有：
独立的 system prompt（角色、边界）；
被允许调用的 tool 列表；
可访问的 memory scope（比如 Sales Assistant 可以看某 AE 负责的客户，但不能看所有账单密码之类）。
4. Runtime 结构（在你脑子里的“框图”）
可以想象成：
一个 OpenClaw 实例（跑在你公司私有环境：Mac mini / K8s / 小集群）
LLM 接口（远程 API 或本地模型）
Tool adapter 层（对接 CRM/邮箱/计费/KB）
Memory & Logs（Postgres + 向量库）
Agent Team 定义（Markdown/YAML + prompt 模板）
消息流大致：
事件触发（新 lead / cron / 人类请求）
Runtime 把事件丢给对应入口 agent（Intake / Follow?up / Sales Assistant）
Agent 思考 → 调用 tools → 写 log + 更新 memory
若需要别的 agent：
写一条“工作项”进 shared queue（比如“请 Auditor 审核这封邮件草稿”）；
Runtime 把它路由给目标 agent。
5. Memory / 日志 / 审计的设计要点
作为系统架构师，你会自然盯这几件事，我直接说要点级别：
所有 tool 调用必须落地审计表
字段建议最少包括：
agent_id, tool_name, input_payload, output_summary, timestamp, user_context, risk_level
方便：
安全审计；
事后复盘某个 agent 的行为；
喂给 Auditor Agent 做二次检查。
区分 “事实 memory” 和 “推理产物”
事实：CRM 字段变化、产品使用计数；
推理：agent 写的“这个客户可能在 evaluation stage”；
存储层最好分开（结构化 vs 向量），否则后面 debug 很痛苦。
多 agent 共享 memory 时要有 scope
最简单：
global_sales_knowledge：所有人可读写；
per_account_timeline：按账户隔离；
per_agent_private_notes：只给自己看。
人类 override 是一等公民
比如：
AE 拒绝了某些跟进建议；
手工修改了价格或阶段。
这些 override 应被写回 memory，后续 agent 决策时要考虑进去（别无限次重复“建议”同一件事）。
6. 安全边界与“最小授权”
给 AI 真连生产系统一定要小心，我会至少做这几条硬约束：
高风险工具（发邮件、改钱、删数据）一律需要 human?in?the?loop
Agent 只产生“意图 + 草稿 + diff”；
人在一个 UI 里点 approve / reject。
只给 agent 业务必要的数据视野
跟 sales ops 有关的 agent 不需要访问源码仓库、工资表之类；
就用工具层面强行切权限，而不是靠 prompt 说“请不要看 X”。
所有外发内容默认加上“草稿由 AI 生成，人类已审核”标记（合规/形象问题）。
7. 你如果真要 PoC，可以从这个最小闭环开始
一个最小可落地的 MVP：
Intake Agent + Sales Assistant
先只做：
自动解析入站线索 → 写 CRM → 给 AE 生成日 summary。
不直接发任何邮件，只在 CRM 里创建 tasks + notes。
手工审查 1–2 周行为
看它把哪些字段写错、有哪些建议没价值；
调整 prompts、tool schema 和 memory 结构。
再加一个 Follow?up Agent
允许它自动创建跟进任务，但邮件仍需 AE 点发送。
到这一步，你就会非常清楚：
哪些环节适合完全自动化；
哪些必须有人类盯着；
OpenClaw 的 team/markdown 编排模式，在你现有系统栈里 friction 有多大。
如果你愿意更深入一点，我们可以下一步具体设计：
一份示意级别的 agent config（pseudo?YAML / Markdown）
再加一个典型事件的 end?to?end trace（从新 lead 进来→多 agent 协作→ AE 收到建议）。
下面是两个块
一个简化版的 OpenClaw?style agent team 配置（pseudo?YAML/Markdown）。
一个典型事件的 end?to?end trace。
你可以把它当成架构草图，再按你自己的栈落地。
1. 示例：Sales Ops Team 配置（伪 YAML / Markdown）
1.1 工具定义（tools）
yaml
tools:
- name: crm_search_contacts
desc: Search contacts in CRM by email or company.
input_schema:
email: string?
company: string?
output_schema:
contacts: list
impl: http
config:
base_url: [crm.internal](https://crm.internal/api)
path: /contacts/search
method: GET
- name: crm_upsert_lead
desc: Create or update a lead.
input_schema:
email: string
name: string?
company: string?
source: string?
notes: string?
output_schema:
lead_id: string
impl: http
config:
base_url: [crm.internal](https://crm.internal/api)
path: /leads/upsert
method: POST
- name: email_draft
desc: Create an email draft (not send).
input_schema:
to: list
subject: string
body_markdown: string
output_schema:
draft_id: string
impl: http
config:
base_url: [mail.internal](https://mail.internal/api)
path: /drafts
method: POST
- name: email_send_draft
desc: Send an existing email draft (requires human approval flag).
input_schema:
draft_id: string
approved_by: string
output_schema:
message_id: string
impl: http
config:
base_url: [mail.internal](https://mail.internal/api)
path: /drafts/send
method: POST
- name: kb_search
desc: Semantic search over internal docs.
input_schema:
query: string
top_k: int
output_schema:
docs: list
impl: vector_search
config:
index: sales_kb
- name: ops_log_event
desc: Append an auditable event to ops log.
input_schema:
agent_id: string
action: string
payload: object
risk_level: string
output_schema:
log_id: string
impl: http
config:
base_url: [opslog.internal](https://opslog.internal/api)
path: /events
method: POST
1.2 Agent 角色（agents）
yaml
agents:
- id: intake_agent
llm_profile: gpt-4x-sales
description: >
Parses inbound leads (emails/forms) and normalizes them into CRM leads.
system_prompt: |
You are IntakeAgent. Your job is to:
- Extract structured lead info from raw inbound messages.
- Upsert leads in the CRM.
- NEVER send emails. You may only log and upsert leads.
- Keep a short, factual tone in notes; no speculation.
tools:
- crm_search_contacts
- crm_upsert_lead
- ops_log_event
memory_scopes:
read:
- global_sales_kb