原来乱在哪里
我们本机让 Pi Agent 帮忙管理一套视频生成工作流。口头说“以后让 Pi 管它”，不能回答 Pi 能做什么、入口在哪、是否会消耗生成额度，也不能让下一位 Agent 判断它是否已通过实际任务。
启明做了什么
启明先确认这套视频工作流已经是本机项目里持续维护的会员，再为独立的 Pi 操作入口建立子会员。它的卡片有自己的 ID，part_of 指向工作流会员，derived_from 指向这次实现任务；Pi 的项目工作目录和 Skill 是它的真实入口，不是复制一套新的服务档案。
这件事给“每个 AI 都是会员”补上了精确含义。视频工作流是被管理的服务；Pi 是一个执行工作的平台；项目级 Pi 入口是为这个服务定制的操作能力。它有独立用途和维护周期，所以可以成为子会员。一次 Pi 对话只是一段工作证据，不能因为用了 AI 就另建会员。以后如果为同一服务又做了一个 MCP，先看它是否提供稳定接口、谁负责升级、是否能被多个 Agent 使用，再决定是 Pi 入口的附属工具、服务的另一个子会员，还是一个跨项目复用的独立会员。
留下了什么
Pi 项目里有 AGENTS.md 说明操作边界，有项目级 .pi/skills/…/SKILL.md 把“查项目、看队列、诊断错误、提交生成”映射到原工作流的现有说明，还有只读状态脚本和对应测试。状态脚本先查本机服务与扩展连接，不提交生成。会员卡和实现任务指向这些入口，不复制一套新的工作流说明。
验证到哪里
已有证据表明 Pi RPC 能发现项目 Skill，状态脚本返回与本机 API 一致，连接、断开、项目不存在三种隔离情况通过测试。模型认证、Pi 在真实会话里完成代理检查，以及真实媒体生成仍待验证。所以这里的结论是“入口就绪、实用仍待验”，不是“Pi 已全自动接管”。
下一步先让 Pi 只读说出服务归属、当前任务、上次证据和待复核状态；答对后再交给它一项小范围任务，并记录请求、输出、额度或失败。项目 Skill 可被发现，与 Agent 能按启明规则执行任务，是两种不同验收。