作者：xiyu 不想阅读的，可以直接发给你的 openclaw 一个人 + OpenClaw = 一个管理团队 用开源 AI Gateway 打造一人公司全栈管理系统 ai时代以前的单人公司如果你在经营一人公司或者独立业务，大概是这样的节奏：上午对账、下午写方案、晚上处理合规文件，中间还要回客户消息、检查服务器状态、更新数据报表。 你不是在做一份工作，你是在同时做五份工作。 大多数人的第一反应是找个 AI 聊天机器人帮忙。ChatGPT、Claude，确实能回答问题、写写文档。但用了一段时间你会发现——聊天机器人解决的是「问答」问题，不是「管理」问题。 你需要的不是一个更聪明的助手，而是一个 AI 管理层：能分工、能记住上下文、能自动执行任务、能在该请示的时候请示你。 这篇文章分享我用OpenClaw（一个开源的 AI Gateway）搭建一人公司全栈管理系统的完整思路和踩坑经验。不是概念验证，是实际在跑的系统。 为什么是 OpenClawOpenClaw 的优势： 开源、自托管 —— 数据全在自己机器上，不经过第三方
原生多 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 适用场景：一人公司、独立开发者、自由职业者、小型工作室
阅读原文