作者：xiyu
不想阅读的，可以直接发给你的 openclaw
一个人 + OpenClaw = 一个管理团队
用开源 AI Gateway 打造一人公司全栈管理系统
ai时代以前的单人公司
如果你在经营一人公司或者独立业务，大概是这样的节奏：上午对账、下午写方案、晚上处理合规文件，中间还要回客户消息、检查服务器状态、更新数据报表。
你不是在做一份工作，你是在同时做五份工作。
大多数人的第一反应是找个 AI 聊天机器人帮忙。ChatGPT、Claude，确实能回答问题、写写文档。但用了一段时间你会发现——聊天机器人解决的是「问答」问题，不是「管理」问题。
你需要的不是一个更聪明的助手，而是一个 AI 管理层：能分工、能记住上下文、能自动执行任务、能在该请示的时候请示你。
这篇文章分享我用 OpenClaw（一个开源的 AI Gateway）搭建一人公司全栈管理系统的完整思路和踩坑经验。不是概念验证，是实际在跑的系统。
为什么是 OpenClaw
OpenClaw 的优势：
-
开源、自托管 —— 数据全在自己机器上，不经过第三方
-
原生多 Agent —— 不同 Agent 有独立的人格文件（SOUL.md）、工具权限、记忆空间
-
Discord 集成 —— 频道就是部门，发消息就是下指令，天然的管理界面
-
持久运行 —— 不是跑一次就结束的 workflow，而是 7×24 在线的 Gateway
最关键的一点：频道 = 部门，消息 = 指令。这个模型天然适合管理场景。你在 #accounting 频道说「本月支出汇总」，会计 Agent 自动响应；在 #ops 频道说「检查服务器状态」，运维 Agent 接手。不需要记住任何命令语法，就像给下属发消息一样自然。
多 Agent 架构设计
角色分工
我的系统目前规划了这些角色：
-
CTO Agent —— 技术负责人，系统架构、代码、部署、工具开发
-
会计 Agent —— 记账、对账、月度结算、报表生成
-
业务 Agent —— 客户沟通、订单跟踪、报价管理
-
合规 Agent —— 法规检查、文件归档、定期扫描
-
监控 Agent —— 系统心跳、异常告警、资源监控
阶段化激活
这里有一个很重要的设计理念：不要一开始就把所有 Agent 都激活。
业务量小的时候，让 CTO 代行会计和合规的职责就够了。等业务量上来，再逐步拆分：
阶段 A（起步期）：CTO 一人多职，其他 Agent 休眠
阶段 B（稳定期）：激活会计 + 合规，CTO 专注技术
阶段 C（扩展期）：全员上线，各司其职
阶段切换可以用定时任务自动检测触发条件（比如月交易笔数超过阈值），也可以手动切换。关键是 架构先搭好，激活按需来。
频道路由
#cto-office → CTO Agent
#accounting → 会计 Agent
#compliance → 合规 Agent
#ops-monitor → 监控 Agent
#general → 所有 Agent 都能看到，按需响应
OpenClaw 的配置文件里可以指定每个 Agent 监听哪些频道。消息进来后自动路由，不需要手动 @。
决策权限矩阵
这是整个系统最重要的设计之一：
护栏内 → Agent 自主执行，事后记录
护栏外 → Agent 暂停，@老板请求决策
不确定 → 视为护栏外，宁可多问一次
举个例子：
-
记一笔常规支出 → 护栏内，自动执行
-
删除一条数据库记录 → 护栏外，必须确认
-
遇到一个没见过的税务分类 → 不确定，上报
关键原则：Agent 永远不应该在不确定的情况下自作主张。 误操作的修复成本远高于多问一句的沟通成本。
数据架构
单一数据源
所有业务数据存在本地 SQLite 数据库里。为什么不用 MySQL 或 PostgreSQL？因为一人公司不需要并发，SQLite 零配置、零运维、一个文件搞定，备份就是复制文件。
~/.openclaw/data/main.db
├── transactions # 交易记录
├── clients # 客户信息
├── documents # 文书索引
├── audit_log # 审计日志
└── ...
统一操作层
所有数据库操作必须通过一个统一的操作脚本（比如 db_ops.py），禁止直接写 SQL。好处：
-
自动审计 —— 每次操作自动记录：谁、什么时候、做了什么、改了什么
-
格式统一 —— 不会出现一个 Agent 用这种格式、另一个用那种格式的问题
-
权限控制 —— 在操作层就能拦截越权操作
Notion 镜像备份
SQLite 是数据源，但不方便人类浏览。所以我用 Notion 做可视化镜像：
-
实时同步：关键操作（新增交易、状态变更）触发即时同步
-
每日兜底：每天 23:00 全量校验一次，确保没有遗漏
-
只读镜像：Notion 那边只看不改，避免双向同步的噩梦
多语言导出
如果你的业务涉及多语言场景，可以在导出层做语言适配：
db_ops.export_csv() # 中文版
db_ops.export_csv() # 英文版
db_ops.export_csv() # 双语对照
列名、分类名、状态标签都在配置文件里维护映射表，导出时自动翻译。
记忆系统
双层记忆架构
工作记忆有容量上限（比如 200 行），超了就要淘汰。长期记忆理论上无限，但检索质量会随数据量增长而下降，需要定期清理。
遗忘曲线：基于引用日期的过期机制
每条记忆都带一个 ref（引用日期），记录它最后一次被实际使用的时间。注意：自动加载不算引用，只有在回复中实际用到才算。
- [2025-01-15][ref:2025-02-20] 供应商 A 的付款周期是 Net 30
- [2025-01-15][ref:2025-01-15] 某个临时备忘（一个月没用到，即将过期）
过期规则：
-
高优先级记忆：ref 超过 90 天淘汰
-
临时备忘：ref 超过 30 天淘汰
-
核心身份信息：永不淘汰
置信度评分
不是所有记忆都一样可信。我给每条记忆加了置信度分数：
来源定价（写入时）：
-
用户亲口确认 → 0.95
-
手动录入 → 0.85
-
自动从日志提取 → 0.50
时间衰减： ref 超过 60 天没被命中的记忆，置信度每天 ×0.95
检索增强： 每次被搜索命中，置信度 ×1.05（上限 0.95）
自动清除： 置信度低于 0.1 时删除
为什么过时的记忆比没有记忆更危险
这是一个血泪教训。没有记忆，Agent 会说「我不知道」，然后你去查。但如果 Agent 记着一条过时的信息（比如三个月前的价格、已经废止的规定），它会非常自信地给你一个错误答案，而你可能不会去验证。
过时的记忆是带毒的缓存。 所以遗忘机制不是可选的，是必须的。
自动化运维
定时任务示例
cron:
- name: monthly-settlement
schedule: "0 10 1 * *" # 每月1号上午10点
action: 月度结算汇总
- name: compliance-scan
schedule: "0 9 * * 1" # 每周一上午9点
action: 合规扫描
- name: system-healthcheck
schedule: "*/30 * * * *" # 每30分钟
action: 系统心跳检查
- name: data-sync
schedule: "0 23 * * *" # 每天23点
action: 数据同步到 Notion
- name: memory-cleanup
schedule: "30 23 * * *" # 每天23:30
action: 记忆过期清理
心跳监控
每 30 分钟让监控 Agent 检查一次系统状态：Gateway 是否在线、磁盘空间、数据库完整性。异常时通过 Discord 告警。
自动升级检测
定期检查 OpenClaw 是否有新版本，有的话通知你，但不自动升级（升级属于「护栏外」操作）。
安全设计
一人公司的 AI 系统，安全设计不能省。因为出了事没有别人帮你兜底。
敏感操作按钮确认
所有危险操作（删除、修改关键配置、执行 shell 命令）必须弹出确认按钮：
⚠️ 确认执行？
操作：删除 2024 年归档数据
影响：不可恢复
[✅ 确认] [❌ 取消]
不是文字确认，是 Discord 的交互组件按钮。防止 Agent 自己「点确认」。
命令白名单 + 分级控制
? 自由执行：ls, cat, head, tail, sqlite3 (只读)
? 需要记录：python3, node, 写文件操作
? 需要确认：rm, chmod, 网络请求, 数据库写入
⛔ 绝对禁止：sudo, 修改系统文件, 访问敏感目录
蜜罐文件检测
在敏感目录放几个「蜜罐文件」（honeypot）。如果 Agent 试图读取这些文件，说明它可能被 prompt injection 了，立即触发告警并暂停该 Agent。
PII 审计扫描
定期扫描所有 Agent 的输出日志，检查是否意外泄露了个人身份信息（PII）。一旦发现，告警 + 自动打码。
踩坑经验
Mac 做服务器的休眠问题
如果你用 Mac 跑 OpenClaw Gateway，一定要处理休眠问题。Mac 默认会在空闲时休眠，Gateway 随之断开。解决方案：
# 禁止休眠（需要 sudo）
sudo pmset -a sleep 0 displaysleep 0 disksleep 0
# 或者用 caffeinate 保持唤醒
caffeinate -s &
但要注意散热和电费，长期跑建议上个低功耗的 Linux 设备。
exec 权限平衡
给 Agent 的 exec 权限太大，它可能误操作搞崩系统；太小，很多自动化任务跑不了。我的经验是：
-
默认最小权限
-
按需开放，每次开放都记录原因
-
用白名单而不是黑名单
Gateway 重启后 session 断开
OpenClaw Gateway 重启后，之前的对话 session 会丢失。如果你有依赖 session 上下文的长任务，要么做好断点续传设计，要么把关键上下文写入文件。
Notion API 的各种限制
-
每分钟请求数有限制（rate limit）
-
单个 block 的文本长度有上限（2000 字符）
-
不支持某些富文本格式
-
数据库属性类型变更会导致同步脚本报错
建议：同步脚本要做好错误处理和重试逻辑，不要假设 API 调用一定成功。
配置合并只能追加不能替换
OpenClaw 的配置文件合并逻辑是追加式的，不是替换式的。也就是说，如果你在本地配置和全局配置里都定义了同一个字段，结果是合并而不是覆盖。踩过坑之后我学会了：关键配置只在一个地方定义，不要分散。
一个人经营一家公司，最大的瓶颈不是能力，而是带宽。你不可能同时精通会计、法务、技术、业务，还要保证每件事都不出错。
一个人 + 一套设计良好的 AI 系统 = 一个完整的管理团队。
但关键词是「设计良好」。这意味着：
-
权限边界清晰 —— Agent 知道什么能做、什么不能做、什么要问
-
数据流可追溯 —— 每一笔操作都有记录，出了问题能查
-
安全不妥协 —— 蜜罐、白名单、PII 扫描，一个都不能少
-
记忆会过期 —— 过时的信息比没有信息更危险
-
阶段化演进 —— 不贪多，按需激活，保持系统简单
这不是一个「用 AI 替代人」的故事，而是一个「用 AI 让一个人能管住一摊事」的实践。
系统还在持续迭代中，但核心架构已经稳定跑了一段时间。如果你也在考虑用 AI 来管理自己的独立业务，希望这些经验对你有用。
技术栈：OpenClaw + SQLite + Notion + Discord + Python
适用场景：一人公司、独立开发者、自由职业者、小型工作室
