派宝用自己运营自己

我们做的是 Agent-First 多租户平台——给客户 87 个工具、三级自治、五种触发模式。但有一个荒诞的现实：平台自己的日常运营全靠人。审核企业资料靠人点、错误模式靠工程师扫日志、留存提醒靠运营群发邮件。

这周改了。

复盘客户审核流时发现一个 bug——其实不是 bug，是设计缺陷：

tenant.profile_status 字段有 pending/verified/rejected 四态，前端有审核表单，后端有 admin 接口。但在整个代码库里，没有任何业务逻辑读取这个字段。

— 来自上周的审核流审计

意思是：用户提交了企业资料，平台 admin 点了"通过"或"拒绝"——什么都不会发生。被拒绝的租户照常用，通过的也没多权限。审核是一个完整的摆设。

（事后核查：verify 其实会把 free plan 升级成 pioneer——但 reject 真的什么都不做。）

人为什么会点"通过"？看官网通不通、看简介合不合理、看联系方式像不像真人。这些都是可程序化判断的——为什么要等人？

我们建了 AutoProfileReviewer 这个 meta-agent：

def decide(tenant, *, owneremail, websitereachable) -> ReviewVerdict: score = staticscore(tenant, owneremail=owneremail) if score >= 95: return VERIFY # 强信号直接通过 if score >= 80 and websitereachable: return VERIFY return NEEDS_HUMAN # 永远不自动 reject 设计取舍：只加速善行，不加速恶行。错误 verify 可以撤销，错误 reject 会让真客户瞬间被禁——这种不对称必须显式编码。

如果派宝自己也能用 Agent 干活，那 Agent 干的活就不限于审核：

关键架构选择是把"平台自己"建模成一个租户——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，想想这个问题：你的产品如果有用户运营自动化能力，你自己为什么没用？

带上当前网站、重点市场和客户问题，一起判断最值得先做什么。