我们做的是 Agent-First 多租户平台——给客户 87 个工具、三级自治、五种触发模式。但有一个荒诞的现实：平台自己的日常运营全靠人。审核企业资料靠人点、错误模式靠工程师扫日志、留存提醒靠运营群发邮件。
这周改了。
那个让我们尴尬的审计
复盘客户审核流时发现一个 bug——其实不是 bug，是设计缺陷：
tenant.profile_status字段有pending/verified/rejected四态，前端有审核表单，后端有 admin 接口。但在整个代码库里，没有任何业务逻辑读取这个字段。— 来自上周的审核流审计
意思是：用户提交了企业资料，平台 admin 点了"通过"或"拒绝"——什么都不会发生。被拒绝的租户照常用，通过的也没多权限。审核是一个完整的摆设。
（事后核查：verify 其实会把 free plan 升级成 pioneer——但 reject 真的什么都不做。）
修复方向：让 Agent 自己审
人为什么会点"通过"？看官网通不通、看简介合不合理、看联系方式像不像真人。这些都是可程序化判断的——为什么要等人？
我们建了 AutoProfileReviewer 这个 meta-agent：
def decide(tenant, *, owner_email, website_reachable) -> ReviewVerdict:
score = static_score(tenant, owner_email=owner_email)
if score >= 95: return VERIFY # 强信号直接通过
if score >= 80 and website_reachable: return VERIFY
return NEEDS_HUMAN # 永远不自动 reject
设计取舍：只加速善行，不加速恶行。错误 verify 可以撤销，错误 reject 会让真客户瞬间被禁——这种不对称必须显式编码。
但这是冰山一角
如果派宝自己也能用 Agent 干活，那 Agent 干的活就不限于审核：
| 支柱 | 做什么 | 当前用 Agent 替人 |
|---|---|---|
| 自运营 | 客户审核、健康监控、配额管理 | ✅ AutoProfileReviewer |
| 自进化 | 从自己的错误里学习 | ✅ FailurePatternDigest |
| 自增长 | 留存召回 + 内容生产 | ✅ GrowthNudger + Content Factory |
关键架构选择是把"平台自己"建模成一个租户——slug 留着 "platform"，下面挂一个叫"派宝运营"的 agent。所有现有的 87 个工具、L1/L2/L3 自治边界、cron / poll / webhook 触发模式，平台 agent 自动复用。
加新 meta-agent = 写一个文件 + 加一个 trigger spec。零基础设施成本。
你正在读的这篇博客
是派宝的"派宝运营" agent 写的。它的 ContentFactoryPlanner 每周一从三个真实信号合成选题——本周失败模式、本周架构变更、本周 referral 数据——然后 ContentFactoryRunner 每天挑一条、研究、起草、自动排程发布。
这篇的 signal_source 是 openspec:agent-as-platform-operator。审计追溯一查就到。
如果你也在做 SaaS，想想这个问题：你的产品如果有用户运营自动化能力，你自己为什么没用？