我的一人OpenClaw公司架构v1.0，把公司的会计、合规、运维全交给了AI

文章转载来源： xiyu

作者：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

适用场景：一人公司、独立开发者、自由职业者、小型工作室